• 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.

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

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.