August 27, 2010

Getting Lost in Features

I have two pet peeves when it comes to "features". One is that we get very caught up in documenting a product's features and not how to use the product. The other, and the one this post is about, is that we tend to crave more features even when they don't make the product any better.
Yesterday I came across two articles. The first article was about a CS professor who uses old BBC micros to teach his students how to program. The micro strips away all of the "features" of modern IDE's and forces the students to think about the code. The second article was a meditation on the possibility that documentation efforts have become so focused on the shiny presentation features and rich editing features that quality content has been overlooked.
The "feature" overload problem makes me remember my early days of MP3 players with horror. I wanted no part of the iPod. It only supported a few formats, didn't have a radio tuner, didn't record, couldn't edit song titles, didn't have a way to make playlists on the fly..... Instead I raced out and bought a fancy Rio that supported every format known to man, recorded, had a radio tuner, and even had network syncing. The thing rocked, but it was a bitch to use. Worse, the radio sucked and I never recorded anything. The only "feature" that was useful was the network syncing because I didn't have a place near the computer to put the syncing cradle. As more of my friends got iPods and I got to use them, I became very jealous. The iPod looked good and was easy to use. Less features, but a better solution to the problem. When the Rio died, I replaced it with an iPod and never looked back.
I look at some of the Webhelp systems in the world and ask myself how much does all that Javascript goodness really add to the usefulness of the documentation. Does a collapsible TOC really make it easier to find things? Does putting the index on a separate tab make it easier to use? Does the half-assed search capabilities built into the system make it faster to find information? What about the buttons that collapse the TOC pain or sync the display to the TOC? They all look cool, but would spending more time on good content and good organization be more valuable? My answer is that the "features" of most documentation UI's are not that helpful and that better content is usually a good answer. Personally, I find using search painful and would prefer a halfway decent index any day.

I have the same problem with a lot of the documentation tools that are on the market. Framemaker, RoboHelp, ePublisher Pro, Flare, Word etc. are all powerful feature rich tools that are intended to make documentation production easier. They all, in their own ways, takes the writer away from the content. WYSWYG editors place too much emphasis on page-layout and distract from the words on the page. To cope with all of their features, and the odd missing features, takes a learning curve and often you are forced to make compromises to fit the tool.
Even some of the XML editor's for documentation can go overboard. They all do auto-complete to various degrees and have WYSWYG views. Give me a simple editors that validates my mark-up and spell checks and I'd be happy.
Let me focus on the words and not the tool.
We need to remember what problem the product is intended to solve and make it excellent at solving that problem. Strip away all features that do not further that goal.

No comments:

Post a Comment