Jacob Neilson’s recent column on productivity and screen size referenced an interesting study comparing a feature-rich application with a simpler one:
The distinction between operations and tasks is important in application design because the goal is to optimize the user interface for task performance, rather than sub-optimize it for individual operations. For example, Judy Olson and Erik Nilsen wrote a classic paper comparing two user interfaces for large data tables. One interface offered many more features for table manipulation and each feature decreased task-performance time in specific circumstances. The other design lacked these optimized features and was thus slower to operate under the specific conditions addressed by the first design’s special features.
So, which of these two designs was faster to use? The one with the fewest features. For each operation, the planning time was 2.9 seconds in the stripped-down design and 4.6 seconds in the feature-rich design. With more choices, it takes more time to make a decision on which one to use. The extra 1.7 seconds required to consider the richer feature set consumed more time than users saved by executing faster operations.
In this case, more choices means less productive. So why aren’t all of our applications much smaller and less feature-intesive? Well, as I went over a few weeks ago, people tend to overvalue measurable things like features and undervalue less tangible aspects like usability and productivity. Here’s another reason we endure feature bloat:
A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC.
That quote is from a relatively old article, and when I first read it, I still didn’t get why you couldn’t create a “lite” word processor that would be significantly smaller than Word, but still get the job done. Then I started using several of the more obscure features of Word, notably the “Track Changes” feature (which was a life saver at the time), which never would have made it into a “lite” version (yes, there are other options for collaborative editing these days, but you gotta use what you have at hand at the time). Add in the ever increasing computer power and ever decreasing cost of memory and storage, and feature bloat looks like less of a problem. However, as this post started out by noting, productivity often suffers as a result (and as Neilson’s article shows, productivity is more difficult to measure than counting a list of features).
The one approach for dealing with “featuritis” that seems to be catching on these days is starting with your “lite” version, then allowing people to install plugins to fill in the missing functionality. This is one of the things that makes Firefox so popular, as it not only allows plugins, it actually encourages users to create their own. Alas, this has lead to choice problems of it’s own. One of my required features for any browser that I would consider for personal use is mouse gestures. Firefox has at least 4 extensions available that implement mouse gestures in one way or another (though it’s not immediately obvious what the differences are, and there appear to be other extensions which utilize mouse gestures for other functions). By contrast, my other favorite browser, Opera, natively supports mouse gestures.
Of course, this is not a new approach to the feature bloat problem. Indeed, as far as I can see, this is one of the primary driving forces behind *nix-based applications. Their text editors don’t have a word count feature because there is already a utility for doing so (command line: wc [filename]). And so on. It’s part of *nix’s modular design, and it’s one of the things that makes it great, but it also presents problems of it’s own (which I belabored at length last week)
In the end, it comes down to tradeoffs. Humans don’t solve problems, they exchange problems, and so on. Right now, the plugin strategy seems to make a reasonable tradeoff, but it certainly isn’t perfect.
Looks like they rediscovered why movie theaters limit the choices at the concession stands – speeds the lines up. The difference is that nobody picks a theater based on options at the concession stands (OK, relatively few people do) but people (businesses especially) pick software on size of feature set.
And don’t get me started on how word has gone downhill from Word 4.0
Huh, that’s interesting. I never realized that about movie concession stands. Probably because it still takes forever to get to the front of the line:P
As for Word, eh, whatever. I’ve found that as time goes on, I’ve become less and less reliant upon that sort of proprietary format and more reliant on open formats on the internet. But then, for work, I still use Word to write all my requirements docs. It does the job well enough, and the newer versions aren’t that bad…