Slashdot Mirror
How To Fix the Poor Usability of Free Software
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.
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.
(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.
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. 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.
Caveat Utilitor
Usability is mostly a function of what the user is used to (no puns intended). 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. I don't really think it's possible to quantify "usability" when to most people it's best rendered as "similarity to Microsoft products."
Like it or not, the fact that there is so many choices for the GUI/Desktop, the packaging system, etc is the main problem for Linux.
The kind of additional functionality added for usability reasons are usually looked down on because they can fall into scope creep, but I think they're quite the opposite. I think most coders look down on these kinds of suggestions because they don't affect how they use the program. And, truly, most people who work on open source code do so because they themselves want the functionality they're coding for.
To them, if it does the job, great. And I think many of them have a similar response to usability problems as those asking for ports to different operating systems, or even a binary: "Not my problem, it works for me and that's enough."
Not to mention that, in many cases, what increases usability to a larger audience is reducing efficiency to the programmer who designed it to suit how they work.
Mainly that people who are interested in coding free software and people who have a great understanding of ergonomics and aesthetics in software are usually just not the same people. I've known plenty of coders whose idea of usability is to configure it for their personal preferences and that's it, but on the other hand, I am sure most people who really understand what is needed for usability couldn't code "Hello World!" in BASIC.
http://twitter.com/OLDTELEGRAM
Perhaps this article signifies the movement that has occurred with open source software. Whilst I'm sure it's been around a long while, there has been a huge increase in what's available in the last few years. Open Source software is maturing as most things do when they get older.
I'm happy with the 'get it working first - then make it pretty' approach taken by most.
The Mothership
I am a 100% satisfied user of free software, after years of negativism and complaining (I admit, my past sins...). I use: Xandros and SLAX distros, OpenOffice (EXCELLENT usability!), Firefox, the WLAN choosers that come with the aforementioned distros and a handful of console apps. I don't even know the name of the movie player that starts up when I doubleclick on a media file. What's not to like, what's not to be able to use?
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Obviously, free software has teh same problems as socialism: If it is free, what is the incentive for enhancement and bettering? 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. And if it meets the usability requirements of a select few for whom the program was designed, what is the purpose of making it more usable by the general populace?
Do I look like a man with a plan?
if you think free software has usability, you have problems identifying and finding good software. you need to fix yourself.
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.
Read radical news here
Just had a look at TFA. The author doesn't even care to say what useability is and why it is so poor in FOSS.
Next try, please...
I have been using free and open source software for over 10 years now, and i would rather have a square block that does what i want it to do when i want it done than have a nice 3D cube with bevelled edges and drop shadows that breaks because of reason x not allowing me to complete my desired task. Just like in any engineering job when the tool you need is not made then you make the tool yourself, once the tool is being used by many people then some corp decides to chrome it and mass produce it. Isn't that what DeadRat and Apple are for?
A computer once beat me at chess, but it was no match for me at kick boxing. Emo Philips
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).
My open source product is mine, to make whatever design decisions I want.
I tend towards the opinion that if someone wants to dictate usability terms to me, they better be prepared either to submit code, pay me, or to be blunt, get lost.
Personally, I like coding console apps. As far as usability goes, this is stone age stuff, but it works for me.
Quite a few people have talked about improving my application suite with 'pure virtual interfaces', or just packing it into a GUI app, but none have actually contributed functional code.
I much prefer to spend my time working deep in the algorithms of my software, because coding those is a pleasure for me. Anything else just doesn't hold my interest.
Leaving little things broken. Many of the small details that improve a program's interface are not exciting or satisfying to work on. Details like setting a window's most appropriate size
... on a site where the text is displayed on a huge blank white page in a column 2" wide.
Aye, right, we're *really* interested to hear what *you* have to say about usability.
My suggestions: start a Usability Level Group where one can see which level of usability the application has ( for platform X).
Things to consider (remember: using starts with considering installation):
-does it compile cleanly?
-is it pre-packaged?
-is it in the standard repositories?
-is there a manual and man page
-are there examples which can be followed
-(if relevant) are there screenshots
-are all options of the application available in the GUI
-let people vote about the quality of the above
First you have to obtain a means to measure usability (by the users is best, I guess).
nosig today
At the bottom the article links to John Gruber's "Ronco Spray-on Usability" 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.
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
A product is of on value until it is placed in the hands of someone that can use it. Open source will never best companies like Microsoft and Apple because most of the world can't use it's unfriendly products. Taking the care to ensure that the software is usable by an end user is what gives it a finishing touch that customers will respond to. Case in point is the Apple corporation. I don't know that they have a shred of technical innovation in them, yet the simple act of making technology both sexy and friendly has turned them into a giant.
That article hit it on the head. There's 1001 programmers in the world, who are excellent coders and whip through the strings like a first chair, but there's very few project designers in freeware. They concentrate so much of function (which, yes, is critical!), but forget about ergonomics and userability (especially *how* end users can and will use their product, and ways to cut out excessive keystrokes or right clicks). The end users winds up getting a proggie that can function well, but such a chore to operate (or even painful, if it not ergonomically friendly). As we more and more get "connected" to computing, it's no longer just being on a keyboard or using a mouse an hour or two a day. Now it's more like 8+ hrs. Programmers need to consider the impact of their software, and beyond how it functions itself, but the whole project. That's where product design is so crucial, and something not just best left up to management to figure.
I am a UI designer by trade, and many is the time I have thought about wading in to a F/LOSS project in order to improve the usability of the interface (last one I considered was IPCop). While I agree with most of TFA, it doesn't seem to emphasise the real point for me, which is that UI design for free software requires radically different skills *from the designer* to that which are necessary in the commercial world.
Because people are so tolerant of awful UI, good UI designers are all about persuasion, charm, leadership and inclusiveness without losing focus. To achieve this commercially is not easy, but at least somebody has hired you in an expectation that you will do this work. Grabbing a bunch of elite coders and trying to persuade them to change their stuff is a massive challenge, even if you have VoIP, virtual whiteboards, etc. I would not expect maintainers to understand, appreciate or tolerate my intervention, mainly down to the reasons the article cites, and I'm not sure I'd be able to persuade them otherwise. Usability is not obvious and often requires a leap of faith, an abandonment of the wrong kind of complexity, and very often a lot of pain.
Still, the more we have these discussions, the better, and I hope the article gets read by a lot of Slashdotters for that reason.
"And the meaning of words; when they cease to function; when will it start worrying you?"
The reason that free software has poor usability is that free software is a subset of software, which is noted for poor usability.
The vast majority of software is written by and used by a single person, and would probably be hard to use for anybody else. Sometimes these projects get to be free.
Most of the remainder have a limited target, whether it is an in-house project or free. Some of these are easily usable, but the majority of companies will prefer more features to usability.
The tiny fraction of "big software" which has serious market penetration comes in three main categories: operating systems, utilities with a free version, and games. Operating systems typically have incredibly poor usability; really successful games almost all have decent usability.
The only real difference between free and commercial software is that the makers of the latter have a better chance of making a living off it.
Now that this problem has been addressed, what about a quick essay on how to fix the poor usability of non-Free software?
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Just for the sake of being proactive (and on-topic, oh horror!), a colleague is a usability expert and has acquired a fascination with free software. I thought that jumping in and rolling up his sleeves would be a good induction, so here's asking: anyone sitting on an interesting project with a need for (and willingness to listen to) such a one?
Blearf. Blearf, I say.
Poor usability? Is there really anybody who thinks that Internet Explorer 7's user interface is better than Firefox 3's?
I'm getting tired of hearing this over and over again. For example, in the past 7 years, GNOME has invested an insane amount of effort in usability. Go read about all those professional GNOME usability studies that Sun has funded. Also, go read Ubuntu and "desktop environments", written by the same author who wrote TFA. In that article, he criticizes people for wanting to include a configuration option in Ubuntu's installer which asks the user whether he wants GNOME, KDE or XCFE. He argues that such a choice is simply too confusing to most non-technical people. And indeed, people like my dad and mom don't know, or want to know, what GNOME is.
In the past 7 years, GNOME has done its best to address exactly that kind of criticism. Almost every single feature is scrutinized with usability in mind. GNOME has been removing more and more configuration options from the user interface in order to make things easier for the average user. In fact, they've done so much their best that the technical audiance, i.e. Slashdot/OSNews/Reddit, is constantly flaming them for removing config options. Yet this same audience is flaming them for not being usable.
KDE, too, has invested a lot of effort in usability. But what's the community doing? Instead of offering helpful feedback, perhaps mockups or even professional usability studies, they're flaming the developers. By flaming, instead of offering useful feedback, they're discouraging the very people who made the software from improving it. And you're wondering why they're having a hard time?
Go figure.
The problem, in my honest opinion, is that free software is quite often used by computer enthusiasts - programmers, that is. ./ - do not see a great problem in using a command line and fixing things using /bin/sh. Free software is often extremely powerful, and that almost automatically means that it gets complicated. For that reason, many average users - and I'm talking about the guy who does some writing and sometimes plays a game on his Windows box - are to some extend "frightened" of FOSS, thus not using it, which again results in mostly developers using FOSS. And now we have a vicious circle...
We - and that goes not only for programmers, but for nearly all people visiting
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.
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.
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?
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.
There are thousands of cars the world can pick from and I don't see the average person having a nervous breakdown over the decision which to buy.
Cars have throttle on the right and brake on the left. Period. GNOME and KDE, on the other hand, can't agree where to put OK and Cancel.
Then someone else comes along, picks up the source and adds what they want. Rinse and repeat.
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.
John_Chalisque
Want to make usable software? Start from the human user perspective. Ask what the person does, not what the software does. Adapt the software to the (generalized) user/person. Sounds simple but it is so rarely done especially with non-commercial, custom proprietary and open source software. Usually it's done exactly backwards with software function first and usability bolted or cobbled on at the end, if at all.
Ask the kinds of questions about software that most developers dismiss as "stupid:" What is it? Who uses it and how? Why?
I have been quite surprised to find that these questions had never been previously asked and answered for a lot of the (paid) projects I've been involved with. "It's obvious" isn't an answer - obvious to you is not enough. If I could get one usability concept through developers' heads, it would be that the software you're writing is not about you.
Unfortunately, such suggestions are often met with the reaction that designers are idiots and nobody cares what some Photoshop moron thinks anyway. Hence the reluctance of designers to get involved in the first place, especially with volunteer projects. I would love to contribute to certain open source projects if I thought my contributions would be welcomed.
Otherwise known as "We Don't Feel Like Fixing That."
I've long noticed this syndrome on the part of medium and small commercial developers including those consisting entirely of a single coder (and **especially** when the application has little or no competition); it tends to occur as a project gets older and the coders start feeling the pinch of corners they maight have coded themselves into... or they just get stubborn in the face of constant user complaints about particular issues. Eventually the issues become "bug non grata"; if you want your issue X dealt with, don't be bringing up that old problem Y, or X and Y will stick around for a few more versions than was necessary.
A big part of this attitude is simply that the coders would rather work on the fun and glamorous parts of the code (like say the renderer in a 3D graphics package) instead of the dull and boring housekeeping parts, such as memory handling and UI code, where a lot of issues arise.
Eventually the userbase starts trickling away, and bug reports start falling off, because the remaining users are pessimistic about them ever getting fixed.
And all of this happens on commercial projects, where at least there is the profit motive to get developers to smarten up... what is there in open source to deal with this kind of issue?
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.
EvilCON - Made Famous by
There are still the issues of acceptance, and support.
Consider Quickbooks for example, even if there were a f/oss equivalent that was just as good, or better:
* No significant cost advantage: QuickBooks simple start is free:
http://quickbooks.intuit.com/product/accounting-software/free-accounting-software.jhtml
Or I can buy the full version of QuickBooks Pro 2008 in only $145:
http://www.amazon.com/Intuit-403697-QuickBooks-Pro-2008/dp/B000V4PLWM/ref=pd_bbs_sr_1?ie=UTF8&s=software&qid=1217794735&sr=8-1
Seems to me that any cost advantage of using a foss alternative is negligible..
* Wide acceptance: I think most businesses are much more comfortable using products that are accepted standards.
* Wealth of available add-ons: Intuit has a very active community of 3rd party developers. You can buy practically any kind of an add-on you can imagine. These add-ons cost money, but at least they are available.
* Major company: I think a lot of businesses are not comfortable with a product unless there is a major company behind that product. I have to admit, even I am not comfortable with software products that are essentially one man operations.
* Support: I can always hire somebody who knows quickbooks, or find a "ProAdvisor" consultant, or I can get support from the company, and there are hundreds - if not thousands - of developers who specialize in developing for quickbooks. I can not see where that is true for any project.
* Training availability and costs. I can hire people who already know quickbooks. If I hire somebody to work on some foss alternative, then there will be a significant training expense. Of course, there is also the issue of training availability.
* Documentation: If I had to pick one thing that kills the usefulness of more foss projects than anything else, this would win in a slam-dunk. Of course, this varies among projects, some foss projects have great documentation. But, I can always find plenty of books, or other documentation for popular proprietary financial apps.
* Many accountants, maybe as many as 200,000, use QB and recommend it to their clients. Some accountants will charge much more for files that are not in QB format.
* QB has much better 3rd party integration. For example, ecommerce packages like oscommerce, and magento, work with quickbooks, not foss alternatives. Msft accounting works with ebay. I can not find that sort of integration with foss software.
The people who design houses don't build them. Sure, they need a solid foundation in what can and can't be done ...
In many of the top tier Architectural programs (Yale for one), the students go out and build a house or at least some of it. The reasoning is to for the reasons you've stated.
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".
I think that would only apply to one or two man projects at best. eg. the firefox dev team won't just stop improving firefox, or the linux kernel devs won't just stop writing the linux kernel
they don't respect you because you're "not technical" and you can't code. Basically, the programmers have no respect for anyone who can't code.
Perhaps you're right. No one can force you, or should be able to. Still, it does not make the usability better. With that attitude it stays as bad.
This software for the XO laptop is an open source project that is intended to be used by elementary school kids.
Usability by its target audience is absolutely of the essence. It is not a project in which the developers can get away with saying "it works for me," nor can they tell their eight-year-old audience "if you don't like it, patch it."
The XO laptop is thus an example of a situation where there are strong "incentives for usability." In fact, the entire enterprise fails if the device is not highly usable by elementary school kids in third world countries with no previous computer experience.
Time will show us how usable the XO software is. It will either be a data point that demonstrates that, indeed, the open source process produces highly usable software provided only that there is an incentive for usability... or that it really has a systemic problem that incentives cannot overcome.
"How to Do Nothing," kids activities, back in print!
Irfanview
Notepad++
CDex
FileZilla
Free or open source software that I use frequently have no usability issues. I know there are some horrific free and open source software choices out there. I just don't use the ones that don't lend themselves to ease of use. I stick with the stuff I know works.
Please don't humanize the morons around me. It makes me very uncomfortable.
I already posted in this thread or I would give you all my mod points.
The most usable of all possible interface is probably the command line. There's no uncertainty about what icons mean, instructions are usually a keystroke or two away (and don't take eleven minutes to get online and load), etc.
Pace Microsoft Bob, if you cannot be bothered to learn the language (phonetic or ideogrammatic) that an interface is "written" in, don't blame *it.
My turnips listen for the soft cry of your love
I'm surprised those were't mentioned in the article. Why, oh, why do you have to type four nonsensical parameters for a file archiver's most basic function (that is, extract the contents)?
I don't mention VI because I've yet to find the key combination to close the program.
Better would be:
"How did the carpenter building his own home respond to the (voluntary) suggestions of a professional architect?"
In this analogy, the right of a carpenter to build his own home, without interference from governments or corporations with market power, would be under attack. This is the case with software intended to run on mobile phones or on affordable computing devices with good SDTV output (such as Wii), where all software must be digitally signed by the platform's maintainer before anyone can run it. There has to be a library of free software on a popular open platform; otherwise, people won't have much of a reason not to switch to a closed platform that uses the lockout chip business model.
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.It often is the most efficient way to get things done. But I doubt even you would say that using the command line for, say, file management, is more natural and understandable to than dragging icons around with a mouse. Even an illiterate use could understand what is going on there.
(This is not to suggest that a mouse-icon interface is the ultimate form of file-management UI, but it is useful as a point of comparison)
I don't really think it's possible to quantify "usability" when to most people it's best rendered as "similarity to Microsoft products."
Well, consistency is certainly a part of usability. If it's possible to just recreate what Microsoft (or whatever industry leader you can expect users to be familiar with) has done, then absolutely you should not re-invent the wheel. Unless you're sure can build a kick-ass wheel.
For less-well-defined domains, (e.g. totally new classes of software) it is certainly possible (though not easy) to quantifiably measure usability. Most of it involves counting clicks/keypresses, timing testers with a stopwatch in a lab, and surveying users. This requires face-to-face interaction and money, which is where most FOSS projects come up short.
The US free market: two halves of a government-granted duopoly are free to set the market price.
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.
Has it been over a year since you last donated to the Electronic Frontier Foundation
" Chasing tail-lights. In the absence of a definite design of their own, many developers assume that whatever Microsoft or Apple have done is good design. Sometimes it is, but sometimes it isnâ(TM)t. In imitating their designs, Free Software developers repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives. Solution: Encourage innovative design through awards and other publicity. Update design guidelines, where appropriate, to reflect the results of successful design experiments. "
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
If you would be designing a mall for me and I noticed that some area would be better accessible if you added a new walkway and some doors, you would as a good architect listen to me. Not just because you wouldn't get paid if you didn't (which often would be true), but also because end users are always right.
End users are not right in what they want though. They know that something bugs them, and often can't tell what it exactly is, or how to fix it. Their suggestions are sometimes quite horrible, and they are not giving exact solutions to problems. Still, they nearly flawlessly always know that something IS wrong. It is the job of the better architects to attempt to understand what is the real problem and fix it. If you wanted to hop back into software usability, people feel naturally things like the focus stealing issues, having to memorize complex paths to functions, and confusing dialog language as bad. They come in 90%+ of the cases forward with real issues, real problems, although their explanation of the problem and how it should be fixed is most commonly trash.
Now, bad architects would either tell the end user to stfu or (often even worse) implement blindly what was requested. That wouldn't fix the problem in either any way, or produce plain mess. A good one would attempt to understand the real issue, and when failing (in open source case, 99.99% of the time) go ask for a second opinion from subject area expert. Oh, building architects are not almighty. They know a lot, but they do ask from others if they need some detail.
Usability experts are available to developers, and they are more than willing to tell you why the current feature X is bad, and why. That discussion is based on the limits of the human brain and cognition, and on solid science. It is reasoned, logical, and can produce great value.
What I don't get are people who are like "Why should I? I am doing this on my free time! You can't force me!". It is exactly the same as saying "I know I am a bad architect. I do not want to take bride of job well done. I like my creations being bad! I don't want to evolve into something better!". It's plain appalling and I feel kind of sad because of it.
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 :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Why benefit only one project?
See if said colleague isn't interesting in trying to work up something along the lines of usuability guidelines such as those for notable Apple products and productions.
Linux clearly already has enough coding guidelines, maybe some general interface ones are in order (that go beyond use E17 for widget support or similar)
Maybe your friend could join OpenUsability.org?
Mada mada dane.
There is no good design for cut-and-paste, zoom, or dealing with images that don't exactly fit the screen.
Note that the target audience is about age 2 to 12, especially age 4 to 9. Ideas swiped from Photoshop will NOT work with this crowd. Scroll bars are probably out of the question.
OpenUsability
I used to work at the company which started it. It's a platform for free software developers to meet usability specialists, and so far it's coming quite good. The KDE 4 HIG was designed by us ("us" as i still used to work there at the time this was done), and the people working there are certainly bright minded people, but there's always friction at the implementation front. In my experience it's not neccessarily easy to convince a developer that a given usability decision is the right one, even if someone with a background in usability makes the proposal.
Power corrupts the few, while weakness corrupts the many.
A lot of free software comes about because of the need, or the personal interest.
And that is often why it is good. Complains about usability in Free Software slowly get old. Not only has Free Software improved quite a lot over the years, commercial software also got rather horrible. Its mindbogglingly how many pointless dialogs and licenses one has to click away in Windows Vista just to make something simple work, yet on Linux you have none of those problems. Its also a little ridiculous how a mouse driver can take 70MB to download on Windows, while it just works by default on Linux.
Now of course none of that means that Linux doesn't have problems, but they aren't really half as big an issue as some people claim.
What we're talking about here is the ability to CODE not to tell programmers what works as a UI. If you are better suited to be an end user or debugger, or a liaison of some sort, don't friggin program, because chances are - you suck at programming, but know how a UI should operate. Instead what is needed is that "liaison" person to LEAD a programming project, and make sure it's good for an end user. Programmers sometimes get blinded by their own ideas and end up making a program that is useless to anyone else but them.
Freeware/shareware programmers all to often do not get someone like this involved ; they're self- employed enthusiasts,looking for some crap to add to a portfolio.
Stupid is as stupid does leads to GIGO
Why else do you think they wrote Sugar in Python?
I actually think it is great to encourage the
eight year olds to patch software, but...
Since the problem is performance, and the solution
is getting rid of Python, all the damn Python isn't
helping at all!
While I agree with the author's intent, many of his proposed solutions are in conflict with the basic nature of open source development which largely rejects the notion of up-front design. Most sucessful projects rely on "evolution, not intelligent design."
I do however agree with the author's suggestion of design awards. I think they would have the potential to establish the idea in the community that design (both visual and ergonomic) is just as important as coding prowess. All open source developers want to create popular applications and they want technical recognition for their work. Just as developers recognise the importance of good coding craftsmanship, so too usability needs to become an important technical consideration in evaluating technical quality.
Another approach would be "design makeovers." Within both the GNOME and KDE communities, exist many small projects written by newer developers. A sponsoring organization, for example a Linux magazine, could select a small project and give it a "makeover." This would involve a couple of experienced coders and a designer who would apply (with the cooperation of the original author) a set of fixes to the UI. The final result would then be presented to the public (along with a lot of before and after screen shots) with a detailed explaination of the improvements and their rationale.
While usability and visual design may require talents that do not come naturally to all developers, we have seen (in the case of stronger security design, for example) that the development community is not incapabable of adapting to new standards of technical excellence. All it takes is for the community to be sufficiently concerned about the issue.
Howard Roark, Architect
I believe in a Man's right to exist for his own sake.
I think the author makes some great points in this essay. The only issue I take with it is that all of the suggestions he makes require quite a bit of leg work and organization. Its useless to write an essay about all the work that should be done by other people.
I think what we need is a Free Software Design and Usability Foundation. And with all his poignant ideas, I would like to see the author of the work help to start it. It could help to make the design material he speaks of available, help to draw more usability experts and UI designers to volunteer where they are most needed. Help give guidelines for best practices, and coordinate the awards he speaks of, possibly with a cash prize generated by donations. It could really do a lot of good for the FOSS community.
But if he's not going to attempt to help start such activities, well, I simply have no respect for someone who writes at length about the work other people should do.
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
...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.
Live today, because you never know what tomorrow brings
Many KDE, Gnome or X applications are just fronts to command line tools. It is frustrating to write GUIs for these programs because they weren't designed to use one in the first place.
The author himself states that usability is hard to measure, but has no problem declaring that OSS usability poor. He doesn't appear to cite any research, so is there anything more than anecdotal evidence to suggest this is the case?
We need some diversity at /. .
One doesn't have to look far to find small but serious usability issues in open source software.
For example, did you hear about Fitt's Law and "mile high menu bar"/ "infinite size widget" effect?
For detailed description, see e.g. this Ubuntu bug.
It turns out that while the Windows and Mac software got this right (at least with respect to scrollbars), massive amounts of OpenSource software (even high profile projects for Gtk/Gnome and Qt/KDE, like Gnumeric, Gnucash, OpenOffice, Konqueror or Kword) add an idiotic small border to their document area that seems to serve only one purpose - prevent this usability effect and make all users' lifes harder.
BTW, I highly recommend Joel Spolsky's "User interface design for programmers" - that's the very least a coder could do to educate himself in the area of usability. The book is very interesting, easy to read and quite short.
I haven't had any problems using any software that's somewhat mature. If you know how to use Unix, you can use almost any software out there. I mean, you only really need to know tar, ./configure, make, make install, that's about it. Oh, and chgrp and chmod for permissions. And /etc is your config files. The rest just comes with experience. Everything is extremely usable; there is no wasted actions when using most unix programs I've seen. The problem is people see "usability" as being "shiny" which is not the same thing. Almost all of the comments I've seen so far have been about "shiny". If it's Usable, it DOES THE JOB. That's it.
If you want shiny, you move to MacOS X or Windows and you're going to pay for all of that design.
Cool! Amazing Toys.
I believe that there exists a good technical solution to this problem: GUI should be decoupled from the application, to the point it could be created in some WYSIWYG editor and dynamically linked with it.
Just imagine, if you would like GIMP to behave more like Photoshop, you would just take the UI source file in the editor and edit it. You could move the panels, change keybindings, restructure dialogs and so on. Then you would just save it, and voila - you could run GIMP as a Photoshop. No programming skill required, really. Or even better - there would be a whole repository of such UI skins, because it would be so damn easy to create them.
This is what happened with the web applications (the visual design/application logic separation).
There would be a couple of problems to solve, like how to describe custom widgets in generic enough fashion, but it should work for the most part. But it would also save people a lot of work trying to rewrite the same application in their favorite GUI toolkit.
If it is free, what is the incentive for enhancement and bettering?
Have you been under a rock for the past 10 years? How about:
- Personal satisfaction
- Acknowledgement and respect for your work
Or if you still can't believe that anyone would program out of personal interest:
- To acquire or improve the skills that get you salary-earning positions
And believe it or not, many developers today actually (drum roll please) get paid to work on open source.
If you don't think open source is big business today, you need to open your eyes and have a look around.
Most programs offered just one user interface, but it could be easy to provide the user a choice level: simple, advanced, expert. The simple and advanced user interface levels should show only some parts of the Expert user interface, and this last level will be the one the programers will develop intensively.
If people spent less time focusing on usability and more time focusing on easability, the world would be a much, much better place.
I find that poor usability is caused by the programmers' arrogance. They fail to understand that having a usability advisor is MORE THAN RECOMMENDED for any open source project. Their word isn't their opinion. Their word is AUTHORITY and should be followed.
To solve this problem, usability guidelines are published. wxWidgets have the wyoGuide. GNOME has the User Interface Guidelines.
A group of designers review three or four programs every quarter. They submit their results to the developers. The program with a weighed average of worst usability and most developer attitude makes the quarterly wall of shame. What's an appropriate phrase for the acronym "Meddlers"?
I found this article a while ago.
"Software Development's Evolution towards Product Design"
http://lostgarden.com/2006/02/software-developments-evolution.html
Here's the PDF. You'll love it.
No, I haven't RTFA yet. But regardless, I think Windows has no user interface guidelines really, or nobody reads them or has any sense of what kind of user interface guidelines. One commenter said that UNIX applications are generally made to work well with other UNIX applications. I think this is great and all. The same thing happens in Windows. We have the Drag-n-Drop functionality (which is workable with nearly all applications because it's built into the API), at the very least.
Windows is not a great example when it comes to usability, either. Microsoft has set a defacto standard for how Windows applications should look but they keep changing it. Now they don't even want menus apparently. I see hardly any 'standards' in Windows when it comes to interface, especially when talking about 3rd party developers. At least in XP, consider Windows Explorer and Internet Explorer 7. Windows Explorer and IE7 are pretty different, not even the same navigational buttons; refresh button is in an entirely random place in my opinion in IE7. Then consider the normal range of applications ever Windows user has. Let us consider the average user with XP installed. They have Norton (yes I know it's terrible, but it's what a lot of users have) AntiVirus 2008, ZoneAlarm Pro for firewall, Ad-Aware Pro for anti-spyware, Microsoft Office 2003, and Adobe Reader. Norton has this all-yellow (extremely ugly) interface that follows no standards whatsoever other than Symantec's crappy 'home user interface' standards; it hardly references the Windows API directly. All of its interface is custom-made to seem easy to any user it seems, even though it hardly looks like a Windows application since it looks drastically different from Explorer. It does not even have a Windows border. ZoneAlarm Pro is nearly the same story, a completely custom-made perhaps 'themeable' interface. Again, it hardly looks like a Windows programme. It's not like the popups from the tray even look like the Windows ones (AFAIK you cannot have a button in one of those with the standard Windows API). They have different colour scheme, etc. The interface is of course, another custom interface made to be 'easy to use'. Ad-Aware is again the same. It is a skinnable interface (there are skins available to choose from), and no buttons look like Windows API buttons. It does not even use standard OK/Cancel//Yes/No dialogues. Office 2003: toolbars that are styled differently from other Windows applications (I forget what the style is called), hard-coded fonts, etc. I don't think I really need to mention about Adobe Reader, we know how that is, especially after version 8. At the very least, Adobe Reader still makes a lot of usage of the Windows API directly (dialog boxes, especially).
I am not advocating the use of the Windows API over any other API. It is just that these 'theme' interfaces are in my opinion a terrible idea. They do not ease the use of the application at all and they make the application use way more RAM, just for what? A nice looking gradient-filled interface? Pointless at best. An anti-virus program should be fast as hell in my opinion, and Norton is the epitome, leading people to think that their computer is supposed to be so slow. I hardly ever see a 'theme' interface in a GUI application in Linux. They stick with Qt or GTK+ (which can of course mean following KDE or GNOME standards), or even Tk, among a few others. It must not be a total waste of money/resources/time for Symantec to hire graphics designers to make a very graphical interface (meaning the buttons are not just Windows buttons, they are coloured or have a gradient behind them, rounded edges, crap like that).
I am advocating standardising any GOOD user interface. I do not think any of them are perfect right now. At the very least, GIMP now uses FreeDesktop icons which are supposed to be standard. What would be great is if this standard could be cross-platform too. So far we have something we are just used to, not really standard, and probably not even very efficient. Consider our menu. W
It's not the same set of problems. FOSS shares the fundamental problem of proprietary software: if no one wants it, it will slowly die. If no one buys it, then it doesn't get better. In both models, the software has to come out strong and useful if enough people are going to use it for it to gain more developers through interest (FOSS) or through funds (proprietary).
Sadly, you may be right about this, judging by the vast majority of responses from developers in this article thread so far.
Almost as one, the FOSS developers here seem to have responded (paraphrasing): "Nobody is paying me for this work, so I'll be darned if they're going to tell me how the UI should be designed for usability." And even some non-developers have defended that stance.
This suggests that, indeed, there may be no solution to the problem coming from the community of FOSS developers itself.
But what if we were shamed into it?
What if Microsoft, or Apple, came out with a public statement that "FOSS products have extremely poor usability, because their developers refuse to accept usability input." It would be hard to defend against such an accusation, since we have almost no cases of devs accepting input from non-devs.
This would cause a huge uproar, I'm willing to bet. Maybe that would shake us out of this impasse.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
I think one important aspect is motivation. And this is wider than just open source software. I think everybody would like their software to have better usability. But, in the end, your resources are limited. So you are going to do the things you are most motivated to do. Improving software usability apparently simply doesn't rank that high.
On the other hand, I have to agree with other posters that usability depends on your users (give me programmable interfaces over GUIs any day, but I know others have the opposite preference) and that a lot of open source software actually does very well as far as usability is concerned.
Please correct me if I got my facts wrong.
without quotes
Eg. man emacs
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.
that would pretty much do it for us.
First of all, good to see you talking about usability. Any talks about improving software should be stimulated.
Let's get back helping you software engineers, designing better interfaces. Perhaps you have heard of Agile or extreme programming; making use cases. This makes you think about what you are going to build and with a target audience in mind. If you want feedback about your plans and goals, talk about potential users about your ideas. These are really fundamental basics. Usability is not a flavor you dip your software in afterwards.
Cowards' hints:
- Investigate the "market"; what are competitors, or products alike and what is there to improve for you? With other words, what's your contribution or added value?
- Structure code: seperating code from GUI code
- There are styleguides out there your users are used to. Be consistent!
- Involve other disciplines, e.g. (graphical, interaction) designers, psychologist (human factors) etc from start
- Agile method makes use of short time periods (2 weeks) to show your result to stake holders (who represent users) and let's your adjust/redesign/refocus/continue ;)
- If you really starting a new project, read parts of ISO's on usability (ISO 9241, ISO TR 18529, etc)
- Google for interaction designers. They are growing in numbers, contact them to get involved! If your idea is good, I'm sure you get help.
I'd say it's the other way around: coders who can't design have absolutely no business working in software.
Design, including the GUI, is an important part of making software successful and coders, who think they are the real heroes, are far too quick to discount it.
Engineering is the art of compromise.
I agree.
Some other things that get stuck in my crawl:
- If you can't solder integrated components onto a motherboard, you shouldn't be allowed to program
- If you can't fix a piston engine, you shouldn't be allowed to drive
- If you can't write your own movie scripts, you shouldn't be allowed to act
- If you can't build your own lunar rover, you shouldn't be allowed to drive one around the moon
- If you don't develop your own film, you shouldn't be allowed to shoot photography
- If you can't build a brick wall, you shouldn't be allowed to pour design buildings
- If you can't sing, you shouldn't be allowed to play drums
Design is a set of skills, just as programming is, and it can lend a lot to the process, and is noticeable when absent. The fact many programmers think coding skill makes up for their lack of design and human factors knowledge is ridiculous.
The best design tool in the world is a blank piece of 8 1/2 x 11 paper. Learn to use it.
I can answer that as soon as you can tell me how to fix the poor usability of commercial applications. Windows, OS X, and the application software for those systems have some really serious usability problems as well.
In fact, Gnome and KDE at least have an excuse: many of their usability problems are problems they inherited when cloning Windows and OS X. What excuse do Microsoft and Apple have?
I for one think that free software often lacks in usability, because obviously as development resources are limited, in the world of ever evolving technologies, keeping functionality at par is a higher priority in any project than making the functionality easily accessible to the end user.
They shouldn't, Fuck them pseudo experts of a mythical science.
He clutches at every imaginable straw but fails to mention to obvious: economics. People can't eat and write great free software as well. Every 'free' software project that isn't harder to install, manage or with a less usable UI than the commercial competition is sponsored, and is a defacto commercial project anyway.
FS programmers need to get over the idea that's there's something wrong or evil about being paid for your work. Getting paid means you can do a better job.
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."
Don't thank God, thank a doctor!
What the hell is he talking about? What's the distinction he's trying to draw between "Show me the code" and "Patches welcome"? I honestly don't get it.
Completely agree. What OS projects need is a UI champion: somebody who is well respected as a coder and who takes it upon him/herself to pick up these UI complaints and makes them a priority. I guess the article describes something similar, but it talks about the project leader. A UI lead could be different from the technical lead though.
The problem is that few such people exist. Most OS programmers are fairly hardcore coders who don't care much about users with a different background (this can also be seen nicely in the discussion here). Folks who can program and are more interested in UI (or UI designers to begin with) aren't typically the people who want to spend day and night coding, and so they don't typically contribute to projects.
EagerEyes.org: Visualization and Visual Communication
The KDE project is always looking for usability experts. More specifically, I would love a usability expert to have a look at the KDE System Monitor (task manager thing). I'm more than happy to implement changes.
How does a developer evaluate the ability of a designer? When lead developers promote other developers (i.e. to having access to the tree), they can do so based off of experience with how well those persons patches are and how dedicated they have shown themselves to working on the project. The UI is a different beast.
Programmers generally cannot tell who is a good designer and who isn't, making it difficult to even pick the first UI designer who can extend the network of UI people. Add to that the problem that UI folk generally even come to a project only once the project has gained attention. At this point, there's already a lot of work done on it.
His solution is to document design first - great. Now tell that to the hundreds of software projects that have been started. And relying on developers to create those documents is foolhardy for the same reason that using them to create a usable interface is - there are designers and there are coders.
Also, the documentation suggestion and user-test suggestion is time consuming, and he acknowledges that. However, he fails to account for the reality that few projects are planned to be big. They begin as really small scale projects that grow. So the documentation can only even begin after enough interest develops (i.e. the original coder rarely has the interest in doing it the proper way - remember your claim that it's generally a scratch an itch problem). The user-testing is an even bigger problem. Who's going to fund this? Didn't you just claim that the users tend to be developers themselves? So how are you planning on doing these tests without any money?
His modularity comment is incorrect. He's arguing that layering a GUI on top of an existing text UI (i.e. ls, etc) produces a bad result. Of course when you start layering UI (especially UI targetting different interface capabilities) you're going to get unusable results. It's not the fault of the people who wrote the ls tool - it's the fault of the GUI developers. You should be using the API they did for your GUI.
The more important critique here is that usually the code isn't modularized enough into a backend library providing the functionality and an executable front-end responsible for the user interaction. Most traditional unix command-line tools aren't complex enough to require a separate library, although there might be some that should be split.
However, its many times easier to write code that parses output from command-line tools than to write the code to perform the function - laziness is the problem here.
I was going to post pretty much the same thing. The problems that free software once had concerning usability are long gone. The real question now is 'how are we going to make it better than Windows or the Mac'. And for that it is vitally important that it is easy to find the bugtracker, post to it without requiring registration, and take what people say there seriously. Especially the last part is important, as it happens way too often that people simply get ignored. As an example, last time I checked, the Russian version of OpenOffice didn't come with a Russian spellchecker. This was entered in the bugtracker, which attracted a lot of newbies who didn't know how to vote and posted reply's a la '2' instead, and just for this the bug was closed 'willnotfix' if I recall correctly, even though the bug demonstrably exists and has by far the most votes. This is just one example, but things like that happen all the time, it's almost like the developers care more about bureaucracy than about improving their software. Anyway, sorry for the little rant. As I said, free software usability has greatly improved.
living with Ubuntu - http://brownn.wordpress.com/
I certainly hope its not based upon the presence of a "Start" button in the lower left corner of the desktop or Mr. Clippy.
Seriously, what's the baseline for evaluating it? How is the analysis affected by the target user group? For example, I'd expect that an FEA application to be totally unusable by non-engineers. They would be unfamiliar with the various objects and methods involved and, as a result, the layout of application menus would make no sense to them.
Have gnu, will travel.
I think the biggest single usability problem is that our current coding tools and 'best practices' force interface design and low-level code to be merged together in a big monolithic box called 'the application'. This is a technological dead end.
Increasingly, what I do on a computer is NOT 'run applications', but 'browse data and construct new data sets'. But the tools used for 'application design' are locked into a developer-user separation that gives us this negative feedback cycle: coders can't design, interface designers can't code, and users whose data and machine it actually is and know what works for them have no way to modify the design of either.
Find a way to SAFELY separate 'interface' from 'internals' at every possible level so that the USER can tweak the interface to 'scratch their own itch', and you'll see an explosion of open-source interface design similar to what happened when the Web appeared.
A key I think is switching from imperative, even OO programming, to a dataflow mindset. Ted Nelson is on the right track with Xanadu and 'applitudes', but he can't coherently describe his vision and nobody is listening. And he's patented his ideas. Pay attention to him, filter out the crap, then try to work around his patents.
Look at Cells, FrTime, Flapjax, and spreadsheets, then generalise that model. That's the missing layer we need to have instead of things like COM. It might be possible to write something like that as a layer over D-BUS, expose *all* data in a system from the filesystem to mouse clicks as *fully* scriptable dataflow events, then add a *thin* GUI layer that lets anyone at runtime construct and run an 'interface' from a small text file that aggregates such events into widgets.
If you want, then add a thin GUI builder which lets you construct such a text file by pointing and clicking, but it's not necessary (and it's necessary that ALL functionality exposed by a GUI layer ALSO be available to a non-imperative, composable scripting language).
Then you'll have something which could seriously take over the world: a Web-like dataflow fabric which can construct runtime pipelines of events and filters and make tiny, user-specific 'tasklets' much like accounting types build spreadsheets.
Even the simplest of 'users' would then be able to be 'interface designers' in the same way a file manager allows anyone to be a librarian. Let people publish such tasklets freely to the Net (like RSS aggregators or Google mashups), and you've solved the interface problem.
The key is to make all your data-processing widgets fully composable, which means to make them pure-functional, which is what existing OO frameworks aren't.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
As a UI designer by trade I always like to throw things like the iPod, Google, Firefox, World of Warcraft and Nintendo Wii into any argument about the validity of designing for your users. These products success against their competitors speak volumes about the impact of a good user experience (the user experience is a vastly more complex beast than just the UI, but this is what usability is all about - designing the environment to try and improve the user experience).
Yup these are mostly commercial products, probably because commercial products have a vested interest in continued use by their user base as well as growing their user base. Not to mention usually having more funding to be able to pay for user experience professionals.
As has already been mentioned numerous times, most open source/free software is written by the developer for the developer. This is fine as long as the people working on the project are happy with a niche user base. If you are developing something for yourself and making it available to others then more power to you.
There is always exceptions to the rule usually where need or cost outweighs usability.
If, however, your are looking to grow your project and see widespread adoption/interest, you are much more likely to see this happen if your interface appeals to a wider audience. Of course you shouldn't design for 'everyone' but you target the user types that you want your software to appeal to.
Most free software is inspired by not-so-free software, and software in general has poor usability. Once mainstream software becomes highly usable, free software will too, since they will clone the good out of it.
As it is, there is not much to copy or, as one might put it, "be inspired from."
Most free softwares are command-line based. I don't think "designers" can do any thing fancy about it. For GUI programs, I thinks the most vital thing is to assemble a universal GUI guideline including all widget libraries such as GTK+, QT, and Tk for free software.
Ok, here we go:
I could go on and on, but I won't. Surfice it to say:- In other words PLEASE can we have editable and transportable .rc files for the Desktop environments, the Window Managers, and the major apps. which set up the menus and shortcut keys, and please make sure they are consistent across Distros, Window-Managers, and as well as the programs themselves. Yes I am prepared to do my share of the slog to get this sorted, because it's actually really important.
The real problem is that "usability" is a giant vague umbrella term encompassing several sub terms that, in some cases, have contradictory goals.
For example, consider efficiency of use versus learnability. In my opinion, vi is /very/ efficient, and it's quite obvious that that's its focus; however, it's pretty far down on the learnability scale: all you get when you first use it (in general) is a pile of tildes on the screen and some cryptic text along the last line. It doesn't help that its control scheme and modal model are different to everything else ever made.
On the other hand, consider gedit (or most modern GUI-based editors): learnability is very high since each one is fairly similar to the last. Sure, there's different keybinding, a different menu layout, but at least those are discoverable with a little poking around. Efficiency-wise, compared to vi at least, it's going to lose: eventually you're going to need to move your hand to the mouse to do something faster than with the keyboard.
In the end, using two input devices is almost assuredly going to be less efficient than one, but the keyboard alone (coupled with the 80x25 "resolution") doesn't engage one visually/spatially, which is practically the only method of teaching a computer has.
Essentially, vi has the learning de-coupled from its usage, which is exactly the opposite in gedit, where they're strongly coupled (e.g., the toolbar buttons that tell you what they do with their labels, then verbosely tell you what they do with their tooltips, then illustrate to some extent what they do with their icons). The two goals and their respective methods are, I think, fundamentally opposed to one another.
And this is why there are so many pundits of the "usability" of open source software: when they say "usability", they really mean "learnability", which is only one aspect of the field. At the end of the day, it's just a preference: would you rather invest heaps of time in an application that's hard to learn but will ultimately make you more productive, or start with a medium level of productivity and have it capped near the end? It also depends on how often you'll be using the app: programmers spend 80% of their time in a text editor (or 100% if you're an emacs fan :), but a CD-burning app used once a month needs to be more learnable, since there's a good chance you'll be forgetting how to use it a little bit.
The real problem is that you can't possibly know the learnability or (maximum) efficiency that an app is going to provide before using it.
I think this guy hit the nail on the head, and to GP:
i'm glad those people are a minority, unfortunately for every one of those there are many who simply walk away silently. Personally, I think that's tragic, and I think the parent post outlines a proper compromise in regard to that kind of conflict.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
Here is a definition that I heard years ago for Apple/Macintosh "computers". "A computer with training wheels you can't remove".
Having used a few of the above machines, I have to agree.
.
"Oh, god, what do I do now?"
There is this simple fear of making a mistake. The fear of what will happen when you hit "Return." The command line argument can be complex, arcane and unforgiving.
It is not an issue of usability, but an issue of the users.
I recently created a really simple website. I am fully aware of the fact that I do not have design skills, but I do consider design important. So what did I do? I simply copied the entire design of another website and replaced the content and code with my own.
This shows how important it is to be clear about software and design license issues, but that is not my point here.
At the moment, it is often not easy enough to copy good design. Design should be as easy to copy as it is to import any other 'library'.
I think the problem is that people don't look at design as a reusable component. People are happy to use libraries when it comes to login systems, connecting to API's, database access, etc. Design should be treated the same way.
Good examples out there:
* Wordpress templates
* Skins in general (but many developers fail to pick a good default for their product)
* The default good looks of Ruby on Rails projects
But we need more. It should be much easier to copy good design elements from other software, without having to do much hacking.
In fact, it should be so easy to change the look of a program that designers can do it without learning too much coding.
.... it's BILLING.
It's one thing for an app to be useable/useful/have a good gooey. Firefox is a good example of all three.
Then there's the horric case of The GIMP - a great paint application. Seriously. The MASSIVE fail point? Linux users bill it as OMG PHOTOSHOPS. As opposed to OMG SUPAR PAINT APP. Gimp is about as Photoshop as an internal combustion engine is a nuclear reactor. The common perception problem is that to just about EVERYONE, Image Manipulation == Photoshop. Which really isn't the case. The GIMP is much more of a painting application along the lines of Corel Draw or Painter.... but the programming-based userbase is deeply sucked into the idea that pixel-pushing === photoshop. Hence the GIMP being marketed as a Photoshop-alike, when in reality the applications have almost nothing to do with each other.
My point, ultimately, is that a huge amount of FOSS is great... but is indirectly crippled by misrepresentation. If you pick up the GIMP because it's been billed as FOSS Photoshop and get burned - and never use it again - the fault isn't the application. It's the advocates failure to understand the specific needs of the targeted market.
Aside from being free to modify the software to make it suit your critical gaze, or pay someone else to, you are also free to not use it at all! Or even better, you are free to print the source and stuff it up your whiny fucking ass!
Poor usability in FOSS is a myth like many others. "Usability" is most often just compared against Windows or Apple and not made as a study of the subject: ie. "it doesn't do it like Windows so it sucks".
That is not USABILITY!
My father (aged 70) got a SuSE some months ago... he was very sceptical... 5 days later he called and asked why people pay for Windows. He just uses the web, e-mail, word processing, instant messaging and skype. ...and since he nedde multilanguage approach (at least Polish, Danish, German, Spanish, Portuguese and French) he loves Linusx where he doesn't have to change the keyboard layout to use a different language.
Usability... yeah, tell me about it...
The article sounds more like a rant than like constructive criticism to me. You can do a lot about the usability of your software by providing visual clues, making your program look like existing programs and raising CLEAR (parameterized) error messages if you really need to- to name a few things. But the least you can do is ask some non-tech coworkers to take a look at your program and see where they get stuck, then fix it. It's really not that hard.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Taking point by point:
:)
"Weak incentives for usability."
I think that the fact that afaik most free software is written for programmers themselves provides quite an incentive to make the program nice to use.
"Few good designers."
Agreed.
"Design suggestions often arenâ€(TM)t invited or welcomed."
Partly agree. Look at awesomebar. Its hated mostly because its new(among other things). In more community-driven developement it wouldnt be accepted. Imho smaller/less radical design changes are accepted more easily.
"Usability is hard to measure."
Partially agree. Usability is partially subjective, and hard to measure. But some aspects of usability can easily measured: how many mouseclicks takes to accomplish some task etc.
"Coding before design."
Disagree. Because most of projects evolve from smaller to larger software(featurewise) unpredictably, designing interface before coding is almost impossible, as its not known what features it needs to accomodate. Making too rigid design decisons too early asks for trouble when new featurs should be added, but the design isn't flexible enough to accomodate them.
"Too many cooks."
Agree on larger projects.
"Chasing tail-lights."
Especially agree. FOSS-developers try too hard to get all users to use their software, and are willing to bend towards mainstream software, insted of making software to themselves and doing what feels right.
"Scratching their own itch."
Especially don't agree. This is the main point where i don't agree. Free software has no need to grab markets and all users. Why is all ui design concentrated on making software easy to use for new users, instead of making software easy to use for power users. Right tool for the right job, noob software for noob users, and poweruser-software for powerusers. IMHO Linux and free software in general needs to get back the 'from hackers to hackers'-attitude, because thats what we do best. Quoting:
"So software thatâ€(TM)s supposed to be for general use[...]"
Not all software is supposed to be for general use. I make software for my own use, and thats enough. I dont need no stinking users....
"Leaving little things broken."
If it hinders usability it will be fixed, if the reward is greater than work needed to fix it.
"Placating people with options."
And this is bad thing because? Quote:
"The number, obscurity, and triviality of such preferences ends up confusing ordinary users"
Again. 'Ordinary users' don't matter. And making good default settings, and showing only relevant options in main ui(about:config vs Preferences-dialog) relieves this problem a lot.
Cases: Awesome-bar. Start-menu in Vista(I atleast would like to have option to use XP-like start-menu).
"Fifteen pixels of fame."
"Design is high-bandwidth, the Net is low-bandwidth."
Agreed.
"Release early, release often, get stuck."
Just add configuration options, and depreciate them if necessary.
"Mediocrity through modularity."
Imho modularity can't be blamed for bad design.
"Gated development communities."
This one I don't understand. If print-dialog sucks, identify the project it belongs to and complain there. It will be fixed or not, depending on other conditions, like ones above.
KDE4 has great technology and some great designers. They are open towards new ideas and concepts and seem to be able to think outside of the box. This is why I like KDE4 so much. One thing that they did was a major cleanup of the interface so you no longer have +100 buttons per program. Take a look at KDE Raptor and you will realise that KDE4 is going to bring major usability innovation for the enduser.
I have learned and used a lot of GUIs (Windows, Mac, Gnome, Fluxbox, Blackbox, IceWM, Openbox, E16, E17, JWM, KDE3, XFCE4, and some more) and KDE4 (not previous KDE's) is the first interface I really came to like to the extend that I will be making it my standard GUI.
Here be signatures
Alan "About Face" Cooper's book "The Inmates are Running the Asylum" deals with this topic. Its main claim is that software developers simply cannot write good user interfaces.
Why? Because programmers are EXPERT users. Thus they tend to design interfaces intended for other expert users. Those interfaces are very plain, give out information that is only easily available, hard to remember how to use, but get the job done fast and effectively. (Once you learn how to use the tool).
When you let marketing in, they want to push a lot of NEWBIE features like happy paper clip assistant, set-up wizards, help files appearing automatically when user invokes an action etc. These are helpful for newbies and first-timers, but tend to get annoying very fast.
Most users - according to Cooper - tend to get over the newbie status quite fast, but will never reach expert level. They will use the software to get their job done and will remain as INTERMEDIATE users. And this is where the problem is: software in general is not designed an intermediate user in mind.
Developers and designers should ask themselves "what are the TYPICAL USE CASES that my application will be used?" and design around that.
If a typical use case for an application is to print out text, then do add print icon to the toolbar. Other features can remain, but they can be "hidden" under menus.
Since we all love to hate Microsoft, take a look at default buttons on Word 2003 toolbar:
- New Document
- Open Document
- Save Document
- Permissions - Information Rights Management (client installation wizard start)
- E-mail
- Print
- Print Preview
- Spelling and Grammar
- Research
- Cut
- Copy
- Paste
- Format Painter
- Undo
- Redo
- Insert Hyperlink
- Tables and borders (shows floating toolbar)
- Insert table
- Insert Microsoft Excel worksheet
- Columns (formats how many columns there will be from that point forward)
- Drawing (shows drawing toolbar)
- Show/Hide unprintable characters
- Zoom level
- Help
- Read
- Another help toolbar with text "type a question for help"
And that was just the first toolbar. In addition to that Word is displaying a formatting toolbar.
How many of these functions are TYPICAL? Document map? Document permissions? Research? Two separate help widgets? None of these really. So why are they on the screen eating up attention space?
Microsoft actually did rather good job in re-designing Office 2007's user interface.
Usability is inversely proportional to the number of mouse clicks for the user desired feature!
There is sometimes also a certain stubborness preventing usability, and I refer here specifically to GTK and The Gimp and their visions about MDI. Some people just don't like having every toolbar and painting being a separate window that has to be managed separatly on your desktop, and there's nothing they do about it, nor anything in GTK to even be able to fix it.
usability standards
the reason humans will never reach the stars is because of our shit software. we'll fall some number of man hours short somehow, and it will be equal to the number of hours someone spent clicking a dialog asking if you really clicked the last dialog or the software did. meanwhile all the guys writing the good software (which could have saved us all) will fail after spending hours making it so that their apps can update itself online just like 90% of all software does these days, missing some other breakthrough. the guy creating the standard to make it so programmers and users alike can get more done (which could have saved all of us) will lose his work when MS word does one of its formatting tricks. his manager will miss the meeting about it (which was our very last chance) because Outlook's version of getting attention is to leave a dialog that won't f*ck off on your desktop all day. the aliens (who can see our possible future vs the one we have) must be laughing their arses off.
there are no standards for commercial software, and its pretty unfair to insinuate that OSS is uniquely unusable when the world's most widely used spreadsheet package still asks you to save changes to documents it has opened in read only mode. oh yeah and if you cancel closing one document (because you aren't sure what it thinks you've changed, if anything), all the documents you HAD successfully f*cked off will reappear. one can only wonder what sort of development and quality feedback process (if any) contributed to such a situation being unfixed in a piece of software that is what, 20 years old?
so in the face of that why is OSS in particular suffering from usability issues? too many people implementing different ways of storing user preferences, different ways of opening and closing a program, different ways of giving software the ability to update itself - it leads to mass confusion for users and programmers and slows development. as a windows developer i can't imagine the confusion deciding to put my preferences in /etc, /usr/etc, /var. not that we don't have a similar situation on windows but we have IDEs and languages so closely coupled to the one OS that you will get exceptions from putting things in the 'wrong' place, if you somehow missed the fact the API will do it all for you in the first place. i hate to say it but this is where we need to go. in this way the Java VM was still one of the best things we ever got going. if dotnet was cross-platform, we'd be *much* more sorted, but still a long way off.
we have some great languages now, but we need to go beyond visual studio's ability to create a hello world app vs a hello world webpage, and turn it into something that really allows programmers to start writing their app, rather than all the little things that make a program into an app (that then bind you to ways of having to do things that you hadn't thought of). and these ways of doing things need to be as standardised as their end appearance. gigabyte easytune anyone? want a 4x4 on your desktop in order to read a few system monitors? did you open the program to read the monitors or see the 4x4? oh yeah, have fun getting rid of the monstrosity, because who knows where they've hidden the close button.
there are fabulous libraries for doing some the things i mentioned, but even deciding on one to use and then making it work with your code is just too tedious. i hate to say it but sometimes having one way of doing things rammed down your throat is better in the long run. but we need to go further and have accepted ways of doing things, both as programmers and as users.
standards that govern the way software interacts with you would increase productivity on computers worldwide. that means absolutely everyone. it shouldn't be acceptable that happening to be hitting a key while typing in one program can lose you work in another program - why aren't popup dialogs banned? because noone is there to ban them. someone needs to kic
It's OK Bender, there's no such thing as 2.
Everybody can make good useable software all by themselves. No degree needed, no teams like Mac OS X, Windows, Gnome, KDE. Not even a small team. Case in point, just look at the mounds of well designed freeware and shareware for the Mac, most of it produced by a single person.
How do the one-man shops do it? Good tools for the Mac, trivial installation, easy to use. And good attitude, in the sense that even the dorkiest software writer like me just knows a program icon and a GUI screen at minimum are expected, or no Mac user will even look at it (even if 99.9% of the work is actually done by underlying Unix command line programs). So we complain for a week, think for a day, do it in an hour. Even if my icon looks awful, or my GUI layout begs for its shame to end, it is a placeholder and plea for help rolled into one. If the software has the least merit, believe me, some kind soul will take pity and send over a nice replacement. Stuff it into its place, add a thank you line in the About box, and everybody thinks it was my brilliant work!
Seriously, that is how it mostly works, no different from the way translations (localization) now happen all the time for free software. No need for you to even say "patches welcome" or "you are free to make your own changes" or even "please help!!!".
Yes, I know usability can get much more complex than a single icon and screen. The big or complex ones are few and far between. Worry about them next year.
Gnu/Linux equivalent tools? I dare you to get the tools installed and actually working. Disagree? Even if you find the right one among the fabled 20,000 choices, even if you know how to install arbitrary Gnu/Linux software which many do not, even if you are able to get that software to work which is often a living hell in itself, the persevering have yet to discover and experience THE TREATMENT described by FooBarWidget above.
Okay, a bit of exaggeration about Gnu/Linux. That was yesterday. All the tools are there, the right packaging is happening, and other difficulties too are sorting themselves out. If the Mac and Windows geeks can do it, then surely nobody can believe that the Gnu/Linux geeks will be found wanting!
I am a developer, I am also responsible for interviewing junior developers.
If I found that someone I was interviewing had an attitude of "You accuse developers of being jerks, yet you're the one who started being a jerk. And then you expect them not behaving like jerks in front of you," even on "free" open source projects, I would consider them unsuitable for dealing with clients and potentially even other developers. Full stop. It doesn't matter if it is "for pay" or "for free."
If I were to even consider hiring them, it would be because I have a position open in a back room that I can lock and that has a sign on it saying "beware of cougar." Then I could lock the "developer" in question back there and slide the occasional pizza under the door, and never have to worry about them seeing another human being.
Integrate Keynote and LaTeX
If any chemist had the attitude of some of us software nerds, he'd most certainly be counted as an elitist dick.
Yes, a non-chemist can tell you that the floor cleaning solution doesn't do this or that. It's then your job to see exactly how it fails there, and if you can improve the formula, and if it's worth improving it. E.g., if it doesn't kill some germs, it's useless in a hospital. If it actually ends up a nutrient for a bunch of harmful germs, then you have an even bigger problem. If it's highly toxic or caustic, well, you've reduced its usefulness for a lot of situations. Etc.
If you end up dismissing it as "unless you can tell me exactly what formula to use, and the exact manufacturing process for it, STFU" -- which, again, is an attitude quite common in software -- then you are an unhelpful and unprofessional dick.
Ditto for any other industry. When MRSA appeared, the antibiotics industry set to try to find an antibiotic that kills them. They didn't go "if you can't make a better antibiotic yourself, STFU." Yes, probably the users didn't know _why_ Methicillin doesn't kill this strain of Staphylococcus Aureus, or how to fix it. Which is why they reported the problem and let the experts fix it. Otherwise they'd have just made their own medicine in the first place. And from there it's the expert's job to figure out the exact details and how to fix it.
Your job is to take that, essentially, bug-report or change-request, and see what can be done about that. Sometimes nothing at all. Sometimes it's not a bug. But nevertheless, it's a piss-poor defense to expect that the user fixes _your_ bugs, and that only people who can fix it are allowed to offer feedback.
And, look, I'm not saying that you shouldn't take pride in your work or skills. But more people need to realize that a bug report isn't an evil personal attack, nor trying to make you look bad, or anything. You don't need to get into an "well, _you_ can't even code that much, so STFU" counter-attack. Yes, you know more about programming than the user who filed that bug report. The knows it too. Otherwise he wouldn't need your tool or your help in the first place. Being helpful isn't some kind of loss of face, that's all I'm saying.
A polar bear is a cartesian bear after a coordinate transform.
Why should designers contribute in the same way as coders? Design is not so much of a constant-effort requirement in a project. Perhaps a more successful approach would be to form a team of designers and enabling coders to help implement their examples and then have this team jump from project to project making design proposals/contributions before moving on to the next project.
This approach would get around the "trust" issues that you raise through the community regard for the teams overall reputation.
Make the UI Consistent!
Books always have past on one side ( in English, that's on the left ),
always have the New Stuff on the other side ( English, that's on the right ),
yet NEARLY ALL apps I've been forced to use don't make the
Cancel ( past-setting is good ) / Commit ( change, new-setting )
arranged consistently!
Makes me wish the coders would be forced to use a system where all apps used /dev/random
to locate ALL UI elements,
until the "get" it.
Another that burns my ass ( and many many others, too ) is
OO.o's
"lets muck your data,
but give you a little happyface,
to tell you that we just did that"
INSTEAD OF
popping-up, and ASKING "do you want this automatism?"
for any automatism that hasn't been OKed yet.
( this was reported as a bug years ago:
they apparently *oppose* asking-first,
permitting our data to ourselves )
I hope their doctors do the same with their health-care / DNA-therapy.
Consideration for our work would be a nice start,
but enforced mucking it apparently makes some sh*t-head egos bigger.
Cheers.
I'm happy with the 'get it working first - then make it pretty' approach taken by most.
Usability and aesthetics may be closely related for technically minded people as they generally appreciated ordered structures and find a (ie their personal) logical flow to be visually comfortable. But equating aesthetics and usability is plain wrong.
Tiny example: You can make your "Yes / No" dialogs [sic] as pretty as you like but if you randomly switch the button positions and ask ambiguous questions, or don't indicate the outcomes, then your users are going to be very frustrated.
Aside: On that point about logical flow - people will use your program in a different way to how you design it. I'm always fascinated when I watch other people using browsers (testing websites I've designed). They of course take different routes through the website, but just how folks use the browser differently is quite interesting itself.
Article is too wordy & suffers from poor usability
OSS is maintained by--let's face it--geeks. The fact is that geeks LIKE things complicated. Easy-to-use software is, well, too easy to use, and isn't a challenge to try to figure out. Where did Macs get the reputation as a "toy" computer? From geeks, who found it TOO easy to use to be fun for them.
Geeks adapt much more quickly than the average bear to software that isn't particularly usable (i.e. Windows of any flavor). That's why OSS will, IMHO, never become really usable for the masses--because the vast majority of people who use it don't notice that it isn't usable!
Things the help design in my not very humble opinion.
1. If you are duplicating a commercial project then duplicate the interface unless you have good reason not to.
Since much of usability is 'what you're used to' then this makes it easier to get people to switch.
2. GUI and command line interface.
Another poster pointed out that autocad has GUI and commandline interfaces.
On NextStep you could usually do things either through a GUI or through a command line. The two weren't always the same -- e.g. it may take 3-4 commands to duplicate what was done in a wizard. The documentation for the commands was sparse. Much of this is true today for Mac OS X, but the command line documentation is even harder to find.
Although confusing as hell for other reasons, the configuration package for IBM AIX had a neat feature: As you selected options in the configuration panel, it built the command line to do the same thing in a 1 line window near the top of the panel. For people who were trying to become wizards, this was a useful way to find out what command did what.
3. Consistency, consistency, consistency.
One of the nice things about macs is that once you start to get to know your way around, much of what you learned for one program translates to a similar function in another. Those things that most programs do, (Open a file, print, preferences) are usually in the same place every time. The layout deeper into the program is more variable.
For those of you who worship the command line: Look at the huge variation even in the submission of options to the command line. E.g compare that of find, dd, rsync, and ls. This got me into trouble on my first sysadmin job. cp -i is interactive copy. rm -i is interactive remove. di -i must be interactive disk initialization.
Nope. di was disk information. -i meant initialize. Fortunately it was a client machine, and had no user files on it. (I won't swear the program was di -- this was 20+ years ago on NextStep 2.0)
Yesterday we had to help a friend set up his email on his new used Mac. Much confusion ensued before we discovered that the email account setup interface for Leopard and for Tiger are quite different. There may be a good reason for this change.
One graphic design program I tried had numerical entries for some tools, drag and drop for some tools, and both for some tools. But in some cases with the both, it would show you the current numerical selection, but you couldn't change it, even though the widget appearance was no different from one that you could.
The school where I have may day job uses a school information management system called renweb. It does some cool stuff, and collects a lot of information under one roof, with modules for grades, assignments, lesson plans. It's very modular -- there are some 40 different modules in it.
But:
You can't have more than one module open at a time. Which means if you need information from another module, you are stuck.
You can't minimize the application when you have a module open.
If you click the exit button, in some modules you are prompted, "discard changes", some save automatically, some discard silently.
The exit button can be anywhere on the panel, and not always next to the save button.
A while ago my personal web page for my tree farm. (My other job) had dual navigation bars, a horizontal one under the logo, and a vertical one on the left margin. I suckered my inlaws into test driving the web site, and watched. In particular I watched the mouse. It kept wandering between the two nav bars.
I tore into the code, and consolidated into a single nav bar.
4. Code last.
One of my CS profs insisted, "Write the user manual first." I think that helps clarify a lot of how the internal coding happens. Open source needs fast UI proto typing tools. If you want to get non-coding designers in on the fun, then we nee
Third Career: Tree Farmer Second Career: Computer Geek First Career: Teacher, Outdoor Instructor, Photographer.
There is a lot of criticism for developers who build things for themselves without being considerate of other users. "It works for me," draws a lot of fire as a typical geek response to others' difficulties.
The other day, I had a very strange experience. I stepped outside my house first thing in the morning, and when I came back in, there was a young boy helping himself to my breakfast. Apparently, the neighbor's child is an early riser and got bored with how quiet things were at his place.
I was mostly amused, and made some more breakfast for myself. The young boy didn't complain about my cooking. If he had, I would have welcomed him to eat his own food at his house. Why should I cook my breakfast to please the neighbor's child?
Now, if I were running a restaurant, things would be different. But most open source software isn't restaurant fare. It is personal breakfast, with a recipe passed on to a neighbor. The neighbor is free to change things up if they prefer. Indeed, the neighbor can open a restaurant using my recipes as a base. They can alter, combine, and otherwise innovate as necessary to meet the needs of _their_ customers or themselves. But that doesn't mean that _I_ need to change anything.
They shouldn't complain that I am not meeting their needs as a cook. I am not their cook. They could hire me as a cook and make any demands they like, or they can hire their own cook. If they want to change color, flavor, quantities, or whatever they can do it themselves, pay me to do it, or hire someone else to do it. But it certainly would not be appropriate to complain that my breakfast doesn't suit them.
My breakfast is for me. I make my breakfast the way I like it.
the simple solution is a three-step process:
1. charge for it
2. listen to what your paying customers are telling you
3. hire professionals to do it right
yes, yes, you could in theory skip step 1, but you'll find that the quality of feedback in step 2 would be reduced by several orders of magnitude
you can also skip step 3, but again you'll find that the absence of monetary incentives reduce the quality and predictability of results to the vanishing point
free software is almost always - for the many reasons outlined in the original article - worth exactly what you paid for it
free software is a great way for novice nerds to get experience [thus becoming hard-core nerds] but just remember that an amateur basketball team (or any other kind of team) will never compete in the long run with a professional team, for reasons that should be blazingly obvious
Nothing bugs me more than a piece of software that insists purely on mouse or purely on keyboard. Except perhaps an environment that has utterly inconsistent keyboard shortcuts.
I like Windows XP, and Office (there, I said it) because it really has stuck to the rules around a common user interface and several ways to do everything. A lot of what is in there has not changed since it was all shamelessly stolen from Xerox / GEM / Lisa.
The other great thing about Office is the customisable toolbars and the ease of changing keyboard shortcuts around, and moving things around to where you want them, and floating stuff to optimise screen estate. (Although this has holes - on IE7 for instance you can move some toolbars/menus but not others - what's that about?)
I haven't played with OpenOffice enough yet to see if it can compete there - but certainly GNOME/Ubuntu has some shortcomings in this area before you even get as far as the app. That said, Nautilus makes a damn sight more sense than Explorer ever has.
I speak fluent vi, because for certain editing jobs it's a very efficient way of going mouse-free, especially if you're doing a ton of search/replace.
I suppose what I am saying here, in a rambling way, is that in a lot of FOSS apps you get what you are given and there's not much that you can change. You can make Windows Media Player look like pretty much any of the media players available for Ubuntu, but the reverse does not apply.
But of course you have already made the choice, Neo...
"... and more and more now there are all kinds of electronic goodies available" -- Pink Floyd 1972
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
As a UNIX admin, fuck you. Maybe you've forgotten who the hell you write code for?
If it's "ME, and I'm a developer" then fuck you twice, you're going to lose mindshare to Solaris, fast.
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.
You are delusional. I'm willing to bet you haven't worked with/been a Windows administrator. In fact, you don't seem to be a UNIX admin either. Also, talking about UNIX in such a broad, oversimplified manner, while excluding OS X is HILARIOUS! Apparently you are comparing desktop environments of Windows, OS X, and GNOME and/or KDE. Care to explain how GNOME or KDE are more functional than the OS X or Windows desktop environments? I'm waiting...
Linux and most UNIX systems and applications are harder to use because they are built with the architecture of the code in mind.
This is an advantage over building applications with user's workflows, and usability expectations in mind?
Users, on the other hand, focus less on the architecture of the software they are using than on the front end.
May I ask, WHAT THE FUCK DO YOU THINK COMPUTERS ARE SUPPOSED TO DO?
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.
Windows applications work easily with other Windows applications, OS X applications work easily with other OS X applications, and show me a bloated UNIX application that gets less bloated over time. Explain how this is unique to "UNIX".
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).
Cool, I think I should win a million bucks tomorrow.
Please, FLOSS volunteers, donate MORE of your time to your free projects. Keep firefox in mind, and continue volunteering your time until the fruits of your labor are indistinguishable in quality from what PAID developers produce.
Do you have ANY idea what makes free software WORK, kid? I bet you think FLOSS developers should devote more time to documentation, internationalization, usability, and then "just make it work" too? Keep on wishing...
No offense intended, but it seems to me the real reason UI designers don't have penetration into free or even some commercial projects is that they generally lack coding credibility and the clout that goes with it.
Part of the issue is that UI designers generally don't contribute code directly into a project. There is nothing more convincing to any project than a working/tested code contribution.
UI designers can talk about placement rules, color palettes, screen flow etc. until they are blue in the face. But if the coders aren't interested - and the UI designer can't code - then it doesn't happen, unless there is buy-in from a management that can enforce (usually monetary) control over the project.
This sort of tight management control is exactly what a lot of coders joined a free software project to avoid in the first place.
So, it ain't gonna happen - not on any meaningful scale.
If you want to see good UI happening in free software projects, then at least one programmer (ideally the one writing the UI) should be proficient in UI and usability (as in older times).
Essentially, you need to somehow reverse the process of UI designer specialization, and recombine the UI design skillset with the UI coding responsibilities.
Until then, we can all continue to enjoy the current level of user experience with free software.
A GUI is really just a set of training wheels for a new application. Once you know what you're doing, you can go faster without it!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
I think that open source software would show great usability improvements if open source developers had less contempt for average users. I don't know how many times I've seen people humbly request a much-needed usability improvement, only to be flamed by defensive developers and their fanboys, insisting that the poor requester simply doesn't have enough familiarity with the application (or technical prowess, or intellect, or taste, or sophistication) to appreciate the "genius" of the interface. If we want business people and grandmas using open source software, we need to grow the hell up, and stop treating them like they're a bunch of dimwits. If your software is hard for them to use, your software is hard for them to use, and no amount of elitist BS is going to magically change that.
One thing all of this random arguing I've read so far misses is the case of the developer who is also a user. I get annoyed when some know-it-all jackass "usability expert" comes to my project and starts making demands that everything will become more usable as soon as I hide or eliminate half the stuff I actually use on a daily basis. We recently went through a round of that. Let's clean up the toolbars, and make them more tidy. So everyone circled what they actually use on a screenshot, and there was very little overlap. The stuff I could do without is critical to someone else, and vice versa. So I have to come down on the side of if you want to castrate my user interface, then fork it or bugger off.
http://weblog.obso1337.org/2008/comments-on-recent-open-source-usability-article/
So, you want to fix free software by trying to get people to stop freely distributing said free software?
Sensational!
I'm a fairly experienced developer and even I find it difficult to solve problems in free software that others are actively controlling. I have to read up on the coding standard, possibly go through large amounts of code to see what needs to be changed (and how to change it to avoid unforeseen problems) and then hope that my patch gets added.
It seems much more sensible to suggest changes to current developers and let them fix it their way. I know this probably goes against the spirit of FOSS, but I just don't feel comfortable spending time trying to solve a problem that may be not be seen (or understood) as one by the people maintaining the software.
I remember the trouble people had convincing the GTK+ developers that there was a bug in the menu code that resulted in the entire menu disappearing if you clicked on a sub-menu within the "keep-up triangle". I don't think they ever got it - at least not in the bug report discussions I contributed to. The bug magically vanished recently, but I am expecting its reintroduction at some point down the line. I did consider trying to fix it myself, but developer's comments led me to believe that I would just be wasting my time.