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


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.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]