Category Archives: Development

Check out mockups for the new Support Forums

The rewrite of the Firefox Support Forums is well underway. Chris Howse, UX designer for the Mozilla websites, has been working over the last couple weeks on making high-fidelity mockups to give us a taste of how the new forums will look and feel.

The first mockup shows how the questions and replies themselves will look. As you can see, users are now given the option to vote that they have a certain problem as well as vote on whether replies are helpful. To make sure that useful replies don’t get lost after other posts, they’re being summarized below the question. We’ve also moved stuff like System information to the sidebar, adding in tags and related questions to help improve navigation between forum questions. This way, if you’re looking for help with something, you can easily find similar threads if the one you’re looking at doesn’t help. Also, if you’re answering this thread, you may find that you also know the answer to a related question.

We’ll also color certain replies differently: The chosen solution is highlighted in green, posts by the original question-asker are blue and other threads are white.

The second mockup shows how the thread listing will look. To make it easier to browse the forum and find questions you can help with, we’ve added tags, the number of “I have this problem” votes and most importantly a short summary to this view. You’re also shown if you’ve contributed to the thread already and what its status is. We’ve kept the filter buttons at the top, letting you view common views (most recent, solved only etc).

Chris Howse has made many more detailed mockups showing various views and button states. You can check them all out in the following two bugs:

We hope you enjoyed this view into the future of the forums. What do you think? We’ll give another update as more development happens, so stay tuned.

SUMO platform roadmap for the rest of 2010: The timeline

Now that we’ve decided to develop a new platform for SUMO, let’s look at how it’ll be developed and how the transition will take place. Since SUMO consists of many components which can be developed one-by-one, Kitsune will be implemented in a series of releases rather than all at once. As each component is developed, it will replace the current SUMO code and we’ll essentially have a hybrid system until the transition is complete.

So what comes first and when does it happen?

  • SUMO 2.0 – Search results: April 2010.
  • SUMO 2.1 – Contributors forum and the Off-topic forum: May 2010.
    These are general discussion forums, and the goal is to move off of TikiWiki code while retaining functionality.
  • SUMO 2.2 – Support forum: June 2010.
    The Support forum has many features specifically designed for providing software support and is coded separately. Part of this goal is to redesign the support forum to make it easier for users to find answers without cluttering the forum with “me too” posts. Another part is to make it easier for community members to get involved and become contributors. If you are a regular reader of this blog, you know that the work has already begun on the redesign. For more information, see the PRD, and the previous blog posts.
  • SUMO 2.3 – Wiki: Summer and Autumn 2010.
    The wiki is what is used for the Knowledge Base, and other documentation (including localization). This is the most complex component and therefore we expect it to require the most time. We’ll also be taking this opportunity to redesign the KB as well, So for the next three months we will start working with the community to draft the details. More information about that process will be posted soon.
  • SUMO 2.4 – User management: Winter 2010.
    This last component covers items like login, log out, and preferences. For technical reasons, all other components need be done before this can be transitioned.

Once that last user management piece is in place, we will be fully transitioned to Kitsune. Any bugs found in the new code will likely need to wait (unless they’re severe) until the entire transition is finished before being addressed.

SUMO platform roadmap for the rest of 2010: Milestones and priorities

Last month, we blogged about the upcoming SUMO platform that will make SUMO much more enjoyable to use for users, contributors, and developers. Of course, SUMO 2.0 (codenamed Kitsune) can’t be written over night — it’s quite an undertaking to be honest — but it’s important that we do this as soon as possible.

Since development resources are limited and a project like this requires that we scrutinize our priorities, we’d like to make it clear that we will devote as much time as possible to Kitsune development. As a result, any work on the previous (Tiki) code will strictly be for maintenance purposes: unless a bug in the previous code simply must be fixed as soon as possible, it will likely not be worked on.

We will be making some changes to the SUMO milestones:

  • The SUMO 1.6 milestone is going be canceled. Any current 1.6 bugs will be moved to “Future”, but we will go through that list of bugs to make sure urgent bugs are fixed soon.
  • Any future maintenance releases to the current code will be updates to SUMO 1.5.x (1.5.3, 1.5.4, etc.).
  • All new Kitsune work is being targeted for SUMO 2.0 and newer versions.

This is going to require some patience from all of us who are waiting for a certain feature or a minor bug to be fixed. Most, if not all of those concerns can be fixed in Kitsune, and the sooner we switch to it, the sooner we will have a much faster and more reliable support platform.

We will blog more about the roadmap for Kitsune soon.

Another Forum redesign mockup

Based on some feedback to the last design, we’ve come up with an alternative concept for the forum redesign. While it has many of the same features as the last one (users will still be able to vote on individual posts in a thread as well as have a button to say “I have this issue too” ), there are a few changes:

  • There are no longer two distinct areas for discussion vs solutions. Instead there is a chronological order of posts. (Like a traditional forum.)
  • The most useful post in a thread will be highlighted rather than shifted to the top to prevent breaking up discussions.
  • Posts by the original thread author will also be highlighted.

You can see these in the mockup below:

Here’s the rationale for these changes: When we looked at a sampling of solved threads, we found that the vast majority (30-to-1) were solved in one or two replies. This seemed to suggest that the benefit of bubbling up the top solutions was small since there weren’t many solutions for forum users to sort through. On the other hand, a chronological ordering would simplify the user interface and may promote discussion and community building between contributors.

Please give us your feedback on this design/mockup. What additional features would you like to see, what would you like to see done differently?

The mockup also shows a three-tiered voting system for posts with “this was helpful”, “this was helpful but didn’t fix my problem” and “this wasn’t helpful”. Please let us know what you think of it.

Redesigning the support forum

With the rewrite of the SUMO platform underway, this is a great time to rethink how we want to handle our support forum.  While the existing forum format is good for promoting discussions and interaction, it isn’t optimized for getting users to the answers to their problems.  Also, anyone who has been helping users in our forum know that it’s not exactly the fastest forum in the world…

A number of websites that have been set up specifically with the goal of answering questions actually don’t use the traditional forum format.  For example, Yahoo! Answers, Get Satisfaction and Stack Overflow all use a more problem-solution based approach. We’d like to take cues and ideas from these sites and redesign the way users and contributors interact on our support forums to make it more fun and engaging to help users.

We’ve started to draft up how this redesigned support forum would look and would like your input on how to make the final support forum best fit your needs as contributors as well as those of our users. Note that we are talking about the English Support forum on SUMO here — it will not apply to the Contributors or Off-topic forums, which have different needs.

Our proposal
The key objectives of this redesign are:

  • To make it easier for users to identify the solution to their problem.
  • To make it easier for contributors to focus on the questions that matter to them — for example, only questions asked by Linux users.
  • To make the forum much faster and more enjoyable to use.

The key element to the new design will be the ability for a user to vote up (or “me too”) threads which adds him to the notification list.  If a user sees a problem description that matches his own, he can vote it up, thereby giving it more attention and increasing the chances of good solutions.  We can then make sure that these questions are shown more prominently in the thread listing.

Answers to questions can also be voted on — not just by the original asker, but by everyone.  That way, the best solution for the majority of people will bubble up to the top.

Lastly, we want to provide an area of the page to get followup information from the original person with the question.  Asking for more information is a key part of the troubleshooting process, but it’s important that the information is readily available near the original question, and not buried somewhere in a lengthy discussion thread.

We’ve put together a rough mockup of how this may look to give you a better sense of what these mean.  Once we’ve finalized on the list of features, we’ll be redrafting it to actually look good, too. :)

Small-sized mockup

What do you think?  What kinds of features do you think are necessary in this kind of new support system?  We’ve got ideas like tagging, custom dashboards, as well as savable views.  However, we’d love to hear your thoughts and ideas to make sure we aren’t missing something here.

So, if you have feedback, please let us know.  You can edit the PRD or just comment in this blog.  Thanks!

The Evolution of SUMO

(Guest post by James Socol of the webdev team. Comments or questions? Head on over to James’ original blog post and comment there!)

When I joined the SUMO team six months ago, the team was just starting a discussion of “where do we go from here?”  SUMO was built on a CMS called TikiWiki, and had diverged pretty significantly in two years. (David Tenser wrote a more detailed history if you’re interested.)

After a few months of talking and testing—and a few changes of direction—we’ve decided that SUMO will follow our colleagues on AMO and move to a custom web application, built on Django, a development framework in Python.

Why are we committing to such a dramatic new direction? Three major reasons. Keep in mind that SUMO was built on TikiWiki 1.10, a little more than two years out of date.


TikiWiki is a very feature-rich application. An unfortunate trade-off for us is performance, especially on a site serving 16 million users every week. As our European users in particular know, SUMO can be unacceptably slow at times, especially when editing articles. Many of the changes we made to the platform—most of which were contributed back over the past few months—were to improve performance via tools like output caching, database replication, and just refactoring. When we evaluated the latest version of TikiWiki, we found that performance was around the same, on average.

In the new platform, we’ll be taking advantage of techniques now available, including query and template/fragment caching and expect to see dramatic performance improvements. We’ll also be avoiding some of the performance pitfalls that TikiWiki fell into over the years with improvements to the security, database, and templating layers, among others.

But the biggest performance impact—I expect—will be moving from a general-purpose CMS to a dedicated web application, focused on providing the SUMO experience.


To work on SUMO, you have to overcome a steep learning curve. Components tend to be tightly-coupled, or grouped in unintuitive ways, and are not as extensible as we’d like. The lack of a comprehensive test suite leaves changes to important sections of code open to introducing regressions in otherwise unrelated, dependent areas. SUMO 1.x also fails to function without a relatively complete copy of its database, which makes it difficult for community members outside the company to contribute.

With the new platform, and some discipline from the team, our goal is to improve all of these and make it easier for someone to get started hacking on SUMO.

  • We’ll be striving to keep code loosely-coupled and extensible—including using existing or external libraries whenever possible, and turning our own contributions into external libraries where possible.
  • We’re adopting a test-driven development workflow to ensure that our components are easier to safely hack, and lighten the load on our QA team by reducing regressions.
  • TDD and Django will make it easier to work without a copy of the database, using fixtures and migrations to minimize the dependence on real data.

The net effect of these decisions will be to lower the barrier to entry to SUMO development, and hopefully make useful code available to other projects. Wil Clouser listed more strengths of Django as a platform when the AMO team decided to switch.

Strength in Numbers

By using the same platform as AMO, both teams will benefit from sharing code and resources. We’re already using the same template adapter, database router, caching layer, and HTML sanitizer. As open source developers often say: “with enough eyes, all bugs are shallow,” and by sharing code we get more eyes on it. We’ll benefit from insights the AMO team has gleaned by starting the process of moving from a PHP framework to Python just ahead of us. We’ll even be able to send code reviews across teams and benefit from deeper knowledge of the various problem domains we share: have a question about localization? Both teams can share expertise and best-practices.

Solving problems once and sharing the solution directly reduces the amount of work both teams have to do. And when SUMO writes code in such a way that AMO can use it, we can also release it separately so others can benefit from our solutions—and point out flaws and contribute improvements.

Other Changes

Also among the changes coming in the next year:

  • Version Control System. Though we don’t have a specific plan in place, it seems likely that SUMO will be moving from SVN to Git for source control. Because Git is distributed, it allows us to use a more collaborative workflow, and it’s easier for us to push our code to public repositories like Github.
  • Continuous Integration. We’ll be using Hudson for continuous integration, which will automate our tests and alert us to potential issues and regressions. The web QA team has also been working to make sure our Selenium tests can run through Hudson, greatly increasing test coverage for a web application like SUMO.
  • Interface Localization. One of the ways we plan to improve the SUMO experience this year is by moving our interface localization to gettext, which is an industry-standard tool for localization. As we move parts of the site from TikiWiki to Django, those new sections will be localized via gettext, which helps us take advantage of our great community with tools like Verbatim.

A Foundation for the Future

The goal of all of this work—and it will be a lot of work—is to put SUMO on a solid foundation for future growth and, at the same time, improve the experience for everyone—from developers to contributors to localizers to visitors. We have a daunting and aggressive road ahead of us, but I’m confident that we’ll emerge in a better place.

SUMO 2 is codenamed Kitsune, and is already up on Github.

Comments or questions? Head on over to James’ original blog post and comment there!

The bright future of the SUMO platform

When the SUMO project started back in 2007, one of the first big questions was what web platform to use as a foundation for the upcoming Firefox support website. The Mozilla web development team started by doing a thorough analysis of the available content management systems (CMS) currently available in order to reach a conclusion. The outcome of that analysis was that TikiWiki was most suitable for our needs. Among other reasons, Tiki was best because of its many bundled features, strong multilingual features and powerful wiki and forum integration.

What followed was some rapid development to get Tiki deployed on our server and adapted to our needs. We received great help from the Tiki community, ensuring that the initial launch of Firefox Support was smooth and successful. Unfortunately, we didn’t really have a plan for how to ensure we remain synchronized with the continuous development of the Tiki platform upstream, so we just kept developing on our local codebase.

Because Firefox is such a popular web browser, we get a lot of visitors on the Firefox Support website. And when we say a lot of visitors, we mean a lot: over 16 million page views per week! is in the top 150 sites in the world, and SUMO naturally gets a good portion of the traffic.

As a result, a significant part of our development focus has been on increasing performance. About two years after the site officially launched, September 2009, we had reached a point where we would be forced to rewrite parts of the underlying infrastructure of Tiki in order to keep up with the increasing traffic to the site.

We had reached a crossroad when we had to decide on what do with the SUMO platform:

  • Should we upgrade to the latest version of Tiki? Remember, we had over two years of local development that hadn’t been upstreamed.
  • Should we continue to patch the Tiki platform locally, i.e. continue with what was essentially a fork of Tiki?
  • Or should we switch to another platform that was better suited to our particular needs?

Abort, Retry, Fail?

Interestingly, in our second analysis of the available platforms in 2009, Tiki still came out as the winner! There simply is no existing CMS that is more suitable for us.

However, that doesn’t change the fact that Tiki is not entirely optimized for our needs. In order to change this, we would have to invest a huge amount of time to rewrite structures and code in Tiki relevant to SUMO, and we would have to take great care to not mess up with all the thousands of other Tiki-powered websites out there.

This led us to the realization that the right path for SUMO is neither of the above options, but to instead do a clean break and work together with the AMO team to develop something new that is optimized exactly for our specific needs: an excellent open source support platform that can handle over 350 million Firefox users.

TikiWiki really is a fantastic CMS — the fact that it still is the best fit for Mozilla among the options available is amazing.

Now our challenge is to build the next generation of the SUMO platform: SUMO 2.0, codenamed Kitsune. More on that soon!

Weekly SUMO development team meeting moved

The SUMO development team meeting (also known as the SUMOdev meeting) has been moved from Tuesdays at 9 am Pacific to Mondays at the same time. This is because one of our developers, paulc, is taking a course this quarter that conflicts with the regular meeting time. Since we’re a small team, we can’t just go on with one third of the team missing from these meetings, so we decided to move it. At the end of this quarter, we will move it back to Tuesdays again.

The new time is Mondays 9 am Pacific.

For those who aren’t familiar with these meetings, the SUMOdev meeting is an opportunity to get a glimpse of the hard work we do “behind the scene” with SUMO. Most of the time, the meetings are about prioritizing and assigning tasks (think “bugs”) to developers, but occasionally we discuss more high-level things like setting goals, defining roadmaps, and brainstorming new features. Even if you’re not a developer, you’re more than welcome to listen in.

Forum survey results

A month ago, we asked you to fill out a survey regarding the improvements to the SUMO forums that we made in the 1.4 – 1.4.2 releases. Overall, the features we pushed were very well received.

Among what people said were their favorite features: the new bar that allows you quickly filter the forum threads and the new detailed ask a question form.

We also got some great suggestions, including: “Bring back the forum’s version of the Top 10 list”, “Word filters” and letting anonymous posters mark threads as solved without having to go via email. We’ll be looking to make sure features like this are implemented as we consider a forum redesign in 2010.

We also asked you to rank some of the major new features on a 1-5 scale:
(Note that we only got 7 responses so these numbers aren’t that statistically useful but it’s good to know that what we do is well-liked.)

How have each of the changes below affected how you use the forums? (1 = a lot worse, 5 = a lot better).

Feature score
Ability to log in while posting a response 5.0
New question form 4.7
Collecting the full useragent 4.7
Thread list has a link to the last post 4.6
Ability to link directly to a post with the # 4.6
Short URLs 4.2
Ability to filter forum list 4.1
Ability to sort forum list 4.0
RSS feed 3.8

Thanks a bunch for filling out the survey.

SUMO 1.5: Even better searching

Last Thursday, we released SUMO 1.5 which implements a significant upgrade to our site search engine.

In addition to having a much more powerful back-end search where we can now index the full database every 15 minutes rather than once a day, we’ve added a bunch of new search options and features available through an advanced search interface.

There are two tabs available in the advanced search interface:

The Knowledge Base tab has options specific to the knowledge base such as language and category and tags. While the default search only looks for articles in the KB category, the advanced search also allows you to find articles that are in the staging area or are awaiting approval.

KB advanced search

The Forum tab has options to search unsolved forum threads or various other statuses in addition to the solved-only threads available in the default. You can also search for threads with posts by a given author or threads created or updated in certain time ranges. This lets you quickly get back to specific threads where you’ve posted or look for recent threads with given keywords.

SUMO 1.5 had a total of 70 bugs fixed. Congrats and thanks to the entire SUMO developer team and the webQA team for pushing this great release!