GNOME Human Interface Guidelines Released

Seth Nickell writes: "We are proud to announce the release of the GNOME Human Interface Guidelines v1.0, the product of usability engineers, designers, hackers, and whatever-keeps-you-writing-calum irish wine[TM]. I hope they'll be useful for improving the usefulness of all free software, not just GNOME apps. Check out the release announcement for details and a plaintive plea for interface coordination between free software projects." (Also at the top of the new Gnome news site called Footnotes.)

Comments

Too little, too late

[PhysicsGenius]

The Open Source community lambasts Microsoft for making security an add-on "feature" instead of engineering it into the lowest, most fundamental levels of the product. We know (and apparently they don't) that security is about more than slapping a lock on the outside and calling it safe. You have to think of protocols, transactions, etc and every stage and with all contingencies in mind.

UI design is the same way and apparently no one in the Linux/UNIX world understands this. You can't make a program intuitive to use by programming it willy-nilly and then putting the right-sized buttons or icons of the correct 16-bit colors on the top. Ease-of-use must be factored in on Day One.

That's why it saddens me to seen GNOME come out with their UI design guidelines fully 4 years after they started programming and after at least two major releases.

If UI design bugs (costing thousands of man-hours and millions of dollars via confusion and "human" error) got the same press that MS's security problems did, ZDNet would have the same biased field days that Slashdot enjoys on a monthly basis.

Re:Too little, too late

[rw2]

1) you're comment is interesting but I think overstates the problem. True, the guidelines are late. False that it necessarily follows that the GUIs for Gnome/KDE/Windowmaker are therefore costing us money.

Microsoft, for example, published GUI standards long after their OS was first available and dominent yet their tool was still very useful.

Fast forward to today: They are now, arguably, publishing standards today that are far behind the Mac. Where do the 'modern' Linux GUIs come in, I don't know (and agree it would be intresesting to see a study), but empirically I _usually_ find them easier than trying to do the same work in Windows. (And I use both regularly).

2) You didn't answer in the form of a physics dissertation. Please describe how QCD effects are ultimately manifested into usable GUIs. If you can propose a test to confirm your theory describe equipment needed, timeline and (most importantly in this era of reduced physics funding) a way that it ties into health sciences so we can get it funded. Something related to 'naked DNA' would be an especially fortunate posit.

Re:Too little, too late

[RevAaron]

No one ever claimed that GNOME isn't useful. Not having well designed UI guidelines doesn't make GNOME useless, it just makes it inconsistent at best, and nearly impossible to use at worse. Which it is, unfortunately. Windows is also quite inconsistent, even though they've had design guidelines for a while. But like with GNOME, they were put out as an afterthought.

I'm not much of a fan of Windows, and I don't use it very often, but it's still more consistent than GNOME. (I use Linux at home and work) Maybe in another 6 years GNOME will achieve the same level of consistency that Windows has now, after the same normalizing process that occured with Windows does with GNOME. Windows is still less consistent than some other options, but it's catching up, no doubt because the HIG were put out.

False that it necessarily follows that the GUIs for Gnome/KDE/Windowmaker are therefore costing us money.

They are. They waste time, and as the adage does, time is money. When I'm at work, that 20 minutes a day I have to spend trying to figure out those inconsistent GNOME apps costs me 20 minutes where I could have been doing real work. Maybe your time is worth nothing, but a lot of us have more to do than dick around with poorly designed GNOME apps.

The Mac OS and the Newton OS are two examples where design guidelines were developed with the OS/GUI system and made available to developers from very early on. It's not surprising that they're the most consistent computing platforms around.

Re:Too little, too late

[rw2]

Wait a minute. I said that there was no study that showed linux to be less efficient than windows and that *I* find the linux guis to be more intuitive.

RevAaron says "They are" and that gets an insightful comment.

That's about the lamest piece of moderation I've ever seen.

Worse, he goes on to say "They waste time, and as the adage does, time is money. When I'm at work, that 20 minutes a day I have to spend trying to figure out those inconsistent GNOME apps costs me 20 minutes where I could have been doing real work. Maybe your time is worth nothing, but a lot of us have more to do than dick around with poorly designed GNOME apps."

WTF? I said that I found the linux stuff more useful. How does that in any way imply that my time isn't valuable or that I enjoy dicking around.

I think the moderators have confused insightful with hostile again. Not exactly a first time, but still, it would be nice if they read the note...

Re:Too little, too late

[rw2]

Blah blah, I read it and it started off valid, but then took a turn for the worse.

He wanted to say consistency is key, but instead went into the land of ad hominem rather than substantiating his point.

I say again. *I* find the linux apps I use to make me more productive than the windows ones.

He can claim that consistency is key, but he's presented no evidence of that (which was all I claimed in the first place). For me, I'd rather spend 20 minutes 'dicking around' once and learn a different interface for each of the 5-6 apps I use and be able to use them well than to have a 'consistent' interface that is written for the lowest common denominator windows user.

Bad Buttons

[Euphonious Coward]

The biggest change I'd like to see in most GNOME program UIs is to eliminate the "Yes" and "No" buttons in dialog boxes. These show up everywhere, and you always have to study the fine print to figure out which button means what. If the buttons said something like "Keep" and "Discard", or "Send" and "Keep Editing", it would be immediately clear.

Likewise "OK" buttons: just what am I okaying? A verb would be a much better hint.

I was told that this was already required by the UI guidelines, but if so it is certainly neither prominent nor obeyed. I couldn't find any mention of it there. Among the programs most egregiously guilty are Evolution and Gnumeric -- just hit the go-away box in a newly-edited message or worksheet.

We should have a class of UI violation that automatically merits high severity in bug reports. Uninformative button labels should be in that list.

Re:Bad Buttons

[scrytch]

Buh. The UI guidelines require every popup to have a different set of buttons for every question it wants to ask you? What do you bind the standard shortcut for "keep file" to? Do you even bother with a shortcut, or just assume everyone has a mouse and enjoys aiming the pointer at controls?

How about asking sensible yes/no questions in the popup? How about getting rid of the popups entirely if at all possible? Ones that demand a yes/no may be difficult, but ones that merely pop up warnings and notifications could be accomplished by prominently displaying a status indication while work proceeds.

Re:Bad Buttons

[foobar104]

Actually, the reference standard for user interface guidelines-- the Apple User Interface Guidelines from Inside Macintosh-- recommend the opposite. Note and stop alert boxes should have only one button: OK. Caution alert boxes should have two buttons: OK (the default, usually) and Cancel. They go on to say this:

Dialog boxes and alert boxes communicate to the user. It is your responsibility to make sure that the user can understand what is going on when you can't be there to explain. Dialog box and alert box messages should be descriptive rather than evaluative. When you're writing messages, try to put yourself in the place of your users and imagine how they will feel when confronted with your message.

A good alert box message says what went wrong, why it went wrong, and what the user can do about it. Try to express everything in the user's vocabulary. Figure 11-3 shows an example of an alert box message that provides little information and doesn't suggest to the user what is really going on.

(Figure 11-3: A poorly written alert box message)

! Error writing file to disk. [OK]

You could improve this message by describing the problem in the user's vocabulary, as shown in Figure 11-4.

(Figure 11-4: An improved alert box message)

! "Monica Stories" could not be saved because the disk "Blackmail stuff" is full. [OK]

To really make this alert box useful to the user, you need to provide some suggestion about what the user can do to get out of the current situation. Figure 11-5 shows the optimal alert box message for this condition.

(Figure 11-5: A well-written alert box message)

! "Monica Stories" could not be saved, because the disk "Blackmail stuff" is full. Try saving onto a different disk. [OK]

In my opinion, the important work on human interfaces has already been done. We just need to go back and read it. I keep a copy of this book on my shelf all the time, and I read it often. It's almost like a Bible for me. I'll even read it sometimes just for inspiration or encouragement when times are tough.

Okay, I'm sick.

Re:Bad Buttons

[scrytch]

I agree with informative names, but only have one problem: the button is misnamed. Much of the time, it's not OK, but there's no button to help you with actually resolving the problem. If you point out a problem, it's incumbent on you to point out the way to fix it -- even if it's just Microsoft's ubiquitous "contact your system administrator" message (at least we know it's a dead-end)

"Dismiss" is a better name for the single button, though "Close" is probably a little less idiomatic.

Re:Bad Buttons

[foobar104]

"Dismiss" is a better name for the single button, though "Close" is probably a little less idiomatic.

No, it isn't. Remember the part about using the user's vocabulary. What if I walked into your office and said, "The vending machine is out of Spritz." You'd acknowledge my announcement by saying, "Okay." You might not care that the vending machine is out of Spritz. On the other hand, you might be terribly disappointed and upset. But in either case, the correct response is simply, "Okay," as in, "I acknowledge this message."

Don't read too much into it. The "OK" button isn't meant to imply approval on the part of the user. It means the same thing "Okay" means in speech. It means, more or less, "I hear you."

Always putting the "human" back in "human interface."

Re:Bad Buttons

[Arandir]

Somehow I have a hard time believing that a bunch of developers who say "we won't follow any sensible UI design until we get mandatory guidelines" are the sort of people that would follow the guidelines to begin with.

What GNOME really needs is a release manager with the cojones to kick out anything that doesn't follow the standards.

Re:Bad Buttons

[foobar104]

Terrible idea. The only point of saving is to retrieve. You can't retrieve a file unless you know where it was, or what name it was given, or something. If the computer automatically stashes my files away in obscure places on my computer, because it found room to do it there, how am I supposed to go back and find them months or years later? I have files on my computer that date back to my college days. I don't need them often, but when I do, I know just where they are, because I put the there. If I let the computer manage them for me, I'd never be able to find them again.

Terrible idea. You need to think about the human factors before you make these kinds of suggestions.

Re:Bad Buttons

[renoX]

I disagree: the way you talk depends on the medium: if there is a misunderstanding with another human due to ambiguous wording, you can talk with him and solve the confusion.

A button OK might means two things depending on the context:
- an acknowledge (as is the case here)
- Do an action

To prevent confusion, I prefer very much having two separate button for two different action:
- Close button to acknowledge.
- OK to do an action.

If you want to use OK, you must end the message with "Close window [OK]" which is more verbose than the simple "[Close]" button.

Re:Bad Buttons

[foobar104]

A button OK might means two things depending on the context:
- an acknowledge (as is the case here)
- Do an action

Can you give an example of an OK button that means "do an action?" There are only two acceptable meanings for an "OK" button in an alert box: "Okay" or "Proceed." If there's only an OK button, then OK means "Okay," as in "I have received the message in this box and would like it to go away now." If there's an "OK" button and a "Cancel" button, "OK" means "proceed with what you were doing," and "Cancel" means "abort."

Re:Bad Buttons

[renoX]

We're talking about the same thing: "Proceed" or "Do an action".

You're right that in this case, there is an additional Cancel button, it helps desambiguate the two usage, but I think its better to use a different word.

Well, the case is not clear-cut, so the best thing to do is to respect the UI guidelines and do what it says.

Non-intuitive interfaces

[Lendrick]

I like the little dig they take at the Mac UI:

On the other hand, a waste basket should not be used for anything other than holding discarded files. It should not be used, for example, to eject a removable disk such as a floppy or CD.

I never liked that... I was always worried that, when I put a floppy in the trash, it would reformat it or something. I'd be curious to find out who came up with that, and what exactly they were thinking. Tossing something in the garbage does imply that you're not ging to use it anymore, ever.

Re:Non-intuitive interfaces

[judd]

According to Bruce Tognazzini, it's because the trash can is in the lower right by default, and the drive icons are directly above it. It is therefore a very easy action to perform. Considerations of ease of performance won out over semantics, and the engineers beat the designers. (I still think was a bad idea too, FWIW - I never met anyone who used a Mac who was confused by this the first time).

Re:Non-intuitive interfaces

[ichimunki]

FWIW, OS X seems to have caught on to this complaint, now the trash can turns into the little eject symbol when you click on a CD (or maybe only when you start to drag a CD-- I wasn't paying that much attention to when it changed, only noticed that it had).

No Multi Document Interface?

[Lendrick]

The document mentions a little ways down that multiple document interfaces have "inherent useability problems" and shouldn't be used.

To the contrary, one of the most annoying "features" of, say, Word 2000 is that it's got a single document interface that opens up multiple windows, cluttering your taskbar. Now, I understand why they did this--they probably got a lot of tech support calls from inexperienced users who believed they had lost their documents ... but it would have been nice of them to include something in the preferences menu to allow you to turn MDI back on.

By the same token, it would be nice if some of these single document applications were only single document by default, and could be changed into multi-document mode in the preferences menu. For experienced users, a tabbed interface is often a lot more convenient.

more on usability

[nocent]

This sounds like the Macintosh Human Interface Guidelines

For those who are interested in usability, check out stuff from Jakob Nielsen and Bruce Tognazzini

where do i report bugs?

[oliverthered]

Chapter 1: Secion 1
'Remember that the purpose of any software application ... So, the first things to establish when designing your application are:

who your users are
what you want to enable them to do
'

'what you want to enable them to do'
should read,
'and what they want to do'

Personaly I think the 1st chapter is quite bad. Not in it's aims but in they way it presents them.

The document hasn't been writen for it's target audiance, namely Hackers/Programmers.
The definitions are too frilly and abstract and seem like something a designer might come up with not a groups with broad HCI implemtation knowlage.

e.g.

'Create a Match Between Your Application and the Real World'

This is the wrong thing to say, think of all the applications that take the statement literally, how useable are they?

any how here's a breif of my design principals!

Spelling not included

Re:context

[foobar104]

Ah, negative questions. "Don't close the document? [Yes] [No]"

That's why it's incredibly important to make sure alert boxes are simple, descriptive, communicative, and (most importantly) not interactive. The user should never expect that a choice made in an alert box will cause the program to do something different that what it's already trying to do. In other words, the alert box should read, "The document 'So n so' as unsaved changes. Closing it without saving will discard those changes," and the options should be "OK" and "Cancel." In other words, the only choices are to proceed with what you're trying to do despite the warning, or to abort the operation.

Re:context

[foobar104]

But that's just the thing. Don't try to read your user's mind. "OK" means "proceed with what I told you to do." "Cancel" means "stop what you're doing." If you tell the program to close the document, then "OK" means close the document, and "Cancel" means don't close the document.

This convention really makes perfect sense. If "OK" always means "go ahead" and "Cancel" always means "stop," you don't have to worry about being confused by the meaning of the buttons any more. After reading the alert message-- assuming it's well written-- you'll know whether you want to keep going with whatever you told the program to do, or whether you want to back up and do something different. If there's no consistency among button labels and meanings, then the user has to stop and figure out how to tell the program what he or she wants to do. That's not good for usability, and it will inevitably lead to more mistakes than a consistent approach will.

There's one overriding principle in human interface design: the human tells the computer what to do, not the other way around. If the user says, "Close this document," the program should warn him or her that the document has unsaved changes (and what that means, of course), but it's up to the user to tell the program if he or she wants to abort the operation.

Ironically, the Mac, which many people accuse of having a "dumbed down" interface, is actually built on the principle that the user knows what he or she is doing all along.

Re:context

[oliverthered]

hmm...
'the user knows what he or she is doing all along.'
and that's my point about dialog you use it when the user doesn't know whats going on.

A lot of project management is run this way (in my experaince any hows) and it usually leads to a bad overrun project that doesn't do what the user wanted. Overrun badly managed projects have a greater visibility than poor UI and there's a lot of common elements.

Well that's just my thoughts and experiance.

Re:context

[foobar104]

and that's my point about dialog you use it when the user doesn't know whats going on.

Uhh.... one uses an alert box to tell the user what's going on. An alert box appears when something exceptional has happened, or when an action may have unintended consequences. The purpose of the alert box is to inform the user. Alert boxes have "OK" buttons because the user needs some way to acknowledging that he or she has read the message. "OK" means just that, "Okay."

In some circumstances, it's appropriate to give the user a chance to say "Never mind." Those are the situations in which the alert box should include a "Cancel" button. The "Cancel" button means "Never mind."

Dialogue boxes in general, and alert boxes in particular, are incredibly simple. There's no need to make them more complex than they are.

Re:context

[oliverthered]

I'll repeat my self again!!
'that's my point about dialog you use it when the user doesn't know whats going on.' .... to tell them what has happened.

the idea that "'OK' is to acknowledging that they have read the message. " is odd, you're nsaying that 'OK' leaves things in an unknown state, and that people read things, they don't; There are enough jokes and TV programes based on people not reading the instructions to show that point. Hell i didn't even read the [ok] [cancel] bit of your first post i read [ok] [not ok].

The default option should always be to give the user an opotunity to recover from the unexpected, the first 'ahhhh..... something weird has happened' dialog should lead the user into the recovery process and should not require the user to fully understand or even read the dialog.

'There has been an error somthing will happen'
options
[ok] [cancel]

so ok makes something happen, what does cancel do? does it roll-back whatever was requested before hand 'context'?

'Continue closing the application even though you have unsaved changes'
[ok] [cancel]

This is poor, the user should be given the recovery option i.e. to save there changes. [ok] [cancel] gives the user no clear path to perform an operation on there unsaved changes.

Re:context

[foobar104]

The default option should always be to give the user an opotunity to recover from the unexpected, the first 'ahhhh..... something weird has happened' dialog should lead the user into the recovery process and should not require the user to fully understand or even read the dialog.

Bullshit. The default option is to do what the user asked you to do. Say I tell my word processor to quit. An alert box pops up. Can't be bothered! Don't have time! I don't read it. I just slam my hand down on the "enter" key to invoke the default button, whatever it may be. Wait a minute. My program hasn't quit. I'm right back where I started, and I don't know why! Shit!

Alert boxes exist to tell a user that something exceptional has happened, or to warn them of possible consequences. (That sounds familiar. I think I'm repeating myself here, because you're not getting what I'm saying.) Alert boxes are not interactive. They don't pose questions. They merely convey information. "Hey, I know you asked me to quit, and I'm gonna do that in a second, here, but first I though you'd like to know that you're about to lose your work." The user knows that "OK" means "proceed in spite of the warning" and "Cancel" means "abort the thing I told you to do." How does the user know this? Because every alert box works that way, every time. That's the point of a human interface guideline.

'There has been an error somthing will happen'
options
[ok] [cancel]

so ok makes something happen, what does cancel do? does it roll-back whatever was requested before hand 'context'?

That's why error alerts don't have a Cancel button. Error alerts only have an OK button. In that context, "OK" means "I hear you."

'Continue closing the application even though you have unsaved changes'
[ok] [cancel]

This is poor, the user should be given the recovery option i.e. to save there changes. [ok] [cancel] gives the user no clear path to perform an operation on there unsaved changes.

You've written a shitty alert message, and you're trying to fix it with buttons. Get this, and get it good: the message is more important than the buttons. Don't try to convey information in the buttons.

It should have been something like:

"You have made changes to 'Monica Stories.' If you quit without saving the document, you will lose those changes." [OK] [Cancel]

See? An informational alert box telling the user of a consequence that he or she may not intend, and giving the user the opportunity to proceed or to abort.

I mean no disrespect, but given what I've read from you yesterday and this morning, please tell me you don't design user interfaces for a living.

Re:context

[oliverthered]

What's worse


" The default option is to do what the user asked you to do. Say I tell my word processor to quit. An alert box pops up. Can't be bothered! Don't have time! I don't read it. I just slam my hand down on the "enter" key to invoke the default button, whatever it may be. ....."

Wait a minute. My program hasn't quit. I'm right back where I started, and I don't know why! Shit!
I'll have to click close again and read the blody message this time!!

or

I walk out of the office, got half a mile down the road and thought 'shit did I save my 1/2 days work before I left in a hurry'

Please don't tell me you design anything for a living, or maybe you write EULA's? ;->

Re:context

[spitzak]

Before this argument goes to far, this poster is exactly right in the common thinking before about 1998. Like usual MicroSoft messed things up and now everybody accusses everybody else of being inconsistent because some of them follow the old convention and some follow MicroSoft, rather than putting the blame on MicroSoft where it belongs.

There are exactly two types of these exit boxes. Before Windows 98 everybody used the "Exit without saving text?" question. Try an old Macintosh if you do not believe me. "Yes" meant exit and discard the text, "no" returned you back to the program exactly as though you had not tried to exit. Though there are variations in the question and in the two buttons, I never saw any other type of exit box before 98.

The other type is the "Changes not saved" with "save", "dont save", and "cancel" buttons. Again the question is worded differently and the buttons are different, but the idea is that you can hit a button that is like going back to the program, saving this document, then exiting again. The other two buttons are the same as the yes and no in the previous versions. The problem here is that a lot of time the yes/no is swapped randomly, as the question is worded "Save this text before exiting?". I have lost untold amounts of data because I instantly hit "no" when I think I made a mistake, this three-button exit panel is a serious user interface goof. More recently they have realized this and changed the buttons to "save" and "don't save" though escape is often the don't save button so you can still screw yourself.

The exact same thing is true of Alt verses Ctrl for menu shortcuts. Until Windows 95 EVERYBODY (including MicroSoft) used Alt as the meta key for menu items. Take a look at some old software someday before you start accussing Linux GUI of being inconsistent!