## page was renamed from UserInterfaceDesign ||<
><>|| * '''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 [[UI/Reviews#Current UI reviewers|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 [[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". * Improve by removing. == 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 [[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.]] 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]].