Re: Hiding a control on MacOS10.2
Re: Hiding a control on MacOS10.2
- Subject: Re: Hiding a control on MacOS10.2
- From: John Stiles <email@hidden>
- Date: Sun, 31 Jul 2005 11:19:49 -0700
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:
This email sent to email@hidden