FreeSoftwareInterfaceStories
ThoughtStorms Wiki
Inspired by this : http://www.catb.org/~esr/writings/cups-horror.html
: Daring Fireball has a good alternative perspective (: http://daringfireball.net/2004/04/sprayonusability) :) FreeSoftware has a lousy interface because UI design can't be parallelized; it needs a visionary, strong leader.
: I doubt that conclusion, but we need to think "how" UI design can be parallelized.
Q : Why does FreeSoftware have such lousy UI?
A : Because they can't afford testing.
But this is a strange claim. free-software is being tested all the time. This massively parallel debugging effort is one of the things that allegedly makes free-software work. So why doesn't massively parallel UI testing happen?
Maybe the real point is that it does happen. But whereas most free projects have bug-trackers where you can report the bugs, they don't have UI-problem trackers where people can report war-stories of confusions that they had with a particular piece of software.
Maybe the real key is that there should be a place to report UI problems and stories on project sites. Perhaps at SourceForge?
Completely agree with all of the article's points and frustrations, BUT the author gets one thing a bit.. feathery:
"So, if you are out there writing GUI apps for Linux or BSD or whatever, here are some questions you need to be asking yourself..."
This really isn't a geek thing, IMHO. OK, maybe geeks suffer from bad UI design a lot, but at the same time there are some truly dreadful designs by non-geeks as well - even down to stupidly simple things such as television remote controls and kettles, I've noticed. There needs to be a (G)UI revolution on all fronts.
Things have improved, I think, in the last couple of years. For instance, we're now (mostly) free of websites including notoriously unusable Flash/Java menu interfaces - implemented by so-called "design" companies. Microsoft have taken how-long to hammer their interface into something with extra-flashy whizzy things? But in the meantime, the majority of people are only now just coming out of a "flashy first, usability later" attitude, and many systems and websites are still very much "feature" led. This is what makes Apple stand out - they'll get the interface first, then add functionality if it fits (and also hence why Microsoft's popularity is a testament to how much consumers are led by marketing and peer influence).
I really like the idea of explicitly tracking UI design in the same way as coding bugs, but feel that it could be taken further. Currently, the whole development process is technically-inclined - CVS, mailing lists, et al. Ideally, some of those people with a handle on both UI issues and coding would get more involved in the development process - remember, the beauty of open source is that anybody can contribute. But that means finding the people who "get" interfaces, but that also know how to read code, and unfortunately I think the two have always been seen as separate. Some attempts to a). reconcile this difference, and b). bring common sense UI design, usually the domain of some well-paid "guru", to the mainstream development cycle would be interesting...
– GrahamLally (Disclaimer: Yes, I use vi.)
But that means finding the people who "get" interfaces, but that also know how to read code,
Maybe, but maybe not. If the commercial world has room for people who just sketch storyboards why not the free? Maybe SourceForge needs to allow people to upload suggested screen-layouts, user stories etc. too. Then coders can pick them up and implement them.
Actually, this is why I think Mozilla's such an important step forward in terms of OSS - by making the development suite include not just a skin-language, but an entire (open) application suite, anyone can make their own interface without having to become part of the Mozilla team.
Perhaps more UI development could be grown in a similar way - entire OSes that run a high level UI "language", or mark-up, that allow the GUI to be developed by independent teams (e.g. the way linux distros customise the underlying structure), and separately from the main codebase. Like the MVC approach now so prevalent in web systems, but for apps.
This quote from the Ion http://modeemi.cs.tut.fi/~tuomov/ion/ Ion page sums it up very nicely:
"Ion is not perfect and certainly not for everyone, but neither is any user interface. To ultimately solve usability problems to the extent possible with current technologies, applications should be written independent of their user interfaces and the UIs should be built according to the user's preferences based on a high-level semantic description of commands provided by the application." ]
More stories :
- and critiqued here : http://www.ok-cancel.com/archives/post/2004/07/osssoshowhcikilledopensource.html
My comment on the last :
I actually think Tom is wrong with this claim :
"Imagine that I were to pose the reverse statement. What if I were to say that usability specialists could do kernel development if they would only spend as little as one single thought on coding each day? Such statements are absurd and indicate a severe lack of understanding of what it takes to do usability (or kernel development) well."
The fundamental insight of OpenSource development (and maybe eXtreme / agile methods too) is that you can sometimes TradeOff smart, up-front, design for a larger amount of dumber testing. That's how OSS manages to accrete contributions from a lot of users / testers / fixers. Possibly many kernel developers contribute less than a single "thought" per day. It's what sets the bazaar apart from the cathedral.
Now the way to improve open-source software UI is not to try to force UI process, as developed in companies, onto free-software communities. It won't work. For social and political reasons.
No, the way to improve free-software UI is to work out how to make the trade-off : from smart UI design to dumber UI testing. And then distribute it. I'd say we don't know how to do it yet. But I don't think it's impossible in principle. We might take hope from things like JakobNielsen's point that you only need to TestWithFiveUsers. Testing can be done in small-doses and still make a difference.
So although "one thought per day" may not be quite right, "one test with a friend or colleague per contributor, per week" might be getting there.
SourceForge has the tools to aggregate the work from distributed coders : it has bug-trackers and CVS repositories. What we need are similar tools to aggregate the war-stories of user-interface problems. A place to post "I showed it to Uncle Bob and he thought that the foo option was going to ..." And also for volunteers to post video evidence, or story-boards of new suggestions. If this parallelization can be cracked, then OSS has a fighting chance.
Open Usability may be doing it : http://www.openusability.org/
I think by far the biggest issue is just numbers.
There are a /lot/ more programmers out there than there are people with usability experience. There are also, because of its hobby nature, a far larger percentage of programmers with free time they're willing to spend on open source projects. There are just not enough people with the appropriate skills/knowledge involved with developing open source applications.
I think the "UI design can't be parallelized" is a red herring. It's basically the same argument that some programmers/ analysts/ architects used against open source software. You can't "design by committee". Yes you can, as long as everybody involved knows how to design. Architectural UI design decisions are no harder than architectural implementation decisions - they're just different.
I think it has to do with the fact pure functionality in a program speaks for itself - you can check that it works with minimal effort - while design evaluation requires much literacy. – ZbigniewLukasiak
- UI designer gets involved with FireFox because it uses an HTML-like language to design it's UI : http://weblogs.mozillazine.org/ben/archives/009698.html
Maybe related : http://www.thishappened.org/
See also :
Backlinks (4 items)