Phew, big Blueprint landing just went in to LP, I guess it will be in production some time this week. This gets the spec tracker into roughly the right shape for us to get Dapper+1 smoothly planned and executed. It also involved quite a lot of groundwork for the 1.0 UI I am driving towards for Launchpad. So perhaps I should blog about those plans and solicit some feedback.
The high-level story is this:
- Applications on subdomains. We will move the functionality of the different facets of Launchpad into subdomains. So rosetta.launchpad.net will be where you will find translation pages, malone.launchpad.net will have bugs, blueprint.launchpad.net will have feature tracking. These applications will share a navigation system so if you are used to using the one app, and moving around Launchpad objects (upstream, ubuntu and derivatives, people and so on) then you will easily feel comfortable moving around in a different app. The big advantage of this is that it keeps you “in the zone” as you move around Launchpad. So say I am working on the spec system, and I click on the link to Carlos’ homepage in Launchpad. Typically, when I do that, it’s because I want to see what Carlos has on his plate in terms of feature development. Using subdomains gives us this for free, because I will be jumping, say, from http://blueprint.launchpad.net/distros/ubuntu/dapper/ to http://blueprint.launchpad.net/people/carlos/ and as you can see I’m automatically still in the “specs” mode. I’ve watched people using Launchpad, and usually when we jump from thing to thing we still want to keep focused on the same “facet” of that thing.
- A better menu system. A lot of the navigation will shift to the top-bar menu and breadcrumbs system. Right now you can see an (ugly) first step towards that, if you hold your mouse over the Launchpad in the top left corner you see a dropdown menu that takes you to distros, products, projects, people, meetings… now imagine you could continue navigating in to the specific product or distro or package you are looking for. Less clicking for everybody. The breadcrumbs will also become part of the menu system, so say you are looking at the 18.104.22.168 release of Firefox (two thumbs up btw guys) and you want to see what features are planned for 2.0, you should be able to get there just by hovering over Firefox in the breadcrumbs, then see the 2.0 series, and go straight to it.
- Better switching between apps. At the moment, we confuse two different kinds of switching. You can switch between objects that you are viewing, and you can switch between the aspect or facet of the object too. Sometimes, clicking on “Bugs” in the actions menu does BOTH kinds of switch, and that’s really bad. Its unpredictable. So we will work towards ensuring that any action link has a predictable result – it either is an action in the current application on the current object, or it changes the app but keeps you on the current object, or it changes the application and takes you to that app home page (“I’m switching now to think about translations, take me to the Rosetta home page”).
- Canonical object names. We track quite a few kinds of objects in Launchpad. The main ones are distributions (and their structure, releases, packages), upstreams (in the form of overarching projects, as well as individual products and their releases) and people. In order to disambiguate them we’ve kept separate namespaces for them, and used the URL structure to indicate what you are looking at. Hence you can have http://launchpad.net/products/mozilla/ and http://launchpad.net/projects/mozilla/ if you want. Now we want to switch to a different approach, where we canonicalise the names of those three major kinds of object. So there can only be one “ubuntu” thing, and that’s the distro. And only one “mozilla” thing, and that’s a project. And only one “firefox” thing, which is a product. This will let us simplify the URL’s quite a bit, down to http://blueprint.launchpad.net/firefox/ for the specifications for Firefox, we can drop the /products/ bit because we have Canonical names. This also gives us a “teleport” facility, where typing the name of the thing teleports you straight there. An email address will take you straight to the home page of the person you are thinking of. A product name will take you straight to that products Launchpad page in the app you are working on.
As you can imagine, there have been lots of dicussions, debates and fairly intense arguments about the UI for Launchpad. It’s a huge piece of infrastructure, I think it’s quite a bit richer in scope than SourceForge, which would be a reasonable comparison point, so it’s taken a long time for us to get a handle on how most efficiently to present it. I’m pretty confident in this plan, and keen to see it in place in the next three months, perhaps even in time for Dapper.
Further down the line I think we can use AJAX tools to speed up the interaction processes, but I don’t want to jam those into the infrastructure until the core plumbing is robust and mature. Right now the world of AJAZ is very much in flux, and so is the underlying set of frameworks we use in Launchpad: Zope 3 and SQLObject. We have a lot of work to do just to get the core app framework robust for taking Launchpad to scale, and that’s where we are focusing the resources. We’ve published pretty much all the Zope and SQLObject changes we are making, and I think I would like to make more of that work. Once the AJAX stuff matures, we can fold it into the app framework in a general and graceful fashion.