Mark Shuttleworth | here be dragons

We’ll be using Scribus for much of the DTP internal to Canonical. Our templates etc will be published in Scribus, so folks who need to knock up a flyer or brochure have the pieces they need ready to hand. However, there’s a problem, in that the stable Scribus package is really quite old.

The Scribus team is making good progress on the next version of Scribus, but I couldn’t find an easy way to test their trunk. So I thought to make a PPA with a daily build. Whenever I’m testing or evaluating a new app I like to check out trunk, just to get a feel for the pace of activity and quality of the work. A crisp, clean, stable trunk is a sign of good quality work, which will likely mean good quality elsewhere like documentation and project governance. Chaos on trunk means… chaos generally, as a rule.

I wrote to Oleksander Moskalenko, one of the upstream developers and Debian maintainer of the Scribus packages, including a complete set of Ubuntu packages with pretty awesome documentation for how to get the newer versions for testing. He kindly offered to review the package and made some suggestions for things to look out for. And then I got lucky, mentioning that I wanted to do this on #kubuntu-devel, because Philip Muskovac turns out to be in the middle of a quest to do daily build PPA’s of most of KDE!

We already had a Bzr import of Scribus trunk for some reason, so tip is easily accessible via LP and bzr.

Philip knocked up a package recipe combining trunk with a clean packaging branch based on Oleksandr’s scribus-ng package. Et voila, LP is now doing all the work to deliver us a nice dose of Scribus goodness every day. So here’s an invitation to DTP-heads everywhere: if you’d like to see the very latest work of the Scribus team, just add that PPA to your sources and grab scribus-trunk:

sudo apt-add-repository ppa:scribus/ppa
sudo apt-get update
sudo apt-get install scribus-trunk

Generally, if the packaging branch is clean, a daily build is pretty stable, it might need a tweak now and then but that work is useful to the packager as an early warning on packaging changes needed for the next version, anyway. And it’s usually easier to fix something if you know exactly what changed to break it 🙂

I’d like to thank Philip and Oleksandr for rocking the park, and the Scribus folks for a wonderful tool that will get wider use now within Canonical and, hopefully, elsewhere too.

The Scribus trunk packages seem to work very well on Unity, the Qt/dbusmenu integration is tight in this newer version, so it’s very usable with the panel menu and launching it full-screen feels right on my laptop. I’m enjoying the extra detailed control that Scribus gives with the use of fonts over apps like OO.o and AbiWord, since I’m becoming a font nerd these days with all the work on Ubuntu.

There is a flag day transition to be aware of, though, as newer Scribus files are not compatible with those of the stable scribus. Nevertheless, both this trunk build and the scribus-ng packages Oleksandr maintains seem pretty stable to me, so we’ll be using the newer format and holding our breath till the actual release. No pressure, team Scribus 😉

Update: Philip’s published Lucid packages as well!

The user experience and design team at Canonical includes a few folks dedicated to web technology. At the moment, there is a substantial effort under way to reshape the Launchpad UI now that we have the core capabilities for cross-project bug tracking, code publishing and translation in place. We want to make it more obvious how to get something done – especially for new users – and we want to make it feel snappy and responsive when making small changes to your project data.

In the design discussions, we spent a lot of time working on a new approach to “dialog boxes, wizards and workflows”, trying to solve a thorny problem in user interaction: how do you make it easy to do something complex? There are lots of cases in Launchpad where you need to get lots of ducks in a row before you can do something. For example, you might need to make sure there is a team with specific people in it before you subscribe that team to a bug. Or you might need to create a new milestone while triaging and scheduling work on bugs in your project.

Currently, that means jumping all around Launchpad in a way that assumes you know exactly how those pieces work. You need to go to one place to register a team, and a completely different place to setup a milestone. That means that lots of people don’t use capabilities in Launchpad, because they need to understand the whole system before they can get something small done. Every time someone bumps their head on that, we fail! And that’s the problem we set out to solve.

We came up with a nifty approach, which we call morphing dialogs, that ensures the user always has the minimum number of choices to make, and still allows for complex variations on a process in a way that feels quite natural for users.

The key ideas behind morphing dialogs are:

• Only show one primary decision at a time, and make it obvious what that is. Sometimes, there are several directions you could take in order to get something done, but there is usually a single normal path for users to follow, and we always want users to be able to do the easy things easily.
• Give users a sense of how far they are in the process, but don’t be too dogmatic about that, since getting one thing done often involves stepping off to the side to take care of preliminary business and those detours can also require several steps.

Here’s an example movie, which shows a person linking a blueprint to a bug. They need to search for the right blueprint, which they can do across a couple of projects simultaneously. In this mockup, they add GNOME to the list of projects that they look for the blueprint in, and when they can’t find it, they go to register a new blueprint for what they want. In the end he decides to go back and pick one from the search results. None of this involved a page load, and the round trips to the server are much cheaper than loading full pages, since we can just get what we need in highly optimized way.

You can see a couple of the key ideas coming through in the movie.

Note the “progress bar” – the green line – is not particular large or obtrusive. It’s also not obviously a progress bar, until one has done a few multi-step processes. Note also that you can have detours; you can step off to one side to get something done, like register a team or register a new blueprint, and those detours get their own progress indicator which is separate from the main one.

We had a major sprint recently that brought the whole Launchpad team together for two weeks while we did a deep dive into JavaScript and AJAX. We picked YUI 3, the next version of Yahoo’s UI toolkit for the web, as a foundational layer for this AJAX effort, and we wanted to bring everyone up to speed on the processes for designing, building and testing web client apps. It was a lot of fun.

In particular, we wanted to unify the web service API’s that we already publish with this AJAX work, so that it would be easy to write web browser code that could talk to the exact same API’s we publish for developers who are integrating with Launchpad. That’s now possible, which means that any API we use for AJAX work will also be available to developers writing their own tools to access Launchpad directly through the web services.

Thanks to the awesomeness of YUI 3, the team is now hard at work turning those ideas into reality. Given that YUI 3 is right on the cutting edge (some would say bleeding edge!) we’re focusing on pieces that don’t depend on complex widgets – those will only start to fall into place next year as YUI 3 emerges from development.

Over the next couple of months you will see pieces of this puzzle land in successive Launchpad monthly releases (or daily, if you’re on edge.launchpad.net and a beta tester). Initially, the AJAX bling will just enable inline editing. In six to nine months, the more complex pieces should have land. And by then Launchpad’s web front-end will also be open source.

I’m absolutely thrilled to see this chart of untriaged bugs in Inkscape since the project moved to Launchpad:

As you can see, the Inkscape community has been busy triaging and closing bugs, radically reducing the “new and unknown” bug count and giving the developers a tighter, more focused idea of where the important issues are that need to be addressed.

A lot of my personal interest in free software is motivated by the idea that we can be more efficient if we collaborate better. If we want free software to be the norm for personal computing software, then we have to show, among other things, that the open, free software approach taps into the global talent pool in a healthier, more dynamic way than the old proprietary approach to building software does. We don’t have money on our side, but we do have the power of collaboration.

I put a lot of personal effort into Launchpad because I love the idea that it can help lead the way to better collaboration across the whole ecosystem of free software development. I look for the practices which the best-run projects follow, and encourage the Launchpad guys to make it easy for everyone to do those things. These improvements and efficiencies will help each project individually, but it also helps every Linux distribution as well. This sort of picture gives me a sense of real accomplishment in that regard.

Bryce Harrington, who happens to work for Canonical and is a member of the Inkscape team, told me about this and blogged the experience. I’ve asked a few other Inkscape folks, and they seem genuinely thrilled at the result. I’m delighted. Thank you!