Slashdot Mirror
What Is Important In A User Interface?
fosh asks: "Out of some discussions going on in response to the Gnome-Microsoft connection I have come to ask myself, (and the Slashdot community) the following question: What is really necessary in a User interface? What is the set of elements that is required, what are the elements that make the user's experience better? What are the inherent problems with MacOS, Windows, Gnome, KDE? Why are computers still hard to use for people like my mother, and how can we make this better?" Of course, the words "user interfaces" usually means "visual user interface." Voice recognition has come a long way in 10 years, and in another 10, we'll probably be able to talk to our machines in plain...well...anything! When this happens, will these ideas still hold merit?
I'm sure everyone will agree that speed is crucial, but simplicity takes a little more convincing. One of the distinctions that many people fail to make is the difference between the complexity of a task and the simplicity of the interface to that task. Where Apple has made a lot of progress is in maintaining the simple interface to a complex task. Consider the rocker arrows on many of the progress dialogs: in its default configuration, the dialog informs you of the percentage of the task completed (by the visual cue of the progress bar). Click on the rocker arrow, and you get a veritable cornucopia of information -- what file/folder is being processed, how many have been processed/how many remain, time elapsed/remaining, etc.
Just because an interface is simple, doesn't mean that it can't be complex. Just because an interface is complicated doesn't mean that it's powerful.
A UI should present a simple view by default to the user that makes most, if not all, of the functionality of the software available. 10% of the learning should be able to accomplish 90% of the tasks you'd need to perform. Ideally, the user should be able to happily use the product without ever being forced to dig deep into customization, preferences, skins, or any of the like - the UI should, however, offer any additional chrome as an option. The original Mac (with a few exceptions like dragging disks to the Trash) came pretty close to this ideal - but has become more complicated and convoluted with time.
.configure script that handles everything necessary. Reasonable defaults should be set, and the advanced user should have a simple way to access those defaults to change them.
Installers should be smart - either dragging the application to the hard drive should be sufficient to install it properly (like much of the simpler Mac software), or a simple installer (the new Windows Installer isn't bad), or a
There's nothing inherently wrong with a CLI - so long as users can function without it. In that sense, it'll be interesting to see how MacOS X turns out. Applications should be consistent to the OS's bulit-in UI functionality - using the system's UI elements should be the default behavior for any application. Chrome and skin use should be optional, if used at all.
Finally, the keyboard/pointing device combination should be enough for most anything. Not that there's a lot of alternatives out there, but I don't see voice recognition (in cubicle farms?) or touchscreens (the old "gorilla arm" syndrome) being too useful for anything but a specialized environment. Day-to-day applications should not be designed with those type of inputs in mind. More audio feedback would be nice to see in the future, so long as it's not required to use the systems properly.
For the most part, I remain a relative fan of the MacOS for UI consistency and design. Though it's a lot more complicated than it used to be, and there really isn't easy access to the underlying OS (AppleScript is great and powerful, but a CLI would have been nice years ago), I agree with the pundit (I can't remember who it was) many years ago who said, basically, "The Mac is the first and only personal computer that's good enough to dislike". And though I own and use systems running Windows 98, Windows 2000, and Linux, when I go home and just want to turn on one of my computers and just get something done quickly and easily, without having to think about how to do it - 9 times out of 10 that means turning on my Mac. So I really guess a good UI should steal as much of that as possible.
- -Josh Turiel
-- Josh Turiel
"2. Do not eat iPod Shuffle."
A GUI under Linux or any other Unix system will have a tougher time of meeting all these requirements than a GUI built on a newly-designed OS. The reason is that Unix already has certain ways of doing things and the requirement for consistency demands that those ways be complied with in a GUI. An example is the documentation access method: Unix uses manpages, and so a GUI should also use manpages. There's nothing that says that you can't build on that, but it's very wrong, IMO, to build an entirely new documentation structure because it violates the rule of consistency and predictability (those two tend to go hand-in-hand).
Thus far, pretty much every Unix-based GUI (and Windows, too) violates Fitts' Law, which basically says that larger targets are easier to hit and thus more desirable, so edges of the screen are prime real-estate since they are infinite in at least one dimension. Gnome has the additional problem that its default scrollbars are far too narrow and thus are difficult to hit, which makes them difficult and annoying to use. Why the width of the scrollbars isn't included in the
Both Gnome and KDE are making slow but steady progress towards being easy and pleasing to use. But I think it's very important that they avoid the mistakes made in Windows, even at the cost of compatibility with the Windows GUI: it's more important to get the UI right than it is to get it to be compatible. People can learn, especially if what they're learning conforms with the principles listed above.
--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
I'm sorry, but you seem to have no respect for anyone whose life doesn't revolve around computers.
There is nothing "logical" about most *nix GUI's. What confuses people is not relentless logic, but incredible arcaneness, the assumption that the user has a great deal of computer knowledge, and no clue whatsoever about where to start in getting a job done.
If a user wants to make a text file (and most users aren't even clear what a "text file" is) there is nothing "logical" about typing "vi newfile.txt." And there is *certainly* nothing logical about the controls in vi.
A computer is a tool. For geeks, it's an extremely important tool, and one that we therefore become intimately familiar with. For us, the primary job of a GUI is to get the hell out of the way so we can get our work done. We memorize key shortcuts, write scripts to automate common tasks, and do most of our work from the command line. Therefore, any attempt by GUI writers to add features is likely to just get in the way, since we already have things just as we like them.
Most users have neither the time or the interest to become this familiar with their computers. This does not make them stupid, lazy, or irrational. It simply means that learning the inner workings of a computer is not a priority. For these users (and 90% fall in this category) the interface needs to be simple, consistent, and provide the user with a limited set of high-level choices that are clearly marked and make it clear what options the user has. A good interface for these users also hides and automates as much as possible the nitty-gritty details of computer operations.
In other words, a mechanic might be perfectly happy reaching into the engine and manipulating it directly, but the rest of us like our steering wheels, dash boards, turn signals, etc. The fact that I can't distinguish a spark plug from an air filter does not make me stupid or irrational. I shouldn't have to know how to rebuild the engine before I drive to the store in my car.
So for geeks the interface doesn't matter that much. We work with our machines long enough that we'll figure out practically any interface. So for us, the priorities are power, flexibility, and minimal intrusiveness.
There *are* however, several facets of good UI design that should be observed in all good GUI's reading these comments I see that most open source types seem to be oblivious to the importance of good UI design. Some of the most important, just from my personal observations:
The possible actions should be available at all times. This is the biggest factor in reducing the learning curve for a new interface, and it's the primary purpose of menus.
Unix GUI's are just awful on this score. If a new user sits down at an average Unix terminal, he's not going to have a clue where to begin. I know I didn't. You *have* to have someone sitting at your side to explain shell commands to you, and even then there are dozens of little tricks that I have learned only by watching other users. Compare this with the Mac OS, in which--although there are still lots of tricks-- all the important functions are either done by direct manipulations or are listed in menus.
Once a user becomes familiar with the interface, this is less important, but even then there are going to be features that the user hasn't used yet.
The second requirement is consistency. The Mac OS imposes a fairly strict set of conventions for widget behavior, menu placement and layout, etc. There are standard shortcuts in almost every app for cut, copy, paste, quite, etc. Unix apps have nothing that vaguely resembles this level of consistency.
If you think that the computer is simply a device to be "really fast at mathematics and transferring data around," I don't think you understand what the information revolution is all about. The whole point of the last 20 years of UI development is that the user can get work done with the computer without understanding its inner workings. A good UI hides unnecessary details and provides simple, high-level abstractions to accomplish the user's objectives. Often these interfaces are poorly done, which is probably why many power users have turned to the raw simplicity of the command line. But the fact that most GUI's today get in the way does not mean that all GUI's are useless.
- simplicity vs. features
- reliance on keyboard vs. mouse
- command language, scripting, or "pure" UI
- dense UI with lots of features visible vs. sequential screens with big fonts and limited information
- UIs that are easy to learn vs. UIs that cater to the experienced user
- UIs with lots of visual features (e.g., 3D buttons and textures) vs. very simple UIs
- easy customizability vs. predictability of the UI across installations (for easier training)
- easy prototyping (for developers)
There are probably many more. I find it regrettable how most of the current UIs just keep copying each other. They all seem roughly like clones of the original MacOS and Windows and somewhat related to Smalltalk.What are some alternatives? Here is a list:
Window management itself is also an area of variability.
Altogether, I feel that there isn't enough experimentation with new UI styles, but I can see reasons for it. I hope this posting will encourage people to look around a bit more and think about alternatives (Google will quickly find pointers to the systems I mention). Most likely, in the near future, new UI styles will simply live within the current system, just like web browser and Mathematica notebooks exist within pretty sparse UI frames.
As far as UIs go, I think one size doesn't fit all. There are too many different applications and different cognitive styles. Let's hope that with Microsoft receding in significance, we'll see a new wave of experimentation and different systems.
However, I don't think it's a good idea to force a stagnation of GUIs yet. If automobile controls had been standardized too soon, we'd still be starting them with cranks and steering them with tillers.
The Mac's GUI should not be taken as a gold standard. I've had to use it at work for the past few months (I'm typing this on a Power Mac) and I find it rather clumsy.
Not that the Windows GUI is any better, mind you, but I'll take my Linux box any day.
Frustrations with the Mac GUI (some apply also to Windows):
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Actually, he is right that even novices should be able to construct complex activities that the computer can perform again and again. If the UI has such a feature, you can have elegance and modularity in your tools. Without it, you get feature bloat.
The problem is that novice-usable UI scripting that is also useful to power users may not really exist yet. If it did, I'd think that the world would be beating a path to its door.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
Whadda mean M$ isn't aware of this? You've got lots of interfaces to choose from! There's
See? Lots of options!
I think most people would agree that with changing technology, dynamic corporations and rollercoster-esque stock markets, software politics, and a huge number of other factors, there should be some universal way of accessing hardware, which is powerful, yet not overcomplicated, fun and yet useful, fast yet flexible. It's estimated that in 20 or 30 years, comptuer literacy will be almost as important as conventional literacy, in many areas, more important. The key to true computer literacy is programming, and finally there's a language that combines all of these factors: ease of use, portability, openness, and flexibility - Python. That language will soon replace conventional UIs.
no sig
What does a UI use windows for?
- Context switching between applications
- As a metaphor for a directory
- For pop-up dialogs
For none of these tasks is a window a good mechanism.For context switching, the stacking and overlapping of windows confuses people, makes partially obscured windows fairly unusable, and results in poor usage of the limited screen real-estate. This isn't to say we don't want multi-tasking - just that the pseudo-3D window is a pretty clunky way of managing the interaction. Modern window systems should be able to perform more active management of the division of screen space between apps, scale the results, etc, etc, so that all apps are usable to some extent if they're given any screen space at all. This becomes especially important if voice-command interfaces ever become popular.
As a directory metaphor, a window filled with icons is a terrible user interface - really bad use of screen space, and provides no context as to what a file is for (other than filename and file type) or where it actually came from. A better interface could be based around HTML, with automatically generated web-like pages serving the purpose of a directory, and having the advantage that they can be annotated by the user so she doesn't lose track of what the file is for.
For dialogs, windows are pretty poor too - they're only appropriate for cases where some catastrophic event occured and the user's work flow absolutely must be interrupted. Even then, you want to tie the dialog to the window that generated the error, rather than have it pop up in the middle of the screen and where it needs to be managed separated from the application.
Unfortunately, window-based applications are really easy to program, so the interests of the user play second fiddle for many applications.
-Fzz
A user interface should let you: Run programs Alter system settings Allow your programs to communicate with each other (drag and drop, calling up a browser when you click on a URL)
A few more things an OS should let you do:
Store documents
Locate documents
Find the program you want to run
Open documents
Connect to external devices
Locating external devices
Allocate memory to a task
Stop programs running
Manage screen real estate
Arbitrate CPU time between running programs
Plus many others. And OS is a complex beast that has to do a lot of things.
A user interface should be:
Intuitive - no learning curve
Unfortunately there is no such thing as a UI without a learning curve. All UIs are learnt. Sit down with a truly novice user some time.
The question is how easy is a particular UI, and the answer is complex and depends heavily on the skills, knowledge and previous experience of the user trying to learn it, as well as on the nature of the UI and its documentation.
Be physically easy to use (single key-strokes and mouse use - you shouldn't have to let go of the mouse to use the keyboard for the basic UI)
With the caveat that what one user finds easy, another might not. Not to mention that not everything can be accessed by simple operations, so you have to choose some things to be a single click, and other require several clicks to make happen. The question is which operations do you make easy and which hard? That's what UI design is all about...
Sailing over the event horizon
- If the user is too stupid to use a computer it will show in big white letters on a black screen. "You are too stupid to use this computer. Please get a clue then try again."
- If the user has the intelligence of a child (whatever the actual user's age), then make it with only a few large buttons and heavy restrictions.
- If the user is average and has at least a lick of common sense, then at least make the errors give the people a clue what is going on. Instead of "memory dump..." put "I hope you saved whatever you were just working on or you're screwed. Don't bother to call Tech Support, they're just going to tell you to reboot it anyway."
- If the user is advanced then go ahead and keep the UI the way it is.
But Above all, make it stable! Even if they have 50 million applications open and a huge Access Database plus Oulook, make it so it doesn't crash and my life will be a whole lot simpler!~Raveness "I never let schooling interfere with my education." -Mark Twain
What programmers and designers need to realize is that they need to provide alternatives. Or at least, they need to make it possible for the user to choose/install a third-party UI if they so choose.
....
That's a laudable goal, but a very hard thing to implement. Consider this: we pretty much agree that the interface across the applications has to be consistent (for obvious reasons). This means that all applications must be decoupled from their interfaces, and that's nontrivial if possible at all. An application will no longer be able to do
switch(some_event) {
...
case button_1_release:
...
}
because it doesn't know whether the user interface used actually has buttons (maybe it's voice input). I actually don't think it is possible to decouple an application from it's UI to this extent.
On a simpler note, consider writing an application the full functionality of which is accessible through (1) command line; (2) GUI; (3) voice input. It's much harder than make a just-GUI or just-command-line applications.
The second problem is: how do you plug in a new user interface for an application? An application has a set of inputs that it reacts to -- the user interface has to know each one of these inputs and map each of it to some mouse/keyboard/voice even. Retrofitting a new user interface onto an application is going to be pretty hard (and demand the application's source most likely) and writing a user interface that you can plug into existing applications is going to be basically impossible (no, I'm not talking about simple things like theming and keyboard remapping).
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
What kind of handle should a tool have?
Form follows function. The user interface is defined by the application and the people who use it. That's why it's called an "interface".
It's also why I cringe when I see GNOME/KDE/UI of the Month (well-intentioned as they are) essentially trying to port the UI from Win95/MacOS (OS's that, IMO, are utterly powerless) to run on top of Linux. It's like covering a bandsaw in wrapping paper: it looks pretty, but now you can't use the tool.
To forestall the inevitable "what about my grandmother" arguments:
1) I'm not saying "keep it ugly and complex to keep the lusers out". I'm saying "think about the power of the tool, THEN decide on a UI." For instance, "gless" (a GNOME pager) is completely useless. How do I pipe to a graphical tool? And even if I could, does it provide me with anything I didn't already have? Does it take anything away?
2) A lot of people who take more than 5 minutes to think about UI's will respond with "but my grandmother doesn't need to run pipes and greps and stuff". OK, but that's not an argument for a simple (minded?) Linux UI--it's an argument for your grandmother to use a different OS.
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
1. Multiple overlapping windows are very hard to sort out for someone who's not used to it. Notice that on video games, ATM's and the like that everything is completely modal; you're not distracted by everything else that's going on.
It would be better if computer GUI's took care of some of the complexity associated with arranging windows, dialog boxes, etc.
2. People aren't used to having to organize their files in a thougtful manner. Many users give their files names like 'Bob.xls' or 'Mary.doc'. What directory are they saving to? Many (maybe even most) people have absolutely no idea.
If the computer organized the user's data into a searchable database, rather than a hierarchial filesystem, information would be much easier to retrieve and reuse.
3. Collaboration is excessively difficult. This could be remedied through better versioning, easier interfaces to web publishing, and the like.
There are a lot of other problems, too, such as creeping featurism, emphasis on style over substance, etc., which I'm sure will be mentioned in other posts.
Your design to a real part online: Big Blue Saw
Every decent interface I've used has scripting. Shells, Emacs, vi, GIMP, Blender - they're all scripable. An interface without scripting is like .... Windows.
-Dave Turner.
Become a FSF associate member before the low #s are used
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I just found this the other day on some linux quotes list. Sorry I can't find the link
"The only "intuitive" interface is the nipple. After that, it's all learned."
LiNT-- Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc, on X interfaces.
M$ used to make fun of this when IBM was bragging that you could format a disk in OS/2 and still do other things, but I think they had a point. I hate it when an OS makes me sit while it is doing something stupid or nothing at all! (Like dialog boxes on Macs). Sometimes on Macs I get a dialog that doesn't allow me to switch windows, but I need to see another window to know that answer it wants.... Arghh. There is no excuse in this day and age to not have an interface that allows you to click between windows and objects seemlessly.
-- Moondog
I can't speak for anyone else but I value consistency in the interface above almost everything else, this can of course only be achieved with well-written style guides etc. One of my biggest gripes with windows recently has been the seemingly diverging application interfaces, many apps even go so far as to design pretty graphical controls which may look pretty but are eroding the intuitiveness that remains one of windows few good points. Projects like GNOME and KDE should pay careful attention to interface design trends and encourage consistency in the different applications.
A user interface should let you:
Run programs
Alter system settings
Allow your programs to communicate with each other (drag and drop, calling up a browser when you click on a URL)
A user interface should be:
Intuitive - no learning curve
Be physically easy to use (single key-strokes and mouse use - you shouldn't have to let go of the mouse to use the keyboard for the basic UI)
In obtrusive - in other words, it's not the end goal, it is a means to a goal.
BlackNova Traders
Consistency is a primary feature for most users; "easy" is often irrelevant, because beginners end up using a cheat sheet of some sort anyway. Consistency is one of the things that allows rapid learning, and is vital to the success of an interface among non-expert users. It's actually fairly valuable to experts, too.
GUI? CLI? Voice? Who cares! The key thing is that:
1. You can get a list of plausible options in most cases. The list may be a bunch of icons, any of which you can click on. It may be a dock. However, somewhere, there should be some kind of guide to what your choices are.
2. There will be cases where no such list can be made, because there are thousands of entries; in these cases, a little sorting goes a long way.
3. You must be able to pick an action unambiguously.
4. You must get feedback as to whether an action has succeeded or failed, and if it failed, you should get an indication of what prevented it.
5. You should be able to control the level of feedback based on your needs.
6. You should be able to abort unintended actions. Undo is nice, but abort is absolutely essential. For newbies, dangerous actions should come with a clearly labeled delay during which an abort will be harmless.
Most UI's try for some portion of some of these. Some attempts to make "easy" user interfaces end up falling down. How do you rename a file on a mac? Click on the name and wait a while, and it becomes a text box. However, if it can't be renamed, no one tells you, because there's no reason to believe that you really meant "rename", not just "select", and it would be stupid to give you the warning if you were just selecting a file.
This gives us also:
7. Explicit actions are preferable to implicit actions. You should always know what the computer thinks you're doing.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
But a few big, important things:
- Ease of learning - steep learning curves bother people!
- Power - it must accommodate both novice and advanced users (scripting is good here)
- Consistency - users should be able to use new programs without having to relearn a new interface each time
- Response speed - it must respond quickly when the user tells it do do something
- Efficiency - it must allow the user to complete tasks quickly, rather than getting in the way. This is one spot where Windows has really failed.
- Aesthetics - yes, most people care about how pretty their desktop is (me included)
- Appropriateness - the UI should reflect the task it was designed to facilitate. For a computer, this means it must be flexible enough to allow many different kinds of applications to work
- Flexibility - both for different types of tasks (word-processing really is quite different than video editing), and different kinds of input devices (why can't I use the joystick to navigate programs?)
- Predictability - things should do what they look like they'll do; nothing more, and nothing less
- Context - the UI should give obvious context to the user, so they'll know what they need to do. Conversely, it should also provide simple and easy ways for the user to specify a new context (multitasking, etc)
That's only a few things which matter, but hopefully it illustrates the difficulty of doing it well...I think one of the major requirements for a user interface is a very hard one -- it has to simultaneously:
(1) Allow newbies to understand what's going one and learn (e.g. menus);
(2) Allow casual users to use "standard" skills in an application (consistency across applications);
(3) Allow experts to use fast but nonintuitive ways (e.g. keyboard shortcuts) and to considerably modify the user interface if desired (e.g. remap keyboard).
(4) Allow a smooth progression from the newbie status to the expert status (newbie and expert should not be two completely different interfaces).
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Pieces of paper on a desktop?
This is one area where I think a lot of the open source tools get it right. A good example would be the utilities that are available for burning CDs under Linux (and other operating systems) such as mkisofs and cdrecord. These tools provide the functionality that you need to premaster and record CD-Rs on the command line. Then you've got software such as xcdroast that essentially acts as a graphical front end; when it needs the services of either of the previously-mentioned pieces of software, it simply opens a pipe to them and lets them do the work. The result is that if you prefer working with a command line (as I do), you're good to go. If you prefer working with a GUI, you're still good to go.
In many ways, this type of architecture is an extension of the classic paradigm of Unix tool development: have a lot of tools that accomplish small tasks, and have the ability to chain those tools together to perform more complex operations. Only in today's environment, "chaining together" often involves wrapping a functional GUI around them to make them easier and more intuitive for users to navigate. This type of architecture really does offer the best of both worlds; it gives users the tools they need to perform a task, and it offers them a choice as to how those tools will be used.
We're going down, in a spiral to the ground
Having different interfaces (e.g. voice recognition/GUI/command line) is vital for a usable computer. So is being able to change the interfaces you are given. MS (as well as other companies) don't seem to be aware of this fact.
"Why are computers still hard to use for people like my mother, and how can we make this better?" Hmmm...then she'll find all my porn. I wish not to make this better.