2148
Comment:
|
5204
Moved under UI/
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## page was renamed from UserInterfaceDesign ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<BR>><<TableOfContents>>|| * '''Name:''' UI Design * '''Owner:''' Launchpad Team * '''Effective:''' Summer of 2009 |
|
Line 3: | Line 10: |
When it comes to building User Interfaces in Launchpad, there are a few practices that make the process go faster for everyone involved. | Before starting coding on a new feature or reworking a new UI, it's very important to do some mock-ups first and get feedback from [[UI/Reviews#Current UI reviewers|reviewers]] and/or the Canonical DUX team. |
Line 5: | Line 15: |
== Use light-weight tools for Mockups == | == 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. 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? == Principles == * 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". == 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. == Create mockups for the changes == === Use light-weight tools for Mockups === |
Line 17: | Line 71: |
You will be going back and forth with the designer many times, perhaps a dozen or more, trying ideas, rearranging information, and integrating your change into the existing page layout. A light-weight mockup takes minutes to create - a typical turnaround between you and the designer is 30 minutes. A medium-fidelity mockup takes a bit longer, perhaps an hour to create, 90 minutes to turn around. A high-fidelity mockup takes hours or days to create: the turnaround is very high (so high that you force the designer to swap back and forth between your design and other work. This is ''not good'' for the creative process). | You will be going back and forth with the designer many times, perhaps a dozen or more, trying ideas, rearranging information, and integrating your change into the existing page layout. A light-weight mockup takes minutes to create - a typical turnaround between you and the designer is 30 minutes. A medium-fidelity mockup takes a bit longer, perhaps an hour to create, 90 minutes to turn around. A high-fidelity mockup takes hours or days to create: the turnaround is very high (so high that you force the designer to swap back and forth between your design and other work. This is ''not good'' for the creative process). |
Line 19: | Line 81: |
== Don't write code first! == | === Don't write code first! === |
Line 21: | Line 83: |
The corollary to using light-weight mockup tools is ''do not write code first''. Please, do ''not'' start with a high-fidelity mockup using HTML, JavaScript, and CSS. If you do this, it will take '''days''' to go through one feedback cycle between yourself and the designer, and the norm is to have a half-dozen such cycles per-feature. | The corollary to using light-weight mockup tools is ''do not write code first''. Please, do ''not'' start with a high-fidelity mockup using HTML, JavaScript, and CSS. If you do this, it will take '''days''' to go through one feedback cycle between yourself and the designer, and the norm is to have a half-dozen such cycles per-feature. |
Line 23: | Line 89: |
== Balsamiq Mockups == | === Balsamiq Mockups === |
Line 25: | Line 91: |
One tool that is very nice for doing quick mockups is [[http://www.balsamiq.com/products/mockups|Balsamiq Mockups]]. In fact, it can be faster than paper. You can find some sample mockups of the "Related branches" bug page module [[http://people.canonical.com/~mars/ui/|here.]] | One tool that is very nice for doing quick mockups is [[http://www.balsamiq.com/products/mockups|Balsamiq Mockups]]. In fact, it can be faster than paper. You can find some sample mockups of the "Related branches" bug page module [[http://people.canonical.com/~mars/ui/|here.]] |
Line 27: | Line 97: |
The team at Balsamiq have graciously provided our Open Source project with a team license. If you would like to use Balsamiq, get in touch with [[http://launchpad.net/~beuno|Martin]]. | The team at Balsamiq have graciously provided our Open Source project with a team license. If you would like to use Balsamiq, get in touch with [[http://launchpad.net/~beuno|Martin]]. == Mockups review & approval == The mock-ups should be attached to the related bug or the LaunchpadEnhancementProposalProcess page describing the features. Then send an email to the [[https://launchpad.net/~launchpad-dev|launchpad-dev]] mailing list requesting reviews of your mock-ups. The subject should start with the tag [RFC-UI] to make it clear to UI reviewers and interested members of the DUX team that their feedback is required. You probably want to wait one day or two to collect the initial feedback. Then book a "live" session with one of the official UI reviewers to quickly iterate on the second version and get approval. Once a UI reviewers or DUX member says, it's good to go, you can start working on the implementation. Once the implementation is done, the loop will be closed during [[UI/Reviews|UI review]]. |
|
Name: UI Design
Owner: Launchpad Team
Effective: Summer of 2009
Designing User Interfaces in Launchpad
Before starting coding on a new feature or reworking a new UI, it's very important to do some mock-ups first and get feedback from reviewers and/or the Canonical DUX team.
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.
- Why are we doing this feature? And why now?
- Is the page necessary? Or is it small enough to be an expandable section of another page?
- Is there any other page in Launchpad that does something similar?
- What value will this add to users?
- Will this make it harder for other users to complete tasks?
- How would you "tweet" this change? (i.e. describe in 140 characters)?
- Are there any other pages that should change their behavior/look with this change?
- Have you had a pre-implementation call with someone outside your team?
- If this changes the users' workflow significantly, what does the transition look like?
- How are we going to introduce this feature to its users?
Principles
- 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".
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.
Create mockups for the changes
Use light-weight tools for Mockups
There are roughly three types of user interface mockups:
low fidelity: Pencil and graph paper is common, Balsamiq mockups are awesome
medium fidelity: Save an existing page, hack the HTML and CSS with Firebug to make it look different
high fidelity: A full prototype with HTML, CSS and JavaScript
When it comes to creating a mock-up, use the lightest weight tool possible
You will be going back and forth with the designer many times, perhaps a dozen or more, trying ideas, rearranging information, and integrating your change into the existing page layout. A light-weight mockup takes minutes to create - a typical turnaround between you and the designer is 30 minutes. A medium-fidelity mockup takes a bit longer, perhaps an hour to create, 90 minutes to turn around. A high-fidelity mockup takes hours or days to create: the turnaround is very high (so high that you force the designer to swap back and forth between your design and other work. This is not good for the creative process).
Don't write code first!
The corollary to using light-weight mockup tools is do not write code first. Please, do not start with a high-fidelity mockup using HTML, JavaScript, and CSS. If you do this, it will take days to go through one feedback cycle between yourself and the designer, and the norm is to have a half-dozen such cycles per-feature.
Balsamiq Mockups
One tool that is very nice for doing quick mockups is Balsamiq Mockups. In fact, it can be faster than paper. You can find some sample mockups of the "Related branches" bug page module here.
The team at Balsamiq have graciously provided our Open Source project with a team license. If you would like to use Balsamiq, get in touch with Martin.
Mockups review & approval
The mock-ups should be attached to the related bug or the LaunchpadEnhancementProposalProcess page describing the features.
Then send an email to the launchpad-dev mailing list requesting reviews of your mock-ups.
The subject should start with the tag [RFC-UI] to make it clear to UI reviewers and interested members of the DUX team that their feedback is required.
You probably want to wait one day or two to collect the initial feedback. Then book a "live" session with one of the official UI reviewers to quickly iterate on the second version and get approval.
Once a UI reviewers or DUX member says, it's good to go, you can start working on the implementation.
Once the implementation is done, the loop will be closed during UI review.