Creating the new SUMO Knowledge Base: From zero to code

When we launched SUMO back in the days of Firefox 2, our TikiWiki based software was a great choice. But by the beginning of 2010 it became clear to us that we’d need something new to be able to keep up with our ever growing community of Firefox users, so we decided to write a completely new support system (named Kitsune) from scratch. Over the spring and summer we released new Contributor Forums, a new Search module and the support Questions App. The next major piece that we’ll release at the end of the month, is our new Knowledge Base.

Designing a new KB from scratch is not easy – especially when it’s a wiki that can be edited and localized by anyone – but you have to start somewhere. We started, way back in April, on a very basic level by defining the users of this new KB; who they are, their importance for us, their goals and the requirements that arise from those goals. Starting by defining our users like this allowed us to have a solid foundation for future decisions. Throughout the whole process we could always ask ourselves, “Does Pascal need this?” or “Would Ellen understand this?” We used these “personas” to build up the story of how we expected people to use the new KB.

Over the summer we worked together with our contributors and our extremely talented designer Chris Howse to take these stories and turn them into the blueprint for the new KB. We took quite some time to create storyboards and detailed mock-ups, so we could get a feel for the interaction of the site before our developers wrote a single line of code. This proved to be really useful and helped us to simplify site navigation and the process of finding solutions to problems. It also helped us to cut down on the necessary steps to edit and localize an article. Iterating over a workflow is much simpler when there are no lines of code involved ;)

Finally we turned to the SUMOdev team, lead by James Socol, to pour our ideas into code and to see what was possible in time for the Firefox 4 release. We wanted move our contributors to the new system so that they could use it to do the majority of the work for Firefox 4. It was clear that it wasn’t possible to implement every feature in the first version and after working through the priorities of the individual features, we agreed with James on a very tight development schedule. Amazingly, James and the rest of the team – Eric, Paul and Ricky – pulled it off and we are on track for our November 30th release. That’s rare in the software world, especially with completely new projects, where much of the stuff is written from scratch. Kudos, guys!

We’re really excited to see this finally come to fruition and next week I’ll post about some of the improvements and changes you can expect in the new KB.