Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hiding a control on MacOS10.2


Erik Buck wrote:


On Jul 31, 2005, at 11:53 AM, John Stiles wrote:

There are lots of perfectly legitimate reasons to hide a control. In my case, I was writing an app which let you install our games. There was a dialog which, depending on which game you're installing, would either ask you for:
- your name
- your name and a CD-key
- your name and two CD-keys


Why not just disable the fields that do not apply ? When you hide a filed, do you resize the window or just leave a mysterious blank space in the window ?

Resized, of course. I did some trick with springs that made it trivially easy (I just had to set the window size and the rest of the controls did the right thing). It's been a while since I set that up so I've forgotten the specifics.


Now, what should I do? Build three identical dialogs and then make minor changes to each one? Then write all the glue code to shuffle between these three dialogs? Talk about a hassle! It's much better to make one dialog with all the necessary controls, and programatically hide the ones that don't apply for the current product.


It is easier to programatically disable the ones that don't apply. Furthermore, why not leave the controller code unchanged and just load a different nib based on what applies. It is certainly no harder to load a nib based on applicability than to hide controls in one nib based on the same criteria. Furthermore, each different nib can have its own layout, window size, etc. as desired. There is no need to have different controllers. Loading different nibs with the same controller is fine, and any fields that don't exist in a particular nib will be left unconnected as unconnected outlets in the controller.

If there were 5 or 6 items at stake, you do realize that the number of permutations grows pretty fast, right? At worst it's a 2^n proposition.
In my case, there were only 3 permutations and I actually think it would have been pretty icky to have to maintain 3 nibs with 99% the same content. Any time I want to make a change, I need to change all 3 nibs? Forget about it. Now if there were 10 or 40 permutations, it stops being just a hassle and just becomes ridiculous.



I had another program; it displays a dialog that, depending on the product that you owned, would show:
- a message and 'OK'
- a message, 1 checkbox, and 'OK'
- a message, 2 checkboxes, and 'OK'
- etc etc, up to 4 or 5 checkboxes.

Great! Did you consider a table ?

No; it would look different than the PC version, and frankly I don't think it would look much like a regular Mac application either. For a product with 0 or 1 checkboxes, in particular, it would look *really* odd to have a table with nothing in it or a single checkbox entry in it. I think having a list of checkboxes in a scrolly table view is pretty nasty UI unless you have 10+ checkboxes to deal with.

How much text is involved in messages ?

About a sentence worth. Probably not enough that it would need to wrap (that would rule out a table).

Is there ever a scroll bar required ?

It's checkboxes and buttons. How would you manage to get a scroll bar in there? I don't even follow.

Do the labels for the check boxes ever change ?

Yes. In fact they are always generated from data (much like the number of checkboxes available also comes from data).

<snip>


A) The user interface never changes from the point of view of the user, but hidden elements exist that enable a programmer to use the same code and interface combination for different applications.

I don't fundamentally object to hiding controls in this situation because it has no impact on users. However, hiding strikes me as a very poor substitute to just loading different nib files. The hiding technique seems like a throwback to "resource" based GUI descriptions that were/are very hard to create well and very inflexible to use. I still claim that loading different nibs but using the same controller "glue" code is actually less work that hiding some controls [unless of course the controls are going to be unhidden at some point in the execution of the application... see B)]

B) Based on the state of the application, controls are hidden or unhidden without the use of a standard user controlled metaphor. This might include expert mode vs. novice mode, context dependent options, etc.

I strongly advise against this for all of the reasons perviously stated. How is the user ever going to discover the options available if they are hidden and the user does not control how they become unhidden in a standard way ? For example, a discloser triangle signals a user that more information is available. A tab view invites users to view what is on each tab. The user controls what is seen, and that is good. A check box that suddenly appears because text was entered in a different field will surprise users. Why not leave the check box visible but disabled until text is entered ? The disabled check box could even have a tool tip telling the user when it will be enabled. Furthermore, if there is space for a hidden control, the user interface will look odd until the control appears... I like to know how my screen real estate is being used or wasted by applications.


I agree with most of the UI portions of your discussion. The UI should appear stable from the point of view of the user. Controls which are sometimes available and sometimes unavailable should typically be grayed out, not hidden.

There are some UI elements where it makes sense to hide and show them based on the user's feedback. Here's one good example--in 10.4, if you press Caps Lock while typing in a password text field, a little icon appears on the edge of the view, and goes away when you press Caps Lock again. Dimming wouldn't make sense here. (I don't know how it's implemented, but it could certainly be done with an embedded NSView.) Also, if the user somehow enters invalid input into a panel, it can sometimes make sense to temporarily show a little Caution icon next to the offending entries, and/or a little box with hint text explaining what they did wrong. Again, dimming those items wouldn't make sense in that situation--they are confusing if they are always there.

I strongly disagree with your notion that hiding controls is something that a programmer should never need to do. Nib duplication, like code duplication, leads to trouble. Any time you have two pieces of code or two assets which are almost identical, you are just begging for trouble; you will eventually screw up and update one and not the other, or edit them both in slightly incompatible ways, etc. It's better to refactor things and avoid duplication.


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Hiding a control on MacOS10.2 (From: Erik Buck <email@hidden>)
 >Re: Hiding a control on MacOS10.2 (From: John Stiles <email@hidden>)
 >Re: Hiding a control on MacOS10.2 (From: Erik Buck <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.