How To Fix the Poor Usability of Free Software 690
flosofl writes "Matthew Paul Thomas has an entry on his blog called Why Free Software Has Poor Usability, And How To Improve It. While this advice is helpful and may indeed lead to improvements in many open source programs, the guidelines may be much more difficult for smaller projects. From the entry, 'Free Software has a long and healthy tradition of "show me the code." But when someone points out a usability issue, this tradition turns into "patches welcome," which is unhelpful since most designers aren't programmers. And it's not obvious how else usability specialists should help out.'" Thomas has been developing the ideas in this essay for years. The critique is comprehensive, listing 15 challenges in the way software projects, and in particular free software projects, are structured, with suggestions for improving each one.
Really a matter of taste... (Score:3, Insightful)
RE: Usability of Free Software (Score:2, Insightful)
You need to fix yourself first (Score:3, Insightful)
i use a lot of free software that has very good usability. there is nothing different in selecting free software than selecting paid software - buyer beware.
It is the thought process (Score:4, Insightful)
UNIX programmers (the majority of FOSS developers) design software the way that they would want it to be used. It makes sense to other programmers and it is actually probably the simplest way to operate if you have the base knowledge. Users, on the other hand, focus less on the architecture of the software they are using than on the front end. Windows and Mac OS X systems and applications are easy to use because the front end has been designed to meet all usual purposes, even if it cuts back on the functionality. Linux and most UNIX systems and applications are harder to use because they are built with the architecture of the code in mind. A good UNIX program can easily work with other UNIX programs, and a good UNIX program is made as general as possible to maximize speed and reduce bloat as the program advances. A 'good' Windows program is made for only one cycle, not the entire development lifetime. Firefox is a good example of a program that meets both the UNIX and the Windows definitions of a good program. But Firefox is very rare, and there have been multiple revolts over de-generalizing the code for a single release.
I think application programmers should keep the Firefox success in mind when they develop code, even though it will be much more expensive and time consuming than the UNIX mentality since they will have to keep stopping what they are doing to release and polish versions for users (essentially dead forking every couple of months).
Re:Usability is a matter of opinion (Score:5, Insightful)
I'm going to take issue with this. Basically you're saying if you can't do X, then your critique is useless. Just because you can't sing doesn't mean you can't critique other people's singing. Just because you don't know how to make a car doesn't mean you can't critique that horrible dashboard layout.
Re:Usability is a matter of opinion (Score:5, Insightful)
Okay, I know these are unpopular things to say, but I feel they need saying. These are just my opinions.
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing
things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the software in question.
It seems you've never used emacs, little one.
And no, it doesn't say more about me than the software if I find that almost all GUIs in Linux are shit and that the command line is more usable.
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
"Right."
And neither have "coders" who can't "design" something the "average" "user" "thinks" is "usable" .
Re:Usability is a matter of opinion (Score:5, Insightful)
Bull crap. An architect doesn't build the building, the carpenter does. An electrical engineer working for the power company doesn't hang the lines, but they layout and design them.
The same thing can go for almost any profession, software included. I don't code and no desire to code (I'm a chemist and have no interest in that part of computing), but I can tell you when the interface sucks and what could be better.
My opinion is, people who won't accept criticism from others because "you don't code," or "you don't know what you're talking about" are nothing but elitist.
Read Gruber's post too (Score:5, Insightful)
At the bottom the article links to John Gruber's "Ronco Spray-on Usability" [daringfireball.net] article, which also provides a lot of background on the challenges of good interface design.
In the original article, I think the most important point is number 8 - "Scratching their own itch." I can see how programmers interested in, for example, having a stable and scalable web server would work on Apache. I don't see the same passion coming from a human interface designer to fix, for example, the horrible user interface for joining wireless networks on desktop linux.
In my opinion the only way the user interface will get fixed is if Ubuntu or another distro pays for expert user interface folks to fix UI issues. I don't see the volunteer community being up to the task.
Re:Usability is a matter of opinion (Score:5, Insightful)
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
Why should software be different from any other industry? Just because the barrier to entry is, in your opinion, lower? The people who design houses don't build them. Sure, they need a solid foundation in what can and can't be done, but architects and interior designers work to a mutually beneficial end with builders, carpenters and plumbers, etc.
Re:Usability is a matter of opinion (Score:5, Insightful)
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing
things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the
software in question.
You are a good example of the "works for me" mentality in the open source software community. "If it works for me, then it must work for anybody else, and if it doesn't, it's their fault".
(2) "Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should
work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
I'm sorry, what? Did you just say that if designers can't code, they shouldn't contribute? I thought this open source stuff was about the fact everybody could contribute to the program if they wanted, but apparently I thought wrong. Apparently only uber-geeks with a masterful command programming knowledge can work to improve open source software.
Design is important. Not everybody wants to learn the idiosyncrasies of software; they want it to "just work". The moment everybody thinks that way is the moment open source software gets better.
Few Good Designers (Score:4, Insightful)
Re:Usability is a matter of opinion (Score:5, Insightful)
Re:Usability is a matter of opinion (Score:5, Insightful)
You seem to confuse usable with usability. Just because something can be used, doesn't mean it is the best option. By your logic we would all be using rocks to pound nails because, "It works, you just have to think a little bit." Being intuitive means that people want to use it that is the point. Unless of course you don't want people to use your product and if that is the case, why are you publishing it publicly?
Your second point is rather funny to me. I wonder if you would say, "If someone doesn't know how to design an engine they have no business designing the rest of the car(oblig. car reference)?" People have specialities, that is how society works now.
Finally a red herring [wikipedia.org] is irrelevant, we are talking about Linux not windows. I don't really like windows either but that is another discussion.
Re:Usability is a matter of opinion (Score:5, Insightful)
1) "Usability" is in the mind of the user.
There's some degree of truth in that, but since most people have essentially similar minds it makes sense to assume that certain types of operation make sense to the vast majority of people. Past experience can lock people into a certain conceptual mindset, there's no denying it. But the holy grail of usability is that which most closely reflects the way in which we have evolved to think.
All computers are essentially tools to enable us to do things we otherwise would not be capable of, or would take much longer without. The best computer systems are the ones which interface as organically as possible with that which we are capable of. It's common sense.
(2) "Designers" who can't code have absolutely no business "working" in software.
That's ridiculous. If it weren't so absurd it would be offensive. Look at the credits for any major software release from the commercial realm. Let's take games, for example - in the entertainment industry, where if something is not 'usable' it is not fun, coders are outnumbered somthing like 20 to 1 by other types of developer, be they writers, artists, testers, etc. Hell, let's take the credits from GTA IV, the video game. They take HALF AN HOUR to scroll, when you complete the game. What percentage of those HUNDREDS of people do you think can code? Even to a reasonable level? Five to fifteen percent at the outside.
When you need a job doing, you hire the person with the skills to do that job. You DON'T hire someone with the skills to do that job AND the skills to code. Sometimes that's not even desirable, and at best it's overkill.
Re:Really a matter of taste... (Score:1, Insightful)
What?
An Apple is more usable than Windows or Linux.
BeOS was superior to Windows and Linux.
AmigaOS was superior to Windows and Linux, as well.
Stop with the fucking "MS" comparison.
Almost all Linux programs try to copy the "MS" way and they even fail to do that properly and that's why people think they have poor usability.
Make the GUI simple to navigate so a 3 year old can handle it and powerful enough so a geek can enjoy it.
And quit whining when someone criticizes free software.
Re:Usability is a matter of opinion (Score:1, Insightful)
No, it isn't, and it's obvious you didn't RTFA.
There is no valid "opinion," none, which holds that windows should appear with low-contrast text and UI elements, or that they should appear hidden behind things (the Dock, for example), or that they should default to a size too small to show their contents.
Regardless of whether you'd like to admit it, a great deal of usability concerns are objective, and a lot of "organic" software violates a number of ground rules.
Re:Usability is a matter of opinion (Score:3, Insightful)
How did the architect respond to your suggestions for improvements?
Re:Really a matter of taste... (Score:5, Insightful)
What? An Apple is more usable than Windows or Linux. BeOS was superior to Windows and Linux. AmigaOS was superior to Windows and Linux, as well.
That's your opinion. I personally find Mac OS harder to use than either Windows or Linux, simply because of what I'm used to. Which is exactly the point of the grandparent post.
Make the GUI simple to navigate so a 3 year old can handle it and powerful enough so a geek can enjoy it.
Good luck with that. It often happens that if something is easy for beginners, it's not so convenient in the long run for experienced users. For example training wheels in bicycles. A good UI lets you remove the extra wheels and tinker under the hood, though.
No it isn't (Score:5, Insightful)
Humans have overall tendencies in what they find easier and harder to use. For example most people find it much harder to memorize lines of commands than to look through a set of icons, hence one of the reasons why GUIs are popular. There's real empirical research that has been done on this, some by psychologists, some by companies like Apple. While you may fall outside the norms for various reasons, that doesn't mean they don't exist.
You also need to be careful in thinking that because you've taken the time to learn something, that means that it is easy. For example I drive a manual transmission vehicle. I have no problems doing so, it is second nature to me, no more problematic than an automatic. However, I am not going to say it is as easy. I remember a rather frustrating learning period when I was getting used to the feel of a clutch and how to shift. It is easy now, but only because I have a lot of experience. It is NOT an easier way of doing things.
I find this kind of thing fairly prevalent in the OSS world. You'll need to do something and someone will say "It's easy!" and then give a couple commands to run. To them, it does seem easy, because they've trained themselves on it, however that isn't. To a new user that's very hard and uninviting.
Ignoring this issue doesn't help free software. Telling people "It is just as easy you just have to learn it," when it isn't doesn't help, they'll just ignore you. The author is trying to say that OSS people need to stop with this attitude that it is just as usable, or that usability doesn't matter to popularity. If you want OSS to start to become the dominant way of doing software, you have to make it as easy to use for the non-technical masses as possible.
usability != "make it pretty" (Score:2, Insightful)
Just because you've made it pretty doesn't mean it's usable. You can't build a bug-free product and then just slap on "usability" at the end--it doesn't work that way. You have to iterate through designs and test your product with users along the way while you're designing the entire system. Good software design is more than just making a UI that people like, but it's designing the entire product in a way that's intuitive for beginners and enabling for advanced users.
Re:Usability is a matter of opinion (Score:4, Insightful)
(1) "Usability" is in the mind of the user. If you learned how to use some other system first and now expect that any other way of doing things isn't "usable" enough, that's just plain old resistance to change. It says more about you than it does about the usability of the software in question.
That is of course true if you are talking about design by the decree of an individual, but that is not "design" in the way most practitioners define it. The currently accepted approach is User Centred Design [wikipedia.org], which basically means that the cumulative indications of many target users are derived through various research techniques. The outcome of this research is modulated by the designer in coming up with the design, but fundamentally, the designer's own opinions are irrelevant.
The upshot of this is that (for example) if a CLUI is found to be the way to go, then a CLUI is shall be. If it's voice-control the users need, then that's cool too. Notice I said "need" there, not "want." Here by dragons.
Re:Usability is a matter of opinion (Score:5, Insightful)
Why is "patches welcome" a bad thing? (Score:5, Insightful)
There seems to be a whole movement who's against the "patches welcome" statement. I fail to understand this.
I'm an open source developer. Look at it from my point of view. I've written software that people find useful. It's not perfect, but it's useful. Then, one day, someone criticizes my software:
Person X: [...] this and this sucks [...]
Me: patches are welcome
Person X: what? what an unhelpful response! no wonder open source sucks, and you suck too!
Now, tell me. I have a job. I maintain this software in my free time. Why should I devote that time to you, for free, instead of, say, hanging out with friends or seeing a movie? You're not paying me for this software. You probably would go away if I ask you to hire me. What exactly do I owe you? I already made the source code available. Why do you criticize me for not working for you for free? Why don't you do it yourself, or hire someone to do it for you? If you can't do either of those, why don't you contribute documentation, mockups, or something else that's not technical but is still useful? Do you expect a baker to give bread to you for free when you criticize his breads for not being tasty enough?
Re:Usability is a matter of opinion (Score:3, Insightful)
Could be fixed (Score:4, Insightful)
People just need to become willing to pay for free software. The problem is right now, most people, even the OSS heads on Slashdot, aren't as interested in free as in speech but more interested in free as in can I crash on your couch. There is this real resistance to paying for open source code. I don't mean things like enterprise support contracts, I mean paying for a copy of software as is done in the commercial software world. Even when it has been tried, it doesn't go well. Look at Sveasoft, for example. They wanted to modify the Linux based Linksys routers, and sell their modified software. However they didn't sell much, because people bought it, recompiled it, and then distributed it for free. This is all perfectly legal per the GPL, of course, but you can see how an attitude like that makes it very hard to sell free software.
Well, if that attitude changed, I think perhaps more groups would be willing to work on it. You could hire designers, artists, etc to work on a project because it is something you could use to generate money. You'd still include the code so people could modify it to their heart's content, however you'd understand that most people were going to pay you if they used it.
Unfortunately, I see a lot of resistance to that. It seems that most OSS people think software shouldn't cost anything every. Well, with an attitude like that, it is going to be more of a hobbyist pursuit.
Re:Usability is a matter of opinion (Score:5, Insightful)
In my experience, most of the people who complain about these sorts of things do so because the new app lacks some key feature that makes their workflow better. Dismissing someone's opinion simply because they have actually used similar commercial software is stupidity, as it means you are unable to gain wisdom from the study of designs that have come before yours. In fact, it is precisely this mindset that causes user interfaces in free software to almost invariably suck---the whole "this is the way we do things, and you'll just have to get used to it" mentality does not lend itself to learning. I'll probably get modded down for saying it, but it's worth burning the karma if it gets people's attention.
Couldn't disagree more. I would argue that most UI designers have no business coding any more than most coders have any business designing user interfaces. The two skill sets are very different, with very little overlap either in knowledge or in the mental structures used in performing the two tasks. Good UI design is more closely related to software architecture, not coding. You have to figure out how best to lay out a user interface based on careful study of what the user is likely to want to do, careful thought about what things a user is likely to group together as similar operations (menu layout), and careful study of actual users to watch their workflow followed by probing interviews to find out what worked well and what didn't. It is basically scientific in nature. Software architecture is the same way. You're looking ahead to what the coders might want to add, what features the users might want, etc. and designing the overall architecture to accommodate those future needs.
Coding is a different skill set entirely. It focuses on knowledge of what types of methodical steps you have to achieve to reach a goal. Software architects and UI designers are the architects where coders are the construction workers. Expecting UI designers to code is no less silly than expecting your architect to be proficient at hammering nails into boards to build a wall.
Further, a strong case for the separation of those elements is the Mac design model. You have a separate Interface Builder application (well, it's part of Xcode now, IIRC) that gives people the ability to design the UI without writing a single line of code. Then, coders can come in and hook that functionality up to the underlying code. By doing that, it not only allows people to focus on the things that they do best, but also makes it much easier to modify the UI because you can create it visually instead of messing around with programmatic drawing that constantly puts UI elements in the wrong place. I get the impression that some Linux developers do the same sort of thing with Glade, but I've never used it, so I can't draw any real comparisons.
Trust me, getting UI designers to write code is the last thing you want to do....
Re:Usability is a matter of opinion (Score:4, Insightful)
Your analogy doesn't follow. Better would be:
"How did the carpenter building his own home respond to the (voluntary) suggestions of a professional architect?"
...but that doesn't have the air of such a witty retort, does it.
Who decides how the code works? (Score:3, Insightful)
I'll point out an example from the world of software synthesisers. Take a look at Rob Papen's Blue, Albino or Predator. They are excellent synthesisers. The point is, Papen is the sound designer and the synthesisers are designed so as to facilitate his designing of the vast collection of factory patches for them (based on what's possible of course.)
In the world of Free Software, things are very different -- those who can design the user interface are not strongly listened to when designing how the user interface libraries should work. Basically, a programmer writes what he/she thinks is good enough, other programmers join in, but when the designer's requirements run contrary to the original direction of the code, resistance is met. This is a major problem, since those most capable of designing effective user interfaces don't get to do so, and those more suited to the coding side of things have to do make-shift user interface designing according to their ideas of how a user interface should work or what is easy to code.
Free software companies should take time to stand back from the process, ask the question: what are we trying to do? and what is the most effective way to accomplish those goals? The problem is that it is effectively beyond the power of an individual person in the free software world to influence things unless they have sufficient time and expertise to code examples of what they want.
Agree But Not Limited to Open Source (Score:3, Insightful)
Agree with this point: "Coding before design".
As an UI developer (at least part of the time) at a major software company, I see this pitfall even in my own work. A lot of us are more concerned about coding up the UI to expose the new features but that's where we stop. OK new features is exposed, on to the next one! Then the UI designers come in and suggests all these changes and we end up undoing a lot of the work we did before. It's such a waste of time. This is a mistake we've learned and look to correct in our next version's development cycle. Sometimes it makes sense to develop software from UI on down because at the end of the day, it's the user's experience that matters, not necessarily how clever or elegant the inner workings of our software is (this does matter in the long run -- a good foundation allows us to make changes and add things quickly).
Another pet-peeve of mine is explaining to the UI designer that we can't do something because of engineering problems when what the designer is suggesting is simple. A rule of thumb of mine is that if the suggested UI interaction/function is simple then the amount of effort to make it happen should also be simple. If it is not, then something is wrong with the UI framework.
Good UI is in some ways a lot harder than what people might expect. It's really a multi-discipline field that takes more than just a good engineer. It requires a good psychologist (one of our UI designers was a cognitive science major) and a good writer. We learned so much about our UI design from filming people using our product and watching their frustration. This was an expensive process in both time and money. I can see a company being able to do this but it's considerably harder for an open source project, especially a small one without a lot of resources. Bad UI design happens everywhere but it seems only software companies and major open source projects have the dedicated resources to fix it. Like the article said, it's a high bandwidth process; people need to be together at the same place to discuss these things and it takes hours as you can tell from my own submission to Ask Slashdot [slashdot.org].
Re: Usability of Free Software (Score:3, Insightful)
I fail to see what any of this has to do with socialism. What you described constantly occurs in the free market. It is called "commoditization".
Re:Really a matter of taste... (Score:5, Insightful)
I'm not sure I agree with this, but there is a definite confusion in most people's minds between easy to use and easy to learn.
Vim is incredibly difficult to learn, but is actually very easy to use if you can learn it. A lot of programmers using an editor for extended amounts of time have found this to be the case.
The problem with Microsoft stuff is that it's pretty easy to pick up and use. But once you've learnt how to do it, you often want command line tools to start scripting and batching work. Generally with MS, and to a lesser extent Apple, you find you can't do that.
Excel is the only Microsoft software I've used where I found it did everything I wanted as a power user. I think it's one of the very few examples of something both easy to learn and easy to use.
Re:Usability is a matter of opinion (Score:3, Insightful)
I wonder how many 'designers' who 'can't code' are employed by Apple to 'design' their user interface without 'coding' it. We'll never know exactly, but I suspect it's quite a few, and the Apple is the one to look to as an example of how it's done properly. (Sure there are many places where it can be improved, but there is less room for improvement in the Mac OS than on either Linux or Windows.)
Personally, I was driven to Linux by frustration with Windows, and to the Mac by frustration with Linux. I've experienced all three, still run Linux a bit, but when it comes to getting things done, I use the Mac. Linux must catch up if it wants to be competitive.
Re:Really a matter of taste... (Score:5, Insightful)
I also find that most people don't really know what they want. It's usually after a fairly long period of using something, when people start to understand what's specifically wrong with the application. By that time they're used to its idiosyncracies, and it won't help them to make the application easier for beginners.
Have you heard of usability testing?
Believe it or not, there are people who make a living figuring out that kind of thing. Obviously people can disagree about what's best, but you and the parent post seem be saying that usability is a lost cause so there's no reason to even try.
This is a case where the perception is the reality. If the audience for your app has a hard time figuring out how to use your it, it has poor usability, whether you accept it or not.
Re:Usability is a matter of opinion (Score:5, Insightful)
Your high horse is showing. :) If you don't like my GPL'd interface, you are free to design one of your own and hire someone else to code it for you, if necessary. FOSS does not mean, "anything you want, gratis!". It means if you don't like something you have the freedom to change it. I have little respect for those who use the word "free" as an excuse to try to hold up developers with their limitless opinion-based suggestions. Some projects are very open to user suggestions, others are very tied to following a well-defined vision. Neither model is "incorrect". No-one is forcing anyone to use any GPL software "as-is", that's the whole point. It's not so you can get your way while contributing nothing but opinions. Though occasionally you may get lucky like that. :)
Re:Usability is a matter of opinion (Score:1, Insightful)
Speaking from experience...
If you open the door for design suggestions to non-programmers, you tend to get a bazillion responses, most of which are complete rubbish.
With code, there is a natural barrier to entry as well as a natural test of the quality of the submission. With interface designs there is no such barriers and it seems every other user fancies him/her self usability expert.
And then, when you don't do what they want, they start to hate you.
Re:Usability is a matter of opinion (Score:5, Insightful)
The command line in Unix is more "usable" because it is older, more mature,
has more features and flexibility, and is more easily extensible. I can
augment a GUI with a few lines of shell scripting with considerably less
effort than it would take to "fix" the given GUI application.
I can make some shell script both easier and simpler than just about
any GUI application and tailor it to my own needs so that it most
closely meets my needs (and thus meets my own personal notion of
"intuitive").
That said, there are still Unix/Linux GUI applications that are
more functional, simpler and easier than their Windows/Mac
counterparts that we're supposed to be cloning. The "chasing
tail lights" criticism is a very good one in this respect because
sometimes neither of the allegedly "better" platforms do it right
or better.
At this point, it's no longer a given that the Mac or Windows version
of some GUI for some sort of app is any better.
Improvement of Linux GUI's should not be limited by what Mac or Windows
applications do or what design dogmas they follow.
Re:Why is "patches welcome" a bad thing? (Score:5, Insightful)
And which craftsman works for you for free? If a craftsman gives something to you for free, do you expect him to do more work for you for free?
If you're paying me, I'll listen. If not, it's up to me to decide whether I want to care. I also gave you the choice to do it yourself, or finding someone else to do it for you. A choice that you didn't have in the first place.
Re:Poor usability? (Score:1, Insightful)
Ease of use, and ease of learning are two very different things, please do not confuse the two.
Speaking of usability (Score:3, Insightful)
I just wrote a detailed comment and previewed. I noted at the end that it was saying I was not logged in, so I could log in or post as anonymous coward. So I clicked the login link, logged in and boom -- the long comment was erased.
The pre-javascript interface probably would not have done that.
Short summary of longer post:
1) He dances around but misses one other scenario. The designer knows the right UI, but it's harder to code, and so chooses to do a lesser but workable UI to have more time to code other things. The problem is the coder is also the "funder" and makes decisions based on how hard things are to code, rather than what's best for the users.
2) It's a false economy sometimes. Why do we write free software? I would hope part of the goal is to make code that lots of people will use. Yet sometimes we choose to work on a feature that will please 10% of our 10,000 users rather than a UI that will make us accessible to 100,000 users.
Re:Why is "patches welcome" a bad thing? (Score:5, Insightful)
I care. I usually respond to criticism by improving my software. But come on, don't you think it's getting ridiculous when people take this for granted and demand that you work for them for free?
"That's understandable, if a bit anti-social, but it's part of what keeps so much open source software from being commercial quality."
So it's anti-social not to work for complete strangers, for free? What is in it for me if the software is commercial quality? I'm not getting paid. How am I suppose to buy my next meal if all I'm doing is implementing requests from users, for free? Have I no say in these matters any more?
Re:Usability is a matter of opinion (Score:5, Insightful)
I wouldn't go so far to say that a critique is useless, but there is truth in his statement. A lot of usability problems are not just where you place the buttons, but they are much more deeply down in the code structure. Take Gimp for example, one of my issues with it is its lackluster animation support, you of course can try to polish the GUI a bit, but the real problem are much deeper down into the code and need to be fixed there first before you can even start to think about a proper GUI, same is true for a lot of other issues.
Usability in the free software world is simply not just an issue of GUI, but goes down through all layers of the code, since after all, they have to be usable too, both by developers and users. Tackling the GUI is all nice and good, but it really is only a small part of the whole picture.
Re:Read Gruber's post too (Score:5, Insightful)
I agree that the community is not up to the task. However, I suspect that we are not talking about the same community.
Let's say that tomorrow I posted an improved layout design to the trac. Descriptions of the various elements, mockup images, UI icons and elements, new error messages, the works. What are the odds that it gets implemented? Seriously? I can't program, but I do decent layout and usability. From my own experience and that of others I suspect that I could post mockups and suggestions on the trac and forums until I am blue in the face.
Even if an entire squadron of UI specialists descended on a linux distro, went through the whole thing and posted up a unified UI design for every level of the system do you really think it would get implemented?
Let's be honest, there are always a million posts and bug reports floating around saying things along the lines of "I'm a regular user who tried to use X feature/menu. It didn't work well because it is missing A,B and C options, and D, E and F are in the wrong menu". If the linux/free software community had any track record of responding to those with 'well, I guess that needs to be fixed' instead of 'read the documentation/use commend line workaround with -r hfg blarg whatamidoing +7' linux would be a better experience than OS X by now.
Re:Why is "patches welcome" a bad thing? (Score:3, Insightful)
More charitably, perhaps the parent poster is not a bondslave to self-righteous and ungrateful whiners.
Usability is not even CLOSE to the problem. :( (Score:3, Insightful)
It's one simple concept:
There are two ways in which software is built. The business way, and the open source way.
The business way is driven by the target of making money. So they try to appeal to everyone. This usually (wrongly) leads to making it as easy as possible, so everyone can use it.
Then there's the open source way. This one has no interest in money, so the creators add, what they like to have in the software. Now usually these are computer professionals, and because they built it, of course it's perfectly usable for them. Unfortunately this means it's very hard to use for non-professionals.
Both ways have their flaws for those that are not in the target group. But they emerged naturally.
The solution is, to let everyone grow to his own level of expertise in the program. We need a program that starts out being as easy as it gets, but grows with your involvement. (=if you work more with it.) Something like difficulty modes in games. Just it's not the difficulty. It's the shortcuts, the special view modes, the application layout, the shown controls, the wizards, and so on.
Of course you can always set that level yourself.
Think of vi, in notepad mode, then gradually growing to emacs if you like. ;) (o boy, i'll get killed for this... hint: i like none of those 3 editors because of the problems mentioned in this post. ;)
The best thing about it: You can make the Gnome people AND the KDE people happy. Oh, and the console/magnet/butterfly people too :)
Re:Usability is a matter of opinion (Score:5, Insightful)
The command line in Unix is more "usable" because it is older, more mature, has more features and flexibility, and is more easily extensible.
And also because all these Computer Science / Physics / Engineering graduates that argue how easy is to get things done with a shell so conveniently forget the amount of time they dedicated to learn how to use a shell.
I am personally (much) more comfortable using zsh than any GUI for manipulating files, or other tasks. But what most people tend to forget is that there is a much larger pool of users that are not willing to memorize 200 commands, and read man pages for days and days in order to just use their computer.
Re:Usability is a matter of opinion (Score:4, Insightful)
If, on the other hand, you can find a way to improve it, I'm sure many people will welcome your advice and implement it.
Agreed. Just telling a programmer that their software isn't usable isn't very constructive. Often times, they already know that, they just don't know the best way to fix it.
One good, non-specific way might be to offer to write an article including a basic set of guidelines for a popular site - say linux journal or linux magazine. Or where ever you think it might come up nicely in a google search, for that matter.
I realize that this might not be a motivation for those who want an immediate return for their efforts - who want specific software X to be more usable - but you never know. Maybe someone who's currently writing software Y, that you've been dying for, will take your advice and make their software contribution that much better.
I suppose what I'm trying to say is that a lot of programmers - myself included - would love it if usability experts would devote some of their time and effort into making our own time and effort more worthwhile to the end users. Heck, even if they don't consider themselves an "expert", if they think they have a few ideas on what would be better, it'd be much more appreciated than a simple comment about how something "sucks".
Re:Why is "patches welcome" a bad thing? (Score:3, Insightful)
Why "Usability" doesn't matter (Score:3, Insightful)
Here is an explanation of why "Usability" doesn't matter.
People forget the other SDLC, the software DEPLOYMENT life cycle.
People also forget that "Usability" means something totally different to novice and experienced users.
The only people whom have a 30 minute SDLC (software deployment lifecycle) is
1) Magazine/Blog Reviewers
2) Usability guinea pigs
3) Usability critics
Completely absent in this list is the actual software users.
Not surprisingly the 30 minute wonders are not going to get along with long term users, and the developers are usually long term users.
Besides, there is a dumb hidden assumption in the computing world that no one wants to discuss is that there should only be one level of user sophistication that all tools should aspire to.
Other fields do not have that problem... For example a CNC milling machine, at least for the first 30 minutes, is much less usable than a blacksmiths forge. Oddly enough we don't have to suffer thru pompous claims about the superior user interface of hammer, tongs, and forge.
Basically the marketing folks are becoming irrelevant and they are pissed about that, hence ridiculous claims against the enemy, etc.
Maybe it's just me... (Score:3, Insightful)
...but I find most of the "ugly" usability problems I find aren't fixed by rearranging some buttons. I think there's plenty competition (Ubuntu, Red Hat, Suse, Mandriva etc etc) on adding those last bits of paint and polish. For example I've struggled endlessly with x11/xorg.conf in the past to get the resolutions right. I don't really care how you implement the resolution/refresh dialog, 99% of the hard work is making something that works so easily. Oh yeah and my dual screen setup still doesn't work right, had to give up on that. Getting Linux to recognize and map all the buttons on my mouse was another one, it's not the UI it's the core system behind it. One funny case I had now with another computer with two soundcards (built-in that doesn't work in Linux + audigy) is that the cards will randomly swap id on boot so I have to fix the sound setup 50% of the time. Very very fun. Taking a solid product and making it usable for a big audience = $$$. So I'm not worried, just get the base in place.
Re:Usability is a matter of opinion (Score:2, Insightful)
Re:Usability is a matter of opinion (Score:3, Insightful)
No, that's not criticising without being constructive, that's just insulting. Just because somebody doesn't tell you how to improve, it doesn't make the criticism invalid. It's perfectly possible to offer constructive criticism without suggesting solutions. Your attitude is typically held by people who don't want to be told they are wrong. It's an easy comeback to ask somebody else to do your job, but it's no excuse. If a critic points out that an interface is confusing, it's the designer's job to fix it, not theirs. Just because the critic isn't a designer themselves, it doesn't make the interface any less confusing.
Re:Read Gruber's post too (Score:3, Insightful)
The "scratching their own itch" point is good, but the article's author misses an important corollary. The person who has scratched their own itch will develop a program as far as they need to for it to be usable to them - unless another piece of software comes along and short-circuits the process. And arguably, if a piece of software is usable to the person who wrote it for the task they wrote it for, its primary usability criteria are satisfied.
Anything after that - ie. everything this article is concerned with - is marketing... making something attractive to people who aren't already using it. There isn't actually any need to do it; it's something you do if you want your userbase to grow, but without a fairly direct incentive to do it - whether that's a financial incentive (consumer software) or the staunch belief that there needs to be a free alternative (the usual FOSS poster kids) - nobody's going to do it, unless something gets in their way directly. The situation is compounded if it becomes easier to write one's own X than to modify an X already available - you end up with lots and lots of Xs that are finished only to a point where their development teams find them sufficient.
Re:Usability is a matter of opinion (Score:3, Insightful)
"Designers" who can't code have absolutely no business "working" in software. If you think you really know how an interface should work and look, then learn to code it. Otherwise, you're just a critic of the kind that the NYT doesn't hire.
I could just as easily argue that programmers who haven't studied behavioral psychology should not be allowed to contribute to designing user interfaces, since they are obviously not qualified. Or, as an analogy, you could argue civil engineers who are not physically fit should not be allowed to have input on the design of runoff ditches and it should be left up to the ditch diggers to decide where they go. Frankly, I think your opinion is myopic.
Personally, I find FBSD, Debian, Slackware, and the majority of GNU software to be quite usable. Of course, I don't expect everything to be zero effort, either. Anything worth doing takes a bit of effort.
Do you feel the same way about, say aircraft? Anything worth doing takes effort, so you should have to learn aircraft repair and maintenance and constantly be working on your plane in order to get it to work each flight. How about cars? You can't expect to be able to drive if you can't put in the effort and learn how to rebuild your fuel injection system.
Speaking of which, tried Windows lately? Now to me, that's really hard to use! But then, I don't want to learn the "Windows way" of doing everything, as I fail to see the pay off in it.
Maybe this is part of what is leading you off track. Windows has terrible usability. The difference is MS has a monopoly so even though their usability sucks, people deal with it and use it anyway. With Linux, the opposite is true. Unless it is significantly better than Windows, it doesn't stand a chance of gaining market share on the desktop. Being as good as the abominable usability that is Windows won't cut it.
Re:Really a matter of taste... (Score:3, Insightful)
"If I'd asked my customers what they wanted, they would have said a faster horse."
You may like to ponder that in the light of that statement you made.
Didn't Henry Ford also say: "They can have any color they want as long as its black"?
Henry Ford also said: "Excuse me, I need to use the bathroom".
Neither of these two quotes, however, alter the value of the reasoning behind the original quote on "faster horses".
Re:Usability is a matter of opinion (Score:3, Insightful)
If FOSS were a restaurant, it would be of a type that if you don't like what's on the menu you may use the kitchen to make something else you prefer, with your choice of ingredients in stock or BYO. Since I doubt there are any restaurants like that, I believe your analogy fails.
And if you can't cook then you shouldn't eat presumably?
The analogy works quite well I think. Just because you can't do better yourself doesn't mean that you can't tell when someone else does it badly.
The chef makes food that makes me puke. I can't cook. Does that, therefore, mean I can't say the chef did a bad job of cooking? That doesn't hold.
Re:Usability is a matter of opinion (Score:5, Insightful)
Re: Usability of Free Software (Score:3, Insightful)
Why go through the trouble after your initial effort, if there is no advantage? A lot of free software comes about because of the need, or the personal interest. But once both of those are satisfied, there is no reason to enhance the program.
Comparing Socialism to Open Source software is an insult to both. Open Source developers are philanthropists, which explains why they would go through the trouble just as they would go through the initial effort. Open Source development is not supposed to be about personal gain. I know few people have a strong grasp of such selfless concepts, and so many misconceptions can be rooted to that fact. The real issue is that of priority and time management. No Open Source project is developed with the initial goal of developing a strong user interface. At best the interface is the secondary goal, because an interface without a function is not a program. The goals of the main developers may not match the goals of the market, and since the market has no DIRECT influence over the goals of the developers, these goals may never sync. The Open Source solution to this is, "I you want it, make it." and the flaws inherent to time management now take hold. Even if I want a feature added to an Open Source application, and have the ability to do so, stepping into an Open Source project is no small feet. Since the developers do not put your concerns above their own concerns, and since you do not wish to invest the time to handle your own concerns, your concerns to not get met. Basically it comes down to two things. One, often Open Source projects to not make it easy enough for prospective developers to gain and utilize an active interest. Two, beggars can not be choosers.
Re:It is the thought process (Score:3, Insightful)
Users, on the other hand, focus less on the architecture of the software they are using than on the front end.
By "focus less" I assume you mean "neither know no care."
To a user of something like a word processor, a web site, or an air conditioning control console, the UI IS the application. There is no architectural consideration of any kind.
Re:Usability is a matter of opinion (Score:5, Insightful)
EXACTLY! I can learn a programming language and write a program that does precisely what I want it to do. But that takes a vast investment of time to have a tool which does instantly what I need done. Perfect for people like programmers who might do one thing over and over and over and over... but not so hot for someone who just wants to do something once every 3 months.
The bane of the command line program is this: ">"
I sit there and stare at the little arrow. I want to copy a file. But all I can see is ">" What does ">" mean? Maybe I should type in what I want to do "CopyFile"... "command unknown". Great... well I'm out of ideas. Yes the interface might be faster... if you don't have to open a MAN file every 10 minutes because you forgot if it was cpyfile or copyfile or cpyfle or copy_file or copy-file or... whatever. The point is. Command lines are like code. They will do exactly what you want them to do once you know the magic incantantation with the right pronunciation. But if you know what you want to do but have never used the software before you're SOL. This is why I love node based tools. When I'm learning a new programming language I have no idea what classes and functions exist. I might even know the exact tool I need "I need to find the position in a string where "hello" is found". But translating that into a class name is a game witchcraft and endless help document scimming until you happen to find an arbitrary function name which does it.
GUIs show me my choices. Yes they show me my choices every single time. But I like to know what it is I can do. A BAD gui doesn't show me my opportunities. It buries it in a menu which is as bad as burying it in a command line command somewhere. But even a GUI is better than a command line while learning because when you finally do find the command you want to do... you can act on it instantly! No closing the MAN file reciting "'copyfile 'filename' -f -s-t-u #silent *underhanded" in your head hoping you don't forget it before you type it in.
Again many developer tools can operate on command line because the functionality barely changes from version to version. In all of the software I use every release adds hundreds of new features I need to learn and I need real time feedback on changes I make... I can't wait to execute a command to see if it's right.
Take SQL as a perfect example of a command line tool. SQL has barely changed in its command structure in 15 years. Of course you're super fast at writing complex SQL scripts that deliver exactly the information you need! You've been practicing those exact same commands for 15 years! What if SQL radically changed every few months? And what if instead of only a few dozen commands chained together it was 10,000 tools and settings in a single application? You cany very quickly get to the point in most software where it is simply impossible to use it as a command line tool and expect a user to use it without a MAN file permanantly open next to it.
I've spent 3 years learning MaxScript for instance for 3DsMax. Which is its command line toolset. It can take me a week to create a script which I can do in 20 seconds using the GUI. Once I write the script it might take an artist half a second but even I completely forget the name of a function I wrote earlier in the morning "What was it again? GetObjectIDFromDatabase or was it getObjectfromDatabase... what was the order of the function calls again? What was the name of that function which... I wrote it myself! And I still have to refer to my own help file to remember what the name of 90% of my commands are. It's unreasonable to expect someone to remember the command names and possible flags for 200 functions... and that's a primitive script. And even if I did expect someone to memorize all 200 commands... they would just have to memorize another 200 the next month when another tool is added to the toolset... and another 200 the next month after that... and another 200 the month after that.
Re:Usability is a matter of opinion (Score:3, Insightful)
(1) "Usability" is in the mind of the user.
(2) "Designers" who can't code have absolutely no business "working" in software.
And this mentality is exactly the reason the free software usability is poor.
Now, as to how to fix *that*, I've no clue.
Might be the wording... (Score:4, Insightful)
With my first major contribution to an open source project, the author essentially said "patches welcome", but he said it differently:
"I would definitely consider a patch that did that."
And, as I kept talking about it, but not actually sending it in -- my monkeypatch was pretty low-quality, and it'd take a weekend to polish it:
"I'm really starting to like this syntax of yours."
So, I was actually encouraged -- it wasn't confrontational, it was encouraging.
So, just as I would tell Person X not to simply say "This sucks!", but to offer a helpful suggestion, I would also tell anyone who would respond to think about how to help them get it implemented.
So, for example, if someone's a designer, but not a programmer, and you've got a programmer who you know wants to contribute, but he's not really sure what to work on, hook the two up. Or, with your example:
Why don't you do it yourself, or hire someone to do it for you? If you can't do either of those, why don't you contribute documentation, mockups, or something else that's not technical but is still useful?
Why don't you offer these up in a FAQ or guidelines somewhere, and mention them in your stock response? Simply saying "patches are welcome" is actually unhelpful, unless you can write a patch -- and even then, it simply comes across as standoffish.
It's the difference between "I can't bake that for you, but here's a recipe, and I can sell you some of the ingredients," and simply saying "Do it yourself."
Re:Maybe if MS/Apple shamed us into it? (Score:3, Insightful)
That's a lousy paraphrase, almost libelous. How about "Nobody is paying me for this work, and the development model and license I have chosen let other people make changes as they see fit. If you want it, please feel free to contribute something more constructive than whining about how unusable you think this software is."
Re:Usability is a matter of opinion (Score:5, Insightful)
Have you actually used AutoCAD, say?
Yes I have. (I'm an avid Emacs user too) You're right, the command line in Acad is great, but it's the combination of the command line (and its scriptability using AutoLisp) with the UI that makes it truly useful (e.g., as you say, the fact that each time a point is required, it may be entered numerically as well as interactively using e.g. snapping). Acad was written by judicious and wise people. If it had been written by pure click'n'drool advocates, it would only have a GUI. If it had been written by die-hard "GUIs are for losers" Unix freaks, it would only have a command line.
Re:Usability is a matter of opinion (Score:4, Insightful)
That's definitely true, most people that code want their programs to be used and as such are unlikely indeed to leave usability issues in when they know how to fix them.
I'm not really sure why open source is getting blamed here, commercial programs are often times just as bad or worse, and at least with open source, I can use it for a few months or even years before deciding if I want to contribute.
Sometimes knowing all the ins and outs of a program makes it harder to make an interface that is useful for those starting out or that don't have all the information. Ideally the learning curve should be relatively gentle and long enough to deal with necessary complexities.
Having a gentle curve that is too short ends you up sort of where Windows is. With the program making most of the decisions and with the tools to override things hidden in a hard to access area. Assuming that one can even override them in the first place.
Re:You need to fix yourself first (Score:3, Insightful)
The Daily WTF.com has a term for software like this: "Enterprise-y." It's a basic joke that most software that advertises itself as being "enterprise-quality" is actually pretty damned shitty. Think of anything from Oracle, Cisco (their VPN client gives me nightmares), IBM (Lotus Notes is aggressively user-hostile, and has been for decades), etc.
There's a "sweet spot." Tiny software is usually unusable because there are too few developers and resources. Medium-sized software is usually pretty good, because it has more development resources, it's in a more general market and trying to be more competitive, etc. Enterprise-y software companies know that all they need to do is feed the CIO enough bullshit terms for them to sign off on the contract; they know the end-user has no say on what software choice is made, so it's 100% marketing.
(That's also why so much enterprise-y is extremely general purpose. If you ask an IBM rep, there's literally no business function Lotus Notes isn't capable of-- web server? You got it. Point of sale? No problem.)
Re:Really a matter of taste... (Score:4, Insightful)
Usability is mostly a function of what the user is used to (no puns intended).
Yes, consistency is one of the things that affects usability.
I find working from a command line to be the most efficient way to get things done, which is in opposition to most of the world.
Which says that there is an aspect about the command line that says it is usable, not necessarily unusable otherwise nobody would ever use it.
I don't really think it's possible to quantify "usability" when to most people it's best rendered as "similarity to Microsoft products."
This is where you're wrong. Usability is quantifiable based on certain metrics you want to measure against. When an interface is designed, there are different users of the interface therefore different needs arise.
For example the command line is one interface that has been successful for a particular purpose but requires a steep learning curve before it can be used correctly. This is okay because what is important is that one has an interface that can be used to probe or maintain a complex system for which designing "easy to use" interfaces would be a gargantuan task. So when one is working from the command line, they expect a high degree of power (do almost anything) that comes with it. The cost is that some of those functions may not be intuitive or may require more steps than necessary had a complete interface been designed. But that is ok because the operations needed on the command line are often unique and covers a huge number of possibilities. So in this case the learning curve is warranted because the knowledge required to perform the task must be learned anyway.
Meanwhile if a user wants to compose a simple email, would the command line interface suffice? Probably not because the details of the command line interface are not necessary in the process of composing and sending an email. What is important is the fact that they can write the email and send it with the fewest hassles. Furthermore if we expand this out to different types of users, we can have a home user and a business user. The home user may not care about integration into their calendar software and other things like easily sending attachments. Meanwhile to a business user, those two operations happen on a daily basis. So for the home user, a simple web mail interface might be sufficient and usable while for the business user it probably won't be. Meanwhile an outlook interface might be perfect for the business user while for the home user it might be a little too much.
So the point here is to identify each user's needs in respect to the task they want to accomplish and in many cases that does not necessarily mean "Microsoft only". Interfaces are everywhere not just in hardware. For example cars with pedals and steering wheels. In almost every car the interface is probably mostly the same. Another example is stereos and music players. Or even your stove in your kitchen. The device I think that is often neglected but needs the biggest usability improvement is the remote control. But maybe soon that will get replaced with an on-screen-display and something like a wii-mote. Anyway the point is that as an interface designer, you can borrow from these other common interfaces (not just the Microsoft ones) to use as metaphors for your new interface. I wouldn't recommend it but that is one option.
The easier route is to use R&D (rob and duplicate) and copy existing interfaces. The problem with this is that sometimes you inherit the faults of whatever you're trying to copy. A good example is OpenOffice. Some people like the interface because it is what they're used to. But for a word processor, I feel that the interface is poorly written such that it leads to poorly authored documents. I've seen countless word documents with foo-bar'ed formatting in the bullets, fonts, and everything. Even the table of contents was put together by hand rather than using th
Re:Usability is a matter of opinion (Score:5, Insightful)
It absolutely amazes me how many people like yourself get modded +5, Insightful in every single discussion like this, when you're all dead wrong. It amazes me how you think you're being logical and can go to incredibly great lengths to justify the continuing elitism of "if you don't know how to build the car you have no business driving it" kind of attitudes, which is exactly what you're espousing. Did you build your own car? Do you know how every single piece of it works? Can you recreate it from scratch? If not, shut your stupid pie hole.
This idea that you have to be the world's foremost expert in a particular field in order to be allowed to open your mouth is just so unbelievably ridiculous that I can't understand how it keeps being perpetuated so strongly even on a site that is supposed to be full of relatively intelligent people.
You're all constantly using obscure corner cases to try and demonstrate that any end user who ever criticizes the work of a "coder" is an idiot and wrong in all cases simply because they don't understand the precious code. Sure, users often misunderstand what the actual issue is with a program that's not working for them, so what? The fact remains that there is an issue, and blaming the user every single time solves nothing.
The longer attitudes like this get perpetuated, the longer most open source software will remain the underdog that most non-coders won't touch with a ten foot pole because it's so baffling or aggravating to use. What all you elite coders need to come to grips with is that you are too close to the code. You understand the code too well and it blinds you to the real life usability problems. You don't realize how much your knowledge of the code warps the way you see the interface. You have to learn to forget what you know about the guts of the software and look at it with fresh eyes, like any new user does.
The real question here: If you aren't making the software for people who don't know how to code, what are you doing putting a GUI on it in the first place? That is after all the entire purpose of a GUI in most cases, is it not? To make software accessible to and usable by people who don't know how to write the code themselves?
Jeebus cripes, folks. Get over yourselves. Stick to writing command-line stuff if you don't want to respond to interface criticism or suggestions like a reasonable human being.
Oh, and stop using Firefox as if it shows how great all open source code is. It's one application that has been worked on by teams of very talented people for several years and is supported by a business. Of course it's one of the best, but 99% of the open source software world falls a few miles short of that. Face up to that fact and you'll be better for it.
Re:Usability is a matter of opinion (Score:2, Insightful)
The goal of a good interface is that you don't have to take the time to understand it, at least not to archieve basic use.
Re:Usability is a matter of opinion (Score:2, Insightful)
In the real world companies which succeed are ones which either reduce the costs of their customers or make their customers more money. If your customer isnt reducing costs because they cant use your software effectively then even if its free the TCO is much higher than commercial software since the customers time will very quickly become more valuable than the software.
Re:Usability is a matter of opinion (Score:3, Insightful)
a more appropriate saying is "the right tool for the job". For some jobs, a command line will never be appropriate and vice versa.
Re:Wait a minute (Score:3, Insightful)
Most people complain if it doesn't act exactly like the proprietary counter part, eg. The GIMP. I bet most the "usability" problems of free software is that it doesn't look and act exactly like the closed-source counter part
Photoshop has years of professional usability research incorporated into its design. What are the human-computer interface credentials of The GIMP team, and what justification can they offer for those interface elements that are different not only from the closed-source counter part, but from practically every other GUI application in common use?
It's dangerous to "chase the tail lights" and not learn from the big players' failures, but it's equally dangerous to reject what they're doing and therefore not learn from their successes.