Monthly Archives: January 2011

Experiences with readers’ comments on the Atlassian documentation wiki

People are what matters in the documentation world. The docs are for the people and increasingly by the people too. One way of giving people a chance to contribute to, and help each other via, the documentation is by allowing them to comment publicly on the doc pages. Susan Grodsky asked me to write something about Atlassian’s experiences with comments on our documentation wiki. Here goes.

There’s a lot to talk about: setting the permissions that determine who can add comments to the pages, managing those comments, the sort of comments people make, how many comments we receive, and above all, is it a good thing or a bad thing to allow public comments on the documentation?

I’ve done some analysis of the comments we received over a week, from 7th to 14th January 2011. This may be a fairly quiet time of year, but it happened to be the period when I had time to do the analysis.

A bit about our documentation wiki

We write and publish all our documentation on a single Confluence site: confluence.atlassian.com, fondly known as CAC. It hosts the documentation for all our products: JIRA, Confluence, Crowd, FishEye, Crucible, Bamboo, JIRA Studio and more.

Each product has its own documentation “space”. Most products in fact have a number of spaces, one for each major release of the product. Many products also have a separate space devoted to developer documentation – APIs, plugin frameworks and the like. If you go to the CAC dashboard and scroll down, you’ll see the list of spaces on the left-hand side of the screen.

And yes, the documentation for the Confluence product is hosted on Confluence itself. The Confluence documentation space is just one of the spaces on CAC.

Stats of visitors to the documentation wiki in a week

To give some context to the number of comments received, I looked at the traffic that the documentation site received in the week of 7th to 14th January 2011.

Across the entire wiki:

  • 99 329 people visited the site, in a total of 157 312 visits.
  • 45 549 pages were viewed a total of 540 488 times.
  • Number of comments on all spaces: 98

Confluence documentation (DOC space) only:

  • 1 793 pages were viewed a total of 99 310 times.
  • Number of unique page views: 78 037
  • Number of comments on this space: 39

My previous blog post has some pretty pictures and more information from Google Analytics.

Analysis of comments on one documentation space in a week

Here are the results of my analysis of the comments received in the week of 7th to 14th January 2011 on the Confluence documentation (DOC space) only.

  • Number of comments on the DOC space in that week: 39
  • Who made the comments:
    • 18 comments were anonymous – added by someone who was not logged in to the wiki.
    • 21 comments were from logged-in users.
  • What the comments were about:
    • Offering information, hints and tips: 9
    • Suggesting an addition/correction to the documentation: 2
    • An unhelpful comment, possibly meant to be humorous: 1
    • Requesting help on functionality (“how do I…” or “is it possible to…”): 9
    • Requesting support (when something does not work as expected): 13
    • Suggesting a feature or improvement in the product: 5

How I tracked the comments

Google Analytics does not show statistics specifically for comments. Instead, I used an RSS feed generated by Confluence to retrieve the comments over the time period I wanted. (To define the RSS feed you want from a Confluence site, click “Feed Builder” on the Confluence dashboard.)

Permissions and public signup

How do we determine who can add a comment? Confluence has a useful permissions scheme. You can grant permissions to specific users, to groups of users, and to “anonymous” users, the last being people who have not logged in.

Each space has its own set of permissions. The permissions determine what people can do with pages, with blog posts, with space administration, and of course with comments. For example, you might choose to allow only a specific group to add and update pages in a given space. That group might be the technical writers, or the company employees. In another space, you might allow everyone to add and update pages, but only a given group to delete pages, and so on.

Talking specifically about comments: For the Atlassian documentation spaces, we have set the permissions to allow everyone to add a comment. Even anonymous users can add comments. Only Atlassian staff members can remove comments.

We have also enabled public signup on the wiki. That means that anyone can sign up for a username and then log in, immediately and at any time. Once logged in, they’re not “anonymous” users any more. They need to enter an email address, but basically they can use any name, username and email address they like.

How we handle the comments

At Atlassian, each technical writer is responsible for a specific set of documentation spaces. We keep a close eye on what’s happening in the documentation, including any comments added to the pages. There are two ways we do that:

  • Select the “watch” option on the space. When you are watching a space, Confluence sends you an email notification of all updates in the space, including comments.
  • Use an RSS feed, configured to show all activity over a given period of time.

As you can see from my analysis above, many of the comments are from people asking for help rather than making suggestions about the documentation itself. The Atlassian Support team monitors the documentation spaces too. The support engineers are really great at responding to comments. We could not do it all without them.

What’s more, readers often help each other. To me, this is one of the most rewarding aspects of allowing public comments.

The technical writers jump in to answer the comments that relate to the documentation. We answer the comment, update the page if necessary and thank the person for their input. A week later we remove the comment and our reply.

Well, that’s the plan anyway :)

In practice, we often don’t have time to respond to all the comments appropriately. We also don’t have time to go back a while later and remove all the comments that the support team and other customers have answered.

The result is that many of our documentation pages, especially in the older spaces, have long strings of comments attached.

We’re considering writing a script that we can run regularly to delete comments that are over two years old (or whatever period we choose). The principle is that the page will have been updated a few times and most comments will be irrelevant after such a long period.

If we do start using such a script, we will write up our comments policy so that wiki users know their comments will disappear eventually, even if we haven’t explicitly replied to every comment.

Are people nasty?

We don’t often see malicious comments. There is of course the occasional frustrated person who can’t get something working. We usually ask them to raise a support request or report a bug on the issue tracker, because the documentation is not the place for venting frustration or for getting immediate help with an urgent problem.

What about spam?

Confluence has Captcha for spam prevention. We have configured it to spring into action whenever an anonymous user adds a comment. Captcha prompts the user to read some text from an image and type it into a form. This is very effective in preventing spambots.

We do get the occasional spam comment from real people – often someone trying to sell watches, funnily enough.  They add their advertisements to the pages about wiki notifications and watches. :)

We remove spam comments as soon as we spot them.

Some examples of comments

Here are some of the comments we have received. They’re not all from the week of 7th to 14th January 2011. Instead, I had a look around to find some interesting and representative comments all over the wiki. Most are from the DOC space, though the last one is from the CROWD space.

Some people use the comments just to try out the wiki functionality:

Experiences with readers’ comments on the Atlassian documentation wiki

Experimenting with wiki comments

Others get a bit more adventurous, and check to see if they can code JavaScript into a comment:

Experiences with readers’ comments on the Atlassian documentation wiki

Trying out a bit of JavaScript

People share macros they have written to extend the wiki functionality. This comment was on a page about the {include} macro. Someone has written a related macro:

Experiences with readers’ comments on the Atlassian documentation wiki

Sharing a macro

People do tell us off when something goes wrong. This comment was on the page about backing up and restoring a Confluence site:

Experiences with readers’ comments on the Atlassian documentation wiki

Telling us off when something goes wrong

Other people jump to our defence. Below is a continuation of the comment above, and a reply from someone else. The reply is the comment that I counted as “unhelpful, possibly meant to be humorous” in my analysis above:

Experiences with readers’ comments on the Atlassian documentation wiki

Jumping to our defence

I stepped in to smooth the troubled waters:

Experiences with readers’ comments on the Atlassian documentation wiki

Smoothing troubled waters

Here’s a helpful comment about the documentation itself. Someone who shall remain nameless ;) had forgotten that we’re not in 2010 any more. This comment was on the release notes:

Experiences with readers’ comments on the Atlassian documentation wiki

Pointing out a typo in the docs

Next is possibly my favourite string of comments, because it’s so cute and funny and totally off topic. The comments are still on the page:

Experiences with readers’ comments on the Atlassian documentation wiki

Been there, done that, got the T-shirt

Readers help each other. To me, that’s the most beneficial aspect of allowing public comments:

Experiences with readers’ comments on the Atlassian documentation wiki

Helping each other

A good or a bad thing?

Receiving and responding to comments keeps the documentation alive, dynamic, iterative, constantly improving. The best of agile.

It’s also chaotic, time consuming and open to occasional abuse.

From looking at the comments themselves, I’d say our customers appreciate being able to have their say, ask questions and help each other.

Me? I love it. I would find it hard to go back to a form of technical writing where there’s less contact with the readers. But I do wish I had more time to give due attention to the comments we receive.

Thank you to everyone who comments on and contributes to the wiki documentation. You are stars!

Google Analytics stats from the Atlassian documentation wiki

A while ago Susan Grodsky dropped a comment on my blog, asking me to write something about Atlassian’s experiences in allowing users to comment publicly on our documentation. I’ve been gathering some information for such a post. But first, I thought, it would be useful to know a bit about the traffic that our documentation wiki receives. So here we go.

I’ve been delving into Google Analytics to gather some stats about the number of visitors to our documentation. In a follow-up post, I’ll take a look at the comments people have posted on the documentation pages in the same period of time.

A bit about our documentation wiki

We write and publish all our documentation on a single Confluence site: confluence.atlassian.com, fondly known as CAC. It hosts the documentation for all our products: JIRA, Confluence, Crowd, FishEye, Crucible, Bamboo, JIRA Studio and more.

Each product has its own documentation “space”. Most products in fact have a number of spaces, one for each major release of the product. If you go to the wiki dashboard and scroll down, you’ll see the list of spaces on the left-hand side of the screen.

And yes, the documentation for the Confluence product is hosted on Confluence itself. :) So, the Confluence documentation space is just one of the spaces on the documentation wiki at confluence.atlassian.com.

I’ll give some stats for the wiki as a whole. Then we’ll look at one single space, the documentation for the Confluence product itself.

Below: Stats for the entire wiki over 6 months, from 14 July 2010 to 14 January 2011

Google Analytics stats from the Atlassian documentation wiki

6 months from 14 July 2010 to 14 January 2011

  • Number of visits: 3 308 866
  • Number of page views: 11 037 412
  • Number of visitors: 1 798 667 (not shown on the screenshot)

Below: Stats for the entire wiki over 1 week, from 7 to 14 January 2011

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

  • Number of visits: 157 312
  • Number of page views: 540 488
  • Number of visitors: 99 329

Below: Top content across the entire wiki over 1 week, from 7 to 14 January 2011

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

Below: Traffic sources for the entire wiki over 1 week, from 7 to 14 January 2011

Google Analytics stats for the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

  • Direct traffic: 22.7%
  • Referring sites: 23.56%
  • Search engines: 53.04% (mostly Google)

Traffic sent from ffeathers to the Atlassian docs

Curiosity grabbed hold here: I wondered how much traffic my own blog had sent to our documentation wiki. So I had a look…

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

The above screenshot shows that ffeathers triggered 1 356 visits to the documentation wiki over 6 months. And over a week:

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

It seems that ffeathers accounted for 0.06% of the visits to the documentation site. Peanuts, maybe, but still interesting. :)

Below: More about the visitors to the wiki over 1 week, from 7 to 14 January 2011

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

  • Number of visits: 157 312
  • Number of unique visitors: 99 329
  • Number of page views: 540 488
  • Most popular browser by far: Firefox

Below: Stats for the documentation for a single product, Confluence, over 1 week, from 7 to 14 January 2011

Let’s take a look at just one space in the wiki: the “DOC” space, containing the documentation for Confluence.

Google Analytics stats from the Atlassian documentation wiki

Google Analytics stats from the Atlassian documentation wiki

  • Number of pages viewed during that week: 1 793
  • Number of page views: 99 310
  • Number of unique page views: 78 037
  • Average time on page: 2 and a half minutes
  • Bounce rate: 52.92% (these are people who just read the one page they landed on, and then left without going elsewhere on the site)

Wrapping up for now

Google Analytics is pretty cool. As you can see from the screenshots, there’s a lot to learn from the information it gives. I hope you’ve enjoyed this brief glimpse into GA and into the number of hits our documentation wiki receives. In my next post, I’ll take a look at the comments we get on the Confluence documentation space (DOC) in particular.

New guide to developing technical documentation on a wiki

We’ve just published a new set of documents in our wiki’s user guide: Developing Technical Documentation on Confluence Wiki. We started writing the guide during our recent doc sprint. Since then, I’ve put it through a technical review and added some bits. Now it’s part of the “official” documentation. That’s a doc sprint win. :)

Designing and developing this suite of documents was a lot of fun and very interesting. The project serendipitously combined a number of aims, all rather different in nature:

  • Think up something to do in the doc sprint.
  • Involve other doc sprinters in the project, especially people from outside the company.
  • Spike a “use-case focused” guide and make sure the result is useful even though it’s a spike.
  • Tie together all the information we have in various spots, about writing technical documentation in a wiki.
  • Put the guide into the core Confluence documentation, so that it will be maintained and updated from now onwards.

People who worked on the guide during the doc sprint

A number of people collaborated on this guide. Two were Atlassians and the rest were people who joined the doc sprint in November:

…and others who reviewed the pages, working remotely in various spots around the world.

What is a “use-case focused” guide?

One of the things we’d like to do is to provide more “use-case focused” documentation. By that we mean that the guides should focus on a specific use of the product. A better term might be “domain-focused” documentation. For example, for Confluence we should write documentation about how to use Confluence as an intranet, how to use Confluence as a knowledge base, how to use Confluence for technical documentation, and so on.

This suite of documents is the first stab at such a user guide.

Design of the guide

These are the principles on which the guide is based. It’s just a spike, so we didn’t hit all these goals. But it’s a very good start.

Write topics that are task-focused on the macro level. The words “on the macro level” are very important in this context. It’s a well-known principle of technical documentation that guides should be task-focused, as opposed to feature-focused. We tell users how to do the things they need to do, rather than documenting the features of the product. At the moment, much of our documentation is nicely task-focused on the micro level: How to add a space, add a page, add a comment, set page restrictions, and so on. But it’s not task-focused on the macro level: How to set up a space for technical documentation; how to push a document through the draft/review/publish workflow (using page restrictions); and so on. One good way of addressing this problem is to produce use-case focused (or domain-focused) guides.

Tell people only what they need to know. Focus on the aspects of Confluence that the target users (technical writers, in this case) need. Ignore the other aspects. For example, on a typical technical documentation wiki it’s not important to know how to follow users or use the other “networking” features of the wiki.

Employ progressive elaboration. Progressively reduce the level of detail in the step-by-step instructions, while increasing the complexity of the concepts. Start with fairly detailed instructions for the basic functionality, in the first section of the guide. Become less detailed in later pages, because the users will have become more familiar with Confluence. At the same time, they will be dealing with more complex topics. But that’s OK, because they’re in their field of expertise (domain).

Encourage users to explore the product and learn from the UI, rather than telling them exactly how to do every single thing. If a user guide is very comprehensive, it gives the impression that it documents the entire product. If something isn’t in the docs, people will think it’s not in the product either. They won’t try to explore the product. We should encourage people to trust the UI. Also, if a user guide is very dense, people won’t find what they need in it.

Employ content re-use. Use Confluence’s {include} macro to pull in content from existing pages, so that we can avoid duplicating content and can thus reduce maintenance.

The result

I’m delighted with the resulting guide: Developing Technical Documentation on Confluence Wiki. It’s not perfect, but it’s a very usable and useful piece of documentation and it certainly fills a gap. Thank you again to all those who took part in developing this guide, and to everyone who took part in the doc sprint!

Sydney Red Gum tree

A magnificent Sydney Red Gum tree I encountered on my walk this morning. Shot taken from a rocky ledge half way up the height of the tree.

Content management LOL

Ready for a Friday chuckle?

I took this picture in a stairwell, then tweeted it:

This has to be an important document! 

Content management LOL

Content management LOL

Here’s the reply I received from Alan J. Porter:

I think that may be taking content management a little too far!!

While Michael O’Neill quips:

Can’t tell if it’s a usability fail or win. ;P

LOL (laugh out loud)! :)

A technical writer in Sydney – and some trees

Julie Norris had a great idea this week. She has created a YouTube channel specifically for the #tcchat Twitter chat group, and she’s uploaded a video of herself and her corner of the world. Now she’s inviting us to do the same. What a lovely idea, thanks Julie!

So I’ve spent the last few days making a video and uploading it to YouTube. To cut a long story short, here’s the video. As Julie suggested, the video introduces me as a technical writer working in Sydney, and shows you a bit about my surroundings:

I think it’s a cool idea that will help to bring far-flung technical writers closer together, especially those of us who take part in the #tcchat Twitter chat group.

The long story

It took many, many tries to get this far. I have to confess that the air turned a delicate blue hue at times. Why oh why are movie formats so finicky, fussy and frustrating? ;)

I first read Julie’s post when I was on the bus on the way to work. Unsurprisingly, I did not have my camera with me. I did, however, have my sparkling new iPhone 4, which does movies. Cool. I made a cute movie of the Sydney Harbour Bridge through the bus window, and of the building where I work. On the way home, I filmed a Paperbark tree flapping in the breeze and a Sydney Red Gum glowing in the gentle afternoon light.

The next day I sallied forth with my “real” camera and took some more movies.

Then I attempted to splice them together. Disaster. I tried free software and trial versions of expensive software. Suffice it to say: Nothing works perfectly.

So in the end, I’ve decided to use the software that came with my Canon camera. It’s pretty good, but it is not able to merge the movie files made by the iPhone. It gets the picture OK, but no sound.

Oh, and I’m fond of Australian trees. You’ve probably noticed there are a couple in the movie above. :)

Follow

Get every new post delivered to your Inbox.

Join 182 other followers