Last week, I ran a one-day FLOSS Manuals book sprint to update the Thunderbird manual that I helped write last year. The usual book sprint lasts anywhere from two to five days — so why did was this one only a single day?
A few reasons. While there were a number of changes to Thunderbird since the team originally wrote the manual, not all of those changes were major. Plus, at the moment, I’m extremely busy. There’s a lot going on in my personal and professional lives right now, aside from the 1,001 things that make them both a joy and a purgatory. One day was all I could spare.
The one-day sprint was interesting. And fun. Here’s a quick look at what went down.
With apologies to The Buggles …
Last week, I gave a talk at FSOSS 2011 about creating ebooks using Open Source tools. If you’re interested, you can take a peek at the slides and notes for that presentation.
This talk wasn’t all theoretical. While I’m definitely not an expert on creating and publishing ebooks, I do have some knowledge of the subject — I’ve been researching this topic for quite some time, and I’ve been working with various Open Source tools. On top of that, I have some practical experience.
As you may or may not know, I published my first ebook recently. And, yes, it is available in the Amazon Kindle Store.
Writing this book was an interesting exercise for a number of reason. Mainly, what was interesting (at least to me) was the approach I took to writing and publishing it. There were a few fits and starts, but I think for this type of book I came upon a solution that works for me.
Why not join me for a peek at how I wrote and published my first, and definitely not last, ebook.
By Roger Sharp
I was at a friend’s house the other day and pointed to something stuck to his refrigerator. It was an invitation to a mutual friend’s birthday party from months ago. The card had a photo of the birthday man sitting in a deck chair sipping a martini. The deck had been made cozy by potted grasses and palms that seemed to surround him. The image was printed in sepia tone.
“I just couldn’t throw it out. It looked too good,” was his excuse for still having it.
And so it is with most people — we appreciate beauty. But more than appreciate it, we look at it longer and remember it better. This principle is also true of user assistance.
I view documentation as serving three main purposes:
- Helping users become familiar, and comfortable, with the hardware or software that we’re writing about.
- Teaching users advanced tips and tricks.
- As a reference for things that users may have forgotten or rarely use.
A big part of the second point is internalization. Making tasks seem like second nature to the user. This was brought home to be recently while doing some audio editing and clean up for my wife.
It’s been some time since I’ve done any audio editing, and quite a bit of time since I’ve done it regularly. That was back when Aaron and I were frequently putting out our podcast.
There’s definitely a lot of talk about the mobile universe in our profession. More and more technical communicators are coming to realize that the devices that we carry in our hands and in our bags are becoming a platform on which to deliver information and documentation.
The question, though, is how best to do that?
Recently, I had a rambling conversation with a friend of mine. He’s not a technical writer (or a writer of any stripe), but portions of our conversations often turn to technical communication. I enjoy the occasional talks I have with people outside of our profession. It gives me a fresh perspective on what I do, and for whom I’m doing it.
Our discussion turned to how best to deliver documentation on a mobile device. Now understand that my friend is a mobile junkie. He lives his personal and professional lives on his phone and portable media player. In fact, it’s been a while since I’ve seen him touch a computer.
Anyway, he said that documentation might best be delivered using an app. I thought about that for a few seconds, then had to politely disagree.
Back in the mid to late 1990s, I didn’t have much money to buy new hardware. Actually, my computing was done on older desktops and laptops. Of course, that hardware wouldn’t run the latest versions of Windows (at least not too well) and I hadn’t started my journey to Linux just yet.
To cut down my computing costs and to keep my hardware alive just a little longer, I turned to an application suite called NewDeal Office. NewDeal was the latest incarnation of GEOS, a once-popular graphical operating environment.
For me, the applications in NewDeal Office were more than serviceable. But what impressed me was what I called the graded interface. I’m not sure if that’s the correct name for it, but the interface had five levels: beginner, intermediate, advanced, expert, and custom. You can read more about it here.
Each level of interface builds on the last one, gradually increasing the complexity of the interface without overwhelming the user.