Slashdot Mirror
User-centric GUI Design Explained to All
TuringTest writes "The webzine User Instinct carries an article on Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development: 'This article presents five key points of user interface design [...] that any software developer should be able to use.' In related news, The Economist writes against software complexity in an interview to MIT's John Maeda, PhD in interface design. See also OpenUsability, a project for testing user interfaces in a bazaar-like model. The specifics of UI design in Open Source projects has been previously debated on Slashdot."
I regularly use KDE, OS X and Windows XP (my ecclectic home network) and find that a brief period of stumbing about is all that is necessary to aquaint the user with basic filesystem functions and get using apps.
Consistancy is more important than simplicity imo, although simplicity really helps first time users.
Prosperity is only an instrument to be used, not a deity to be worshipped. Calvin Coolidge
Part of every software project should be to analyze how the users interact with the software. Using that information, the interface can be tweaked to provide more efficiency and reduce errors. Of course, the customer would have to pay for this but it would probably pay for itself. For example, if a clerk takes two seconds less to input a transaction and there are 100 clerks doing 200 transactions per day, then the company saves 20,000 seconds per day. That's about five hours per day or say $50. That times 200 days per year is about $10,000. So, if the company spends 10k, they get their investment back in a year. That's pretty good roi.
There should also be a mechanism whereby the end user (clerks in this case) can provide feedback to the developer. I'm sick of hearing: "We can't do that because the computer won't let us." This way, annoyances like that could be flagged as they happen.
I'd say if your UI design invades your code, it's a sign of a flawed software design.
Well, first thing I thought when I saw this was this previous article that was listed on ./. the link is here. It's really a rather good read, especially if your a big fan of Apple like myself. I found a lot of his suggestions to be good guides toward a better GUI, but a few were also a bit flaming. I do like the idea of simplicity, but I also like to be able to delve as deep as possible, when I can, and understand as much as I can shove into this tiny planet-sized brain of mine. I think that after using a lot of different products, and quite a few OS's, well, I can't settle on the perfect list, but this comes close.
sig!wind down the juuice, let the tubes roar with the glow of alternative powers, not they that be." me, today...
Hah! My feeble pipe means my 233Mhz laughs at the Slashdot effect. I'm going to stop posting now and save some bandwidth for readers.
The 7+/- 2 items rule is incorrectly applied here - trust me, this is from some of my colleagues researching short term memory and HCI.
First of all, memory has to hold a number of things, not just the items in a presented list. For example, what it is that the user is trying to do. Forgetting the immediate subtask is a bad idea (see research on task interruptions). Secondly, presenting a user with a list doesn't mean that they have to "memorise" each item to process it: by way of example, giving someone a list of 10 items should clear their memory of what's in their before they see the list.
Memory just doesn't work like that. Read up about chunking and the plethora of HCI research into menu design (Google for Howes for an example). People can adequately (and without penalty) be presented with more than 7+/-2 items easily. The important bit is what is in the menu - it should be obvious (therefore not imposing too much cognitive load to detract away from current tasks; and also subject to recognition memory rather than inference or recall), and easy to view, preferably with an "intuitive" position (among other factors, such as not being similar to other items - confusion requiring discrimination). The ideal menu item should be subject to pre-attentional processing (you can see it in proficient users who move their pointer to exactly where a menu item will be before it appears) which doesn't impose any penalty upon a users cognitive capacity.
And yes, I code FOSS.
There was a really good (TLC?) episode about designing modern jet fighter aircraft. They spoke of two things: making it fly, and making pilots able to fly it.
... "it should have banked harder to the left" or "why did it stall? I increased power ..." After much tweaking, they had a software system that "understood" what the pilot expected to have happen from their control of the plane and the plane could be made to do those things (within its limits) by the software.
It seemed that with all the control surfaces necessary to make this plane (new F-16?) fly, it would be impossible for the pilot to successfully fly the plane in combat (or at all?).
Instead, they engineered the plane the way they wanted, essentially ignoring the pilot's limitations and then wrote a software interface between the pilot's usual tools (pedals, joystick, etc.) and the plane's mechanics. They ran top gun pilots through flight simulators while listening to their comments
Designing UIs should be similar. Where I work we design database systems that are used, in part, at both POS and for data-entry clerks. The UIs for each are quite different but related. The POS worker shouldn't have to navigate menus, etc. to get a sale completed; the system simply runs through the normal questions one after the next with "ENTER" alone doing the right thing most of the time.
Data entry clerks are asked for several starting pieces of information (type of customer/transaction, etc.) and then presented with a form that allows them to simply keep typing without moving their hands almost at all.
In cases where redundancy sets in (entering 50 of something slightly different), filling in the fields automatically is also possible.
I shouldn't have to navigate a word processor's menus to spell-check my document, or to change the margins, or to move text around, etc. And for the most part, modern word processors are fairly well-designed beasts (being heavily used by many people).
Good UI design takes a lot of thought, and user testing, and ignoring your "instincts" as a programmer sometimes -- your users probably aren't programmers.
- Michael T. Babcock (Yes, I blog)
When a menu bar is attached to the window, its context is always obvious. The targets are always on the screen, even if the window isn't active. If there's a target that is harder to hit than a small target, then it's one that you can't see until you do something else. If you have the screen real estate, wasting it on multiple menu bars is reasonable because you will most likely have more windows from different applications which you use concurrently. The effective target size is not that important to regular computer users with normal mouse aim if it means they don't have to travel to the window to activate it and then move the mouse to the menu. Besides, menus are relatively slow interfaces regardless of the position of the menubar: There are many options, they're nested at least 2 levels deep (menu bar, menu items) and only one level is initially visible. If you use menu items so often that you wish you could just fling the mouse to the top of the screen, there is probably a better user interface for that function.
On the other hand, scrollbars in maximized windows should always be flush right. Even after the invention of the scroll mouse, scroll bars are one of the most used widgets, so they need to be easy to hit. I disagree with the author on the placement of window close buttons. A target should be easy to hit if it is used often and the border targets should be reserved for non-destructive actions, because they will be used blindly. Closing windows is very often destructive, so the close button should not be placed flush top-right.
For your application to be user friendly, it has to actually be friendly to the user.
This means that:
- There is no way to create, let's say, a user-friendly interface for product activation because activation is in itself a distrustful, user-hostile goal.
- If you want to avoid describing to the user what the computer is doing, whether that's because it's something underhand or because you are an insufficiently skilled explainer to be able to describe it in understandable terms, then no matter how many windows and buttons and fancy animations you include it will be obvious that you are treating the user as stupid, which is not friendly.
- If you cannot give the user useful information because it is not technically possible to do so, then do not think that giving them some information using a component from a user interfacing handbook will make your app friendly. As an example, just because it is not possible for a web-browser to provide a true time-based progress bar (which rises at constant rate and completes immediately when full) does not mean that's OK to slap in a progress bar that displays a relatively meaningless value. (What is the average user supposed to do with the knowledge of how many parts of the network download and typesetting task have been completed, especially when the parts are decided arbitrarily by the system designer and never explained?)
GUI's should be extreamly thin clients that wrap other functionality that is also available in another form.
GUI's should be modeled like opening a book. If you close the book everything that you wrote in that book is still there.
Decoupling the GUI from the actual application is the mark of an experienced programmer.
I find that an application should have multiple ways to access it. I like to have things running in the background and have the GUI be spawned later.
This would be for use with industrial control systems real-time automation.
If the GUI crashes the application should keep running. IE: the car doesn't crash if the navigation system reboots.
Also: if a GUI is designed correctly and the app is accessed by it and used by it, then you can run the GUI from pretty much anywhere.
Mainly the problem is that users don't often want to *learn* a new piece of software, but they do want to use it. They want advanced features, but they don't want to figure them out.
That being so, in designing your interfaces (and backend) you have to do a lot of hand-holding. You have to make the basic features obvious, and the complex features easy enough to use for the average user. Often this might mean anticipating how the user expects to use a program, or by filling different controls etc etc based on default behaviors.
This is exactly the reason that so many UIs suck so much. You have to differentiate between design for looks and design for function. Users care about pretty pictures for about one minute. After that, if your application is impossible to use (no matter how many great features it has) they will choose the simpler application that helps them get their task done.
for showing us how badly a browser can be designed... yes... except that Konqueror's primary function is as a filesystem browser, where the UP button makes perfect sense in it's location...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Taking about Expose, I consider it something along the best invention I have seen in the GUIs on todays computers in the last years. Yes, it can be a bit annoying if you only have a slugish touchpad at hand and trigger it by excident and it might be confusing to new users, since its not obvious how it got triggered in the first place, but after all its off by default so no evil things happen.
The good thing of Expose is that it gives you one feature that everybody knows from the real world, but which is extremly seldomly seen in GUIs, I would call the 'step back' feature. With drop-down lists, tasksbars and even with different workspaces is way to easy to lose the overview, Expose gives you the freedoom to virtually step back and see whats on your desktop simply by zooming out and rearanging the windows so that everything gets visible. It makes navigating a whole heapload of windows way easier then anything else. In general the ability to 'step back' when losing the overview is what makes computers so much more inaccessible then a table and some pieces of paper.
Lots of mistakes are made in UI design on a conceptual level. The article touches that slightly by explaining the importance of only showing the information/controls important to the user. But it goes much further.
To show some examples from firefox: there are many settings to control privacy/security. Many users do like these settings, but not for each site. If they trust a site, they don't mind popups, images from other servers etc. But firefox does not place the site central, but the control. That's simply not how a user _thinks_.
I've got a lot of other grieves, but I'll let that pass for now. Normally I only comment on programs that I find of great use to me, also because I try not to use the others at all. The screen real estate that firefox leaves me is for instance fantastic, and it is very uncluttered.