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


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

Oh, let's not go there.

I am certainly not an absolutist, but you raise some interesting examples.

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 ?

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.


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 ? How much text is involved in messages ? Is there ever a scroll bar required ? Do the labels for the check boxes ever change ?

Once again, hiding made way more sense than any of the other options.
I don't understand why every time control hiding comes up, somebody always assumes that there's no need for hide/show. If you think about it for a minute, of course that's not true. Particularly in this day and age, when so many little utility apps are meant to be repurposed again and again, there are plenty of reasons to do it.

It is usually unwise to second guess the programmer in the trenches, but I certainly feel safe suggesting general guidelines.

Consider the following cases:
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.



On Jul 31, 2005, at 6:16 AM, Erik Buck wrote:

One solution for hiding controls is not to do it.

Please see past discussions:

http://www.cocoabuilder.com/archive/message/2001/11/18/16874
http://www.cocoabuilder.com/archive/message/cocoa/2001/11/18/16879
http://www.cocoabuilder.com/archive/message/2001/11/19/16852
http://www.cocoabuilder.com/archive/message/cocoa/2004/9/20/117870

In summary:
Tab Views, Drawers, Info-Window pages, disclosure triangles attached to
expanding/contracting windows, and probably other UI elements are all ways
of hiding user interface elements. However, all of these ways indicate that
more UI is available and how to see it. Tab views show the user how many
tabs are available and the user can cycle through the tabs at any time to
see their contents. There is usually a way for the user to open a drawer
and see its contents.

Having a button or text field suddenly appear where there was none before is
probably going to surprise users. There is no indication to a user that a
hidden control exists. There is no indication to the user how to make the
control visible or invisible. A user who remembers the existence of the
control may be come frustrated when she can not find the control later
because it is hidden and the reason for its being hidden is not obvious.

_______________________________________________
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/jstiles% 40blizzard.com

This email sent to email@hidden



_______________________________________________
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>)



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.