Tag: Mozilla

May 5, 2014

Write the Docs: Ali Spivak – Communities are Awesome

I’m at Write the Docs today in Portland and will be post­ing notes from ses­sions through­out the day. These are all posted right after a talk fin­ishes so they’re rough around the edges.

Ali works at Mozilla. They rely on a huge community of volunteers to achieve their broader mission. Ali’s responsible for the Mozilla Developer Network, an open source wiki of documentation. The web is really big, it’s a lot to document. Mozilla is trying to document everything that’s important and relevant to developers as well as all of their products.

They have about 2 million users a month on MDN and about 11,000 articles. They’re constantly staying on top of evolving standards and spec changes. There are 5 people who try to wrangle all of that. The community helps greatly; it’s a fellowship of people who feel passionate about web standards and making the web a better place. It’s the community that let’s Mozilla punch above their weight class.

That community includes 600 contributors who have made at least one edit in the last month. When you expand that to one edit in the life of MDN it’s up to 5,000 contributors.

What do all these community members do? They write articles, they edit, they translate articles in to 35 different languages. They also speak at events and help build the underlying information architecture of the site. In some cases they even throw their own events and documentation sprints.

More importantly, what their community provides, a huge amount of diversity and differing perspectives. It’s hard to know what’s relevant to document for communities outside of those you’re familiar with. Contributors from those communities who are deeply embedded in the project help greatly. In some cases this means volunteers have taken on recruiting, event organizing, and really drive the community in areas Mozilla has less of an official staff presence. In India they’ve built up doc sprints and even documented guidelines for throwing events so that even more people in that local community can organize the community.

As Ali stated, “A strong community benefits the individual, the community, and the greater society.” Getting people started is sometime as easy as showing what they need to do to edit a document. MDN makes the barrier to this very low; they want those contributions. Volunteers don’t always realize that companies will trust them to make these edits. Sometimes all it takes is showing them. In some events they’ve been able to translate over 200 articles just by showing people how. That little nudge creates a large ripple effect.

When you entrust volunteers it adds to the sense of responsibility people feel toward the community, toward the content, and toward its improvement. Everything comes around this peer respect; your users are your peers and your collaborators.

But how do you get this army of “minions” to do what you want? You don’t. Community is not minions. It’s about partners in a journey; a special herd of awesome cats. You can provide direction but you cannot control. The responsibility is on providing opportunities to use their expertise in a way that’s meaningful for them. Intrinsic motivators are extremely powerful but they’re also autonomous. A lot of a volunteer’s motivation is in contributing their expertise to an audience much bigger than they could have alone. Making it as easy as possible to do that is crucial.

Ali also recommending reading Drive, by Daniel Pink, to greater understand people’s motivations and systems of volunteering. Those motivations come out in more than just open source tech projects. They’re a part of Burning Man, events everywhere, and communities all over the world.

Building a set of principles that define a community and define its culture is also key. That helps guide the volunteer participation. It’s not a method for control, but rather a system for guiding productive contributions. Building a culture where you ask everyone to participate relies on on collaboration. Mozilla has a foundation like this. It’s a set of principles that act as a contract with their community. It keeps them responsible and responsive to the community at large.

Just having those principles is not enough, though; they have to permeate everything that you do. You have to develop a roadmap and goals with your community, not for them. Make the volunteers an integral part of the process. If you can’t convince people that something is the right thing to do then maybe it isn’t the right thing to do for that community. If you create that transparent and trusting relationship your community will tell you when you’re not doing enough or when you’re taking things in a direction not relevant for the community.

Ultimately not everyone needs to build a community in the same way. What works for Mozilla may not work for you. You can focus on what you’re passionate about, though. Think about what opportunity you can provide for volunteers in your community. More importantly, what opportunity can they provide for you?

March 31, 2014

Write the Docs: Jannis Leidel – Search and find. How we made MDN discoverable

I’m at Write the Docs today in Budapest and will be post­ing notes from ses­sions through­out the day. These are all posted right after a talk fin­ishes so they’re rough around the edges.

Jannis is a developer working at Mozilla. He’s currently working on the Mozilla Developer Network, a site that covers the web platform, desktop app, Android, and Firefox OS efforts at Mozilla. There are 5.5 writers and 6 developers, as well as 14,000 community contributors, working on MDN and the site gets around 2 million unique visitors per month. With 900 live code demos and 33,000 wiki documents which have 375,000 edits in total there is a lot of content to deal with.

They now use kuma, a django-based wiki that’s available on GitHub. In the past, though, MDN ran on DevEdge, an AOL creation for static page sites. After a couple iterations they ended up writing their own software for documentation. That project became kuma. In 2013 they designed the site to bring a responsive layout with content zones that places search front and center.

Screen Shot 2014-03-31 at 2.40.27 PM

The emphasis on search, though, requires a powerful engine behind it. MDN has moved from a custom Google-based search to rolling their own implementation. It’s a full-text, multilingual search engine that provides faceting, filters, and pagination. The filters cover topics, skills, and document types. They can be dynamically changed based on what the Mozilla team sees in usage. Growth in certain areas allows them to emphasize different areas. It keeps the documentation responsive to the community’s demands and interest.

Each search page is also available as JSON. The users of MDN are developers themselves and this gives them the ability to use the data in formats other than MDN’s main site.

Another piece of MDN are the documentation status pages. This allows them to show the thousands of community editors and contributors what to work on first. It shows which pages need tags, editorial reviews, or technical reviews.

Firefox also ships with command-line access to MDN as part of their developer tools. From within the browser you can use the search API to pull up developer documentation. Users don’t have to leave to another site to find answers. In the future they want to extend this to plugins for popular code editors.

June 3, 2013

Checkboxes that kill. Great post about the dangers in complex, customizable settings. Two key takeaways: regularly audit how people are using your product and consider whether more than 2% of your users will use a setting.

April 9, 2013

Write the Docs: James Socol – UX and IA at Mozilla Support, and Helping 7.2 Million More People

I’m at Write the Docs today in Portland and will be post­ing notes from ses­sions through­out the day. These are all posted right after a talk fin­ishes so they’re rough around the edges.

James started things off after lunch. He works on support.mozilla.org and the Mozilla Developer Network.

James started talking with a short history of SUMO, which Michael talked a bit about yesterday. Through a series of redesigns they got to the design they now have. In that process they worked through solving the problems of earlier iterations.

When they tried solving this problem they lacked a good bit of data. What they did have, though, showed very low “helpful” scores on articles. They also had high exits from searches, re-searches, and high bounce rates.

One of the first things they did was have someone dedicated to the web side of support. They started with an heuristic evaluation and worked with a user experience expert on improving things. One thing they discovered in this was that if people got to the right article the helpfulness scores were very high. Outside of that, though, the scores tanked. They knew they had an information architecture problem.

They set out to analyze the current information architecture of the site. The first step was the manually look through the docs. They looked at what articles they had, where they were linked from, and the taxonomy that existed. To help with this they did a card sort, a means to guide users to generate a category tree.

With the map they had from the card sort they used Treejack and limited the user testing to just displaying the title of docs. The goal for users was then to say, “This is where I will find my answer.” With their current architecture of the time the success rates were as low as 1%. That’s bad. With that, though, they now had data. They had something they could work with and could optimize. What they found was interesting. Some articles were missing, some were badly named, and some had other issues.

Their user experience people had a few ideas. They proposed and tested a few solutions. This took their success rates in user tests up to highs of 92%. One task specifically went from a 1% success rate all the way up to 86%. With Treejack they were able to run all these tests by focusing just on the titles. It meant they could test quickly without having to rearrange or rewrite all of their docs.

At the end of things 10% more people were coming to the site and finding their answer. They tracked this by graphing the rate of “helpful” scores on documents. That 10% meant 7.25 million more people a year found the solution.

April 8, 2013

Write the Docs: Michael Verdi – How Mozilla supports users all over the world

I’m at Write the Docs today in Portland and will be post­ing notes from ses­sions through­out the day. These are all posted right after a talk fin­ishes 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.