Monthly Archives: January 2011
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
- 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
- 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
Below: Traffic sources for the entire wiki over 1 week, from 7 to 14 January 2011
- 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…
The above screenshot shows that ffeathers triggered 1 356 visits to the documentation wiki over 6 months. And over a week:
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
- 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.
- 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:
- Jodie Miners
- Ekaterina Stepalina
- Eliane Pohl
- Matt Doar
- Doug Morrison
- Matt Hodges
- Sarah Maddox – that’s me, folks
…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!
Content management LOL
Ready for a Friday chuckle?
I took this picture in a stairwell, then tweeted it:

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)!












Experiences with readers’ comments on the Atlassian documentation wiki
Jan 29
Posted by ffeathers
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:
Confluence documentation (DOC space) only:
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.
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:
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:
Experimenting with wiki comments
Others get a bit more adventurous, and check to see if they can code JavaScript into a comment:
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:
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:
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:
Jumping to our defence
I stepped in to smooth the troubled waters:
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:
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:
Been there, done that, got the T-shirt
Readers help each other. To me, that’s the most beneficial aspect of allowing public comments:
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!
Share this:
Like this:
Posted in atlassian, Confluence, technical writing, wiki
13 Comments
Tags: atlassian, comments, Confluence, crowd sourcing, documentation, feedback, social documentation, social media, technical communication, technical documentation, technical writing, user assistance, wiki