Diff for "UI/Reviews"

Not logged in - Log In / Register
Differences between revisions 4 and 18 (spanning 14 versions)
⇤ ← Revision 4 as of 2009-07-28 12:53:27 →
Size: 2275
Editor: beuno
Comment:
← Revision 18 as of 2009-09-01 20:21:16 → ⇥
Size: 4761
Editor: beuno
Comment: page was renamed from UserInterfaceReviewNotes
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from UserInterfaceReviewNotes
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 3: Line 6:
For a detailed process for UI changes (link to Curtis' suggestion... can't find it on the wiki yet.) = UI review process =

Currently one of the following is required to land a branch with UI changes:
 * a ui review by a graduated ui reviewer.
 * two ui reviews by ungraduated ui reviewers (marked with an asterisk below).

For a detailed process for 3.0 UI changes: [[VersionThreeDotO/UI/Conversion]]

== 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)
Line 6: Line 26:
== Identify the page purpose(s) ==

The purpose of the page, target audience and primary user stories will help guide all your work. If possible, document these on the wiki so that other people who work on the page at a later date can easily understand the purpose of the page. You can use the [[SoyuzPPAIndexPage|PPA index page documentation]] as a template.
Line 9: Line 32:
 1. Is there any other page in Launchpad that does something similar?
 2. Will this add any value to users?		  1. Is the page necessary? Or is it small enough to be an expandable section of another page?
 2. Is there any other page in Launchpad that does something similar?
 3. What value will this add to users?
Line 12: Line 36:
 4...
 5...		  4. How would you "tweet" this change? (i.e. describe in 140 characters)?
 5. Are there any other pages that should change their behavior/look with this change?
Line 24: Line 48:
Line 28: Line 53:
 1. What value does this add to users?
 2. Will this make it harder to complete any tasks?
 3. Will this make it easier to complete any tasks?
 4. Does this behave differently than other pages in Launchpad?
 5. Does completing the task require prior knowledge? Is that knowledge available as help?
 6...
 7...
 8...
 9...
 10...		  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?
Line 39: Line 64:
== Create a screenshot or screencast ==
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).		 == Check your choice of words ==
Line 42: Line 66:
If your UI change involves a behaviour, consider creating a brief screen-cast using gtkRecordMyDesktop and attaching it to the bug. Again, this will again help the reviewer and other interested people from commenting without having to merge your branch. Check through the [[UserInterfaceWording|User interface wording guidelines]] to ensure that you are using the recommended wording and capitalization etc.
Line 44: Line 68:
== Check your template code ==
Line 45: Line 70:
= Tips for reviewers = Review the [[PageTemplateHacking|quick checklist for template code]] to ensure that your template code is consistent and therefore more maintainable.

== 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 ==

Contents

  1. UI review process
    1. Current UI reviewers
  2. Starting your UI branch
    1. Identify the page purpose(s)
    2. 10 questions to ask yourself before starting a branch
    3. What is this page trying to tell me
  3. Submitting your branch for review
    1. 10 questions to ask yourself before submitting
    2. Check your choice of words
    3. Check your template code
    4. Make it easy to demonstrate your UI
  4. UI-reviewing a branch
    1. Tips for reviewers

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

UI review process

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

  • a ui review by a graduated ui reviewer.
  • two ui reviews by ungraduated ui reviewers (marked with an asterisk below).

For a detailed process for 3.0 UI changes: VersionThreeDotO/UI/Conversion

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)

Starting your UI branch

Identify the page purpose(s)

The purpose of the page, target audience and primary user stories will help guide all your work. If possible, document these on the wiki so that other people who work on the page at a later date can easily understand the purpose of the page. You can use the PPA index page documentation as a template.

10 questions to ask yourself before starting a branch

  1. Is the page necessary? Or is it small enough to be an expandable section of another page?
  2. Is there any other page in Launchpad that does something similar?
  3. What value will this add to users?
  4. Will this make it harder for other users to complete tasks?
  5. How would you "tweet" this change? (i.e. describe in 140 characters)?
  6. Are there any other pages that should change their behavior/look with this change? 6... 7... 8... 9... 10...

What is this page trying to tell me

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... and there might be small improvements outside the scope of your bug that will make a huge difference to the user experience. (Maris' to add notes)

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.

Check your template code

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

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.

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