What Landscape Blog talks about

Posts tagged with 'design'

One of the first tasks I worked on when I joined the Landscape team in early 2009 was adding a progress bar to the activity page, to give an overall indication on the progress of a set of common activities. The original idea was that this progress bar would update automatically as activities got delivered to computers and computers reported back on their progress.

However, not all things happen as planned, and for a long time users were confused by staring at said progress bar and waiting for it to update, which it never did. Well. Not anymore! With our latest rollout, which happened earlier this week, we’ve finally introduced live activity progress updates!

I could write a thousand words about it, but I don’t think it would do justice to how amazing it is to see it in action. So I’ll let you see for yourself with a very short video (~1min long) demoing this nice feature (if you’re reading this post from an RSS reader, you might have to click through to see the video).

This is only one of the many user-focused changes we’ve been doing, and hopefully you’ll enjoy it as much as we do. Keep tuned for more updates.

One of the many things we worked on during this cycle was to improve our frontpage, where we worked together with the amazing folks from Canonical’s Design Team to deliver a revamped look with consistent messaging that better reflects where Landscape is positioned within the Ubuntu ecosystem. I consider this to be the “cherry on top” of our updated look-and-feel, which we’ve started rolling in back in November.

While we don’t have specific roles within the Landscape team (everyone is encouraged to work on all areas), my personal focus has for a while been on frontend performance, in addition to end-user experience, so I took up this challenge: can we deliver an updated frontpage with more content in less time?

Turns out that we’ve been incrementally improving our frontend infrastructure, applying best-practices recommended by frontend gurus like Souders and Zakas and some of our own, so after the new design was put in place we looked for more things that could be improved to reduce even further our page load time, which was already pretty good.

Our Javascript framework of choice is the excellent YUI 3, and we’ve structured our usage of YUI in such a way that modules are loaded and combined on-demand, so that we only load what’s needed and keep requests to a minimum. While looking at the requests being performed I noticed that we were unconditionally loading some things that are only used on internal pages (more on that in a later post), so getting rid of those was easy: restrict the loading of those additional modules so that they are only loaded if a specific DOM element (which we apply Progressive Enhancement to) is present in the page instead of always loading the module, but only using it if the element is there.

With that out of the way, the next thing to look for was how images were being loaded. Our new design, like the old one, contains 3 medium-sized images highlighting specific features of Landscape. The main difference, though, is that those images are placed much lower in the page, so that for the great majority of users out there they will not be above the fold anymore. A nifty YUI 3 module immediately sprung to mind: the ImageLoader. Even better, the documentation for it had two niftyexamples that could be combined to deliver the improvement we were looking for.

The end result? Check for yourself. We’ve managed to deliver a slicker, faster and better frontpage by a) reducing the number of requests by 2 for a fully loaded page, b) reducing the number of bytes transfered before ‘document complete’ by 96Kb (a 47.4% improvement) and c) reducing the time to a fully loaded page by 525ms (a 12.8% improvement).

Improving frontend performance is a neverending task, and we still have lots of things to work on. We are doing a pretty good job so far — with a load time of under 4 seconds now, even though we’re forcing SSL, we’re doing better than 80% of the websites out there according to Yottaa — but we are not resting on our laurels.

We recently announced our new user interface and today we released an updated cloud experience, which was designed as part of the refresh process. The new cloud experience has a different focus than what we had before. We want to satisfy two types of users:

Cloud operators are users that manage a cloud. They control an account on Amazon Web Services or an account on an Ubuntu Enterprise Cloud, and want to provide access to their users to make use of resources in the cloud(s) they control.

Cloud users are people that want to make use of cloud resources to run their workloads. This user would traditionally go to the IS department and make a hardware request to satisfy their needs.

The first step to try the new functionality is to register your cloud with Landscape.

The new user interface lets a cloud operator create resource groups, which are groups of related users, and to limit the number of instances a user can run at once. The system keeps track of how many instance hours each user uses and shows current capacity uses along with a graph to show usage history over time.

The user interface is split into two sections:

The cloud section, shown at the top, provides a high-level view of activity in a cloud, including the capacity being used and a graph showing the usage over time. The ‘Settings’ tab provides tools to configure the registered cloud.

The resource group section, shown below the cloud section, provides a view of activity in a resource group. Tabs provide access to tools to manage EC2 artefacts such as key pairs, security groups, elastic IPs, etc., and of course, to start and stop instances.

When a user has instances running they can be seen in the resource group they were started in.

When a cloud user is added to a resource group they receive an email invitation to join Landscape. Only cloud operators have access to the full functionality in the new user interface. Right now, cloud users can retrieve their credentials and the EC2 endpoint to use them with. They can use EC2-compatible tools such as euca2ools or ElasticFox to make use of the resources they have available to them. In the future, we’ll make the functionality in the new user interface available to cloud users, too.