GNOME Human Interface Guidelines Released 48
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.)
Too little, too late (Score:3, Insightful)
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 (Score:2)
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 (Score:3, Insightful)
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 (Score:2)
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 (Score:2)
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.
Good for Gnome (Score:1)
Sure you can setup your favorite distro of Linux with your favorite window manager and all your favorite hotkeys. But the point is that windows has ingrained standards that carry over to all applications, usually regardless if the programmer intended it. For example in a list view in windows, double-click on a separator between column titles and windows will resize that column to fit the width of the largest string in that column. This works on all versions of windows that I work.
I understand it is not an issue with Linux as much as it is with a lack of focus toward UI in OSS. Props to Gnome for trying to make a difference.
Bad Buttons (Score:2)
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 (Score:2)
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 (Score:1)
/Janne
Re:Bad Buttons (Score:3, Insightful)
What GNOME really needs is a release manager with the cojones to kick out anything that doesn't follow the standards.
Re:Bad Buttons (Score:1)
Yeah, it's especially a pain to read (this is common to Windows too) "Press OK to do blah, or Cancel to do this other thing", neither of which are really OKing or Canceling anything. There must be a ton of people out there who are too lazy to label their buttons appropriately.
Or if that is too difficult to label, then maybe the scenario the user is being asked to understand is too complex in the first place? I think a lot of these situations are made more difficult for the user precisely because they are condensed down to OK/Cancel or Yes/No questions.
Re:Bad Buttons (Score:4, Informative)
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 (Score:2)
"Dismiss" is a better name for the single button, though "Close" is probably a little less idiomatic.
Re:Bad Buttons (Score:3, Insightful)
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 (Score:2)
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 (Score:2)
- 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 (Score:2)
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.
context (Score:1)
when i close something i expect 'yes' to be 'save the file' not 'yes close the application without saving'.
Why would the application alert me to a task I've chosen to perform(closing the application)?
The VB default installer programme has a good example of the yes no error, as i remember yes quits the install and no retries whatever caused the error.
Re:context (Score:2)
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 (Score:1)
The default option should be to recover what you are doing not loose it.
if OK is don't close you can always try and close the application again, and actually read what the box says if you have to
if Ok is close there's no way your ever going to recover potentially lost work.
that's why the VB yes/no's are the wrong way arround, you loose the work you've put into install the application and have to start over.
don't forget the alert is because of a problem in following the action you have requested.
Re:context (Score:2)
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 (Score:2)
'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 (Score:2)
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 (Score:2)
'that's my point about dialog you use it when the user doesn't know whats going on.'
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 (Score:2)
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 (Score:2)
" 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 (Score:2)
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!
Re:Bad Buttons (Score:1)
Still, a good ui wouldn't bother the user with such trivial things as choosing where to save a file, other than "on my computer" or "on my website". It should look for a disk with available space, save the file there and remember what files are available where. Saving is not intuitive: "What do you mean it's not here!?! I typed it in yesterday and saw it on my screen and everything was just fine!
Re:Bad Buttons (Score:2)
Terrible idea. You need to think about the human factors before you make these kinds of suggestions.
Re:Bad Buttons (Score:1)
Re:Bad Buttons (Score:1)
You mean like Windows?
This post not for the sarcasm impaired.
Non-intuitive interfaces (Score:2)
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 (Score:2)
Re:Non-intuitive interfaces (Score:2, Informative)
No Multi Document Interface? (Score:2)
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
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.
Re:No Multi Document Interface? (Score:1)
To prove this
start word,
Create a new document
Write 'this is document 1' at the top
now create another new document.
Write 'this is document 2' at the top
press alt+f6 to switch between documents (ctrl+tab in everything else!)
You can also open up lots of word windows if you want to. (which i prefer!)
Re:No Multi Document Interface? (Score:1)
What bugs me is that all of the Office XP apps do the "Windows in Taskbar" thing differently. Word has multiple top level windows. Excel still has MDI, but with a button for each doc in the taskbar. I think Powerpoint has some other variation. Talk about consistency!!
more on usability (Score:2, Interesting)
For those who are interested in usability, check out stuff from Jakob Nielsen [useit.com] and Bruce Tognazzini [asktog.com]
where do i report bugs? (Score:2)
'Remember that the purpose of any software application
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! [slashdot.org]
Spelling not included
Re:where do i report bugs? (Score:1)
personal gripe: useless ABOUT boxes (Score:1, Insightful)
I have not read the whole thing yet, but I don't see anything about ABOUT boxes in these guidelines. There are some programs which handle the ABOUT box well. I am not complaining about those
Instead, I am complaining about programs which use their ABOUT box to do nothing but show a pretty logo, the name of the program and (sometimes but not always) the name of the creator. That doesn't really give me much information to go on. If I said "Tell me about your hometown" and you mumbled that it was on earth while gesturing indifferently toward a picture postcard tacked to a telephone pole across town
When I choose "ABOUT" from a menu (And what silly convention puts this under "HELP"? Oh well, I think that one is too late to change
- What is the Name / Version of the software I'm running?
- What is the purpose of the software? [I wish the Mozilla ABOUT box mentioned that one could use Mozilla to interact with and create Web pages,read and send email, and chat on IRC
- Who wrote it / sponsored it, and how can I track them down to give them money?
- Was it formerly known under a different name?
- When was it written? (Version number alone may be useful if you already know what you're looking for, but the information that a program was written in September of 2001 might mean more.)
- What are the terms of redistribution?
- Is there a web page somewhere with tutorials etc on the software?
- Even better would be local files accessable from the ABOUT screen with things like tutorials, errata, a reasonable-sized FAQ
Note: Both KDE and GNOME "official" programs tend to do these things relatively well -- this is a bitch aimed at *other* programs, esp. those made by people who might just now be reading with interest the GNOME guidelines
And of course, the odd easter egg is nice too
timothy
easter eggs (Score:1)