All of my earlier talk.bmc blog posts have been copied to my BMCDN blog. Please join me at http://developer.bmc.com/communities/blogs/writeon to continue the conversation.
Thank you
Posted: April 17, 2009
All of my earlier talk.bmc blog posts have been copied to my BMCDN blog. Please join me at http://developer.bmc.com/communities/blogs/writeon to continue the conversation.
Thank you
Posted: April 17, 2009
Yet another datapoint to confirm that we're ready to go green in IDD.
When users (or IT staff) want to read only certain topics in the user guides, providing printed manuals is an even bigger waste. As a self-professed techie problem management analyst writes, [printed] software manuals are an absolute waste of paper, and do nothing but kill trees. He proposes customized documentation. However, before you get to the point of custom on-demand software manuals, you can use the search capabilities in help files and online PDFs to get to the information you need, without wading through a sea of paper.
Because I haven't received many comments, I felt like I was talking to myself, and wondered if more than a handful of people were reading. I checked the web stats, and found that more than a handful of you are reading my blog. My most popular pages seem to be:
Why don't you leave me a comment? Please let me know what you like to read.... and what you'd like to read about.
I just played a business efficiency game that shows how IT can make a significant reduction in their carbon footprint and reduce costs by applying Business Service Management.
Before I played this game, I knew that Business Service Management could be used to align IT with the business. But I hadn't realized how much this could improve a company's carbon footprint.
Ronald Bartels pointed me to a page on his blog about problem management. When I check his posts about documentation, I see that while he is interested in the documentation about products, he seems mostly concerned with the documentation created by an IT department that is relevant to problem management - internally created documentation about how servers and other areas managed by the IT department have been set up, and standard operating procedures.
What sort of documentation do you work with?
I work as an information developer, and mostly I work on user and administrator guides. That means that I'm producing pages and pages of information. So, how do I reduce the number of pages being printed?
Reducing the amount of printed documentation sent to customers
Last fall, I asked: Are printed manuals a thing of the past? My iPod came with a small instructive brochure in the box, and the rest of the documentation was available online.
BMC Software customers can download software, instead of ordering a physical box. But customers have indicated that even when they get a physical kit, they don't need all the printed manuals. Now customers will get electronic copies of documentation, and will only get printed copies on request.
Working online instead of on paper
If you're not an information developer, you might think that all my work is always online. Of course, I do my writing on the computer. But reviews and proof reading used to take place in a mix of paper and online.
Now, almost all work is taking place online. We can do proof reading from the PDFs. I enable commenting in PDFs, so that editors and reviewers can add their comments even from Acrobat Reader. They don't have to print drafts of my guides. And as a bonus, it's easier for me to work from their online comments, because I don't have to decipher handwriting.
What are you doing?
What are you doing to reduce your environmental impact at work? I'd love to hear what else I could be doing.
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?
I read at The Content Wrangler that a new OASIS committee is being formed to explore this use of DITA. Apparently, they're looking for committee members, so if you'd like to get involved, check out the article for more information.
As a technical writer, this could be pretty cool. Imagine if all business
documents were written with DITA specializations. Perhaps I could pull
planning and design topics into technical documentation. People throughout
the organization could pull topics from manuals into their documents.
Some of the topics we'd like to discuss at future meetings include:
I joined the mailing list, and some of us are setting up a meeting to explore the possibility of a chapter. If you're in Toronto, and want to join us, we'll be meeting:
When: Tuesday, October 23, 6:30 pm
Update: modified location
Where: Spring Rolls (Yonge & Bloor location of this restaurant, 2nd floor)
So we can adjust the reservation, please let us know you're coming by:
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.
DITA
On October 9, I'll attend the monthly meeting of the Toronto chapter of the Society for Technical Communications (STC). Michael Priestley, will be speaking about the adoption of DITA in a wide range of contexts, and about DITA 1.1. I've heard Michael Priestley about the basics of DITA. I'm interested to find out how various organizations are adapting DITA to their needs.
Social Media Club
About a month or so ago, Ynema Magnum invited me (along with other talk.bmc bloggers) to a meeting of the Social Media Club. Unfortunately, I couldn't attend, as the meeting was in Austin, but Ynema pointed out that there are chapters of the Social Media Club all over. The Toronto chapter hasn't taken off yet, but we do have a mailing list. Robin (one of the other members of the mailing list) and I are planning a meeting later this month, to help get the Toronto chapter started. By the way, if you're in Toronto and interested in social media (such as blogging, and social networks, such as LinkedIn and Facebook), consider joining the mailing list, so that you can find out about the October and future meetings.
Advanced technical communication and project management
At the end of this month, I'll head out to New Orleans for Lavacon, the conference for advanced technical communication and project management. I'm looking forward to meeting in-person with technical communications professionals whom I've mostly dealt with on-line, and sharing great ideas on managing technical communications projects.
What about you?
If you'll be at any of these events, please do say hello. I love meeting people in the professional communications family. If these events don't work for you:
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:
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.
What sort of documentation do you get with the iPod?
Recently, I finally got an iPod. Of course, as a writer, I find myself paying attention to how they provide documentation, and it gives me some ideas for documentation minimalism. Even with their simple design, Apple includes a small printed manual. More of a mini-brochure with just a few basics to get started.
You have to go online to get a more complete manual. But what a great idea! Besides not wasting paper on printing (I didn't print my copy), I have the latest version.
But even if you don't look at the manual, some of the less obvious
features are displayed on the iPod where you need it. For example, a note in
the Contact section provides instructions on how to load contacts if you
don't synchronize with outlook. Or when I accidentally created an on-the-go
play list, an additional on-the-go play list appeared and included a note
explaining the feature.
What does this mean for documenting larger products?
The iPod is a simple consumer device. Although it's a great device, it supports only limited functionality (not that I necessarily want it to do more). Does the iPod's documentation offer any suggestions to how to improve the documentation experience for products that offer greater functionality, such as BMC Remedy Service Desk?
To me, it seems like there are a few lessons that can be learned:
