Discussing one evaluator’s perspective and looking for other evaluation methods
I use Google Answers for research questions on occasion, by typing in some keywords and then browsing through already-asked or already-answered questions. I believe you could look for business trends by browsing through the Business and Money section of Google Answers periodically. It’s a definite time-suck if you go off on some of the sections like the questions in Family and Home. (Just how many times does a toddler hear No? Try 400 times a day.) Or even just sort by price to see what information is worth $200. For example, what if you need to buy 1 million Nokia cell phones? But I digress.
In Google Answers, while researching a white paper, I stumbled across an interesting account of how a system administrator might go about evaluating software. This is only a view into one person’s mind set when buying software, but it offers a glimpse and a perspective I hadn’t seen before. I think it also caught my eye because his third priority when evaluation software revolves around documentation and learning curve. His words: “The third qualification I look for is: existing documentation and training availability. I want to know this not only for my team’s learning curve, but also, to see how much the industry accepts the package as something worth writing about.”
As a technical writer I definitely like to hear that documentation helps put a product over the top. But also worry a little because each person’s evaluation of a piece of documentation is different. Plus, as I learned at the Best Practices in Tech Pubs session a few weeks ago, sometimes what a user perceives as product documentation didn’t come from a tech pubs group. Also, his perspective has to do with what others have written about the software, not necessarily the manual that’s shipped with the product. So, in my mind, there has to be something written other than the online help or printed guide to help him qualify and evaluate the software.
His first and second qualifications have to do with exit strategy. “How do I get away from this thing if I need too?” and “Can I access the data from another tool, outside this one, such as Perl?” For someone who makes software, that registers as “Yikes.” Yet in my own evaluations of document publishing or HTML editing software packages, I can see his point. If all my documents were in Word Perfect still, I’d be looking for a more common information architecture to go to for that content. (Reminisce: remember Word Perfect’s code view in the early 90s?)
So. What are your top three evaluation criteria when looking at a software package? Does the doc factor in at all?