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

Twitter List: Create
Cut, Cut, Cut Your Content and Procedures
Why Tech Writers Should Know Database Design