Interview: Huw Wilkins on Launchpad’s UI
Published by Matthew Revell July 8, 2011 in Podcast
The Canonical Launchpad and Bazaar teams were in Dublin last week for their six-monthly meet-up.
While there I spoke to Launchpad’s UI guy, Huw Wilkins, to ask what he’s working on and what’s next for Launchpad’s web interface.
Consistent display of tangential links
Published by Curtis Hovey June 24, 2011 in General
On Launchpad we have a lot of links that take your focus away from the current task. Usually, these exist to let you get more information on Launchpad or take you off Launchpad to do something like look at upstream information.
These links are usually represented one of two ways–a blue link with a globe for something that takes you to a new website, or a blue or green link for an internal link that opens a new window.
There’s a problem with this though. Green links mean an action will not take you away from your current view. Using a green link to take you to another window is a contradiction in our UI. Blue links alone aren’t ideal either, because blue links are scary. Everyone’s been bitten by clicking a link while in the process of filling out a form and losing the data they’ve spend five minutes filling out.
Right now, on our enhanced person-pickers, we have a green “Details…” link to let you see more information about a person. This link opens in a new tab, and we need to come up with a better way to indicate that action. We’ve put together a survey showing some rough ideas of how we might indicate a link that opens in a new window. It’s a very short survey, and we would love to get your input.
Please, take the “link opens a new window” survey.
Launchpad meet-up Dublin
Published by Matthew Revell June 22, 2011 in General
We’re having a Launchpad meet-up in Dublin next Wednesday (29th June) from 8pm at the Porterhouse on Nassau Street.
Come and meet some of the Canonical Launchpad team, a few other Canonical types and members of the Ubuntu Irish LoCo.
Knowing who the user is in Launchpad
Published by Curtis Hovey June 20, 2011 in General
We are testing changes to the person picker used on many pages in Launchpad. Our general goal is to ensure that you can trust you know who the user you are seeing is.
Beta testers will see two subtle changes to pages: The login status area in the upper right of the page will show both your display name and launchpad id.
We call this presentation unique-name. This is the same presentation that users will see when you post a comment.
When you read comments, you should know exactly who wrote it. There should be no confusion when there are many users with the same Launchpad display name. Launchpad users commonly have a single word display name, such as Tom, and it is not clear who wrote the what when there are comments from several users named Tom on a page.
Beta testers will will see substantial changes to the person picker. We want you to find the user you are searching listed in the first page of results. It is easy to confuse users of similar name and IRC nickname, and users often hide their email address. The listing must show enough information for you to confidently make a choice.
There will always be a link to choose yourself for any action where you are a legitimate choice. You should never need to search for yourself.
The search results are ordered by best match. Exact matches on Launchpad Id, email address, and IRC nicknames are shown first. Users who are active in Launchpad are shown next. Non active users are shown last.
The listing of users shows the unique-name. IRC nicknames were added, since it was common for users to search on them. Those who are active in the project you are working with are shown with the project’s badge to the right of their name. While users may have similar names and IRC nicknames, Their Launchpad Id is unique and their activity in Launchpad or your project is a strong indication who the user is. There will be cases where you want to see more details about the user before choosing, so the listing includes a link to see the user’s profile.
We are tracking person picker defects with the person-picker tag. If you find issues not already reported, add the person-picker tag to your new bug get them triaged quickly: https://bugs.launchpad.net/launchpad/+bugs?field.tag=person-picker
Farewell, Jonathan
Published by Francis J. Lacoste June 17, 2011 in General
Yesterday, Jonathan Lange our Product Strategist announced that he was leaving Launchpad after four and a half year. The fact that he’s only leaving next door to work on the Ubuntu Developer Programme from within the Platform team is only a small comfort.
Before becoming Launchpad Product Strategist, Jonathan was known for adding support for source package branches to Launchpad. He became Strategist at about the same time I took the interim leadership of Launchpad. It will interesting to see how I manage without him!
He was instrumental in most of the process changes that happened to the team in the last two years. We can thanks Jonathan for bringing us the LEP process which make sure that we focus on the right things before starting coding, the Stakeholders process to make sure that we are working on the right thing. He also brought some clarity on what Launchpad was all about! Recently, he has been working on clarifying the feature development process, so that we can deliver polished changes on a regular cadence to users. I’m probably forgetting also a lot of other changes which his constant quest for improvements suggested to us in one way or another.
Oh, and we can thank him for making sure that we didn’t move on early from daily builds, improved bug subscriptions and other changes without the polish they have today. I (and I’m sure our users) thank you!
Whoever takes that role forward, will have big shoes to fill! If you are interested by the challenge, a job opening should be posted soon!
Thanks a lot Jonathan, it was a pleasure to work with you all these years! You’ll be missed. Good luck with your new project, but I’m glad to think that the future of Ubuntu Application Development is in excellent hands!
Photo by Robin Robokow. Licence: CC BY-NC-SA 2.0.
Visualizing Ubuntu Differences Against Debian
Published by Julian Edwards June 16, 2011 in Beta, Cool new stuff
Over the past few months, my team have been working to make it easier to create and manage derivative distributions in Launchpad.
Although most of this will be of interest only to distro admins and contributors, we recently released a beta of a new feature that lets you visualize the differences between Ubuntu’s Oneiric series and Debian Sid.
There’s a new portlet on the distroseries page that will list the numbers of packages in both distributions, numbers only in Sid and numbers only in Oneiric. Clicking on the links takes you to pages that show the differences in more detail and allows you to request debdiffs and add comments on the packages.
Please let me know what you think of this change. We’re tracking bugs using the ‘derivation’ bug tag. Note that this is not meant to be a replacement for MoM – yet. We have a long way to go for that.
Coming soon, actual syncing from Debian to Ubuntu. Watch this space!
Using visibility for rudimentary JavaScript templating
Published by Aaron Bentley June 14, 2011 in General
DRY is one of my watchwords. That’s “Don’t Repeat Yourself“, of course.
If you’re designing your page to work with-and-without JavaScript enabled, then you’ll likely be tempted to repeat some of the
user-interface text in the template and in the JavaScript file. Especially for text that appears only some of the time.
One alternative is to render that text all the time, and only show it some of the time. In Launchpad, you add the “unseen” class to text in order to hide it.
In YUI3, it’s easy to add or remove classes using Node.toggleClass(). For example:
foo.toggleClass('unseen', baz);
This adds the ‘unseen‘ class to foo when baz is true, and removes it when baz is false.
This approach means you don’t need to repeat the text. It means your HTML stays in an XHTML file, with all the syntax-highlighting and other tool support that implies. It makes it easier to live with the fact that Launchpad don’t have a hardcore templating system in JavaScript.
It doesn’t eliminate all issues. If the page needs to have more than one instance of the text, this approach doesn’t directly apply. However, it’s easy to imagine extending it by using a hidden copy as a prototype and copying it as needed.
One disadvantage is that testing becomes harder. With conditional rendering, you can just check whether the text is rendered. With conditional visibility, you need to check whether the text has the unseen class, which is harder. If plan to apply this technique, it’s best to start out using it, or else you’ll have to rewrite all your tests when you switch approaches.
Another issue is that you will probably need to leave placeholders. For example, one of our conditionally-rendered strings included a link to a branch. When there’s no assigned branch, that text must be hidden. When someone assigns the branch via AJAX, we need to have a placeholder for the branch link, so that we can set it to the correct value with Javascript. At present, there’s no way to generate placeholders for arbitrary types, so it must be done manually.
Initializing page JavaScript from the JSONCache
Published by Aaron Bentley June 10, 2011 in General
Launchpad has a nice feature for initialising on-page JavaScript, called the JSONCache. I recommend considering it as your first choice when writing JavaScript that needs to be initialised. The one downside is that due to bug #740208, it’s not available for users who aren’t logged in. But then, users who aren’t logged in don’t need a lot of JavaScript, because they can’t write to most of Launchpad.
I found out about the JSONCache when we were working on he sourcepackage +sharing-details pages recently. This JavaScript has model objects, but I didn’t know how we should initialise them. We considered initialising them from the page HTML. We considered using the web service. But it turned out there’s already a great facility for this: the JSON cache.
If you’ve hacked on Launchpad’s HTML, you probably already know that every you can get LP.cache.context and LP.cache.me from any Launchpad page. These come for free, but with a little more work, you can get any object you need:
cache = IJSONRequestCache(self.request)
cache.objects.update({
'productseries': self.context.productseries,
'upstream_branch': self.upstream_branch,
'product': self.product,
})
These entries will then appear in the LP.cache with the names specified in the dict.
However, they are provided as plain JavaScript mappings, unlike the values returned by lp.client.Launchpad. You can use convert_cache to create a copy of the cache containing lp.client.Entry values. This allows you to intermix values from the lp.cache and the web service freely.
convert_cache currently lives in translations/javascript/sourcepackage_sharing_details.js, but should probably be moved into lp.client.
One extension I’d love to see would be a way to retrieve an updated copy of just the JSONRequestCache for a page. That way, we could reduce our number of round-trips, and also be confident that everything was up-to-date.
Getting started with launchpadlib
Published by Matthew Revell June 8, 2011 in API
I’m not a developer. I’ve played around — various flavours of BASIC as a kid, Python nowadays — but it rarely goes beyond a little experimentation.
Lately, though, my lack of Python-fu has been increasingly frustrating. In particular, there are times when I want to know something that I’m pretty sure Launchpad can tell me but there’s not an easy way to get at that information through the web UI.
For just those occasions we have the Launchpad web services API and its Python library, launchpadlib.
So, I’m going to learn my way around launchpadlib and write about my experience here. Bear in mind, I’m writing this from the perspective of someone who isn’t a developer. That may seem odd but I’m willing to be there are plenty of people out there who want to do the same as me: get more out of Launchpad and the data it hosts.
Getting started
You can install launchpadlib straight from the primary Ubuntu archive in recent releases. That’s what I’ve done so, unless I say otherwise, assume I’m writing about the version of launchpadlib that’s available in Ubuntu 11.04 (Natty).
Installation takes nothing more than a simple:
sudo apt-get install python-launchpadlib
Authenticating with Launchpad
When you access Launchpad through launchpadlib you can opt to either:
- access Launchpad anonymously
- log in with a user account and grant that launchpadlib instance a certain level of access to the account’s data.
If all you need is read-only access to public data, you may as well access Launchpad anonymously. For anything where you need to write data or access data that’s available only when logged in, each person who uses your launchpadlib application will need to grant their instance of the app access to their Launchpad account.
The Launchpad API, and so launchpadlib, lets OAuth take care of the authentication. It’s pretty simple really: when you run your app it opens up a Launchpad page in your browser. On that page you can choose what level of access that particular application has to your account. That log-in should be a one-time thing, as launchpadlib will cache your credentials.
And you can check/change what access different API apps have at any time.
Accessing Launchpad data
launchpadlib lets you access Launchpad data and functionality just like they were any other Python object. That’s great for someone like me because it means I don’t have to care about REST APIs, HTTP or any of that.
In my next post I’ll start actually getting hold of Launchpad data and maybe trying to do something with it.
Photo by Sébastien Bertrand. Licence: CC BY 2.0
JavaScript development: YUI testing
Published by Aaron Bentley June 6, 2011 in General
I recently came back to JavaScript, having largely ignored it for a couple of years. Development in JavaScript is much nicer than I remember. I thought I should share what I’ve learned.
The first thing I’ll mention is YUI tests. If you’re a TDD developer (and if not, why not?), YUI unit tests are the way TDD should be. The change/test cycle is very fast (to run the tests, hit “reload” in your browser). And since they’re proper unit tests, they feel like a safety net when you start to make changes.
They are a good way to test your model code and HTML changes. Other members of the Launchpad team have used them to do more integration-style testing, as well. It’s somewhat difficult to set up I/O dependent tests, but that will encourage you to make most of your code I/O-independent.
For information on how to get started with them, see: Developing with YUI.Test
