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.
Cool. In most cases, the logic to programatically resize a window
when controls are hidden is tricky, but it sounds like you have a
good solution. I would probably just create separate nibs and set
the default windows size in IB, but his is an unimportant
implementation detail :).
[Deleted]
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 am curious how you avoid complex code to deal with all the
permutations in cases where that are many. When there are many
permutations, that implies that the are many different ways the
window will have to be sized and visible controls repositioned based
on the many different permutations of visible and invisible
controls. However, as long as its all an implementation detail of a
user interface that does not surprise users, I have no philosophical
objection. The best implementation is always the one that works and
is most easily explained and maintained.
[Deleted]
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.
I hope that an objection to making Mac software look different than
PC (Windows) software does not become too common. I understand that
you are working on games, and frankly, games are a special case for
lots of reasons. Users do not expect games to conform to the
platform standards and immersion is critical etc.
I agree that tables are not always the best solution... I just raised
the idea because it sounded like you needed an arbitrary number of
similar interface elements repeated using an interface convention
that users recognize.
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).
[deleted]
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.
I think we are not too far apart on this philosophy :)
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
This is an excellent point, and you have caused me to reevaluate my
position somewhat. I think that status indicators (whether
implemented as controls or just icons) can and should be hidden as
you suggest. This particular example really strikes home for me
because there is a real world analog: The caps-lock key on my
keyboard has a little light the is on when caps-lock is on. Having
an icon appear in the user interface to remind users that caps-lock
is on when they are about to enter case sensitive information is
helpful and not counter user expectations from related interfaces :)
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.
Many web interfaces show a red exclamation point or other indications
if required elements of a form have not been entered. This is
another good example of a status item.
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.
The flip side is that code that is complex in order to provide
generality is often very hard to maintain. The best implementation
approach is clearly something that the programmer in the trenches can
decide better than me in my remote office full of high ideals.
If all presentations of a user interface are 99% the same but there
are many permutations that that effect the remaining 1%, I am going
to be very suspicious of a complicated code solution. You suggest
that the interface is determined by data, ant that is an excellent
approach. Perhaps you can use the nib file format as your data file
format ? Perhaps use one nib for the 99% that doesn't change and
just load a small "accessory" nib for the each of the permutations.
Just a though.
I occasionally encounter people who resist the idea of using a
separate set of nib files for each cultural/language localization of
their applications. They cite the same objection that there will be
duplication and keeping the nib files synchronized will be
difficult. I counter that trying to shoe horn the different
localizations into one nib will seldom produce nice results for any
localization. Furthermore, if given the choice between maintaining
more [and more complex] code or maintaining data files, I will
usually chose to maintain the data files. Nib files are data
files :) Of course, there is no universal rule, and each situation is
best handled by the people close to it...
_______________________________________________
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
