Real-time: it’s sooooo last second

Who has time to think? These days, actions do speak louder than words. The world has changed to an immediate, need-it-now mentality. Real-time is turning into all-the-time, and tech writers need to address it. Can’t ignore this one!

The luxury of time is slipping away from us. Time to research. Time to test. Time to write in-depth. Here are some examples of how quickly information is disseminated.

Minutes after posting, a tweet of mine showed up in search results in Google. Sometimes my tweets get retweeted by followers soon after posting. That’s fast.

A week or so ago, one mere hour after I posted a tweet about a product I thought was interesting, it was retweeted by an employee at the company that developed it. Clearly, they were monitoring the real-time mentions of said product.

These instances have really set me thinking about real-time. I’ve known that it’s coming, and now it has arrived in a major way. I’ve really been thinking about it and trying to determine how it affects docs.

The main question in my mind is: how do you handle both longer, bigger base docs as well as on-the-fly need-it-now information? All I see is an even bigger movement toward fast, fast, fast. Quickly developed (Agile). Quickly documented. Quickly addressed when it hits the airwaves and is mentioned one way or another. Quickly fixed if need be.

My ideas on how to address this follow.

Maintain focus on the big picture

I believe that the need for a main body of documentation will remain. However, while in the past, it was the main and only type of doc, I think it’s now moving to the background. Just as you write topics from general-to-specific, we need to begin writing docs in the same manner. It’s just changing.

Real-time is the new “general.” Older, more traditional docs are now the “specific.” Only you will be able to determine what is what, and where to focus your resources and time. I would wager, though, that the trend will move more to real-time and the main body will begin to diminish in importance. I also think that the balance between real-time and core docs will fluctuate at each company, each doc group, each writer.

Use databases and xml for single-sourcing

I still believe wholeheartedly that databases are the only way to go. You need a good content database design that provides the ability to run queries in seconds, both existing and new. That’s the quickest way to handle immediate needs.

At the risk of causing a ruckus, I don’t believe in using existing, industry-standard authoring tools. I think they’re limiting and, frankly, coddle tech writers, enabling them to stay with the familiar instead of learning what’s needed and how it all works under the hood. Tech writers need to learn about database design, schemas, and mapping.

The old ways are just that: old. Obsolete. If this real-time push doesn’t illustrate that enough to people, I don’t know what will.

Dedicate resources to monitor and address real-time inquiries

It’s not just that you may need to address something quickly; it’s also that people aren’t going to want to wait to find something. You have just seconds. If it’s not there when they want it to be, then you may be out of luck and lose them forever. We all know that it only takes one bad experience to have users dismiss docs and never use them again. Why be totally irrelevant? Get somebody monitoring the desk, so to speak. Rotate resources so everyone gets a feel for it, and so you can brainstorm on best ways to handle emergencies.

Act on emergencies and immediate needs

Answer something immediately with a tweet or similar item. Then add it to your FAQs. Or, add it to your FAQs immediately, even in draft form. Then create a link in a tracking URL shortener like bit.ly and see who’s looking at the link. Pop it into a tweet and off you go. Write in snippets. Microblog your docs. Then, if needed, work it into your main body of docs.

Just move fast. It doesn’t need to be perfect at first. It just needs to be quick. Let’s say you get an FAQ posted. Maybe at first it’s one sentence. Or perhaps it’s just “we’re aware of it and working on it” with a date and time listed. Then update it as you go. Tweet about the original and updates. If people know you’re working on it, they can relax a bit.

What we’re looking at, perhaps, is a day where we just need to let our thoughts spill onto the page for these quick items. No testing. No passes through an editor. Just think, type, and post. Fast fast fast. Perhaps docs will become one big first draft.

Of course, although it needs no reminder, I’ll say it anyway: work with tech support so they know what’s up and what you’re doing.

Plan for real-time doc needs

Some of my past posts are somewhat related to his topic. Just add real-time to the list. In the interests of saving time (perhaps a real-time doc example?), I’m just listing some links and saying this: just add real-time to the list; apply the same thoughts to real-time. It’s not perfect, but it’s something I can get out right away and save some time, until I can get to it later. Or perhaps this is enough for this item. I’ll have to see. Right now, I’m in a hurry to get this post published so am trying to save minutes.  

Here are the posts:

Legal Requirements in the New Age

The Changing Role of Writers and Editors

There’s a section in the latter post about editorial boards. I’d say that addressing real-time issues should be another topic for such a board to plan for. Establish guidelines and determine procedures.

In closing…

This is all I can think of right now. Like I said, I just want to get something out now. And if I think of something else later on, I’ll just update this. That’s fast. That’s real-time.

Honestly, I don’t know how much quicker information can be presented, processed, and categorized. What’s next? Implanting chips into our brains so that we can just look a screen, think, and poof! It’s there, typed up and ready to view? Never rule anything out in the tech world. All I know, right now, real-time, is that the ground has shifted.