[DEPRECATED] Instant-Apply and Property Windows (GNOME HIG)

["M. Uli Kusterer" <Witness of TeachText gmx net>]

Hi,

 just read the GNOME HIG. It's a great piece of work. I have a few 
suggestions for clarifications, though:

1) In the Guidelines for Instant-Apply windows, it talks about 
validating text fields. Your comment in the auto-generated version 
that you should be saying what to do instead of what not to is 
definitely true. But also, it would help if you more precisely said 
*why*. Most developers, when they make bad design decisions, do so 
because they think they know better.

 E.g. They want to prevent users from getting weird colors when a hex 
color value is edited in a text field. They don't even realize that 
they should be using a visual color picker window instead of a hex 
text field, or that maybe the hex field should be three fields for R, 
G and B, and maybe have a slight delay or only apply the change (and 
validation) on close field, or whatever.

 I'd be especially interested in hearing why you're against 
validating e.g. an entry field where a number is entered immediately, 
by not allowing any characters but numbers. I don't see how giving a 
beep at typing invalid characters in this case would be annoying.

2) Property Windows - I guess you took a riff from Windows when you 
made this an explicit window style to describe. I don't really see 
how those are much different from other windows.

The only way Windows makes them different is that they have a tabbed 
control, even if they don't have multiple pages. IMHO, having a 
one-paged tab control is a pointless waste of screen space and 
confuses the user because they will probably confused at getting a 
"one-state-switch". They'll wonder if there's anything they can do 
with this thing.

If you agree, it'd be nice if you mentioned that the tab control 
isn't mandatory and that there should *never* be a one-page tab 
control. If you don't, it'd be nice if you explicitly stated why you 
want it in this particular case.

3) Alert buttons: Again, you're not stating why you want certain 
button positions, you're just saying that those should be used. Give 
the developers the rationale behind your decisions so they can see 
it's not arbitrary, and so they can learn to "think for usability". I 
guess in this case it'd be consistency and reliability.

It may also be helpful to suggest that the default button should be 
the one that causes the least destructive action. E.g. In a "Really 
Delete?" dialog, the default button should be "No", while the 
affirmative button is "Delete", simply to help new users with the 
decision and to avoid loss of data.

Also, I think you should link to this section from the 
"Explicit-Apply Windows" section, so the developers get the 
additional info about placement.

4) Document Icons: You may want to mention that the use of different 
colors for distinguishing document types mustn't be the only clue. 
Otherwise the Accessibility folks will slap you over the head with a 
dead tuna in a few years when all those differently-colored icons pop 
up.

5) Document Icons/Application Icons: You may want to provide a way to 
distinguish applications and their documents. Right now you're 
actually stating that a document icon should be used for the app's 
icon, and you're also dumping the "paper" icon that Windows and MacOS 
use to make documents distinct. The concept of an Application is 
something most people have problems with anyway, and anything that 
helps distinguishing them might be good. IMHO Apple has a nice idea 
with its use of tools and certain color schemes to distinguish apps.

Oh, and fix the apostrophes after plurals in that section. An 
apostrophe is not a warning that an "s" is coming ;-)


In General, I think the following changes would increase the 
usefulness of your guide:

1) Get rid of "abstract" sample pictures like the 3.12 picture. It 
has useless titles like "Affirmative" and "Alternate" (these should 
be real-world examples, even though they may still be funny like 
3.13). That doesn't help people at all. To indicate which button is 
the "Affirmative" or "Alternate" button, it'd be better to have 
labeled arrows pointing at the different buttons.

Also, 3.12 should be bigger, so people really see that "Help" is in 
the lower left, and the other three are in the lower right. Show more 
of the window.

2) Provide the rationale behind the suggestions. (as elaborated above)

3) Provide positive examples, not just negative ones. Case in point: 
Chapter 9's "Designing Effective icons". It contains oodles of bad 
examples, but no good one. You may have learned in School that 
showing bad examples actually "burns in" the bad stuff, and that you 
usually don't let people write wrong stuff on the blackboard and 
leave it there for that reason. That works for icons, too.

It would probably help if you provided a good icon next to each bad 
one and crossed out the bad one So your users immediately see which 
one is better. Just resist the marketing temptation to make the good 
icon look cooler. Ideally, the good icon would simply be a modified 
version of the bad one that fixes the mistakes but keeps the same 
general look.

4) Your structure is pretty good, but somehow it still feels a little 
like an "infodump", a list of all info on Human Interface. E.g. there 
are several sections that mention button positions or icon styles. 
You may want to homogenize those, so that there is only *one* place 
people have to look for for a particular piece. Maybe Apple's 
original ("Classic MacOS") Human Interface Guidelines can help here 
(maybe not, they have a good deal less things to cover).

 In particular, the "Language" section could probably benefit from 
being split up over the other sections (controls -> alerts, menus, 
...), and similarly for Desktop Integration; GKonf looks kind of out 
of place as it's much more a programming topic than an HIG topic, the 
Applications Menu stuff would go better with the other menus etc.

 It feels like the HIG is still written from a programmers' viewpoint 
and segmented according to the installer packages and modules. 
Instead, it'd be better if you took a layman's look and went: All 
windows in one section, all menus in another, all icons in a third, 
all controls in a fourth etc. Items that are together on the screen 
should probably be together in the guide as well. Especially the 
desktop stuff, because most of that is visible for all applications, 
and this should IMHO be treated as part of *each* application, not 
separate.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
       "The Witnesses of TeachText are everywhere..."
                   http://www.zathras.de