Slashdot Mirror
Software Usability As A Technical Problem
An anonymous reader writes "Let's face it. Poor user interface design is a big problem in software today, particularly in the Open Source world. A recent article on NewsForge addresses this problem from the perspective that software usability is a technical issue that Open Source developers can and should face and conquer, just as we have conquered other technical problems that have stood in our way." (Slashdot and NewsForge are both part of OSDN.)
Isn't this synonymous for saying that the market for computer software has grown so much that all sorts of people are using it?
I are winner
Software should be designed, not just coded. And interface must be part of the design.
Personally, i like to ask the users what they want to see. Let *them* draw the screens, then merely implement it. A three-tiered approach is best, where called for. The backend should be design and implemented according toi a decent set of guidelines and rules, and the frontend should be completely designed by the user. The middle teir is where the magic should happen, even using a nasty hack here and there.
Ultimately the disparity between those who code software, and those who use software is a big problem. Perhaps a recognition of the separate group will go a long way.
Have you read my journal today?
So what you're saying is that because the Windows UI sucks, it is O.K. for anything else to suck as much, too?
/dale
Why is it that the first reaction of some people here is to make an excuse?
A UI that is intuitive to navigate is getting more and more important. The reason why Windows is and has been the way it has been since its conception is tha commercial companies don't like to rock the boat. I'm sure MS has come up with tons of ways to improve the Windows UI, but implementing these changes may in their eyes, upset too many customers who are used to it. I still remember certain people getting upitty when the taskbar and Start button were added in Windows 95.
Free software, OTOH, has quite a bit more maneuvering room in this area.
For GUI applications, the UI layout is can no-longer be considered by programmers as the sole kindom of the {Photoshop|GIMP} guy sitting over there and pass all worry of it on to him or her. Just as programmers want good APIs in their code, the Human -> Computer "API" is just as critical to good and satisfactory program and user function.
See KJofol/Winamp3, and Trillian among others. You've got dozens of very beautiful skins for your apps that are a bitch to actually use. Visual beauty while nice does not a usable app make.
What is needed is a consistent, predictable interface across all of a desktop's apps. In practice, this is a lot harder than just making it look pretty.
Why? Because then to operate the machine, each of the users hands had to hold down a separate button making it nearly impossible for the user to inadvertently reach into the machine while it was running.
At first I thought it was a silly thing to do that would insult the operator's intelligence (who would be stupid enough to reach into a compactor while it was running?) But one of the operators confided that it was a great idea because after being burned out from working a couple of double shift days in a row, he didn't want to loose his hand from a simple operational oversight.
The operational interface was well recieved because we gave the users ownership in the design process. I think that the same should apply in designing software UIs.
No no no!
Artists give us interfaces like ATI's TV recording software. All flash and no function. The more artistic freedom an app gives to skin designers, the more time I have to spend squinting at the cryptic emblems and trying to click on the 3-pixel-wide "play" button. Look at an old version of Windows media player (before v6), and marvel at how much easier it is to use than WMP 9 or Winamp 5. It uses the same widgets as the rest of the desktop, so you don't have to spend any time at all trying to decide where to click to activate each button. Artists understand what looks good, but very few of them have a grasp of what's easy to use.
It's better to write everything for a standard set of GUI widgets, and provide a mechanism for theming those standard widgets to look cool. That way, all your apps look consistent, and you can change the look-and-feel without having to re-learn all the interfaces.
0 1 - just my two bits
No matter how shity Windows is, one thing you can't argue is it's ease of use.
Anyone from a five-year-old to a WWI veteran can sit behing a Windows PC and be browsing the Internet and checking mails in no-time. (mind you, i'm not arguing the risks of this)That is what OSS should try to learn: simplicity. Average users like it simple and straight-forward, and IMHO that's *one* of the reasons for windows success.
--Just as important, the average user is by now used to the Windows interface, and it wouldn't be that bad of an idea to give them the power and strength of OSS with a windows-like interface which they are more comfortable with.
Usable doesn't mean pretty. Pretty doesn't mean usable. Artists can add aesthetic polish, but if they don't know anything about usability, they'll just make the problem worse. Look at Kai's Power Tools or the various other applications that try to look happy or fun but end up being totally non-standard and difficult to use.
Skins are not a solution to usability. Skins are a punt. To me, skins represent everything that's wrong: the software developers doesn't feel like spending the effort to time on design and doing usability testing, so they throw on a skin system and let the user deal with it.
How many users actually go create their own customized skins? And most skins out there usually cater more to aesthetics than utility.
Plus, there's the perpetual problem where every application has its own skin, and nothing is consistent with anything else. If necessary, global themes should be used for personalization; per-application skins are a mess.
Good lord, no. Please, please don't reinvent GUI widgets. Lack of consistency is one of the problems, especially in the OSS world where there are a zillion and one widget toolkits. Do you want a dozen different textboxes where some of them allow copy/paste and some of them inexplicably don't? Or maybe some of them can't handle Unicode, or maybe some of them don't have keyboard shortcuts to select text, or who knows what else.
Standardize. Stop bickering, stop wasting time reinventing things, and then everyone can focus on real usability issues.
Most companies I work for as a contractor consider the UI design as an afterthought, an unwanted burden, or a mere exercise for the programmer who was assigned the interface screen. The development managers have been hardnosed pragmatic guys who see no sense in spending their budget on any 'needless' items like psychology and design of a proper UI. These clowns also see no sense in developing state diagrams for the control flow on interfaces. The result is often interfaces that have unlearnably convoluted navigation. This is just unforgivably bad design practice. Sometimes I have to state chart the UI to prove that the interface is broken and bad. I often see interfaces that dynamically change their functionality - same screen, but buttons and selectors come and go depending on the state, new navigational connectivities invisibly appear and disappear - all of which confuses the hell out of users.
See, a user first encountering an interface has to build a mental model of meanings of objects, control flow/states, and navigation. Your goal as a designer or programmer is make the UI design easily learnable and usable. That's both a science and an art.
I've also seen far too many UIs employing flashy objects that interfere with the readability. I don't care if a button looks like a 3D gem, if I can't read the friggin text label quickly and easily under the gloss, it's a failure. Yet I've seen $6 million corporate software with unreadable browser-based interfaces apparently designed by a 16 year old Web designer with attention-deficit disorder.
Visual readability, learnability, ease of understanding navigation, three major rules.
No, I assume what he means is that if MS, with all its resources, has a hard time in the only area where they seem to make a serious effort, then it must be a difficult task.
Another issue I think needs to be discussed is the way people's biases influence UI design. Some people, especially younger users, seem to think GUI==good automatically, and thus, the more eye candy a UI has, the better it must be. Conversely, they think that a less graphical interface is automatically primitive, and that anyone who criticizes excessively flashy interfaces must be an old fart pining for the days of punch cards. Such people will see lots of eye candy and get a warm fuzzy feeling, and will think that UI is "easier to use." Even though all the stuff just gets in the way, and he has to go down through 4 or 5 levels of menus and/or screens to do the simplest thing.
Unfortunately, such people seem to dominate UI surveys, and UI designers get the message. The result, for me, is endless frustration as the UI keeps trying to "do things for me" and I keep having to hunt some setting down in the dungeons of the preferences editor somewhere to turn off yet another annoying feature.
Speaking of which, does anyone know how to tell XP to stop rearranging menus and/or hiding half of the options? That's such a PITA -- who the hell thought of such a moronic thing?
What apps and OSes need is scalable UIs - UIs that scale as the knowledge level of the user grows. A total novice, non-technical, casual users should be just as comfortable and productive as a hard-core, 80-hour-per-week developer. This has not happened yet because there are two distinct camps in UI development. Profits in the mass market drove closed source, mass-market software to create useability on the low-end. The natural interests and abilities of its contributors drove open-source to create useability at the high end.
The biggest challenge to scalability is creating inuitive metaphors or abstractions between the human interface (i/o modalities) and underlying digital constructs that does not get in the way of the power-user. Apple's early OS effort were great for the novice, but derided by more experienced users - the UI was not scalable in the upward direction. In contrast, Unix/DOS/CPM was fine for power-users, but it arcane command interface made it not scalable in the downward direction.
I suspect that the answer will be concepts like Mac OS X that combine GUI and CLI elements. But even OS X is not as scalable as one might like because it is really an intuitive Apple GUI grafted on to a separate powerful *nix CLI core. Although novice Mac users can "graduate" to the command line, the transition is not smooth -- using Finder does not teach one how to use ls, cd, mv, cp, rm, etc. Rather than being scalable in a continuous sense, Mac OS X offers interfaces at two different scales - the intuitive GUI and a separate power-user CLI.
Perhaps future OS/app UIs will be truely scalable -- early GUI use will seamlessly teach the user and help them slowly become more powerful users. Developign scalable UIs will require contributions from both novice-oriented usability experts and power-oriented developers. It will require forethought and coordination so that the disparate elements of the system are "consistent" without being inflexible.
Two wrongs don't make a right, but three lefts do.
Ten things you can do to make your program at least tolerable for end users: