Canonical Voices

Steph Wilson

Today we celebrate our amazing Ubuntu Community and show our appreciation for all the hard work put into making Ubuntu what it is today.

Ubuntu is not just an operating system, it is a whole community in which everybody collaborates with everybody to bring to the life a wonderful human experience. When you download the ISO, burn it, install it and start to enjoy it, you know that a lot of people made magnificent efforts to deliver the best Ubuntu OS possible.

To show our appreciation, the Community Managers and Designers have nominated several community application developers to receive a special thank you for their outstanding work:

  • Dan Chapman (dekko)
  • Boren Zhang (dekko)
  • Kunal Parmar (calendar)
  • Stefano Verzegnassi (docviewer)
  • Riccardo Padovani (calculator, notes)
  • Bartosz Kosiorek (calculator, clock)
  • Roman Shchekin (shorts, docviewer)
  • Joey Chan (shorts)
  • Victor Thomson (music, weather)
  • Andrew Hazen (music, weather)
  • Nekhelesh Ramananthan (clock)
  • Niklas Wenzel (terminal, dekko/platform)

We’ll send everyone an official Ubuntu keychain and sticker pack.


We also got hold of some other special Ubuntu items and because it is impossible to pick favourites, names were drawn out of a hat:



The following folks will be receiving a special Ubuntu gift from us:

3rd prize: An official Ubuntu hat – Niklas Wenzel


2nd prize: An official Ubuntu pad from Castelli – Andrew Hazen


1st prize: An official Ubuntu wireless mouse from Xoopar – Joey Chan


Well done guys!

Community Appreciation Day merchandise pack

Models not included.

Show your appreciation:

  • Ping an IRC Ubuntu channel and leave a thank you
  • Send an email to a mailing list; you can do it to a LoCo mailing list
  • On social media:
  • Or if you see a community member in the street, go up to them and give them a well-deserved pat on the back :)

For everyone who works out of passion and love for Ubuntu: we thank you, and hope it will encourage more contributors to join and make Ubuntu even better!

Read more
Anthony Dillon

Using Vanilla with Jekyll

We’re using NPM as Vanilla’s package manager. Which gives us a number of advantages such as, an easy way to install and update the CSS framework. This all worked fine until we hit an issue with Github Pages. They do not supporting install scripts therefore it is not possible in npm install. Highlighted in this issue #4 on the Jekyll Vanilla theme project.

There are a number of ways to use Vanilla with Jekyll. Here are the number of methods we discussed with their pros and cons.

Commit node_modules

This is not recommended as it duplicates a lot of code. The repo will grow in size as it will include all the framework code also.

Clone and commit Vanilla without NPM

Again this will include the entire framework in the repos code base. Another downfall would be the loss of the NPM update process.

Use Git submodules

This is the method we went with in the end. Creating a submodule in the git repo does not add all the code to the project but includes a reference and path to include the framework.

By running the following command it will pull down the framework into the correct location.

We lose NPM’s functionality but submodules are understood and run when a Github Pages are built.


These methods were derived from a short exploration, but solved our issue. Any better methods would be very much welcomed in the comments. You can see a demo of the Vanilla theme running on the projects Github Page below:

Read more

After many hours of research, testing and never-ending questions about structure, design, aesthetics and function, we’re very happy to announce that Jujucharms has a new homepage!

All through this site redesign, our main aim has been to make complex content easy to digest and more fun to read. We’ve strived to create a website that not only looks beautiful, but also succeeds in thoroughly explaining what Juju is and the way it can improve your workflow.

Key content is now featured more prominently. We wanted the homepage to be illustrative and functional, hence the positioning of a bold headline and clear call to action which users immediately see as they access the site.

One of the key change between the old homepage and the new is the addition of two visual diagrams, which we have made sure to optimise for whichever device users may be accessing the site with. The first diagram explains the most relevant aspects of the service and how users can incorporate it into their workflow (Fig. 1). The second explains the different elements that compose Juju and the way the service works at a technical level (Fig. 2).

jujucharms-home-diagramFigure 1.

jujucharms-home-2Figure 2.

After scrolling, visitors encounter a section which allows direct access into the store, encouraging them to explore the wide range of services it offers. This allows for a more hands-on discovery and understanding of what Juju is – users can either start designing straight away, test it, or explore the site if they wish to find more information before trying it out. homepage discovery

Overall, we’ve made sure to re-design our homepage in a way that truly benefits our audience. In order to do so we conducted numerous user testing sessions throughout the development of the site and re-iterated the designs based on our user’s feedback. This approach enabled us to understand which content and elements should be prioritised and define the best way to evolve the design.

We collaboratively reviewed and analysed our findings as a team throughout the process and made decisions on next steps to take. After quite a few iterations we hope to have designed a homepage which reflects the core concept and benefits of Juju, and that it becomes something that users will want to come back to.

We hope you like it and look forward to hearing your thoughts about it!

Read more
Inayaili de León Persson

Ubuntu 15.10 is here!

And has a brand new homepage too!

The new homepage gives a better overview and links to all Ubuntu products. We also wanted to give visitors easy access to the latest Ubuntu news, so we’ve included a ‘latest news’ strip right below the big intro hero with links to featured articles on Ubuntu Insights.

We’ve also improved the content and flow of the cloud section, and brought the phone and desktop sections up to date.

Let us know what you think. And try the new Ubuntu 15.10! homepage before and after release

Read more
James Mulholland

We sat down with Dekko star Dan Chapman to get an insight into how he got involved with Ubuntu and his excitement for the release of the Pocket Desktop.


Dan has been an active member of the Community since 2013, where he has worked closely with our Design Team to create one of our first convergent showcase apps: Dekko. He also helps out with the Ubuntu QA community with package testing and automated tests for the ubuntu-autopilot-tests project.

The Dekko app is an email client that we are currently developing to work across all devices: mobile, tablet and desktop. If you are interested in contributing to Dekko, whether that be writing code, testing, documentation, translations or have some super cool ideas you would just like to discuss. Then please do get in touch, all contributions are welcomed!

Dan can be reached by email or pop by #dekko on or see his wiki page

Early Dekko exploration

Dekko Phone Retro 1

What inspired you to contribute?

I first got involved with the Community in 2013, where Nicholas Skaggs introduced me to the Quality Team to write test cases for automated testing for the Platform. I can’t remember why I started exactly, but I saw it as an opportunity to improve it. Ever since then it’s been a well worth it experience.

What is it about open source that you like?

I like the fact that in the Community everyone has a common goal to build something great.

How does it fit into your lifestyle?

I study from home at the moment so I have to divide my time between my family, Ubuntu and my studies.

What I do for Ubuntu and my course are quite closely tied. The stuff I do for Ubuntu is giving me real life practical skills that I can relate to my course, which is mainly theory based.

Have you made your work with the Ubuntu Community an integral part of your studies as well?

I’m actually doing a project at the moment that is to do with my work on Dekko, but it’s for interacting with an exchange server and implementing a client side library. Hopefully when that’s done I can bring it into Dekko on a later date. I try to keep my interests parallel.

How much time does it take you to develop an app?

Quite a large proportion of my time goes towards Ubuntu.

How is it working remotely?

I find it more than effective. I mean it would be great to meet people face-to-face too.

Dekko development

Dekko Phone Retro 2

What are you most excited about?

Being able to have a full-blown computer in my pocket. As soon as it’s available i’m having the pocket desktop.

Do you use your Ubuntu phone as your main device?

I do yes. The rest of the family do too. I even got my eldest boy, who’s 9 to use it, as well as my partner and mother-in-law.

How is it working with the Ubuntu Design Team?

It’s been great actually because i’m useless at design. There’s always something to improve on, so even if the designs aren’t ready there’s still enough to work on. There hasn’t been big waits in-between or waiting for you guys as you’re busy. The support is there if you need it.

Have you faced any challenges when working on an app for many form factors (phone, tablet, desktop etc)?

The only challenge is getting the design before the toolkit components are ready. It was a case of creating custom stuff and trying to not cause myself too much pain when I have to switch. The rest has been plain sailing as they toolkit is a breeze to use, and the Design team keep me informed of any changes.

What’s the vibe like in the Community at the moment?

I speak to a fair few of them now through Telegram, that seems to be the place to talk now there’s an app for it. It’s nice you can ping your question to anyone and you’ll get an immediate response relatively quickly. Alan Pope, always gives you answers.

What are you thoughts on the Pocket Desktop?

It is exciting as it’s something different. I don’t think there’s competition, as we all have different target audiences we are reaching to. I’m really excited about where the Platform is heading.

The future of convergent Dekko

Dekko Future

Read more
Robin Winslow

Last weekend I went to my first Pycon, my second conference in a fortnight.

The conference runs from Friday to Monday, with 3 days of talks followed by one day of “sprints”, which is basically a hack day.

PyCon has a code of conduct to discourage any form of othering:

Happily, PyCon UK is a diverse community who maintain a reputation as a friendly, welcoming and dynamic group.

We trust that attendees will treat each other in a way that reflects the widely held view that diversity and friendliness are strengths of our community to be celebrated and fostered.

And for me, the conference lived up to this, with a very friendly feel, and a lot of diversity in its attendants. The friendly and informal atmosphere was impressive for such a large event with more than 450 people.

Unfortunately, the Monday sprint day was cut short by the discovery of an unexploded bomb.

Many keynotes, without much Python

There were a lot of “keynote” talks, with 2 on Friday, and one each on Saturday and Sunday. And interestingly none of them were really about Python, instead covering future technology, space travel and the psychology of power and impostor syndrome.

But of course there were plenty of Python talks throughout the rest of the day – you can read about them on my other post. And I think it was a good decision to have more abstract keynotes. It shows that the Python community really is more of a general community than just a special interest group.

Van Lindberg on data economics, Marx and the Internet of Things

In the opening keynote on Friday morning, the PSF chairman showed that total computing power is almost doubling every year, and that by 2020, the total processing power in portable devices will exceed that in PCs and servers.

He then used the fact that data can’t travel faster than 11.8 inches per nanosecond to argue that we will see a fundamental shift in the economics of data processing.

The big-data models of today’s tech giants will be challenged as it starts to be quicker and make more economic sense to process data at source, rather than transfer it to distant servers to be processed. Centralised servers will be relegated to mere aggregators of pre-processed data.

He likened this to Marx seizing the means of production in a movement which will empower users, as our portable Things start to hold the real information, and choose who to share it with.

I really hope he’s right, and that the centralised data companies are doomed to fail to be replaced by the Internet of Autonomous Things, because the world of centralised data is not an equal world.

Does Python have a future on small processors? Isn’t it too inefficient?

In a world where all the interesting software is running on light-weight portable devices, processing efficiency becomes important once again. Van used this to argue that efforts to run Python effectively on low-powered devices, like MicroPython, will be essential for Python as a language to survive.

Daniele Procida: All I really want is power

The second keynote was just after lunch on Friday, Daniele Procida, organiser of DjangoCon Europe openly admitted that what he really wanted out of life was power. He put forward the somewhat controversial idea that power and usefulness are the same thing, and that ideas without power are useless.

He made the very good point that power only comes to those who ask for it, or fight for it. And that if we want power not to be abused, we really need to talk about it a whole lot more, even though it makes people uncomfortable (try asking someone their salary). We should acknowledge who has the power, and what power we have, and watch where the power goes.

He suggested that, while in politics or industry, power is very much a rivalled good, in open source it is entirely an unrivalled good. The way you grab power in the open source community is by doing good for the community, by helping out. And so by weilding power you are actually increasing power for those around you.

I don’t agree with him on this final point. I think power can be and is hoarded and abused in the open source community as well. A lot of people use their power in the community to edge out others, or make others feel small, or to soak up influence through talks and presentations and then exert their will over the will of others. I am certainly somewhat guilty of this. Which is why we should definitely watch the power, especially our own power, to see what effect it’s having.

The takeaway maxim from this for me is that we should always make every effort to share power, as opposed to jealously guarding it. It’s not that sharing power in the open source community is inevitable or necessarily comes naturally, but at least in the open source community sharing power genuinely can help you gain respect, where I fear the same isn’t so true of politics or industry.

Dr Simon Sheridan: Landing on a comet: From planning to reality

Simon Sheridan was an incredibly most humble and unassuming man, given his towering achievements. He is a world-class space scientist who was part of the European Space Agency team who helped to land Rosetta on comet 67P.

Most of what he mentioned was basically covered in the news, but it was wonderful to hear it from his perspective.

Naomi Ceder: Confessions of a True Impostor

When, a short way into her Sunday morning keynote, Naomi Ceder asked the room:

How many of you would say that you have in some way or another suffered from imposter syndrome along with me?

Almost everybody put their hands up. This is why I think this was such an important talk.

She didn’t talk about this per se, but contributing to the open source community is hard. No-one talks about it much, but I certainly feel there’s a lot of pressure. Because of its very nature, your contributions will be open, to be seen by anyone, to be criticised by anyone. And let’s face it, your contributions are never going to be perfect. And the rules of the game aren’t written down anywhere, so the chance of being ridiculed seem pretty high. Open source may be a benevolent idea, but it’s damned scary to take part in.

I believe this is why less than 2% of open source contributors are female, compared with more like 25-30% women in software development in general. And, as with impostor syndrome, the same trend is true of other marginalised groups. It’s not surprising to me that people who are used to being criticised and discriminated against wouldn’t subject themselves to that willingly.

And, as Naomi’s question showed, it is not just marginalised people who feel this pressure, it’s all of us. And it’s a problem. As we know, confidence is no indicator of actual ability, meaning that many many talented people may be too scared to contribute to open source.

As Naomi pointed out, impostor syndrome is a socially created condition – when people are expected to do badly, they do badly. In fact I completely agree with her suggestion that the existing Wikipedia definition of impostor syndrome (at the time of writing) could be more sensitively phrased to define it as a “social condition” rather than a “psychological phenomenon”, as well as avoiding singling out women.

While Naomi chose to focus in her talk on how we personally can try to mitigate feelings of being an impostor, I think the really important message here is one for the community. It’s not our fault that open source is scary, that’s just the nature of openness. But we have to make it more welcoming. The success of the open source movement really does depend on it being diverse and accepting.

What I think is really interesting is that stereotype threat can be mitigated by reminding people of their values, of what’s important to them. And this is what I hope will save open source. The more we express our principles and passion for open source, the more we express our values, the easier it is to counter negative feelings, to be welcoming, to stop feeling like impostors.

A great conference

Overall, the conference was exhausting, but I’m very grateful that I got to attend. It was inspiring and informative, and a great example of how to maintain a great community.

If you want you can now go and read about the other talks.

(Also published on

Read more
Robin Winslow

The weekend before last, I went to PyCon UK 2015.

I already wrote about the keynotes, which were more abstract. Here I’m going to talk about the other talks I saw, which were generally more technical or at least had more to do with Python.


The talks I saw covered a whole range of topics – from testing through documentation and ways to achieve simplicity to leadership. Here are some key take-aways:

The talks

Following are slightly more in-depth summaries of the talks I thought were interesting.


Leadership of Technical Teams – Owen Campbell

There were two key points I took away from this talk. The first was Owen’s suggestion that leaders should take every opportunity to practice leading. Find opportunities in your personal life to lead teams of all sorts.

The second point was more complex. He suggested that all leaders exist on two spectra:

  • Amount of control: hand-off to dictatorial
  • Knowledge of the field: novice to expert

The less you know about a field the more hands-off you should be. And conversely, if you’re the only one who knows what you’re talking about, you should probably be more of a dictator.

Although he cautioned that people tend to mis-estimate their ability, and particularly when it comes to process (e.g. agile), people think they know more than they do. No-one is really an expert on process.

He suggested that leading technical teams is particularly challenging because you slide up and down the knowledge scale on a minute-to-minute basis sometimes, so you have to learn to be authoritative one moment and then permissive the next, as appropriate.

Document all the things – Kristian Glass

Kristian spoke about the importance, and difficulty, of good documentation.
Here are some particular points he made:

  • Document why a step is necessary, as well as what it is
  • Remember that error messages are documentation
  • Try pair documentation – novice sitting with expert
  • Checklists are great
  • Stop answering questions face-to-face. Always write it down instead.
  • Github pages are better than wikis (PRs, better tracking)

One of Kristian’s main points was that it goes against the grain to write documentation, ‘cos the person with the knowledge can’t see why it’s important, and the novice can’t write the documentation.

He suggested pair documentation as a solution, which sounds like a good idea, but I was also wondering if a StackOverflow model might work, where users submit questions, and the team treat them like bugs – need to stay on top of answering them. This answer base would then become the documentation.


Asking About Gender – the Whats, Whys and Hows – Claire Gowler

Claire spoke about how so many online forms expect people to be either simply “male” or “female”, when the truth can be much more complicated.

My main takeaway from this was the basic point that forms very often ask for much more information than they need, and make too many assumptions about their users. When it comes to asking someone’s name, try radically reducing the complexity by just having one text field called “name”. Or better yet, don’t even ask their name if you don’t need it.

I think this feeds into the whole field of simplicity very nicely. A very many apps try to do much more than they need to, and ask for much more information than they need. Thinking about how little you know about your user can help you realise what you actually don’t need to know about your user.

Finding more bugs with less work – David R. MacIver

David MacIver is the author of the Hypothesis testing library.

Hypothesis is a Python library for creating unit tests which are simpler to write and more powerful when run, finding edge cases in your code you wouldn’t have thought to look for. It is stable, powerful and easy to add to any existing test suite.

When we write tests normally, we choose the input cases, and we normally do this and we often end up being really kind to our tests. E.g.:

What Hypothesis does it help us test with a much wider and more challenging range of values. E.g.:

There are many cases where Hypothesis won’t be much use, but it’s certainly good to have in your toolkit.


Simplicity Is A Feature – Cory Benfield

Cory presented simplicity as the opposite of complexity – that is, the fewer options something gives you, the more simple and straightforward it is.

“Simplicity is about defaults”

To present as simple an interface as possible, the important thing is to have many sensible defaults as possible, so the user has to make hardly any choices.

Cory was heavily involved in the Python Requests library, and presented it as an example of how to achieve apparent simplicity in a complex tool.

“Simple things should be simple, complex things should be possible”

He suggested thinking of an “onion model”, where your application has layers, so everything is customisable at one of the layers, but the outermost layer is as simple as possible. He suggested that 3 layers is a good number:

  • Layer 1: Low-level – everything is customisable, even things that are just for weird edge-cases.
  • Layer 2: Features – a nicer, but still customisable interface for all the core features.
  • Layer 3: Simplicity – hardly any mandatory options, sensible defaults
    • People should always find this first
    • Support 80% of users 80% of the time
    • In the face of ambiguity do the right thing

He also mentioned that he likes README driven development, which seems like is an interesting approach.

How (not) to argue – a recipe for more productive tech conversations – Harry Percival

I think this one could be particularly useful for me.

Harry spoke about how many people (including him) have a very strong need to be right. Especially men. Especially those who went to boarding school. And software development tends to be full of these people.

Collaboration is particularly important in open source, and strongly disagreeing with people rarely leads to consensus, in fact it’s more likely to achieve the opposite. So it’s important that we learn how to get along.

He suggests various strategies to try out, for getting along with people better:

  • Try simply giving in, do it someone else’s way once in a while (hard to do graciously)
  • Socratic dialogue: Ask someone to explain their solution to you in simple terms
  • Dogfooding – try out your idea before arguing for its strength
  • Bide your time: Wait for the moment to see how it goes
  • Expose yourself to other social situations, where arguments are less acceptable

All of this comes down to stepping back, waiting and exercising humility. All of which are easier said than done, but all of which are very valuable if I could only manage it.

FIDO – The dog ate my password – Alex Willmer

After covering fairly common ground of how and why passwords suck, Alex introduced the FIDO alliance.

The FIDO alliance’s goal is to standardise authentication methods and hopefully replace passwords. They have created two standards for device-based authentication to try to replace passwords:

  • UAF: First-factor passwordless biometric authentication
  • U2F: Second-factor device authentication

Browsers are just starting to support U2F, whereas support for UAF is farther off. Keep an eye out.

Data Visualisation with Python and Javascript – crafting a data-visualisation for the web – Kyran Dale

Kyran spoke about visualising data, and demoed using Scrapy and Pandas to retrieve the Nobel laureatte data from Wikipedia, using Flask to serve it as a RESTful API, and then using D3 to create an interactive browser-based visualisation.

(Also published on

Read more
Steph Wilson

We believe that the first impression matters, especially when it comes to introducing a new product to a user for the first time. Our aim is to delight the user from the moment they open the box, through to the setup wizard that will help them get started with their new phone.

Devices have become an essential part of our everyday lives. We choose carefully the ones we want to adopt, taking into account all manner of factors that influence our lifestyle and how we conduct our everyday tasks. So when buying a totally new product, with unfamiliar software, or from a new brand, you want to make the first impression count in order to seduce and reassure the user that this product is for them.

The out of the box experience (OOBE) is one of the most important categories of software usability. It essentially says how easy your software is to use, as well as introducing the user into your brand through visual design and tone of voice, which can convey familiarity and trust within your product.

How did we do it?

We started to look at research around users past experiences when setting up a new device and their feelings about the whole process. We also took a look at what our competitors were doing, taking into account current patterns and trends in the market.

From gathering this research we started to simplify as much as possible the OOBE workflow. Taking into consideration the good and the bad things, we started to define our design goals:

  • Design for seduction
  • Simplicity
  • Introduce the brand through design
  • Transform the setup wizard

What did we change?

First of all we started from the smallest screen, taking the existing screens we have for mobile and assessing the design faults and bugs.

In order to create a consistent experience across all devices, we drew together common first experiences found on the mobile, tablet and desktop:

  • Choosing a language
  • Wifi setup
  • Choosing a Time Zone
  • Choosing a lock screen option

One of the major changes we wanted to achieve was to give the user the same experience across all devices, moving us closer to achieving a seamless convergent platform.

What did we achieve?

  • We achieved our main aim in creating the same visual experience across all devices.



  • We defined two types of screens: Primary screen (left), Secondary screen (right)

Image 1

The secondary screens created more space for forms, which helped us to define a consistent and intuitive animation between screens.


  • All the dialogs were transformed where possible into full screens. We kept the dialogs only to communicate to the user confirmation or error messages.

Image 2


  • The desktop installer was simplified and modernized.

desktop 2

The implementation of the OOBE has already begun and we cannot wait for you to open the box and experience it on your new Ubuntu device.

UX Designer: Andreea Pirvu

Visual Designer: Grazina Borosko

Read more
Robin Winslow

Prepare for when Ubuntu freezes

I routinely have at least 20 tabs open in Chrome, 10 files open in Atom (my editor of choice) and I’m often running virtual machines as well. This means my poor little X1 Carbon often runs out of memory, at which point Ubuntu completely freezes up, preventing me from doing anything at all.

Just a few days ago I had written a long post which I lost completely when my system froze, because Atom doesn’t yet recover documents after crashes.

If this sounds at all familiar to you, I now have a solution! (Although it didn’t save me in this case because it needs to be enabled first – see below.)


The magic SysRq key can run a bunch of kernel-level commands. One of these commands is called oom_kill. OOM stands for “Out of memory”, so oom_kill will kill the process taking up the most memory, to free some up. In most cases this should unfreeze Ubuntu.

You can run oom_kill from the keyboard with the following shortcut:

Except that this is disabled by default on Ubuntu:

Enabling SysRq functions

For security reasons, SysRq keyboard functions are disabled by default. To enable them, change the value in the file /etc/sysctl.d/10-magic-sysrq.conf to 1:

And to enable the new config run:

SysRq shortcut for the Thinkpad X1

Most laptops don’t have a physical SysRq key. Instead they offer a keyboard combination to emulate the key. On my Thinkpad, this is fn + s. However, there’s a quirk that the SysRq key is only “pressed” when you release.

So to run oom_kill on a Thinkpad, after enabling it, do the following:

  • Press and hold alt
  • To emulate SysRq, press fn and s keys together, then release them (keep holding alt)
  • Press f

This will kill the most expensive process (usually the browser tab running in my case), and freeup some memory.

Now, if your computer ever freezes up, you can just do this, and hopefully fix it.

(Also posted on

Read more
Jamie Young

dConstruct 2015


We had a great time at dConstruct in Brighton last Friday. Ubuntu was the premier sponsor of the event, so 15 of us headed down from London in the small hours of the morning to set up our stand and enjoy a day out.

Origami competition



Our stand became a landscape of wolves and unicorns as attendees of the conference took up our challenge to fold one of these animals (with instructions) to win themselves a brand new BQ Aquaris E5 Ubuntu Phone.

The talks



The theme of the talks was ‘Designing the Future’ so we had robots, The Jetsons, various superheroes and The Terminator all making an appearance during the day.

Josh Clark demonstrated real magic on stage. Matt Novak revealed the secret behind robot vacuum cleaners of the 1950s (they were radio-controlled). Nick Foster brought us all back down to earth with a great talk on designing for the mundane and finally Dan Hill encouraged us to look more closely at the planning regulation notices pinned to lampposts.

If you want to hear all the talks from the day you can find them here.

A well deserved lunch!


After a morning of mental sustenance we needed some real food in our stomachs and we all set off for a tasty lunch at the Chilli Pickle, just around the corner from the venue. Feeling energised from the spicy food, it was back for round two of talks…

Positive feedback



From the moment the doors opened we had people coming up to the stand to speak to us about Ubuntu. We had a really positive response from attendees to the stand, where we were showing off demos of both Ubuntu Phones. People were really happy to see us, which was nice! From our end, it was invaluable meeting you all and hearing all the interesting questions you had for us. We hope we managed to answer them all!

A sunny day out

A beautiful sunny day, without a drop of rain, made it for a nice day out of the office: that alone is usually enough to fill anyone with energy and inspiration.

The future is sponsored by Ubuntu

We are inspired to support entrepreneurs and inventors focused on life-changing projects. We’re building open source tools for the next generation of devices, things, desktops and clouds.

Take a look at

Join us

Passionate about good design and creating delightful experiences? We’re looking for people who love to learn and share their knowledge and ideas.

See all the design jobs on

Read more
Inayaili de León Persson

We’re going to be at dConstruct!

Ubuntu is once again sponsoring the excellent dConstruct conference, taking place this Friday, 11th September in Brighton.

This year’s theme is “Designing the future” and we can’t wait to hear what the stellar lineup of speakers has to share.

As ever, if you’re going to be there, come and say hi, and grab a few Ubuntu goodies while you’re at it.

In the meantime, why not listen to the dConstruct podcast, where Jeremy Keith talks to the speakers before the event?

See you on Friday!

Ubuntu at dConstruct 2014

Read more
Inayaili de León Persson

August’s reading list

The design team members are constantly sharing interesting, fun, weird, links with each other, so we thought it might be a nice idea to share a selection of those links with everyone.

Here are the links that have been passed around during last month:

Thanks to Robin, Luca, Elvira, Anthony, Jamie, Joe and me, for the links this month!

Read more
Tristram Oaten

Publishing Vanilla

We’ve got a new CSS framework at Canonical, named Vanilla. My colleague Ant has a great write-up introducing Vanilla. Essentially it’s a CSS microframework powered by Sass. The build process consists of two steps, an open source build, and a private build.

Open Source Build

While there are inevitably componants that need to be kept private (keys, tokens, etc.) being Canonical, we want to keep much of the build in the open, in addition to the code. We wanted the build to be as automated and close to CI/CD principles as possible. Here’s what happens:

Committing to our github repository kicks off a travis build that runs gulp tests, which include sass-lint. And we also use to make sure our npm dependencies are up to date. All of these have nice badges we can link to right from our github page, so the first thing people see is the heath of our project. I really like this, it keeps us honest, and informs the community.

Not everything can be done with travis, however, as publishing Vanilla to npm, updating our project page and demo site require some private credentials. For the confidential build, we use Jenkins. (formally Hudson, a java-based build management system.).

Private Build with Jenkins

Our Jenkins build does a few things:

  1. Increment the package.json version number
  2. npm publish (package)
  3. Build Sass with npm install
  4. Upload css to our assets server
  5. Update Sassdoc
  6. Update demo site with new CSS

Robin put this functionality together in a neat bash script:

We use this script in a Jenkins build that we kick off with a few parameters, point, minor and major to indicate the version to be updated in package.json. This allows our devs push-button releases on the fly, with the same build, from bugfixes all the way up to stable releases (1.0.0)

After less than 30 seconds, our demo site, which showcases framework elements and their usage, is updated. This demo is styled with the latest version of Vanilla, and also serves as documentation and a test of the CSS. We take advantage of github’s html publishing feature, Github Pages. Anyone can grab – or even hotlink – the files on our release page.

The Future

It’d be nice for the regression test (which we currently just eyeball) to be automated, perhaps with a visual diff tool such as PhantomCSS or a bespoke solution with Selenium.


Vanilla is ready to hack on, go get it here and tell us what you think! (And yes, you can get it in colours other than Ubuntu Orange)

Read more
Robin Winslow

pre {font-size: 1em; margin-bottom: 0.75em; padding: 0.75em} code {padding-left: 0.5em; padding-right: 0.5em} pre code {padding: 0; display: block;}

I recently tried to setup OpenID for one of our sites to support authentication with, and it took me much longer than I’d anticipated because our site is behind a reverse-proxy.

My problem

I was trying to setup OpenID with the django-openid-auth plugin. Normally our sites don’t include absolute links ( back to themselves, because relative URLs (/hello-world) work perfectly well, so normally Django doesn’t need to know the domain name that it’s hosted it.

However, when authenticating with OpenID, our website needs to send the user off to with a callback url so that once they’re successfully authenticed they can be directed back to our site. This means that the django-openid-auth needs to ask Django for an absolute URL to send off to the authenticator (e.g.

The problem with proxies

In our setup, the Django app is served with a light Gunicorn server behind an Apache front-end which handles HTTPS negotiation:

User <-> Apache <-> Gunicorn (Django)

(There’s actually an additional HAProxy load-balancer in between, which I thought was complicating matters, but it turns out HAProxy was just passing through requests absolutely untouched and so was irrelevant to the problem.)

Apache was setup as a reverse-proxy to Django, meaning that the user only ever talks to Apache, and Apache goes off to get the response from Django itself, with Django’s local network IP address – e.g.

It turns out this is the problem. Because Apache, and not the user directly, is making the request to Django, Django sees the request come in at rather than This meant that django-openid-auth was generating and sending the wrong callback URL of to

How Django generates absolute URLs

django-openid-auth uses HttpRequest.build_absolute_uri which in turn uses HttpRequest.get_host to retrieve the domain. get_host then normally uses the HTTP_HOST header to generate the URL, or if it doesn’t exist, it uses the request URL (e.g.:

However, after inspecting the code for get_host I discovered that if and only if settings.USE_X_FORWARDED_HOST is True then Django will look for the X-Forwarded-Host header first to generate this URL. This is the key to the solution.

Solving the problem – Apache

In our Apache config, we were initially using mod_rewrite to forward requests to Django.

RewriteEngine On
RewriteRule ^/?(.*)$$1 [P,L]

However, when proxying with this method Apache2 doesn’t send the X_Forwarded_Host header that we need. So we changed it to use mod_proxy:

ProxyPass /
ProxyPassReverse /

This then means that Apache will send three headers to Django: X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server, which will contain the information for the original request.

In our case the Apache frontend used HTTPS protocol, whereas Django was only using so we had to pass that through as well by manually setting Apache to pass an X-Forwarded-Proto to Django. Our eventual config changes looked like this:

<VirtualHost *:443>
    RequestHeader set X-Forwarded-Proto 'https' env=HTTPS

    ProxyPass /
    ProxyPassReverse /

This meant that Apache now passes through all the information Django needs to properly build absolute URLs, we just need to make Django parse them properly.

Solving the problem – Django

By default, Django ignores all X-Forwarded headers. As mentioned earlier, you can set get_host to read the X-Forwarded-Host header by setting USE_X_FORWARDED_HOST = True, but we also needed one more setting to get HTTPS to work. These are the settings we added to our Django

# Setup support for proxy headers

After changing all these settings, we now have Apache passing all the relevant information (X-Forwarded-Host, X-Forwarded-Proto) so that Django is now able to successfully generate absolute URLs, and django-openid-auth now works a charm.

Read more
Robin Winslow

We recently introduced Vanilla framework, a light-weight styling framework which is intended to replace the old Guidelines framework as the basis for our Ubuntu and Canonical branded sites and others.

One of the reasons we created Vanilla was because we ran into significant problems trying to use Guidelines across multiple different sites because of the way it was made. In this article I’m going to explain how we structured Vanilla to hopefully overcome these problems.

You may wish to skip the rationale and go straight to “Overall structure” or “How to use the framework”.

Who’s it for?

We in Canonical’s design team will definitely be using Vanilla, and we also hope that other teams within Canonical can start to use it (as they did with Guidelines before it).

But most importantly, it would be fantastic if Vanilla offers a solid enough styling basis that members of the wider community feel comfortable using it as well. Guidelines was never really safe for the community at large to use with confidence.

This is why we’ve made an effort to structure Vanilla in such a way that any or all of it can be used with confidence by anyone.

Limitations of Guidelines

Guidelines was initially intended to solve exactly one problem – to be a single resource containing all the styling for This would mean that we could update Guidelines whenever we needed to update’s styling, and those changes would propagate across all our other Ubuntu-branded sites (e.g.: or

So we simply structured the markup of these sites in the same way, and then created a single hosted CSS file, and linked to it from all the sites that needed Ubuntu styling.

As time went on, two large problems with this solution emerged:

  • As over 10 sites were linking to the same CSS file, updating that file became very cumbersome, as we’d have to test the changes on every site first.
  • As the different sites became more individual over time, we found we were having to override the base stylesheet more and more, leading to overly complex and confusing local styling.

This second problem was only exacerbated when we started using Guidelines as the basis for Canonical-branded sites (e.g.: as well, which had a significantly different look.

Architecture goals for Vanilla

Learning from our experiences with Guidelines, we planned to solve a few specific problems with Vanilla:

  • Website projects could include only the CSS code they actually needed, so they don’t have to override lots of unnecessary CSS.
  • We could release new changes to the framework without worrying about breaking existing sites, allowing us to iterate quickly.
  • Other projects could still easily copy the styles we use on our sites with minimal work

To solve these problems, we decided on the following goals:

  • Create a basic framework (Vanilla) which only contains the common elements shared across all our sites.

    • This framework should be written in a modular way, so it’s easy to include only the parts you need
  • Extend the basic framework in “theme” projects (e.g. ubuntu-vanilla-theme) which will apply specific styling (colours etc.) for that specific brand.

    • These themes should also only contain code which needs to be shared. Site-specific styling should be kept local to the project
  • Still provide hosted compiled CSS for sites to hotlink to if they like, but force them to link to a specific version (e.g. vanilla-framework-version-0.0.15.css) rather than “latest” so that we can release a new version without worry.

Sass modularisation

This modular structure would be impossible in pure CSS. CSS itself offers no mechanism for encapsulation. Fortunately, our team has been using Sass to write our CSS for a while now, and Sass offers some important mechanisms that help us modularise our code. So what we decided to create is actually a Sass mixin library (like Bourbon for example) using the following mechanisms:

Default variables

Setting global variables is essential for the framework, so we can keep consistent settings (e.g. font colours, padding etc.). Variables can also be declared with the !default flag. This allows the framework’s settings to be overridden when extending the framework:

We’ve used this pattern in each of the Vanilla themes we’ve created.

Separating concerns into separate files

Sass’s @import feature allows us to encapsulate our code into files. This not only keeps our code tidier, but it means that anyone hoping to include some parts of our framework can choose which files they want:

Keeping everything in a mixin

When a Sass file is imported any loose CSS is compiled directly to the output. But anything declared inside a @mixin will not be output unless you call the mixin.

Therefore, we set a goal of ensuring that all parts of our library can be imported without any CSS being output, so that you can import the whole module but just choose what you want output into your compiled CSS:


To avoid conflicts with any local sass setup, we decided to namespace all our mixins with the vf- prefix – e.g. vf-grid or vf-header.

Overall structure

Using the aforementioned techniques, we created one base framework, Vanilla Framework, which contains (at the time of writing) 19 separate “modules” (vf-buttons, vf-grid etc.). You can see the latest release of the framework on the project’s homepage, and see the framework in action on the demo page.

The framework can be customised by overriding any of the global settings inside your local Sass, as described above.

We then extended this basic framework with three branded themes which we will use across our sites:

You can of course create your own themes by extending the framework in the same way.

NPM modules

To make it easy to include Vanilla Framework in our projects, we needed to pick a package manager to use for installing it and tracking versions. We experimented with Bower, but in the end we decided to use the Node package manager. So now anyone can install and use any of the following packages:

Hotlinks for compiled CSS

Although for in-depth usage of our framework we recommend that you install and extend it locally, we also provide hosted compiled CSS files, both minified and unminified, for the Vanilla framework itself and all Vanilla themes, which you can hotlink to if you like.

To find the links to the latest compiled CSS files, please visit the project homepage.

How to use the framework

The simplest way to use the framework is to hotlink to it. To do this, simply link to the latest version (minified or unminified) directly in your HTML:

However, if you want to take full advantage of the framework’s modular nature, you’ll probably want to install it directly in your project.

To do this, add the latest version of vanilla-framework to your project’s package.json as follows:

Then, after you’ve npm installed, include the framework from the node_modules folder:

The future

We will continue to develop Vanilla Framework, with version 0.1.0 just around the corner. You can track our progress over on the project homepage and on Github.

In the near future we’ll switch over and to using it, and when we do we’ll definitely blog about it.

Read more
Richard McCartney

Converting old guidelines to vanilla

How the previous guidelines worked

Guidelines essentially is a framework built by the Canonical web design team. The whole framework has an array of tools to make it easy to create a Ubuntu themed sites. The guidelines were a collaboration between developers and designers and followed consistent look which meant in-house teams and community websites could have a consistent brand feel.

It worked in one way, a large framework of modules, helpers and components which built the Ubuntu style for all our sites. The structure of this required a lot of overrides and work arounds for different projects and added to a bloated nature that the guidelines had become. Canonical and cloud sites required a large set of overrides to imprint their own visual requirements and created a lot of duplication and overhead for each site.

There was no build system nor a way to update to the latest version unless using the hosted pre-compiled guidelines or pulled from our bazaar repository. Not having any form of build step meant having to rely on a local Sass compiler or setup a watcher for each project. Also we had no viable way to check linting errors or create a concrete coding standard.

The actual framework its self was a ported CSS framework into Sass. Not utilising placeholders or mixins correctly and with a bloated amount of variables. To change one colour for example or changing the size of an element wouldn’t be as easy as passing a mixin with set values or changing one variable.

Unlike how we have currently built in Vanilla, all preprocessor styles are created via mixins. Creating responsive changes would be done in a large media query at the end of any document and this again would be repeated for our Canonical or Cloud styles too.

Removing Ubuntu and Canonical from theme

Our first task in building Vanilla was referencing all elements which were ‘Ubuntu’ centric. Anything which had a unique class, colour or style. Once identified the team systematically took one section of each part of guidelines and removed the classes or variables and creating new versions. Once this stage was achieved the team was able to then look at refactoring and updating the code.

Clean-up and making it generic

We decided when starting this project to update how we write any new module / element. Linting was a big factor and when using a build system like gulp we finally had the ability to adhere to a coding standard. This meant a lot of modules / elements had to be rewritten and also improved upon, trimming down the Sass nesting, applying new techniques such as flex box and cleaning duplicated styles.

But the main goal was to make it generic, extendable and easy. Not the simplest of tasks, this meant removing any custom modules or specific style / classes but also building the framework to change via a variable update or a value change with in a mixin. We wanted the Vanilla theme to inherit another developers style and that would cascade through out the whole framework with ease. Setting the brand colour for example would effect the whole framework and change a multiple of modules / elements. But you are not restricted which we had as a bottle neck with the old guidelines.

Using Sass mixins

Mixins are a powerful part of Sass which we weren’t utilising. In guidelines they were used to create preprocessor polyfills, something which was annoying. Gulp now replaces that need. We used mixins to modularise the entire framework, thus giving flexibility over which parts of the framework a project requires.

The ability to easily turn on/off a section of vanilla felt very powerful but required. We wanted a developer to choose what was needed for their project. This was the opposite of guidelines where you would receive the entire framework. In Vanilla, each section our elements or modules would also be encapsulated with in mixins and on some have values which would effect them. For example the buttons mixin;

@mixin vf-button($button-color, $button-bg, $border-color) {
  @extend %button-pattern;
  color: $button-color;
  background: $button-bg;
  @if $border-color != null {
    border: 1px solid $border-color;
  &:hover {
    background: darken($button-bg, 6.2%);
    @if $button-bg == $transparent {
      text-decoration: underline;

The above code shows how this mixin isn’t attached to fixed styles or colours. When building a new Vanilla theme a few variable changes will style any button to the projects requirements. This is something we have replicated through out the project and creates a far better modular framework.

Creating new themes

As I have mentioned earlier a few changes can setup a whole new theme in Vanilla, using it as a base and then adding or extending new styles. Change the branding or a font family just requires overwriting the default value e.g $brand-colour: $orange !default; is set in the global variables document. Amending this in another document and setting it to $brand-colour: #990000; will change any element effected by brand colour thus creating the beginning of a new theme.

We can also take this per module mixin. Including the module into a new class or element and then extend or add upon it. This means themes are not constricted to just using what is there but gives more freedom. This method is particularly useful for the web team as we build themes for Ubuntu, Canonical and Cloud products.

An example of a live theme we have created is the Ubuntu vanilla theme. This is an extension of the Vanilla framework and is set up to override any required variables to give it the Ubuntu brand. Diving into the theme.scss It shows all elements used from Vanilla but also Ubuntu specific modules. These are exclusively used just for the Ubuntu brand but are also structured in the same manner as the Vanilla framework. This reduces complexity in maintaining these themes and developers can easily pick up what has been built or use it as a reference to building their own theme versions.

Read more
Steph Wilson

We have given our monochromatic icons a small facelift to make them more elegant, lighter and consistent across the platform by incorporating our Suru language and font style.

The rationale behind the new designs are similar to that of our old guidelines, where we have kept to our recurring font patterns but made them more streamlined and legible with lighter strokes, negative spaces, and a minimal solid shape.

What we have changed:

  • Reduced and standardized the strokes width from 6 or 8 pixels to 4.
  • Less solid shapes and more outlines.
  • The curvature radius of rectangles and squares has been slightly reduced (e.g message icon) to make them less ‘clumsy’.
  • Few outlines are ‘broken’ (e.g bookmark, slideshow, contact, copy, paste, delete) for more personality. This negative space can also represent a shadow cast.


Less solid shapes


Screenshot 2015-07-15 16.39.59


Screenshot 2015-07-15 16.38.19

Lighter strokes



Screenshot 2015-07-15 17.27.20


Screenshot 2015-07-15 17.26.34

Negative spaces



Screenshot 2015-07-15 17.30.01



Screenshot 2015-07-15 17.50.50


Font patterns 

Oblique lines are slightly curved

Screenshot 2015-07-16 13.39.03

Arcs are not perfectly rounded but rather curved


Screenshot 2015-07-15 16.38.19

Uppercase letters use right or sharp angles

Screenshot 2015-07-16 13.42.56

Vertical lines have oblique upper terminations.

Screenshot 2015-07-15 17.26.34

Nice soft curves

Screenshot 2015-07-16 13.44.16










Read more
Peter Mahnke

Ubuntu is a big Open Source project and there are a lot of websites in our community. The web team at Canonical literally doesn’t even know how many sites there are. We have heard there are over 200 subdomains alone, but we know that there are many more that are owned by local groups and teams outside that single domain.

Traditionally most of our work has been on and, but over the years, we have designed, often built and occasionally are responsible for the content of a series of key sites like:,,, And we have often attempted to provide on-brand versions of wiki and WordPress templates.

As the number of sites grew, we got tired of re-creating grids, templates, CSS all the time.

Enter guidelines

To resolve these issues, we created Ubuntu web guidelines. Instead of sites of cobbled together CSS and a borrowed grid, guidelines gave us something far more formalised and systematic. A grid, typography, core styles and pattern, all with our beautiful Ubuntu brand guidelines. We were not only able to maintain a whole set of sites from a single hosted set of CSS files, but others could borrow and use it easily. We even transitioned the guidelines to be responsive without breaking our sites. You can read more in our series of posts Making responsive.

Exit guidelines

Around two years ago, the web team started supporting the design and development of some of Canonical’s cloud apps, including Juju, MAAS, and Canonical OpenStack Autopilot installer. These apps have a different look and feel than And they often have special requirements, for example, MAAS is likely to be run in data centres without internet access for things like fonts, images, or CSS, that the guidelines did not natively support.

We looked at how to best adapt the guidelines to work with these web apps. We looked at how we were already making work, essentially overriding the Ubuntu branded guidelines and decided to change the entire approach.

Enter Vanilla

For Vanilla, we wanted to start over, but not have to rewrite everything. So our quick list of project goals was:

  • Minimise the changes to our existing html
  • Create a core theme that distilled the guidelines to its basic Ubuntu-ness
  • Make everything more modular, easy to add or remove components
  • Make it easy for anyone to create themes for each new project that could borrow from other themes
  • Create themes for ubuntu and canonical websites
  • Remove our reliance on javascript
  • Make it work stand-alone
  • Make it easy to build, develop and update
  • Invite other people both inside and outside Canonical to start using the framework

The future

So now we are close to releasing the first version of Vanilla. and will be moved over the coming months. Then we will look at moving other projects, like MAAS,, Landscape to the framework.

Please keep reading these posts, you can see Ant’s first post, Introducing Vanilla. And take a look at the project on GitHub and let us know what you think.

Read more