Canonical Voices

Joseph Williams

Working to make Juju more accessible

In the middle of July the Juju team got together to work towards making Juju more accessible. For now the aim was to reach Level AA compliant, with the intention of reaching AAA in the future.

We started by reading through the W3C accessibility guidelines and distilling each principle into sentences that made sense to us as a team and documenting this into a spreadsheet.

We then created separate columns as to how this would affect the main areas across Juju as a product. Namely static pages on, the GUI and the inspector element within the GUI.




GUI live on




Inspector within the GUI




Example of static page content from the homepage




The Juju team working through the accessibility guidelines



Tackling this as a team meant that we were all on the same page as to which areas of the Juju GUI were affected by not being AA compliant and how we could work to improve it.

We also discussed the amount of design effort needed for each of the areas that isn’t AA compliant and how long we thought it would take to make improvements.

You can have a look at the spreadsheet we created to help us track the changes that we need to make to Juju to make more accessible:




Spreadsheet created to track changes and improvements needed to be done



This workflow has helped us manage and scope the tasks ahead and clear up uncertainties that we had about which tasks done or which requirements need to be met to achieve the level of accessibility we are aiming for.



Read more
Grazina Borosko

The Yakkety Yak 16.10 is released and now you can download the new wallpaper by clicking here. It’s the latest part of the set for the Ubuntu 2016 releases following Xenial Xerus. You can read about our wallpaper visual design process here.

Ubuntu 16.10 Yakkety Yak


Ubuntu 16.10 Yakkety Yak (light version)


Read more
Tom Macfarlane

Ubuntu Core

Recently the brand team designed new logos for Core and Ubuntu Core. Both of which will replace the existing Snappy logo and bring consistency across all Ubuntu Core branding, online and in print.




Guidelines for use


Use the Core logo when the Ubuntu logo or the word Ubuntu appears within the same field of vision. For example: web pages, exhibition stands, brochure text.

Ubuntu Core

Use the Ubuntu Core logo in stand alone circumstances where there is no existing or supporting Ubuntu branding or any mention of Ubuntu within text. For example: third-party websites or print collateral, social media sites, roll-up banners.

The Ubuntu Core logo is also used for third-party branding.

The design process

Extensive design exploration was undertaken considering: logotype arrangement, font weight, roundel designs – exploring the ‘core’ idea, concentric circles and the letter ‘C’ – and how all the elements came together as a logo.


Options for how the logotype/wordmark is presented:

  • Following the design style set when creating the Ubuntu brandmark
  • Core in a lighter weight, reduced space between Ubuntu and Core
  • Ubuntu in the lighter weight, emphasis on Core
  • Core on its own





Core, circles and the letter ‘C’


Design exploration using concentric circles of varying line numbers, spacing and line weights. Some options incorporating the Circle of Friends as an underlying grid to determine specific angles.

Circle of Friends


Design exploration using the Circle of Friends – in its entirety and stripped down.




How the logotype and roundel design sit together.


Full sets of Core and Ubuntu Core logo artwork are now available at

Read more
Inayaili de León Persson

A week in Vancouver with the Landscape team

Earlier this month Peter and I headed to Vancouver to participate in a week-long Landscape sprint.

The main goals of the sprint were to review the work that had been done in the past 6 months, and plan for the following cycle.


Landscape is a totally distributed team, so having regular face-to-face time throughout the year is important in order to maintain team spirit and a sense of connection.

It is also important for us, from the design team, to meet in person the people that we have to work with every day, and that ultimately will implement the designs we create.

I thought it was interesting to hear the Landscape team discuss candidly about how the previous cycle went, what went well and what could have been improved, and how every team member’s opinion was heard and taken into consideration for the following cycle.


Landscape team in VancouverLandscape team discussing the previous cycle


User interviews

Peter and I took some time aside to interview some of the developers in 1-2-1 sessions, so they could talk us through what they thought could be improved in Landscape, and what worked well. As we talked to them, I wrote down key ideas on post it notes and Peter wrote down more thorough notes on his laptop. At the end of the interviews, we collated the findings into a Trello board, to identify patterns and try to prioritise design improvements for the next cycle.

The city

But the week was not all work!

Every day we went out for lunch (unlike most sprints which provide the usual hotel food). This allowed us to explore a little bit of the city and its great culinary offerings. It was a great way to get to know the Landscape team a little bit better outside of work.


Vancouver foodLots of great food in Vancouver


Vancouver also has really great coffee places, and, even though I’m more of a tea person, I made sure to go to a few of them during the week.


Vancouver coffeeNice Vancouver coffee


I took a few days off after the sprint, so had some time to explore Vancouver with my family. We even saw a TV show being filmed in one of our favourite coffee shops!


Exploring VancouverExploring Vancouver


This was my first time in Canada, and I really enjoyed it: we had a great sprint and it was good to have some time to explore the city. Maybe I’ll be back some day!

Read more
Inayaili de León Persson

September’s reading list

Here are the best links shared by the design team during the month of September:

  1. Empty States
  2. It’s ok to say what’s ok
  3. Sully – 208 Seconds Experience
  4. Google Allo
  5. Tech Giants Team Up to Fix Typography’s Biggest Problem
  6. Redesigning Chrome desktop
  7. Clarity Conference videos

Thank you to Alejandra, Jamie, Joe and me for the links this month!

Read more
Inayaili de León Persson

August’s reading list

August has been a quiet month, as many of team have taken some time off to enjoy the unusually lovely London summer weather, but we have a few great links to share with you that were shared by the design team this month:

  1. Developing a Crisis Communication Strategy
  2. Accessibility Guidelines
  3. An Evening with Cult Sensation – Randall Munroe
  4. Clearleft Public Speaking Workshop in Brighton
  5. Hello Color
  6. The best and worst Olympic logo designs throughout the ages, according to the man who created I <3 NY
  7. Readability Test Tool
  8. Breadcrumbs For Web Sites: What, When and How

Thank you to Joe, Peter, Steph and me for the links this month!

Read more
Rae Shambrook

Recently I have been working on the visual design for RCS (which stands for rich communications service) group chat. While working on the “Group Info” screen, we found ourselves wondering what the best way to display an online/offline status. Some of us thought text would be more explicit but others thought  it adds more noise to the screen. We decided that we needed some real data in order to make the best decision.

Usually our user testing is done by a designated Researcher but usually their plates are full and projects bigger, so I decided to make my first foray into user testing. I got some tips from designers who had more experience with user testing on our cloud team; Maria  Vrachni, Carla Berkers and Luca Paulina.

I then set about finding my user testing group. I chose 5 people to start with because you can uncover up to 80% of usability issues from speaking to 5 people. I tried to recruit a range of people to test with and they were:

  1. Billy: software engineer, very tech savvy and tech enthusiast.
  2. Magda: Our former PM and very familiar with our product and designs.
  3. Stefanie: Our Office Manager who knows our products but not so familiar with our designs.
  4. Rodney: Our IS Associate who is tech savvy but not familiar with our design work
  5. Ben: A copyeditor who has no background in tech or design and a light phone user.

The tool I decided to use was Invision. It has a lot of good features and I already had some experience creating lightweight prototypes with it. I made four minimal prototypes where the group info screen had a mixture of dots vs text to represent online status and variations on placement.  I then put these on my phone so my test subjects could interact with it and feel like they were looking at a full fledged app and have the same expectations.


During testing, I made sure not to ask my subjects any leading questions. I only asked them very broad questions like “Do you see everything you expect to on this page?” “Is anything unclear?” etc. When testing, it’s important not to lead the test subjects so they can be as objective as possible. Keeping this in mind, it was interesting to to see what the testers noticed and brought up on their own and what patterns arise.

My findings were as follows:

Online status: Text or Green Dot

Unanimously they all preferred online status to be depicted with colour and 4 out of 5 preferred the green dot rather than text because of its scannability.

Online status placement:

This one was close but having the green dot next to the avatar had the edge, again because of its scannability. One tester preferred the dot next to the arrow and another didn’t have a preference on placement.

Pending status:

What was also interesting is that three out of the four thought “pending” had the wrong placement. They felt it should have the same placement as online and offline status.

Overall, it was very interesting to collect real data to support our work and looking forward to the next time which will hopefully be bigger in scope.


The finished design

Read more
Jouni Helminen

We have been looking at ways of making the Terminal app more pleasing, in terms of the user experience, as well as the visuals.

I would like to share the work so far, invite users of the app to comment on the new designs, and share ideas on what other new features would be desirable.

On the visual side, we have brought the app in line with our Suru visual language. We have also adopted the very nice Solarized palette as the default palette – though this will of course be completely customisable by the user.

On the functionality side we are proposing a number of improvements:

-Keyboard shortcuts
-Ability to completely customise touch/keyboard shortcuts
-Ability to split the screen horizontally/vertically (similar to Terminator)
-Ability to easily customise the palette colours, and window transparency (on desktop)
-Unlimited history/scrollback
-Adding a “find” action for searching the history


Tabs and split screen

On larger screens tabs will be visually persistent. In addition it’s desirable to be able split a panel horizontally and vertically, and use keyboard shortcuts or focusing with a mouse/touch to move between the focused panel.

On mobile, the tabs will be accessed through the bottom edge, as on the browser app.


Quick mobile access to shortcuts and commands

We are discussing the option of having modifier (Ctrl, Alt etc) keys working together with the on-screen keyboard on touch – which would be a very welcome addition. While this is possible to do in theory with our on-screen keyboard, it’s something that won’t land in the immediate near future. In the interim modifier key combinations will still be accessible on touch via the shortcuts at the bottom of the screen. We also want to make these shortcuts ordered by recency, and have the ability to add your own custom key shortcuts and commands.

We are also discussing with the on-screen keyboard devs about adding an app specific auto-correct dictionary – in this case terminal commands – that together with a swipe keyboard should make a much nicer mobile terminal user experience.


More themability

We would like the user to be able to define their own custom themes more easily, either via in-app settings with colour picker and theme import, or by editing a JSON configuration file. We would also like to be able to choose the window transparency (in windowed mode), as some users want a see-through terminal.

We need your help!

These visuals are work in progress – we would love to hear what kind of features you would like to see in your favourite terminal app!

Also, as Terminal app is a fully community developed project, we are looking for one or two experienced Qt/QML developers with time to contribute to lead the implementation of these designs. Please reach out to or to discuss details!

EDIT: To clarify – these proposed visuals are improvements for the community developed terminal app currently available for the phone and tablet. We hope to improve it, but it is still not as mature as older terminal apps. You should still be able to run your current favourite terminal (like gnome-terminal, Terminator etc) in Unity8.

Read more
Steph Wilson

Back in June we hosted a competition that asked developers to use the AdaptivePageLayout component from the UI toolkit to create an app that converges across devices. We had some very impressive entires that used the component in different ways; choosing a winner was hard. However, after testing all the apps the design team chose a winner: the Timer App.

How does the AdaptivepageLayout work?

The AdaptivePageLayout component eliminates guesswork for developers when adapting from one form factor to another. It works by tracking an infinite number of virtual columns that may be displayed on a screen at once. For example, an app will automatically switch between a 1-panel and 2-panel layout when the user changes the size of the window or surface, by dragging the app from the main stage to the side stage.

You can read more about convergence and how the adaptive page layout works in the App design guides.

Timer app

The Timer app impressed the design team the most with its slick transitions, well thought-out design and ease of use. It used the AdaptivepageLayout well when it translated to different screens.

Design feedback

  • Design: well-considered touches with design, animation and various cool themes.
  • Usability: a favourite is the ability to drag seconds / minutes / hours directly on the clock.
  • Convergence: adjusts beautifully to different screen sizes.

Screen Shot 2016-08-09 at 09.10.32

Screen Shot 2016-08-09 at 09.14.14

Timer app

Other entries

Thank you to all who participated in making their apps look even more slick. Here are the other entries:

2nd: AIDA64 App

  • Design: clean, readable with clear content
  • Usability: pretty flawless
  • Convergence: Adaptive Page Layout suits this type of application well and is used well

3rd: Movie Time

  • Design: functional with good management of all the content
  • Usability: live results for search works smoothly as well as trailer links
  • Convergence: the gridview of poster art lends itself well to various screen sizes

4th: Ubuntu Hangups

  • Design: clean and follows guidelines well
  • Usability: easy to message / chat, with user-friendly functionality
  • Convergence: easy to use particularly on Phone and Tablet

5th: uBeginner

  • Design: basic and clean
  • Usability: information is well-presented
  • Convergence: uses the Adaptive Page Layout well

Try it yourself!

To get involved in building apps, click here.

Read more
Anthony Dillon

Web team hack day

Last week the developers in the web team swapped the office for the lobby of the hotel across the street. The day was geared up to allow us to leave our daily tasks in the office and think of ideas that we would like to work on.

The morning started with coffee and sitting in sofas brainstorming ideas. We collected a list of ideas from each person would like to work on. The ideas ranged from IRC bots to a performance audit of a few of our sites.

Choosing ideas

We wrote all the ideas on post it notes and lay them out on the table. Then each of us chose the idea we were most interested in working on by putting our hand on it. I worked out an almost perfect split of two people per idea, so we broke up into our teams and got to work.

Here are the things we worked on during this “hack day”.

IRC bots

These are bots that can listen to an action and report it to our IRC channel. For example, the creator of a pull request wouldn’t have to paste a link to their PR into our channel to be picked up for review.

This task was picked up by Karl and Will, who started by setting up a Hubot on Heroku. They attached a webhook to all projects under the ubuntudesign to listen for pull requests and report this in the web team channel.

This bot can be used for many other things like reporting deployments, CI failures, etc. We also discussed a method of subscribing to the notifications you are interested in, instead of the whole team being notified about everything.

Asset manager search improvements

Our asset manager and server acts as an internal asset storage. By storing an asset here we get a link to it which can be used by any website. As there are many assets stored in the asset manager we usually need to search existing assets to see if one already exists before making a new one.

Graham and myself picked this task and started by working out how to setup both the manager and server locally.

Previously the search would return results that contained either of a two-word query, but now the result has to contain all search terms to return.

We added our Vanilla framework to the front end, as it is obviously good to use our framework for all internal and external projects.

We have also implemented filtering results by file type, which makes it easy to go through what can sometimes be dozens of search results.

GitHub CMS

GitHub CMS is a nicer and more restricted interface that the marketing team can use to edit the GitHub repository containing page content for example,

Rich and Robin picked this task and began work on it straight away, by discussing the best approach and list of possible features.

Even though Robin was also helping out with. setting up the asset manager and server locally for Graham and me, he still managed to investigate the best Python framework to use and selected one. Rich on the other hand went ahead with the front end and developed a bunch of page templates using the new MAAS GUI Vanilla theme.

Commit linting

Commit linting is a service that gives a committer to a project a nice step by step wizard to build a high quality commit message.

Barry picked up this task and got the service up and running, and working, but hit a blocker at the point of choosing between different methods of committing. For instance, Tower would bypass this step and also we do not necessarily want to dictate to contributors which way they should commit code. This is something we will leave as an investigation for the time being.


Our hack day went well, in fact better than I imagined it would. We all had fun, got to work on things we found important but struggle to get prioritised in our day to day. It gave the developers a feeling of achievement and the buzz of landing and releasing something at the end of the day.

We will be attempting to do a hack day once every month or so, so watch this space!

Read more
Andrea Bernabei

Refreshed scrollbars!

You may have noticed that the scrollbars available on Ubuntu Touch and the Unity8 environment have recently received a huge overhaul in both visual appearance and user experience. More specifically, we redesigned the Scrollbar component (which is already provided in the Ubuntu UI Toolkit) and added a new ScrollView component that builds on top of it and caters for convergence.

Technical note to app developers: the Scrollbar component is still available for compatibility purposes, but we recommend transitioning to the new and convergent ScrollView.

How did we do it?

The process was as follows:

  • Interaction design was specified
  • Applied visual style to the component
  • Prototyped the component
  • Iterated over design and performed user testing
  • Sent for review to the SDK team and integrated into the UI toolkit.

We started by researching the field, exploring the possibilities and thoroughly analyzing the history of the scrollbar component. The output of this step was an interaction specification. The visual design team picked that up and applied our visual style to the component, ensuring a consistent visual language across all the elements provided by the UI Toolkit.

Once we had a first draft of the interaction and visual specs, we created a prototype of the component.
We then iterated over the design choices and refined the prototype. While iterating we also took into account the results of the user testing research that we conducted in the meanwhile. The testers found the new scrollbars easy to use and visually appealing. The only pain point highlighted by the research were the stepper buttons, that were deemed a bit small. We refined them by creating a new crispier graphic asset and by tweaking their size as well as the visual feedback they provided, especially when being hovered with a mouse.

Once we were happy with the result, we submitted our work to be reviewed by the SDK team. The SDK team are the final gatekeeper and decide whether the implementation of a component is ready to be merged to the UI Toolkit or not. The review process can be lengthy, but it is of great help in ensuring a higher code quality, less bugs and clearer documentation. Once the SDK team gave the green light, the component was merged to the next release of the UI Toolkit.

What did we change?

A critical requirement of the new solution was to be “convergence-ready”. Convergence means implementing a UI that scales not just across form factors, but also across different input devices. This is particularly important in the case of scrolling, as it must be responsive to all input devices.

The new ScrollView can be interacted with using the touchscreen of your phone or tablet, but thanks to convergence, now your tablet can turn into a full fledged computing device with a hardware keyboard and a pointer device, such as a mouse. The component must be up to the task and adapt to the capabilities provided by the input device which is currently in use.

At any time, the new scrollbar can be in one of the 3 following modes:

  • Indicator mode, where the scrollbar is a non-interactive visual aid;
  • Thumb mode, that allows quick scrolling using a touch screen;
  • Steppers mode, optimized for pointer devices interactions.

Let’s go through the modes in more detail.

Indicator mode

Whenever the user scrolls content without directly interacting with the scrollbar, i.e. he or she performs a flick or uses the mouse wheel or keyboard keys, the scrollbar gently fades in as an overlay on top of the content. In this mode the scrollbar is not interactive, and just acts as a visual aid to provide information about the position of the content. The indicator gently fades out following a short timeout after the surface stops scrolling.

Please note: we will be replacing these images with GIFs soon.



Thumb mode

Imagine you want to send a picture to a friend of yours, but the file is somewhere down the very lengthy grid of pictures. Let’s also suppose you’re using a smartphone or tablet and you have no mouse or keyboard connected to it. Wouldn’t it be handy to have a way to quickly scroll a long distance without having to repeatedly flick the list? We designed Thumb mode to address that use case.

When the content on screen reaches a length of 10 or more pages, the thin indicator provided by the indicator mode grows thicker into an interactive thumb. That marks the transition to the Thumb mode. While the scrollbar is in Thumb mode you can drag the thumb using touchscreen to quickly scroll the content.

The component still fades out when the user stops interacting with the surface and the surface stops scrolling, in order to leave as much real estate to the application content as possible.

Stepper mode


When the user is interacting with the UI using a pointer device, they expect a different experience than a touchscreen. Pointer devices allow for much more precise interactions and also provide different ways of interacting with the UI components, such as hovering. A good convergent component exploits those additional capabilities to provide the best user experience for the input device which is currently in use.

When the user hovers over the area occupied by the (initially hidden) scrollbar, the bar reveals itself, this time in what we call Stepper mode.

This mode is optimized for pointer device interactions, although it can be interacted with using touchscreen as well. More generally, for a component to be defined convergent the user must be able to start interacting with it using one input device (in this case, a mouse) and switch to another (e.g. touch screen) whenever they wish to. That transition must be effortless and non disruptive.

When in Stepper mode, the scrollbar has a thick and interactive thumb. This is similar to the Thumb mode we presented in the previous section. However, Stepper mode also provides a semi-transparent background and the two clickable stepper buttons desktop users are already accustomed to. The steppers buttons can be clicked to scroll a short distance. Holding a stepper button pressed will scroll multiple times.

The areas above and below the thumb are also interactive. You can click/tap or press-and-hold to scrolling by one or more pages.

Once the user moves the pointer away from the scrollbar area and the surface stops scrolling, the component elegantly fades out, just like in the other modes.

Visual convergence

We put a lot of efforts into making the transitions between the different modes as smooth and visually pleasing as possible. The alignment of the sub components (the thumb, its background, the stepper buttons), their sizes, their colours have been carefully chosen to achieve that goal.

When the bar grows from Indicator to Thumb modes and vice versa, it does so by anchoring one side and expanding only the opposite one. This minimizes unexpected movements and produces a simple yet crisp animated transition. Those same principles also apply to the transitions from thumb to stepper modes and indicator to stepper and vice versa. We wanted to create transitions that would look elegant but not distrustful.

The new scrollbar also provides visual aids to indicate when a pointer device is hovering over any of the sub components. Both the stepper buttons and the thumb react to hovering by adjusting their colours.

Scroller variations

Interaction handling convergence

A lot of effort has gone into tweaking the interactions to provide an effortless interaction model. Here’s a summary of how we handle touch screen and pointer devices:

  • Thumb mode features a thicker interactive thumb to allow quick scrolling using touch screen;
  • Press-and-holding the steppers buttons provides an effortless way to perform multiple short scrolls;
  • Press-and-holding the areas above and below the thumb makes provides easy multiple page scrolling;
  • Mouse hovering is exploited to reveal or hide the scrollbar;
  • Visual feedback on press/tap;
  • Visual feedback on pointer device hover.

It is a lot of small (and sometimes trivial!) details that make up for a great user experience.

Some of you might be wondering: “what about keyboard input?”

I’m glad you asked! That is an important feature to realize full convergence. The ScrollView components handles that transparently for you. Scrolling content using the keyboard is just as easy as scrolling using the touchscreen or any pointer device:

  • Arrow keys trigger a short scroll;
  • PageUp/PageDown trigger a page scroll;
  • Home/End keys trigger scrolling to the top/bottom of the content, respectively
  • Holding a key down triggers multiple scrolls;

What did we achieve?

The new scrollbars fully implement our vision of convergence. The user can interact with any of the input device he has available and switch from one to the other at any time. The interactions feel snappy and we think the component looks great too!

We can’t wait for you to try it and let us know your opinion!

What does the future hold?

The focus so far has been on getting the right visual appearance and user experience.

However, in order to have a complete solution, we also need to make sure adding such a feature as scrollbars to the applications does not come with a big performance drawback. Ideally, all the scrollable surfaces (images, text fields, etc) should include a scrollbar and that means it’s very important to provide a component that is not just easy to use and visually appealing but also extremely performant.

There are two main aspects where the performance of this component comes into play: the performance of interactions, so that they happen immediately and without unexpected delays. I believe we’re in a very good shape there. The second is: the time it takes to create a scrollbar when an application needs one; this affects application startup time and the time it takes to load a new view that holds scrollable content.

A few changes have already been implemented, which has resulted in a speed-up of about 25%. These changes should be released with OTA13.

If you have ideas or want to provide any feedback, here are the contact details of the people who worked on this project.

IRC: #ubuntu-touch channel on FreeNode server

Alternatively, start a thread on the ubuntu-phone mailing list.

Read more
Steph Wilson

Last week we released phase 1 of the new App Design Guides, which included Get started and Building blocks. Now we have just released phase 2: Patterns. This includes handy guidance on gestures, navigation and layout possibilities to provide a great user experience in your app.

Navigation: user journeys

Find guidance for utilizing components for effective and natural user journeys within your UI.

750w_Navigation_UserJourney (2)

Layouts: using Grid Units

Use the Grid Unit System to help visualise how much space you have in order to create a consistent and proportionate UI.


More to come…

More sections will be added to patterns in the future, such as search, accessibility and communication.

Up next is phase 3: System integration; which includes the number of a touchpoints your app can plug into inside the Ubuntu operating system shell, such as the launcher, notifications and indicators.

If you want to help us improve these guides, join our mailing list. We’d love to hear from you!

Read more
Barry McGee

Developing for Vanilla v1

As Inayaili recently blogged, we are now working towards a goal of releasing Version one (v1) of Vanilla for early September.


Vanilla was created just over a year ago and in that time has been used to build a wide range of sites across Canonical and beyond. It currently averages around 1,500 downloads a month on NPM. We’ve been delighted to see it grow in popularity and see the myriad of different experiences people have been building using Vanilla.

A big advantage of this wide adoption is the feedback we’ve received from developers on the front line, including within our own teams at Canonical. This feedback has enabled us to identify growing pains and mark out clear areas for improvement.

The overarching themes for v1 are maturity and stability — ensuring the framework is a cohesive set of building blocks and also making sure those building blocks are stress tested and robust.

Practical steps

The first step we will be taking is to audit the codebase and ensure it adheres to our coding standards. This will include encapsulating all components with the BEM methodology which we have introduced to our coding standards within the last year.

We will also be working to improve accessibility and responsiveness of each component while making some aspects of the codebase less opinionated to help increase its applicability to a broad range of use cases.

Another big area earmarked for love is the documentation provided for Vanilla. Given that the framework is now used by a wide and diverse set of people, we can make no assumptions about what they may know. So we need to provide comprehensive documentation that not only details how to implement each component but that also explains where each component should or should not be used.

It’s also important that everything in Vanilla is visible. Over time, code has slipped into Vanilla that is not documented on the demo.  This can cause page elements to display in ways a developer might not expect. We will be addressing this by building a comprehensive documentation site at a dedicated URL. This will be the one-stop-shop for all things Vanilla and will replace the current Vanilla demo page and Sass docs.

We will also be restructuring Vanilla so it is in a better place for scalability and extensibility going forward. Vanilla currently employs a flat structure for simplicity but we’ve come to realise that it can be confusing to mix components with utilities and presentation with configuration.

We recently had a team discussion on possible ways to structure the code within Vanilla and settled on an approach minted by Harry Roberts — Inverted Triangle CSS or ITCSS. Structuring Vanilla in this way will not only improve the quality of the resulting CSS but make it much easier to initiate new developers to building with Vanilla.


Layers of ITCSS – courtesy of Harry Roberts

Exciting times

I’m very excited about this project and think it has huge potential to help shape how we in Canonical approach building experiences on the web, not to mention how the wider community will benefit from these changes.

If you have any feedback or ideas on the future direction of Vanilla from a development point of view, please do comment below – we’d love to hear from you.

Read more
Steph Wilson

Meet the newest member of the design team, UX designer Raul Alvarez, who will be working on the Ubuntu convergence story. Raul will be bringing new ideas to improve our apps to allow for a seamless experience across all devices. We caught up with him to tell us more about his background and what attracted him to the open source world of Ubuntu.



You can find Raul’s blog here and reach out to him on Twitter using his handle @raulalgo.

Tell me about your background

If we go all the way back to university, I started as a computer engineer student, but after a while I got to a point where I was rather burnt out by it. Then almost by chance, I ended up studying another degree in Advertising and PR. When studying my second degree I gained a fresh perspective. I was coming from studying maths and physics to then finding myself in classes for Spanish, history, law, and eventually design, which is where I got hooked.

I turned 30 and decided to move to London, as everyone in the small town of Salamanca (West Spain) was either getting married or bored; I was the latter. I wanted to challenge myself to do the most difficult things and push a bit more. I moved into designing Forex trading apps, which was a great experience with very smart people. I got to work very close with the developers too.

I then went into e-commerce as a designer, which was another diverse industry I wanted to learn from. Getting into something I know nothing about is key for me. It’s tricky, as people want experience, but once I’m there and I learn, I feel that I have the ability to take a fresh look at things. From studying advertising and knowing how apps are build I could bring those disciplines together to work on different platforms.

Canonical was a company I wanted to be part of. Just so happens they were looking for a designer, and now here I am!

Do you have any projects you’re working / or have worked on?

In the late days of my computer engineering degree, me and some fellow students started our own business. It was when the Social Network movie was out and everyone wanted to be Mark Zuckerberg; and so did we. We created a photography social network that was like a Flickr wannabe, or closer to what 500px is now. We had good intentions and we worked very hard on it. However, we lacked the business vision and strategy to push it forward. We had two choices: we close it off and do something else, or we find a better way to make money.

Salamanca is a small town and has little going on, but it just so happened that a company was doing mobile apps on demand for clients. Instead of hiring more people when they had large spikes of work, they would reached out to other companies. My three partners were playing the role of developers and I was the designer. We spent four years designing mobile apps for various clients specific needs, most came from the advertising industry. We had some startups come to us who didn’t have much money and we would help them advertise and prototype their apps. It was always a rather constrained working environment with a low budget and working with trial and error.

What attracted you to the open source world of Ubuntu?

For me, being here is amazing because I had been using a laptop that ran Ubuntu in my uni days. I’ve always known open source and the ideas around it. I remember playing with Linux when I was at high school too.

What does UX mean to you?

User Experience (laughs). But seriously, I think the term ‘UX’ is thrown back and forth a lot and people forget what it means. It’s a lot of ideas that could or could not be UX.

People might think that UX is just associated with apps and web design. But it’s not. If you think about user experience, it’s in everything. You can use user experience to build your hotel for instance. I could say how is the lobby going to be decorated, what is the uniform going to be like, do I want the guests to find a little chocolate under their pillow? THAT is defining the user experience. You don’t need to do a lot of research. Well, you can research user experience in other hotels, that would be one approach. Or you can say I have this vision I want to make my approach work. For this you need good judgement and to think about people, but also be prepared to take risks.

One of the parts I enjoy most about designing is whenever I don’t know what I’m going to do. That is the fun bit.

What have you learned in your first week at Canonical?

I came here thinking I knew how complex an operating system was. I wasn’t even close. I realised the complexity was way down below, every single little thing is taken into account, which amazes me. Then I realised the scale of the task. It’s amazing how much work is going on here. I have a lot of respect for it.

What is your proudest achievement?

Making a decision like: I’m stuck and I need a change. I made the effort to move to a different country and to change my degree. It has always been very natural for me to take risks, but I didn’t realize how scary it actually is until I stop and think about it.

Read more

Last week the design team had two interns undertaking their work experience at the London office.

Our first student is studying computer science for her GCSEs and has an interest in Python programming and software engineering. The second student is studying Geography and IT and had a general interest in IT.

The tasks

We wanted them to experience what working in the design team is like, so we set them two tasks:

Task 1 – Create a poster of your work experience

We asked them to keep a note of the key things that they had been doing and what they learned throughout the week.

They were then asked to create two paper versions of their posters, which were reviewed by one of our visual designers. After being reviewed, the designers helped the student to create a final electronic version, which they could take back to school with them.

Task 2 – Convergence tablet

We asked them to use the convergence tablet as their device during the week for user testing purposes.

We wanted them to:

  • Send emails
  • Take notes
  • Update social media
  • Take images
  • Organise their gallery
  • Share something with a friend
  • Play games
  • Play music
  • Read news articles or other articles

We asked for feedback on:

  • What they liked about convergence
  • What would they like to see on the tablet?
  • What was their favourite app
  • What can we improve?

They were expected to talk through their feedback for 15 minutes with two designers.


By the end of the week we wanted our interns to have the confidence to present their findings to us, as well as experience a review process with their poster designs.

The feedback we got from our first student – who used the tablet for 4 days, in between her other tasks – said: ‘ready, not a prototype, sleek and lightweight’. What she liked most about it was that ‘it can be a whole computer if you connect it’. She also liked the UbuntuStore.

The feedback we got back from our second student – who used the tablet in between tasks of making bootable USB drives and learning code – was that he ‘likes how it has the capability to … just pick it up and plug it into a monitor … Because it means that you don’t have to carry anything around, just a tablet.’
His favourite app was the Browser, he said ‘because it gives you access to everything’ and he thought it was ‘better than Safari because Safari blocks a lot of things like Flash’. He thought that the camera was of ‘good quality and focused quickly’ and felt it was easy to take photos and videos.

We also received suggestions on what they wished to see in the future and what they thought could be improved, which was great to see from the student demographic. We have captured all of this and can incorporate some of these ideas.

Work experience poster

With the help of one of our visual designer’s, we reviewed our first student’s paper designs and helped bring her poster to life.


This poster was the fruits of her labour and she was then tasked with finishing it off at home, ready to take back to school with her.

Our London office really values the work our work experience interns undertake in the week they are here during the summer. Many of them tend to have interests in technology and our open source nature is a good way to give them a flavour of the Ubuntu design and engineering process.

Want to be an intern at Canonical?

If you’re a student and like what you’ve seen so far, and would like to undertake your work experience with us please do get in touch with Stefanie Davenoy –

Read more

Over the past few months, the Juju team has been working on a whole redesign of the Juju store </><style=”font-weight: 400;”>homepage</><style=”font-weight: 400;”> and we’re very happy to announce that it is now live!

Juju is an application and service modelling tool that enables you to quickly model, configure, deploy and manage applications in the cloud. Juju comes with ready-made solutions for everything you need – these solutions are encapsulated in Charms and Bundles:

  • Charms contain all the instructions necessary to deploy, manage and scale cloud applications.
  • Bundles are collections of charms that work together, deploying an entire application or chunk of infrastructure in one go.

The new Juju Charm store allows you to explore the growing ecosystem of over 300 charms and bundles – everything you need to build your app.

You can now get started with the featured charms and bundles at the top or explore the whole collection of categories:

Screen Shot 2016-07-18 at 12.53.40


We’ve surfaced key categories and highlighted their most popular services:

Screen Shot 2016-07-18 at 12.54.36

Screen Shot 2016-07-18 at 12.55.28


The search stays the same for now, but we’re working on improvements which will be released in the near future:


Screen Shot 2016-07-18 at 12.59.10


You can explore bundles and view charm details:

Screenshot 2016-07-10 14.10.08

Screenshot 2016-07-10 14.11.20


And deploy your chosen charm, using the GUI or CLI:


Screenshot 2016-07-10 14.13.20


Check it out at:


How did we arrive at this solution?

We’ve summarised four of the most important stages of the project for you to get an insight into our design process.

  1. Defining the problem

You may want a shiny new design, but if you don’t understand the problems that you are trying to solve you’ll probably find yourself having to redesign the whole page again in no time. We therefore began by identifying the issues that we wanted this new design to tackle,  and laying out the new store requirements.

This is what the store homepage looked like before the redesign:


Screen Shot 2016-07-11 at 13.36.52
Screen Shot 2016-07-11 at 13.37.10


The original goal of this page was to feature the breadth of the software available for Juju. However, there were a number of elements in our previous design that didn’t facilitate a smooth browsing experience. As the Juju ecosystem grew, we found the need to increase the store’s performance by:

  • Providing a more curated selection to users when they arrive at the store
  • Highlighting the most popular and interesting charms and bundles for users to get started
  • Providing better discovery methods for browsing
  • Encouraging exploration
  • Reducing cognitive load
  • Helping visitors find what they’re looking for with the least amount of friction.


  1. Understanding our audience

Before making any design decisions we:

  • Conducted a round of user testing to uncover friction points and reveal insights into our users’ behaviour and needs.
  • Dived into our site’s analytics to learn more about how current users are moving across the store.
  • Looked at conversion, bounce rate and page views.
  • Identified what search terms are used most and what terms and categories were the most popular.
  • Tagged our content to increase findability.

It’s a surprisingly large amount of prep work but absolutely essential – all this research enabled us to gain some insight into our audience and allowed the definition of use cases which we then used as a basis for our designs.


  1. Researching our competitors

We also undertook a competitor benchmarking project with the aim of:

  • Comparing our general practices and performance with that of our competitors
  • Identifying the strengths and weaknesses of our competitors and review that against our own.
  • Identifying pitfalls to avoid and ways in which we could improve our page.



  1. Test the performance

Testing the design enabled us to continuously iterate towards a solution that, when finalised, was very well received by the community. We love conducting user testing sessions to see how our designs are performing, and it’s hard to over-emphasise the importance of watching actual people interact with your design!

We’ve enjoyed every stage of this process and are very happy it is now available to the public. We’d welcome any feedback, please don’t hesitate to share it here. Check it out here


Read more
Steph Wilson


You can now follow us on Dribbble and Behance for design inspiration.

See things like: the Ubuntu #reinvent digital campaign, Juju embeddable card and Suru app icon designs.

Follow us :)

Read more
Inayaili de León Persson

Getting Vanilla ready for v1: the roadmap

We have been using our front end framework Vanilla across our sites for a while now, so it might surprise you to know that its first official version (let’s call it v1) hasn’t yet been released.

In preparation for v1 (which we are tentatively aiming for early September), there are a few tasks that we have been, and will be, working on to make sure that Vanilla is as robust as we can make it, and to make the process of using and improving it clear.

Future-thinking: defining a high level roadmap

It’s important that long-term, ongoing projects have defined goals that people can focus on and strive for. Having short, mid and long-term goals makes it easier to prioritise and concentrate efforts on tasks that will get you closer to achieving the ultimate vision for the project.

The first thing we did in order to outline a roadmap for Vanilla was to collect all the things that we felt needed to happen for it to be ready for release, things we’d like to improve, and wishlist items that might not be urgent but that we would like to tackle at some point in the future.

With this list at hand, we organised the tasks by priority and added them to a roadmap board in Trello, which is open for anyone to have a look at. You can see which tasks we are working on during the current two-week sprint, and which tasks are queued to be done next.


Vanilla roadmap in TrelloThe Vanilla framework roadmap Trello board


Contributing: defining the process for adding new patterns

Releasing Vanilla v1 does not mean that Vanilla will then be finished. As a working style guide that is used across Canonical on various different projects with different needs, new patterns will emerge and existing ones will have to be improved to be more flexible.

We thought that it would be good to document the process that a pattern should follow in order to become a Vanilla pattern, so after a little bit of brainstorming, we created a diagram that shows the different steps that should be taken from before submitting a pattern proposal to its full acceptance as a Vanilla pattern.

Most of the steps in the diagram happen in just a few seconds, but it is good to be able to visualise the entire process.


Vanilla process diagramDiagram of the process to submit a new pattern to Vanilla


As Vanilla itself, this process diagram is not really finished. Once we start using it more frequently, we will probably have to make some adjustments to improve it. Also, there are a few branches of the process that we still need to include, namely how a pattern is added to a theme as opposed to the main Vanilla framework, and how an existing pattern (in a website of Vanilla theme) can be promoted to Vanilla.

As part of this task, we also updated the existing GitHub template that pops up when you submit a new issue on the Vanilla repository to include the option of submitting a pattern proposal.

The proposals will be reviewed on a fortnightly basis by the web team during the Vanilla working group meetings. We are pondering how we can make these meetings open to anyone who’d like to participate, as we know that lots of you would like to contribute with new patterns and improvements. We’d be happy to hear your ideas on how this could work.

Defining browser support guidelines

While internally, in the web team, we tend to agree on and follow consistent browser support guidelines, the process isn’t documented.

We want to make sure that Vanilla is built following the latest web standards, and that people can build sites with it that will work on as many form factors as possible, so we thought defining the browser support guidelines that we want contributors to follow was a vital step in preparation for the v1 release.

The document isn’t yet finished, but we are working on it as we speak and will be sharing it soon enough.

Future tasks

You can see the roadmap that we have planned for Vanilla in preparation for v1 and after in Trello, but there are few key tasks that we want to carry out before September that we’d like to highlight:

  • Defining the accessibility standards that all patterns will have to follow, and adding automated tests to the build process to ensure they are adhered to
  • Conducting an internal accessibility audit and making as many changes as we can to improve accessibility
  • Redesigning the dedicated Vanilla website to include the new documentation we are writing and other pieces of useful information, including the style guide itself — all living together in one single site
  • And, obviously, making sure that Vanilla has its own logo — as any respectable framework does :)

Final words

This is all from me for now! Barry is writing a companion post that will go into more detail about the technical tasks that are being done on Vanilla, which he will be publishing soon.

We would love to know if you have any ideas on how to improve Vanilla — share your thoughts in the comments.

Read more

Vancouver sprint recap: MAAS and Juju

This was my first cycle sprint within the Cloud design team and my first time to Vancouver, Canada #winner

Having only been with Canonical for 8 weeks and working closely my fellow design colleagues, it was a great opportunity for me meet and collaborate with product engineers working around the world.

Not only was it great to meet engineers but also to sit in meetings with them and learn more about our products, giving me further insight and understanding into MAAS. Discussing new features, sketching, presenting and planning during the week really helped us to evolve our thinking about what we plan to deliver in the next few months. I also had the chance to showcase recent designs and get feedback from a variety of people across different areas of the business.

An exciting new project I worked on whilst at the sprint was, a tool that enables you to deliver and package your app to any Linux desktop or cloud server. I was given the task of creating a micro website promoting this tool and showcasing how easy it is to use to setup your app.

But it wasn’t just all #workworkwork… as the evenings gave us opportunity to socialise and get to know different people and explore the city of Vancouver.

It’s an exciting time to be at Canonical with big product releases on the horizon. I’m looking forward to our releases of MAAS 2.0 and Juju 2.0!

Below are some photos of our week in Vancouver. Enjoy :)

Vancouver sprint

Vancouver sprint

Vancouver sprint

Read more