I stumbled across Mozilla Firefox’s help system last week and was interested to find most of the articles were largely written by volunteers. I hadn’t come across this kind of model for documentation before so it raised some interesting questions. For starters, can a group of volunteer technical writers collaborate to produce an effective help system?
Mozilla released Firefox as an open-source web browser back in 2002 and as such the source code is open to anyone. As a non-profit organisation, Mozilla also relied heavily on the code, along with the support and documentation being largely maintained by volunteers. Although the company now has a large workforce of paid employees, an army of volunteers also still contribute to roughly 40% of its work, which includes not only the documentation but also coding tweaks (around 24% of all source code changes) and even the Firefox logo design. The help system was created through the SUMO technical writing program, which invited participants (a mixture of college students and technical writing professionals) to take part in each release cycle in order to produce the documentation. Although the program is not currently active, the participants and other volunteers still seem to be actively involved in maintaining the existing help articles.
Visually, I think the design and layout of the Mozilla Support homepage is really appealing, with all of the individual products and their logos mapped out in different sections. It just looks cool. The simple grey background, contrasting with the colourful designs of the Mozilla product icons and clearly marked out sections make it very easy to navigate. It was interesting to discover that some of the legacy of Mozilla’s design is down to an interface designer called Steven Garrity wrote an article listing everything that was wrong with Mozilla’s visual identity back in 2003 and was subsequently invited to their head office and asked to head up their new visual identity team which led a re-brand in 2004 when the now well-known Firefox logo, designed by Jon Hicks, was introduced.
The help is broken down into nine help topics, with multiple articles under each topic. The documentation itself is clearly laid out, although the screenshots are sometimes different sizes and formats (some fade into background, some do not etc.) and it is easy to spot where different technical writers have worked on the same article and used different styles to highlight sections of a screenshot. In the example below, you can see three different contributors’ work, with one opting for a crimson red rectangle to highlight ‘Desktop’, another using a orange-red circle and the third person using a brighter scarlet red oval:
Each page does actually list the authors of each article so it is possible to see how many people have contributed to each article. This particular article had eight contributors but other have even more, and unfortunately it shows:
In this article, which had 22 contributors, there were little issues like the screenshots being slightly different sizes. While it’s not the end of the world, the different styles of writing and formatting are pretty noticeable, even for someone without mild OCD, and it can look a bit messy and unprofessional. I guess it’s the kind of thing that’s forgivable when you’re using a free open-source browser but it could be easily remedied if Mozilla implemented a style guide for all contributing technical authors to ensure there is more uniformity with terminology, screenshots and how things are highlighted. Alternatively an editor could go through and make edits to clean things up where necessary.
One thing I was really pleased to see in the help was the occasional gif clip and a good number of tutorial videos which ensure the content is dynamic and semi-interactive for its readers. The videos, which have been produced by Mozilla senior UX designer Michael Verdi, are short and well edited so they are very watchable. He has a personal, informal style and friendly tone which is more engaging than a robotic Siri/Cortana-style narration.
At the top of each article, there is also a drop-down menu on the left-hand side which has some pretty useful features such as a link to any discussion items on the article’s topic, multiple language translations of the article, showing what other articles are linked to the article you are reading and seeing the history of who contributed and edited the article.
In terms of help and support, it has three main branches: Twitter, a support forum and help articles. Again, this is a great way for Mozilla to keep all of their bases covered. The other great thing people volunteer to assist with all three of those branches as well, with volunteer contributors on Twitter, volunteers answering questions on the support form and volunteers writing the help articles themselves. These volunteers are prompted to help by various Volunteer for Mozilla Support buttons, as shown in the screenshot below:
There is constant encouragement to get involved in things like the “Army of Awesome” (their Twitter helpers) and statistics about how help matters. For example, “1 Tweet can save 1 day” and “1 article can be viewed by 400 million users”. It just has a really positive, pro-active community feel about it.
Another common theme is the carton Firefox character, who is like a superhero-type figure, which appeals to everyone’s inner geek. It’s another simple but effective way to make the support pages fun and engaging.
I am really impressed with the content and support that is being produced by Mozilla, especially given the high percentage of work being done voluntarily. On top of the written content, they are also managing to offer video tutorial content and a Twitter help account which are further supported by a support forum. It would be useful to have a style guide or some kind of lead technical author/editor to iron out any issues with uniformity but overall I think Firefox’s support pages prove that open source projects can be reasonably well-documented through crowd-sourcing volunteer technical writers. I’m not sure this model of documentation would work for everyone but I think Mozilla have proved that volunteers can collaborate to produce an extensive help system, this clearly isn’t just a big work experience project.