Session takeaways: the STC India annual conference 2015

About a month ago, I attended the STC India annual conference at Pune. That it's been a month and it's still playing on my mind is proof that, this time, I had solid takeaways from the conference (this doesn't happen every time, you know). In this blog post, I will talk about those takeaways.

First, the pre-conference. I think we should do away with the "pre" suffix altogether — it isn't something one *must* do before attending the conference; it's rather something that one does *in* the conference. But, let me not nitpick. Pre-conference, Vidhya VKumar and I took a day-long workshop on writing with DITA. This meant that I missed an excellent track that had workshops on regex (by Savio) and on scripting by techwriters (by Puneet). As soon as I could, I looked at the session slides, and got my first takeaways — pointers to places where I could teach myself regex (as also ReST API, by Punam) and examples of where I can put my scripting (v. v. basic Python) knowledge to good use. I am hoping that the sessions by Savio (regex) and Puneet (scripting) get repeated at an STC city session in 2016, or even better still, at the annual conference of 2016.

I have always believed I am not cut for management. This perception was reinforced when I looked at the session slides of Bhavana and Brinda (preconference management track). The slides also nudged me to develop myself as a technical expert, and gave sufficient pointers to get me started.

I must also mention the preconf session slides on strategy by Wasique. To me, the slides look extremely well-thought out and I am sure I would have benefited much had I been physically present at the session. This, again, is one more session that I hope the STC people arrange for a repeat in 2016.

Day 1  started well, with Wasique (again) on...Bombay films. Well, not really; that part came much much later but I liked the session (seriously) because it explained the WHY of short attention spans. To someone like me who's internalised Twitter, DITA, and progressive disclosure, chunking information comes easily but knowing the science  — the real actual neuroscience  — behind why doing what I do is good...is great.

Because there were parallel tracks, I missed a few sessions on Day 1 too (mainly because of a few bad choices). When I looked at the slides of these missed sessions, I regretted not having been at Seema's session on cognitive load. Again, to me, serving info in byte-sized pieces is natural but we can always (always) learn more, and the slides of this session did have a few takeaways for me.

Day 2, I missed Mayur's session on HTML 5. The slides are packed with information; I am sure this was one of the most highly rated sessions at the conference. I did attend the Quick Bytes session: small, 10-minute talks. I loved to tiny little bits Amruta's talk on logical fallacies in text, and was very impressed with Swati's journey as an innovator. Then, I went away for Antarchakshu. Folks, if you ever ever ever get a chance to attend one of these sessions (the Xavier's Instt at Bombay does these), do NOT pass the chance up. Before Antarchakshu, "accessibility" was just one more thing to check off a release-readiness list. After Antarchakshu, .... well :) It opened my eyes. It really did.

And so, yes, these are the sessions that I gained from.

I look forward to the 2016 conference.

---

Slides and session details of conference are at http://stc-india.org/conferences/2015/program.

The Udaan publishing story

Udaan is the publication of the STC India annual conference 2015. It was released at the conference that happened between Dec 10 through 12 at Pune. This blog post talks about the backend publishing process.

Udaan, the name, was conceived by the conference program manager, Mugdha Kulkarni. When she handed the Udaan brief to us, Mugdha was very clear:

• It should be something that people will keep on their desks for at least a month or two. Not something that goes to the raddiwala on Day 2 of the conference.
• If we're having an online version, it should really be a complete digital experience. Not boring web pages.

The first item on that list could be addressed by getting good articles. We spread the word around, and when the articles started coming in, and we began to see all the non-boring possibilities in them, it became clear that *just* HTML won't do. We wanted interaction and, consequently, javascript and styling.

Which became something of a problem, initially. The agency that did the conference web presence put up their hands. What we were asking for needed "programming knowledge", they said, and beyond the scope of free services.  Like someone from Allahabad would say, "Itne mein to, bhaiyya, bas itna hi ho payega."

Which meant, hosting Udaan on stc-india.org, where resided the other pages relating to the conference, would be in direct contravention of the second item in our brief: non-boring web pages. A different hosting site was needed. The next choice seemed easy: a blog. Either Wordpress or Blogger. But wait! We need javascript. Neither free Wordpress nor Blogger are JS-friendly. So, no, we need some other solution. Enter GitHub.

O dear GitHub, how do I love thee? Let me count the ways:

• It is free.
• It gives you a repository. You store all your content there. And content means *anything*. Any image, any text, any code, any sound, any movie...
• It gives you on-click publishing (and a public URL) for your repository content.
• It gives you stuff like version control and multi-author checkins and checkouts.
• It has its own bugtracker (which we used extensively during the review period).
• It takes content out of your laptop (which can crash any day, or whose owner might break an arm) and puts it on its server (which can also crash but at least the hospital scenario is unlikely).

Perfect. So, GitHub was to be the platform.

Now to the content.

Everything is in HTML. That means, in the beginning, the only tool I needed was Programmer's Notepad 2. Even plain Notepad would've been sufficient, but line numbers and word wrap are handy! The authors sent in their articles in MS Word and I did a paragraph-by-paragraph copy-paste to HTML. Why didn't I just do a Save As in MS Word and generate an HTML file? Because, when an MS Word file is converted to HTML, a lot of unnecessary styling classes get added and, consequently, the end result is not "clean" HTML.

For the apparent "programming knowledge", I just googled. I had no intention of reinventing the wheel. You'll see that Udaan uses Javascript snippets that are freely available on the net. Udaan also uses styling elements from free CSS available on the net. The main look-and-feel is from the w3schools CSS; I chose it because not only is it the place where many of us learnt our HTML from, but also because their CSS uses responsive design principles.  Udaan also uses icons and images available freely on the net. In short, Udaan uses free stuff, thanks to helpful people who think about giving back to the community and therefore share their work so freely.

But let me talk about content referencing. It's something that's easy in DITA but not so easy in HTML. For consistency, I wanted to use boilerplate text for the headers and footers, and I needed a referencing mechanism that does not need a Ctrl-C + Ctrl-V. The solution that I used is this:

1. Make HTML files with the boilerplate text. For Udaan, the header file contains the Michi masthead, the clickable Udaan heading, and the ToC (accessed through the hamburger menu). The footer file contains the conference date banner, sponsor logos, and code for the scroll-to-top button.
2. Place the boilerplate files in the same folder that contains the other HTML files that will "call" the boilerplate text. This is important. The referencing mechanism does not work beyond one folder level.
   
   
3. In the file that calls the boilerplate text, insert a <script> tag like this:
   
4. At the place where the boilerplate text is needed in the calling file, create a <div> tag, like this:
   

Notice that the "id" attribute of the <div> element is the same as the # name that I gave in my <script> tag.
Notice also that the <div> tag has no content and looks like an empty tag. But, when the file is rendered in a browser, the actual contents of the file linked to that <div> element will be shown in this <div>.

This content referencing works perfectly off a server (such as a GitHub content repo) but not in a local file system, so if you're trying this out on your laptop, 8 times out of 10, this won't work. You'll need to test it on a server. I don't know why it works 2 times out of 10.

Let me also talk about folder structure. To maintain our sanity, instead of having just one folder that contains all of the files, I created several folders: each folder holds only one kind of content. I thought it would be more intuitive for a multi-author environment. I also assumed that Udaan would continue to live, and that one day someone else might be managing these files, so I created a README file that explains the folder structure, and how the files inside these folders link to each other (for example, what is file X in folder Y doing here).

Which brings me to premissions. Only the editors (Nibu Thomas and I) have write permission to the GitHub project. Because I own the project, I can add others to it, and adding such people will automatically give them write permission. Everyone else has read permission, which is the default GitHub permission for the whole world. If Udaan is managed by someone else in future, I can "transfer" the project (and, thus, ownership) to that person. The files still remain where they are, the Udaan articles still continue to be read by the world.

People with read permission cannot directly modify the files but they can still file bugs. So, we asked all authors to review their own articles and also do peer-review, and open bug reports for all their suggested changes. By doing this, we broke free of email-jail. Everything pertaining to Udaan was captured right there, in the Udaan repo bugtracker, open for the whole world to see.

I used GitHub's internal publishing method, so it's really a one-click thing. The moment you push a change into the publish-branch of the repo, that very moment the public URL is refreshed with the changed content. So, what's a publish branch? Well, in a GitHub repo, you can have several branches (which correspond to "streams" or "forks" in other repo parlance) but only the stuff that you put in a branch called "gh-pages" is the stuff that GitHub will publish to that external URL it gave you. It's somewhat like the DITA authoring scene: you can have a thousand files in a hundred folders but only those files that you put in a .ditamap file are the ones that get published.

Which brings me to the published web pages. For starters, I wanted the Udaan web page to "look" different from other open browser tags, so I used a favicon.

You see tiny Michi on the Udaan tab? That's what we call a favicon. I couldn't get the favicon to show up in Chrome or IE. I scoured the net for a solution and tried every suggestion but nothing worked. If you know of a way, let me know. Meanwhile, here are the steps to get a favicon on a Firefox tab:

1. Choose an image file that's no larger than 16 x 16 pixels.
2. Convert it to an .ico file. There are several google-able online free services that'll do this in a trice.
3. Save the favicon in the root folder. Ideally, name the file favicon.ico.
4. In all of the files, in the <head> section, add a link to the favicon file, like this:
   

After the browser tab, the actual content. I thought we should apply all the good-technical-writing stuff we know, so here's what Udaan has:

• The first paragraph, just after the title and author name, is either a summary of the entire article or a teaser to entice someone to read further. This is not only good SEO but akin to the <shortdesc> tag of DITA that everyone keeps telling me is good writing.
  
• This first paragraph is tweetable on click. The code is:
  
  Notice the "href" attribute. The first part, https://twitter.com/intent/tweet?, is what makes a Twitter box pop up. The next part, text = ...whatever..., is what auto-populates the Twitter box. Notice also that all non-text, non-comma, and non-period characters are represented by their ASCII symbols. Thus, a space is represented by %20. Want to try out such clickable sentences in your semi-formal documentation such as customer-facing blogs?
• No page is an "orphan". Every Udaan article links to some other related article.
• Every page is page one, so each article is complete in itself, with full header, footer, author details, content, acknowledgement, references, related links, and a ToC.
• Progressive disclosure techniques were applied. You don't need to leave the page to read stuff like author profile (shown on mouseover) or to listen to audiocasts and watch video versions (shown within popup boxes). Footnote text is revealed on mouseover, so you don't have to jump back and forth on the page. Every link has a tooltip that shows the first sentence (the summary or teaser sentence) of that article, so you can decide before you click whether to go to that article. (To see all of these together on one page, see Asha Mokashi's leadership article.)
• Every page has a unique <title> tag (which won't be rendered on the browser page but is anyway picked up by search engines).
• Every URL has descriptive link text.
• For universal accessibility, we included voice versions. You are no longer tied down to a read-the-text scenario.
• Voice interviews have the transcripts included, so you can read them if you don't want to listen in.

A word about the multimedia. The audio files are playable on click, achieved by using the embedded player feature of HTML5. The code is:

Notice the "control" attribute of the <audio> tag. That's what specifies whether the player controls like Play and Pause should be displayed. Notice also text within the the <audio> tag. That's what's displayed if a browser cannot handle multimedia. I used words that describe what's gone wrong and what could be a possible solution.

Udaan was to live online and its pages had several links. To eliminate broken links, I used Xenu link sleuth. I tried making a custom 404 page but discovered that's possible only with paid GitHub. Since the entire purpose of using Xenu was to eliminate a 404 scenario, this didn't bother me much.

So much for the web version. Let me move on to the .epub and .azw versions, to be used on iPads and Kindles.

I used Sigil to create an EPUB file. I imported the HTML files into Sigil, and generated the EPUB output. I then imported this EPUB into Calibre and generated an AZW file.

This part took longer than I expected. An EPUB file is just an archive file (just like a .zip file is) that contains XHTML for the basic content, and some other folders and files that tell computers that this is an EPUB file. The folder structure is fixed, and Sigil generates them for you.

All you need to do is put your content in the appropriate folders: audio, images, styles, and text. If I was embedding a video clip, there would've been another folder named "Video".

The difficult part was the styling. I discovered that the CSS that looks great on a laptop looks awful in an e-reader. The task of manually stripping the HTML tags of all styling took about 2 hours. (This is where I miss DITA). I created a CSS file just for the EPUB, and specified some very basic styling such as line spacing and a background colour for headings. The rest of the output is the default HTML style. The end result might look plain on a computer screen but looks clean and neat on iPads and Kindles.

For the audio, I used Audacity. Thanks are due to these people: Prachi Karnik, Deval Faldu, Santosh Krishnamurthy, Mihir Mishra, Mayuri Baruah, and Jolein Vadhariya; they gave their time to record someone else's articles. Another instance of giving back to the community. After the sound bytes were recorded, I discovered they'd been done in various file formats, so I first used Audacity to convert them to .mp3. Then I googled for how to filter out background noise, how to trim the too long silences, and how to amplify the quiet bits. The sound files still lack that "professional" feel but I think they serve our purpose fine.

And Udaan was ready to be released.

What didn't work well:

• The favicon. Like I said, I just couldn't get it to work on Chrome and IE. Also, I had to manually insert the favicon link in every HTML file; inserting it only in the boilerplate header file did not work.
• The author profiles. I did a copy-paste from the home page to the individual articles. The content-referencing just did not work with the CSS I was using to show the profiles on mouseover. Maybe I need to create separate files for every author (in other words, maybe HTML content referencing works only for a *file* and not for an *anchor* within a file).
• The multimedia in the EPUB file plays only with the iBooks app. I couldn't figure out a way to make it play with the default iPad reading app.
• For the print version, there wasn't an easy way to port content from HTML to MS Publisher. Porting was done manually by Sangeeta Raghu Punnadi. Then, Nibu Thomas did the layout and inserted the sponsor ads and the fillers. It was not easy; "nightmare" was a word that was used several times. It also meant that content lived in two places: GitHub and Publisher. We couldn't figure out a way to create a "book" of discrete HTML files and turn that into a format that our print vendor could use.
• I could not directly make an EPUB or AZW file from GitHub, which allows only HTML publishing, not other types of publishing.

What would've been nice to have but no time, no money, etc:

• A copybook-like underline style looks charming on iPads.
  
• The print version could also have had some interactivity. For example, think of Anagha's article on commonly-confused words. Now, think of a book page where you first read the tip, then lift a flap to see a cartoon underneath on the very same page.
  
• The print version could've had perforated pages for the blank pages (where you could've taken notes during the conference) and for the checklists in Rajib's leadership article (which you could've tacked to your workdesk for ready reference).

What software was used:

• Programmer's Notepad 2 for creating and editing the HTML, CSS, and JS files.
• GitHub client for Windows desktop to push the folder structure and non-text content into the GitHub repo. For text content, GitHub's web interface can be used (client not needed).
• Audacity, for editing the soundtracks and converting them to MP3.
• Sigil, for creating an EPUB file.
• Calibre, for converting an EPUB file to an AZW file.
• Sound Recorder, Voice Recorder, or whatever it is that your computer or phone uses to record voice.
• MS Paint, for making flowchart diagrams and for resizing pictures.
• Xenu link sleuth, for checking for broken links
• For everything else, online resources:
  • The comic strips were created at https://www.bitstrips.com/create/comic/ and http://www.makebeliefscomix.com/
  • The transparent background for the favicon was created at http://www.online-image-editor.com/help/transparency
  • The PNG file of Michi was converted to ICO at http://convertico.com/

Which free CSS and JS files were used:

• The look and feel is because of w3.css and the related theme files of http://www.w3schools.com/w3css/default.asp.
• The flip-card effect is courtesy https://www.developphp.com/video/CSS/Flip-3D-Boxes-and-Cards-Animation-CSS-Tutorial.
• The javascript for footnotes-on-hover is from http://ignorethecode.net/blog/2010/04/20/footnotes/.
• The scroll-to-top button is from http://www.scrolltotop.com/.
• The icons are from Google's material design icon library at https://www.google.com/design/icons/.
• The speech bubble styling is based on the CSS file from http://nicolasgallagher.com/pure-css-speech-bubbles/demo/.
• The styling on mouseover is based on the CSS file from http://www.menucool.com/tooltip/css-tooltip.
• The commenting facility is courtesy http://web.livefyre.com/comments/.

So, yeah, that's the Udaan back-end story. The entire source code of Udaan is on this GitHub repo: https://github.com/UdaanSTC/GutsAndGlory/tree/gh-pages.

And Udaan itself is here: Udaan.

Here's what Udaan Print looks like: 100 pages, A5, hardbound, all colour. Distributed to the 350-odd people who came to the conference.

To see a 3-minute video on the Udaan story, see this:

---

* iBooks EPUB picture is from https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/cics_transaction_server_now_has_epub?lang=en
** flap-in-book picture is from http://www.booktryst.com/2011/04/anatomy-gets-animated-in-rare-flap.html 

Techwriting lessons from films

This post contains what I presented at the STC India annual conference of 2011 at Chennai.

---

We'll go straight to the first of the film clips. [The videos might take a while to appear on the page. Depends upon the internet speed.]

When chess pieces go missing

The lesson I learnt from this movie sequence?  That I need to be more concerned about my core skill (writing) than the tools I am using to practice that skill.  That, as a writer, my other core skills must be agility, resourcefulness, and adaptibility so that I can work with whatever is available to deliver that which is deadlined.

On to the next lesson.

You have to ask me nicely 

As a writer, I am on cross-functional team meetings, I test software, I file defects, I coax people to share their knowledge…I need to  know the people I am talking to. And, I need to ask them nicely. Because, I work with talking-feeling humans for:

• Getting information from the development teams
• Getting the technical and editorial reviews done
• Getting feedback from customer-facing teams
• Getting support from the doc team

Next clip.

Are my eyes really brown? 

My takeaway from that question was Accuracy - My writing must be free from mistakes, must adhere to facts.  I must:

• Write only that information which you have understood and verified
• Maintain consistency of all information about a subject

On to my next lesson.

I'll speak real slow

This one is about Clarity, about freedom from ambiguity or obfuscation, about presenting the information in such a manner that it can be understood the first time

Here, let me show you a film sequence that demonstrates what is not Clarity.

I'll speak real slow 

Now, I'll show you a scene from a Sunny Deol movie.

Dropping down dead

Some docs are so heavy, trying to read them is like being hit by a ton of bricks.  Docs that knock me down dead.  The lesson I learnt from Sunny's killer punch is about Retrievability and Organisation.  About how my documents must:

• Provide helpful entry points
• Facilitate navigation and search
• Give an index
• Provide you-are-here indicators
• Suggest links to similar or related information

Next on to my all-time favourite Kamal Hassan movie.  No, I don't understand Tamil, the language that this movie is in but hey! this clip doesn't need me to know Tamil.

What language was that

This one's about Style, about the correctness of writing conventions, and of words and phrases.  What I learnt from this film sequence is that I must always:

• Use correct grammar, spelling, and punctuation
• Follow template designs
• Use boilerplate text
• Follow style guidelines

Here's the next clip.

When you have to shoot, shoot

My lesson? Task orientation. I must focus on helping getting a job done.  I must classify my information by its type so that I can:

• Create docs in a consistent manner, so that the right design gets used (for example, tables for reference information, step sequences for tasks)
• Focus on tasks, and move the supporting concepts and reference information into other topics, where they can be read if required and ignored if not

When my information is focussed on the task at hand, stripped of all supporting information, here's how I can help people get their jobs done.

When you have to shoot, shoot 

And now to the last of the film clips.

Broken bones 

This one's about Visual effectiveness, about how I should:

• Ensure that all users can access the information
• Use graphics to complement the text

---

Acknowledgements

• Films: Shatranj Ke Khiladi, A Few Good Men, Casablanca, Deja Vu, Fandango, Damini, Salangai Oli, The Good The Bad The Ugly, Beverly Hills Cop, and Rear Window
• Books: The IBM Press book called Developing Quality Technical Education

Recasting the recipe

Just because I do something well does not necessarily mean I like doing it. Cooking, for example. Hence, I steer clear of all recipe booklets, cooking websites, and similar. But a weekend conversation on FaceBook about things planned for the Holi break needed me to sit down and write a recipe for my friend, fellow techwriter Samartha Vashishth. One look at my mail and he wrote back saying "put in blog post" etc. Hence.

I know the first list in that recipe should've been an unordered one. :-)

Let's take our edit hats off while we look at the recipe, shall we? 

How is it different from standard recipes? Here's how:

• It assumes you are doing only this task and nothing else. There's no "Do X and keep aside" instructions (despite possibilities); there's only a linear task flow.
  Lesson for techcomm: Do not introduce branches into a procedure.
• It does not just list the ingredients but group them according to when they're going to be used in the process and what they're going to be used together with.
  Lesson for techcomm: Grouping of logically related items aids in (i) comprehension (ii) task completion.
• It does not have pictures :)
  Lesson for techcomm: Use pictures only if they are essential to performing the task.

How I could've made it better? Listed the utensils, perhaps. No recipe that I've come across ever lists them (except, maybe, cakes, and that too a grudging 5" baking tray mention) even though they are very important to the task at hand. Notice how, in step 9, I suddenly introduce a utensil (bharta toaster) that is otherwise not logically related to the cooking of haleem? Bad!

Tweet, don't twitter

"Talk rapidly and at length in a trivial way * " is what prompted this blog post. I've been on Twitter for close to two years now and thought it was time I compiled a "Thou shalt not" list for tweeting. So, here goes:

1. Do not use "Pls RT". Not only does that use up six characters, it also presumes I am not smart enough to know if something is good enough to be shouted of from rooftops.  That, and the fact I hate being told what to do.
2. Do not use up all 140 characters unless unavoidable. Leave enough room for your twitter handle (if someone wants to RT) and some comments (from people who're sharing your tweet).  The first is self-promotion, the second is courtesy.
3. Do not tweet ONLY to share your blog post URLs. Thanks, but we have feed readers for that.
4. Do not keep retweeting like there's no tomorrow. If we are linked through Twitter, there's a 1 in 2 probablity that our Followed list is very similar. Retweets by you clog up my timeline.  If you find yourself retweeting stuff too often, consider putting those tweets into paper.li and sending out ONE single paper.li-automated tweet daily. Besides, if all that you do is retweet, I am going to Unfollow you within a week (unless what I was looking for was a human feed-aggregator. For free).
5. Do not just retweet - tell me why you thought it was retweetable (see #2).
6. Do not be a radio commentator on the sports field. If I am as enthusiastic about that game as you, I am watching it (and not reading your tweets). If I hate sports, you're clogging up my timeline and, No, I can't filter you out because you never use hashtags and words consistently. This holds true not only of sports but of TV programs as well.
7. Do not tweet something that wouldn't make sense to 50% of your followers. What, you do not know about your followers? Bleh! You talking to chairs and tables, then - where's the point?
8. Do not tweet long updates one after the other, 16 tweets to a minute for 3 full minutes. If you have lots to say, use Twitlonger (or whatever) or write a blog post.

As with life, so with Twitter - do not blabber and do know who you are talking to.

--------
* One of the definitions of 'twitter (verb)' given by the Oxford dictionary

Disclaimer: Sorry for the rant post but I just had to. Rant, i.e.

Listen! Do you want to know a secret?

Let's start at the very beginning
A very good place to start
When you read, you begin with A-B-C

• A is for Adobe.  The company that left Anindita with the distinct impression that it thinks that that the techcomm world revolves around it. Also see F and R.
• B is for Beta.  It stands neither for the second letter in the Greek alphabet nor the second brightest star in a constellation. It stands for not-yet-ready releases and is an excellent medium for techcommers to get feedback on their work.
• C is for content. That which makes the techcomm world go round.
• D is for DITA.  That thing which cures all ills.  Sane voices suggest otherwise but people still see through the glass darkly.
• E is for English.  A language much maligned by a tiny, pint-sized apostrophe, which, if misaligned, can even become a comma. E is for editors. That group of people who are haplessly left with correcting the thats and whichs when what they’d dearly like to do is spend time on indexes, navigation, and coherence and cohesion.
• F is for FrameMaker (See A). F is for feedback. A message where the message is often confused with the messenger, often unjustly.
• G is for Google.  It is a help authoring tool that saves a lot of SME time (see S).
• H is for Help. A verb and a noun (See the possibility related V). Help is a privilege. You may want it but not get it.
• I is for information. Information is a noun that cannot stand on its own; it must always be used as an adjective. Information design, information architecture, information developer, and information overload, for instance.
• J is for coffee and pictures. As in, Java and JPEG.
• K is for knowledge.  Of, besides writing, the tools, domains, and processes.
• L is for listening.  It stands for the characteristic of being alert and ready to hear anything that might lead to knowledge (see K).
• M is for multimedia, an umbrella term for anything that moves, creates noise, and can be packaged.
• N is for No. As in, “No, I will not document how it should work; only, how it does indeed work”, “No, I will not put this screenshot here because …”, “No, this will not go into an install guide because….”
• O is for obfuscation.  So long as obfuscation exists, so will a technical communicator.  If you do not know what obfuscation is, here is an example: “The relationship, which I might tentatively venture to aver has not been without a degree of reciprocal utility and even perhaps occasional gratification, is approaching the point of irreversible bifurcation and, to put it briefly, is in the propinquity of its ultimate regrettable termination.”
• P is for PDF.  It was born in 1993. Other births that year include Microsoft Windows NT and the republics of Slovakia and Czech.
• Q is for  curiosity. Why should I…? How does this…? When will it…? If I do this, what will….? What’s the difference between…? What is the weight of the moon?
• R is for RoboHelp (See A). R is for respect. An emotion that causes much existential angst among techcommers.
• S is for scrum. It means giving daily updates to your team and then running back to do the work you yourself promised to. S is for SME.  It means the fount of knowledge from which information must be gleaned. S is for substance (See C). S is for style. It is something best only followed, not tampered with.
• T is for Twitter.  A medium used almost exclusively to pimp blog posts, product launches, and rave reviews. T is for TWIN. Bonded for life.
• U is a letter so important that it must never be used in isolation. U is royalty and must always be teamed with other letters, like this: UX, UA. U is the reason techcommers exist; U is for users.
• V is for vision. That which makes techcommers put descriptions in alt text, pick the reds and greens with care, and prefer lists to tables. The ability to see beyond the obvious, to ‘write’ for everyone.
• W is for wiki.  Everybody knows it’s there but nobody knows what to do with it, hoping that somebody comes up with a wiki-to-source roundtripping that helps anybody adopt a wiki.
• X is a placeholder. As in XML.
• Y.  A letter for which I could not come up with a word. I did try to match it to words such as Yes, Year, Yearn, and Yesterday but felt something was missing.  So, I am leaving Y alone. For You, the reader.
• Z is for zen.  And the art of writing for motorcycle mechanics.

When you know the notes to sing
You can sing most anything

====================================================

This first appeared in the Nov-Dec2010 issue of INDUS, STC-India's newsletter.

Acknowledgements

• Rachna Singh Ganguli for G = Google, F = feedback, Help is a privilege, J=Java and JPEG, R = respect; T=TWIN.
• Anagha Bhat-Chandratrey for K = knowledge, L = learning.
• The Beatles, for “Listen! Do you want to know a secret”.
• The people of The Sound of Music (1965) for “Let’s start…with A-B-C” and “When you know…most anything”.
• The people of Yes, Minister (BBC) for “The relationship…termination”.

Woo hoo! Smart search is possible

Watson had not been on my mind when I wrote my last blog post. In fact, if you were to shake me awake in the middle of the night and say, "Watson!", my immediate response would have been "Elementary, Holmes!" Despite being vaguely aware of a project called Watson underway in my company, the name didn't really mean "Wow" to me till, well, last night.  But before I tell you why, let me go back a bit - and talk about my last blog post. In that post, I had implied 'storage' and 'retrieval' are two different things and, while tagging and indexing might work when one is storing something, the same tag or index could fail while retrieving the data. In my post, I had put foward a question - should content be context insensitive for it to be reused effectively? Conventional wisdom - that which runs search engines and SEO jobs - says, "No".

And then came along Watson, and beat two people in Jeopardy to win an indecent amount of money, which, it was declared, would be given to charity.  A computer beat two awesome humans.

Somewhere halfway through this video, when analysing why Watson got 'Chicago' wrong, you'll see the IBM engineer say something like "the info was stored in sectors but this was not about discrete compartments" or something to that effect.

Exactly! Human brain does not process information in linear paths. It hops, skips, jumps, runs around in circles. And, because we're getting there - with Watson's help - I think in my lifetime at least I'll see content being reused in ways that I (the writer) never imagined it could be because the user (with help from Watson) is retrieving just that much - and only that much - information that the user needs. Correctly, every time, the first time.  Smart user!

Lose that tag please

It all started last night when I tweeted some Hindi film dialogues (In India, we have two major religions - films and cricket).

(to zoom, click the image)

And then, we got around to discussing the bestest comedy film that's ever come out of Bombay. And, this was the tweet that got me to writing this blog post.

(to zoom, click the image)

How is this relevant to techwriting?

Well, if I were an indexer, I'd have probably tagged all my film content with some of these words: bombay, bollywood, hindifilm, <nameOFfilm>, <nameOFstar>, and so on? Very search friendly and all. But say, my reader was a sociologist researching corruption in India (ahem!).  This dialogue ("Thoda khao, thoda phenko" #epic) would never even show up in the search results, yet it contains exactly what the sociologist is looking for - the entire social mileu from which the phenomenon has sprung (including the defence mechanisms people employ to forget the misery it produces).

So, how did I link this dialogue to scams (that are occupying the entire front page - and more - of newspapers these past weeks)? Because in my mind, my content database is neither indexed nor tagged. I can pull out random references and tag it to anything random and yet make it look relevant.

Me: To copy, perchance to paste; Aye, there's the rub for in that paste what copies might come when we have shuffled the platforms and the versions out of the filters.
Colleague: Coils. Not filters. Coils.
Me: Coils.
<silence for one minute>

Colleague: A coil is a wrapper, right?
Me: Right.
Colleague: So, if we put a wrapper to call the boolean....

So, here I am, thinking if there is more to indexing that meets the eye. More to content reuse? More to "context"? Thoughts?

Where is the User in the Design

Creation and delivery of help content was what was on my mind as I sat crocheting a tiny coin purse for my mother.  She has a very cute, 3-inch, pot-bellied leather purse that she uses to keep her loose change in but it's coming apart at the seams, hence I sat there, crocheting this:

To zoom in, click on the picture

And, have we not often come across something like this:

To zoom in, click on the picture 

[Note: Thanks for catching the misplaced apostrophe. Feeling too lazy to edit the pic.]

I am picturing a scenario with me and my mom:

 To zoom in, click on the picture

Creating and delivering help content is very similar to creating any other product.  So, I ask myself, Where, How, and When is my reader going to need this information.  If I can answer these three questions, the content I create will truly be User Assistance.

Where is the user in the guide

Yesterday, I got myself a new phone. Last time I had bought one, it was April 2004 - a time when cellphones here did not have built-in FM radios, internet support, multimedia messaging, and all such exciting features that are so much passé today. Consequently, it was a very celliterate me that held the phone gingerly and regarded its QWERTY keyboard with interest. And thence started my frustration. I could not figure out how to do any of those exciting features that all phones have nowadays (let's not blame the UI now.  All UIs seem non-intuitive to first-time users).
So, I reached for the user guide. A glance at the ToC, and I could not find answers to any of my three questions.

To magnify the picture, click on the picture

"So what", I told myself. "Just a 37 page booklet. I'll flip through it and will surely find something."

Five minutes later, I threw the booklet away, powered my laptop on, asked Google, and found answers to all my questions:

• How do I transfer a photo taken on the phone to my laptop?
• Where do I get the Missed Calls list?
• How do I disable the keypad beeps?

I see several things wrong with this user guide but the one thing that stands out prominently is - this guide is describing the features of the phone; it's not describing the tasks I, the user, do.

Of currency notes and information

Today, I want to talk about currency notes. Indian currency notes, to be precise. Someone asked me, "How many languages are spoken in India?" Sighing with relief that the question was not the more usual "You all don't speak Indian?", I leaned over, pulled the wallet out from my pocket, extracted a 100-rupee note, flipped it over, counted something, and declared, "Fifteen officially. Not counting Hindi and English."

Users find information in the most unlikely of places. Had I been a "normal" user, the kinds that a techwriter would have had in mind while documenting something, I'd have gone to the Constitution of India website and referred to Schedule 8 - the place that lists all official languages (22, actually, till date, not including English). If I didn't know that's where the official languages are listed, I'd have run a Google search (which, in turn, leads me to the Eighth Schedule anyway). But I am not a normal user - just like most users are not normal users. Most users get their information from places that the writer might never have dreamt of.

The currency note designer, on the other hand, is very well aware of the implications of the panel that I referred to.

It is intentional - it's been put there to remind people what a greatly diverse country we are. I should know. I used to be part of our currency presses once upon a time. We used to call it the language panel. It's almost - but not quite- an easter egg *.

Which led me to wonder - do technical writers put easter eggs in their documents? I've not seen any but would love to know.
============================
* More on easter eggs: Wikipedia link

Am writing a book

I am writing a book on DITA.

Yes, there are, already, books on DITA. Why, then, am I writing one? Because:

• I think this book closes the gap between "what is DITA" and "how can I write in DITA".
• I had wished for a book like this when I had started off with DITA.

XML Press is bringing the book out next year. Here's more on the book: Authoring with DITA.

The Myth of the Holy Cow

In my life as a technical writer, I have been handed out quite a few myths [A myth, says the Oxford dictionary, is a traditional story], myths that come disguised as commandments that resound with a Thou Shalt Not. The intention, I suspect, is to lull me to passive obedience. In this blog post, I will mention some of these myths and what I think (and do) about them.

Passive voice has no place in technical writing

Before I state my position on this myth, let us recollect the definition of voice: the form of the verb that shows the relation of the subject to the action. So, the voice of a sentence shows whether the subject actively took ownership of an action and did it, or was so passive as to only be the recipient of the effects of the action.

Picture source: http://www.chumpysclipart.com/illustration/1199/picture_of_a_soccer_referee_being_hit_on_the_back_of_the_head_with_a_soccer_ball

Now let us look at the structure of a very simple sentence expressed both in active and passive voice.

Active: The installer copied the WAR files to the installation directory.
Passive: The WAR files were copied to the installation directory.

This example is a simple example and I wouldn't really prefer one voice over the other. But, consider the following example:

License key definitions are stored in a license key file, which, by default, is named lkad.dat and located in the product installation directory. If you need to modify the list of authorised servers or users, edit the license key file with any text editor.

Is there any reason why the first sentence needs to be turned into the active voice? Is there any reason why I want to know who is doing the storing action? All I want to know, if I am a license administrator, is where the file is stored (by whoever – I don’t care), what it is named, and how I can edit the license definitions it contains. Passive voice works here, and marvellously.

Upshot: When I think the doing of an action is important, I write in active voice. When I think it doesn’t matter who or what did or caused the action so long as the action got done, I don’t spend any time changing a passive voice construction to active.

Writing must be gender neutral

With all respect to all kinds of genders on this earth, I think that’s a piece of unholy baloney. In English, there is no grammatical gender. But, even though we write in English, there's every likelihood that the text will be translated to at least one language other than English. Many of these non-English languages have grammatical genders. The nouns have genders, the verbs are conjugated based on the gender of the nouns, and so on. So, something that is gender neutral in English can very well turn into a gendered phrase in a language like, say, French or Hindi.

My take is that spending anything more than 5 minutes on rephrasing an otherwise understandable and acceptable-by-usage English sentence into a gender-neutral sentence is nothing but a waste of time.

Every list should be preceded by an introductory sentence

The logic is, if I suddenly start a numbered list that has steps to perform a specific task, but do not introduce the list with a stem sentence, readers might be misled, confused, misinformed, etc.

Now, let’s see the following example:

1. Use one of the following methods to start the Manage Information Catalog wizard:

    * From the Windows desktop, click Start > IBM DB2 > Set-up Tools > Manage Information Catalog wizard.
    * At a command prompt, enter db2iccwz.

The Manage Information Catalog wizard opens.

2. Select the Migrate metadata from an existing information catalog option.

3. Enter the required information on each page of the wizard and click Finish.

To me, it is apparent this is a procedure for migrating your data from an existing catalog to a new one.  To my users, who are undoubtedly smarter than me because they are database administrators [audience, audience], it is very apparent that this is a procedure for migrating data from an old catalog to new; my users just do not need a stem sentence that goes:

To migrate metadata from an existing information catalog:

The title of the topic would, in any case, always have an indication of what is contained in the topic. The stem sentence adds nothing of value to the content except increasing the word count.

However, I have also come across procedures where, if a stem sentence were to be absent, important information would be missing. Here is an example:

The following steps are needed only if you overrode the default options when you installed the product.

The end result – I leave out stem sentences if I think there’s no value add in having them.

Leave the comparatives and the adverbs alone

I am in complete agreement. Whether an application is quickly installed, easier to use, and fastest in terms of response time is a conclusion best left to the user to arrive at. Technical writers are supposed to report facts, not hand out value judgements.

Computers (and computer applications) do not possess human characteristics, so, do not anthropomorphise them

I agree.
Did I hear someone say, " A piece of software does guide, control, direct my actions. Microsoft Excel lets me create spreadsheets but it does not let me create documents. An umbrella shields me from rain; a car gets me from point A to point B. It’s perfectly okay to anthropomorphise."

Picture source: http://www.wpclipart.com/cartoon/animals/fish/fish_with_umbrella_cartoon.png.html

I disagree with this line of reasoning. When someone says, "The umbrella shields me from rain", that is not anthropomorphism. That’s just someone using a verb correctly because that is indeed what an umbrella does – it shields people from rain. That is an action, not a human characteristic. Now, if someone were to say, "My brave umbrella valiantly tries to shield me from rain but fails", now that, my friend, is anthropomorphism because the umbrella has become possessed of the human characteristic of braveness (and chivalry, perchance).

Me? I let my software detect conflicts and resolve them but I do not expect it to be remorseful when it crashes my desktop.

A procedure should not have more than 7 steps
If anything takes more than 7 steps, says the stricture, break the procedure up into smaller logical pieces. I am guessing this comes from the assumption that readers have short attention spans. I said "guessing" because though I’ve been told there are studies that prove a decrease in comprehension levels after Step 7, I am inclined to believe if someone’s life depended on it, that person would read even War and Peace from cover to cover.

That said, I do try to keep my procedures as short as possible. But, sometimes, the products we write for do have procedures that cannot be fitted into the 7-step-frame. For example, can the instructions to install a rack-mounted server system really be covered in 7 steps?  Really?

Conclusion
So, is the cow holy? Well, it depends.

[A slightly different version of this blog post was published in STC India's magazine INDUS.]

DITA tools - 4 (Authoring)

I've had quite a few of my friends say, "Well, yes, we can do the information typing and we also totally get the semantic tagging concept of DITA but when we get down to actually writing in DITA, it is a bit of a hassle trying to remember all the tag names and where they are allowed. Is there a free WYSISYG editor for all this?"

In a previous blog post I had mentioned one such DITA authoring tool. In this blog post, I will talk about another.

The Serna XML Editor has a free edition that I've been using the past couple of weeks to do some personal stuff in DITA. For DITA authoring, I really like it and for the following reasons:

• It comes bundled with the DITA open toolkit. I don't have to download and install the OT separately.
• It also has DocBook (which is next on my personal ToDo list).
• Its validators will not let you insert a DITA tag at a place where the tag is not allowed. You will be shown a list of allowable tags, with hovertext for each tag.
  
  
  

  

  To see a larger image, click on the image

• It lets you define the attributes of any element through an element-specific wizard page.
  
  
  

  

  To see a larger image, click on the image

• It lets you drag and drop elements. This is something we (writers) take for granted in our word-processing software but not many free XML editors have this feature.
• It is WYSIWYG - not only in terms of DITA tags but also for output previews. To my knowledge, no other free XML editor gives a preview of the output.
  
  
  

  

  To see a larger image, click on the image

• It comes bundled with a transform engine (that's how it has the inbuilt output preview feature). This means you don't need a separate software for running the transforms. You do, however, need the JRE (if you want to publish to XHTML) and FOP (if you want to publish to PDF) - both of which are free to download and easy to install

The Syntext Serna Free XML Editor can be downloaded from http://www.syntext.com/products/serna-free/.

Some of the 'cons' that I've noticed thus far (I am not sure if these are a restriction for the free edition):

• The glossary specialisation, though supported, does not result in transformed XHTML files.
• Bookmaps, though supported, don't get transformed.

Writing in DITA - Tips #4 to 10

A verbose version of these tips was published in the Mar-Apr 2010 issue of STC India's newsletter, INDUS, as DITA writing tips.

4. To conref dissimilar elements, wrap the source text in <ph>
5. To prevent all topics of a <reltable> row from linking back to each other, use the 'linking' attribute of <topicref;
6. To include pretty much anything in a <step>, insert an <info>
7. To preserve the formatting of a copy-pasted text snippet, use <pre>
8. To have topics show different titles in different scenarios, use <titlealts>
9. To caption images, use <fig> as container for <image>
10. To have a slightly longer <shortdesc>, put it in an <abstract>

To conref dissimilar elements, wrap the source text in <ph>

DITA is about content reuse - with a rider. Only like can call like. I cannot, for example, reuse a <step> as an <li> - if I want to reuse the text of a <step>, I can conref it only from another <step>. This becomes a bit of a hassle - say, I have written something in a <shortdesc> in a concept topic that makes perfect sense as the <context> of a task topic, how do I conref it? By using the <ph> tag.

To prevent all topics of a relationship table row from linking back to each other, use the 'linking' attribute of the <topicref> element

The relationship tables in DITA are an extremely useful tool for maintaining, at a single point, the linking between all topics in a book. Each row in the table represents a discrete relationship and all files in a row link back to each other. But sometimes I end up with more links than I really want. To prevent that, I qualify the <topicref> tags with either a sourceonly attribute or a targetonly attribute. When a <topicref> has a sourceonly attribute, a link is generated to the target topic only in the source topic; when it's targetonly, a link is generated to the source topic only in the target topic.

To include pretty much anything in a <step> tag, use an <info> tag

When describing procedures, sometimes it becomes necessary to include things such as pictures, code snippets, explanatory notes, and so on. But a <step> tag can contain only a <cmd> tag and then a bunch of other tags that are pretty useless for pictures, notes, and code. The workaround is to insert an <info> tag after the closing <cmd>; an <info> tag can contain pretty much anything.

To preserve the formatting of a copy-pasted text snippet, use <pre>

Because DITA is XML, anything enclosed within < > is interpreted as a tag. So how do I include, for example, a code snippet that contais angular brackets? I wrap the text in a <pre> tag, just like I'd have done if I were writing it in HTML.

To have the topic show different titles in different scenarios, use <titlealts>

I use <titlealts>, with which I can specify two additional titles: a <navtitle>, which shows up in the ToC pane, and a <searchtitle>, which shows up in the search results page. I make these two titles slightly more verbose than the actual page title, so that they make sense even when seen outside the context of the page content. In the absence of a <titlealts> tag, the title displayed in the ToC and in the search result page defaults to what's contained in the <title> tag.

To caption images, use <fig> as container for <image>

The easiest way to put an image in a topic is by using an <image> tag. But, according to the DITA language specification, an <image> tag cannot contain anything other than alt text. How do I caption my images? By wrapping the <image> tag in a <fig> tag, which can contain not only a <title> tag but a host of other useful ones such as <desc>, <note>, and <codeblock>.

To have a slightly longer <shortdesc>, put it in an <abstract>

The <shortdesc> element is what I use for writing the "click-through text" for the topic - the text that shows up in search results and in hovertext for links. Mostly, my short descriptions contain 2-3 sentences that sum up the topic. But sometimes, just sometimes, I feel the need to write a longer short description. I'd still like to retain the shorter short description as the "pull text", but what if I want to add another two sentences and want to have them all in that section itself - the first section on a page - instead of carrying the extra sentences over to the body of the topic (where they'll probably have to reside after a <prereq> and, thus, lose all sense of connect)? In such a case, I use an <abstract> tag

DITA 1.2 - New <task> elements

The DITA language specification v1.2 introduces two new task elements: <steps-informal> and <stepsection>.
The <steps-informal> element is for describing procedural information that is otherwise not normally described as a step. The <stepsection> is for giving explanatory information before a step. It is contained within the <steps> element and can be placed betweeen two <step> elements; the output of the content of a <stepsection> will not contain a bullet or a number.

When should I use the <steps-informal> and <stepsection> elements

<steps-informal>: The v1.2 language specifications haven't yet included an example of the <steps-informal> element so I am still a bit unclear about how and when to use it.
<stepsection>: If I am using DITA v1.1 and need to give some info before a step, the only way I could do that was insert an <info> in the previous step. With <stepsection>, this problem is resolved. Here's an example (taken from the v1.2 lang specs doc):

<steps>
  <step><cmd>Get out a bowl</cmd></step>
  <stepsection>The next two steps are very important!</stepsection>
  <step><cmd>Put on safety gloves</cmd></step>
  <step><cmd>Put on goggles</cmd></step>
  <step><cmd>Pour milk and cereal into the bowl</cmd></step>
</steps>

Related information

With v1.2, a <step> can have an <note> before the <cmd>.

  

DITA 1.2 - New <topic> elements

The DITA language specification v1.2 introduces two new topic elements: <bodydiv> and <sectiondiv>.
The <bodydiv> element is intended to be used as a grouping element for containing logical blocks of info that otherwise do not need either a title or a separate topic. It can be placed only within a <body> or within another <bodydiv>.
The <sectiondiv> element is similar to the <bodydiv> element except that it has more container elements - it can be placed within a <section>, <sectiondiv>, and a bunch of other tags depending upon the topic type.

Why and when should I use <bodydiv> and <sectiondiv>

If I want to reuse a whole group of info somewhere else, these two tags are handy. Not that such reuse couldn't have been done otherwise, but then, these tags can, for example, contain several <p> elements, some lists, some images...it's almost like being able to reuse an information chunk instead of individual tags. Without being actual formal topics, these tags behave like topics.

Related information

The <concept> topic type also has a new element in v1.2 that's similar to <bodydiv> and <sectiondiv>. It's called <conbodydiv>.

History of <topic> elements

Here's a list of the various topic elements from v 1.0 to 1.2:

DITA 1.0	DITA 1.1	DITA 1.2
dita	-	-
topic	topic	topic
title	title	title
titlealts	titlealts	titlealts
navtitle	navtitle	navtitle
searchtitle	searchtitle	searchtitle
-	abstract	abstract
shortdesc	shortdesc	shortdesc
body	body	body
-	-	bodydiv
section	section	section
-	-	sectiondiv
example	example	example
related-links	related-links	related-links