Calendar:UI Ownership

Issues To Address

Until now, we've had a very informal UI process that served us well up to a point, but now that more people are involved, it has not scaled. Problems that especially need to be dealt with include:

• Trying to reach consensus uses a tremendous amount of everyone's time and often can't be done.
• We need to be able to iterate on UI relatively quickly so that we can get it in front of users for feedback.

Stuff To Keep In Mind

Some things that we've learned over the years from UI work on various Mozilla projects include:

• No matter what UI process is chosen, UI decisions frequently require tradeoffs in favor of one usage pattern at the expense of another. As a result, everyone has their own list of UI decisions that they feel were made incorrectly.
• Avoiding designed-by-committee feel requires a very small group of UI owners.

High-level Ownership

Taking the above into account, we believe that since the project owners are responsible for the overall project vision, it makes sense to have them responsible, at a high level, for the UI as well. This will help ensure that vision and UI implementation stay in sync.

This means that UI changes should have ui-review+ signoff by either mvl or dmose. This ui-review+ signoff will generally be based off of proposals submitted prior to actual patches being written and will serve as an indication that the proposal has high-level approval from the UI-owners. (See Step 1 of "Basic Bug/Feature Workflow" here.)

In the future, it may make sense to give more people the ability to sign off on UI patches as our group vision becomes more coherent and better articulated.

UI and Design Work

Given expertise and bandwith constraints, the majority of the UI and design work still needs to happen in the community at large; the owners are simply where the buck stops when we need to make a decision for the current upcoming release and move on to implementation. We hope to lean heavily on the advice, suggestions, and work of key people who have exhibited strong design skills in the past, such as chris-j and jminta.

Questions & Answers

Q: Does this solve all of our UI problems?

A: It allows us to move forward with existing UI work that the owners feel doesn't need to wait for product definition, roadmap issues, and user research to be further along. This includes several UI discussions currently on the table.

Q: The review process is known to slow to respond to developer proposals. Will this really let us move faster on UI-related questions?

A: This process ought to help decrease the time necessary to make certain UI-related changes. However, it is not a perfect solution and further iterations will likely be necessary.

Q: What about product definition, the roadmap, and user research?

Q: What's the process for getting UI design of new features done?

A: Another document addressing these issues will be forthcoming.

Q: How do community members work with the owners towards the overall vision?

A: This will be addressed in more detail in the above-mentioned document. That said, design work is likely to include a combination of these things:

• user research & feedback
• understanding and defining use cases
• mockups
• prototypes
• experimenting with UI from other products
• discussion

Q: Given that mvl hasn't been around much lately, can this really work?

A: mvl has recently changed jobs and moved. We believe that once his phone and Internet service are installed (hopefully in the next few weeks), he will once again have sufficient bandwidth. If that turns out not to be the case, we will re-evaluate the situation.