My First Procedure Written in Twitter
All I’ve been thinking about the past week, it seems, is real-time and how it affects docs. Yesterday I wrote a post about it. Today, I tested it out. I wrote a procedure in Twitter.
Tech writers – take a look at it and let me know what you think. Tweets are from today, December 29, 2009. The first tweet is:
1) Procedure: How to Create Twitter Lists
Note: This is the same procedure I wrote a few weeks ago on this blog, in as an abbreviated a fashion as I could muster. This cuts that even more. Looking at my procedure tweets, I think we can definitely do with less verbiage. What do you think?
Update 1: 11:50 am
In the spirit of real-time writing, as noted in my previous post (real time, soooo last second), I’m updating this on the fly. No time to think. Just have to get something out quick. Letting my thoughts spill onto the page and my fingers fly across my keypad.
Should have: included a bit.ly link to my original procedure blog post (Twitter List: Create) in the last procedure tweet. Would/could have more detailed info. General > specific.
Need to: create hashtags for procedures to use for searching
Update 2: 12:45 pm
Corrections: Based on input from users (in this case, tech writers), fixed glaring omissions. Added step 6 re adding feeds to list. Also, info re identifying successful completion of procedure. Also added new, more detailed partner proc re adding feeds to the list. Fixed up this post a bit. Applied heading styles and time reference updates.
Update 3: 1:04 pm
More thoughts: This started as an example/experiment in writing a quick procedure in Twitter. Evolved quickly into a real-time situation. I had immediate feedback from users (other tech writers), and I did my best to quickly address errors and omissions. Ended up adding correction tweets and another procedure. Got me thinking. Perfect example of handling emergency situation.
Let’s say your company has immediate need to fix something, tech support needs to respond, and you have a support feed in place. (You do have a support feed, don’t you?) You must get info out immediately. So, boom! I’d get one person quickly writing tweets, and perhaps another testing and writing details. Yelling over the wall if need be, depending on the emergency. Posting updates constantly, as it’s a real-time, highly fluid situation.
In this case, I’m pretending that my tweets are for a company, that the tech writers responding are customers, and that I better get info out quick.
I uncovered a few problems. How to handle corrections? Also, there’s always the fact that followers will also be getting other tweets by the second, so the updates may get lost in the lists. How do we handle that? I have no idea at this particular moment. Perhaps create a list for your company that includes support feeds? Encourage customers/users to follow that list? One idea. If I have more, I’ll add them. In the meantime, I want to post this. So off it goes.
History
All times are Pacific Standard (PST)
Posted: 12/29/09 11:30 am
Update 1: 12/29/09 11:50 am
Update 2: 12/29/09 12:45 pm
Update 3: 12/29/09 1:13 pm
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.
E-Learning Rapid Development = Sticky Learning
Sticky learning* is the primary goal of any learning initiative, regardless of the method used to create it. Good content and well-defined learning objectives and measurements will result in effective e-learning courses that improve business performance and the bottom line.
“Rapid-development” is a hot topic, generating a great amount of discussion about whether it is an acceptable method for creating e-learning.
Proponents assert that rapid-development can significantly streamline the process, reducing the amount of time spent on programming basic interface elements. In addition, a shorter development cycle directly impacts costs. They maintain that getting the course to the audience quicker translates into reaping the benefits of the learning intervention sooner.
Opponents maintain that the learning may not be as effective as courses created using traditional methods. They state (correctly) that subject matter experts may be able to use a rapid-development tool to develop e-learning, but they may not know how to design effective instruction.
I will not purport to have the correct answer in this debate. Instead, I’ll leave you with enough information about rapid-development to engage in a discussion at your local coffee shop.
Many organizations are moving toward courses developed with rapid-development software—especially with reduced workforces that need to do the work in less time, and with smaller budgets. I’ve developed courses using both traditional and rapid-development methods, and have seen that engaging and sticky learning can occur with either method. (Just as poor-quality learning can be imparted with either method.) I believe the crucial, determining factor is to ensure that instructional design expertise is applied during the development process.
Cost
Foremost for many companies, adopting rapid-development methods and tools minimizes the development cost of e-learning. It allows companies that previously had no opportunity to afford or benefit from e-learning to quickly and effectively train their workforce. Even small businesses and non-profits can jump in and start reaping the benefits of e-learning.
Time
We all agree that time is money. If you can create a high-quality e-learning course in one month as opposed to four months, wouldn’t it make sense?
We will also agree that time translates into areas other than money. If e-learning is available sooner, rather than later, companies start seeing the benefits of their well-trained employees sooner. The company can continue to focus on running their core business successfully, which is what it’s all about.
Efficiency
This translates into time and money, too. Rapid-development allows your subject matter expert to transfer their knowledge into the development tool. Other team resources can then convert the content into solid instruction and add the bells and whistles.
Bells and Whistles
Perhaps rapid-development tools were lacking in nifty and engaging features in the past. This is no longer true. I’ve seen numerous e-learning courses that would knock the socks off any learner. Eye-catching animations and superb functionality are now commonplace in the rapid-development toolbox.
E-learning methods, tools, and delivery options will continue to evolve. Social media is already changing the scene. Our job as designers and developers is to use our creativity, effective writing skills, and knowledge of human learning behavior to develop compelling and sticky e-learning. If rapid-development can enable us to create cheaper, quicker, and (in some cases) superior courses, then shouldn’t it be strongly considered?
* Sticky learning – my term for learning that will get stuck in the brain like gum to a shoe (only without the mess and frustration)
Introducing: New e-Learning Category and Contributor Jill Freeman
Tech writers often work closely with e-learning developers. Yes, it’s true that tech writers can (and should) be able to make their own short online tutorials, or make a quick video to show how an app works. However, there are definitely times when a polished, planned tutorial or similar item must be developed – and by an e-learning specialist.
While related to tech writing to some degree, e-learning is an entirely different field of study with its own rules and methodologies. It’s a different career path. There are different tools used and different expertise to draw upon. Personally, I’m glad to know that option is available. I know that, if needed, I can toss something over the wall to an e-learning specialist and obtain a well-designed, well-planned tutorial or item that meets e-learning industry guidelines. The users definitely benefit.
As it happens, there are many changes occurring in the e-learning industry as well. Our new contributor, Jill Freeman, is going to address that periodically. She is an experienced e-learning professional. In her first post, she discusses the difference between rapid development and traditional development. This is a topic of great interest and debate in the e-learning field, and is, in my opinion, important to tech writers. We need to know what’s happening in the e-learning field.
Take a few minutes and read Jill’s post:
E-Learning Rapid Development = Sticky Learning
Welcome, Jill!
On Writing and Finding Words
Now, I don’t know how other writers view the world of words, or all the letters and words available from which to choose when composing some sort of written material. For me, I always visualize words up in the sky, like stars, and when writing, I just reach up and gather some. Sometimes they’re easily in reach, and other times not. Depends on the word, I suppose, or the day.
If it’s a day when words come slow as molasses, just give up and make it an editing day. If it’s one of those days when words pour out like water out of a pitcher, type as fast as you can to catch as many as you can. Some will spill onto the floor, but you can’t worry about that. Just keep typing and don’t even think about editing. Just empty the contents of your mind onto the page.
Never underestimate the power of words, or their capacity to hide when you’re looking for them. Or for running out the door before you can catch them, for that matter.
These days, I look up and see something different than in years past. Between my desk and the stars, I see a band of words, videos, and all sorts of devices continually zooming by in a convoluting band. Kinda like one of Saturn’s rings, but spinning and moving fast. That’s the Internet; that’s all the information from all over the world zipping by in an instant. Every second, more is tossed up into the mix. Every second, someone pulls some piece down and uses it one way or another. It’s fast, and it’s a race. And everybody around the world is contributing and it’s continually changing. It’s so unbelievably wonderful to have all this information and sharing all around the world in ways I never would have imagined even a few short years ago.
I love it.
I’ve been off the grid here for the past couple of weeks for one reason or another. Now I’m back to writing. I’ll be composing something about databases and xml and that sort of serious thing, but for now, I thought I’d just let myself get sidetracked and see what words and thoughts came to mind. I think writers need to do that once in a while. Just sit back and pluck a few stars.
Well, time for me to toss these words up on the Internet. Let them join the mix and see where they go…