Slashdot Mirror
What Makes a Good UI?
OSXCPA asks: "While there are plenty of OS business apps from accounting to ERP, they seem to share a common failing with "commercial" software - the user interface is terrible! Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it? For the techno-elite, drooly-gui may not be a priority, but I am working on a project (OS) where I have to show real savings (in task performance time and reduced data entry error) on a specialized accounting system via better UI. Am looking for some inspiration. Any ideas? Projects? Books?"
by Jef Raskin
u maneinterface/
http://www.jefraskin.com/forjef/jefweb-compiled/h
It's a book that can help you look at interfaces in a different way, with some measures you can make, and some guidelines that an be helpful. Maybe going all the way is not feasible immediately, but it can gie some insight on the subject.
The biggest problem I have with programs, is the way they make you hop all over to input data. If you can just go from input box to input box, flowing continously, then its a good UI design.
Who cares about looks, I care about functionality, well, I guess I do care about looks somewhat, take proxomitron's default colors when it came out, ICK. The user interface is perfect as a program goes.
But back to flow, nothing bothers me more than something taking away attention when you are working, pop up boxes, something that takes focus away from your work. I think this is why so many people like ratpoison, windowmaker, icewm, you can do your work without the distractions.
ok, do I really need Internet explorer to pop up and tell me when my download is finished? When I'm in the middle of typing an email? No. Stay out of the way. Stealing focus, or making a user hop around is biggest problem in UI design IMHO.
Vim.
No, don't laugh.
Its base set of commands is simple enough, and its effective.
For example, take 'd'. 'd' is for delete. 'dw' deletes a word, 'dd' deletes a line, 'd$' deletes until the end of a line.
'y' is copy. 'yw' copies a word, 'yy' copies a line, and 'y$' copies until the end of the line.
'c' is to change. Guess what 'cc', 'c$' and 'cw' does.
Moreso, 2dw deletes two words, as 2yw copies two words, etc.
Once you learn how one set of commands works, and you know another command, you probably know how that command works and how to use that command to extend the commands you currently know.
For example, /string searches for the next occurence of 'string'. Guess what
d/string and y/string does.
Sure, vim might not be the easiest UI to learn, but I seperate 'ease of learning' from 'ease of use'.
Just my $.02
PS: This post composed in vim. (Its my default editor for w3m)
Whatever you end up reading, I suggest you get some real users to sit down in front of it and test it. You need to be sure that the end user understands what you mean by what you say.
For instance, in this posting, your use of OS for Open Source instead of OSS for Open Source Software was mildly confusing because in the specialized world that is IT, OS, by convention, usually refers to Operating System. If you'd sat down and tested with a focus group, you might not have made this error ;)
Seriously, though, you'll get the best UI you can design if you just sit down with the end users and let them show you what makes sense for them...
GMail does not like you to delete mail; it wants you to archive it - that is the reason that deletion is not how it "should" be.
But, as far as UIs go, I believe that all of the flame wars and discussions that happen because of this are for one reason - no UI will appeal to everyone. Some like GNOME because it is simpler and there is less configuration; some like KDE because it is extremely customizable; some like OSX because it is beautiful; some like Windows because it is simple and direct; I like fluxbox because it stays out of the way and does not interfere with what I do. I do not think that any UI will ever become "the best", because no one will ever agree on what is "the best". Use what you like, design things so that the highest fraction of the people who use it like it. But there is no perfect solution.
Also try usability guru Jakob Nielsen's site Useit. Although mostly focused on web design it s a good read for anyone designing interfaces.
Thanks for browsing at -1
Please vistit my blog: www.framtiden.nu
Common places to look:
- Anywhere involving the mouse. Operations like selecting or cutting and pasting are very time consuming, and open to a huge degree of errors.
- Anywhere involving manual communication between programs. "The cron job emails this file to me as an attachment, then I save it and import it into Excel to run this macro."
- Anywhere that the human is acting as calculator. "I click in this field and then I type today's date."
- Anywhere there's a handoff between humans. "I start the server, email Jim to tell him its up, and then wait for him to tell me whether there are bugs he wants fixed."
- Manual touch points that don't need to be there at all. "I generate the newsletters, which takes like 10-20 minutes, and then when that's done I upload them to the test server."
In short, if you are trying to improve efficiency, then your human is your weakest link and your job is to minimize your human's input into the system. Whittle down their input to the bare minimum that cannot be accomplished by the computer itself, and then do the rest for them.Note very importantly that this implies there is one major audience that uses your product for one primary thing. We're not talking about something like a Microsoft Word that is used generically by a universe of different people. You said you have to optimize productivity, which implies that you have some control over hacking away at features that do not impact productivity.
www.HearMySoulSpeak.com
... This is not meant as a slight to developers. Those who are intimately aware of how every detail of the program works cannot shift perspective and see it from the point of view of someone who neither knows nor cares about the inner workings. I've spent 15 years designing systems to be used in a manufacturing environment. Saying that any problems are due to lack of user training is a cop-out, one that will kill follow-on business. Industry has the operators they have and are not going to start hiring special people and paying them more to run my systems. It's just reality.
I'll give what I think are the biggest UI traps:
1) UI's that expose all the capabilities of a system. This is not good UI design, in fact it is lazy UI design. What you need to do is understand how your users are going to do with your system, and present them with as few choices as possible. Example: If you have a screen for looking up Customer records, and further allow it to be customized to show various fields, and further allow it to check or uncheck any field, you can end up with a screen that does not show the Customer ID (because it was accidently turned off). From the developers point of view you are adding functionality. From a user's point of view there is now a way to accidently render the screen useless, or at least annoying.
2. Beware of allowing users to customize (Wow - there goes my Karma...) Customization is fine for stuff you play with, but in a professional environment it is much more important to have consistency. It is important that people can walk away from something for a week or a month, and come back and get to work right away. It is important that telephone support can make assumptions about what the user is seeing. Floating toolbars, menu items that come and go with frequency of use, frames that can be moved from top to bottom, all of these make it difficult both for telephone support and for people who are "backups" i.e. they were trained once and only use the system every so often.
3. Don't be afraid of busy screens (Damn - there goes the rest of my Karma) Professionals get used to the layout and appreciate having all the information right at hand. (This makes number 2 - consistency - especially important). So err on the side of putting as much useful information as will fit. And prune mercilously anything that isn't useful or required. Don't you hate it when you go to a bank or an airline check-in counter and see the attendent typing endlessly, screen flipping, all at the speed of light, but... why exactly do they need all that commotion?
4. Keyboard shortcuts, labeled and encouraged. The mouse is great for a lot of things, but speed is not one of them.
5. Remember your audience. Are they people who sit in front of the screen all day, using your application as their primary function, or are they several times a day users who simply need it to perform a vital function but just want it to work and go away? Even if it is the former, what about their backup's or the third shift people? In any case, present what they need immediately and clearly and leave off the fluff and BS.
6. Most important. Remember that your application is not what the people do. It is a tool that helps (or hinders) them in doing what they do. A tool should not be their primary focus. The task is their primary focus. Whether a carpenter or developer, any time spent fiddling with a tool simply means less time to spend actually doing the task.
No, and neither will you. The sign of a real good user interface is that you don't notice it, you just use it.
The problem is that it takes a lot of very hard work to get that far and most application developers (Open source as well as commercial) don't bother and/or lack the skills to do it.
My opinion? See above.
A good UI is one that does not cause to you sit up and take notice at all. A good UI is one that lets you sit back and get your work done, without making/allowing mistakes, without making you do anything repetitive, allows fast work, and all this without getting in your way.
Now creating this interface is often difficult. It is worse because sometimes the best UI for novices is different from the best one for experts. A novice needs a easy to learn interface, while the expert already knows it and just wants something that gets the work done fast.
Example: An accountant needs more power from from an accounting package than the average Joe. (yet the average Joe needs to send everything to an accountant once in a while!) "Joe" doesn't know how double entry bookkeeping works, and shouldn't have to learn. The accountant needs to know and use it.
ALl of ed's commands are single letters. What could be easy to remember than a single letter?
a appends text. c changes lines. Simple!
And the error reporting is second to none! If your command contains an error, ed helpfully prints "?" to your terminal. No memorizing what 200 different error messages mean, all you need to remember is "?". Isn't ed great?
Don't blame me; I'm never given mod points.
One related point is how to ask users for data. The wizard approach is good for users who don't always know what they want. It provides a simple way to extract information and make decisions on what to ask next based on previous responses. But it sucks for speed. For a specialized app, like this one, your users probably know exactly what information they need to provide. Let them provide it all at once instead of spread out over 10 dialog pages. Since your users probably won't be entering exactly the same type of data all the time, present them with a simple choice, then give them the huge forms. It's not elegant design (lots of duplicated information) but it's fast as hell. And you can always lay out the forms in the same sort of way, so five tabs takes you to the same field no matter what form you're in, etc.
I mean, don't you hate those Web forms where you answer one or two questions per page? And the damn thing seems to go on for hours? Just give me a monster page with all the fields, I'm smart enough to know which ones are relevant and need to be filled in.
But make sure it really can be automated! There's nothing more frustrating than a program which does something you don't want it to with no convenient way to stop it. The key here is to know your audience. A common pitfall for developers is to build the application they want, instead of the application the users want. This plagues the OSS world in particular, for obvious reasons. Excessive configuration is often a crutch for uncertain design principles. If you know what your app needs to do, and you know how people will be using it, then users shouldn't need to configure anything at all. Fine, let them change the sort order of tables or whatever. But if you find your users need to tweak your program extensively before they're happy with it, you've done something wrong.This goes back to the "lots of options" point as well. The more options you give your users, the more confused they tend to get and the harder it is for them to find the stuff they need to.
Also note that allowing for customization adversely affects consistency. Even simple customizations can adversely affect the ability of one person to use another's copy of the application. In a place where there are more people than computers that's a serious problem. It's also a problem if you want to offer technical support, training, etc. In a way, let MacOS be your guide: "I don't care if it's the best way, but it's the way you're going to do it." And if you're designing an app which builds, at least to a certain extent, on other apps, you should probably choose to do things the same way the others do. That will be the way your users are used to doing things, so unless you expect to see some enormous improvement in efficiency or ease-of-use, don't rock the boat.
You said: A UI that doesn't let you access all the capabilities of a system is a broken UI.
If you add the word "necessary" in there somewhere, I would agree with you. I'll give you a real world example: Print orientation in industrial inkjet printers (these are the kind that write the date on the bottom of coke cans - not anything like a Deskjet). Because these printers are non-contact, you can't predict ahead of time which direction the product will go past the printhead, whether it is upside down, and whether it is printing on the inside of something transparent in order to be read from the outside. There are 3 different parameters that give you all the 8 different combinations, and 7 of the 8 could be used in the real world. The traditional way is to give the user control over all three parameters and let them try to figure it out. The better way is to let them print a test message, then select the way the print acutually printed. The code figures out the settings that correct the orientation. More work for the coder, but much easier for the operator. When this second method was implemented it was considered by many to be an amazing leap in the printer technology, when in fact, the printer hadn't changed at all. Sold a lot of printers though.
The important thing is to understand what the end user wants to do, and present it in a way that makes intuitive sense to them. It is oftentimes more difficult to code, but it is really the only right way to do it.