5 Reasons to Write Procedures in Twitter
Recently, I’ve been exploring the need for writing procedures in real-time, focusing on Twitter in particular. This is the fourth post in the series. In my last post, I was asked by Larry Kunz in a comment for thoughts on situations in which one might write procedures in Twitter. Five come to mind; I’ve described them below.
Push Information
The beauty of Twitter is that you can quickly disseminate information to a large, targeted audience. Initially, it would, of course, be followers of the feed in question. Retweeting then magnifies that distribution, possibly exponentially. In classic online docs (help, websites, knowledgebases, and the like), we wait for users to come to us. By using Twitter, we can go to them.
This puts an entirely different spin on the whole question of doc development. When planning a content strategy, consider this: what might you want to hand-deliver to your users vs. requiring them to come to you to find?
Quick Fixes
Let’s say, for example, that you have a procedure regarding a fix that’s needed immediately. If one user has a question about it and asks a question on a Twitter support feed, you can be sure that there are many that have the same question. So if a person retweets a procedure, it could possibly travel far. If there’s a negative comment (e.g., something along the lines of “this app doesn’t work, it’s awful”) it might compel a company to get out a fix or explanation, or a quick procedure to quell disruptions.
Example: late last year there were there hacking attacks that affected WordPress sites that hadn’t been upgraded to the newest version. Site managers that had not yet upgraded needed to act immediately to fend off an attack on their sites. News came through Twitter. It was retweeted everywhere. That’s how I found out about it. In such a case, you could write a quick procedure about the upgrade requirements as well as other information. Who knows how far a procedure might travel? I think that tweets pointed people to blogs and sites that had procedures or information about how to address the situation – which in itself is another excellent example.
WordPress is updated frequently. There are docs and blog posts in existence that describe how to upgrade to the latest version. It doesn’t matter what version; the same basic procedures apply to any upgrade. (That’s the beauty of WordPress. There’s so much information out there, and the open-source community is so helpful and collaborative. It’s wonderful.)
If you have an app that has regular updates (as WordPress does), or just has an impending release, why not have something written beforehand that you could point to when necessary? When I ran my Twitter procedure experiment on 12/29/09, Larry Kunz (@larry_kunz) made this suggestion:
“Also, and I know this is a lot harder than it sounds: anticipate the situation, and have responses pre-written, ready to go.”
This is exactly the type of situation that fits Larry’s suggestion. Anything that occurs on at least a periodic basis (such as app updates) should have some docs already written somewhere. Plus, said docs should be written in a generic fashion that would be applicable to any upgrade situation (content management in action) – not just one in particular. You can always address particulars, but have some clean generic docs ready at all times.
Product Launches and New Features
If a company has an app revision or new feature and wants to get the news out, a related procedure in Twitter might support marketing efforts. (As in, here’s our new feature; here’s how to use it.) It also never hurts a company to promote visibility of their products, keeping the company in mind. Pointing out features that would help users and save them time is always a good idea.
Real-Time
People are growing accustomed to getting information right now. They may not have the patience to look through online docs to find it. I cannot emphasize real-time considerations enough. There’s also always the possibility that one of your tweets will be picked up and distributed immediately once it hits the airwaves.
Either put a quick procedure in Twitter, or put in one tweet that links to the appropriate location in online docs or some other location, such as a SharePoint portal. Help your users. Answer their questions before they know they need them. Fix their problems. Monitor support questions and get something out there once in a while. Why not put a short FAQ in your support feed, particularly if it’s asked regularly?
After all, excellent customer service is always a good idea. Given that tech writers must perpetually sell their worth to a company, it sure can’t hurt to help customers.
Go Where Your Users Are
If users are scanning Twitter regularly or using Facebook, that’s where some of your docs should be. If they’re reading your blogs, think about adding procedures there. You can embed Twitter feeds in multiple places: WordPress sites, Facebook, LinkedIn, and Google Wave. Also, in Facebook, people can leave comments for each tweet that becomes a status item in Facebook. Look at the Mashable page for an example.
Remember: social media is a primary mode of communication these days. Start using it, if you’re not already. If nothing else, mentions of detailed docs and links to them can easily be integrated into these locations.
If your users are all at Twitter, Facebook, blogs, and the like much of the time, why not go there? If not, you may find yourself standing at an empty storefront.
Related Posts
Real time: it’s sooooo last second
My First Procedure Written in Twitter
Lessons Learned: Procedure Written in Twitter
Minimal Procedure Content: Reasoning
The procedure I wrote about creating a Twitter list uses abbreviated content. This post describes the reasoning behind and decisions made in writing the topic.
Title
Instead of using this:
Create a Twitter List
I opt for this construction:
Twitter List: Create
Reasons
It puts the topic first. You don’t have to dig through the content to get to it. For scanning, you can see immediately that it’s about Twitter lists. If there were an alphabetical list of “creating” topics, where would you find this? I know the training has always been to start topics with an action. However, I think it’s OK to break that rule.
I believe this construction would also lend itself to XML more easily. Twitter could be a tag and database record, as could Lists and Create. From a database design standpoint and rules of normalization, it would be better to have a “Twitter” record that could be referenced and reused more easily. It would make it easier to create tables, build queries, and add programming features to accompanying XSL files. If you have an XML tag/database record that contains just a topic title (e.g., Create a Twitter List) you may have problems down the road. Your database won’t scale very easily.
Also, it provides a way to automatically sort. As an example, I’ve made up some titles to show how it might work
Twitter Feeds: Block
Twitter Feeds: Follow
Twitter Feeds: Unfollow
Twitter Lists: Create
Twitter Lists: Edit
Twitter Lists: Delete
Facebook Pages: Create
Facebook Privacy Settings: Edit
In a sample table of contents (TOC) for Twitter:
Feeds
Follow
Unfollow
Block
Lists
Create
Edit
Delete
Traditional construction (both in title and TOC)
Block a Twitter Follower
Unfollow a Twitter Feed
Create a Twitter List
Delete a Twitter List
Edit a Twitter List
Create a Facebook Page
Edit Facebook Privacy Settings
Content
The audience I’m writing to is tech-saavy individuals that already know how to use Twitter. Any general usage procedures would be covered elsewhere. Content is abbreviated as much as possible, written with mobile devices and small screens in mind.
As I’m planning to include a short video showing this, I also don’t believe it’s necessary to go into as much detail in the written procedure. For example, step 2 mentions a “box at the top of the page (if visible).”
During testing, I closed the box, and was unable to reopen it. Rather than writing a long sentence or two explaining that, I just chose to put in “(if visible)” to quickly note it. Then, in the video, I can discuss it more. Commentary can be provided in a video that would just clutter a written procedure. I see the written procedure and video as a pair. Each has its own purpose.
Video
The video I’ll be adding won’t be fancy or long. I don’t think it’s necessary in this case. There will be times when it’s important to plan out and make thorough, polished presentations and tutorials, but perhaps they don’t all need to be. Allow for something quick to be made, tossed up on a server somewhere, and available right away. I believe we can make some quickly that do not have to be completely polished. Today, speed is increasingly important, as are budget considerations. I think it’s time for doc departments to let go a little. Determine when it’s OK to just get something out fast and when to go the distance and make a full presentation. Times have changed. Does it always have to be perfect?
More
WordPress Rules! Goin' to WordCamp …
Oh boy. I feel like a kid at Christmas. I’ve signed up to go to WordCamp Seattle, taking place next month. That’s because, of course, WordPress is the coolest thing ever. I think that every tech writer needs to know it. How I ever lived without it before now I can’t say. I could easily see it being used for docs. Toss some words up on the blog. Collect comments for said entries; engage the users. Tag items and automatically sort them into categories for archiving. Add pages and subpages and more. Import a Twitter feed or two. Dig away; use the Search box to sift through the content. Wow. What possibilities.
WordPress has tons of functionality. It’s open-source, and people are constantly developing plug-ins and themes that can be used by anybody. It’s collaboration on a grand scale.
Collaboration. That’s the future. That’s WordPress now.
Sit back and take a long look. Not just at WordPress itself, but at how it’s developed and maintained. See how everyone contributes themes and plug-ins. Start thinking of your docs as becoming open-source. What can you develop? What can we, as tech writers, do to make it easier for users to generate their own content, to join the conversation, to collaborate? It’s not enough to just think about and advocate for the user. We have to throw open the doors and let them in. We have to build the framework that allows the input.
Cut, Cut, Cut your Content and Procedures
Sure. We’ve been reducing word count in procedures for some time. It’s time to do more, however. As noted in an earlier post, we have to think mobile. Think small screens and small devices. Screen real estate will be at a premium.
With that in mind, I’m offering some suggestions on how to cut back. Remember that users are now quite computer-savvy. I don’t think we have to concern ourselves with the level of basic understanding as we did in years past.
Personally, I don’t think it’s necessary to include all the bold type such as that shown in The Old Way example. Those would make the screen too busy, anyway. If you stand back and look at that example, what jumps out at you? Right – the bold type. The main item for each step. You can scan those steps and pull out what you need. When you strip out all the extra wording, you’re left with what was bold in the first place. So why not pull all the extraneous wording? Look at The Old Way bold items and look at the Cut More example. Notice anything? Aren’t they the same?
The Old Way
1. Settings > Contacts Settings > Update Contact Information
2. Click the Permissions tab.
3. In the Access dropdown list, select Global.
4. Click Save Changes.
Cut
1. Settings > Contacts Settings > Update Contact Information
2. Tab: Permissions
3. Access: Global
4. Save Changes
Cut More
1. Settings > Contacts > Update
2. Permissions
3. Global
4. Save
In the Cut More example, you can see that I dropped some of the menu titles. I know that we’re supposed to write it exactly as it appears. However, if you can drop a word so only the main one remains, then go with it. (Contacts is the main term of Contacts Settings; is the Settings item really necessary? Of course, in such a case, a chat with the developers about a UI change might not hurt either.) It would be a judgement call every time. You’d have to see what other menu or screen items there are to ensure that there’s no confusion. If you can cut it though, do so.
I think that we could at least go with Cut or Cut More, or perhaps a combination of the two. Get out your scissors and get to work. Keep cutting until you get all the way down to the least common denominator (going back to the days when I had to break down fractions).
The Changing Roles of Writers and Editors
As my friends and family know, I’ve been mesmerized of late by a box of old letters I had stashed in my closet. The letters were from long ago – the late 70s and early 80s – before computers were in use, and definitely before e-mail.
The letters are a joy to read, as they recall wonderful memories and good times with people I’ve not seen in some time, or those I’ll never be able to visit again. Letters were often written over a period of days. Started, put down, picked up a different day. And then that was repeated, until the letter finally found its way to the mailbox.
In stark contrast to this is the technology of today: computers, e-mail, phones. We no longer write letters; we write snippets. In social media, we’re limited to the maximum character length allowed. Server capacity rules. Database limitations rule. Bandwidth matters. Plus we’re all in a hurry, so there’s not much time for reading, let alone writing.
How this applies to tech writing I haven’t completely figured out yet, but I have some ideas. I know content will be more snippet-like with quick delivery and review in mind. Finding, gathering, and monitoring the info is what will gain in importance. How much time will writers spend developing material, and how much time will be spent in searching the airwaves for existing material, determining what’s applicable and useful, and delivering it to users? How can we direct this burgeoning cloud of content?
Folksonomy – Taxonomy – Tags
Everybody puts some sort of tag on their content. Look at any post on any blog and you’ll see tags. What the tech writing community needs to do as a whole is determine some basic tags for all of us to use. This will ensure some consistency, make it easier for people to think of which tag to choose and then apply it, and provide more focused results listings. I’ll write a post and start listing some. Let’s get started.
Editorial Boards
Someone has to moderate all the user-generated content. The role of editor may be expanded from reviewing work of writers only. Writers will still need to prepare information of their own. They will also need to review what others develop to help ensure accuracy – to a point. They will undoubtedly need to look the other way at times, as the freedom to prepare one’s own information must be retained and to ensure that other points of view are represented. However, there will be times when it will be necessary to remove or delete some content. That’s where an editorial board comes in. Set the rules. Establish guidelines for submittals and content. Determine procedures for correcting or removing information. Establish your board now and get busy.
Make it Quick – Whip up a Video
Sure, there are times when it’s preferable to create a planned, long, official nice-looking online tutorial. Much of the time, though, I think you could just take out your little video cam and whip up a gem of a demo. Do we really need to have everything completely scripted and approved and run through the whole process? No. Definitely not. Not everything needs to be polished. Some videos could just be made in minutes and uploaded in seconds. They can’t – and shouldn’t – be too long in duration. For in-house uses in particular, it may be all that’s necessary. And if it’s wrong or outdated? Simply pull out the camera and make another one.
. . . . . .
After reading my letters, I’ve decided to turn off my computer sometimes and write some nice long letters to friends and family. I’ll save my snippets for another day. I don’t want to give up those snippets, but they’re like fall leaves being lifted off the sidewalk by cooling winds: there one moment, gone in the air the next. They’re meant to be momentary. Letters are meant to last.
Tech docs are not meant to last. The technology being discussed is changing so fast that the content is quickly rendered obsolete. People do not want to read that much any longer. We have to be fast, nimble, and prepared to gather, review, and move content quickly.
Might We Become Walking Computers?
What do an article in Wired magazine about attaching a sensor to your running shoe and uploading it via iPod for data analysis, a camping trip, an article about wearing video screens, a scientist husband, a discussion about wildlife parks, office work, and work by a W3C working group have in common? If you can bear with me for a moment, I’ll tell you.
We’re going to turn into walking computers. That’s what I think. This will enable us to leave cubicles and exist in our natural habitats – sans clunky laptops and the like. Crazy idea? Perhaps. Now for an explanation: here is how all this fits together (in my mind, at least).
First, a short while back I found the article on Technology Review about video screens on clothes (There’s a post about it on this blog: Use of Flexible Screens in Documentation.) Development is underway for video screens that can be “worn on wrists, and plastered on clothes.” Ok. So that’s the computer-on-clothes aspect of this.
Second, the Wired article is about how Nike and Apple have developed a sensor that you can hook on your sneaker and which uploads information about your run to the iPod you’re wearing, and you can access the data via iTunes and Nike. That’s more of the computer-on-clothes aspect, but which goes one step further: uploading data.
Third, on our recent camping trip at a lake, there was a duck family that swam around each day right by our campsite. They were in their natural habitat. My husband, in his work and in the group with which he works, focus on natural habitats. We had a family discussion at dinner the other night about wildlife parks and zoos, and I said I preferred to see creatures in their natural habitat. That made me think about office work and cubicles. Nobody likes cubicles. We would all prefer to be in our natural habitat – and an office doesn’t fit that description. Our lake campground was close to a resort town, so we saw many people in town in their natural habitat – one where they could have fun. Everyone was in casual clothes. Not a suit in sight.
Fourth, just yesterday I came across information about a W3C VoiceXML working group. I didn’t know that there was such a thing. Is there a future where one will be able to talk and have some data somehow uploaded somewhere? I haven’t read it in detail, but just the thought of it has my imagination running wild.
So here it is, all wrapped up: maybe we’ll be able to leave offices and work in our natural habitats (whatever or wherever that may be) and wear computers on our clothes, sneakers, and who knows what else, upload data via devices such as the sensor/iPod scenario, use VoiceXML for processing, and download videos and info onto our sleeves. Perhaps this could all be powered by using Velcro to strap a solar-panel strip on said sleeves. Who knows? Who needs a laptop when you just need a shirt, some sneakers and an iPod, and a mobile phone gizmo in your ear?
Wikipedia to Add Editable Video Functionality
Game over. Print is on its way out. I just read an article about Wikipedia adding video functionality down the road that will enable people to edit videos.
I’ve been figuring that video is key, and that people would take some video already made, come up with their own version, and post it somewhere. I’ve seen such videos on YouTube – not for docs, but for other topics. Functionality for people to “annotate your video, edit your video, and improve upon it–in the same way people have been doing to your text posts” makes it a whole new ball game.
See the article in Technology Review:
Wikipedia Gets Ready for a Video Upgrade
In With the New: Video
“Everything is on YouTube.”
So stated my son the other day, in response to a comment about looking to see if something might be there. I’d have to agree with him. Every time I look for something there, I’m surprised. The fact that younger kids think of YouTube as a primary source of information also gives pause.
For a while, I’ve been looking at videos on YouTube and other sites with tech writing in mind. What jumps out is that people use videos in varied, unexpected ways (to me, at least). It’s not just that people are creating videos and putting them up there. They’re also taking news broadcasts and movies and making them their own. For movies, I’ve seen videos where people have taken their favorite scenes, put them together, and added music. While some are similar, you can see that each person gives theirs a slightly different slant or uses different music. What’s important to one person is not so much to another.
Now think of that related to tech writing. You’ve researched a topic, talked to SMEs, and written something up. Still, it’s your slant on what’s most important. You’ve been trained what to look for, how to organize content, and how to prepare the info. With this usage in YouTube in mind, someone could just take what you’ve written and make their own version. Assume that users will (a) make their own videos, and (b) take something already made and create a new version. In may be from something in-house. Perhaps it may be from an external source. This has tremendous potential. Combined with comments, it could provide a wealth of information.
By now, I imagine (I hope) that companies are either using or already in the process of setting up an internal video site along the lines of YouTube. For documentation departments, I believe now is the time to try and move that along. The process may take a while to run through a company. There could be a number of issues to work out: technology requirements, security, processes, and usage guidelines are possibly a few.
We’re always the voice for the users while an app is in development. I believe that we now must be the voice for the users coming in that will expect to be able to post and review job-related videos.
I believe that the role of tech writers will change. We may shift more into content management and development of enterprise information and moderator of user-generated content. There will still be procedures to write and doc sets to create. We’ll just need to make room for whatever comes so the voice of the user is heard. All can participate. I’m looking forward to it.
Digital Natives – Digital Immigrants
It’s a generation gap, basically. Digital immigrants are at the older end; they prefer to read information in print in something they can hold in their hand. Those of a younger age prefer the new technologies, and are quite comfortable reading on the computer or on their phone. They learn differently, access information differently, and are changing everything.
That’s a very brief overview. The terms were coined by Mark Prensky a few years back. For details, view the links on my del.icio.us page. The link to that is on this page.
I’m an in-betweener. Got one foot in both camps. I understand and am very familiar with the paper-based methodologies, and am thrilled to see all these new devices and possibilities – and am using them as much as possible. I’ve seen a name for my age group: Generation Jones. http://en.wikipedia.org/wiki/Generation_Jones
My generation’s role, I believe, is that of transition-moderator. We have the expertise, like baby-boomers, but we’re not ready to retire just yet. Plus we’re ready to embrace the new technologies. So maybe, just maybe, we can help companies transition through this massive shift in demographics that is upon us – and have fun to boot!