Diff for "UI/Reviews"

Not logged in - Log In / Register

Differences between revisions 1 and 29 (spanning 28 versions)
Revision 1 as of 2009-07-13 08:45:56
Size: 652
Comment:
Revision 29 as of 2010-02-19 20:37:48
Size: 4681
Editor: flacoste
Comment: Moved the pre-coding content to UserInterfaceDesign page
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
These guidelines are to help all of us make UI reviews as straight-forward as possible. ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 3: Line 3:
= What is this page trying to tell me =  * '''Name:''' UI Review
 * '''Owner:''' Launchpad Team
 * '''Effective:''' Summer of 2009
Line 5: Line 7:
Although it may be out of the scope of the current branch that you are working on, it is always worthwhile getting the big-picture... = UI review process =
Line 7: Line 9:
= Create a screenshot =
The UI review process will be much faster if the reviewer can view your change without having to merge and run your branch. Sometimes this can be as simple as attaching screenshots to the bug (this also allows other interested people to comment).
These guidelines are to help all of us make UI reviews as
straight-forward as possible.
Line 10: Line 12:
If your UI change involves a behaviour, consider creating a brief screen-cast using gtkRecordMyDesktop. Currently one of the following is required to land a branch with UI
changes:

  * a ui review by a graduated ui reviewer or a member of the Canonical
  DUX team.
  * two ui reviews by ungraduated ui reviewers (marked with an
  asterisk below).

== Current UI reviewers ==

 * Martin Albisetti (beuno)
 * Maris Fogels* (mars)
 * Paul Hummer* (rockstar)
 * Michael Nelson (noodles)
 * Edwin Grubbs* (EdwinGrubbs)
 * Tom Berger* (intellectronica)
 * Curtis Hovey* (sinzui)
 * Barry Warsaw* (barry)
 * Matthew Revell* (mrevell)
 * Jonathan Lange* (jml)

== Reminder: Before starting a UI change ==

 1. Consult the ReadyToCode checklist.
 2. If necessary create a LaunchpadEnhancementProposalProcess to
 clarify the feature scope.
 3. Create and discuss the [[UI/Design|mockups]].

== Submitting your branch for review ==

=== 10 questions to ask yourself before submitting ===

  1. Is the <title> appropriate and context-sensitive? If the page is
  the Overview of an independent entity (e.g. a person or a package), does
  the <title> end with "in Launchpad"? (copied from mpt's old notes - do
  we still do do this?)
  2. After finishing with the page, is there anywhere you'll very likely
  want to go next? Is that destination linked to?
  3. Will your changes make it easier to complete the page's defined
  tasks?
  4. Does this behave differently than other pages in Launchpad? Why are
  those exceptions there?
  5. Imagine you're in the target audience for the page, but you've
  never seen it before. Reading it, would you understand what's going on?
  Does it need embedded help?
  6. How many more knobs and buttons have I added?
  7. In any form, what happens if you skip a compulsory field? What
  happens if you enter disallowed characters? What happens if you enter
  200 KB of text?
  8. What can I do to make it explaining it easier, or even unnecessary?
  9. Is it fun to use?
  10. Does the page look elegant and well-balanced?

=== Check your choice of words ===

Check through the [[UserInterfaceWording|User interface wording guidelines]]
to ensure that you are using the recommended wording and capitalization
etc.

=== Did you consider in-line help? ===

We all agree that the user interface should be self-explanatory but
there are some terms and concepts that will not be familiar to everyone
using Launchpad. If you feel there's room for confusion, you should
either:

  * use [[PopUpHelp|pop-up help]] to explain a term, concept or short
  process
  * or link to the relevant page on the
  [[https://help.launchpad.net|help wiki]] to explain a more involved
  process or workflow.

=== Check your template code ===

Review the [[PageTemplateHacking|quick checklist for template code]] to
ensure that your template code is consistent and therefore more
maintainable.

=== Check your URLs ===

Have you added or changed any URLs in this branch? If so, look at our
[[UI/UrlStyleGuide|URL Style Guide]].

=== Make it easy to demonstrate your UI ===

If it is difficult to setup the sample data required to demonstrate your
changes, consider pasting a harness script that can be used by the
reviewer to setup the relevant data.

It is always worth creating a single before/after screenshot and
attaching it to the bug - this allows those people following the bug to
provide input too. Or if your change involves some behavioral changes,
consider creating a brief screen-cast using gtkRecordMyDesktop and
attaching it to the bug. Again, other interested people to comment on
your UI without having to merge your branch.

== UI-reviewing a branch ==

=== Tips for reviewers ===

  1. '''Don't read the merge proposal'''. Branch, fire up the page(s)
  that where changed, and write down your initial impressions. Sometimes a
  change causes other parts of the page to look out of place, so knowing
  what to look at may make you miss that.
  2. '''Make mistakes'''. When going through a work flow, make as many
  mistakes on purpose. This will help you feel what a frustration scenario
  would look like.
  3. '''What's the transition story?''' When we make significant
  changes to existing UI, or add new things, what's the transition story
  for people who just see that pop up one day?

  • Name: UI Review

  • Owner: Launchpad Team

  • Effective: Summer of 2009

UI review process

These guidelines are to help all of us make UI reviews as straight-forward as possible.

Currently one of the following is required to land a branch with UI changes:

  • a ui review by a graduated ui reviewer or a member of the Canonical DUX team.
  • two ui reviews by ungraduated ui reviewers (marked with an asterisk below).

Current UI reviewers

  • Martin Albisetti (beuno)
  • Maris Fogels* (mars)
  • Paul Hummer* (rockstar)
  • Michael Nelson (noodles)
  • Edwin Grubbs* (EdwinGrubbs)

  • Tom Berger* (intellectronica)
  • Curtis Hovey* (sinzui)
  • Barry Warsaw* (barry)
  • Matthew Revell* (mrevell)
  • Jonathan Lange* (jml)

Reminder: Before starting a UI change

  1. Consult the ReadyToCode checklist.

  2. If necessary create a LaunchpadEnhancementProposalProcess to clarify the feature scope.

  3. Create and discuss the mockups.

Submitting your branch for review

10 questions to ask yourself before submitting

  1. Is the <title> appropriate and context-sensitive? If the page is the Overview of an independent entity (e.g. a person or a package), does the <title> end with "in Launchpad"? (copied from mpt's old notes - do we still do do this?)

  2. After finishing with the page, is there anywhere you'll very likely want to go next? Is that destination linked to?
  3. Will your changes make it easier to complete the page's defined tasks?
  4. Does this behave differently than other pages in Launchpad? Why are those exceptions there?
  5. Imagine you're in the target audience for the page, but you've never seen it before. Reading it, would you understand what's going on? Does it need embedded help?
  6. How many more knobs and buttons have I added?
  7. In any form, what happens if you skip a compulsory field? What happens if you enter disallowed characters? What happens if you enter 200 KB of text?
  8. What can I do to make it explaining it easier, or even unnecessary?
  9. Is it fun to use?
  10. Does the page look elegant and well-balanced?

Check your choice of words

Check through the User interface wording guidelines to ensure that you are using the recommended wording and capitalization etc.

Did you consider in-line help?

We all agree that the user interface should be self-explanatory but there are some terms and concepts that will not be familiar to everyone using Launchpad. If you feel there's room for confusion, you should either:

  • use pop-up help to explain a term, concept or short process

  • or link to the relevant page on the

    help wiki to explain a more involved process or workflow.

Check your template code

Review the quick checklist for template code to ensure that your template code is consistent and therefore more maintainable.

Check your URLs

Have you added or changed any URLs in this branch? If so, look at our URL Style Guide.

Make it easy to demonstrate your UI

If it is difficult to setup the sample data required to demonstrate your changes, consider pasting a harness script that can be used by the reviewer to setup the relevant data.

It is always worth creating a single before/after screenshot and attaching it to the bug - this allows those people following the bug to provide input too. Or if your change involves some behavioral changes, consider creating a brief screen-cast using gtkRecordMyDesktop and attaching it to the bug. Again, other interested people to comment on your UI without having to merge your branch.

UI-reviewing a branch

Tips for reviewers

  1. Don't read the merge proposal. Branch, fire up the page(s) that where changed, and write down your initial impressions. Sometimes a change causes other parts of the page to look out of place, so knowing what to look at may make you miss that.

  2. Make mistakes. When going through a work flow, make as many mistakes on purpose. This will help you feel what a frustration scenario would look like.

  3. What's the transition story? When we make significant changes to existing UI, or add new things, what's the transition story for people who just see that pop up one day?

UI/Reviews (last edited 2010-09-14 10:25:21 by gmb)