Blogs and official documentation aka Why technical writers should blog

Today morning, via Twitter, I landed up on Neal’s blog post Using humor in your documentation. Or not. Go read it–some nice pros and cons of using humor in documents!

The post got my thinking about how I write as a technical writer and my desire to better the UX for my readers. I too document Enterprise software (Adobe Connect and Adobe LiveCycle) in my current job. Also, I have never used casual language or humor. However, the rewrite of a warning, in Neal’s blog post, is enticing 🙂

I think a great way out, is to separate the two styles in to two different containers–official documents and semi-official or even informal blogs.

Why should we blog

Why should we blog

The humorous, casual, informal, witty, off-beat, and community content should be re-directed to the blogs! If they are done well, the blogs compliment the docs nicely. I am listing some advantages of blogging that come readily to my mind:

  • One does not have to deal with the issue of localization of blogs. Blog content can be consumed by readers in their locales via Google Translate. Typically, organizations shy away from recommending that official documentation be read via Google Translate! This is not to suggest that humor gets translated–this post is just about blogs and documents. Irrespective of humor, via blogs we save localization costs.
  • Blogs are not driven entirely by timelines or ties with lengthy review cycles or are a mandate. Blogs can be ad-hoc, personal blog posts can be published without internal reviews, and there can be both, lean periods and peak seasons, for blogging.
  • Blogs also help in creating a good buzz about the software, in the community. This helps in indirect marketing. Blog posts can further feed into other social media channels like Twitter, Facebook, List.ly,  Pinterest, and so on, to drive social media engagement.
  • By re-purposing multiple blog posts, one can compile cheat sheet, tips and tricks, lengthier technical articles and workflows, and so on.
  • On blogs one can invite community members to write–guests posts are a great way to give recognition to power users, as well as, have a vibrant community around a software. Exploring how other people use the same software leads to better self-learning as well.
  • Many writers shy away and many a times editors do not permit documenting what do not work very well in the software. On blogs one can post actions that users should avoid, provide workarounds for broken workflows, share less-professionally done illustrations that cannot make it in the official docs, invite the community to share real-world workflows, etc. With timelines, styles guides, and localization costs driving documentation, it is difficult, if not impossible, to do all of these as part of documentation activities.
  • With blogs one doesn’t need a user story! Not just technical writers but any member of engineering team who blogs, gets to be in touch with the real community, interact with the real users, face the real bugs, and get to know the real workflows.

Share in the comments, what are your reasons for blogging?

——–

Updated Oct 23, 2013 to add last bullet point.

To allow for social collaboration and embedding of this content, I have re-purposed this blog post as a List at http://list.ly/list/DDo-why-should-technical-communicators-and-writers-blog.

Advertisements

Adobe Connect 9 documentation in all the supported languages besides English

Adobe Connect product page

I work on the Adobe Connect documentation and self-help material. To improve findability of the complete doc set, I created a documentation landing page.

Millions of people using Adobe Connect across the world need self-help material in their first language. See the two popular guides in 11 other locales. Bookmark this post, in your language of preference**, for quick access.

*MIC = Migrating, Installing, and Configuring.
**Translated post = This blog post auto-translated in the corresponding locale. Note that irrespective of the blog language, the links point to the locale-specific documents.

Language /
Locale in URL
Using guide MIC* guide
(v9.0 & v9.1)
MIC* guide
(v9.2)
Translated post**
English / en_US Online help | PDF PDF PDF English
French / fr_FR Online help | PDF PDF PDF French
German / de_DE Online help | PDF PDF PDF German
Japanese / ja_JP Online help | PDF PDF PDF Japanese
Italian / it_IT Online help | PDF PDF PDF Italian
Spanish / es_ES Online help | PDF PDF PDF Spanish
Dutch / nl_NL Online help | PDF PDF PDF Dutch
Portuguese / pt_BR Online help | PDF PDF PDF Portuguese
Chinese / zh_CN Online help | PDF PDF PDF Chinese
Korean / ko_KR Online help | PDF PDF PDF Korean
Russian / ru_RU Online help | PDF PDF PDF Russian
Turkish / tr_TR Online help | PDF PDF PDF Turkish

Leave a note in comments to let me know how you liked the compilation, what works for you, and what would you like to see more about this.

And for the issues that are not addressed in the guide, feel free to initiate a discussion in Adobe Connect forums.
Edited April 4, 2014 to include Adobe Connect 9.2 links and Google Translate links.