Calendar:UI Ownership: Difference between revisions

Jump to navigation Jump to search

Calendar:UI Ownership (view source)

Revision as of 12:34, 5 July 2007

2,088 bytes removed ,  5 July 2007
no edit summary
No edit summary
Line 1: Line 1:
=== Issues To Address ===
=== UI Ownership ===
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:
UI decisions frequently require trade offs in favor of one usage pattern at the expense of another. We decided to have two ui-owners. The UI-owners have the responsibility to review UI-changes, and to come up with decisions which align to the overall product vision.


* Trying to reach consensus uses a tremendous amount of everyone's time and often can't be done.
=== UI Review ===
* We need to be able to iterate on UI relatively quickly so that we can get it in front of users for feedback.
UI-changes should have "ui-review+" signoff by either mvl or chris-j.
=== Stuff To Keep In Mind ===
The ui-review+ sign off will generally be based off of proposals or draft specifications submitted prior to actual patches.
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" [[Calendar:Development Strategies | here.]])
The "ui-review+" will serve as an indication that the proposal has high-level approval from the UI-owners


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.
To assure that reviews run smooth and promt mvl and chris-j advise contributers to add or reference to
=== 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 ===
* mock-ups
'''Q:''' Does this solve all of our UI problems?
* prototypes
* screen shots


'''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.
to their patches.


=== UI and Design Work ===


'''Q:''' The review process is known to be slow to respond to developer proposals.  Will this really let us move faster on UI-related questions?
UI and design work 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 jminta and others.
 
'''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 may well 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.


Larger changes should base on


'''Q:''' How do community members work with the owners towards the overall vision?
* user research & feedback
* align to realistic use cases which match to our two main target users


'''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:
and should conform to the overall product vision.
* user research & feedback
* understanding and defining use cases
* mockups
* prototypes
* experimenting with UI from other products
* discussion
Chris281
595

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/61220"

Navigation menu