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."
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
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 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
No, it's not, but I'd like to hear more about your shrewd point of view.
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.
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.
And this attitude is why you won't get paid for it. The free software you code is a resume, whether you submit it or not. If your attitude is "it works good enough for me, fuck you", your prospective employer will hire someone who listens to the users of their software. They wil think you're just going to do it good enough to get your money and won't care about making it usable enough for them -- and, given your attitude, they'd probably be right.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
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.
Just saying, it may not be as ironic as you think.
-- Andyvan
And that's all perfectly fine if you don't intend for lots of people in the general public to use your program, for example, if you have some sort of niche program. This article seems to specifically apply to programs that are meant to gain widespread use in the population.
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.
If your attitude is "it works good enough for me, fuck you", your prospective employer will hire someone who listens to the users of their software. They wil think you're just going to do it good enough to get your money and won't care about making it usable enough for them -- and, given your attitude, they'd probably be right.
Actually, my open source program has got me jobs, even though that's not why I maintain it, and is fairly widely used.
What does that do to your theory?
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.
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.
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
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
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
How do you know the parent even wants to work as a developer and be paid for his work? He didn't say anything about that.
Mada mada dane.
" 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.
So are absurdly narrow fixed-width columns with three or four words per line. I didn't buy a 22" monitor so I could look at masses and masses of whitespace...
Maybe your friend could join OpenUsability.org?
Mada mada dane.
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.
What nonsensical parameters do you use for tar? To extract, you type the name of the program, the operation you want, the option to use a file, what compression you are using (if any), and the location of the file you want to extract. That comes down to: 'tar --extract --file --bzip2 file.tar.bz2'. How is that unintuitive (keeping in mind that --file is needed because it's a tape archiver and you are using it to a different purpose)?
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.
Oh, vi is easy. Colon, Q, enter. You're out. If it's not been saved, use :wq! to save or :q! to discard.
That said, they're both very counter-intuitive. The user doesn't want to have to patch their software. They want it to just work, and in an intuitive and sensible way. I learnt to compute on a Dell workstation with Windows 3.11, MS-DOS 5 (or 6) and Works 2, and I am entirely self-taught. Those interfaces were more intuitive than some FOSS interfaces around today, which is why I was able to sniff my way around and orientate myself quite quickly.
Something that might solve a lot of problems is better documentation, with proper tutorials. The tutorials in Works and Windows 3 were fantastic in that they explained things very simply, and were interactive: i.e. you learned by doing.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
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?
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.
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.
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.
May I ask what the program is?
The last time I answered that my site got slashdotted and my web stats were thrown out for a month, so no.
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
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.
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.
This guy got modded troll. Seems like the mods haven't read this book, published by one of the most respected web application developers in the world. Are they trolls too for saying exactly what this guy is saying (amongst other things)?
Like I said in a previous post. Here be dragons.
"And the meaning of words; when they cease to function; when will it start worrying you?"
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.
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.
living with Ubuntu - http://brownn.wordpress.com/
So why do we still use a tape archiver for our downloaded/uploaded and backup archives in this era when hard drive arrays have totally and utterly outmoded tape drives for the average user?
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.
So why do we still use a tape archiver for our downloaded/uploaded and backup archives in this era when hard drive arrays have totally and utterly outmoded tape drives for the average user?
Because it still works? It's not as if there aren't alternatives (7zip comes to mind), it's just that this is already on all unixes already and so becomes the default. If tar was not adequate for the job, one of the alternatives would have taken over long ago.
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
Well if we want to keep using a Tape ARchiver, maybe we should change the damn thing's interface to work on files by default? Why keep a crappy, unintuitive bit of UI if it doesn't work out of naught but inertia?
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.
There is an interactive tutorial built into vi. Just press ESC until it beeps at you and then :h - you are straight into the tutorial cum help system. ZZ or :q! to get out of it.
I've been using a subset of vi[m] on a regular basis for about 20 years. It just works for me. The keystrokes are completely intuitive - provided your mind-to-finger pathway has not been totally wreaked by becoming habituated to a different editor.
That's the rub for ALL software - the package you have become used to is what is usable for you.
Well if we want to keep using a Tape ARchiver, maybe we should change the damn thing's interface to work on files by default? Why keep a crappy, unintuitive bit of UI if it doesn't work out of naught but inertia?
We keep it like that because that's how every other tool that uses tar expects it to work. And for what the tool is for, the --file option is not just there for inertia. It would be silly and unintuitive to have a tape archiver that required a special option to be able to use it for archiving to tape.
If it really bothers you that the most commonly used archiver doesn't do files by default, it's not like you can't fix it. A simple alias (lets call it far for File ARchive) like 'alias far='tar --file' will create a tar interface which allows you to extract a file with a simple 'far --extract some_file.tar'
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.
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!!
.
"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.
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
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.
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.
True, vim has a rather good tutorial, even if I'd prefer it to be along the lines of the 'old-style' tutorials.
I believe some distributions of Windows XP had a 'step-by-step' learning system which had manuals, instructional videos, and interactive tutorials. You were actually given a mock-up of the window, and guided through it keystroke-by-keystroke.
Vi, once you've got used to it, has a wonderfully powerful interface and becomes quite intuitive when you learn new commands. The problem is that someone who's never touched a computer before is unlikely to think "right... perhaps if I try pressing 'colon'... ah!" This also means they'd not be able to get into the tutorial. It is intuitive to people who've used it before, but it's not intuitive if you've never seen it before.
On the other hand, if they see a mouse and that moving the mouse moves that little arrow on the screen, they might figure that clicking the mouse will 'press' what the arrow is on. (This is even more intuitive on one-button mice, but even two/three/four-button mice are speedy enough to pick up.)
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
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.
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.
Me too ('cept mine is 24" - SyncMaster 245b)... The new browsers support min-width/min-height and max-width/max-height.
Why not use it?
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
I didn't buy a 22" monitor so I could look at masses and masses of whitespace...
You prefer tightly-packed, illegible seas of text then? I'm guessing you are not a graphic designer, having made that comment. White space is your friend and white space isn't determined by how many columns our how wide the columns are either. You can have plentiful white space in one column text.
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...
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.
Yes, but my
point is this:
The article looks
like this on my
screen. There's
no real need to
have such a narrow
column of text.
Oh, and as it happens, no, I'm not a graphic designer, I just happen to know a bit about web design and typography, having done it for rather more than a decade.
yeah, I got that much (the skinny column being no good), but my point is that one big block of text is no good either. White space is good and can be achieved even in one-column spreads is all I'm saying.
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.
... columns with three or four words per line.
I dunno how you could be getting this, unless your system is pretty messed up or you have a buggy browser or something. In the linked article, I'm counting around 10-15 words per line of text, not three or four. And that amount is near-perfect, based on scientific research into readability and line-length.
That's actually a very well-deigned web page for its purpose, and the length of the written material. 90% of pages I encounter these days are far worse. The light-gray background is icing on the cake, taking away the harshness of a white background, without inducing the text-burn of dark backgrounds.
... and then they built the supercollider.
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.