Social Media etiquettes and best practices

I know a lot has been written on the topic. You can read all about it via this Google search.

It is impossible to have a set of social media guidelines, that work for all scenarios. New fails and faux pas keep showing up, even from experience people and established brands. All we can do is minimize them, educate ourselves, and well… hope for the best! 🙂

The reason there is room for each of those apparently repetitive points, is:

  • Social Media is subjective.
  • People have varied opinions.
  • One man’s misery is another man’s fortune/delight.
  • Subjective things are mood-dependent.
  • Cultural, geographical, racial, gender related, and other such differences are difficult to figure out, fathom, prevent, plan for, and mitigate.

I could go on and on, but you get the gist. I have shared my condensed experience at http://list.ly/list/EnJ-what-to-do-on-social-media-channels-to-prevent-social-media-fails.

Leave a comment on what your experience says.

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.

Crowd source your feedback via social lists

Everyone in the IT sector is looking for feedback from social media.

  • Product managers for the products.
  • Support staff for the overall perception of their support.
  • Investors for the new hot field to invest in.
  • Like-minded people to discuss topics, follow feeds, attend events, contribute to causes, etc.
  • And us communicators for our documentation, videos, forums’ efficacy, and usefulness of blogs.

However,

  • Surveys are now a thing of past.
  • Tracking user behavior is limited in various ways, for various reasons.
  • Doing such market research is relatively costly.
  • Face-to-face customer engagement is a bit formal and restricted media for open feedback.

Listly's feature wish listSocial and crowd-sourced lists are a great tool for all the above use cases and then some more. While lists have always been around and ranks and ratings have always been part of the websites, but these have not been so prominent, so user-friendly, never had such a large user base, and never went social.

List.ly has overcome all these shortcomings in a great way. Here’s a great example of list.ly seeking wish list items from the community!

Oh and you can find yours truly listing here. To join Listly, use this link.