Software Usability As A Technical Problem 551
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.)
not really (Score:2, Insightful)
Expanding market? (Score:5, Insightful)
Re:not really (Score:2, Insightful)
Moo (Score:5, Insightful)
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.
Not just "technical" (Score:2, Insightful)
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
Re:not really (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Artists aren't necessarily usability experts... (Score:5, Insightful)
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 (Score:4, Insightful)
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 (Score:2, Insightful)
The desktop is not the problem.... (Score:2, Insightful)
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... (Score:2, Insightful)
Until people start taking human factors seriously (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
We use the users in designing (Score:5, Insightful)
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 (Score:5, Insightful)
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... (Score:4, Insightful)
Re:not really (Score:5, Insightful)
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.
Maybe we should be taking hints from games. (Score:5, Insightful)
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 (Score:2, Insightful)
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 (Score:4, Insightful)
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:Expanding market? (Score:5, Insightful)
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:Evolve (Score:5, Insightful)
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.
Consistency vs. Flexibility (Score:4, Insightful)
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 (Score:3, Insightful)
Re:not really (Score:5, Insightful)
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:Moo (Score:2, Insightful)
The average developer knows zero about good ui design. The average user knows less than that.
Consistency (Score:3, Insightful)
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:not really (Score:5, Insightful)
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:Usability (Score:4, Insightful)
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 (Score:2, Insightful)
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.
Open Source still has a long way ahead... (Score:2, Insightful)
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:Moo (Score:2, Insightful)
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:Yes a technical problem, but of different natur (Score:5, Insightful)
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 (Score:1, Insightful)
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.
Re:not really (Score:2, Insightful)
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:Moo (Score:5, Insightful)
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 [useit.com]? "We Don't Need Usability, We Already Listen to Customer Feedback" (at the bottom) [useit.com].
Maximise "discoverability" (Score:1, Insightful)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:2, Insightful)
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.
Re:KDE, Gnome, Linux... (Score:4, Insightful)
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 [greenend.org.uk] 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
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
D'oh - dumb article, solveable problem (Score:5, Insightful)
Ten things you can do to make your program at least tolerable for end users:
Re:usability problems aren't just technical proble (Score:3, Insightful)
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:Consistency (Score:3, Insightful)
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:not really (Score:2, Insightful)
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:Yes a technical problem, but of different natur (Score:5, Insightful)
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 (Score:1, Insightful)
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? (Score:1, Insightful)
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 (Score:3, Insightful)
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 ? (Score:4, Insightful)
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 (Score:3, Insightful)
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 (Score:5, Insightful)
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.
Re:Yes a technical problem, but of different natur (Score:3, Insightful)
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 (Score:1, Insightful)
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 (Score:5, Insightful)
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:not really (Score:3, Insightful)
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:Usability (Score:4, Insightful)
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 (Score:4, Insightful)
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 (Score:3, Insightful)
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 (Score:3, Insightful)
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. (Score:3, Insightful)
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 (Score:3, Insightful)
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:Graphic designer != user interface designer (Score:2, Insightful)
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:Until people start taking human factors serious (Score:3, Insightful)
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:We should be able to solve this (Score:3, Insightful)
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:The real issue at stake here? The File System. (Score:3, Insightful)
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 (Score:4, Insightful)
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.)
Re:D'oh - dumb article, solveable problem (Score:2, Insightful)
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 [cs.tut.fi], 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 (Score:3, Insightful)
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.
** Users should not design UI ** (Score:3, Insightful)
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 (Score:3, Insightful)
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 (Score:2, Insightful)
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 (Score:1, Insightful)
-Adam
Re:not really (Score:3, Insightful)
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 (Score:1, Insightful)
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.
Re:Expanding market? (Score:3, Insightful)
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.
There's no such thing as 'intuitive' (Score:3, Insightful)
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 (Score:3, Insightful)
Re:Expanding market? (Score:3, Insightful)
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.
Re:Getting rid of "configuration" (Score:1, Insightful)
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.