Support/SUMOdev Redesign2012
Contents
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.
Overview
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.
Definitions
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.
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.
https://en.wikipedia.org/wiki/Requirement#Characteristics_of_good_requirements
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.
Issues
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.
