I’m at Write the Docs today in Portland and will be posting notes from sessions throughout the day. These are all posted right after a talk finishes so they’re rough around the edges.
Michael works on the SUMO project which is short for support.mozilla.org. He’s a content manager who works on projects affecting people on every continent. At any given time there are 200 or so “Mozillians” working on their support site.
The first part of the documentation process is proactive support. They set up a big force field around planet Firefox. As part of proactive support they focus on user advocacy (bug fixes, features, etc.) and education (experience, features, marketing, engagement, articles). Mozilla’s more reactive aspect of support includes self-service support and user-to-user support.
In terms of education they aim to link to support docs whenever possible, even on Firefox’s homepage. Every new release of Firefox also includes documentation. So with Firefox 20 the download manager changed and was released along with a how-to video that was sent to tech writers and press.
As Michael put it, “It’d be nice if we could write software that never broke.” In the meantime, we should make it easy for users to recover when there is a problem. Mozilla approaches this with, for example, a “Reset Firefox” button that aims to automate some of the preferences-related debugging you have to do. About 80% of the time this fixes their support issues.
Some things will get through the force field of proactive support. For that, Mozilla uses a tool called Kitsune. This is their knowledge base, support forum, Twitter client, search, internal communication, and metrics.
The knowledge base is what Michael focused on. They use fully localizable wiki-based documents that support multiple products across multiple versions and operating systems.
The multiplicity of docs was cool. It’s all done through special wiki markup that allows them to show platform and version-specific instructions and screenshots for a particular feature. That allows the document to much more directly speak to the user’s need.
They run a survey on each article to gauge its helpfulness. They’ll then plot the responses to this survey alongside revision history. It helps them draw a correlation between document changes and their impact on users. This data is then pulled in to their document dashboard which allows them to, for example, filter for unhelpful documents.
For their localization each untranslated article includes helper text that asks readers to get involved and help translate articles. It still presents the text in English in case that is helpful to the reader. Their tool for this shows the English on one side with the new, translated text, on the other.
The top 20 articles on Mozilla’s support site account for 50% of the traffic. The drop off after that is quite steep. Just the top 70 articles account for 80% of their visits. This makes translation much easier as efforts can be directed to those documents that are most-used.
With their 6 week release cycle they don’t mark any documents as ready for localization until 2 weeks in to the cycle. This, ideally, means that localizations only have be done once per cycle. Small changes after that 4 week mark will be made in English but, unless it’s critical, not marked for localization again.
Michael posted all his slides too, which is great.