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.)
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.
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
Well i think it is true but companies like red hat did some pretty good stuff like their blue curve theme for Gnome, I mean I love Gnome, I love the spatial nautilus (in term of usability it is just a dream for me) but the default theme for Gnome that i got in Slackware was a drawback in comparaison.. I love bluecurve
How is this much different from this article posted just four days ago?
Ford Prefect: No, but I've got a different name for the problem.
- The Hitck-Hikers Guide To The Galaxy.
I had to walk a newbie through it's UI the other day to burn an ISO - damn, talk about a UI that needs an overhaul. don't get me wrong, it's all I use when I need a GUI burner, and I'm responsible for burning all of our code and apps for distribution, so I like it, bu tit could use some...useability.
But don't get me started on the apps we produce...blech!
BFCB@$
free ipod and free gmail!
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?
All of the technical skills in the world are useless if the programmer doesn't understand what people want (or at least would like). ... machines that people use everyday, such as TV remotes and their "Recall" button (kinda like alt-tab), can teach us things).
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
It's a collection of 20 or so stories about where human factors problems caused injuries and, in many cases, death. Poor documentation, unclear designs, and poor handling of expected user situations (for instance, the reactor technician being pinned to the ceiling by a control rod because there wasn't a safety stop to prevent supercriticallity) is serious business.
There's more to usabillity and human factors then just 'that guy is too stupid to use linux', it can literally be the difference between life and death.
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.
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.
I like this quote from the article:
Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.
Exactly. Submit it as a bug. This is the first thing. Many of the people who work on OSS projects realize that there is a usability problem. However, nobody wants to do anything about it. It seems that many developers do not consider usability issues to be a defect in the software. As a person who is *very* interested in usability of software (part of my degree), I have to disagree -- issues with usability is a MAJOR defect. It's the reason that many people will not turn to Linux/OSS options. They are scared by the command line. They don't like it when menus in one program do not match up with menus in others. I can't say I blame 'em! (Well, I like the command line, but that's a byproduct of me being a nerd.)
As a backup to my previous statement, I am constantly submitting usability bugs to projects when I find them. However, I am constantly ignored. WHY? There are so many things that could be improved upon and made easier so it's more appealing to the users. Why do you think Microsoft products do so well? People recognize them. They know where stuff is. There's no guesswork needed.
And, yes, some OSS projects do this very well. Mozilla products (Firefox, etc.) are very well designed. There are minor usability flaws, but nothing that isn't easy to figure out.
Personally, I would love to sit down with a team and work through usability issues. I would love to have someone actually show some interest in fixing these problems. However, it seems that, too many times, these issues are discarded for ones that are more technical. And, of course, the usability issues will come up again later. It's a pretty vicious cycle that needs to be stopped. If only someone were willing to do it.
(BTW - I realize I could code these changes myself, but I do not have the necessary skills to do this. Otherwise, I would.)
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).
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.
I mean: right now most OSS has lots of skins and different possible interfaces, but most newbies don't even know how to switch them on. And that's because the software isn't intuitive.
Say you want to add a new remote printer: it's no use that the menus were designed by an artist, have several combining colors and so on, if you don't even know were to start from.
What the community needs to start paying more attention to, is the non-geek user who would rather have it simple and straight-forward than full of options he/she doesn't even know what they mean, and how to set them.
OSS is counter-intuitive, and even though it is making great progress, it still has a long way to go.
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."
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!
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).
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.
Consensus is good, but informed dictatorship is better
This is the secret to open source stuff: drawing on the community skill. This method is just in a non 'programming-skill' oriented fashion
If you get a Chilean developer to have his grandpa, who has no stereo vision, have half a look at it, then there'll be lots more important feedback, at least after Babelfish has done its work.
[% slash_sig_val.text %]
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
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.
I am a developer myself, so this post is in no way meant to offend developers. However it's true that developers (generally) do not see things the same way that most users do.
When i ponder what makes Microsoft so successful (aside from the questionably legal business practices) is that their company is not ruled by the developers but by the PHB's of this world. Microsoft invest considerable effort into researching what people are actually doing with their computers. Say what you want about them, they are actually pretty good about listening to their customers when it comes to features. By contrast, Linux developers often concentrate on scratching thier own itches which ultimately only appeal to like minded individuals. I could list several things right now that are not easily possible in Linux right now.
I write software for a small company, and we are very blessed to have a very technically less-literate person on our staff. He is our functional expert and he gives us a lot of great feedback on our UI's. Open source projects should never underestimate the value of such a person.
Blender And Linux Fan
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.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
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.
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.
Achille Talon
Hop!
Apple's Human Interface Guidelines is a good place to start, and is online for free.
It represents many years' worth of HID research. It's not the end-all, be all of HID, but it's one helluvalot better than nothing.
-- Cerebus
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.
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)
I am sick of hearing "I'm not a normal user." It is true that most users are not software developers, however there is a very wide range of users, with a very diverse range of needs.
What this means is that people who call for "similar applications" and "uniform experience" are just kidding themselves. The software I use and write works *very* well for me. Is pandering to a specific audience a problem? Or am I obliged to write software that I can't use?
Remember Homer's car?
Forget thrust, drag, lift and weight. Airplanes fly because of money.
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.
[
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.
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 to do their job - and that if they don't they're mindless idiots that aren't worth considering the opinion of.
...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.
I was going to mod you insightful, but this slashdot interface is too complicated to figure out.
"Personally, i like to ask the users what they want to see."
EXACTLY! Sometimes the users don't see the Big Picture and have old habits they want to keep around, but more often in my experience it's some boneheaded developer's choice to squander resources to "improve" an interface without ever actually investigating whether the users will get any improvement at all.
On my latest project (in-house application) I've actually had to go head-to-head with our senior developer (not a software engineer) over how the interface should look and work, me going to bat for the users.
The users of the new application want it to look and function in a manner that suits the way in which they need to operate day in/day out. Simple, straightforward. I prototyped it for them and they loved it.
Our senior developer then told me no, we're going to do it using MegaSuperKewl WizBang crap, something the users were fundamentally opposed to (it would actually tangibly interfere with the way they use the data in production).
I'm hardly junior myself - 11 years fulltime S.E. - and figured screw it, I'm not going to watch this abomination progress unchallenged. I arranged a meeting between the users, the senior developer and myself. The conversation was hilarious. I asked him to explain to the users how his design would improve their productivity. Let your imagination run wild and you'll come close. The users won in the end, but it was hard fought
But then the same week I had to argue, yes ARGUE, to store constants to be shared across applications in a common header file. The same fellow argued it would be much easier to hardcode it in each application separately. A heated 20-minute meeting later, I get to store the constants in a common header file.
I *WISH* I was making this stuff up. My life is a Dilbert strip.
IBM had some interface nightmares of it's own. Good to see they learned their lessons.
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.
There is no need to use a SlashDot sig for SEO...
A friend of mine went through alot of effort to get his racing wheel to be able to control his mp3 player, so he could just spin the wheel with his foot from his bed and not have to get up to change tracks.
:P
Someone once told me "The two required qualities of a successful programmer are laziness, and hubris."
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
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.
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.
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.
Ten things you can do to make your program at least tolerable for end users:
From the article:
Bulls***.
There are numerous books and resources on usability. For example:
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.
It has to be the tenth article about OSS and usability that I see in a couple of months (and at least two were mentioned here on ./).
:)
Listen, as someone pointed out: if there's a usability problem, fill in a bug report. This is OSS real force.
We are all a bit lazy. If something don't fits your needs, fill in a bug: it is like black ink on your dress, you HAVE to have it fixed, or what sort of programmer are you?!
Moreover, I think that's still the same old story: who says "command line is good enough for everyone, and if you don't like it, it's a problem of yours" versus "mouse is beautiful, why should I use that keyboard? It'll bite me, if I touch it!"
Well, I'm for: keep them both. For example, I noticed that in Kdevelop you haven't key accelerators when debugging your code. This is a problem for me, so I'll fill in a bug report, and I'll point it out.
See Emacs: you have menus, you have toolbars. Me, I spent some time learning the keyboard shortcut, and I never ever touch the mouse anymore! That's fine for me, and that's fine for the newbie, because the UI is there to help him.
As always, FS is about freedom, expecially to choose. And since we are here to get better, if you want it "your way", speak with the right people (the devs), don't just complain! OSS is about community, take part in it, don't just sit on the bench criticizing.
(Sorry for the awful english)
42.
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.
while a one-button system might work for a device, it does NOT make for good software. You have just demonstrated a very good reason why actual UI designers are an absolute requirement if OSS is going to move forward: even if you try to think of a good UI, and dont write any code at all, you wont know when to stop. You'll create crap.
;)
Good UI design doesnt come from the ass, it comes from working with things, talking to others who work with things, and improving apon them. OSS should be perfect for this, but we dont have any place for people to make UI suggestions, and we dont have UI designers who would be able to read, filter, and combine those ideas.
Nobody can come up with a good user interface. Everybody, on the other hand, that's a different story. The trick is finding out how to get everybody.
When you're talking about writing code, it's simple enough: It's open-source, send a patch.
When you're talking about using the product of that code, it's an entirely different matter: people who send patches probably shouldnt be trusted with their UI suggestions in the first place
-- 'The' Lord and Master Bitman On High, Master Of All
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.
Switch from windows to mac os, and you will find yourself in the same predicament of "having to read documentation".
Apple once held up the idea of the user never having to read a manual as a goal for their software.
Apple's now-unfortunately-defunct help system (Apple Guide) was what I consider to be one of the best UI creations in the desktop world. Microsoft took a "wizards" approach, where they slap a basic interface up to allow the user to accomplish a simple task. Often, if this was what the user wanted to do, they could accomplish the task quickly. Unfortunately, they had no idea what was done in the "regular" interface to accomplish this task. Their knowledge did not transition to the regular interface, they did not learn how to do something very similar but different from what the wizard allowed, and sometimes they couldn't figure out how to accomplish the a particular element that they could manage through the wizard in the regular interface. In short, Microsoft gave the user a fish.
Apple Guide was a much, much better design for the user in the long term, though it might be less immediately satisfying. Instead of popping up a wzard that hid the regular interface, Apple Guide walked the user through accomplishing a task *with the regular interface* so that they learned how to use the regular interface. This is much slower the first time or perhaps two times, but after that the user knows how to accomplish his task using the regular interface. It is much easier for him to become an "expert" with the software, and he requires less technical support in using the software.
May we never see th
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.
May we never see th
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
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.
May we never see th
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".
Business. Numbers. Money. People. Computer World.
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.
I disagree that it's at all uncommon. I think it's very common. The reason end users don't demand it is because it's foreign to their way of thinking about computers and how to use them. I've seen people many times searching through a document, looking for some word and then writing something about each location. About the only thing unusual about the example is that it presumes that only a single line of context is required.
Really, I think the way most end users think about how to use computers is a negative result of the document-centric model. They don't think of data as really manipulable, because they're used to looking at a document surrounded by icons and menus that define the totality of what can be done with it. I don't know that that's really correctable without an inordinate amount of education, but I think that it's fallacious to look at the features provided by common apps and assume that anything not in the list isn't something people do often. It may very well be something they don't realize they can do, or wouldn't understand how to use effectively if it were given to them. But something that would be useful if they had it and understood it.
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).
I use both GUIs and the CLI, bouncing back and forth all day long, using each for the tasks for which it's best suited. I don't think either is inherently better for all common tasks (and, of course, the CLI excels at many uncommon tasks which aren't worth coding a GUI for).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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!"
Find free books.
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.
May we never see th
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.
Friends don't help friends install M$ junk.
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.
Blogging because I can...
There are already a lot of replies to this post saying "no definitely not, OSS developers are all elitest ignoramuses" because it's easy to sound insightful when criticising, but really what they're saying doesn't stack up. It might have been right 3 years ago but the improvements made since then have been staggering.
A lot of software has been rewritten or redesigned with usability being core. Example: grip was deemed a lost cause as far as UI went, so Sound Juicer was written instead. XMMS was deemed fundamentally flawed so Muine and RhythmBox were written. Gnome has adopted a pervasive HIG and while it may have a few rough edges still it's arguably more consistent than both Windows (hands up if you read the Windows HIG - thought not) and even Apples (brushed metal or aqua - what mood is Steven in today?).
Today, if you want, you can get software that's had well thought through usability. That doesn't mean everybody uses it, but it's certainly available to those who want it.
Now, there are some big remaining usability issues in free software but these tend to be structural/architectural. For instance Linux software installation is frequently very difficult and it's not easy to solve without a great deal of engineering.
On Windows the GIMP user interface isn't anywhere near as good as on Linux, despite the GIMP 2 itself making great strides over the 1.2 release in absolute terms, the different (arguably worse) Windows WM model and UI paradigms aren't accounted for and there aren't enough Win32 Gimp developers to give Gimp/Win32 an excellently integrated UI. Or at least, not rapidly.
This is more a side-effect of the Gimp being most popular on Linux and the core developers all using Linux though, rather than any fundamental insight into the nature of open source. I've seen some pretty crap ports to Windows UI from commercial companies as well - for instance, the laughable QuickTime 4 which not only made zero effort to integrate with the host operating systems UI but also committed quite a few usability sins like the thumbwheel.
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...)
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.
This is one lame signature, please read the message above instead.
They have a pill for that sort of thing now, you know. Technical problem indeed.
Shop as usual. And avoid panic buying.
I started working at a company a few years back. When I got there, the developer had written an application to replace the users 'green screen' interface.
;)
The user where data entry where they never looked at the screen, much less the keyboard. we're talking about 100's of pages a day of entry.
This software engineer had created an application that was almost completly mouse driven. The tabbing wasn't in any order, you had to use the ouse to drop down to any option, to select were the document is sent to, etc...
They went from 100's of docs a day to dozens.
The software engineer always blamed the users, and said what he did was 'standard'.
I went in, fixed the tab order, and assigned keystrokes to all the options. The same keystrokes that had been used on the previous app.
It took me a week, when the engineer found out, he blew a gasket. Screamed at me, mostly at my back, since I don't tolorate that behaviour, then up to the Sr. Managment team.
When I got thir, he had them all convinced that I had broke the app, made it unusable, and it would takes "years" to fix it.
So there I am, looking at a Sr.VP, a Jr VP, and an HR person. I'm not stupid, I know what they had in mind.
The converstaion went like this:
VP: "Did you make all these changes to the application?"
Me: "yes"
VP: "did you consult the engineer?"
Me: "yes, he said that the mothod they were using was a 'standard'"
VP: "I think you may have stepped out of bounds"
Me: "excuse me, I need to use your phone."
[Calls the data entry manager]
"hi brenda, I'm here with some VP's, can I put you on speaker phone?"-"Great"
ME: "Brenda, what was the user average per day for document input before the new system"
Brenda: "About 700"
ME:"And what was it last month?"
Brenda: "about 80"
Me: "I see, and what was it last week after the new changes went in?"
Brenda: "I haven't finished the report, but I'd guess about 700"
Me: "Thanks Branda, that what I needed."
The VP excused me. later i the week I got a promotion to fill the former engineers position.
The point of this story? User interface is for the user. Give them what they need, to do what they want.
You should hire me, we could fight the good fight together.
The Kruger Dunning explains most post on
We need to be developing software that has an interface that is initially simple, but can be more complex if needed.
Slashdot is a pretty good example of this (no I'm not using it as a way to be moderated up). Initially you can simply use it for information gathering. Everything recent is one one page, the left hand column has the basic method of reducing the mount of information into simplified "Sections". As you may know, (or maybe not you may be a new reader here) you can reduce the amount of useless information by creating a login, and setting your preferences to see the information you want on the main page and limiting the comments you see on articles to those (for example) moderated level 3 and above. If you want to get more complex, try responding to articles and getting modded up. If you want more complex try getting submissions published!
Another example I have seen recently is Adobe Photoshop Elements which is picture editing software. I use primarily the first 4 menus of this software for my photos. My brother, an artist and an owner of the full version of Photoshop, used the first 4 and remaining menus when building the graphics for his website that I maintain on my computer. The simple items are near the front (to the left) and the more complex items are to the back.
A more embarassing example was when I had my Non-techie wife testing a new version of my brother's website I was building. I had put in some fancy Javascript tricks I found at Dynamic Drive to bring up larger pictures of the thumbnails within the same window to "simplify" the user experience. When she used these pages, she found them more complex and less useable because they were inconsistent within the realm of a web page. Needless to say I ended up ripping out all of the Javascript and creating 40 new pages to simplify the interface. My even less technical mother approved of the new site with the Javascript removed.
You can lose something that is loose, so tighten the loose item so you don't lose it.
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.)
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
The biggest reason why Windows has a definite edge over Linux in terms of adoption is because of its user interface for configuration. For example: In Windows, if I want to add something to my startup sequence, all I have to do is add it to my aptly-named Startup folder.
Poor user-interface design was what kept me away from using Litestep as my Windows Shell replacement I couldn't just drag things where I wanted them, but instead had to go in and edit some configuration file. Expose users to settings in different graphical menu systems - that's what they were designed for.
I myself know that I have a great sense of usability when it comes to wetware-software interaction (I, Robot reference ripped). It's unfortunate that I don't have all the necessary skills to help a project. Would love to do some free design/consulting work for a project, though, if I was taught how to do the whole design process.
...I am proof that intelligent beings are not always intelligent...
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.
Printing, for example. You should never have to "configure" a printer. When you try to print something, you should be offered a list of available printers. The system should find them. If the system doesn't have the tools to find printers, why should the user be expected to do it? Maybe you have buttons like "look for more printers", or "ask neighboring machines for help finding printers". But the user should not be typing in IP addresses or installing "drivers".
Yeah, this takes some programming work. But it saves the user work. That's the idea.
Making a subsystem robust, flexible, and easy to use is a very similar challenge to making a good user interface. Both are hard but not unsolveable problems--you just have to spend some time thinking before you rush to start coding.
While it's not good to design the UI last, it is possible to design applications with a hard wall between the "guts" of the application engine and the GUI--besides being a good software design principle, this allows multiple GUIs to be created, and would make it easier for people like you to contribute to OSS projects.
Another point that has been already made but needs reinforcing--artists are not designers! (and most "web designers" are not designers either) The GUIs at work that I've seen that were dominated by an artist are often worse than the programmer-designed ones--lots of pretty borders that take up valuable screen real estate, hand-built art bits to make every screen different from every other one in slight ways, button schemes that only work with four-letter text labels, etc, etc.
Anyways, if you want to perservere, and you have access to a Mac (as I think you might if you're an architect), is to install the developer tools that come with OS X (called Xcode in the current version). There is a tool called "Interface Builder" that lets you design user interfaces by dragging buttons around and making connections, that can actually form GUI prototypes that can even have limited functionality. If you made an awesome looking "dummy" application and put it up somewhere along with a well-thought out control flow diagram or other document, I bet some programmer might say "hey, that would be really cool if it worked" and add the neccesary code. Hell, I probably would! ;)
FLOSS is a really good development model when the software can be incrementally written in a distributed manner. Linux works because the majority of work in the kernel is in maintaining the drivers; small and independent chunks of code. Debian works because of packages; without packaging, Ian says Debian would never have succeeded.
Projects that require a big bang from a small group of people do sometimes occur with FLOSS but it's much rarer. And I think those projects are far less successful. The last example I can think of was the DRI; it took a small team of very dedicated people to invest a lot of effort before there was a result. The barrier to entry (the knowledge required to contribute) with the DRI is very high so progress is slow. It's not possible to just jump in and fix something small. You have to spend ages learning how it all fits together.
In my mind, the way to solve the "UI problem" with KDE and GNOME is to figure out how to break the problem into smaller independent chunks. Then just sit back and allow the distributed model of development take over. 1000s of programmers each contributing 10 lines of code has the same coding power as 10 programmers contributing 1000 lines each but it's only possible if the problem can be broken up into 1000 independent chunks.
Maybe UI design isn't one of the problems that can be broken up that way.
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.
The perception that all software should be intuitive and 100% usable the moment you unwrap the shrink-wrap is an incorrect one & has been created as a result of heavy over-marketing by commercial software vendors in order to generate more sales.
Sure, I accept that if Joe Bloke buys himself a digital camera, he wants to load some software from a CD on his Windows machine, plug his camera into the USB port and start downloading his images to his PC for editing.
But the fact is that the majority of normal users still believe the hype that when you buy a PC, it's no different to buying, say, a TV where all you do is just switch it on and it works. There is no mention by the PC salesman of having to perform regular defrags, keep the OS updated, update virus checkers, install firewalls, etc.
Just because a piece of software takes some time to familiarise oneself with, does not mean that it is unintuitive - if anything, results are far more rewarding when one has put in a little effort to achieve them.
The UNIX/Linux command line philosophy, for example, is frequently targetted for "lack of usability" complaints. However, the fact is that taking the time to understand what programs are on a UNIX system and how to bolt them together in things like shell-scripts means that some very repetitive and boring tasks can be completely eliminated very quickly.
The Open Source movement is not about trying to compete with, or displace, Microsoft - it is simply about doing the right thing which means sticking to open standards that all of us can enjoy (rather than closed standards that we pay a subscription for). Therefore, the creation of cohesive GUIs for software is not the prime concern of the OSS community, albeit that the same are receptive to feedback from users of their software.
Commercial software vendors have to make profits which means listening to their users and rushing their software out to the marketplace - therefore, in the case of Windows software, those same vendors will use the Windows GUI libraries for their software, cutting down on development time and fitting in with the Windows "look & feel".
I'm not denying that OSS software is viewed by some as "difficult to use" - but this should be taken into context that OSS demands a degree of responsibility and time commitment from each user to learn how the software works and to feed back into the developers what the user perceives to be problems with the functionality or layout of the software.
Gentoo Linux - another day, another USE flag.
Because Ctrl+C/X/V may interfere with the console app inside the terminal. Come on, is it that hard to understand?
I like to think I've got enough theory in my head to have a good whack at user-interface design, but of course I'm not going to claim to be an expert. There are two main skills we need for user interfaces in open source software:
The second of these is the easier of the two, and I think most people can make some constructive comments about the pros and cons of a user interface designed by someone else. The first item, however, is the hardest part. To start from scratch like that requires quite a lot of background, and while some developers make a reasonable stab at it, usually by responding to how other developers handled a similar situation, that can't work for all cases.
Until such a time when we have qualified UI engineers contributing to open source projects, I think it's useful to increase the feedback between the two tasks above. The original developer uses some simple UI background to design an initial interface, then throw it to other developers and interested users and invite feedback on the interface specifically. The developers, in their role as developers, will probably point out some inconsistancies with the simple rules they have learnt, but the developers can also take the role of users and see what they find hard to do in the software.
Once that is fed back, the user interface can be refined just like the rest of the software until it's good to go. This refinement process works for the innards of the software, where perhaps the set of people able to make good comments is smaller, but everyone can have a point of view on a user interface because everyone knows what they are trying to do and what's obstructing them from doing it. Of course, we have to remember not to go overboard as some goals will be more "common" than others, but we make decisions like this in software design every day so applying similar priorities to the UI suggestions should come naturally to any seasoned open-source developer.