Share this
Digg
Del.icio.us
Furl
Yahoo
Technorati
Googlize this
Export PDF
Print
E-mail
TagsAs a developer-driven phenomenon, much of the best open-source software ends up being written for other developers. For example, it's not surprising that Linux wins on the server (technical audience) but largely loses on the desktop (non-technical audience). Companies like Canonical and MindTouch can mitigate this by paying for usability design. But as an overall movement, it remains a weakness.
Apple has the opposite problem. It is religiously focused on usability, but struggles to open up to outside developers.
Even so, its attention to the user is something open source must emulate to reach the next level of adoption. Jason Snell of MacWorld writes:
Apple excels at creating products that the general public likes because the company is driven by design, not by engineering. Most tech products--heck, most products in general--aren't as good as they can be because they're put together by the people with the technical knowledge required to build them. And so the technical aspects of the product get pushed to the forefront.
The more complicated a product gets, the more technical acumen is required to put it together. Bad Web sites are built by people who know how to code HTML and JavaScript but don't understand how people use the Web. Bad software is written by people who are experts at knowing how a computer works and how to write code to make it do what they want, but no idea about how regular people behave and how those people expect to interact with that software.
Apple's the kind of company that makes decisions based on people, on users, and then challenges its engineers to find ways to fulfill those needs.
Why can't open source do this? Isn't there room in the open-source development process for the product manager, the focus group, and various other tools that software companies employ to determine what average users want and then to translate this into development plans?
The company (or project) that figures out how to do this will win.
Some projects already accomplish this to some extent. The strength of Mozilla, for example, is that it has figured out how to enable 40 percent of its development to be done by outside contributors, as BusinessWeek recently wrote. The downside is that these contributors are techies, but the upside is that they're techies who add language packs, accessibility features, and other "niche" areas that Mozilla might otherwise struggle to deliver.
This suggests a start: enable your open-source project to accept meaningful outside contributions that make the project reflective of a wider development community.
But the real goldmine is broadening the definition of "developer" to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won.
Until that day, don't be surprised to see Microsoft, Apple, and their ilk win most battles for the hearts and minds of common users. This is why Google comes across as naive in asking open-source developers to help it fight Microsoft on the "desktop." It's not a market developers are well-equipped to win because they're aren't reflective of the vast majority of end users.
Most people don't care how the software is written, and care even less for the supposed elegance of a given program's code. They just want the software to work in an easy-to-use manner, to look nice, and to fit their budget.
Open source does the last one better than most, but struggles at times with the first two. Fix that problem and open source will know no boundaries
Trackback(0)
TrackBack URI for this entry
Comments (2)
written by ..don, October 14, 2009
One of my favorite quotes is from Mike Cowlishaw, an IBM Fellow: “If a feature, accidentally misused, gives apparently unpredictable results, then it has a high astonishment factor and is therefore undesirable. This is another way of saying that if the program doesn't match the user's model of what's going on, then it has a design error. “
On of the more important ways to reduce the astonishment factor is to maintain a high degree of consistency. This is easier to do with a small group of developers. Apple does it by tightly controlling the interfaces, and by not allowing non-apple sanctioned code. But even they mess up – recently I experienced a hard drive failure on a Windows systems. When I restarted iTunes after installing a replacement drive and restoring the files from a backup, all of my iTunes settings and usage statistics were gone – again. That was the impetus to move to another player.
In the past, every time I did a KDE or Linux upgrade, I lost all or most of my desktop settings. I finally just gave up customizing the desktop. This means that my Windows system works more like I expect and is the one that I end up using when I just want to get real work done with the least hassle. I only use Open Office when I am trying to be good and can afford the time to figure out how to use the features.
I use Firefox almost exclusively not because it is the best browser, but because every time that something has not worked that way that I expected, I have been able to find a plug-in to 'fix' its behavior and because it has, mostly, survived a number of upgrades with settings intact
I have followed more that one forum with endless discussions about the 'correct' way of doing something – almost a given in any security discussion. But all too often we end up with academically correct applications that no one likes to use. I once used the install DVD to 'upgraded' a SuSE system that was already current. The install process proceeded to delete several hundred packages and make the system unusable. When I filed a bug report, it was closed as user error because an upgrade with no packages to upgrade technically did not fit their definition of an upgrade. Since I had to rebuild the system anyway, I went with another distro.
My feeling is that open-source does not need focus groups or users as part of the development team (most have better things to do), but needs to embrace the old Sear's motto: 'the customer is always right'; and the following design principles:
The ability to track feature usage, and user errors, and the ability to upgrade the program must be designed in from the start.
If a feature generates a lot of support calls, complaints, or forum traffic, it has too high an astonishment factor and needs to be redesigned.
If a feature is difficult to document or explain, it will have too high an astonishment factor and needs to be redesigned.
Developers have to stop treating users who do not immediately appreciate the elegance and correctness of their design as fools. The program is not the goal, the goal is to help the user complete some task as painlessly as possible.
On of the more important ways to reduce the astonishment factor is to maintain a high degree of consistency. This is easier to do with a small group of developers. Apple does it by tightly controlling the interfaces, and by not allowing non-apple sanctioned code. But even they mess up – recently I experienced a hard drive failure on a Windows systems. When I restarted iTunes after installing a replacement drive and restoring the files from a backup, all of my iTunes settings and usage statistics were gone – again. That was the impetus to move to another player.
In the past, every time I did a KDE or Linux upgrade, I lost all or most of my desktop settings. I finally just gave up customizing the desktop. This means that my Windows system works more like I expect and is the one that I end up using when I just want to get real work done with the least hassle. I only use Open Office when I am trying to be good and can afford the time to figure out how to use the features.
I use Firefox almost exclusively not because it is the best browser, but because every time that something has not worked that way that I expected, I have been able to find a plug-in to 'fix' its behavior and because it has, mostly, survived a number of upgrades with settings intact
I have followed more that one forum with endless discussions about the 'correct' way of doing something – almost a given in any security discussion. But all too often we end up with academically correct applications that no one likes to use. I once used the install DVD to 'upgraded' a SuSE system that was already current. The install process proceeded to delete several hundred packages and make the system unusable. When I filed a bug report, it was closed as user error because an upgrade with no packages to upgrade technically did not fit their definition of an upgrade. Since I had to rebuild the system anyway, I went with another distro.
My feeling is that open-source does not need focus groups or users as part of the development team (most have better things to do), but needs to embrace the old Sear's motto: 'the customer is always right'; and the following design principles:
The ability to track feature usage, and user errors, and the ability to upgrade the program must be designed in from the start.
If a feature generates a lot of support calls, complaints, or forum traffic, it has too high an astonishment factor and needs to be redesigned.
If a feature is difficult to document or explain, it will have too high an astonishment factor and needs to be redesigned.
Developers have to stop treating users who do not immediately appreciate the elegance and correctness of their design as fools. The program is not the goal, the goal is to help the user complete some task as painlessly as possible.
-
- +0
-
-
Write comment
I think are you wrong in your assumptions about the reasons for this.
An open source community includes many non-technical poeple. In fact, in successful open source projects, the developers make up less than 1% of the community. The rest of the community is made up of people who provide contributions around: use cases, QA and bug reports, documentation, platform issues, performance issues, translations, usability issues etc.
Most open source projects welcome usability feedback and would love to have a usability expert contribute advise to make the software better.
The thing I have consistently heard over the years from developers of open source projects is this - why can't we get specialists in graphics and usability to contribute?
Why don't these people contribute? Maybe, like you, they assume they can't. You never know until you try.