launchpad-dev team mailing list archive
Mailing list archive
Q&A with Michael Nelson: Designing the Build Branch to Archive UI
Over the past few months we have been trying new tools and techniques for UI
development in Launchpad. Michael Nelson recently took a good number of them
through their paces to design a long-requested feature for Launchpad, so I asked
him a few questions to give us a look inside the design process. He has good
advice about what did and did not work along the way. It is my hope that
stories like his will make the UI development process smoother and faster for
those who follow.
In this Q&A Michael shares his experience helping design the 'Build Branch to
Archive' user interface. Here is a brief description of the feature:
Ubuntu is beginning to manage its source packages as Bazaar branches, as
part of the DistributedDevelopment project.
One incredibly important activity for source packages is building them into
binary packages that can be downloaded and installed. This spec explains how
Launchpad can make this a wonderful experience.
Mars: Have you done any work designing user interfaces before this?
Michael: A little - we went through a similar process for the PPA redesign as
part of Launchpad 3.0. Prior to that, no, only your typical "Oh this
needs a UI - let's just start creating the UI that *we* think the
target users will want."
We had tried (in the Launchpad Soyuz team) doing something similar to
this design process previously (particularly, defining stories for an
interaction before coding, and getting feedback from the people
representing the target users), but no matter how hard we tried, we
weren't able to get the time with them or any feedback, and so we
ended up implementing the design and landing it without their
feedback, which was a mistake - and a lesson learned which influenced
the process I used here.
Mars: What tools and resources did you use as you went through the project?
Michael: Balsamiq, wikis, email discussions and phone calls. Balsamiq was great
as a way to create UI's quickly, modify them easily as we learned
more, share them for others to modify (I just pushed a bzr branch that
I kept up to date).
Mars: Was there a particular process that you followed?
Michael: Basically I tried to:
1. Identify and describe the use-cases,
2. Create mockups for each use-case,
3. Get feedback from as many people as possible,
and then constantly update or add new use-cases and mockups as more
info came in. Looking back, it seems we went through three definite
Mars: How long did it take to design the page?
Michael: We just designed the main interactions to build a branch into a PPA,
which is 2 pages/overlays (they'll be overlays if js is enabled). I
think the process (3 iterations above of gathering feedback,
phone-calls etc.) spanned 3 weeks, on and off.
Mars: Do you think the problem was well-understood before you started working on
the user interface?
Michael: I think different people understood their own domains of the
build-from-branch interaction, and everyone had ideas about how the
other parts should work, but no, I don't think any of us understood
the use-cases properly - particularly the issues around re-using
recipes in the UI - until all the ideas and feeback was collected and
Mars: Did the design of the interface change much as work progressed?
Michael: Yes, quite a bit. Initially I had initially (mis)understood that we
needed to work with the current implementation of bzr-builder, but
after the first iteration, James Westby pointed out that bzr-builder
can be updated to support the requirements of the UI. This freed us to
consider sharing recipes in the UI in a way that would not have been
Collecting and expanding the use-cases naturally required updates to
the design. Also feedback and questions from various people helped to
keep refocusing on what people want to be able to do (for example,
"This recipe supports building to Ubuntu Lucid, Ubuntu 9.10 and Ubuntu
9.04", while still allowing the person using the recipe to select just
the distroseries they want).
Mars: How did you get feedback on the designs? Was there a good response?
Michael: So as above, email to the dev list, then irc chats, but the biggest
throughput of communication and feedback came via actual calls. It's
just so much easier to clear misunderstandings on the spot if you walk
through the process together. I had multiple calls with 6 different
people, all which were invaluable.
Mars: Looking back, what was the most difficult part of the process?
Michael: (1) Getting real user input and feedback and (2) getting feedback from
With (1) the best I could do with the time I had was to communicate
with representatives of target users, which I think worked quite well.
And (2) was difficult mostly due to the nature of the problem for
build-from-branch. IMO it requires someone to sit physically in the
office and walk through the process with a designer, something I
couldn't do, and hasn't been done yet as far as I know.
Mars: What did you most enjoy about the work?
Michael: Bringing lots of ideas together from lots of people, clarifying the
different needs to different people to build a common understanding of
the issues involved.
But, to be honest, I am also enjoying getting back to soyuz coding. I
enjoy doing this kind of thing for a week or two, but after that I'm
always keen to get back to doing some coding.
I think I (and James?) also enjoyed the fact that we could work on
defining the interaction *before* anything had been coded. Too often
we get in there and just start coding something without thinking
through the use-cases properly (or even defining them), and it ends up
causing a lot of pain. Like everything, it's a learning process.
Mars: Any final words for developers looking to try this themselves?
Michael: Sure, if you'd like a change of rhythm and enjoy facilitating
conversations and ideas, give it a go - it's a great chance to
interact with other people in different areas and build your
understanding of what people actually want to do with your product.
My thanks go to Michael for taking the time to answer my questions.
Description: OpenPGP digital signature