Playing with Checkvist for handy online “to do” lists

A few weeks ago Sasha dropped a comment on my blog about a website called Checkvist. She called it an “online outliner”, a pet project developed by herself and her husband. That sounds pretty cool, I thought.

So I moseyed over to Checkvist and found that it’s a place where you can create neat “to do” lists quickly. Then you can do all sorts of things with them.

The power of the list

Are you a list person? I am. Never underestimate the power of the list in keeping the scary chaos of the multiplex universe at bay. Checkvist is particularly awesome because you can create hierarchical lists – one list item can be the child of another. Take that, oh chaotic universiplex!

On a side note, people even use Checkvist to plot the outlines of their novels.

What does Checkvist look like?

Here’s a list on Checkvist :

Playing with Checkvist for handy online "to do" lists

The format is nice and clean. You can change the “view options” to display your list as a numbered list or to show details such as date last edited and by whom.

How does Checkvist behave?

I love it! The interface is very no fuss no bother. Just click, something happens, it’s what you wanted and you’re done. The power is in the shortcut keys. Look out chaotic universiplex, here we come.

Cutting loose from the Checkvist website

You don’t have to visit the Checkvist website for every interaction with Checkvist. There are a number of options for more flexible interaction.

Do you live in your web browser? You can put Checkvist into a Firefox side panel or a Chrome popup. Here’s the Firefox side panel (with Wikipedia in the main panel):

Playing with Checkvist for handy online "to do" lists

There’s a Google gadget that you can put on your iGoogle home page. I wonder how many people use iGoogle as their home page and how many people use gadgets regularly. Do you? I experimented with iGoogle a while ago, but don’t go there regularly any more.

Checkvist supplies a bookmarklet that you can drag onto your browser. First make sure your browser is showing the bookmark toolbar. Then go to your user profile in Checkvist, click “Tools and Extensions” and drag the bookmarklet to the browser’s bookmark toolbar. When you are on a web page and want to remind yourself about something associated with that page, just click the bookmarklet to add a linked item in your Checkvist list.

There’s a mobile interface for use on the iPhone and other smart phones.

Checkvist integration with Confluence wiki

In her comment, Sasha pointed out that you can convert a Checkvist list to Confluence wiki format. True to Checkvist style, it’s very simple. Just click “export” and choose Confluence wiki format.

Playing with Checkvist for handy online "to do" lists

The output appears in a new browser tab, so that you can copy and paste it into Confluence. It contains the wiki markup that Confluence will recognise.

Playing with Checkvist for handy online "to do" lists

There are other export formats too, including OPML.

Checkvist integration with JIRA issue tracker and Gmail

This is very handy indeed. The Checkvist bookmarklet, mentioned above, has a special relationship with three web applications:

• Gmail
• JIRA issue tracker
• YouTrack issue tracker

I tried it in the first two. Go to Gmail and open an email message. Click the Checkvist bookmarklet. Checkvist pops up a dialogue offering you the option to add the email message as a task.

Open an issue in JIRA and click the bookmarklet to add the issue as a Checkvist task. Magic. That’s how I created the first item in my Checkvist list. CONF-5994 is a JIRA task:

Playing with Checkvist for handy online "to do" lists

Why would I want a simple, online “to do” list?

I have JIRA for project management and issue tracking. I have Outlook tasks. I have Gmail. I have Confluence wiki for collaboration. Why add Checkvist to the mix?

Well, at the moment I use Outlook tasks for micro management. JIRA is great for the big picture, but sometimes I need a short list of things to kick off the day. Things I know I will and must look at first thing. Outlook tasks are very good for this. But there are two drawbacks:

• This is the only thing I use Outlook for. It’s a bit of overkill to run Outlook just for micro task management.
• I can only access the tasks from my desktop PC. So if I know I’ll be working from home or some other remote location, I email myself all the urgent tasks coming up. If my working remote is unplanned, I just have to guess what they are.

Sometimes I’m busy with an urgent issue in JIRA bug tracker, and I want to send myself an extra special reminder, just for me. I could just click the bookmarklet to add the issue as a task in Checkvist.

Maybe I want to make sure I reply to my mother’s email message, and I’m afraid it will disappear into the morass that is my email inbox. No worries, just click the Checkvist bookmarklet.

Lots of other uses I haven’t tried yet

There’s the guy who outlined his novel on Checkvist. You can share a list and work with other people to compile the tasks – maybe a list of holiday “to dos”. It could be a handy tool for a brainstorming session, especially if the scribe is a wizard with the Checkvist shortcuts.

tl;dr: I think Checkvist is pretty cool. Let me know if you’ve tried it too.

Book review of “WIKI: Grow Your Own for Fun and Profit”

I’ve just finished reading Alan J. Porter‘s new book, WIKI: Grow Your Own for Fun and Profit. I heartily recommended this book to anyone who wants to know more about wikis. In fact, you’ll enjoy it even if you’re already intimately acquainted with wikis.

The content and message of the book grow organically, rather like its subject. To get the full benefit of Alan’s experience and the full impact of his message, you need to sit down with a beverage or brew, start from the beginning and read through to the end. That’s easy and rewarding to do. The book has a comfortable conversational style. Alan introduces a topic or concept in one chapter, then builds on it in subsequent chapters. By the time you reach the end of the book, you’ve absorbed Alan’s experience of and research into wikis. You’ve also examined his useful examples, mulled over his anecdotes and chuckled at Douglas Potter’s apt drawings.

What’s it about?

The book takes you through all stages of wiki ownership, from deciding whether you need a wiki, through choosing the right one, encouraging people to use it, designing it, then structuring and restructuring it as it gains more content.

Throughout the book are ideas for encouraging people to use the wiki and to contribute content to it.

Chapter 2 "Defining the Wiki" - drawing by Douglas Potter

First impressions

I love the cover of the book. Comfortable. Alternative. Man at work.

I also love the drawings by Douglas Potter. They are so cleverly suited to the style of the book. This one is my favourite, from the cover plate of chapter 2, Defining the Wiki.

Highlights

The case studies at the back of the book are particularly interesting. There are five of them. For me, these stand out:

• Case study 5 tells the story of the book itself. The author, editor, reviewers and publisher all worked together on the book, using a wiki (PBworks) as their collaboration platform. Now that’s dogfooding the message of a book. The case study outlines the process they followed and the benefits the publisher saw in using a wiki for this purpose. Alan also gives a foretaste of the process earlier in the book, under the heading Doing it Ourselves (page 12).
  
• Case study 3 tells how a company used a wiki to gain ISO 9000 certification in a very short period of time.
• Case study 4 is Gina Fevrier‘s story of adopting Confluence wiki to engage users in her company’s document content strategy.
  

Some sections of the book that stood out for me:

• User-Generated Content (pages 82-4). This section  is a must-read, for its excellent summary of the value of user-generated content, and for its anecdotes.
• Why Would You Need to Use a Wiki? (pages 6-11). This section has a good, concise list of a wiki’s uses, based on a real-life example of a project that could have used one but didn’t.
• Appendix D: Notes on Popular Wikis (pages 141-6). The summaries of the features and intended audiences of each wiki are concise and useful. The wikis covered are: Confluence, DokuWiki, MediaWiki, MindTouch (the erstwhile DekiWiki), MoinMoin, MyWiki, PBworks, ProjectForum, TiddlyWiki, TikiWiki and Trac.

Interesting titbits:

• Under the heading Aren’t Wikis Inaccurate? (page 4) Alan says: “Studies have shown that the number of mistakes per article on Wikipedia is actually lower than in the venerated print Encyclopedia Britannica”.
  

My favourite anecdote:

• The one about tennis balls in the server room (page 61). I won’t repeat it, because it’s best to read it in context.

In conclusion

Sit back, put your feet up, tilt back your hat and get reading. Your wiki will take root as you go.

A blitz test of the documentation

This week at Atlassian we held a blitz test of the documentation that we were soon to publish with an upcoming software release. It was fun and productive. We made some nice improvements in the documentation. As a bonus, we found a cute bug in the application itself when we tested the procedure against the step-by-step guide.

Our QA team first introduced blitz tests, to test the applications themselves rather than the documentation. We decided to try it out on the documentation too.

What is a blitz test?

The doughty blitz testers

In a blitz test, people from all walks of life spend an hour doing concerted and concentrated testing of specific aspects of the product. It’s a way of timeboxing the testing. It’s also a way of viewing the product as whole rather than the disparate bits that have previously been reviewed individually. Best of all, it’s a way of working together on improving the product.

To say “people from all walks of life” is a bit of an exaggeration, of course. The point is that the developers, technical writers, product managers and various other people join the QA team and that we all work together for that hour on testing the product due for imminent release.

As technical writers, our product is the documentation. For this blitz test, we targeted the documentation for the release of Atlassian Crowd 2.1.

Preparing for the blitz test

First I contacted the development team leader and product manager to check whether they liked the idea of the team taking part in a documentation blitz test. They were enthusiastic. The Crowd team are great.

The next step was to create a test plan that everyone could work off, with the following information:

• Date and time of the blitz test.
• Names of the testers.
• Location. We held a kickoff meeting in the team area and then the testers worked at their own desks.
• Aim and scope of the blitz test.
• A list of all the new and updated documents that I wanted tested, grouped by functional area in the application.
• The test environment. In our case, we were testing the draft documentation on our production documentation wiki.
• Where and how people could record their test results and feedback.

At the appointed date and time, we all gathered in the area around the development team’s desks to confirm that everyone knew the areas of the application and the documents to be tested. We allocated one or more areas and documents to each person, and checked that everyone knew where to put their results and which chat room to join.

It’s on! People rushed back to their desks, the room took on an air of frenzied quiet, and the chat room and wiki exploded into action.

How did the testers provide their test results?

We offered various ways that people could record their results:

• Edit the documentation pages directly. The documentation is on a wiki, so that was easy.
• Add comments to the documentation pages. The pages were in draft status, so the content and the comments were visible to Atlassians only.
• Chat about the test findings in the team’s online chat room.
• Ping me on IM.
• Add a child page to the test plan on the internal wiki, documenting the test findings there.
• Add a comment to the test plan on the internal wiki.

The results

The development team were positive and enthusiastic about the experience and jumped in with a will.

• The development team leader suggested a few small additions to the more technical documents, clarifying the impact of changes and new features.
• A developer pointed out a page where the terminology used on the screens had changed again after I’d updated the documentation. We needed new screenshots and a change to a page name. Phew, that was a biggie.
• Other developers pointed out a number of small clarifications.
• Someone pointed out a change in behaviour that was actually a bug. Nothing major, just that the “Continue” button in one of the wizards no longer worked in the same way. You now need to click a tab instead of a “Continue” button when you want to move to the next stage. I’ve updated the documentation and we’ll fix the bug in the next release. At which stage I’ll change the documentation back again.
• Someone else found an issue that he’d fixed in the code, but had forgotten to mark as “fixed” in the issue tracker. The result was that I hadn’t updated the documentation, of course. This was a fairly big find too. Phew again.

Some feedback came directly to me via IM. What a good thing that you can copy and paste from an IM conversation!

Did anyone update the documentation itself? Yes indeedy! The product manager tweaked the release notes, and noted that he would produce some performance stats to illustrate a point.

What did the developers think of the documentation blitz test?

The Crowd team's standup toy at rest in the clasp of a monkey

After the blitz test was over, I asked the development team what they thought of the experiment. Here’s their feedback about why they thought it was beneficial:

• Team ownership of the documentation.
• Team building.
• The obvious verification that what we’ve specified in the docs is correct.
• It can be worthwhile double-checking the docs in case functionality or edge cases are missed in the docs (because we may have subtly changed the implementation without notifying the tech writers).

Was the blitz test a Good Thing?

From my point of view as technical writer, it was very valuable.

The development team and product manager had already reviewed the documentation piece by piece, as I developed it. The blitz test gave them the opportunity of viewing it as a whole.

People continued updating the documentation the day after the blitz. We released the software and published the documentation two days after the blitz test. We’re on a roll!