0

Help us improve Launchpad’s icons

Published by Matthew Revell October 5, 2009 in General

Martin posts on his blog:

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

Here’s the link: http://www.surveymonkey.com/s.aspx?sm=6iwthaIT4FwPCsMPa1EDEA_3d_3d

0

Code Hosting offline from 10:00-10:30 UTC, Thursday 1 Oct

Published by Karl Fogel September 29, 2009 in General, Notifications

Launchpad’s Code Hosting service (code.launchpad.net and all Bazaar access) will be offline from 10:00am-10:30am UTC, Thursday, 1 October 2009. Sorry for the short notice; we need to do some unexpected hardware maintenance.

     Going offline: 10am UTC, 1 Oct 2009
     Expected back: 10:30am UTC, 1 Oct 2009

That’s 11am London (BST), 12 noon Western Europe, 2pm Moscow, 6pm Beijing, 8pm Sydney, 3am California, 6am New York.

0

Soyuz 3.0

Published by Julian Edwards September 24, 2009 in General

The Soyuz team was very, very busy over the last year fixing lots of bugs and adding plenty of new features. These are the highlights that I’d like to mention!

New features

3.0 UI

We also did a lot of complete page redesigns for 3.0:

But the work doesn’t stop here. We’re already thinking about 4.0!

0

Launchpad Translations 3.0

Published by Данило Шеган in Translations

Launchpad 3.0 is a major milestone for Translations. Along with many small improvements across the board, here are the highlights.

Improved UI and navigation

Along with the rest of Launchpad, Translations has switched to the new and stream-lined 3.0 layout. However, that’s not all: we’ve fixed a huge number of small annoyances while doing this conversion, and we expect your experience to be much nicer.

The new Launchpad layout

One of bigger improvements has come through…

Personal dashboard

You are a reviewer in a translation team, and wonder if somebody has submitted any suggestions you can look at? Or, you’re stumped about what you could translate next?

Your personal dashboard now lists all the translations you’ve worked on in the past if they’ve got something you can help with: unreviewed suggestions, or strings that need translating.

Bazaar integration

You’ve got your code hosted in Launchpad, but you have to manually upload and download tarballs with translation files?

Not any more! With 3.0, Launchpad allows you to directly import all translations from your code branches, and to have them automatically committed to a separate or the very same branch.

Translations sharing

Your project has multiple series (eg. stable and trunk)? Translators have to go through both just to keep them up-to-date? Well, not with Launchpad.

If same strings appear in both series, translating it on one will have it automatically get translated in the other.

8

Talking about Launchpad’s new interface

Published by Matthew Revell September 23, 2009 in General

Launchpad 3.0’s most noticeable feature is a new user interface. Martin Albisetti led the development of that new interface, so I asked him how the work had gone.

Matthew: What problem were you and the rest of the Launchpad team trying to solve with this UI redesign?

Martin: When I started working on Launchpad, I was presented with the challenge of bringing the project into the 2.0 era, where everything is editable inline, nice to use, fast and slick.

Mark Shuttleworth created a new team dedicated to making sure that Canonical shipped amazing user experiences in every single project, and Launchpad has been the pioneer project.

There were long-standing issues with the UI we wanted to solve, and there where many new features being worked on, the redesign was taken to make sure that the new and old worked well together. There where also a lot of infrastructure changes that needed to be made to enable us to continue developing in an Agile way and keep quality high, while we upped the bar in the experience our users had.

It’s been a great challenge, but with a team of super-stars like Launchpad it almost felt easy.

Matthew: Would you consider using Flash or other similar technologies in the Launchpad UI?

Martin: We did. Being an open source project sponsored by an open source company with an open source culture, proprietary tools are usually the last option we consider. We use Flash to create mockup movies of what we want the interaction and experience to look like, so developers can see it over and over again while they’re making javascript magic.

With browsers supporting new open technologies every single day, it didn’t make sense for us to force our users to install proprietary software to user our service. AJAX, and especially the canvas element allow us to do whatever we want. I can’t tell you enough about how grateful us web developers are for the healthy browser competition that has spring up the the last few years.

Matthew: How do you produce and maintain the templates used for Launchpad pages?

Martin: Well, it can happen in a few different ways. A common path would be:

  1. Find out what the intention of that page is.
  2. Research how users are currently using it (it’s amazing how people use pages in unexpected ways).
  3. Create a low quality mockup of what the page could look like, something easy to change.
  4. Throw it out in the public, the more feedback you can get, the less likely you will miss out on something important.
  5. Hand it over to a developer, work with them on implementing it and solving problems you didn’t predict would come up.

Launchpad uses Zope, so our templates are Zope templates. Like any technology, it has it’s advantages and it’s limitations. Sometimes it limits us on what we can ship, but rarely significantly thanks to our incredibly creative developers.

Matthew: You introduced a system of UI reviews to the Launchpad project: how did that work? Has it been a success?

Martin: This to me has been the most significant change. We have 30 developers working at the same time delivering improvements and new features to our edge users on a daily basis, and it was hard to keep the interface consistent and clean.

UI reviews where an extension of an existing process, code reviews. Not one line of code was changed or added to the project without someone else looking at it first. So I started reviewing the UI for all changes before they landed, working together to change anything that would be inconsistent or hard to understand. This had an immediate impact. Developers shifted to thinking about UI before they started programming, had the opportunity to learn in the review process and ask questions.

We got to a stage where some people had understood this so well I started building a team of UI reviewers, people who where especially interested in user interfaces and had learned from the reviewing experience. Very quickly, more than half the UI changes where being reviewed by developers. There’s a graduation process where they can approve changes with no supervision, and I already have a few candidates close to graduation day!

A wonderful side effect of inverting the roles was that the developers improved their own work, fully knowing what was required to land a change. I feel it’s been the biggest success since I joined the company over a year ago.

Matthew: How do you teach an understanding of what makes good UI?

Martin: In the process of including more people in the UI review process (and eventually, we’re aiming at including everyone) there where many hours of conversations around changes, explaining why some things needed changing and figuring out together how to do it. These conversations slowly grew into a wiki page with tips and tricks, easy to follow and understand. All this together with experience is what I feel teaches understanding of good UI.

Matthew: Many of the UI changes have involved Ajax: what have been the biggest challenges in retrofitting the web application for Ajax and also for introducing Ajax to the team?

Martin: The first challenge was picking the right tools. The rich number of options out there made this a non-trivial task. Since Launchpad was spearheading many of the changes that will happen to the rest of the web applications in Canonical, it was an exhaustive process. In the end, we gambled on using YUI3, Yahoo’s Javascript library currently in beta but in early alpha back then. YUI2 had a great reputation, well tested with a vibrant community, and YUI3 was building a new library from the ground up with all the lessons they learned from previous versions. It was the right choice.

Testing infrastructure was also a big thing for us. We’re a quality-oriented company, so we weren’t about to get into hundreds of thousands of lines of Javascript and CSS without being able to have integration and regression tests. This seems to be an area that still needs maturing. Windmill seemed like the most reasonable choice. I hear their community has been very valuable in our adoption.

Once we had made the big decisions, all the team flew into London for two weeks of javascript training to kick off the work. It was a very fun sprint.

Retrofitting I feel was easy due to the way the code base had been developed. We had HTML fallbacks for every single page already available, so we just needed to tack on a click handler to a link and we where ready to go, allowing us to use what is commonly called “progressive enhancement”.

Matthew: How have coding standards changed as a result of the UI changes?

Martin: New processes were added to bring UI to the front, we standardized on a Javascript-specific style of coding, and “trivial” changes rarely became trivial.

Matthew: Some browsers are less well supported by the Launchpad interface when it comes to Ajax. Why is that?

Martin: YUI3 grades browsers based on how well they are supported, so we inherit those standards as a base. CSS comes into play as well, so based on our user base we adapt that list. MS Internet Explorer is usually the biggest headache for us and usually gets less support as it’s a small user base.

Matthew: Thanks Martin!

13

Launchpad 3.0 is here! New UI and more.

Published by Matthew Revell in Releases

The Launchpad team is proud to announce the release of Launchpad 3.0!

Highlights in this release include:

Let’s take a look at these, and more, in closer detail.

New user interface, with in-line editing

Visit Launchpad to see our new web interface. You can now view more information on many pages without scrolling, particularly on people and project profile pages.

And the web interface is now faster: you can update more data, including almost everything on bug report pages, without reloading the page.

Take a look at our screencast for more on the new interface:

(Ogg Theora version)

(Read our interview with Launchpad’s UI guy, Martin Albisetti)

Personal translation dashboards

Want to check if a translation needs your review? Or perhaps you want to see which projects need translation work in your language.

You can now get a quick overview of translation work that needs your attention by visiting your new translation dashboard.

(Read Danilo’s post on Launchpad Translations 3.0)

Automatically updated code diffs during code reviews

When you’re going through a code review, you’re likely to make changes to your code based on your reviewer’s comments.

Now, when you push your changes up to Launchpad in the middle of a code review, Launchpad updates the diff shown on the review page. So now it’s easier for your reviewers to see your proposed changes even as you update them.

Launchpad now using Bazaar 2.0

We’re now running Bazaar 2.0. This means that all new code imports — from git, Subersion and CVS sources — are in Bazaar’s new more efficient 2a format. We’re also starting to upgrade existing imported branches to the new format.

To use Bazaar’s new 2a repositories, you should upgrade to Bazaar 2.0.

Community contributions

Now that Launchpad’s an open source project, 3.0 also includes a number of contributions from developers outside Canonical’s Launchpad team.

Many thanks for their work and enthusiasm for Launchpad go to:

(See more detail on our contributions page)

Also in release 3.0

For full details of the bugfixes and blueprints that make up Launchpad 3.0, visit its milestone page.

If you come across a bug, please report it.

See you next time

Launchpad 3.1.10 is due on the 4th of November. See the releases calendar for more.

In the meantime, stay up to date with Launchpad news and views here on our blog.

As always, you can join us in channel #launchpad on irc.freenode.net and on the launchpad-users mailing list.

For development discussion, come to channel #launchpad-dev on irc.freenode.net or to the launchpad-dev mailing list.

4

Under the hood

Published by Matthew Revell in General

Bjorn Tillenius recently took the role of Launchpad Technical Architect. That, and the release of Launchpad 3.0, seemed like a good opportunity to learn a bit more about his new role.

Matthew: You’ve just taken a new role in the Launchpad team of Launchpad Technical Architect. That sounds like a big job: how is it going so far?

Bjorn: Yes, it’s indeed a big job. There are a lof of things that are in need of attention, so a big part of my work so far have been to talk to people, and get a list of the most pressing tasks written down. But I’ve also managed to do something concrete, like integrating our Windmill (a Javascript integration test framework) test suite into our zope.testing test runner, which we use for all our other tests.

Matthew: Is your role mostly concerned with the code of Launchpad or also the servers etc?

Bjorn: My role is mostly concerned with the code of Launchpad. My main objective is to make it easier to develop Launchpad, which includes designing and refactoring code to make it easier to use. I’m also concerned about ensuring that the quality of the code is high, and that we have good automated tests.

Matthew: What are your top three priorities for your new role?

Bjorn:

  1. Make it quicker to develop new pieces of code.
  2. Code reuse.
  3. Make sure Launchpad code is scalable.

Matthew: What challenges does being a large Python/Zope application throw up?

Bjorn: Complexity. There are a lot of sub-systems that need to interact, and it’s hard to keep track of everything in the code base. If you work on one part of the system, you might not know that another part of the system has already solved part of your problem.

Another big challenge is that Python is big on readability. It should be easy to read and understand your code. This is great, except when you get more users, and realise that the beautiful code you wrote is really slow. Producing code that is both beautiful and fast is hard, and sometimes impossible. You have to make a lot of compromises.

Matthew: What coming technologies look as though they might be interesting for Launchpad?

Bjorn: We’re currently looking into using Grok and memcached.

Grok is interesting, since it allows us to more easily replace our ZCML code with Python code. This makes it easier to both write, and to understand, since ZCML adds another language the developer has to learn, and it adds an indirection which can be hard to follow.

Memcached is interesting, since we currently render a big part of the HTML page on-the-fly, which is quite expensive. Memcached allows us to cache part of the page, so that our pages will render faster.

Matthew: How do you ensure a consistent approach to development and architecture of Launchpad with a distributed team?

Bjorn: Being in a distributed team certainly makes things harder, when it comes to making sure everyone does the same thing. I’d say our biggest asset here is the code review that we require before any code can land in the mainline. With another pair of eyes looking at the code, the chance of spotting areas of improvement increases. Of course, spotting mistakes at this point isn’t ideal, since it’s quite late in the process, the developer has already spent time writing the code. That’s why we also are pro-active, and use mailing lists and IRC to inform the developers about things they should be aware of when coding. We also aim to have a call with another developer, before the code is written, so that there are at least two people thinking about the design.

Most of these discussions are made on public mailing lists, so that all the developers can see and be part of the discussion.

Thanks Bjorn!

0

Launchpad 3.0 release 22.00 UTC 23rd September 2009

Published by Matthew Revell September 22, 2009 in Notifications

Launchpad’s web interface will be read-only for around one hour from 22.00 UTC on Wednesday the 23rd September. During that time package uploads and code hosting will be offline.

Going read-only: 22.00 UTC 23rd September 2009
Expected back: 23.00 UTC 23rd September 2009.

During this time we’ll be releasing Launchpad 3.0! Details of the release to follow!

10

Removing Launchpad’s “Mentoring” Feature.

Published by Karl Fogel September 15, 2009 in General

Partial screen capture of a page showing mentoring

This is a last call for user experience data with Launchpad’s “Mentoring” feature for bugs and blueprints.

We’ve seen only limited usage of this feature, and haven’t gotten much positive feedback on it. Right now, it’s dropped from our 3.0 redesign; but before 3.0 is finalized, we’re interested in hearing people’s experiences with mentoring.

If you’ve used the Mentoring feature, either as a mentor or a mentee, please leave your feedback as a comment here. We’re particularly interested in answers to these questions:

  1. Would you say that Mentoring caused any difference in the rate of resolution between mentored and non-mentored bugs? (It could be a positive or a negative difference; both are interesting to us.)

  2. For people who offered mentoring: in your experience, did you have responses on your mentoring offers? Were you successful in integrating the mentee’s changes?

  3. Do you have any thoughts on how to improve the feature?

Please note: this is about Launchpad’s specific implementation of Mentoring, not about mentoring features in the abstract. We’re interested in your experiences with what’s actually been available in Launchpad. If a few people found the Mentoring feature useful, but most who tried it did not, then we will probably leave it out of Launchpad 3.0. On the other hand, if we hear something very unexpected from the feedback, that could affect our decision of course.

2

Xibo: open source signage

Published by Matthew Revell September 11, 2009 in Projects

Xibo is a free software signage system. I asked its lead developers, Alex Harrington and Dan Garner, about the project.

Matthew: So, does Xibo power the sorts of display we see in train stations and airports?

Alex and Dan: Yes, and in shops, post offices, schools, universities, colleges, churches or hotels. Anywhere there is a need to display information to the public or employees via a screen or projector. There’s over 150 Xibo installs worldwide that we know of, running 250 screens — however the Launchpad download stats suggest the actual install base is much larger.

Xibo allows organisations to build up collections of images, videos, RSS feeds, Flash, Embedded or External HTML and Microsoft Powerpoint presentations and combine them together into presentations which can then, in turn, be scheduled on to one or more of the displays attached to the Xibo system.

Matthew: We’re pretty used to seeing the Windows blue screen of death on public displays. In building Xibo, what have you done to ensure high uptime and to avoid rather public, embarrassing, error screens?

Alex and Dan: The current stable release of Xibo (1.0.3 at the time of writing) comprises a server application written in PHP and a client application written in C#. The client is written with resilience in mind, and is capable of operating over poor quality internet connections or running offline for periods of time.

The classic BSOD FAIL images from digital signs are often the underlying operating system crashing rather than the signage application itself. To that end, the client attempts to be as light as possible on system resources to keep the workload on the OS manageable – We have a production client running on a Via EPIA Fanless Mini-ITX system.

Looking forward, we have a new cross-platform (Linux/Win/Mac) client coming written in Python using the libavg engine which is guaranteed BSOD free! It uses OpenGL to do a lot of the screen rendering which opens up a lot of possibilities for cool-new-shiney-bits later on.

Matthew: What’s the competition for Xibo?

Alex and Dan: There’s huge competition in the digital signage market place, however we’re frequently told that our offering is better than a lot of the commercial signage applications people have used before. In terms of Open Source competition, there is the Concerto Signage Project who are based at the Rensselaer Polytehnic Institute and released under the GPL v2.

What we’re hoping to bring to the DS market place is a Free solution translated in to many languages with a thriving community of contributors working together to make Xibo the best it can be. An example is the new Xibo Layout Exchange. Here you can download contributed artwork for use in the Xibo system but eventually we plan to allow people to share whole bundles of content.

Matthew: Are you building a business around Xibo?

Alex and Dan: The Xibo application is Free and we have no plans to change that. There are many options available to monetize Xibo (content creation, hosting, support, custom development etc) but there’s nothing in the pipeline at the moment.

Matthew: Why did you select the AGPL 3 as Xibo’s licence?

Alex and Dan: Xibo is written with SaaS (Software as a Service) in mind. We’re very happy for businesses to take Xibo, rebrand it and sell it as a service to their customers, but the freedom needs to be two-way. We wanted a license that ensured that modifications these companies made would be accessible to the end user, for the greater good of the project. AGPLv3 offers us those things, while being compatible with a lot of existing library code.

Matthew: Is there a community of people interested in developing an open source signage system?

Alex and Dan: Xibo currently has two main developers. We’ve had code contributions from a few other people to date, but there’s a fair learning curve which presents a hurdle for prospective developers. We’re working towards a more modular architecture which will allow people to develop plugins to the server and client to extend it’s functionallity, which should lower the barrier to entry significantly.

There’s an active support community already in the Forum and in Launchpad Answers. We’re also taking art submissions for the Layout Exchange, and there is already a huge list of blueprints in Launchpad for future development, contributed by many people.

At least one of the developers is planning to be at LugRadio Live 2009 and Oggcamp in Wolverhampton later this year — just as a visitor, we aren’t exhibiting, but they’ll be suitably dressed so come over and say hello!

Matthew: Heh, see you there. So, why did you choose Launchpad?

Alex and Dan: We have used Sourceforge and Subversion before, but we wanted to use Bazaar for the RCS and Launchpad gave us Bazaar hosting and a good bug tracker. The translations support has been a huge bonus as has Blueprints and Answers. It rolls almost everything we needed in to one convenient package. It also acts as an OpenID provider so we can give the community secure access to edit the wiki and authenticate with the forum.

Matthew: What have you found particularly useful in Launchpad?

Alex and Dan: I think possibly the single most useful feature is merge request tracking – allowing us to fix bugs in individual branches and then queue the fixes up for merging later on. Answers has been great for doing user support – especially where there’s four or five of us helping someone it gives a good overview of which issues are outstanding, and a clear progression to a bug if needed. The bugtracker integration with bzr is great too for keeping track of where fixes went.

Matthew: What would you like to see added to Launchpad?

Alex and Dan: In the early days it would have helped us a lot if Launchpad had provided a wiki too. Now we’ve got our own system in place migrating over makes less sense though. I’d love to see a “Convert to Blueprint” button in Answers, as we get a lot of people making feature requests there.

Matthew: Thanks both!

Previous Entries
Next Entries