Social web for Tech Comm, STC March 2013


Published on

In a world where readers simply expect websites to offer well-connected experiences, technical documentation
teams must consider the possibilities now available to us through collaborative means. Having worked with blogs,
wikis, open source software, and social networking techniques, I want to share what I’ve learned about documentation as conversation. Through my work with the
OpenStack project, I have further refined my approach to technical content strategy with collaborative, community methods. My presentation shares the methods we use with OpenStack, the ways my thinking has changed, pitfalls to avoid, and measurements that help refine the strategy.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Cover slide- when I look back at the last five to eight years of experimenting and finding the future of tech comm, these are the two themes that emerged for me.I’m Anne Gentle and I work at Rackspace, the open cloud company.
  • I believe in it so much I’m willing to work in open source, have faith that the community will eventually deliver exactly what we need, and persevere through uncertainty and doubt. This work is so exciting right now because there is a shift and we are working through it, with it, around it.
  • I am a content stacker at Rackspace, here’s where I think we’re going
  • So where are we today? This is computer scientist Barbie. When Mattel surveyed thousands of little girls asking what careers they are interested in, they said computer scientist – and also journalist! Guess what, that is what we are heading towards today. While news delivery and sourcing is changing, actual professional journalism is still in demand. The same goes for professional technical writing – we report on the indepth stories behind the technology to help everyone understand what they need to know. I believe we can be heroes of the technology world by working with social web techniques.
  • collaboration, instant communication, project tracking, and data gathering
  • I have ideas because I’ve been working on this OpenStack project for 2 years now. Here’s some background.
  • found a mistake in the first run through so they just ran it again.
  • Next: what are our goals with the documentation?
  • So let’s start tying together community and documentation
  • there are challenges to using these tools – social media amplifies errors and heightens drama in communities while also enabling more voices and sites.AmplificationDramaToo many channelsToo much datamap represents the number of unique authors in each Usenet newsgroup who appeared in the current year, 2003.Making it work anyway.I’m going to walk through three areas: Sharing information and collecting feedback via social media techniquesGathering information from social networksMaking it relevant and collaborating closely with users, advocates, customers
  • Comments and workflowCommenting toolsMobile considerationsTranslation considerationsCategories of comments
  • Incorporate comment moderation and responses into your workflow. Use comments to create doc bugs (if they are bugs).Treat docs as code- manage content like an asset.
  • Embedding into output – where? How does each persona accomplish their goals?Identity and connection to existing sites?Spam protectionExpiration - How do releases work? Bulk operations for moderators?Notifications (and for whom)Analytics
  • Instagram only went for mobile platforms, not even the web.Twitter made an API that third party apps use.Niche – Instagram and Pinterest have specific features
  • Comments are the start of community, so you may need to build a community around the discussions
  • ■ Typo or minor edit suggestions: Log a documentation bug reportand tell the commenter about the report.■ Conceptual questions: These are questions like, “Why does itwork this way?” Give the commenter the additional informationhe or she needs. Then, if you think the question is of generalinterest, log a documentation bug report suggesting a revision.■ Troubleshooting or help requests: If you can, provide help directlyin the comments. If not, direct the commenter to anotherplace to receive help, perhaps support. Take ownership and followthrough to make sure the problem is resolved.■ Feature requests: Let the user know the current status if this isa feature that is in the works or has been rejected. If the featuredoesn’t yet exist, let the user know that. If there is another systemwhere the user can request the feature, either redirect the commentthere or let the user know about that system.
  • Listen in, be conversationalMine the data goldResearch existing channels
  • Interact but don’t get fired: know the policiesRackspace policy: be helpful
  • Technical writers are good at reporting their findings about users (Forrester analyst Josh Bernoff agrees). Write a monthly email summarizing what you see on the social web after listening for a while.If you see a troublesome spot based on feedback, fix it, or report it to someone who can.
  • This is where LinkedIn comes inI also advocate for a Community Content Audit – who are your members, what are their motivations? Who is blogging? Why?
  • I think of social relevance as the final frontier: creating documentation with the community. Collaboration, resource sharing, shared goalsIt’s like having a giant docs team with just as much cat herding – the only way to manage is to treat docs like code: adopt developer-like workflows and version control
  • Publishers want OpenStack content. I feel like I’m in a fight to be an acquisitions editor some days. Everyone wants an OpenStack book, or blog entries about OpenStack to publish on their site. I was surprised at this.
  • Originally had doc sprint during design summit, moved it to earlier dateExpectation – to hold these regularly, reality, releases dictated when to hold themTiming has changed again to six month releases with milestone releases in between. Doc sprints need a rethink.
  • Eric Holscher – read the docs - said at Pycon, Devs need to write for other devs – strongly believe what guy preaches now. This is a 180 degree turn for me.
  • OpenStack-doc-core reviews and decisions to publish docs to the live production site100 doc bugsOver 500 options in Compute now, nearly 300 in Object Storage* While Rackspace has the highest number of code contributors, it has the lowest number of writer contributors.Badge wearersAT&T IBMNebulaNiciraNimbis ServicesNuageRackspaceRedHatGrad StudentsUniversity of MelbourneUniversity of Tokyo
  • TryStack and DevStack – working environments for writersWADL to API ReferenceTry it out for APIBug triagingSpreadsheets of gaps in docsEntire outlinesGoogle Doc SprintExtensions are challenging – API docs are challenging
  • Curated search engine plus search analyticsWorking on loyalty, bounce rateProof of the PDF popularity
  • Next slide: blank slide
  • So, how can you take these ideas and put them into practice?Everyone’s a writer, so we need to tap the power of conversation and community to add value. To be better at any job, you can use social technologies to seek info. In your job, you are helping others be better at their job by giving them info matched to what they seek. Find ways to provide value with strategic social technologies.
  • Social web for Tech Comm, STC March 2013

    1. 1. Social Media, Social Networking, and Social Relevance in Tech Comm Anne Gentle Society for Technical Communication Houston March 2013
    2. 2. Flickr: seier+seier
    3. 3.  OpenStack – Open Source Cloud Computing Rackspace – Fanatical Support in all we do
    4. 4.  Not always a technical writer Wanting to make an impact ▪ 72% of companies use social technologies ▪ Writers are user advocates ▪ Need a plan and execution
    5. 5.  Never before have we had tools for media, networking, and relevance that help us meet our goals How do we harness the power of the social web for documentation?
    6. 6. Flickr: thegentles
    7. 7.  Self-Service, Prorated Supercomputing Fun! Your mission: “make all the public domain (New York Times) articles from 1851–1922 available free of charge” but “each article is actually composed of numerous smaller TIFF images” Your solution: To the cloud! Rented resources: “churned through all 11 million articles in just under 24 hours using 100 EC2 instances, and generated another 1.5TB of data to store in S3”
    8. 8.  Open Source Cloud Computing for all organizations Community-built with a global collaboration of developers and cloud deployers with open development Apache2 licensed code Open design process with an in-person meeting every six months
    9. 9.  Increase OpenStack adoption by driving usage and deployments – I was the first point of contact for AT&T’s cloud entry. Provide OpenStack support with docs and comments. In fact, gets about 10,000 unique visitors a week. Be strategic, collaborative, and open with documentation. (That’s the BHAG!) I’ve bet my career on this approach. Provide truth and trust. Hard as you might think with fast-moving code. Achieve business objectives for multiple companies in the OpenStack ecosystem.
    10. 10.  for deployers for cloud administrators and architects for cloud operators for REST API developers for Python developers
    11. 11.  Social media  Sharing content, feedback loops, discussions, and destinations Social networking  Gather information by interacting with your audience and users Social relevance  Collaboration, resource sharing, sharing goals
    12. 12. Flickr: marc_smith
    13. 13.  Close the loop  Track doc bugs that are reported in the commentsFlickr: myklroventine
    14. 14.  Personas  Commenters  Readers  Moderators  Administrators
    15. 15.  Why not mobile first or mobile only? Consider immersive experiences Consider when and where you search – from your phone? Responsive web design examples:
    16. 16.  Comment in their language Build communities locally Think: is English the “source” or another language?
    17. 17.  Many comments at once to gain further understanding  Pointing out typos or small errors in code  Want specific examples and specific help  Request for a particular featureFlickr: theilr
    19. 19. INFORM RESPOND
    20. 20.  Listen where users are; select channels Mine data gold  Daily/weekly blog searches  Career- and job-related searches Get to know community content members Anne Gentle
    21. 21.  Think like an acquisition editor  Everyone’s a writer (but not all of them have a coach)  Files as the basis are key to treading docs like codeFlickr: gruntzooki
    22. 22.  Originally had three month release cycles  Design Summit in- person meeting April and October  Now six month release cycles with milestone releasesFlickr: plenty
    23. 23.  Devs write for devs  Admins write for admins  This is a complete turnaround for me  Some people can only review (and it’s not worthwhile to convince them to write)Flickr: kholkute
    24. 24. • 66% Site visitors stay instead of leaving • 100 Doc patches and reviews a month • 10,000 unique visitors a week • 6 months before commenters answered each otherFlickr: dno1967b
    25. 25. • Logged doc bug in afternoon, came in to a fix the next day• Glossary out of “nowhere” from a wiki page starting point• Translation workflow in six months
    26. 26. Bam. Site Launch.
    27. 27. Hey! Release date!Doh. Release date.
    28. 28.  Acquisition editor Web stats analyst Writing coach Project manager Bug tracker/triager Editor Advocate Writer
    29. 29.  Media: Encourage conversation Networking: Listen and learn Relevance: Build a team and community Iterate repeatedly
    30. 30. Anne @annegentle conversationandcommunity annegentle Flickr: candelabrumelabrumdanse