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.)

Comments

not really

[Anonymous Coward]

Windows has a rather counter intuitive interface, and I'm sure it is rather well funded. The menu is very slow to navigate, and can't really be customized. The desktop is clutter waiting to happen.

Re:not really

[hostyle]

I've always wondered about that "desktop is clutter waiting to happen" metaphor. I personally never use it in any OS. The desktop is always covered by applications I am currently using. I've never actually got the whole desktop background / image thing either for the same reason. Am I alone here?

Re:not really

[StateOfTheUnion]

But the windows interface is familiar . . . and that makes it useful to stay with the same conventions.

Open Source stuff could leverage that familiarity by create exactly the same sort of interface with all the advantages and disadvantages it provides because that would at least be familiar to the Joe Average user.

Re:not really

[E-Lad]

So what you're saying is that because the Windows UI sucks, it is O.K. for anything else to suck as much, too?

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. /dale

Re:not really

[ZZeta]

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.

Re:not really

[Walt Dismal]

The problem basically is a failure of vision by management.

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.

Re:not really

[Prof. Pi]

So what you're saying is that because the Windows UI sucks, it is O.K. for anything else to suck as much, too?

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?

Re:not really

[AntiOrganic]

At the very least, it sure explains why I get so many calls from clients who are confused by how simple it is to load their systems with spyware and viruses through Internet Explorer exploits.

Unfortunately, it seems that Microsoft put way too much stock in "simplicity" and not nearly enough in "good operating system design," so the time spent on the learning curve they would save by sticking with Windows is utterly negated by the amount of time their system is incapacitated and in the possession of someone whose job it is to fix it.

While simplicity is important, it's not the most important thing, and a learning curve isn't the biggest dent in TCO of a system.

Re:not really

[blix5]

You can sit the same 5 year old kid in front of a modern Linux or Mac machine, and they can just as easily surf the web and play games.
Windows didn't sell millions of copies because of simplicity and good software development; it sold because MS has always had a stronghold on PC hardware.

Re:not really

[bit01]

Agreed, way too many programmers make excuses.

A good, basic GUI interface is not hard, it is easy. Too many programmers won't even spend the hour it takes to design. They incrementally add cruft for months and then wonder why the hell everybody complains about their program. It is a real shame the number of freeware programs out there where the programmer spends months on the code and seconds on the user interface. What a waste.

All they need to do is keep in mind one simple fact:

Will the naive, lowest common denominator user operating the program for the first time immediately know what to do next at every stage or do they have to be a mind reader or a detective?

Way too many programmers do not follow that simple principle. All they need to do is storyboard the common uses of the program (starting from before installation!), see where the roadblocks are and reorganise each part of the user interface causing a problem until their are no roadblocks left. Easy. If the programmer can't imagine what a naive user would be like just pick a naive friend or relative and (mentally) run them through the program assuming they will have no prompting or help at all.

Stop making excuses. If you want your program to be used, make it useable.

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA abuse.

Re:not really

[drsmithy]

For instance, Microsoft puts icons on the left, directly behind where most Windows open, so you have to minimize or hide those windows to access your icons. Apple puts icons on the right and in the dock, so when you have a window open, you can still double-click on your icons.

That's what the Start Menu is for. Not to mention apps don't "open on the left" any more than they "open on the right".

Microsoft maximizes windows to full-screen. Apple maximizes windows just large enough so that you can see everything in the window, so that you can still get to things behind the window.

Again, this is simply a matter of "different". Personally I *hate* the way OS X's "maximise" isn't "maximise".

Microsoft doesn't have a standard for keyboard shortcuts(alt-f4/tab to quit/switch apps, ctrl-x/c/v/z for cut/copy/paste).

Yes, it does (and always has). If developers don't use those keys, there's nothing Microsoft can do about it - but they _do_ exist.

Microsoft has application preferences in some weird menu generally named "Options" somewhere off to the right, and Preferences isn't generally named anything.

Tools -> Options. If it's anywhere else, it's a developer mistake.

Microsoft has the same UI standards as Apple. The difference is Windows has so much more software there's bound to be more that doesn't follow those standards.

Re:not really

[Anonymous Coward]

The article suggested that programmers take the time to learn about usability. While I agree, I think the problem is larger than just having familiarity with usability. Development should be done in multidisciplinary teams, not in silos. If one group designs something, no matter how many studies they read or testing the do afterwards, it will still really be built by only one discipline and be lacking. Having a usability person whose expertise is to think of the user at all times makes a huge difference, but having them work WITH the tech team makes all the difference.

As a programmer, when you are solving a problem, you are constantly thinking of the design of the code, the algorithm to use, optimizations you can do... Which is exactly what you should be thinking of. It is nearly impossible to do that AND think of usability at the same time effectively. Trying to do it yourself, to change your frame of mind like that is very difficult and time consuming. Having a basic understanding of usability principles though can go a long way to making your application or whatever many times more usable than if you had no context at all.

Having a usability expert that knows nothing of programming can be complicated too though because they do not know what is and is not possible. Usually the problem is them not knowing what IS possible. Having the knowledge of what computers are capable of, what all those gigahertz and gigabytes of RAM and disk space can do... knowing those things and working with programmers that know what they are doing... THAT is when things take off and really become something special.

When usability and programming comes together and understands each other the end result is more familiar, faster to use and usually takes less time to develop. Programmers are creative, just many do not realize it. When given the right context and enough room the usability/programming team can do some great things. I am not a fan, but who thought up Mac OS X's expose? I am betting it was not just a programmer or just a usability engineer.

Expanding market?

[LeahofRivendell]

Isn't this synonymous for saying that the market for computer software has grown so much that all sorts of people are using it?

Re:Expanding market?

[MasterVidBoi]

No. This was a problem even when only geeks used linux. Just because you are a 1337 h4x0r doesn't mean the interface doesn't matter.

My most recent example? I decided on the advice of a friend to try Fluxbox a few days ago. In fluxbox, pretty much all configuration of happens inside a context menu. Fluxbox was definitly designed for technical users, but that doesn't change the fact that this is *terrible* UI design. Why? let me count the ways:

- Error prone: if you move the mouse the wrong way, you have to drill through several levels of submenu to get back to where you want to be. Similarly, when you activate a menu item with a submenu, you have to drag the mouse straight across the current menu horizontally until it enters the submenu, then drag up or down to the item you want. If you do the natural motion (drag diagonally directly to the desired item), the mouse will almost invariably cross another submenu first, forcing you to go back and re-activate the menu you wanted.

- Bad choice of widget for the type of action necessary: Incrementing or derementing transparency levels as a menu item!? It takes ~20 clicks to go all the way from opaque to fully transparent.

- Slow: In keeping with the previous comments, actually making this menu system work takes time and concentration. Fluxbox devs and users may think they're cool for having 'every option at your fingertips', but actually getting to those fingertips takes longer than if they had brought up a conventional window with sliders and buttons.

There are a set of utilities that provide conventional GUIs for configuring these things, but they are quite incomplete feature-wise, and suffer from their own ugly interface problems. In addition, you have to restart fluxbox to see the changes. Things done in a preferences panel should take effect instantly, which gives the user the ability to experement easily, giving them, in effect, more control.

There's been a lot of research done on how menus should work, and submenus really slow users down. A lot. For this reason, Apple's UI guides recommend that under no circumstances should you ever have a submenu inside another submenu, to eliminate this nasty nesting.

Just because you or I are technical users doesn't change the fact that there are other interfaces for this functionality that are faster and more forgiving.

Re:Expanding market?

[GCP]

From the article:

One of the advantages of open source is its ability to put the consumer ahead of profit.

This is bordering on nonsense because, though OSS has that "ability", strictly speaking, it certainly doesn't have that *tendency*.

On the contrary, companies that pursue *profits* are more likely to be interested in consumer usability because all profits come from the consumer.

What OSS does is put the developer's needs ahead of those of consumers. If there is no profit to be had, then it has to meet the developer's needs or it won't get written. (This is personally advantageous to me because, as a developer, my preferences tend to resemble that of other developers, but that doesn't mean that their first priority is *me*.)

A system that tends to answer complaints from its consumers with "if you don't like it, write it yourself!" is not one that I would call responsive to consumers, and the fact that they are not after profits doesn't seem to me to make them *more* responsive to consumers. It makes them *less* responsive.

I think the best thing for usability is the entry of corporations (anyone from little Red Hat to giant IBM) into the game. These guys *are* looking for profits, and they are the big drivers behind consumer usability in OSS, for the most part.

Re:Expanding market?

[Erik Hensema]

In my experience, this is exacly the problem in the usability discussion. Most people completely miss the point, saying that after countless tweaks which are very hard to implement for a novice user, the system works just fine.

IMHO, they take the easy way out. Making a system usable by default is hard. Very hard.

Moo

[Chacham]

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.

Re:Moo

[skraps]

Let *them* draw the screens, then merely implement it.

Bzzzt. Wrong. Users have no idea what they want.
The average developer knows zero about good ui design. The average user knows less than that.

Re:Moo

[skraps]

At best, this tactic means that you pre-empt the user from arguing that you gave them something they didn't want. It does *not* mean you gave them a usable interface.
The goal is to make something the user can actually use, not to eliminate a valid avenue for them to ask for improvement, or to make them feel guilty about being shitty ui designers.

Re:Moo

[Jerf]

Let *them* draw the screens, then merely implement it.

You think developers know nothing about usability? That is nothing compared to users ignorance.

Your suggestion, while noble sounding, is a recipe for a design where every whim a user ever had is encoded as a button that does just that, nothing more, resulting in a Million Buttons design.

Users are moderately competent at designing an expert interface but utterly incompetent at designing a beginner interface. (So are most developers, so that's not a horribly user-hostile thing to say.) And note I mean moderately literally.

The problem is, first and foremost, that people need to understand what usability is. Here you are with a +5 comment on Slashdot and you seem to think its just a matter of drawing screens. You evidently have no clue. It goes way beyond that. It is a matter of making software easy to use.

What is Usability? "We Don't Need Usability, We Already Listen to Customer Feedback" (at the bottom).

Not just "technical"

[Alex711]

All of the technical skills in the world are useless if the programmer doesn't understand what people want (or at least would like).
However, it is very expensive and difficult to really understand how people use things. The solution, I think, starts with taking user-friendly interfaces from other products (and not just software ... machines that people use everyday, such as TV remotes and their "Recall" button (kinda like alt-tab), can teach us things).

Artists aren't necessarily usability experts...

[Anonymous Coward]

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.

usability problems aren't just technical problems

[Anonymous Coward]

The author alludes to the real problem with usability and open source when he comment about egotistical mailings on the newsgroups.

Too many open source developpers think of themselves as GUI experts. Until developpers are prepared to give up their egos and admit that while they may be shit-hot kernel coders, they know jack-shit about GUI development, open source will be stuck with poor usability. Unfortunately everyone seems to have their opinion on GUI development, and somehow believe that their opinion is right, despite having no training whatsoever in usuability engineering (does this remind you of how everyone is a 'pop psychologist', and a 'pop computer language expert'? -- it should).

Until developpers understand that GUI development is hard, and that it's also a science with reputable metrics, and until GUI developpers are put on the same footing as other developpers in projects, open source will continue to have poor usability.

Apologies for being so harsh on the open source world, but that's the reality of it, and we need to face that fact.

Re:Evolve

[Anonymous Coward]

one of the first things they teach you in usability classes: complete customization and skinning does not equal good usability and can confuse normal users. It's best to stay with the default look-and-feel of other common programs. "normal" users want a clear interface that works and looks as expected. (Note: you and your friends are not "normal" users).

The desktop is not the problem....

[Anonymous Coward]

Let's talk about applications. One glamourous example is GIMP.
In my job I do a lot of technical documentation and I like when my work is pretty and easy understood.
I know I can get almost any task done with Gimp, but I also know that if I use Gimp I dont get my work done - simply because the interface is too difficult.
There's nothing wrong with advanced interfaces but rocket scientists should not have to have the skills and experience of Technical witers in order to document their project.

Okay...

[CosmeticLobotamy]

Maybe I missed the point, but this seems to be an article that says, "This is the problem we all know about. The solution is to fix the problem."

Until people start taking human factors seriously

[Anton Anatopopov]

We will never get usable software. Very few CS courses make their students study cognitive psychology, or design, or anything else in the 'creative' area of science.

Your average linux-using developer thinks that everyone else is as smart as he is, and that command line interfaces are a good thing. The GUI is seen as a fisher-price interface for retards.

We need to get rid of this way of thinking. Software should be like a vending machine. You press a button, and it does exactly what its supposed to.

Linix and Windoze have set back the cause of usable software about 20 years!

Re:Evolve

[dracvl]

Bollocks.

Skinning has done more to ruin usability of applications than anything else the last 10 years. Skinning has absolutely nothing to do with usability, it's purely visual customization.

Throwing out the menu/window paradigm is a very bad idea, as you get rid of the only thing the user will be able to re-use from other applications in yours.

I haven't read the article yet (on my way there now), but the parent poster has no idea what constitutes good UI, and shouldn't be modded up. I assume the article has more sane advice.

And yes, IAAID (I am an interaction designer).

good graphic designers

[stonebeat.org]

i speak this from experience: there are 2 kinds of good graphics designers: 1) those who have a real job; and 2) those who work a starbuck (or other coffee shops) Those who have a real job, make way too much money to care about OpenSource stuff. And those who work at coffee shops don't have enough time/money to spend on OpenSource stuff. Both of these types don't have time to write HOWTOs on good User Interface design.

We use the users in designing

[StateOfTheUnion]

When we design systems for plants we typically involve the users . . . like for a compactor, the users demanded that two separate buttons be pressed to engage the machine and the buttons must be held down and must be located about 1 yard apart.

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.

Re:Evolve

[Cid Highwind]

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.

KDE, Gnome, Linux...

[halo1982]

I've tried to switch over several times, and I just can't do it. KDE and Gnome get better and better, but they are still so different from the Windows I've been using for the past 14 years. I always have the same problems: I can't find things, wizards don't work properly forcing me to go to HOWTOs and the command line/conf files, and theres not enough integration between the window managers and X. I'm quite technically competent and I get better and better with Linux everytime I try it, but for the average user or your mother/grandmother there is still so much work to be done.

Re:KDE, Gnome, Linux...

[theCoder]

What you're talking about isn't a usability problem per se, but an interface difference. And you're right -- Linux and Linux programs are different from Windows. KDE is similar, but it's not the same. And it will never be. Some things will always be different -- either because of design differences or because Windows just does the wrong thing. And that's not a bad thing either.

For me, the best way to really learn Linux is two get a second computer and put Linux on it (if you're really adventerous, put it on your only computer, but I wouldn't recommend that). Don't dual (or as I call it "duel") boot, because you'll always fall into the trap of "I know how to do this in Windows, so I'll just use that". There's still that temptation with two computers, but IMO, it's not as bad since you still have the Linux one up to use. Gradually, you'll learn more and more about Linux and how it operates (it actually is fairly logical and intuitive -- just not the same as Windows).

You may want to use something like Putty to ssh to the Linux computer from Windows and use both at the same time. You'll learn about Linux while using the more comfortable (for you) Windows GUI.

One other thing to remember -- you can't hurt the Linux computer while you're not root (unless, as root, you give your user account permission to hurt it). So don't be afraid to poke around (especially in places like /proc) to learn more.

Personally, I don't think Linux has as many usability problems (at least not in general) as people claim. After all, most Linux softare is OSS, and most OSS developers actually use the software they're developing. So, the developers are the users. In that case there is tremendous user feedback and interaction in the development of OSS. It may not be usable for everyone (it may not even be usable for most people), but it is usable for someone. For example, gcc is a very difficult to use program. In fact, most developers rarely execute it directly, except for very simple compilations. Usually, the gcc command line is built by make through a Makefile (at work, we use imake to make exceedingly complex Makefiles from Imakefiles). Some compile command lines can be dozens of terminal lines long, and would be difficult to type in by hand. But gcc (and other compilers) are powerful tools intended only for experts. They really aren't intended for average users, and thus don't need to be usable for them. But they are usable (or usable enough) for developers, and work exactly as developers want.

I think most of the perceived usability problems with Linux (and KDE/Gnome/etc) are because of different expectations by the users. KDE and Gnome are certainly very usable (I only run Linux at home now). But different expectations lead to this perceived "crisis" in usability that can apparently be fixed (I'm not sure it can ever be completely addressed). While some tools could use improvement (especially integrating with hardware), there are a lot of tools that do have good (or at least usable) interfaces.

Anyway, sorry for the rant :)

Maybe we should be taking hints from games.

[Gldm]

Is it just me or are video games way ahead of other apps on user interface? These days most people can pick up a game and given the general type (fps, driving, rts, rpg) have a pretty damn good guess at the interface. It's not that the game authors have agreed on a standard interface for each genre, it's that they've figured out the things that frustrate new gamers the least so they enjoy the game more with less manual reading. When was the last time you had to read a game's manual to actually jump in and play it? I mean just the basic playing around, not the detailed stuff.

Why haven't desktops and apps incorporated advances from here? Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are. Also, how do they handle things similar to launching apps? Well there's a sidebar full of big easy to distinguish one click icons, and a set of tabs at the top that switches what set of icons is displayed by type (units, buildings, etc). Seems pretty easy to figure out to me. Want to quickly get back to the thing you were last working on? You can designate hotkeys with ctrl+number an then pressing the number jumps back to it. Some RTS's have seperate select and change focus but all seem to use a similar hotkey system.

One of the things that keeps me happier with windows than linux is the at least moderate effort at standardized interfaces. Most apps of simlar types have similar interfaces and I don't have to relearn all the terms that someone decided to use THEIR names for. Every time I see a custom media player or something with this horrible neo-future interface on windows I cringe, because it's such a bad idea. I don't want to spend time relearning how to use a media player just so it can look cool, I want to watch media with it. On linux it seems every app suffers from this "I want to look unique" urge, or a complete lack of asthetic design whatsoever. So your choices are pretty and confusing or ugly and confusing.

Re:Evolve

[FosterKanig]

Sort of responding to all the responses, not necessarily this post.
Usability is having the majority of features that normal (not programmers) use easily accessible. And then a layer below, have all of the power/complexity you want. Think of what the majority or normal users use the majority of the time. It's not that hard to do if you can just step back from yourself. Adding cool geek functions on the top level does not make the program better. It makes it more confusing.

Re:Evolve

[AchilleTalon]

Do you really mean you'd like to see and use a GUI designed by Picasso?

When contemplating a paint or sculpture from Picasso, you may be there and think for minutes trying to understand what Picasso was thinking while doing this paint/sculpture.

So, I don't really think you really mean artists, but rather than designers. That's not quite the same.

Re:Evolve

[stickb0y]

Attract artists.

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.

Write your software so that it can be expanded with skins

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.

Write your own GUI widgets instead of dragging and dropping something from your existing library.

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.

Consistency vs. Flexibility

[graiz]

There is no UI that will ever satisfy 100% of the people who use it. In a closed source OS you sacrifice UI flexibility for consistency. Not everyone is happy but the UI can be built consistently to satisfy novice users and intermediate users.

In an open source world everyone can customize the software to suite their needs so you sacrifice Consistency and Usability for Flexibility. Advanced users are happy but novices loose out.

If you want to improve usability in Linux or other open source projects you need to put someone in charge of the UI. Linus is the de-facto gatekeeper of the kernel but the UI seems to be fair game for just about anyone.

(A Former MS UI Guy)

Re:Yes a technical problem, but of different natur

[Speare]

The OSS community is fragmented, and values "do it yourself" too highly. Developers don't ASK for designs (other than skins and icons), and they ignore any interaction designs you offer them. I'd like to see that change, but honestly, I see little hope. There are very few people who can both design for the user AND implement the design.

Consistency

[zaphod_bee4]

The real key to Good UI design is consistency. Many open source projects have unfinished features, differing UI conventions and throw the user curve balls. This can be expected for testing and non stable releases. However any release labled stable build or 1.0 and so on should have a clear consistent UI and NO I repeat NO unfinished features.

This alone would help greatly. When a user downloads a stable build binary he should never see a menu that doesn't work or a radically different approach to a task that doesn't fit with the rest of the app. CVS snapshot builds and testing builds are a different ballgame.

Also Stable builds need to be clearly marked as such and stressed as the "polished" version.

Re:Consistency

[0x0d0a]

Many open source projects have unfinished features, differing UI conventions and throw the user curve balls. This can be expected for testing and non stable releases. However any release labled stable build or 1.0 and so on should have a clear consistent UI and NO I repeat NO unfinished features.

Frankly, I've found commercial software to generally be worse off with v1.0 releases. There are lots of pieces of OSS that slowly climb the ladder towards version 1 for a *long* time.

Re:Usability

[Quasar1999]

I'm a software developer, I work on commerical software. What you propose is great, lets fix the usability problems, and then worry about the technical 'behind the scenes' problems.

The problem is, that there are many cases where a seemingly minor UI change to the program would downright destroy the backend. For example (and it's a crappy one, I know, trying not to overcomplicate it...) Take a look at how the clipboard works. You can copy one item of infromation on it at once, and take one item off at once. As an end user, I don't understand why I can't copy text from notepad on it, then copy an image from paint, and then paste the text I had into Word, and paste the image I have back into paint. Obviously all the changes needed would be to know what I want to paste. Problem comes when as a programmer I now have to figure out what to paste where. Text into notepad, that's easy... but what about Word... now what, image or text? Okay, lets ask the user... oh wait, I can't, because I'm not able to do any UI in another program (hypothetically here...)

Yes it can be solved, but from a user point of view, it's minor, and from a programmers point of view it is damned complex and not worth the trouble. Let the user do two copy operations, instead of me having to write and debug thousands of lines of code that is trying to assume what the user wants (and the user will bitch about if I get it wrong anyways). Add to that most OSS developers are doing this for free, and are not going to want to rewrite their backend just for a seemingly minor UI change, which isn't going to make everyone happy, just a few people who complained.

What some people find intuitive is complex for others... there is no happy median... there will always be UI's that are not liked by some... there is no perfect UI design out there... and very few people willing to try and find it, especially for free.

Re:Until people start taking human factors serious

[kin_korn_karn]

Open source is full of people that are completely out of touch with reality.

The people who are involved in OSS have outright contempt for those who 'merely' use the software and think that everyone should want to type things like

ls -la |grep foo > foo.txt

to do their job - and that if they don't they're mindless idiots that aren't worth considering the opinion of.

Open Source still has a long way ahead...

[NotAHappyCoder]

...before it can compete in usability with commercial software.

The company I work for, generally sees Open Source as a good thing. But very often we choose commercial solutions just because they offer as a far better usability than those available for free.

Few months ago we tested OpenOffice.org against MS Office. We found out that OO.org was significantly slower than MSO, when running on not-so-modern hardware. Our users also found many problems in normal day-to-day usage. For example creating a document with a working table of contents was quite difficult for many of our users. With only a few clicks they usually managed to totally screw up their document.

Also OO.org sucked really bad in compatibility with MS Office. Almost all Word and Excel-documents our clients sent to us during that testing period, were displayed wrong. Only those with no embedded objects, pictures and tables, were displayed correctly.

I'm not trying to bash OO.org here. I'm merely trying to point out that it still needs a lot of work to become as good as MS Office is.

Re:Yes a technical problem, but of different natur

[digitect]

I'm not an active open source community person (just a user) . . . but I have to wonder if the open source community attracts the kind of people typically needed to create excellent interfaces.

It doesn't. I'm an architect and I regularly observe UIs that have no sense to them whatsoever. Open Source acts usually as a meritocracy and I've never found a coder who was willing to redesign his entire application because the UI sucked. It's not a chicken and egg problem (as other posts around seem to indicate) since the UI always comes last.

I once considered starting a project that designed application interfaces for tasks that were needed in hopes that some coder would come along behind and actually write them. (I had a great idea for a clock that doubled as a date/location/world time zone applet.) But we have no influence. UI is considered like the body molding tacked on to American cars half way through a model's life to re-energize sales. It's never considered as an integral part of the design the way someone Porsche does.

Re:Usability

[Anonymous Coward]

Exactly. Submit it as a bug. This is the first thing

OK, the problem is that your bug is probably going to land on the desk of the dork who thought that "smbUmount" was a good idea to begin with. Now, he might say "Duh! it was 3 in the morning, Sorry!", but he's more likely going to defend whatever perverse decision-making or technical constraints that went into this.

Any sane system would have identified the "smbUmount" thing as a problem to begin with, and wouldn't be waiting for some end user to wander in and say "Hey, umm, you know...".

At some point, it's like arguing with UFO Believers or Holocaust Deniers. Ultimately people either see things the "right" way, or they don't.

Maximise "discoverability"

[Anonymous Coward]

Make it easy to find out how to use the program. Intuitiveness is largely a myth, but discoverability isn't.

Here are my pet peeves:

(1) Context menus. Don't make entries disappear, dammit! Ghost them out. That way the user knows the thing is possible, even if it's not possible "right now". And you can learn their position.

(2) Icons (or 99% of all icons, anyway). Cryptic little pictures that might be meaningful to you, but mean jack shit to me half a world away. Except for _very_ well established standard pictures, you'd better put words next to the picture (and no, tooltips won't do). KDE menus and toolbars, at least with "text under icons" are _easy_. Humans invented language for a reason. Use it. GUI does not mean "no text". I prefer KDE to MacOS X mainly for this reason. Admittedly, I have a 1600x1200 display and don't have to worry much about real estate availability, but it is SO much easier to learn to use new KDE apps than Mac OS X apps because of this.

(4) Affordances. Make it clear that things are clickable. A simple bevel frame around a button might be ugly to you for some reason. But then make a prettier button, don't try and disguise the _fact_ it's a button and supposed to be clickable! This is the #1 sin of many a "skinnable" UI skin. Perhaps unlike many, I don't necessarily disagree with skinnable UIs. But then the skin needs to be designed for discoverability as well or better than an ordinary GUI!

(5) Undocumented "Registry" or text files for "advanced" configuration. The thing about such databases (_including_ plain text files, BTW), is that you lose discoverability. You don't know what strings are valid and what strings aren't as values. Editing text files is easy, and in some ways I like it, but NOT if it's not fully and clearly documented what values are valid and what they do.

Re:Evolve

[Prof. Pi]

Artists give us interfaces like ATI's TV recording software. All flash and no function.

Presentations went through a similar trend. Thanks to Powerpoint (mostly), the emphasis shifted from conveying the essence of your ideas simply and succinctly to making things pretty. It really was due to the laziness of audiences: if your slide had lots of colors, then it must be good -- they weren't really paying attention to it anyway.

My advisor got into that trend. It started when he told one of the grad students to add some color to the slide, which was a block diagram. "What color should I add?" was the somewhat sarcastic response. It didn't matter; any color would do, as long as it was exciting. (No, there were no differences between the blocks that could be expressed by color.) Then he had some of our undergrads do some presentations. One guy went wild, throwing in pointless animations and sound effects that did nothing except show off his Powerpoint skills. But then the advisor started encouraging this from everyone.

Fortunately, most people didn't go for the over-the-top stuff, but they still would do things like put shadows on boxes in block diagrams, even if that meant using smaller boxes, and therefore smaller fonts for the text. So who cares if the people in the back can't read your slide -- it's pretty!

Some of the best presentations I saw, BTW, were by someone who was giving an extemporaneous talk, and was drawing diagrams with a single marker on a clear sheet.

We Need Scalable UIs

[G4from128k]

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.

Usability 101

[k.ovaska]

On our "Usability 101" course at university, we were taught this process: figure out a set of goals that users have with the software; prioritize them and desing the application to make it as easy as possible to meet the goals. The whole visible structure and workflow is based on the goals. The set of goals must be complete enough to cover all uses, but should not have repetition. There might be different kinds of users who have different goals.

Details such as good menu labels are just that, details. They have to be worked out, but first the structure of the program must support the goals.

Usability testing is a fairly good way to spot errors in desing, but tends to bring up problems in learning the program. It doesn't need to be fancy, get a user and ask him/her to accomplish some goals. We practived it with videotaped paper simulation. No large numbers of test users are needed. After 5-10 users (even less for small applications), the problems that are brought up start looking the same.

The are design patterns such as "give user an idea of the whole when looking at a part of a document (or whatever)", an example being the scrollbar that hints about the current position and the length of a document. A good book would cover these.

Designing good UI is not something that can be learned in 5 hours. I agree some good free (as in beer) book would be good. I think usability is a problem for open source, because even if an "expert" would give usability comments on a project, there is no guarantee anything significant will happen (and restructuring a program is significant). OSS people generally don't like to be told, "look, you have to code like this". I think the expert should be prepared to code himself, or better, that leading OSS developers would themselves be educated on usability and able to desing good software from the beginning.

D'oh - dumb article, solveable problem

[Animats]

That's not an approach, that's a pep talk that says nothing. "Usability is a relatively new matter for us". Like, hello, Mac programmers have been doing this for two decades. We need to hit the "I am l33t because I can use a command line" people with a clue stick.

Ten things you can do to make your program at least tolerable for end users:

• No funny key combinations. Repeat, no funny key combinations. Everything must be accessable through the menus. Yeah, I know you want to be able to bind any control key combination to any function. Don't. It doesn't really speed up use anyway. Read Apple's old studies on this. People blank out on the 500ms they're thinking about the control key combo. And never, ever use keyboard toggles that don't have a permanently visible state on screen.
• If it's undoable, you don't need a confirmation dialog. If it's not undoable, you need a confirmation dialog. Make it undoable if at all possible.
• Distinguish clearly between severe and non-severe errors. "You are about to change your font to sans-serif" should look very different than "You are about to permanently delete all your files".
• The user should never have to tell the computer something it already knows. This is basic, and routinely violated in the Open Source world. The user should never have to fill in a blank when the computer can find out what goes in that blank. Offer a choice if necessary. Yes, much of this comes from UNIX's crappy approach to system administration. Work on that.
• If you need a database, use a real database. Flat files are so 1970s. Databases work today. The most troublesome apps in computing, BIND and Sendmail, are both database apps with a bad homebrew database. Provide for database validation and recovery.
• Anything that can get itself into a bad state must be able to get itself out of that state. No more having to delete "XUL.mfl" every time Mozilla screws up. Anything with cached data must get this right.
• If you try to be smart, make sure you're not being stupid. Try entering data into an OpenOffice spreadsheet. If you have something like "12 VDC" somewhere in your spreadsheet, and you type "1", it fills in "12 VDC". Which you have to erase. Every time. Now go try that in Microsoft Excel. Microsoft's wizards will fight you once, but if you override them, they give up.
• Modal dialogs should be short and clear. They consist of a statement of the problem and a suggested corrective action.
• Get the subtle stuff right. Grey out the options you can't use now. Show in the menus whether something is off or on.
• Be rigorously consistent about how things appear to work, even when it's more work for some cases.

Re:D'oh - dumb article, solveable problem

[wirelessbuzzers]

No funny key combinations. Repeat, no funny key combinations. Everything must be accessable through the menus. Yeah, I know you want to be able to bind any control key combination to any function. Don't. It doesn't really speed up use anyway. Read Apple's old studies on this. People blank out on the 500ms they're thinking about the control key combo.

As a person who is (mildly, for now) affected by RSI, I must disagree with this, at least for power users. I do most of my work (at least, when I'm on an operating system which allows it) without the mouse, and generally learn the keyboard interface for a new tool as quickly as possible. This is because I find it both faster and easier on the wrists to use the keyboard for most of my work (programming). Unless I'm designing a human interface myself, I have very little use for the mouse because programming requires lots of text input and no mouse input.

For the occasional thing that the novice would use a menu for, I probaly have my hands on the keyboard already, and so even if there were half a second delay to think up the key combo, it would still be more convenient than the mouse. (Usually, I bind intuitive key combos so that this isn't an issue.)

For a window manager, I use Ion, which entirely violates your usability thesis: most of its features cannot be accessed using the mouse without a good deal of scripting, but on the other hand, almost all of its features can be accessed extremely quickly from the keyboard. While its model is not so intuitive as the one pushed by Windows, and it takes some getting used to, it is much easier and much more comfortable to use once one is used to it (and in my case, has customized the settings).

As a result of its terrible practices of hiding mouse interfaces and indicators, and its preferred model leaving out things like overlapping windows, Ion wastes very little screen space, and one can navigate to a given window with only one keystroke (two if it's hidden or on a different desktop), which once you've been using it for a month or so is much faster than one mouse click.

Thanks to Firefox's interactive searching and generally good keyboard navigation capabilities, I don't even have to use mouse there (although I often do anyway; for web browsing, it's just as fast as the keyboard).

I must say that I'm an Apple user also, and that I like their (mostly, see rant elsewhere) transparent metaphors and simple configuration, and I often find Open Source Software to be lacking in these categories. But you must remember that in general it is written by programmers, for programmers, and not for novices. If you're going to be using a tool fairly often, the most obvious interface might not be the best one.

Re:D'oh - dumb article, solveable problem

[wirelessbuzzers]

I actually would like to add one more bullet point to this list, which Microsoft in particular seems to get wrong a lot.

Have command buttons that describe an action, whenever possible! "Save" and "Don't Save" is one hell of a lot better than "OK" and "Cancel"! If you name the buttons after actions, the user doesn't even have to read the dialog most of the time.

Re:usability problems aren't just technical proble

[cleverhandle]

Somebody mod this AC up, please. He is stating a simple fact, which most coders will admit - most coders can't design UI. Is there proof of this? Not exactly, I guess. But I know in my experience that I'm so into the architecture of most technology I use that I have very little idea anymore of what "hard" and "easy" are for a regular user. When a friend/coworker comes to me with a problem, I'm frequently surprised at the problem's existence at all. The solution to me seems intuitive. Yet at the same time, I'll see the same user perform other tasks that seem clunky to me without any issue. I'm happy to admit - I should not be designing a UI. I don't have the training, and the more I learn about everything else, the further I get from "normalcy".

The NewsForge article flatly contradicts my opinion, yet offers no evidence whatsoever. It's nothing but cheerleading. "They say we need experts to design usable interfaces! I say we just need to try harder!! Rah! Rah! Rah!" Go on, write some HowTo's, file some more bug reports. But the whole point of the AC's comment (and mine) is that you have no point of reference for your solutions. The FOSS model is powerful, but it needs to face up to its limitations as well as celebrate its strengths.

Re:Yes a technical problem, but of different natur

[StateOfTheUnion]

This is what I was afraid of when I posted the original post . . . Personally I get the impression that a lot of open source folks create great applications for themselves or their peers . . . few seem to want or to know how to write applications for the average joe.

Perhaps there is an unspoken rule in the community that "easy user interfaces" = "simplistic programming" and perhaps that causes one to lose points in the open source "meritocracy"?

I really like your idea of designing interfaces for tasks and then developing the code to support the interface next. It implies that the user's need is defined first by the design of the interface. This locks the programmer into coding in a way that meets the user's need exactly as specified by the UI. It's a shame that didn't take off . . . But perhaps that doesn't leave enough creative freedom for the programmers to feel the project is "fun" enough to work on.

Re:usability problems aren't just technical proble

[Anonymous Coward]

I will back my own post up :-)

I am the perfect example of what I am talking about. I can code mathematics algorithms really well. That's what I am trained to do. I used to think I knew how to make GUIs as well. Then I got over myself :-)

Now I freely admit that I haven't got a clue about building good GUIs. As the parent to this says I have become so involved in the technical ideas of my discipline, that I have no real idea what is and is not normal/intuitive etc anymore.

I can no longer look at GUI design with "outside" eyes, only with the eyes of someone entrenched in my own way of doing things.

more Redmond propaganda?

[Anonymous Coward]

It is not just a problem in the OpenSource world.

Either the writer is ignorant of the proprietary software business, including windows, or intends to mislead the reader and reinforce the "Open Source Is Bad" propaganda.

Many windows apps, including those from Microsoft have terrible graphical front ends which frustrate the user's efforts to use the application and too often wastes time. Often the front end is so bad that I wonder whether it was deliberately designed that way to torment the user.

And many programmers arrogantly force users into doing things the programmers' way.

(And then there are the "smart apps" which do their damndest to second-guess the user and often do things wrong or alter data without notice. Those who produce such atrocities should be hung by their tongues and whipped with a very high quality SCSI cable--but that's another subject.)

Many open source apps are indeed designed the same way. The interface is poorly designed, incomplete, or just plain broken.

What makes open source different, though, is that one can use the source and make the interface better, unlike windows and other proprietary stuff.

And, unlike Windows, support--if it exists and you can get to it before you collect Social Security--is not going to tell you that the software you paid for is sold as-is and since you bought it, it's your problem and if you want it fixed, then buy the next version--if it ever comes out.

I stopped buying windows apps because of vendors' attitudes. The last crap software was from MIPS, the business forms company in California before their software division was spun off into a separate company, who told me flat out that it was my problem (and implied that it was my fault) that their check printing software only pretended to do anything. Thanks to that statement from both their support and sales people, we no longer have any business dealings with MIPS. And there are many others we no longer deal with because of the same attitudes--such as SCO!

I prefer open source free/shareware that I can try first to ensure it works, is not crap, and is not a pain to use. If it works, I pay for it. I have no problem at all paying for stuff that works.

Re:Usability

[Planesdragon]

You DO realize that the whole "clipboard problem" was solved, and solved in a very elegant and clever fashion?

When there are subsequent copy operations without pasting, move the buffer to a new file and display a UI to select items from it.

It's actually a great example. You don't give users what they want--you figure out their problem, and then come up with the best solution for it.

What about common sense in UI design ?

[master_p]

Everybody says how difficult it is to design the proper gui. I think that if a little common sense is applied, then guis can be functional and pretty at the same time. Here are some tips:

1) don't clutter things closely together; provide the proper spacing between elements of the gui. KDE/Gnome severely violates this rule.

2) use soft colors. Harsh colors make the user tired very soon.

3) Use bitmaps and labels that have a clear meaning to the user, not to the developer.

4) Be consistent with interfaces. The File menu should be there to open/close files; Ctrl+S must save the current document etc. There are lots of established conventions that work really well.

5) group similar things together (similar by concept).

There are really good sites with lots of examples of what or not what to do. But I don't think it is extremely difficult to make a GUI. All that is needed is plain common sense. I am a programmer, but people never complained about my GUIs.

How Sourceforge/Bugzilla can help usability

[0x0d0a]

True.

A way that software might support this behavior would be the ability to create "usability reports" and file them in Sourceforge or Bugzilla, and have bugs that simply refer to elements in them.

Re:Until people start taking human factors serious

[swillden]

Open source is full of people that are completely out of touch with reality. The people who are involved in OSS have outright contempt for those who 'merely' use the software

This is insightful? It's pure crap. There are certainly people who wrote OSS who do have contempt for the "mere" users, just as there are plenty of people who write commercial software who have contempt for the users. In general, though, developers of end-user applications, whether OSS or commercial, feel no such thing. They want their apps to be usable, because it's really cool to have lots of people using your stuff. That doesn't mean they know how to make software usable, of course. Wanting to and knowing how are different things.

ls -la |grep foo > foo.txt

Very bad example, though. The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily. The above is an excellent demonstration of the difference between ease of learning and ease of use. The UNIX command shell is extremely powerful and easy to use, but it is not necessarily easy to learn.

An easy to use interface is one which makes it possible to accomplish the desired tasks quickly and easily, without unnecessary steps or wasted motion.

An easy to learn interface is one which allows the user to accomplish the desired tasks without training (or significant effort to figure out how). Note that this concept is fundamentally different from ease of use in that while ease of use is an absolute (for a given task set), ease of learning depends heavily upon the user's other experiences and is achieved mostly through similarity.

These two axes of ease are nearly orthogonal, although they often seem to be somewhat opposed to one another. There are plenty of examples of apps (particularly in the Windows world) that are easy to learn but hard to use, and lots (particularly in the UNIX world) that are hard to learn but easy to use, but there are also a precious few that are both easy to learn and easy to use (many of them in the Mac world, actually). And there are an unfortunate number that are both hard to learn _and_ hard to use (Easily found on any platform). I'm sure if you think about it for a moment, you can come up with examples in all four categories.

Re:Yes a technical problem, but of different natur

[iabervon]

I think there are plenty of people with those skills who would like to help out. The issue is that they would need to learn to code and become familiar with the internals of the project before they could actually change things as systems are done currently.

My feeling is that the useability issue will be solved once UI implementation doesn't require any significant coding. At that point, users with ideas about how UIs should be done will work on projects.

Re:Yes a technical problem, but of different natur

[Anonymous Coward]

A) Gnome/KDE/Microsoft have HIGs as well.

Yes, and they may or may not be decent. No one knows, cause no one reads them. Apple's, on the other hand, are actually read.

B) You can go to a Mac board and find numerous places where Apple ignores/violates thier own HIG.

They are the Human Interface Guidelines, not Human Interface Laws. No one document can describe with absolute certainty how each situation must be handled. A good designer will take the guidelines as a starting point, and apply them to an overall vision as appropriate.

C) The "deep" problem is how to design an application around the tasks the user needs to accomplish. A HIG about button spacing, menu design, etc doesn't really help you there. iTunes, for example, is a lot more than MP3 + HIG.

And now your true colors show - you clearly have never even read Apple's HIG. The document does more than talk about button spacing (although that's there) - it also talks about the big picture. Now go read a bit and educate yourself before spouting off again.

Graphic designer != user interface designer

[0x0d0a]

Graphic designers generally suck at user interface design.

User interface design is wildly different from graphic design. As a matter of fact, there are probably more industrial designers that would do a better job of doing software user interface design than graphic designers.

I'd say that a lot of awful websites out there were due to people with traditional publishing and graphic design experience trying to apply old knowledge to the Web and failing.

Re:Graphic designer != user interface designer

[Anonymous Coward]

" Graphic designers generally suck at user interface design."

That's true. However, ultimately graphic design helps make an interface succeed or fail. At the very least, it clarifies the elements of a GUI and puts the user at ease. I feel much more relaxed in front of Aqua than in front of Win2K.

Ultimately, I think it's easier for an artist to learn interface design, than for a programmer or interface designer to learn art and graphic design.

Re:Usability

[Ilan Volow]

The problem is, that there are many cases where a seemingly minor UI change to the program would downright destroy the backend.

And that's precisely why we usability folks advocate designing the UI at the *start* of the development process, so usability is there from the get go and programmers won't have to re-write zillions of lines of code.

Unfortunately, designing UI before writing code is seen as heresy by the Unix Culture that dominates Open Source, often being referred to as a "proprietary" development methodology. And this is one of the big reasons why Open Source usability sucks.

Re:Until people start taking human factors serious

[IntlHarvester]

Very bad example, though. The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily

It's a good example, but not for the reasons you are thinking. GUIs don't do this because it's a completely uncommon task. (If anyone actually cared, it would be easy to add a "save as text" button somewhere in a filemanager.)

However, the CLI Fanclub can't get past the the idea that a GUI is crippled because it can't do the stuff nobody really wants to do anyway. They are completely confused between the concept of a "user" interface (make everyday tasks easy) and a "programmatic" interface (be infinitely flexible).

(Now someone's might come at me about how they use grep/find 300 times a day, but do they really do that more than simple directory browsing or copying random files from point A to point B?)

I think the original poster was being a little extreme, but you do get the idea that Unix Filemanagers are developed for "other people" and not for "us" or "everyone".

system versus apps

[bcrowell]

I think your example of the clipboard is an important one, because it touches on the interface between the system and apps. In my view, most of the most severe usability problems in OSS are system problems, not problems with applications.

I just gave my father a Linux machine as a present. He is not a computer ignoramus. He's a lawyer, but he used CP/M for years, and is at least conversant with the idea of using a command line. The biggest problem he's running into is that I gave it to him configured for 8-bit color, and now he can't figure out how to get it to work with 16-bit color. I haven't been able to solve the problem for him over the phone, either. He doesn't need help using Mozilla; it's basically the same UI as IE. He doesn't need help with AbiWord; it's the same as every other word processor.

For me as a Linux user, the big frustrations are all things that are the fault of the system, not the fault of the person who wrote the end-user GUI apps. Some programs (e.g., Pan) only fully support the control-C/control-V style of cut and paste, while others (e.g., Emacs) only support the traditional X-Windows version. The lack of standardization of the interface is a system-level problem.

Another example is shared library hell. It's not the fault of the person who wrote a GUI app that the latest version of the Pango library wants its data files in a different place than the old one, and gives a misleading and worse-than-useless error message. Printing is another example. How many people do you know who boot into Windows every time they need to print, simply because setting up printing on Linux is too much of a hassle?

There are many layers of software below the application level (libraries, X, the kernel), and the problems are almost all down there, not at the app level. That shouldn't surprise anyone, either. There is no centralized authority to tell people how to write Linux apps according to certain guidelines, and the people writing libraries don't have a boss to tell them, "No, goddamn it, you are not allowed to break binary compatibility twice in a month!"

Horrible idea

[0x0d0a]

I subscribe to the tenant, "Your application should look like the standard applications in your environment." If you are in windows, make your application menus like Microsoft Word as much as possible.

This sounds quite reasonable, and honestly, I probably would have tried something like this if I hadn't seen what it does.

It's actually quite a horrible idea.

The problem is that much of the time, very popular applications make interface mistakes that then get propagated.

For example, Microsoft regularly "beta tests" new interface elements for the next version of Windows in Office or MSIE. People consider that "since something is in Office, it's okay", they promptly duplicate it. This has led to duplication of a lot of interface mistakes on Windows. These include "smart menus" that reorder themselves, progress bars that move in non-minimum increments, animated icons to indicate ongoing tasks, rollover-highlighted toolbar buttons, wizards, multi-row tab bars, etc.

Also, many times behavior in one place is not appropriate in another. If you are using an interface guideline book instead of other software to help you choose what to do, at least the reasoning behind each decision can be included attached to the behavior to assist you in knowing when that behavior should *not* be used. For example, the classic MacOS flashes a menu item several times after it has been selected. This is not eye candy, but to help allow the user to determine which item has been selected, and to correct from errors in choosing the wrong item. If you simply saw this behavior, and were writing a game with custom widgets, you might think that *every* clickable item should flash several times after being clicked.

There should be a set of interface guidelines in place desktop-environment-wide that are sufficient to usually determine how to do something. This has worked well for Apple (who used to be King of User Interface), and is currently being used for GNOME and KDE.

no one has enough money for $oftware.

[twitter]

[graphic designers] who work at coffee shops don't have enough time/money to spend on OpenSource stuff.

Like they have enough money to keep up with Adobe and Apple? The designers I know are bummed out that they can't afford the software they were trained on in school. Introducing your favorite graphic designer to free software would be the biggest favor you could do for them.

Oh yeah, doing a little free design work is one way for an up and coming designer to get exposure. They don't need to write howtos for anyone.

We should be able to solve this

[PotatoHead]

I would like to throw out a couple of observations here:

I have found the very best programs are those built into two parts; namely, the command line part and the GUI wrapper part. Take a look at the SGI Indigo Magic desktop utilities and programs for very good examples of this. Of particular note is their software manager application. The command line is 'inst'. It is text based and can do everything from a terminal. The GUI portion is 'swmgr'. It simply wraps around 'inst' and presents a good interface.

The nice thing about this is the choice the user has. Running remote on low bandwidth, or want to script something? Use the text only portion. Perhaps a number of advanced operations need to be performed, such as new installations, or upgrades that break the GUI. Also use the text version.

Have a nicely running box and just want to organize and manage some software, perhaps install something new. Use the GUI and perform the task with ease.

Don't like the GUI? Well, write another one that does what you want in ways you want it to. Nothing breaks as a result and you don't have to talk with the people who wrote 'inst' in the first place.

Sure there are exceptions, like OpenOffice.org, so lets set those aside for a moment. I am not sure how well this approach would work for a large application like this.

However, most of the little programs people want to use are easily done in two parts. Doing this splits the work in that the geek developers can get the technical part done. Nothing really gets in the way of their innovation because they can leave the equaly hard GUI development to others.

Distributions, and corporations can build GUI interfaces that make sense without having to directly involve the core developers of the project.

Seems to me this fits in with both UNIX and FS/OSS core ideals.

Re:We should be able to solve this

[grumbel]

The command-line + GUI part however won't work much good for anything more then rather trivial stuff. Command-line tools are just far to inflexible for this, making it hard, slow or even impossible to get correct data out of them (ps auxw output is outdated already as it gets printed, find ... | xargs ... won't work for filenames with newlines in them, many utils output 'ascii art' (statusbars and such) stuff that one has to filter away or even interpret, etc.).

Sure for some of these things there are workarounds or even fixes, but in general the simple nature of command line tools makes them a rather bad choice as the basis for a GUI where one would need automatic updating of the displayed info as soon as it changed and such.

IMHO a more correct way to solve this would be to seperate all functionality out into a library and consider the command line tool to be just what it is, another user interface to the libraries functionality, just like the GUI. That way pretty much all problems could be solved while still providing both GUI and console tools, while neither of them would be limited by the other. However for this to work, people would need to cleanly seperate the functionality and that always involves some more work than just crunching a UI directly into the 'functionality'. There also seems to be some kind of philosophical difference between GUI and console people, both of them almost completly ignore the other in their design, leading to quite a huge gap between GUI and console tools, instead of a smooth translation as it should be.

KDE already has some support for calling its functions from command line, so there is hope, however pretty much all command line tools for daily use still lack a GUI counterpart or visa verse.

Re:Until people start taking human factors serious

[6Yankee]

ls -la |grep foo > foo.txt

[...] The above is fantastically usable... find me a GUI app that can accomplish the same purpose as quickly and easily

Agreed, it's fantastically usable - if you know what the hell any of that means. Of course, that means that if you don't know the first thing about ls, it isn't particularly usable.

I've ranted before about trying to print double-sided from a Linux/KDE machine, spending half an hour reading man pages, and finally booting up a Windows box and clicking a radio button marked "Double Sided". All because someone thought that sticking a command line in a pretty box with an OK button makes it usable. No, dammit, give me radio buttons.

What I could never understand was why, for the love of $DEITY, couldn't we have both? You can go straight to a command line, and I can play with my pointy-clicky button things (and maybe watch the command change as I do it, and just maybe learn something about lpr...)

Re:The real issue at stake here? The File System.

[Neduz]

I think you're comments on the "file system" are wrong. First of all, you're not talking about what "file system" technically means. Strictly filesystems are OS independent. Out of all OSes Linux can probably handle most of them. Of course there are some "typical linux filesystems" such as ext2, ext3, reiserfs, xfs.

What you're commenting on is the Unix vs Microsoft way of handling files/folders. And if your argument is intiutivity: take a look at Mac OS X, it's also based on the / structure. Some things are just more easy with this way of working. Especially mixing rw an ro partitions, network partitions, ... transparent to the user/applications. If you log in to a *nix box with home directories which are actually located on some nfs server, you'll find them under /home/youruserame. If you look for a program, you'll find it under /usr/bin. It doesn't matter if it is a rw partition on your local harddisc, or a nfs partition on some server, or even a ro cd, it's in /usr, where you expect it to be. With windows its a lot less intuitive to find My Documents on C: at box A, on D: at box B, and maybe on Y: at your work. Even worse if you want to install a program on a network disc. If you want to install it on M:\program files\, but the windows dll's are on E:\windows, you're really fucked. And nowadays most computers have more than 1 harddrive partition. In the old days A: was the floppy, C: the harddrive, D: the cdrom. But today I find computers with C, D and E are harddrive partitions. F and G are cdrom and dvd. J and I are shared music and movie drives, and M some online webspace. You call that intuitive? With the "everything is in /" structure you can have a /usr on the local disc, /usr/bin on a ro local disc, /usr/lib on a nfs share, it's just more flexible.

And to find your files, just use common sense: most Linux user mount their cd's under /mnt/cdrom, or /mnt/dvd, a floppy is usually: /mnt/floppy. Install programs in /usr: the executable goes in /usr/bin, /usr/sbin if it's a static one. Shared objects go in /usr/lib. Files belonging to a particular user go in /home/username. In that directory you can create folders for you text documents, multimedia files, ... in whatever way you want. If you want to share those files with other users on the pc, create a directory like /public.

I agree that at first the structure on a unix system looks like chaos, you seem unable to find anything in it. But when you understand some of it's basics, you see how logical and powerful it is.

Manuals is another discussion, and for every project the documentation is different. But IMHO the Gimp documentation is good.

Speaking Heresey

[coaxial]

Now you may want to call me a heretic, a troll, and a baiter of the flame, but listen my brothers and sisters to what I am about to speak none the less.

Many have you say, "Linux isn't any harder to use than windows/mac." That my friends is a lie. Still many more of you say, "Linux is almost there!" Again, I say that is a lie. I know! I have been using Linux since 1994. It has suckethed in the past, and it sucketh today. Has it improved, yes, but it is still quite bad. While I can only speak for the state of GNOME, I can say that it is actually becoming harder to use in the name of useability. How you ask? Why the file chooser dialog has no filename entry. Support for typing filename or URIs, things that have been included in everyone of the filechoosers ever developed is hidden under arcane keystrokes and even then lack the support of 2.4. Abilites that distinguished the GNOME desktop from others have been removed in recent years inorder to make it "more intuitive", which is merely a synonym for "poorly cloned in the broken in the way of Redmond".

The linux user experience is one of confusion and inconsistency. Applications don't look the same. Applications don't behave the same. Applications having improper interface criteria ("Edit|Preferences"? Why would I look for configuration details in the same menu that I use copy, paste, and search the text in?) Installing packages leaves them unconfigured, or configured with broken defaults. Too many times, the user is forced to enter commands at the terminal, or edit cryptic configuration files. Things that should be automatic aren't.

I postulate that this situation could be be resolved with a two pronged approach. First, a distribution that doesn't try be the One True distribution with every conceivable package in it. It should have one desktop environment, one office package, one media player, one emailer, et cetra. In short, one and only one of every software type. This simplifies package configuration, and enables almost complete autoconfiguration.

Secondly, all the user applications must be tightly integrated. There shouldn't be a mixture of say Gtk, GNOME, wxWindows, and Motif applications. All applications be of the same toolkit and of the same desktop enviroment. This will help make the user experience more cohessive. Unfortunately this isn't enough either. There has been developments in some of the required software that seem to be actually detremental to the user experience. Either a new enviroment will need to be developed (*bleh*) or perferably patches against an existing enviroment/applications developed. (Think Ximian, only not based on a cult personalities.)

** Users should not design UI **

[count0]

Because they almost universally don't know what they really need. Asking them to draw screens is great - but don't take it as gospel.

Instead you need to understand that Feature requests are symptoms of goals. If you follow up a particular feature request or screen widget with 'Why' you'll be able to design a UI that actually meets their needs, instead of something that they think will meet their needs.

ps developers shouldn't design UI either. That's why we have user researchers, information architects, interaction designers, ui designers, etc. Even if someone is able to code and to design (very very rare) there is a significant conflict of interest between design and implementation.

Re:Until people start taking human factors serious

[swillden]

What I could never understand was why, for the love of $DEITY, couldn't we have both? You can go straight to a command line, and I can play with my pointy-clicky button things

I think that's where we're headed. The trend with OSS stuff seems to be that every feature is provided at three levels: A CLI interface, for shell users, a GUI interface, for GUI users, and a library, for programmers (and, incidentally, used by both the CLI and the GUI interfaces).

We may not be getting there fast enough, but I think that's where we're going.

YOU can't solve the Problem

[yawgnol]

You can't solve the problem, because you don't have the skills to do it.

It's NOT a technical problem. It's a problem of DESIGN, which is different. So OSS programmers can make some kick-*ss software, but most people are not going to be able to use it unless someone gets humble fast and says, "Oh f*ck, I don't know how to design ANYTHING because... I'M A PROGRAMMER! I need a DESIGNER!"

I know it's hard, and it takes a project leader with almost saint-like patience and humility to let his/her project be co-designed from conception to completion by someone who knows close to nothing about programming, but that's the only way. You're not a designer so just suck it up, and if you want your software to be popular, and useable by people, make sure a user interface designer is on your team and do what they tell you to do.

Also understand that you are going to have to do almost double the amount of work you would normaly have to do to get a good interface. Don't get mad at your designer... It takes a lot of work. You will have to grit your teeth and do strenuous amounts of work to get something that satisfies your designers' requirements. Don't bitch about it, just do it. That's how it works. It's hard, and yes, most of the work is going to fall on the programmer(s).

But in the end, the reason why Open Source hasn't taken over MS is because of the UI and the marketing. Linux? Most people can't use it. I mean, I've used *NIX, and I hate it. Most people do. In fact, most people don't even bother to learn it enough to hate it. What non-programmer is going to commit 300+ commands to memory just to search and type and use email. Uh, yeah.

So don't be so full of yourself. You can't do everything well. Beg, borrow, or pay a designer, do the work, and watch people actually start using your sh*t.

Then you can get an open source MARKETER and start REALLY doing some damage to MS.

Re:Here's a crap ui design from KDE

[Anonymous Coward]

This is because CTRL+C is passed as a "terminate application" signal. Some applications also override this for their own functionality. Keep in mind, this was BEFORE the so-called standard, and it's and accepted standard of it's own.

-Adam

There's no such thing as 'intuitive'

[jandersen]

People keep talking about 'intuitive' as if they knew what it was; and most of the time it turns out that it is just another word for 'cool'. A lot of things would be a lot better if application designers would concentrate a little less on making the 'perfect' Fisher-Price look or implementing their own, private 'vision' of how the world ought to function. We have enough primadonnas as it is.

To achieve usability, I find that it is much better to focus on a few things:

1. Simplicity. It helps a lot if the application simply does what it says on the packet. Please note that simple is not the same as 'not advanced' - it just means that it does what you expect it to do. An electric drill is simple, even though it is a complex piece of mechanics - a Swiss Army knife with toothpicks, saw blades, compass and that pointy thing you can't figure out what is, is not simple, even though it is just some bits of metal stuck together.

2. Extensibility. When you have learned the basics it should be possible to add things in one way or another. Again, the function of an electric drill can be extended little by little as the owner gets more competent and/or wants to do more.

3. Discoverability. It shouldn't be necessary to learn-by-guessing a new ideographic script in the form of icons. This means there has to be documentation and a help system - and preferably one that isn't limited to some moronic context sensitive help. It's amazing so often you need to do something out of the immediate context.

4. Configurability. Quite contrary to common belief, people actually want to be able to customize and configure far more than developers want to let them. Yes, in the first few hours too many options may be intimidating, but very soon people get over this and want to make changes. Some applications manage this by providing more than one configuration interface - one simple, where the system sets a lot of defaults, and another where you have full access.

Some might think that these things conflict with each other. Like, how can it be simple, if the user can configure a million parameters? Well, provide sensible defaults, of course, so people are not forced to learn everything at once - but another thing to remember is, that a simple tool is also one that is adequate for the task - if you have to configure something that by nature is complicated, then the tool has to give you access to that complexity. As Windows so abundantly illustrates, it can get very complicated if the configuration tool is inadequate; and in Windows you often come across the sort of tool that is too simple, but at the same time cumbersome to use, where it would have been so much easier if only the configuration has been kept in a simple text file, and you could use a simple editor.

Re:Here's a crap ui design from KDE

[FooBarWidget]

Because Ctrl+C/X/V may interfere with the console app inside the terminal. Come on, is it that hard to understand?

Re:Getting rid of "configuration"

[Anonymous Coward]

This stuff about printer drivers being hard, blah, blah, is just a red herring, since the issue isnt about drivers.

Go sit down at Mac OS X and see what happens. You click print. A list of printers comes up. You chose one, and hit print. There are buttons to search for rendezvous enabled printers, and a few other bells and whistles, but it's basically, click and print.

If OS X can do it, Linux can do it. It's just a matter of mindset and effort on the developpers part.