The other day, my wife pointed me to an interesting presentation given at the LIFT 2007 conference by Sugata Mitra. In this presentation, Mitra discusses his Hole in the Wall project — 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.

The results were very interesting. Mitra found that when they stumbled upon this, the children invariably were able to teach themselves to browse the Web within minutes. All with no outside assistance.

This got me thinking about so-called intuitive user interfaces, and the ability (or lack of it) of users to adapt to something different.

Read the rest of this entry »

• 0 Comments

In case you hadn’t heard, Google has released a new Open Source browser named Chrome. What’s interesting is how Google explained the browser. While they could have used a lengthy blog post or a set of screencasts (which Google has also done), they instead created an introductory comic.

It’s not any ordinary comic, though. It’s done by Scott McCloud who wrote and illustrated the wonderful books Understanding Comics and Reinventing Comics — both are great reads, even if you’re not interested in comics.

The introduction to Chrome is in the style of those books, and features various Google employees who worked on Chrome explaining the browser. Check it out, if only to learn a few things about using visuals in documentation.

• 0 Comments

I was reading the 37signals blog the other day, and came across an interesting post on why you shouldn’t laugh at your customers. In it, the writer discusses some confusion among customers at a New York City bookstore who were trying to sell some used books. The employees were hardly sympathetic to the customers. But the blog post makes a good point:

Sure, any one customer might be stupid. But if multiple customers are repeatedly making the same mistake, maybe it’s not a mistake on their part. Maybe it’s a mistake on your part. If no one can figure out where to wait in line, maybe that’s a sign that you’re not doing a good enough job explaining it.

Good documentation — whether it’s a sign, a user guide, or an online help system — helps to eliminate that kind of confusion. Unfortunately, it’s easy to get caught up in the mindset of oh, that’s obvious! when dealing with an application or a device that you’ve been working with for a while.

As I mentioned in a previous post, familiarity breeds familiarity. Being so close to the application or device, we tend to take things for granted. We can easily lose sight of what a new user, who may come tabula rasa, will be able to intuit.

Sometimes, we need to take a step back and try to view what we’re documenting with fresh eyes. It’s not easy, but maybe that can prevent customers being laughed at and make customers happier. And isn’t that one of the goals of good technical communication?

• 0 Comments

• An interesting interview on user experience with Jeff Veen of Adaptive Path.
• Your product is you. Here are some tips on how to sell that product.
• Here’s a book that will definitely find its way on to one of my bookshelves.
• A detailed post on building documents to order with DITA.
• Use DocBook? Then check out Mr. XML Publisher for DocBook, a demo of a server-based application that formats DocBook XML.

• 0 Comments

Rebuilding existing documentation. I don’t know about you, but I find that to be something of a daunting proposition. Especially if I wasn’t the one who wrote the original.

Sometimes, though, this scary deed must be done. I’ve done it a few times, and it’s not easy. It can be done, but the process of rebuilding a piece of documentation can be on par with starting a new documentation project from scratch. Actually, in some cases it might be a bit more difficult.

Intrigued? Read on …

Read the rest of this entry »

• 0 Comments

While going through some Google Alerts the other day, I stumbled across this blog post that discusses user-guide-driven development. What the author wrote about bad software code bubbling up into the documentation is so true.

The user documentation is an excellent indicator of the quality of a product. Bad software produces a lot of lengthy documentation because you have to clearly, almost laboriously guide the user through a convoluted workflow or process.

The author is saying something that Scott and I (and others in our field) have said for years. You can’t paper over bad design, no matter how hard you try. But done iteratively, documentation can add additional value by improving the product.

It’s not a stretch to say that good technical communicators are the best quality assurance weapon available to technology companies.

• 0 Comments

Subject matter experts (commonly referred to as SMEs) are one of the key sources of information for a technical communicator. Whether a developer, project manager, business analyst, or a QA person, a SME can provide valuable feedback and additional information that can help strengthen your deliverables.

The care and feeding of SMEs is an art in itself. Everyone has a few strategies. But this article is one of the most comprehensive explorations about working with SMEs that I’ve seen in a while. Great advice all around. And the information in the article can be applied by SMEs working with technical writers.

• 0 Comments

Lately I’ve been doing a lot of thinking about the process of switching from one niche in technical communications to another and the challenges and obstacles that can make it difficult to make the change. Technical communicators tend to work in specific domains where they have accrued extensive experience and knowledge.

Specialization commands a premium in many fields, including medical writing, aerospace, and telecommunications. Is it possible to switch from one niche to another after spending the bulk of your career focused on a specific domain? It seems to me that there are those who find a niche and stick with it, and others that gain a broader range of experience by working in different fields.

Getting experience (and eventually, employment) within specific niches of technical communication is notoriously difficult to gain without an advanced degree or extensive experience. For example, the medical device and pharmaceutical industries often require an advanced degree in a science-related background to satisfy the requirements of the position.

One of the things I enjoy most about being a technical communicator is the constant opportunity to learn new technologies. It’s a rewarding experience when a complex concept “clicks” (try saying that 10 times fast). So it makes sense that willingness and flexibility to learn new concepts, businesses, and technologies would make switching easier. But I get the feeling that switching is kind of like becoming a newbie all over again. You don’t have the specialized domain expertise, so you’re immediately at a disadvantage.

Have you successfully made the switch between two different niches in technical communications? What were some of the obstacles you faced in the process? Post a comment and we’ll continue talking about “switching niches” in upcoming posts.

• 0 Comments

Reuse. It’s a small word, but one which has can have huge connotations. Especially in the world of technical communications. Reuse is one of the big themes in our profession right now, and everyone has a theory about it or method that they’re advocating.

I was pondering the subject the other day, and was about to pen a lengthy blog post about it when I remembered that Michael Hughes beat me to it. He’s published a four-part series on reuse, which looks at:

• Architecting for reuse
• Types of reuse
• Same topic, different content
• Reusing snippets

• 0 Comments

• Gordon McLean discusses testing documentation
• A lengthy discussion the poor usability of Free software and how to can be improved
• Heidi Hansen discusses how she writes help for a topic-based help system
• An interesting look at authoring practices for the mobile Web
• Still writing based on features rather than tasks? Here’s why you should think about changing

• 0 Comments