Rapid Release and Usability
A significant frustration with using free/libre software is the break neck speed of development. While geeks, enthusiasts, and developers relish the fast pace and respond like puppies wetting themselves, the majority of users do not. While most non technical users understand the need for security patches, the majority of users do not understand, and more importantly, do not relish rapid release development.
This is noticeable when developers change program interfaces for the same reason dogs and cats lick themselves — because they can.
Most non technical users never dig deeper than the proverbial tip of the iceberg with respect to features. They really do not care. Computers are complicated and hence, scary to most people. They just want to use their computers.
Linux based software is regulated by geeks and enthusiasts. The computer equivalent of the weekend motorhead. Usability often seems to be an after thought with the “scratch my own itch” philosophy. Usability testing often is limited to fellow geeks. “Works for me” say fellow geeks. “WTF” say non technical users. This seems to be the nature of many free/libre software projects.
Sure, the “scratch my own itch” philosophy carries no obligations to care about other users. Often software is released under the GPL and that is all the original developers care about.
To reduce the effects of rapid release, some maintainers offer something called Long Term Support (LTS) or Extended Support Release (ESR) versions. The geeks, enthusiasts, and developers tend to avoid these versions. There is no “cool” factor and with respect to the break neck speed of development, such software grows “stale.” That is, new features are not available to users.
Yet those same non technical users want exactly that. Yes, a few such users at the fringes of the bell curve care and want new features, but more often than not, only with respect to an app or two they use often or depend upon for a living.
The nature of free/libre software development is sometimes called rapid release or agile development but to many users, the status is more appropriately called beta testing. There is evidence to support that claim. Subscribe to Linux related RSS feeds and notice the never ending press releases about newer software versions, most of which always mentions a slew of bug fixes.
In reality and practice all free/libre users are unpaid beta testers. Arguably there is quid pro quo. Most users obtain the software for no meaningful pocket cost. Yet as free/libre software continues to become more popular, something needs to be done to protect users from the continual harassment of rapid release.
Yes, harassment.
This is a fundamental but hidden cost. The continual frustration of ever-changing or broken software. To the non technical user, “ever-changing” and “buggy” are synonymous. This includes interface changes. As far as users are concerned, more often than not, from a user’s perspective rapid release means something “breaks.”
Non technical users do not understand the complexity of software or how subtle changes upstream might avalanche downstream. They also do not care. They just want to use their computers. Contrary to tech savvy users, non technical users perceive computers as appliances and not as complex tools to be mastered or tweaked. Computers are a means to an end.
Usability testing must include non technical users. Fellow geeks, developers, and the adventurous new Linux user are not part of the 80% bell curve. Geeks, developers, and the adventurous are the exception and not the norm.
Posted: Category: Usability Tagged: General
Next: The Love Affair With The Terminal
Previous: Remember the Users