Often, when I look at news how technology might affect writing, I envision myself sitting at a computer, using some new software that lets me use XML tags to mark up my content, or that uses Web 2.0 to interact with my readers.

But today, I am sitting on my sofa, writing this blog entry, not on my laptop, but with pen on a piece of paper. It looks and feels like old technology, but really it's new. The pad of paper is clipped into a special board (actually, a computer, although it barely resembles one), and the pen - although it does write with ink - is sending signals to the board. The board captures what I write (or draw). After, I will upload this entry to a more traditional computer, and run the tools I typically think of as hi-tech to complete the publication process.

How else can low-tech be harnessed to meet our hi-tech needs? Do you have a favorite low-tech tool that you wish could meet your hi-tech needs?

Robin Yap and I planned a meeting to launch the Toronto chapter of the Social Media Club (SMC). This evening over dinner, we met others interested in the SMC and discussed our involvement in social media, and what we'd like to get from the SMC.

Some of the topics we'd like to discuss at future meetings include:

• Best practices for using various social media tools (such as blogging, Facebook, LinkedIn)
• How to attract readers to your blog
• Using social media for social activism

We agreed to use multiple social media to publicize the group, and I started a facebook   group, to facilitate future planning.

DITA was designed for modular information, such as technical publications, help systems, or web sites. But now, more people are trying to use DITA to fit their needs.

New and cool things are happening with DITA

Apparently, lots of people are creating specializations. It's not so surprising that companies are creating their own specializations, which allows them to use DITA in a way that better fits their needs.

What was surprising was seeing how a large number of organizations and other groups are working together to create specializations that are available for others to use. For example, there are specializations being developed for the manufacturing industry, for the pharmaceutical industry, and for learning and training.

The learning and training specialization gives me hope that information topics developed by IDD could be reused by instructional designers.

Link round-up

I checked out the links that Michael Priestley mentioned. They're a great source for more information about DITA.

• OASIS DITA Technical Committee - This is where the work behind DITA as an open standard is happening. If you're new to DITA, check out their DITA FAQ. You can find out what's happening with the DITA standard, and with the subcommittees for specializations that might become standards. And, of course, more links.
• DITA Open Toolkit - This toolkit is a free open source implementation of DITA in Java. I've heard that it's not trivial to implement, so this is probably only for those serious about trying DITA without a commercial product.
• DITA online community - This community is hosted by OASIS. It lists news and events, includes a wiki, and even tutorials. It also includes blogs about DITA.
  
• DITA Users Yahoo group - If you have questions about using DITA, this is a place to pose questions, and possibly get answers.
  
• DITA Users.org - This is a well-organized one-stop site for resources, tools, tutorials, and examples. Members get file storage space, access to the web-based XML editor DITA Storm, and other services.

On   Palimpset, Sarah blogged that she has recently joined Facebook and mused whether Facebook could be used for technical support or other technical communications.

I started wondering what documentation might look like on Facebook or other social media. Currently, most documentation is the equivalent of Web 1.0 - printed manuals, PDFs, online help, and other forms that present useful information, but don't allow users to reorganize the information, to add to it, or to communicate. Communications with users are typically handled separately from documentation.

What might documentation look like on the Facebook platform or other social media (Web 2.0) platforms?

What is salient about Facebook for documentation?

On your Facebook profile, information is presented in modules. These modules are typically small, although some expand to fit the content. As a user, you can control which modules to display, as well as their location on the screen.

Facebook provides space for you or others to write ("the wall"). Additionally, many of the modules provide space to add comments. Notes can be used for longer, article-length pieces of information.

On a user's profile, Facebook lists some of the user's friends, along with a link to display all friends.

How are these features relevant to documentation?

Information modules aren't new to technical writing. They're a key aspect of Content Management Systems, and have really taken off with XML and DITA. If we are using Facebook as a model, these information modules, would mostly contain small chunks of information, although some would expand for the needed content.

The user would be able to control which types of modules to display, and where to locate them on the screen.

Users would be able to annotate the documentation. These might be comments added to individual topics. If this were help on a multi-user system, each screen would have a place for messages, which could be a forum for adding tips or asking questions.

Facebook is about people; the friends displayed are part of the user's social network. For documentation, instead of friends, a list of related topics would be listed. If the list were over six, six topics would be listed, with a link to the complete list of related topics.

Can you give an example of how this might work?

On Facebook, your profile is centered around you, the user. Everything is about you and your friends. For documentation, we must find another starting point. For example, if Facebook-like documentation were provided as a help system, the starting point could be the user's screen when clicking Help.

Information modules might be available to:

• List all tasks that can be performed on the current screen (with links to more information about the tasks)
• List all tasks that include the current screen.
• Describe the purpose of key fields on the screen.
• Provide keyboard shortcuts, or other sorts of accelerators.

Notes would be available to present concepts and procedures relevant to the current screen.

A list of related tasks would be available.

The user could writer on "the wall" to write notes to himself (or other users) about the current screen, and to pose questions that other users (or someone in Support) might answer.

Does this seem like too much information to fit on one screen?

Perhaps. But if the system is as configurable as the Facebook profiles, the user can remove any modules that he doesn't want to see. Also, he can arrange the modules in any order or column, so that the overall layout meets his needs.

What about other social media platforms?

What about them? What do you think documentation would be like if it used a platform based on Myspace, LinkedIn, or twitter? Does Facebook inspire you in a different way?

If you have your own vision, write it up in your blog, and leave me a   comment. I'll post a round-up of the entries.

Recently, I read on Mark Cuban's blog how he realized that he's forgotten how to write. He's been taking notes electronically and become proficient at it - then when he was stuck in a meeting trying to take pen to paper, he realized that his skills had degraded.

I don't think I'll forget how to put pen to paper. After a brief experiment with electronic note-taking, I returned to hand-written notes. His post makes me wonder, however, whether there are other skills I've forgotten, and whether they'll prove useful again. For example, when I first started using a computer to write, I had to insert all sorts of mark-up tags in the middle of my writing. There was no WYSIWIG capability on terminals, and my PC didn't even have a graphics card.

Now, of course, I can write and mark my text as bold or italic with the click of a button, and see the effects of my mark-up. Will I ever need to see tags as plain text again? It could be a useful skill to relearn for working with XML. What do you think?

Have you ever forgotten a skill and wanted to use it again?

More and more developers are moving to Agile. As a result, information developers and technical writers are struggling with the best approach to creating documentation in an Agile environment. We don't want to write too much too early, for fear we will have to rework the document, as features change in subsequent iterations.

Anne Gentle blogged   about creating a Documentation Plan in an Agile environment. Her approach is to keep the doc plan high-level, and not get into all the details. My approach is to include updates to the doc plan in the schedule.   I plan to work on the most solid features first, and update plans with each iteration.

One great suggestion from Melody Locke is to include documentation in the acceptance criteria. I like this suggestion regardless of the development methodology being used. If documentation is truly part of the product, the product isn't complete without appropriate and accurate documentation.

I'm still fairly new to agile. But I like getting feedback from customers early on. When we receive customer feedback in the early stages, it's easier to make adjustments. When I get feedback on the documentation, I have time to make the guides better serve the customer's information needs.

- By Michele Marques, Lead Information Developer, ITSM

An introduction to Michele Marques and her Write On blog with talk.bmc.com.

Although I've been writing personal blogs for some time, I feel a little nervous with my first corporate blog here at talk.bmc. I probably don't know you, and you don't know me. I'm no longer used to speaking publicly. Although many years ago at the Schulich School of Business, I gave a presentation to 600 incoming MBA students.

As a technical writer, I've become accustomed to anonymity. Plenty of people read what I write (manuals, white papers, technical bulletins, and so on), but only a few people know those are my words.

In case you haven't already read my bio, let me introduce myself. I started with BMC a couple of years ago as a technical writer. I write about products in the BMC Remedy IT Service Management (BMC Remedy ITSM) suite and solutions using those applications.

Recently, I had the opportunity to meet some customers. I came away from that meeting surprised and energized. Surprised - because some of their challenges were different from my preconceptions. Energized - because I had ideas I wanted to bring to our documentation that might enhance the customer experience. Hopefully, your experience.

I'm glad to have this opportunity to blog at BMC, because this will give me a forum where I can talk about ideas and get feedback from: customers, people in environments similar to our customers, and to others who are facing similar challenges.

Are you a customer? Are you providing IT service? I'd love to hear from you, to learn more about your challenges and what information you're seeking.