- Ellis Pratt asks where does your help sit on the technology adoption curve?
- Ben Minson on developing a list of standard tech comm products
- Is it about usability or changing user behaviour? I think we know the answer to that one …
- Kai Weber discusses efficiency and documentation
- Take a look at this use for Evernote: delivering documentation
Let’s take short stroll down memory lane. To 2007 to be exact. Back then, I was thinking a lot about wikis, writing about them, and using them fairly extensively. My thoughts then, as they are now, were about how to use wikis to write and deliver documentation.
For some reason or another, the thoughts and ideas that were floating around in my brain refused to coalesce into something concrete. Then came DocTrain UX 2007 in Vancouver. On day two of the conference I attended three sessions on wikis. The first of these was given by Alan J. Porter. That session gave my brain the kick it needed. All of the ideas and thoughts I mentioned started to come together.
Jump forward to 2010. I have in my hands a copy of Porter’s recently-published book WIKI: Grow Your Own for Fun and Profit. It’s a short book, but it packs a lot of information into its 150-odd pages. It’s easily the best book on wikis that I’ve read in a long time.
I don’t know why, but over the last few years the going rate for writers (technical and otherwise) has been declining. This has been something that’s been on my mind for a while now. It’s a tricky subject. That said, Aaron and I believe in charging what our work is worth.
As someone who has more than just a bit of experience and skill, I think that my time and my effort deserve reasonable compensation. I’m sure that the freelance technical writers who read this blog feel the same way.
And I agree with Canadian freelance writer Paul Lima who wrote:
I don’t give a hoot what the client expects to pay. I give a hoot about what I expect to earn.
One of the biggest problems that freelance technical writers face is what clients are willing to pay. As we’ve all seen, that can range from a decent wage to an insulting amount for a lot of work.
I usually don’t talk about journeys unless I’m describing actual travel. But I have to admit that co-founding DMN Communications and becoming a tech writer for hire has been a journey. In fact, several related journeys. One of learning, one of becoming more fulfilled in my career, and one of finding out what I’m capable of.
While not all of the journeys I listed in the last paragraph are complete, I’m definitely making progress on those roads. But there’s more to my freelancing than the journeys.
Becoming a full-time freelancer has changed me. In a number of ways, and all of them good. At least I think they’re good … Curious? Read on.
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.