''(See the [[Wishes|Wishes]] page for what this is all about.)'' == Matthew Paul Thomas == {{{ My three wishes: Do less, do it smaller, do it smoother. By "less" I mean getting rid of things like blueprint feedback requests, which have never worked[1][2]; the Fix Released bug status, which has never worked[3]; the Incomplete bug status, which hasn't worked for a year or so; CVE pages[4], which as far as I can tell, have never been used by their target audience[5]; poll option "names", which are useless[6]; and the unused project fields -- such as Freshmeat URL -- that make projects a chore to register[7]. I also mean merging things that cause aggravation or confusion by their separation: for example, make bug reports and blueprints interchangable variants of the the same thing[8], make milestones and releases interchangable variants of the same thing[9], make code-browsing pages use exactly the same navigation as the rest of Launchpad, and make launchpadblog and Planet Launchpad the same Web site. By "smaller" I mean more power in the same, or less, amount of interface.[10] For example, it should be possible to do advanced bug searches without navigating a huge advanced search page.[11] It should be possible to set up a team poll without having to enter each option on a separate page load. It should be possible to set up translations, in the project you've just registered, without having to spelunk through half a dozen pages.[12][13] And bug tags should be easy and powerful enough that Launchpad developers themselves don't need to use fake projects to categorize their bug reports. Part of this is just using XHR more -- but most of it is thinking about, user testing of, and designing for, user goals rather than pages in isolation. And by "smoother" I mean designing and implementing not just changes, but the process for announcing and teaching the changes. Introducing a small feature? For each user, remember whether they've dismissed the highlighted help box that points to the feature and links to more detailed help. Introducing a big feature? Publish a screencast of it a week ahead of time, and again use a dismissable help box on appropriate pages to link to the screencast. Finally lighting up a long-disabled tab (such as the Code tab for source packages)? For a month afterward, stick a "New!" starburst on the tab for the appropriate pages. Moving something to another position on the same page? For two weeks afterward, put an explanation in the old position with a link that scrolls to and highlights the new position. Launchpad is a Web site: people don't have the luxury of delaying upgrading to the next major version until they're ready. So Launchpad shouldn't have major versions like "3.0" or "4.0"[14]; instead, there should be constant small improvements, each with its own guides and signposts. Thanks to Jono Lange for a conversation that helped brainstorm and clarify some of these ideas. [1] http://launchpad.net/bugs/3522 [2] http://launchpad.net/bugs/125394 [3] http://launchpad.net/bugs/163694 [4] http://launchpad.net/ubuntu/+cve [5] They use instead. [6] http://launchpad.net/bugs/179441 [7] https://dev.launchpad.net/RegistrySimplifications [8] https://dev.launchpad.net/IssueTracker [9] http://launchpad.net/bugs/174468 [10] http://www.uie.com/articles/experiencedesign/ [11] http://launchpad.net/bugs/5594 [12] http://launchpad.net/bugs/60939 [13] http://launchpad.net/bugs/264109 [14] http://www.uie.com/articles/death_of_relaunch/ }}}