7 Ways to Keep Up With Trends
Two facts: we have to try and keep up with all the changes in IT, and we don’t have much time, if any, to do so. What can you do? Here are some ideas. They’ve been working well for me. Hopefully they will for you as well.
Blogs
Bloggers are out there in the trenches: finding information, presenting information about trends, explaining things and providing tips on various subjects. It’s always worth your time to review blogs. A good resource to find them is:
In fact, there’s probably an Alltop page for any topic you’d like to view. Just select your topic of choice and go from there. I’ve included some for different topics in my lists of links on this blog.
You can also make a customized myAlltop page and put your favorite blogs all in one place.
Also, check Ivan Walsh’s list of tech writing blogs. He also includes international writing considerations, so that’s something not to miss.
All hail Twitter! I can’t survive without it. I use it for work, primarily. I prefer to follow feeds that are packed with information and links to articles, or those that pass on information. It’s great to follow people that focus on a particular topic; their expertise comes through, as they have reviewed materials and chosen what they think matters most. So, I see it as expert advice delivered daily to my door. It saves so much time; I needn’t search high and low for information. An expert has done that already. All I need to do is review what they’ve posted. And boy, have they ever posted excellent information.
Twitter is my starting point for the day. It’s my morning paper, so to speak, and is a great way to jumpstart the synapses each morning. I enjoy perusing the articles and information that is posted.
eServer Technical Communication Library
Hello! This is a HUGE database packed with timely, thought-provoking articles. It is updated regularly. It’s a must-visit resource. I’ve signed up for their RSS feed , and try to check it each day, if possible. If unable to, I check it whenever I can. Sign up for the feed. Go there, go there, go there – and go there regularly.
There are a number of writing and other IT groups you can sign up for. Actually, there’s probably a group for just about any topic you can think of. I’ve got some listed on my profile, but there are plenty of others out there. Join some groups, follow the discussions, and perhaps chime in once in a while. You can set it so you get daily or weekly digests of discussions sent directly to your e-mail address.
Websites
Surely you’ll find websites you’ll want to peruse from time to time for information. Mashable is one that comes to mind offhand. It’s an excellent resource. Also, the W3C site is a good site to review periodically. No doubt, there are sites that one should visit periodically, at least. Plenty to see out there on the Internet, is there not?
Mailing Lists
Of course, there are always good ‘ol mailing lists. No explanation required, I believe.
RSS Feeds
This is, of course, another way to follow your favorite blogs and other items. It’s nice to have these in your back pocket.
…………………………….
That’s all I can think of at the moment. However, as you can see, there are ways to quickly review quite a bit of information for many topics. Happy reading!
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
Lessons Learned: Procedure Written in Twitter
Last week, I thought I’d experiment and write a quick procedure in Twitter. This goes right along with my thoughts that new methods should be used for creating docs. Given that microblogging is here to stay, as is real-time, I decided to give it a try. There were two main thoughts in play: see if it was possible to condense a procedure into steps of 140 characters or less, and test a real-time situation, as trending topics always appear in Twitter and it may be necessary to write something there. Plus, I thought it would be fun. Which it was.
Thus, my exercise in microblogging a procedure began – and evolved immediately into a real-time writing event. I learned plenty in the process, as you’ll see below.
Content Development
Twitter-Specific Considerations
- Read from bottom to top
- No bold, italic, or formatting of any kind
- Tweets might get interrupted by other tweets, as new ones come in continually. Hence, you can lose continuity.
Writing Approach
- Included numbers in all the procedure tweets. This included the title tweet to set off the series.
- Combined steps when possible
- Abbreviated content and used snippets instead of full sentences
- Wrote procedure immediately, posting one tweet as soon as the previous one posted. This was to limit the possibility of new tweets coming in which would break up the procedure.
- Wrote very quickly. I used an existing procedure written in more detail. Took the steps and modified content (as noted above) to fit in tweets. Did this on the fly; not beforehand. You have to edit as you go to fit steps into tweets and determine what to include in each.
Input from Users
I actively asked for input. First, it was when I initially published the tweets. I wondered what other tech writers thought about it, not really knowing what to expect. Then, I asked for comments as I went, and incorporated some and updated accordingly. I continued to ask for and incorporate suggestions as appropriate.
What was really great was the amount and depth of input that came in. That immediately changed the situation from a one-writer task to a collaborative effort of a makeshift team, in effect. It was as though an ad hoc team formed for a moment in time, discussed items, and then immediately disbanded. It was completely virtual, and people didn’t know each other, really. How cool is that? What potential there is. I suppose that’s the nature of virtual communication these days, but it’s still interesting on a real-time basis.
Of course, the flip side is that you may end up with too much input. That’s where triage mentality will come into play. You’ll have to decide what to include and incorporate right then and there. Also, you may want to address some items immediately, and others later. Some you may need to review more, depending on content and whether or not you think the input would be applicable or not. There will be many, many such decisions to make on the fly. My thought is that you still want all the input you can get, even if you can’t get to it at the moment, or if it’s not something you’ll eventually integrate. If there’s too much, perhaps you could write a tweet that says something to the effect of “Addressing input as quickly as possible. Please keep sending comments.” Then review everything when things calm down, or enter a revised procedure afterward.
Also, if you were in the midst of a rush to get out information, wouldn’t you want to know of anything you missed? If it’s critical, if it’s a negative viral situation, then you want to hear what people are thinking. And then you need to address it. Either you fix it right then, or write a new item for your FAQs and have a link to it in a tweet.
Just as there’s no such thing as a stupid question, there’s no such thing as bad input in today’s world. Ignoring input could prove disastrous. You have to be open to suggestion.
Managing the Process
If possible, I would definitely have an entire procedure already written, or at least sketched out. This enables you to input tweets one after the other (as noted above), editing as you go. It may not be perfect – there may not be time for that, but you’d have a base from which to work.
Deleting and Revising Tweets
You can’t really delete a tweet and rewrite it, or insert a revised one in the exact location. Well, OK – technically, you could delete one. However, you would lose continuity and break the procedure. Plus, the tweet is still there, archived somewhere, so could show up at a later date if someone looks for it.
This begs the question: when do you leave a tweet as is, even if not completely perfect or correct, and when do you rewrite the entire procedure? My gut response is that if it is not correct in a major way, then it must be rewritten. My belief is that accuracy is still the most important aspect of tech writing. That may be old-school, but it’s still my mantra. Makes sense to me. However, I’m all for lightening up a bit with the rules of tech writing. When you’re working in Twitter, I think you need to bend them once in a while.
Managing Input
I was very busy handling input from just several people. Also, I purposefully tried to address comments and update accordingly immediately, to put as much pressure on as possible to see what would happen. I didn’t want to think much; I wanted to react. That’s a situation I can envision occurring some day. However, I was sure enough of the procedure that I thought people would basically be able to figure it out. That was based on the audience; I assumed familiarity with using Twitter.
If the procedure had been more detailed, I would have:
- Posted a tweet that a procedure was being worked on at that moment
- Created a longer version somewhere and included a link to it in a tweet
- Put a bare-bones procedure in Twitter, as best I could
Posting Updates
I felt it was very important to provide status updates as I went. That was an important part of the exercise. It’s also one more decision to make on the fly: how often do you update people, and where do you do so? What information do you include in the update?
I added new tweets, and updated my blog post with new information for each update. After the first update, I added time information as well. There were two reasons for that: show that it was actively being worked on, and enable users to see what information they want to focus on, given the time of the update. That may prove critical in some cases, so I think I’d always include times in posts. For tweets, the timestamp is automatically included.
In my case, I posted updated tweets designated by “UPDATE” as the starting. Example:
UPDATE: Create Twitter List proc (12/29). New: step 6 > List created; add feeds by selecting in Followers list or searching (proc follows)
UPDATES: Create Twitter List proc. Update 2: fixes 12:45 pm. Update 3: thoughts 1:13 pm http://bit.ly/53eoe5
Conclusions – Recommendations
- Use Twitter for procedures in a real-time situation. Also, start using it frequently. People use Twitter to disseminate and find information. Docs should be there in one form or another. Either write procedures, or link to online docs.
- Keep the number of steps to a minimum. Keep in mind that you may need to add a step number to the title.
- Provide regular status updates.
- Set up internal processes for handling real-time situations.
- Set up a separate support feed for procedures and announcements.
- Do not even think of writing perfect procedure tweets when you’re writing something quickly. In some cases, that might be possible. However – always keep in mind that if you don’t post the tweets immediately, one after the other, they may get lost in between tweets from others. Just as it’s more difficult to follow a driver to a destination you’re unfamiliar with if a car gets in line between you and the lead car, it can be difficult to follow a tweeted procedure if tweets get in between posts.
In this situation, it’s also true that someone can select your feed on its own, and you’d see the procedure in its entirety as you intended. You can’t assume that, though. Are people likely to just switch over to your feed? Probably not at the particular time you’re writing. Later, perhaps. Don’t count on it, though. (This is another argument for setting up a separate support feed.)
Writing the Tweets
- If it’s a crisis – provide frequent status updates
- Update FAQs or base online docs simultaneously
- If it’s an immediate event, determine if a team response is necessary – or be ready for one if it escalates
Resources Required
I think that you need one or more writers to:
- Test and write tweets
- Update FAQs or main docs
- Update a blog, website home page, or other location for real-time status
- Monitor and answer tweets from users
- Line up reviewers to gauge response (per suggestion from Larry Kunz)
Plan
- Triage incoming tweets: which to address, and when?
- Triage updates: when, where posted? What if the format for each option?
- Who does what: (see Resources list above)
- Tech support coordination: set up processes
- Escalation plan: when to call in more resources or managers
That’s all I can think of at the moment. If anything else comes to mind, I’ll just update this post.
Notes
Would I do this again? Absolutely. It was fun, for one thing. There’s much to learn, for another. Finally, and most importantly, I think it’s here to stay, so we better determine how to microblog docs.
More >
To see the procedures and input, look at my feed for 12/29/09. You can also find additional comments by searching on @2morodocs.
Thanks to Larry Kunz (@larry_kunz), Julio Vazquez (@juliov27612), and David Farbey (@dfarb) for comments and offering input and suggestions real-time. That was fun.
http://www.twitter.com/2morodocs
Related posts:
Real time: it’s sooooo last second
My First Procedure Written in Twitter
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.
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
Open-Source Tech Writing: the Time is Now
Recently, I started working with WordPress. For those unfamiliar with WP, it’s an open-source platform used for blogging, websites, and the like. Development and maintenance is completed by a world-wide community. There’s an incredible energy and community that is part of it. Last month, I attended a WordCamp event. Along with the information I obtained, I came away with one main thought:
It’s time to apply this open-source model to technical writing.
Why? The reason is simple. As I noted in an earlier post about industry trends, it’s impossible to keep up with all the changes coming through. We are all going to have to collaborate like never before. Everyone should select at least one area of interest and specialize as best they can. Then we will need to start meeting and sharing information. Immediately.
There are several ways to do this, I believe.
Virtual
Twitter is one example and is already well underway. If you’re looking for information about a topic, find some feeds to follow that are packed with good leads. There are many out there. I’ve been collecting some; take a look at the list referenced below.
The EServer Technical Communication Library (TCLibrary) is another great source. They’re collecting and cataloging an incredible amount of information related to the field, including the use of new technologies. Peruse the site, sign up for the RSS feed, and follow them on Twitter.
Blogs are another source of info. Alltop has a great list of blogs on their Technical Writing page; that’s a good starting point. They also have pages for topics I think are of interest for tech writers, such as Cloud Computing and Agile Programming. Review the topics on Alltop and I’m sure you’ll find something. Ivan Walsh has also compiled a list of 50 blogs to follow; it includes international writers.
Face-to-Face Meetings
Perhaps it’s time to start setting up Meetups to just start gathering and talking about all of this. Do we always need to have a planned meeting with a planned topic? Perhaps not. Let’s just start talking. Come up with a situation a person is having with a project and have people chime in with ideas/problems/fixes and whatever other thoughts they have. Then perhaps, along the line of WordCamps, someone could videotape and stream it, then poof! Face-to-face becomes virtual for anyone anywhere at anytime. Let’s toss our knowledge up to the cloud and see where it goes.
Looking for Contributors
With all this in mind, I’ve decided to expand my blog to include guest posts from contributors that have expertise in or have researched a particular area. If you would like to become a contributor and submit a post, please contact me or send a DM on Twitter. I wouldn’t be able to pay for any content, but would be interested in sharing information. I’m about to roll out my new design, and have a couple of contributors lined up, so let’s start collaborating!
Links
Ivan Walsh: Top 50 Technical Writers on the Web
Alltop Technical Writing
EServer Technical Communication Library (TCLibrary)
Meetup.com
Related Posts
Must-Follow Trends for Tech Writers
Must-Follow Twitter Feeds for Tech Writers
Changing Roles of Writers and Editors
A New Doc Strategy
Contact Me
Julie Norris
HTML 5: What Tech Writers Need to Consider
Wow. I knew that there were many items to consider when writing documentation these days. However, there is much more than I realized. For example, today I started looking at HTML 5 more in-depth. As I read through the information on the W3C site, it became clear that big changes are in store that will affect technical writers.
In HTML 5, a large number of elements will possibly be relegated to setup in CSS only. The major one I noticed initially is tables, as use of tables is obviously prevalent in docs. It appears that presentation elements will be handled through CSS. That includes everything, basically: width, padding, height, and borders are among the attributes that are changing.
Given all these changes, I looked at the current state of CSS on the W3C website. Version 2.1 is now in Candidate Recommendation status.
Frame support will also be discontinued. I imagine that most people do not use frames at this point. If you are, consider stopping that practice. Frames are also not recommended for mobile devices, and search engines have difficulty reading them as well.
References to Review
HTML 5 differences from HTML 4
Recommendations
Move all presentation configuration to a CSS file
While work will continue to evolve with HTML 5, it may be difficult to know what to include or not. However, I think that at this point, if you’re not already, you can at least focus on moving all presentation configuration to a CSS file, particularly for tables. Use the information on the W3C site as a guide, and realize that development is yet in progress.
Discontinue use of frames
For reasons noted above, it’s best to avoid use of frames.
Keep up with changes
On my Twitter feed, I’ve listed some links related to HTML 5 and will continue to do so. I’ll also note feeds that may be helpful to follow in a #followfriday entry. Keep in mind, too, that this will also affect mobile items.
I need to look at all this in more detail, and determine how it might affect XML and XSL files. For the moment, just be aware: there are even more items to plan for when setting up your documentation. Don’t assume that your style sheets of today will be adequate for docs down the road.
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.
Legal Requirements in the New Age
With the recent news this past week about a woman being sued $50K for a tweet she wrote and the resultant backlash on the company that was suing, it started me thinking about legal ramifications of using social media for business. I’m all for using social media as part of an overall tech doc strategy, but this should give you pause.
If you’re a company that is addressed negatively over Twitter, Facebook, YouTube, or whatever else comes out, how do you respond? Will the comments or your response go viral?
Let’s imagine for a moment that you’re using Twitter for real-time tech support. Would you provide an answer in your tweet? Or might you perhaps say a few words and have a link back to your company site, where you have all your legalese spelled out? If you always use links, will your users walk away? There may be a fine line to determine. Only time will tell.
If someone made a negative comment about your docs, might you contact them and write a tweet on their feed (or whatever else) or a direct message to say something along the lines of “hey – thanks for your input. We’ll address that problem.” Or would that run the risk of going viral? What will your response be? What do you address, and what do you let sit? And don’t forget that once something is out there, it can be transformed into something else for a different mode of social media – particularly video.
I believe that when planning a doc strategy, particularly use of social media, you should always consider legal requirements and ramifications as part of the review. Legal considerations are going to flush out with time, as new issues become known (and some very quickly).
Perhaps the best course of action is to come up with a plan now about what you’ll do if something related to your docs goes viral in a negative way. Have some wording worked out with Legal or Communications ahead of time. Have a process for incorporating some immediate sort of change to your docs, FAQ, Twitter feed, Facebook page, or whatever else you have.
Obviously, you won’t be able to address everything that someone might write. There are regular deadlines that must be met, of course. You should, however, be able to identify the type of comment that should be addressed. One suggestion: perhaps an alert level could be established. Go with a simple green-yellow-red stoplight scenario to start with. If you have a plan about what you will or won’t address in what sort of situation, and how to do so, you’ll be ahead of the game. Perhaps if you have a plan, comments won’t go viral because you’ve identified their potential severity and addressed them accordingly – and swiftly. Will your response fuel the flames or put them out?
Consider a plan that identifies who in your company will address phone or other inquiries if something goes viral (read the article and you’ll see what I mean). If you can respond along the lines of “We have a process in place and will have this addressed and fixed within a (set time period)” rather than a perceived-as-negative comment, a situation may calm down as quickly as it arose.
One more thought: if you run a real-time search on your company several times a day, perhaps you can find and address some negative comments before they even get picked up by anyone. Prevention, planning, quick action: those are the new realities.
Reference:
Article from Mashable.com: “Horizon Realty Responds to Lawsuit Twitter Controversy“