Diff for "UI/Reviews"

Not logged in - Log In / Register

Differences between revisions 26 and 36 (spanning 10 versions)
Revision 26 as of 2009-10-08 15:31:50
Size: 5554
Editor: jml
Comment:
Revision 36 as of 2010-09-14 10:25:21
Size: 5759
Editor: gmb
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from UserInterfaceReviewNotes
Line 4: Line 3:
These guidelines are to help all of us make UI reviews as straight-forward as possible.  * '''Name:''' UI Review
 * '''Owner:''' Launchpad Team
 * '''Effective:''' Summer of 2009
Line 8: Line 9:
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).
These guidelines are to help all of us make UI reviews as
straight-forward as possible.
Line 12: Line 12:
For a detailed process for 3.0 UI changes: [[VersionThreeDotO/UI/Conversion]] 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).
Line 16: Line 22:
 * Martin Albisetti (beuno)
* Maris Fogels (mars)
 * Paul Hummer (rockstar)
 * Maris Fogels* (mars)
 * Paul Hummer* (rockstar)
Line 20: Line 25:
 * Edwin Grubbs (EdwinGrubbs)
 * Tom Berger (intellectronica)
 * Edwin Grubbs* (EdwinGrubbs)
Line 23: Line 27:
 * Barry Warsaw (barry)
* Matthew Revell (mrevell)
 * Jonathan Lange (jml)
 * Matthew Revell* (mrevell)
Line 27: Line 29:
= Starting your UI branch =
== Identify the page purpose(s) ==
== Reminder: Before starting a UI change ==
Line 30: Line 31:
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.  1. Consult the ReadyToCode checklist.
 2. If necessary create a LaunchpadEnhancementProposalProcess to
 clarify the feature scope.
 3. Create and discuss the [[UI/Design|mockups]].
Line 32: Line 36:
== 10 questions to ask yourself before starting a branch == == Submitting your branch for review ==
Line 34: Line 38:
 1. Why are we doing this feature? And why now?
 2. Is the page necessary? Or is it small enough to be an expandable section of another page?
 3. Is there any other page in Launchpad that does something similar?
 4. What value will this add to users?
 5. Will this make it harder for other users to complete tasks?
 6. How would you "tweet" this change? (i.e. describe in 140 characters)?
 7. Are there any other pages that should change their behavior/look with this change?
 8. Have you had a pre-implementation call with someone outside your team?
 9. If this changes the users' workflow significantly, what does the transition look like?
 10. How are we going to introduce this feature to its users?
=== Ten questions to ask yourself about any page ===
Line 45: Line 40:
== Principles ==  1. Is the <h1>'''main heading'''</h1> enough so that, if someone glances at it for two seconds, they know what this page is for ''without looking at any of the other navigation''?
Line 47: Line 42:
 * Think about the entire life of the data / object, not just how it's entered.
 * Try to break it.
 * Every error should have a way out.
 * Talk to an actual user.
 * Remember that different users have different access levels.
 * Have pictures of what it actually looks like, don't just cover "the happy case".
 2. Is the <title>page title</title> concise and meaningful enough so that it '''makes sense in a Go/History menu''', even when truncated at the end? Will people know it’s the page they want to go back to? (For example, "Bugs in “software-center” in Ubuntu Maverick" is better than "Ubuntu Maverick “software-center” bugs" or "Bugs : “software-center” source package : Maverick (10.10) : Ubuntu".)
Line 54: Line 44:
== What is this page trying to tell me ==  3. If the page is accessible when logged out, is the <title>page title</title> enough so that it '''makes sense in Web search results'''? (For example, the Launchpad pages for many people or projects rank higher than their own Web sites. To disclaim this, the <title> for these pages should end with “ in Launchpad”.)
Line 56: Line 46:
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)  4. If you were in the target audience but '''you’d never seen the page before''', would you understand what's going on? Does it need embedded help? Could you make help less necessary?
Line 58: Line 48:
 5. Do your changes make it '''easier to complete the task'''? Have you added visual complexity, or removed it?
Line 59: Line 50:
= Submitting your branch for review =  6. Does this behave '''differently than other pages''' in Launchpad? Why are those exceptions there?
Line 61: Line 52:
== 10 questions to ask yourself before submitting ==  7. After finishing with the page, is there anywhere you'll very likely '''want to go next'''? Is that destination linked to near the bottom of the page?
Line 63: Line 54:
 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?
 8. 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?
Line 74: Line 56:
== Check your choice of words ==  9. Does the page look '''elegant''' and well-balanced?
Line 76: Line 58:
Check through the [[UserInterfaceWording|User interface wording guidelines]] to ensure that you are using the recommended wording and capitalization etc.  10. Is it '''fun''' to use?
Line 78: Line 60:
== Check your template code == === Check your choice of words ===
Line 80: Line 62:
Review the [[PageTemplateHacking|quick checklist for template code]] to ensure that your template code is consistent and therefore more maintainable. Check through the [[UserInterfaceWording|User interface wording guidelines]]
to ensure that you are using the recommended wording and capitalization
etc.
Line 82: Line 66:
== Make it easy to demonstrate your UI == === Did you consider in-line help? ===
Line 84: Line 68:
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. 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:
Line 86: Line 73:
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.   * 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.
Line 88: Line 79:
= UI-reviewing a branch =
== Tips for reviewers ==
=== Check your template code ===
Line 91: Line 81:
 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?
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?
  4. '''What issues have already been raised?''' After playing with the
  branch with as little background knowledge
  as possible and forming your own ideas, it is important to go back and
  read all the related pre-implementation discussions on the related
  bugs or LEPs.
  5. '''How wide is the reach of this change?''' If a certain change is for
  a specific corner case and this knowledge influences your decisions, then
  either ensure yourself that this is the case, or ask the developer and
  code reviewer to double-check.

  • 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

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

  • Curtis Hovey (sinzui)
  • Matthew Revell* (mrevell)

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

Ten questions to ask yourself about any page

  1. Is the <h1>main heading</h1> enough so that, if someone glances at it for two seconds, they know what this page is for without looking at any of the other navigation?

  2. Is the <title>page title</title> concise and meaningful enough so that it makes sense in a Go/History menu, even when truncated at the end? Will people know it’s the page they want to go back to? (For example, "Bugs in “software-center” in Ubuntu Maverick" is better than "Ubuntu Maverick “software-center” bugs" or "Bugs : “software-center” source package : Maverick (10.10) : Ubuntu".)

  3. If the page is accessible when logged out, is the <title>page title</title> enough so that it makes sense in Web search results? (For example, the Launchpad pages for many people or projects rank higher than their own Web sites. To disclaim this, the <title> for these pages should end with “ in Launchpad”.)

  4. If you were in the target audience but you’d never seen the page before, would you understand what's going on? Does it need embedded help? Could you make help less necessary?

  5. Do your changes make it easier to complete the task? Have you added visual complexity, or removed it?

  6. Does this behave differently than other pages in Launchpad? Why are those exceptions there?

  7. After finishing with the page, is there anywhere you'll very likely want to go next? Is that destination linked to near the bottom of the page?

  8. 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?

  9. Does the page look elegant and well-balanced?

  10. Is it fun to use?

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?

  4. What issues have already been raised? After playing with the branch with as little background knowledge as possible and forming your own ideas, it is important to go back and read all the related pre-implementation discussions on the related bugs or LEPs.

  5. How wide is the reach of this change? If a certain change is for a specific corner case and this knowledge influences your decisions, then either ensure yourself that this is the case, or ask the developer and code reviewer to double-check.

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