When I gave a talk about FLOSS Manuals at FSOSS 2010 in October, someone in the audience asked a question I definitely wasn’t prepared for. And I was asked a similar question a couple of times during the event:
Does FLOSS Manuals drive people away from the official documentation?
I tried to explain that explain that one of the goals of FLOSS Manuals (at least from my perspective) is to get people up and running with whatever technology quickly and in a very friendly way. But those manuals don’t cover everything – they get you going. If you want to delve deeper into the software or technology, the official docs are still there.
While that seemed to get some folks more interested in FLOSS Manuals, the question illustrated something of a gap in perception, on my opinion. I don’t think it’s FLOSS Manuals vs. the official documentation or other documentation or sources of information.
I mentioned this to Adam Hyde, the head honcho of FLOSS Manuals, and he’d never been asked that question before. Adam asked me to start a discussion on the FLOSS Manuals mailing list. That posting prompted a lot of interesting responses. You can read the thread, starting here.
But that discussion also got me thinking about this in the context of documentation for commercial products.
A while back, I wrote a post in this space about Sugata Mitra and his Hole in the Wall project. The project involved, literally, putting a computer and a track pad in a hole in a wall in several locations in India, and letting children (who’ve never seen or used a computer before) discover and learn to use the device.
I was browsing the BBC News Web site recently and stumbled across an article describing how Mitra not only continued the experiment, but also how he’s been expanding on it.
A paragraph in the article sparked a thought about the role of documentation:
Further experiment showed that having a person – known as “the granny figure” – stand behind the children and encourage them raised standards even higher.
Here are a few thoughts on that idea.
As the title of this post states, what you’re reading is the result of some woolgathering I’ve been doing about a topic that I recently discussed in this space. Don’t expect any conclusions or deep insights …
If you’ve been reading this space for any length of time, you know that melding user-generated documentation with so-called official documentation is something that I think about quite a bit. As I’ve written and said in the past, I haven’t found an efficient and effective way of doing that melding.
One of the keys to that could be to use lightweight markup languages.
1 a : known or perceived by intuition : directly apprehended b : knowable by intuition c : based on or agreeing with intuition d : readily learned or understood
– Source: Merriam-Webster Online
As I’ve written in this space time and time again, I don’t believe that any software (and definitely most of the software I’ve documented) is intuitive. It’s familiar — people have used certain applications and interfaces for so long that they’ve gotten used to them. But they didn’t start out that way.
Somedays, I feel like I’ve been shouting in the wilderness with only trees and mountains hearing me. But, as it turns out, I’m not alone. A few days ago, I stumbled across an interesting article at LinuxInsider.
The article goes into quite a bit of depth about whether or not operating systems should be intuitive. Not surprisingly, the title of the article is “Should Operating Systems Be Intuitive?”.
A couple of quotes from the article struck me:
“‘Intuitive’ has nothing to do with computers,” (Carla) Schroder wrote. “It’s all learned.”
“Nothing is intuitive,” Montreal consultant and Slashdot blogger Gerhard Mack told LinuxInsider. “Think about it: We have to be taught to use a toilet, how to use a fork and how to drive. Why do we expect computers to be some magic thing that does not have a learning curve?”
There is some interesting food for thought in there. Give the article a read. It’s time well spent, no matter what side of the fence you’re on.
I’ve written in this space before about how people can, and should be able to, adapt to new applications and interfaces and all of that kind of thing. Lately, I’ve been really practicing what I preach. And while the results haven’t surprised me (I’ve done this in the past), I’ve learned a few things about how technical communicators can help users adapt.
So, let’s take a little walk …
Over the last several weeks, part of my evening ritual (if you want to call it that) has involved re-reading a few of the books on my bookshelves. Everything from Harlan Ellison‘s essays to I.F. Stone‘s musings on the trial of Socrates, from a couple of novels by James Salter to issues of Transmetropolitan.
Recently, I was going through my copy of Crowdsourcing. If you’ve been following this phenomenon for a while, the book contains nothing new or groundbreaking. But, I have to admit, the last chapter got my attention. Especially the the section “Keep It Simple and Break It Down”:
When it comes to crowdsourcing, any task worth doing is worth dividing up into its smallest possible components.
That definitely has application in the wacky world of technical communication.