Support/SUMOdev Redesign2012

From MozillaWiki
Jump to: navigation, search

Master Plan: Redesign 2012

This master plan is in draft and will be fleshed out over the course of the project. The purpose of this document is NOT to require that everything be planned out ahead of time. The purpose is to codify everything we're figuring out as we go along and also to give us a structured way to get a 50' view of the project, its scope and what's involved so as to find problems BEFORE we hit them.


This redesign couples a visual refresh of the SUMO site with structural changes suggested by the IA work.

People involved:

  • Bram: UI/UX
  • Ricky, Rehan, Mike, Will: Dev team
  • Maintainer of this document Rehan, Ricky
  • Kadir: go-to person for questions

Deadline: 2012 Q3

Additional conditions:

  • When breaking up the work into tasks, each task must be atomic in the sense that we'll be rolling out visual refresh changes incrementally and any given time, the site must be functional and usable.
  • When work is done on a visual refresh task, we'll need to be able to show the results of that work to all the stake-holders so that we can talk about it and recommend tweaks.


The following is a list of terms and definitions for terms that are either new or changing definition because of this redesign:

List of source documents

Here is a list of urls to source documents that the master plan is based on (e.g. wireframes, mock-ups, forum threads, bugs, ...):

Items that are source documents, but are obsoleted should be crossed out and stay in the list.

Use cases

Some ui changes involve use cases that have actors with tasks they're trying to accomplish and how they accomplish them. As we come up with those, it helps to write them down here because that helps us figure out the requirements.


This is the list of requirements and anti-requirements. Each requirement should be a single well-formed sentence. It helps to put it in an outline showing hierarchical groups. Requirements that can be tied back to a source document should have a link to the source document.

The goal of this section is to establish the requirements which are a fleshing out of yes/no/measurable statements derived from source documents and use cases.

Figuring out the requirements first makes it much easier to figure out an appropriate implementation. Figuring out the requirements after implementing typically costs 10x more development time than it would have figuring it out first.

Anything that needs to be tested should have a corresponding testable requirement.

Breakdown of work

The list of tasks, subtasks and bugs for work that needs to be done to satisfy one or more requirements above.


Outstanding issues

Each issue should include a well-formed question that can be answered---that's the outstanding issue. If it's helpful, include the context for the question. Each outstanding issue should be a paragraph.

Solved issues

Once an outstanding issue has been solved, it gets moved here and the solution is codified alongside it.