Re: Hiding a control on MacOS10.2
Re: Hiding a control on MacOS10.2
- Subject: Re: Hiding a control on MacOS10.2
- From: Erik Buck <email@hidden>
- Date: Sun, 31 Jul 2005 12:45:08 -0400
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:
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:
This email sent to email@hidden