Not logged in - Log In / Register

(See the Wishes page for what this is all about.)

Matthew Paul Thomas <mpt {_AT_} canonical.com>

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 <http://launchpad.net/ubuntu-cve-tracker> 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/

Wishes/DoLessBeSmallerBeSmoother (last edited 2009-09-02 17:54:37 by kfogel)