5123
Comment:
|
4681
Moved the pre-coding content to UserInterfaceDesign page
|
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 15: | Line 21: |
Line 16: | Line 23: |
* Maris Fogels (mars) * Paul Hummer (rockstar) |
* Maris Fogels* (mars) * Paul Hummer* (rockstar) |
Line 19: | Line 26: |
* Edwin Grubbs (EdwinGrubbs) * Tom Berger (intellectronica) * Curtis Hovey (sinzui) * Barry Warsaw (barry) * Matthew Revell (mrevell) * Jono Lang (jml) |
* Edwin Grubbs* (EdwinGrubbs) * Tom Berger* (intellectronica) * Curtis Hovey* (sinzui) * Barry Warsaw* (barry) * Matthew Revell* (mrevell) * Jonathan Lange* (jml) |
Line 26: | Line 33: |
= Starting your UI branch = == Identify the page purpose(s) == |
== Reminder: Before starting a UI change == |
Line 29: | Line 35: |
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 31: | Line 40: |
== 10 questions to ask yourself before starting a branch == | == Submitting your branch for review == |
Line 33: | Line 42: |
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? 3. Will this make it harder for other users to complete tasks? 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? 6. Have you had a pre-implementation call with someone outside your team? 7. If this changes the users' workflow significantly, what does the transition look like? ## 8... ## 9... ## 10... |
=== 10 questions to ask yourself before submitting === |
Line 45: | Line 44: |
== What is this page trying to tell me == | 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 47: | Line 65: |
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) | === Check your choice of words === |
Line 49: | Line 67: |
Check through the [[UserInterfaceWording|User interface wording guidelines]] to ensure that you are using the recommended wording and capitalization etc. |
|
Line 50: | Line 71: |
= Submitting your branch for review = | === Did you consider in-line help? === |
Line 52: | Line 73: |
== 10 questions to ask yourself before submitting == | 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 54: | Line 78: |
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? |
* 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 65: | Line 84: |
== Check your choice of words == | === Check your template code === |
Line 67: | Line 86: |
Check through the [[UserInterfaceWording|User interface wording guidelines]] to ensure that you are using the recommended wording and capitalization etc. | Review the [[PageTemplateHacking|quick checklist for template code]] to ensure that your template code is consistent and therefore more maintainable. |
Line 69: | Line 90: |
== Check your template code == | === Check your URLs === |
Line 71: | Line 92: |
Review the [[PageTemplateHacking|quick checklist for template code]] to ensure that your template code is consistent and therefore more maintainable. | Have you added or changed any URLs in this branch? If so, look at our [[UI/UrlStyleGuide|URL Style Guide]]. |
Line 73: | Line 95: |
== Make it easy to demonstrate your UI == | === Make it easy to demonstrate your UI === |
Line 75: | Line 97: |
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. | 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. |
Line 77: | Line 101: |
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. | 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. |
Line 79: | Line 108: |
= UI-reviewing a branch = == Tips for reviewers == |
== UI-reviewing a branch == |
Line 82: | Line 110: |
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? |
=== 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
Consult the ReadyToCode checklist.
If necessary create a LaunchpadEnhancementProposalProcess to clarify the feature scope.
Create and discuss the mockups.
Submitting your branch for review
10 questions to ask yourself before submitting
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?)
- After finishing with the page, is there anywhere you'll very likely want to go next? Is that destination linked to?
- Will your changes make it easier to complete the page's defined tasks?
- Does this behave differently than other pages in Launchpad? Why are those exceptions there?
- 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?
- How many more knobs and buttons have I added?
- 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?
- What can I do to make it explaining it easier, or even unnecessary?
- Is it fun to use?
- 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
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.
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.
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?