Canonical Voices

Posts tagged with 'featured'

Tom Macfarlane

Last month at Mobile World Congress Ubuntu’s presence was stronger than ever. Our third year at MWC and we made some significant design changes to our stand.

In such a large exhibition space, strong branding is key. We designed five large banners – made from fabric and stretched across metal frames – that were suspended above the stand. Each banner was then individually illuminated by a series of spotlights creating maximum impact and high level brand presence, while still maintaining the stands open and welcoming feel.


The back walls and a new hanging aisle banner all featured the folded paper background with large graphics showcasing app and scope designs from the phone and tablet. We also dedicated one wall to the Ubuntu Carrier Advisory Group (CAG).


Continuing our clean and precise design approach we used the Ubuntu shape (the squircle) to create bespoke pods, reception desk and demo unit – with warm white LED down lighting around the top and base and lightboxes to illuminate the Circle of Friends on the reception desk.

CAN MWC Reception Desk RevA.vwx

Integrating elements from our phone and tablet design across print and 3D environments builds a strong brand/design coherence in everything we do. We’re very happy with the new stand design and feedback from MWC has been very positive.


Read more
Michal Izydorczyk

Ubuntu 14.04 LTS wallpaper


For the last couple of weeks we’ve been working on the new Ubuntu Wallpaper. It is never easy trust me. The most difficult part was to work out the connection between the old wallpapers and the new look and feel – Suru. The wallpaper has become an integral part of the ubuntu brand, the strong colours and gradated flow are powerful important elements. We realised this when looking from a distance at someone laptop it really does shout UBUNTU.

We spent some time looking at our brand guidelines as well as previous wallpaper thinking how to connect the old with the new and how to make the transition smooth. I did start with simple shapes and treated them as a separate sheets of paper. After a while we moved away from that idea simply because Suru is about simplicity and minimalism.
When we got the composition right we started to play with colours, we tried all our Ubuntu complimentary colours but we were not entirely happy. Don’t get me wrong ;) they did look nice but it didn’t feel like a next step from our last wallpaper…


And here some examples of the things I was exploring…


Read more
Daniel Oliver

Loving the bottom edge

The bottom edge is the most pleasurable edge to use. Grab a phone, any phone, and slide your thumb up over the bottom edge, then back. Go on, do it a few times. Feel good? Yeah, our extensive research suggests this feels pretty amazing to pretty much everyone.

Hmmm…. Feels good!

That’s why we’ve given the bottom edge to you, the developer, for your app. It’s the best one and we thought you could make the best use of it. If you want to create a truly “Ubuntu!” experience for your app you’ll want to invest in thoughtful but also creative interpretations of this edge in your app.

In fact, getting THIS ONE THING perfect is the most important thing you do when you bring your app to Ubuntu. Pretty much everything else is just… you know, obvious. But creating a bottom edge experience that is exactly perfect for your app and consistent with our values is where the magic happens.

Be perfect, be yourself, be exciting

There is no one answer for “the bottom edge”. There are definitely some values we can apply to judge if it’s a GREAT bottom edge, and there are several patterns that you’ll see, but you should start with a blank canvas and set yourself the goal of making your bottom edge experience YOURS.

Just to get the creative juices flowing, here are three great examples:

Think phases. Go beyond “one thing” in the gesture

The bottom edge swipe very naturally lends itself to what we call a “ranged gesture”. This is a gesture where going further does more. In other words, a great bottom edge will often be more than a simple transition. For example, you are unlikely to be great if you just reveal a toolbar, or pause a movie. You’ve got the opportunity to take several (well, two, at most three) logical “steps” on the way from the bottom edge up to the full stretch of the thumb.




When we design ranged gestures, though, we have to do a couple of things right to make them feel slick.

1. Make them connect smoothly

If your bottom edge gesture is going to have two phases, make sure that you pick two things which are related, so that the second one feels like a natural extension of the first.

A good example is the way we use the left edge: a little bit of left edge shows your *favourite* apps, a lot shows you ALL the apps. Seeing “all the apps” is a natural place to go if seeing your favourite apps wasn’t enough… it’s “more apps”. That makes a really good ranged gesture.

If the second phase was totaly unrelated to the first, it would feel jarring. Don’t do that!

Some examples of great ranged gestures:

  1. In a movie player, start with the player controls, then go further to reveal the chapter selection, and maybe even further to pop out of the movie to show other movies available on the device.

  2. In a map, use the bottom edge to zoom out. This is very sexy because the further you go the further you zoom, and zooming back is very naturally a tap where you want to zoom in.

  3. In a calendar, use the bottom edge to go from day to week to month to year view, like zooming out in time.

  4. In a turn-based game, use the bottom edge to pause the game and present game options.

  5. Go radial – present a radial menu of 5 top actions. Make it fade in beautifully so people want to use the bottom edge just to see those things show up. Make it fast so you just have to slide to one of them and release to invoke the action. Slick. Fast. Yum.

2. Be reversible. Let people change their mind easily.

Your user might not have intended to invoke the bottom edge, so it should always be possible for them to change their mind before they let go and slide back down, at which point their app is unchanged, they haven’t switched mode or done anything that they have to undo. Sliding back down is like saying “Oops, not down this corridor!” and you should respect that perfectly.

So, don’t pause or commit to any change until the finger is lifted off the screen – make sure that someone can unwind the use of the edge just by changing direction.

Actually… I don’t need to create a new note

3. Make it visually sexy

This is a FANTASTIC opportunity to show off some really beautiful visual design and motion graphics skills. A really beautiful set of transitions or effects will make people say “ooooh!”. If you get this really right, you’ll see people showing their friends that experience. “Check this out!”. “Ooooooh”. “Do it again!”. “Aaaaah.”, “Can I try?”…. that’s what you want to get when you show it to friends and family before you reveal it to the world.

Trust us, there are a million options for you, but to make it really work well will take a lot of thought and testing…. but it’s definitely worth it! Remember the “desktop cube” and how much fun it was to show people that? Now imagine getting the same reaction to your bottom edge… that’s what you’re shooting for.

The very best bottom edge experience will have movement associated with every tiny move of your finger. It will feel “on rails”, as you move your finger up it feels like you are totally in control of the scene that is unfolding, all the way up to the point where the final phase of your experience “clicks” into place, the final commit.

4. Hint, reveal, commit

We have a pattern we call “hint, reveal, commit”. For any substantial change that a gesture might drive, we want first to hint that it will happen, then we want a stretch of the gesture which reveals the first part of the change without actually making it happen, and finally we want a “click” which is the commit.

hint reveal commit A good example is the launcher. First, we show a shadow. If you just tap at the edge, all you see is that shadow, briefly. That’s the hint. There is “something on the edge”. If you slide a little bit from the edge, you start to see the launcher and the app dims slightly. That’s the reveal, it tells you what’s coming, but still lets you change your mind. And finally, before the launcher is fully revealed, there is a point at which it “clicks” into place. That’s the commit. Letting go of the screen after the commit, you KNOW you will have the launcher.

left edgeHint. Reveal. Commit.

Now, here’s the fun part. With a ranged gesture, you want to think about hint, reveal, commit for EACH PHASE of the gesture. It’s OK for the commit of one phase to immediately give you a hint of the next – you are, after all, in mid-gesture. In fact, that’s what we usually do ourselves, we show the second phase hint at the same time as the first phase commit.

The reveal is usually the place where  you want to make it feel like the user is in total control: have something that tracks the movement of the finger up the screen; it could be fading something in, or moving something in response to that movement. The important thing is that every tiny movement of the finger should reveal more, or less, until the commit.

Prioritise. Really, PRIORITISE

You have one bottom edge. Only one. It’s the sexiest thing for a user to do. They can even do it without looking where they are pressing – it’s an instinctive thing, pure muscle memory.

So you should think carefully about what’s REALLY IMPORTANT and CENTRAL in your app. Maybe there is something that the user will do all the time and you want to make it easy for them to do it fast, no hunting and pecking for buttons. Maybe there’s a natural “zoom out” expression in your app (those are usually good if you can make them beautifully visual). There is only one first phase to your bottom edge, it’s the first thing people will try – make it great, choose wisely!

quick draw

Provide a visual cue

Having a magical bottom edge that nobody discovers is no fun at all!

We can’t guarantee that every app will use the bottom edge. Some apps will be so straightforward that a bottom edge experience would be superfluous – just for show. And we don’t want that.

So users can’t be CERTAIN there is a bottom edge worth trying. That’s risky, because if they try  it a few times and get no result, they’ll stop trying it for apps which DO have a great bottom edge. So, you want to provide some sort of cue that it’s worth their while to give it a go.

Sometimes you can provide that cue as part of a transition into the app. You could show the stuff that’s in there, and animate it away into the edge after a few seconds during the app launch, so people know its there. That might be enough.

You might also want to leave a visual cue on the screen all the time. If you do, though, keep it REALLY small. Just a hint, just a clue, just a taste. For example, you might have a teeny little tab with a (+) on it if that edge holds the magic for adding something. Or you might have a teeny tab with the word “London” on it, if the bottom edge will reveal more cities, starting with London. Or just a highlighted line might do the trick.

visual hint

Be creative on the cue. Make it fit with the story you are telling. There are a million possibilities and only one is best for your particular design. Have fun, but don’t forget the cue!

Common patterns

Yes, if you’re stuck for inspiration, there are a few common patterns you might want to consider. We put this LAST because we really think you want to be inspired by the essence of YOUR APP, not just following a pattern that works elsewhere, in case you miss a chance to invent something really great for yourself and for others.

Zooming out

Many apps have the idea of an “outer” layer, or levels. Maps are an obvious case, calendars also have the idea of a “wider view” (days, weeks, months, years). But the concept of “taking a step back from the coal face” is very common. For example, in a word processor, you might step back to switch between files. In a browser, you might step back to switch between tabs. In a game, you might step back to change settings or invite a friend to play. In Evernote, stepping back from the current note might show you other notes in the same album, or other albums altogether.

By scaling down the content (objects, time, space) we offer a quicker way to navigate across large amounts of content. Step back, go HERE is a great way to get around.

zoom out


If your app has two, and only two, main faces, then the bottom edge is a fast, controlled way to switch between them. You can do a nice cross-fade, or a page-over effect that makes the user feel in control.

2 faces


If your app has a set of controls – for example, a music player – then the bottom edge might be a great way to bring those smoothly onto the screen.

A great idea is to think carefully about the various controls, and have a ranged gesture which reveals steadily more. For example, first just play, pause, back and forward, then things like chapter selection which provide a broader view of the content.

Quick draw

Your app may have a particular thing that you want people to be able to do instantly, with nothing but a reflex reaction. For example, a note-taking app might use the bottom edge as a quick-draw “new note” facility.

quick draw

Make it great!

This is bottom edge is something unique to Ubuntu – we’ve given it to you because it really is the prime edge from a user perspective, and the app has all the user’s attention. It’s worth taking time to think carefully, try a range of options, test them on your friends, and craft it beautifully.






Read more
Inayaili de León Persson

Ubuntu Resources — beta!

Today we’ve released a new version of Ubuntu Resources with some new functionality and design improvements, and we’ve now moved from alpha to beta!


We asked visitors to the site to give us their feedback based on their visits on their mobile devices, and we received lots of useful comments since we launched the alpha version of the site in November.

Several of the comments focused on the same themes, which became our areas of focus for this release, such as:

1. Understanding which site you are visiting

Because of the way we were using the Circle of Friends roundel without the “ubuntu” wordmark next to the word “resources”, many people didn’t understand that was the name of the site. In this iteration, we went back to using the standard brand extension, reducing the overall size of the logo and making that more clearly the title of the site and homepage link.

Navigation before and afterNavigation before (left) and after (right).

New landing pages

2. Understanding the variety of content that the site has to offer

Some people thought they had landed on the “Ubuntu Blog”, because of the way the homepage and other topic pages were laid out.

We’ve designed landing pages that are more curated and show the most recent and featured content with the option to see all archived content related to that topic near the bottom of the screen.

3. Learn more about the topics presented (cloud, server, etc.)

A common mistake when designing for brands you’re familiar with is to think other people will have the same understanding of it as you do.

Some people that we showed the site to and that were not too familiar with Ubuntu or Canonical did not understand exactly what we meant by “Server” or “Ubuntu on phones”, for example. Links to learn more about these topics used to be at the bottom of screens, so we moved that content to the top of the topic landing pages for easier access if you’re new to the subject.

Topic introsNew introductions to the topics.

Learnings from

With the launch of the new Canonical website in January, we changed the way some of our small screen patterns work:

  • We’ve updated the font sizes, so they are now slightly larger
  • We’ve updated the background of the pages
  • We’ve change the way content is divided, reducing the number of lines and using different blocks of colour instead

These were fed back into Ubuntu Resources so that we can keep our patterns as consistent as possible across sites.

In terms of the less visible updates, we’ve also:

  • Improved the pre-populated messages when content is shared
  • Tweaked the style of the tags which can be used to navigate the site
  • Fixed some bugs in the rendering of SVG icons

Next steps

In the next iteration of the site, we will be focusing mainly on layout improvements for medium sized screens (think tablets), as at the moment the site is still only displaying the small screen style sheet regardless of screen size.

We’ve already started to improve the search functionality, so that it’s possible to filter search results, but visitors should only be seeing these changes in the next release, in a few weeks.

Once we’ve built the site to scale up to large screen sizes smoothly, and have integrated all the top-priority functionality, the plan is for it to replace the current Insights website.

If you haven’t checked it out yet, head to Ubuntu Resources and feel free to send us your comments via the feedback link in the site’s footer.

Read more
Vesa Rautiainen

In January when the winter weather was at its worst in London we packed our laptops, designs and prototypes and headed to Cape Town, South Africa for Client Platform Sprint. This design sprint was a mid cycle checkpoint and the target was to get some important 14.04 designs, including Dash and Right edge swipe, reviewed and finalized.

It was an intense week with lots of review sessions and a tight schedule. But after the day’s work was done we tried to make most of our time in this astonishing place. The trip wouldn’t have been complete without visiting those vineyards, white-sand beaches and of course THE Table Mountain.

All in all it was a great work week in the sun with some bits of free time activities. Easily beats a regular week at the office. Some pictures from the trip:

Right Edge designRight Edge design

Trying to nail the DashTrying to nail the Dash

Camps Bay

Camps Bay

Table Mountain

Table MountainCape Town

Read more
Bejan Alizadeh

Sheets transition

We’ve recently been exploring how the share transitions should work when you’re previewing a photo in gallery mode. Our main goal is that there is a consistent transition for sharing photos across the phone.

This is the latest iteration of the explorations we’ve been doing, and, as such, these transitions are still work in progress, but certainly worth sharing.

Step by step

Video: Sharing a photo in photo gallery mode

The first transition happens when you select “Share” from the toolbar. This takes you to a ‘content picker’ mode where you can select where you’d like to share your photo (Facebook, Twitter, etc.).

The intention is that the ‘content picker’ transition is similar to the ‘page stack’ one — which takes you deeper into the app — but because you’re going into a ‘content picker’ mode the transition needs to be slightly different. That difference is the direction: instead of going from right to left it goes bottom to top.

Once you’ve selected how to share your photo, the screen splits slightly below where you’ve tapped (in the example, below Facebook), and there is a subtle transparency fade so that the transition is less jarring.

In the next step, the transition takes you to an embedded Facebook share page, where you can write a description about the photo you’re posting. Once you select the description box, the OSK keyboard comes from the bottom to top, something that is always consistent across the phone.

When you click “Post”, a similar transition to the selecting share transition, but reversed, takes you back to the photo.

Your feedback

As I’ve mentioned before, this is still work in progress, but we’re really interested in hearing your thoughts — let us know what you think in the comments.

Read more
Inayaili de León Persson

New year, new website: the new

We’ve been talking about it for a while and we are now happy to reveal Canonical’s brand new website.

The brief

We thought that it was more than appropriate that, in the year that Canonical commemorates its 10th anniversary, our website got some love, so that’s exactly what we set out to do.

Canonical on devicesThe homepage of the new on various devices

The main goal of this redesign was to create a website that clearly communicates what Canonical is and does. To present our services, describe our role in the creation of Ubuntu and to give users an understanding of the principles behind Canonical as a company.

The journey

We set out to distill the Canonical site into its most essential components. This required a huge amount of editing as the site had grown over time. This was not a straightforward task, but there were a few things that we knew would get us very close to that goal:

  • Clearly define’s audiences and make sure the new site’s content was created with them in mind
  • Move the content that dates easily (events, news, etc.) from the site to a searchable repository
  • Move all detailed product and service information to to make it more easy to find

We started preparing to move a lot of the content that previously lived on the site a few months ago when we started the Ubuntu Resources project — a place for content such as news, events, press releases, white papers and case studies.

Ubuntu Resources (currently in ‘alpha’) is also our first responsive site, and a lot of the lessons we have been learning from it, code- and design-wise, have been applied to the new, like the small screen site navigation and the global Ubuntu sites navigation.

Carla has published a very interesting post on how she used stakeholder interviews to define the website’s key journeys and audiences. This research was instrumental in keeping the content of the site focused and the information architecture as simple as possible.

Before moving onto a digital format, we did a lot of collaborative sketching, churning out ideas on how we could illustrate each page’s message.

Sketching ideasGenerating ideas: some of our sketches

Even though we were working towards a fairly tight deadline, we went through several content, design and code iterations, with copywriters, designers and developers working closely together and improving as much as possible until we were happy with the results.

Canonical status boardOur ever-changing analog status board — sometimes only sticky notes will do!

The visual design borrowed most of the underlying patterns from, such as the grid and font sizes. Ubuntu’s website has been evolving into a more ‘open’ design and the new Canonical website takes that idea even further by removing the main content container and increasing spacing between elements.

We also brought in new patterns, influenced by the design work that is being done on the phone and tablet, like the grid used in small screens, the Ubuntu shape (the squircle) and the folded paper background.

Phone patterns on canonical.comUsing the squircle and the folded paper background on the new

The result

We’re very happy with the result, and we think it achieves the goals we set out to accomplish. Now that the site is launched though, it’s up to everyone who visits it to let us know how we did: do let us know your thoughts in the comments!

Read more
Bejan Alizadeh

Messaging interaction

We’ve currently been working on user interaction for sending and deleting multiple SMSs and we thought it would be nice to show you where we’re going with it.

Here are some of things that we’ve had to consider when making these interactions user friendly:

  • making sure the transitions fit within our paper metaphor — for example, when you select a message thread we wanted it to feel like it’s taking you deeper into the app
  • just like with the visual assets, transitions also need to be consistent — for example, whenever you’re diving deeper into any app the transition should be similar
  • making room for scrolling and seeing more messages without the keypad taking too much space
  • making sure it’s clear when a message is pending
  • initial exploration into how to navigate back within an app

Video: Sending messages

Video: Deleting messages

As with many of the current interactions, these are work in progress — we’ll be keeping you updated with any further developments.

Read more
Carla Berkers

I’d like to share my experience working on the project that has been my main focus over the past months: the redesign of

Research methods

As I started talking to people in the design department I quickly discovered we have a lot of information about our site visitors. My colleagues helped me access Google Analytics data and findings from previous user testing sessions. There was also a research-based set of personas, that helped me to put together an initial overview of user needs and tasks.

I was curious to try to validate these user needs and test them against Canonical’s current business requirements. In order to find out more about the company goals I prepared a stakeholder interview script and started putting together a list of people to talk to. I initially planned to limit the number of interviewees to about six to eight stakeholders, as too many opinions could potentially slow down the project and complicate the requirements.

Getting to know the company

I started with eight people to talk to, but with each interview I found out about other people that I should add to my list. At the same time, many of the interviewees warned me that every person I would talk to would have different ideas about the site requirements. By the end of the first round of interviews, ending up with too many stakeholders turned out to be the most commonly mentioned risk to endanger the project finishing on time.

I had very diverse conversations about different aspects of the site with a range of people. From strategic insights from our CEO Jane, to brand guidelines and requirements from our Head of Design Marcus and ideas around recruitment from our HR business partner Alice — each conversation brought unique requirements to light.

After I spoke to about fifteen people I summarised the key points from each stakeholder on post it notes and put them all up on a wall in one of the meeting rooms in the office. As I took out the duplicates and restructured the remaining notes, I began to see a familiar pattern.


When I finished grouping the different audiences, I ended up with five groups of users: enterprise customers, (potential) partners, job seekers, media (a varied group that includes press, tech analysts and bloggers), open source advocates and the more generic tech enthusiasts that want to know more about the company backing Ubuntu.

As these groups aligned very well with the persona’s and other pieces of research that I had found, I felt comfortable continuing my process by moving on to the user needs and site goals that will help build a good site structure and generate useful content for each group of users.

I found that talking to many experts from within the company helped me quickly understand the full range of requirements, saving me time rather than making my job more complicated. Furthermore I was happy to get a chance to get to know people from different parts of the company so soon after I got started.

In order to keep the project moving forward, we appointed one key stakeholder to sign off each step of the process, but I’m looking forward to showing the end results to the broader group to see if I managed to meet all their expectations. We will also conduct user-testing to ensure the site answers our core audiences questions and allows them to complete their tasks.

I hope to share more about this project in the months to come.

Read more

The new Ubuntu icons

During last month’s vUDS we showcased the latest design explorations for the new Ubuntu icon theme. Here is a summary of what we presented.

Our objectives

This project’s main goal is to create a single modern, high-resolution icon theme for desktop and touch devices that can adapt to various screen densities and reinforces the Ubuntu user experience. We want our icons to express our values and convey Ubuntu’s personality in a unique way.

We already had mobile icons for the applications and symbols, but, because they evolved over time without strong guidelines, did not form a consistent set. On the desktop, even though the style is clean and consistent, the icons looked dated and needed to be replaced too.

Previous desktop icons
Previous mobile and monochromatic iconsThe previous version of desktop, mobile and monochromatic icons

New icons

We’ve been working on this on-going project for the past year. We’ve done extensive research on the subject with a focus on learning how best to classify the icons; and we’ve gone through several design iterations and explorations.

So here is the latest iteration of the new icon set. As I’ve mentioned, these are all still subject to change as we’re constantly improving and refining the designs.

Latest application iconsLatest application icons

Latest symbol iconsLatest symbolic icons

Icons in contextIcons in context — one of the latest design explorations of the dash

Next steps

The goals for 14.04 are to provide a new icon theme for mobile and tablet, and to provide guidelines with templates to help people to design consistent icons for their apps. We’d like to eventually implement the new set on the desktop too.

We’ve had lots of good feedback so far, and we’d like to get even more, so please let us know your thoughts in the comments!

Read more
Christina Li

App Design Clinic #6

We have been running the app design clinic every two weeks to answer any questions from community designers and developers on the apps they are working on!

For this session we talked about the community submitted convergence designs for file manager and clock app (thanks everyone!) as well as answering some questions from our Canonical engineers submitted apps, such as:
- If your app has two equal actions- how do you provide entry points?
- What if I want to show more content, but page stack is not appropriate?
- Where should ‘About’ & ‘Settings’ go? (Not in the tabs, please)

If you missed it, or want to watch it again, here it is:

Please send your questions and screenshots to by 1pm UTC on a Tuesdays to be included in the following Wednesday clinic.

Watch this space for our next App Design Clinic time.

Read more
Christina Li

On 19-21 November we had our vUDS where we got to discuss and share with the community some of the design work we’ve been doing recently.

Our topics ranged from our design blog to convergence designs to Juju GUI cloud to icon designs!

If you missed any of our sessions, don’t worry. They are all below for you to check them out!

Design Blog

Love our blog? How can we make it better? What topics would you like to see?

Responsive Design

Hear about our thoughts on converging our patterns, components and designs from phone to tablet to desktop.

App Design Clinic

Every two weeks, we gather to talk about app designs and patterns. If you are developing an app or have any questions on apps, let us know!

Designing a responsive website and web guide

We talked about the process of designing a responsive website and shared the current web style guide we have been using for the main site.

Research on Windows and Android usability

Juju GUI design evolution

User research has informed the way Juju GUI has changed over the last year. Here is the evolution of Juju GUI.

Designing icons for Ubutnu

We have been designing icons for Ubuntu Phone and Tablet and Desktop. Check them out!

Let us know what you think, or suggestions on what you want to see next from the Design team at the next vUDS!

Read more

Juju ice-cream icon design

Who doesn’t like ice-cream? Here in the design team we sure do! In the last few weeks we’ve been preparing a special Juju demo for the OpenStack Summit in Hong Kong and we’ve created some very ‘tasty’ icons for it. We thought it would be nice to show you how those icons were created, so here’s a little insight on the design process.

The brief

We wanted to replace the normal Juju icons for something a little bit more special in order to explain to people that visited the Ubuntu stand what kind of things Juju can do. We decided to use the idea of an ice-cream with toppings and sauce which you can build in the same way that you can build services in Juju.

The best part of this demo is that people would actually get the ice-cream they had ‘built’ in Juju in real life!

JujuThe Juju interface, with its default icons

Finding good concepts

The first thing I needed to do was to find good concepts to present ice-creams and toppings in an icon format. Toppings were going to be especially tricky, as they can be very small and therefore hard to make out at small sizes.

I initially sketched and designed some ideas that were using a kind of flat look. This worked well for the ice-cream, but not so much for the toppings — I soon noticed they had to be semi-realistic to be recognisable.

Initial flat sketches
Initial version of the Juju ice-cream iconsInitial sketches and designs following a flat and more simplified look

At a second stage, I added perspective to the icons; it was important that the icons kept the same perspective for consistency.

Sketches with added perspectiveAnother set of sketches with added perspective

The shape of the sauce bottles was also something that needed a bit of trial and error. The initial design looked too much like a ketchup bottle, so we’ve decided to try a different approach.

Before and after sauce bottle shapeBefore and after shape of the sauce

For the backgrounds, I chose to use vibrant colours for the ice-cream icons, to contrast with the ice-creams’ monochrome palette, but paler colours for the toppings, as these are already quite colourful.

The amount of detail added to the icons is just enough for what we needed to show and for them to be recognised. I’ve also added larger pieces to the side of the toppings, to make them easier to be identified.

Juju Oreo toppingThe Oreo topping icon, with a side of Oreos

Working out the detail

The Oreo pieces were created from a single biscuit, which I cut into 9 different parts and then distributed in different layers — I guess in a similar way to what happens in real life.

9 Oreo piecesThe 9 pieces used to create the icon

The clone tool in Inkscape came in handy: repeating the same small set of different pieces made the final SVG file much lighter, and also Inkscape faster.

The whole process took 4 days from brief to final icons, which is quite a tight deadline, but it was a really fun project to work on.

Final icon setThe final icon set

Read more
Inayaili de León Persson

The new Ubuntu Resources

Today we’ve launched the alpha version of our latest project: the Ubuntu Resources website.

This is our first responsive project that follows the mobile-first methodology and we’re very excited to share this with everyone!

As you’ll be able to see, we’re not quite done with it yet, but we wanted to share what we’ve created so far, so we can get feedback and keep improving the design and expanding the features.

Ubuntu Resources on a phoneThe new Ubuntu Resources on an Ubuntu-powered phone

A little bit of background

This project grew from the need to separate content like case studies, news, press releases and events, from the core of the Canonical and Ubuntu sites — and it will eventually replace much of what currently is at As the site is designed for reading and engaging with longer pieces of content, we thought it would be the ideal place to explore mobile-first and responsive approaches. And we plan to use what we’?ve learned from it to make and our Web Style Guide responsive.

Scaling things down

We started the research phase taking a holistic view of the project, trying to understand what types of content and users we wanted to target. We realised that with limited time and resources we would have to divide the project into different releases, so that we could make sure each aspect of the site was given the attention it deserved.

The first and current release of the site — alpha — focuses solely on small screens. The main goal is that all the content is accessible and the visual style and features will be progressing and being added as we go.

WireframesInitial wireframes across a variety of screen sizes

Reusing existing styles

One of the challenges in this project was deciding how we were going to integrate the existing Web Style Guide, which we’ve been using internally for a while now and will be made public on soon.

Ubuntu Web Style GuideSneak peek of our Web Style Guide

We decided to use a minimal version of the style guide that kept the Ubuntu Resources’ style coherent with and that we could improve on.

You’ll also notice small details that align with our phone design, like the grid, navigation selection and icons, and we’ll be adding even more in the upcoming releases.

What’s coming

Apart from working on the larger screen versions of the site, some of the things we will be looking into for the next iterations are:

  • the ability to subscribe to different types of content
  • more curated topic landing pages
  • content filtering and sorting
  • cleaner URLs
  • the way we handle PDFs and other file formats
  • more content like a press section

Go and have a look at the site and let us know your thoughts. We want to know what you like and what you think can be improved, or any other comments you might have — we’ve included a handy link to the feedback form at the bottom of every page. Enjoy!

Read more
Christina Li

November Brown Bag lunch

Some of us in the Design team have been gathering on a monthly basis to have lunch together and share things we find interesting to us.

Today, I’d like to share with you the Brown Bag lunch we had this week.

Vesa shared with us his interest in photography and showed us some of the shots he took over time.

9690256316_8c4040a4bb_bWestminster at night by Vesa (flickr)

I came across an inspiring research done by Helen Hamlyn Centre for Design at the Royal College of Art in London. The research focused on facilitating older people using mobile phones, rather than designing a simpler phone for them to use.

And, our challenge of the month was to build the tallest paper tower! Each team had 20 pieces of paper and 6 minutes, with 2 rules:

1. You can only use paper to build your tower
2.You can tear or fold the pieces of paper.

Well, I’m happy to report that Rachel, Vesa and Olga proudly won this challenge with their paper tower!

photo (2)

How would you build your tower in 6 minutes?

Read more
Tingting Zhao

In the previous post, we talked about how to design effective user testing tasks to evaluate the usability of an interface. This post continues with this topic by highlighting a number of key strategies that you may need to use when conducting a formative user testing, whose main aim is to identify usability problems and propose design solutions, rather than compare quantitative metrics (summative testing), eg. task completion time and mouse clicks. It is unlikely that the prepared task script could be strictly applied without any changes, since the testing situation tends to be dynamic and often unpredictable. To get useful data, you need to be able to manipulate your task script with flexibilities, while also maintaining consistency.

Changing task orders during testing

Normally, to avoid order effect, the issuing of the tasks should be randomised for each participant. Order effect refers to the effect in which the tasks are presented, which can affect the results, specifically: users may perform better in later tasks as their familiarity with the interface increases; or users may perform worse as they become more fatigued. However, as discussed in the previous post, the tasks are often contextual and dependent on each other, so you need to carefully consider which tasks could be shuffled. For example, it is a good practice to mark on the script to indicate dependent tasks, so that you know these tasks should not be reordered and separated from each other. In other words, the dependent tasks must always be moved together. It is worth noting that the randomisation of task orders may not always be possible for a testing, for example, when the tasks are procedurally related, such as a testing focusing on payment flow.

Sometimes you may need to change the task orders by considering their levels of difficulty. This is useful in the following two scenarios: when you notice a participant appears to be slightly nervous before the testing has started, provide a simple first task to put him/her at ease; or when you observe a participant has failed to solve several tasks in a row, provide one or two easy tasks to reduce the frustration and stress, and boost confidence.

Another type of changing task order is made in response to users’ solicited goals that are associated with a coming task. For example, in one phone testing, after a participant checked the battery level, s/he spontaneously expressed a desire to know if there was a way to switch off some running apps to save battery. In this case, we jumped to the task of closing running apps, rather than waiting until later. This makes the testing feel more natural.

Remove tasks during testing

There are typically two situations that require you to skip tasks:

  • Time restriction

  • Questions being answered with previous tasks

Time restriction: user testing normally has a time limit. Participants are paid for certain lengths of time. Ideally, all the tasks should be carried out by all the participants. However, sometimes they take longer to solve tasks. Or you may discover areas that require more time for investigation. In this case, not all the tasks could be performed by a participant within the given time. Subsequently, you need to be able to quickly decide which tasks should be abandoned for this specific participant. There are two ways to approach this:

  • Omit tasks that are less important: it is always useful to prioritise the tasks in terms of their importance – what are the most important areas that have key questions that need to be answered and require feedback; what could be left for the next testing, if not covered this time?

  • Omit tasks that have already received abundant feedback: skip the tasks from which you have already gathered rich and useful information from other participants.

Questions were answered with previous tasks: Sometimes questions associated with a specific task would be answered while a participant was attempting to solve the previous task – in this case, you could skip this task.

In one of our phone testings, we asked a participant to send a text to a non-contact (a plumber). During the task-solving process, s/he decided to save the number to the contact book first and then send a text. In this case, we skipped the task of ‘saving a number to contact book’.

However sometimes you should not skip a task, even if it might seem repetitive. For example, if you want to test the learnability and memorability of a feature, having the participant perform the same task (with slightly different descriptions) for the second time (after a certain time duration) could afford useful insights.

Add tasks during testing

There are three contexts in which you could consider adding tasks:

  • Where the user formulates new goals

  • Re-examinations

  • Giving the user a second chance

The added task must be relevant to the aim of the testing, and should only be included if the testing time permits.

User formulates new goals: you could add tasks based on user-formulated goals in the task solving process.

For example, in one phone testing, one participant wondered if s/he could customise the tiles on the Windows phone’s home screen. We made this an added task for her/him. Adding tasks based on user articulated new goals follows their thought process and make the testing more natural. It also provides opportunities for us to discover new information.

Re-examinations: sometimes the users may succeed in a task accidently, without knowing how s/he did it. In this case, the same task (with a slightly changed description) could be added to re-assess the usability.

For example, in one phone testing, we had one task: “You want to call you sister Lisa to say thank you for the phone”. One participant experienced great difficulties in performing this task, and only completed it after a long time and by accident. In this case, we added another task to re-evaluate the ease of making a phone call:

“Your call is cut off while you are talking to your sister, so now you want to call her again.”

Similarly in the Gallery app testing, where participants managed to add a picture into a selected album accidently, we asked them to add another picture into a different album.

Re-examination allows us to judge accurately the impact of a problem, as well as to understand the learnability of interface – the extent to which users could detect and learn interaction patterns (even by accident), and apply the rules later.

Giving the user a second chance: in the majority of the user testing, participants used the evaluated interface for the first time. It could be very demanding for them to solve the tasks successfully in their first attempt. However, as the testing progresses, participants might discover more things, such as features and interaction patterns (although possibly by accident). Consequently, their knowledge of the interface may increase. In this case, you could give them another chance to solve the task that they failed earlier in the tests. Again, this helps you to test the learnability of the interface, as well as assess the impact of a problem.

For example, in a tablet testing, one participant could not find the music scope earlier in the testing, but later s/he accidentally discovered the video scope. To test if s/he now understood the concept of dash scopes, we asked the participant to find the music scope again after several other tasks.

Change task descriptions (slightly) during testing

Information gathered from pre-testing brief interview and participants’ testing verbal data could often be used to modify the task description slightly to make the task more realistic to the users. This also gives the user the impression that you are an active listener and interested in their comments, which helps to build a rapport with them. The change should be minor and limited to the details of the scenario (not the aim of the task). It is important that the change does not compromise the consistency with other participants’ task descriptions.

For example, in a tablet testing, where we needed to evaluate the discoverability of the HUD in the context of photo editing, we had this task: “You want to do some advanced editing by adjusting the colour of the picture.” One participant commented that s/he often changed pictures to ‘black and white’ effect. In response to this, we changed the task to “You mentioned that you often change a picture to black and white, and now you want to change this picture to ‘black and white’”. The task change here does not change the aim of the task, nor the requirements for solving the task (in this case, the access to the HUD), but it becomes more relatable to the participant.

Another example is from a phone testing. We changed the task of “you want to go to Twitter” to “you want to go to Facebook” after learning the participant uses Facebook but not Twitter. If we continued to request this participant to find Twitter, it would make the testing become artificial, which would result in invalid data. The aim of the task is to evaluate the ease of navigation in finding an app, therefore changing Twitter to Facebook does not change the nature of the task.


This post outlines a number of main strategies you could use to modify your task script to deal with typical situations that may occur in a formative user testing. To sum up:

Changing tasks orders: randomise tasks for each participant if possible, and move the dependent tasks as a whole; consider the difficulties of the task and issue an easy task to start with if you feel participant is nervous, or provide an easy task if participants failed several tasks in a row. Allow them to perform a later task if they verbalise it as a goal/strategy for solving the current task.

Remove tasks: if time is running out with a particular participant, omit certain tasks. This could be tasks with low priorities; tasks that already have enough feedback from other participants; or tasks the participant has already covered while attempting a previous task.

Add tasks: if time permits, allow users to perform a new task if it is a user initiated goal and is relevant to the testing; repeat a task (with slightly different wording and at an appropriate time) if the user succeeds in a task accidently, or has failed this task earlier, or if the aim is to test the learnability of the system.

Change task description: slightly amend the details of the task scenario (not the aim of the task) based on users’ verbal data to make it more relatable and realistic to the user. This will improve the reliability of the data.

If you have other ways to maneuver the tasks during the testing session, or have situations you are unsure about, feel free to share your experience and thoughts.

Read more
Anthony Dillon

I was recently asked to attend a cloud sprint in San Francisco as a front-end developer for the new Juju GUI product. I had the pleasure of finally meeting the guys that I have collaboratively worked with and ultimately been helped by on the project.

Here is a collection of things I learnt during my week overseas.

Mocha testing

Mocha is a JavaScript test framework that tests asynchronously in a browser. Previously I found it difficult to imagine a use case when developing a site, but I now know that any interactive element of a site could benefit from Mocha testing.

This is by no means a full tutorial or features set of Mocha but my findings from a week with the UI engineering team.

Breakdown small elements of your app or website its logic test

If you take a system like a user’s login and register, it is much easier to test each function of the system. For example, if the user hits the signup button you should test the registration form is then visible to the user. Then work methodically through each step of the process, testing as many different inputs you can think of.

Saving your bacon

Testing undoubtedly slows down initial development but catches a lot of mistakes and flaws in the system before anything lands in the main code base. It also means if a test fails you don’t have to manually check each test again by hand — you simply run the test suite and see the ticks roll in.

Speeds up bug squashing

Bug fixing becomes easier to the reporter and the developer. If the reporter submits a test that fails due to a bug, the developer will get the full scope of the issue and once the test passes the developer and reporter can be confident the problem no longer exists.


While I have read a lot about linting in the past but have not needed to use it on any projects I have worked on to date. So I was very happy to use and be taught the linting performed by the UI engineering team.

Enforces a standard coding syntax

I was very impressed with the level of code standards it enforces. It requires all code to be written in a certain way, from indenting and commenting to unused variables. This results in anyone using the code, being able to pick up it up and read it as if created by one person when in fact it may have contributed by many.

Code reviews

In my opinion code reviews should be performed on all front-end work to discourage sloppy code and encourage shared knowledge.

Mark up

Mark up should be very semantic. This can be a case of opinion, but shared discussion will get the team to an agreed solution, which will then be reused again by others in the similar situations.


CSS can be difficult as there are different ways to achieve a similar result, but with a code review the style used will be common practise within the team.


A perfect candidate as different people have different methods of coding. With a review, it will catch any sloppy or short cuts in the code. A review makes sure  your code is refactored to best-practise the first time.


Test driven development (TDD) does slow the development process down but enforces better output from your time spend on the code and less bugs in the future.

If someone writes a failing test for your code which is expected to pass, working on the code to produce a passing test is a much easier way to demonstrate the code now works, along with all the other test for that function.

I truly believe in code reviews now. Previously I was sceptical about them. I used to think that  “because my code is working” I didn’t need reviews and it would slow me down. But a good reviewer will catch things like “it works but didn’t you take a shortcut two classes ago which you meant to go back and refactor”. We all want our code to be perfect and to learn from others on a daily basis. That is what code reviews give us.

Read more
Rosie Zhu

Since we released the initial demo of Ubuntu on phones, we’ve been looking at refining the whole Suru theme — the theme on Ubuntu for phones and tablets — and creating visual guidelines for it.

Two of the things that we evolved were the treatment of the indented style and the corner size of the Ubuntu shape — the squircle. We wanted to make sure these were consistent across the theme so that any designer and developer could follow the same guidelines.

The Ubuntu squircle shapeThe Ubuntu squircle shape


There were lots of discussions about what kind of shadows we should use — blurred shadows, sharp shadows or a combination of the two — to represent the indented style, and we went through various iterations.

Variations on grey backgroundVariations on grey

Soon after we started looking into the indented style we decided to look at the corner size of the shape at the same time, as they work together. Since the squircle is not an ordinary shape, it can’t just be scaled up and down as needed, so we arrived at four different corner sizes that can be used in the different sizes necessary across the theme.

The four different corner sizes of the Ubuntu shapeThe four different corner sizes of the Ubuntu shape

One of the main goals for the shadows was to make sure they worked with different images inside the shape and on different backgrounds. We also needed to consider the pressed state of the shape, which has a bigger shadow inside.

Variations of icon on different backgrounds in the normal and pressed statesVariations of Maps icon on different backgrounds in the normal and pressed states

When the shape is used, it’s not always indented (like in popovers and notifications), so we also had to study these variations too.

Final styles

And finally after many iterations, discussions and reviews, here are the current styles of the indented and non-indented shapes.

Telephony icon on different backgroundsTelephony icon on different backgrounds

We’ve started to put these guidelines on, where you can follow their evolution.

Read more
Luca Paulina

Over the last year we have been working on the Juju GUI to reach a broader audience. Juju is a way of building complex cloud environments. It connects different services, allows complex configuration and the ability to scale out quickly and easily. Juju is offered as a command line tool or as a GUI on the web.

The team

For the last 6 months a small dedicated team has been working together to push the design of the Juju GUI forward. The design team consists of 2 user experience designers, Alejandra and Luca, and 2 visual designers, Jamie and Spencer. The project has raised many questions and one of them was what it is like designing a product you don’t use. In this blog post Jamie and Luca attempt to clarify our process.

No assumptions

Luca: As a user experience designer part of my process is to create assumptions to further thought, design and development, these are later validated in interviews with stakeholders, user testing or with the development team. An assumption is something that is generally accepted as being true without proof. I’ll never be a direct user of Juju, therefore creating assumptions for the type of audience that the Juju GUI is designed for is an interesting challenge.

To help build assumptions, ideate and create cohesive user flows that will later be tested I’ve had to run planned and impromptu workshops, ask questions, have daily hangouts with the development team,  run week long sprints, ask more questions and lock myself away in the Juju war room to immerse myself in the world of Juju.


Jamie: From a visual perspective this digital product is unlike anything that I’ve worked on in the past. Whereas some rules of typography, hierarchies and readability apply to the design I’ve found myself a lot more focussed on subtle detailing and refinements than ever before. This is because users of the GUI are wanting to complete tasks, they want to be able to deploy their environments as quickly and painlessly as possible. So the design job became about helping them do that without the GUI getting in the way. It is intended to lay lightly across the canvas, aiding users when they need and not obstructing them when they don’t.

Juju GUIThe Juju GUI

Extensive and continuous research

Luca: I’m always surprised by the sheer amount of complexity that the GUI entails. The varying needs of our core target audiences means that we have to conduct a lot of research when we create user flows, ideas and when we’re examining if a feature is needed. Thankfully we have a great user research team which helps find users, conducts the testing and helps interpret the results.

I’ve found that with this particular product the interpretation of feedback has been key to making sure our designs resonate with our users. The feedback is catalogued in a document and shared out amongst the development teams to gain their insights and ideas as well. Solutions are then ideated and the design team then acts upon them creating new designs.

Jamie: The user testing results and feedback from the community has been key to the development of the visual style for the GUI. We’ve been through numerous rounds of testing to get to this stage of design development and each round of tests has moved the design forward. Once a round of testing has been completed the team will review the findings and create design tasks to solve any issues highlighted by the testers. The users we’ve tested with have been high-level cloud architects and system administrators, so familiar with the type of tasks that the GUI performs just not familiar with the way in which we perform those tasks in the GUI. Assumptions we’ve made about the way they would use the GUI have sometimes been mistaken so the design really has been guided by the users.

Juju GUI design evolutionEvolution of Juju’s interface

Constant validation from a multidisciplinary team

Luca: Throughout the project the need for validation on concepts and ideas has been incredibly important. The agile process we use allows us to create wireframes and designs quickly and get them in front the dev team and get their insight and feedback, we’re lucky enough to have a near 24 hour working cycle (Teams in Europe, North America and Australasia). Because of this it’s not uncommon for a design to go through many iterations in a week, for example; the inspector wireframes (pictured below) went through 9 revisions in 10 working days, the complexity of the inspector design and experience was refined and finessed collaboratively with the development team, this has turned the inspector into an integral and very powerful part of the GUI.

Juju inspector wireframesDetailed wireframes for the inspector

Jamie: Working within an agile process has meant that design decisions are required to be made quickly and collaboratively within the team. The design team in London is small so we can share work internally and move designs on sometimes multiple times a day. This means we’re able to keep up with the development cycle that releases every 2 weeks and means that users can see the design evolve far faster than waiting for a yearly or biannual release of the product. As a designer it’s been hard seeing the product not pixel perfect when it’s released but we’re working hard to craft, fine-tune and round the edges of it so it will be a beautiful thing to use and interact with each new release.

Inspector designVisual iterations of the inspector

Questioning language and terminology

Luca: Juju is expanding into a new field of creating clouds by managing services not machines. This means that there really isn’t a language framework that we can rely on and one thing that has been apparent over the last 6 months is the importance of terminology and language for developers. At the beginning of the project it was difficult and time consuming to learn the established vocabulary associated with the cloud and Juju, this gave us a great reason to start questioning words and terms used throughout the GUI. We uncovered words that were already established in other web services and words that didn’t connect with the user. Questioning these words and terms made it clear that not only do we (as non-users) not understand but this would also happen with users and it allowed us to finesse the language in the GUI to something more appropriate.

Good design principles and patterns

Jamie: The GUI is not just the work of the Cloud team. To harmonize the look of the products in the Canonical stable we’ve worked closely with the design team developing the phone OS looking for ways that design patterns developed by them can be applied to the Juju GUI. We’ve also worked with the Web team to see where we can integrate any elements from their UI library. The GUI is a product but it’s not a mobile OS and equally we interact with it in a desktop web browser but it’s not a website, so it ultimately has to have it’s own look. But by pooling the collective design wisdom of the teams who have been crafting interactions in their specific fields and by using patterns and guidelines already defined in this space we can create a interface that is better than the sum these parts but with it’s own clear voice.

Good design practices

Jamie: We like to sketch here. We sketch everything out before any work is done on screen and it’s enormously useful in iterating quickly through problems that users have and trying to come up with multiple solutions to these in a collaborative way. With a small team we can sketch our way through multiple problems towards multiple solutions and then move into applications like Photoshop and Illustrator once we’ve got a clear direction of the UX. This fast way of working also allows us to keep pace with the development cycle and to be able to add features to the GUI each time we do a release. Once a feature of the GUI is open to the world we’ll gather feedback then it’s back to the drawing board to refine it.

Isle of Man workshopUX sketching during a recent sprint

Playing to our strengths

Luca: Most of the processes to provision, create and manage services in the cloud are currently carried out via command line. A priority for us has been to think about how we can use visual language to provide a layer of information and understanding not readily available via the command line. As designers we understand that with colour, structure, layout and flow we can communicate the status of a system or process in a very powerful way. We have made it our goal to bring out the strengths of the GUI by exploring visual metaphors and relationships. We established that the command line is an input output tool, the GUI doesn’t have that type of interaction and offers a more holistic approach, we offer that by having a clear hierarchy and having concise user flows. Early on in the project we made a principle to not compete with the command line but to embrace it, there are users out there who will use Juju just as a command line tool or as the GUI or a mix of both.

Charm-iconsPlayful icons helps users navigate the GUI

Final thoughts

Pretty much everyone in the team has been involved in the conceptual stage of the project, this has helped us create a cohesive product with some really powerful features. I’m sure there are a lot of designers out there working on designs for products that they won’t end up using. We wanted to take the time to highlight how we’ve approached this problem while we’ve been working on the Juju GUI project. The coming months will see a redesign of the the navigation bar, notifications, service blocks and relationship lines. We’ve given you a preview of some of these features in the visuals above.

Read more
Katie Taylor

Wednesday App Clinic – Update

Over the last few weeks, we’ve enjoyed running 2 Wednesday App Clinics. Thanks to all those who sent us their apps and questions. It’s been a fantastic response! It certainly has helped us to see how you’ve been using the design guides and the components, and I hope it has helped you.

The first clinic started with an introduction and then feedback on a Brad Wells’ Blackjack app, and Marcin Le?niowski’s Skydiving logbook app. The second clinic included Michael Zanetti’s GetMeWheels, Daniel Beck’s RamSamSam RSS reader and Szymon Waliczek’s uShopper shopping list apps.

Screenshot from 2013-09-26 10:22:43

If you would like feedback or to ask a particular question (and to see your app featured!) send a screenshot or link to before 1pm UTC on Tuesday.

To watch previous clinics go to the Ubuntu OnAir youtube channel at

The clinics are on Wednesdays at 1pm UTC at . Join us (or watch later) to find out more.

Read more