Notes from the Mousepad

I’m at the GNOME documentation hackfest in Brno, Czech Republic, and we’ve been updating help for GNOME platform and applications in advance of GNOME 3.4.

As part of the event, we’ve been reviewing our use of the Mallard syntax, making sure that we’re getting the most out of some of the new features. One newer feature in Mallard allows users to expand or hide portions of the help as needed. This helps users can more easily scan through possible topics, and to open the ones that are relevant to them. It also has the added benefit of saving space on the screen. This feature is in an experimental namespace for now, but we’re please enough with the results, and it is likely to be moved into the primary schema shortly. It will be in limited use in our help releases for the 3.4 cycle.

Here’s a brief example of what this looks like in action (note: you might need to view the page directly rather than through a feed aggregator if you want to see the video):

Also, here’s a portion of the code that makes it work. All that’s required is a the “ui:expanded” attribute on the appropriate element. It accepts values of “yes” and “no.”

<table rules="rows" frame="top bottom" ui:expanded="yes">
  <title>Tab-related Shortcut keys</title>
    <thead>
      <tr>
        <td><p>To Do This</p></td>  <td><p>Press This</p></td>  
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><p>Switch to the next tab to the left</p></td> <td><p>Ctrl + Alt + PageUp</p></td>  
      </tr>
    </tbody>
</table>

It’s possible to use this attribute on any element that contains a title, so you have the ability to use it on tables (as I’ve done here), lists, steps, or even entire sections. Thus far we’ve only used them on tables, and the style rules have yet to be ironed out.

The hackfest has been good thus far, but we still have much to do over the next couple of days. I am focusing on some updates to GNOME user docs, as well as writing new docs for Seahorse Encryption Manager, Rhythmbox, and am doing some GNOME docs team wiki work. Florian Nadge and Petr Kovar of Red Hat have been more than gracious as hosts, and the food on Brno is plenty meaty. Plus, there is cheap beer.

Of course the food and drink is even less expensive when Shaun McCance of Syllogist.net sponsors a dinner for us (thanks, Shaun!). Many thanks, as well, go to the GNOME Foundation for their sponsorship of our travel and accommodations.

With both a two-day conference and a three-day sprint, the Open Help Conference made for a busy week, but I must say that it was a success. We had people there from Gnome, Mozilla, OpenStack, Red Hat, BSD, as well as people who were interested in learning about open-source help. Everyone had something to share.

Some of our discussions may bubble-up as other blog posts, but a couple of the presentations and discussions made me think more about engaging users where they are. They made me think of how we can do more to extended help to people who use our software in the places that they go, rather than just requiring them to seek-out help from our help platform.

Twitter as a support tool
For example, one topic that we discussed was using Twitter as a support platform. Jennifer Zickerman demonstrated Mozilla’s Twitter-based “Army of Awesome” as a facilitator for user-to-user support. It’s pretty cool that Mozilla opens up their support channels in this way — users help other users directly, and you only need a Twitter account to help out. Although you can’t always solve a problem in 140 characters, it’s easy to point someone to a support article or to suggest other help resources. In a less formal way, I’ve also seen members of the Mozilla documentation team use Twitter to request a technical review of new help articles, or to remind people about documentation-related events (e.g., reminders for Mozilla’s Wiki Wednesday events).

Stack Exchange sites: Likes and dislikes
Another approach that we talked about were the various Stack Exchange sites. In talking about this, we liked how good answers rise to the top (as opposed to regular user forums where you may need to scroll through rows of posts to find a solution to a problem) and the gamefulness of the sites. We also liked that user questions and responses are available for download in XML format under a CC-by-SA license (albeit with fairly stringent attribution requirements). In particular, the XML downloads of user questions will allow documentation contributors to see what questions users are really asking, and what questions are occur frequently.

This being an open help conference, some of us did note that the back-end for any Stack Exchange site is proprietary, and discussed the network-effect of how using closed-source tools encourages more people to use to closed-source tools. Yes, Stack Exchange sites are “free-as-in-beer” to the people who use them, but we discussed both OSQA (GPL-licensed) and Shapado (AGPLv3-licensed) as open-source alternatives that would be worth considering for similar help-site deployments. Someone also mentioned that Reddit (which isn’t necessarily a help platform, but is open-source software) is a popular area where people can post questions or comments that are related specifically to Gnome or Ubuntu.

Using blogs and planets to recruit writers
Aside from Twitter-based tools and Stack Exchange sites, some other ways of seeking out users are less centralized. Two items I took away from Anne Gentle’s talk were that she is not shy about asking bloggers to repurpose their blog posts for use in the official documentation, and she also recruits people who post to the OpenStack Planet to help write documentation. These approaches seem especially helpful when writing documentation for very technical and complex projects. In some areas, the help author may not have the deep domain expertise needed to write docs for bleeding-edge software.

Other possibilities, and the remaining need for good docs
One project that I’m curious to know more about is the Mozilla Sumo project. I wish that members of their team had been able to join us. Sumo seems like a well-rounded platform for gathering user contributions to official documentation, while still allowing for editorial review and for document translations.

Even with all of this in mind, though, I still see strong, centralized documentation as very important. After all, it can save a lot of time if a user can find good docs in one central spot, and even Google isn’t helpful if no one has documented a well-researched solution to a problem. These discussions reminded me that it’s also important to interact with users where they are, though. If you have ideas for other ways to interact with users where they are, or know of something that has worked well for you, feel free to share any suggestions in the comments.

I’m in Cincinnati in advance of the Open Help Conference, an event organized around open source docs, and the building of community documentation efforts in commercial projects. The conference will kick-off this evening with a social event, and will continue (with both the conference and post-conference docs hackfests) through Wednesday.

The event has some great speakers lined up, with speakers from Mozilla, Red Hat, BSD, GE, and others. Scott Nesbitt from DMN Communications will also be here. I’m looking forward to interacting with everyone, and am especially looking forward to talking shop with Anne Gentle. Anne works as the “Content Stacker” (aka documentation lead) for OpenStack. OpenStack shares our Launchpad infrastructure, so it will be great to find ways to collaborate with her and the other OpenStack doc contributors.

I will provide a few updates on the conference over the weekend on my blog, but you can also get some updates by following the #openhelp hashtag on both twitter and identi.ca.

I’m looking forward to a great weekend.

Now that my week at the Ubuntu Developer Summit is over, and I have completed my safe flight back, I thought I would write up a blog post about my experience while I complete my recovery from jet lag.

My week at UDS was a challenging week. A great week. A week in which I had great discussions around docs, met lots of cool people, and wound up expanding the limits of what are normally considered acceptable sleep patterns.

I had three docs-team sessions during the week. I also attended two sessions about cloud-related documentation, and another session on server documentation. The three docs-team sessions focused on the team strategy, our goals for the 11.10 release cycle, and evaluating a web-based documentation platform.

Team Strategy

The inspiration for the team strategy discussion is the Xubuntu Strategy Document. Have you read it? When Cody Somerville first wrote it, part of me was like, “Are you serious? Did you write this yourself?” It seemed too complicated. In practice, though, I’ve seen the Xubuntu team reference that document while making decisions time and time again. I think a similar document would benefit the docs team, too. I’m preparing a draft document based off of recent team discussions, and will be sharing it in the next week.

Team Goals for the 11.10 Release

The team goals session was pretty great. People in the room, and people listening in via the audio casts, gave helpful input. There was more focus on the Ubuntu wiki at UDS than I anticipated. Some of our goals for this cycle include creating a strategy document, contributing to upstream docs projects, refactoring our team wiki, testing of documentation accessibility, testing a preferred help layout, doing stable release updates for docs and translations, squashing boogs, adopting a consistent coding style, updating our style guide (or picking an existing one), and doing some of the initial work in revamping help.ubuntu.com.

It sounds like a lot, and it is, but some of it is already a work in progress. We will make these goals explicit during our next team meeting.

Web-based Documentation Platform

The group behind this project is Pronovix, a Drupal consultancy. I knew that their project was using Drupal and DITA, but I wasn’t sure what *their project did*. They had some of their staff based in Hungary, just a short trip away from Budapest, so I thought it was worth getting in touch to learn more about their approach and how it might benefit us.

DITA stands for the Darwin Information Typing Architecture, an XML syntax developed by IBM that specializes in content profiling and content reuse. The advantage of content reuse with a tool like DITA is that it allows you to write something once, write it well, and reuse it most everywhere. That is the idea, at least. Implementation of DITA can be difficult. Their project has promise, but the toolchain isn’t currently packaged by any distro other than OpenSUSE. Harald Sitter (Mr. Apache Log File) felt that this very much limits the likelihood of upstream adoption.

Even with that in mind, we are going to seriously evaluate their platform. It was very considerate of this group to make a trip to demonstrate their project, and we want to be supportive of everyone who is working in open source documentation.

There are quite a few irons in our fire, and we’ll have to get word out about our activities somehow. Our progress will likely be presented via a new Ubuntu Documentation Team blog. We think now is a good time to start one up, so look for more info on that soon, as well.