Canonical Voices

Posts tagged with 'notes'

Ivanka Majic

Designing in the open

On Tuesday 9th of April I gave a little talk at Mozilla’s “Designing in the Open” event. Along with the rest of the speakers I was asked to prepare a 10 – 15 minutes talk and to be prepared for a discussion to follow.

In preparation for the talk I spoke to a few people – designers and engineers – and one of them (@sil) said: “I hope you are going to publish this somewhere”. So here I am.

To help stimulate some discussion I decided to present some truths. You will have to wait for my follow up posts for something with more answers than questions!

Thank you for the fantastic illustration @zhenshuofang


Truth #1: It’s complicated

Design in the open is an ambiguous term behind which hides an endless stream of potential pitfalls, challenges and rewards.

It is complicated not just in the practical sense of not sitting in the same country, nevermind the same office, as the people you are working with.

I’ll go a bit stronger, design in the open is in my view an ill defined term which is why it is often such a contentious and emotionally fraught activity. I don’t want to get too philosophical but there are some questions that definitely need to be considered before you embark on a project to design something in the open.

Why design in the open? What is it that you hope to gain from doing this? What do you think your co-contributors are going to gain? Why do you want to make something in the open?

Do you really mean build something in the open? I would argue that design and engineering are both integral parts of making something and therefore to make that thing well you should never talk about the two activities as somehow divorced.

Something can be made in secret and still be completely open-source.

Do we mean everyone has a voice in the open? Because that is what it feels like to me. I don’t think people want to necessarily participate in a design process but rather they want to be heard. They want to feel included and like they have some influence and control.

When I first joined Canonical and Ubuntu I had this awful emotional pressure to do what felt like sitting in some sort of zoo that hosts design so that people could watch me work. “In this cage you will see a group of designers using what they call ‘post-its’. They can often be seen engaging in this activity where they stick them on walls and argue with each other about what should be written on them and how they should be grouped.”

Is that how design needs to be done to be truly open?

@mpt put it as: “the real issue is how much delay is there between someone having an idea and it appearing in the public and whether people who are not in the same room can get involved early enough to make a difference.”

That’s true and sometimes it isn’t possible for everyone to get involved in everything and that should be OK too. I have opinions on whether or not the Ubuntu Dash should be engineered in NUX or QML and I like my opinions to be heard but I don’t expect to actually have direct influence.

Are we talking about design in the open as in OpenIDEO or do we mean design in an existing open-source community?

I do have some very specific thoughts and suggestions around this but I will provide them in a second post!


Truth #2: Have no secrets

 If you want to design in the open you can’t have secrets. You can’t operate in a world of partial disclosure. It is an additional burden that quickly gets sidelined. It is too hard. There can be no trust and therefore there can be no real collaboration.

Since I joined Canonical in March 2009 we have been pursuing a design strategy of cross device convergence. Most of our work – and even the fact we have been doing it – has been confidential. This year we have gone public with our phone and tablet story and already it is approximately a million times easier to organise work with our community. I say a million but I might actually mean 2 million. You see, if your design strategy isn’t truly public then how can you explain your design direction? And, in an open-source environment which claims to be a meritocracy how can you properly justify your actions if you can’t tie them back to a clear design strategy?

The flipside is that in a world where a tada moment is still a useful promotional tool, can you ever have full disclosure and, if not, how can you work around that?


Truth #3: Play nicely

 Over the years (nearly 40 of them!) of school then work and life in general I have come to the conclusion that most people don’t get up in the morning and say to themselves: “Today I would like to be mediocre.”

 One thing that is hard with doing anything in the open is that it seems quite a number of people appear to assume that people *do* get up in the morning wanting to be mediocre or worse, that everyone else *is* mediocre (or worse!). It is another truth, but one that doesn’t justify a number of its own, that it seems easier to make that negative assumption when you are sitting in front of a computer writing a comment, filing a bug or writing to a mailing list.

 This works all sorts of ways round. From people on my team coming back from a Google Hangout and saying: “the developers had some really good ideas!” or a classic following an internal sprint: “you know, I really enjoyed myself hanging out with the developers this week, they are really a lot of fun!” to the developers saying things like: “I didn’t realise you guys actually cared about Ubuntu!”

 One could argue that if you are going to take a walk down a busy street then you should be prepared for people to bump into you, but in reality social norms exist which help us walk along a busy street without incurring actual injury.

I know what meritocracy means and I also know that some merit takes time to show and proving it is not always a case of: “your code compiled and you passed the code review”. Wikipedia asks us to assume good faith, let’s do that and also remember that you don’t actually need to shoulder barge to make your way down a crowded street.


Truth #4 Educate and share

 In order to work with people you need to communicate. Starting with the word design, moving on to the word open, and then through words like wireframe, mood board, sketch, distro, motu, if these words don’t have the same meaning to everyone who is trying to use them then you can’t actually have a conversation!

 It is very hard to collaborate if you can’t communicate. Take the time to explain what you are doing how and why.

 Have evidence-based conversations. Not because you need to prove yourself – that can be a really negative thing to carry around with you all the time – , but because it helps people learn. Engineers like to – need to – break problems down into tiny parts so that they can build them, help them break down and understand your ideas.


Truth #5 It’s brilliant

 This is the best truth of all. I get to work with some outstanding – if not awesome – people. Vish, Sense, Thorwil, Jason de Rose, and so many other who are community volunteers who have helped me deliver.

 Being part of the community itself is an experience that I don’t know how it would be possible to replicate elsewhere. Some of you may know that I travelled from Alaska to Argentina on a motorcycle and the open-source (note, not just Ubuntu) community helped me more than once. The most amazing example of which was the help we got from the Central America Software Libre guys and girls. We were in El Salvador and one of the bikers we met travelling had some bad news from home and needed to leave urgently. The problem was what to do with his bike and gear and how to organise flights etc. I spent 45 minutes on email and IRC (thanks to the 3G dongle I borrowed from the owner of the hostel we were in) and in that time people had volunteered secure parking in San Salvador and Managua (thanks @tatotat, @leogg and @n0rman and everyone else!)

 I agree that my story is more an opportunity to tell tales of my trip (can you really blame me?) but making the effort to be part of a community is more than just lines on your CV and that bit actually is awesome (pronounced with a British English accent to give it gravitas).

 These engineers I work with, they like to make things work. They go “WOW, this is going to be the best clock app in the world ever!” And then they go off and make it. Just like that. In their spare time!

Now that, that’s brilliant.

(Originally posted on

Read more
Calum Pringle

Well done to everyone working on the core utility apps – we’ve made amazing progress so let’s celebrate that!

We all want to see what’s coming up so here’s a summary of where we have been, where we are now and where we are going in our design process.

Right hand side image : our typical user experience design process.

Where have we been?

Scope and objectives

We started with a call for core app proposals from the Ubuntu Community team which received great responses! We chipped in on the effort and started thinking about our strategy for apps which we see as core utilities for Ubuntu Touch.

What we really want to do with these utilities is not just to make them work, but to use them as an opportunity to explore and express our Design Vision:

  • Focus on the content
  • Fast and natural interactions
  • Sophisticated style

Based on these we set out to establish the most essential user needs. Development began, laying the groundwork for envisaged functionality.

Research, concept development and requirements

We undertook different research activities to understand what we want these apps to do:

  • Researched mobile app usage and behaviours
  • Looked at our competitors – What are people using? What works and what doesn’t work?
  • Workshopped design ideas in the office and in the community

Read more here.

What emerged from all this research and exploration? Rituals.

We then wireframed key user journeys to unpack these concepts:

Where are we now?

Visual exploration

Our Visual designers are looking at both inspirational designs, and what it means for an app to feel Ubuntu.

Iterative prototyping

Through hangouts, irc chats and emails with our community developers, sharing ideas and feeding back on design and development, we have iterated the concepts. Throughout this process we’ve taken the opportunity to use real code to prototype ideas for everyone to play around with on an actual device. The progress we have made already is astounding! For example, here is how the Clock, Calendar and Calculator were shaping up at the start of last week:

Nekhelesh Ramananthan has posted a video of his teams latest work on the clock app here too.

(Weather is coming soon too!)

Where are we going next?

From here we will be iterating our designs through Launchpad to capture bugs for development and design. We will soon be testing the prototypes with users and sharing visual designs to communicate style of the apps from textures to layout of information.

After a fair amount of iteration, we will have both functional and aesthetically beautiful apps!

Read more
Christina Li

These last few weeks we have looked at the concepts behind our ritual apps, and explored key journeys for each. Now it is the turn of the weather app!

Sitting down with visual design (visual designs coming soon, watch this space!), we fleshed out the original weather concept to explore how it will meet the user journeys prioritised from our rituals metaphor.

Check today’s weather and forecast

I wonder what I should wear?

A weather app is a utility we use every day to decide how to get to work or what to wear. It’s essential that this app tells us how hot or cold it’s going to be or how much rain or wind we should expect!

  • The home view of the app shows essential information for the current weather, such as temperature and precipitation. Tap on the information panel to check what you need to wear for today’s weather.
  • The temperature display is defaulted to the user’s preference.
  • As the user scrolls up, the forecasted weather gradually changes to reflect the weather over the course of the day.
  • Once the scroll has reached a certain threshold, the forecast for the next day will snap into full view.

View yesterdays weather

Can I wear the same thing as yesterday?

  • User scrolls down to see yesterdays weather (this history feature is limited to just one day previous)
  • User taps on the information panel to reveal extra information.

Manage locations

  • Consistent to the Clock app, edit the location list from the toolbar
  • Add a city by tapping on “add city”, and either selecting from the list or searching.
  • Edit the list of stored cities by swiping to clear or drag from the left edge to rearrange (This is a new pattern we’re considering to rearrange items).

View different cities

  • To view other cities’ forecasts, users tap on the tab to display the list of cities they have selected, scrolls to select the city they want to view.

So, this wraps up the key journeys for the weather app as well as all the other ritual apps. We’ll post some teasers of the apps in action soon, and visual design!!! Exciting times.

As usual,  feel free to get in touch with us on the Ubuntu Phone mailing list and the IRC channel.

Read more
Inayaili León

Good Ubuntu books?

A few weeks ago we received a copy of the “No Starch Press” book “Ubuntu Made Easy”, by Rickford Grant with Phil Bull.

Ubuntu Made Easy book cover

The book’s main goal – which we fully approve of! – is to introduce Ubuntu to newcomers by taking readers through the various projects, with step-by-step instructions which demonstrate how to do things on Ubuntu, from the more basic to the more advanced tasks.

We think this is a great resource for anyone who’s thinking of delving into the Ubuntu world – highly recommended!

Are there any other books or resources that you’d recommend to someone who’s just new to Ubuntu? We’d like to hear your thoughts.

Read more
Mika Meskanen

Moving forward with the design of the core apps, we’ve been working on the interaction details of the clock for a while now, building on these concepts introduced a few weeks ago.

As with the calendar and calculator, we have outlined typical tasks a user wants to accomplish. We call them key journeys.

We have grouped the key journeys of the Clock app around its four tabs; Clock, Alarm, Timer and Stopwatch.

Clock : what time is it in New York?


  • Tap on “London” or swipe/scroll up to reveal a list of cities underneath
  • Tap on “New York” on the list
  • View scrolls back up, and shows the time in New York

Clock : adding a new city


  • Swipe up from the bottom edge to reveal toolbar
  • Tap on “Edit”
  • Tap on “Add city”
  • Select a city from the alphabetical list, or tap on the search field
  • Type in the name of the city, and select one from the results
  • New city is added to the list, you can rearrange the list by dragging list items around
  • When ready, tap on “Done” to return to the main view

Clock Easter egg: sunrise and sunset times

Here’s a little trick we’d like to add to the clock face: By tapping on it, you get the sunrise and sunset times for that location. To revert back to normal clock face, just tap on it again. Easy!

Alarm : set an alarm


  • To change the alarm time tap on the clock face
  • Clock face pops out larger, dial become interactive and a “Done” button appears in the middle
  • Turn the hour and minute dials to set the time. Counter above shows the set time. The label underneath dynamically shows the time to this alarm.
  • To make the alarm repeat, tap on “Repeat“ and a multiple selection list appears. To close, tap on “Repeat” again.
  • Similarly, you can tap on “Tone” to set the alarm tone
  • When you’re happy with your alarm, tap on “Done” in the middle of the clockface
  • Clockface pops back into its default size and alarm is toggled on

Alarm : toggle alarms on and off


  • Tap on ”Time to next alarm” or swipe up to see the list of alarms
  • As the panel containing the list slides in, the view with the clockface compresses to show just the digital clock and the “Time to next” button
  • In the list you can toggle alarms on and off
  • Return to the main view by swiping down, or tapping on the top part of the screen
  • Main view displays the next alarm, if no other alarm is selected

Alarm : create a new alarm


  • Swipe up from the bottom edge to reveal toolbar
  • Tap on “add alarm”
  • Clockface pops out to an edit mode.
  • Turn the dials to set the alarm time
  • Use options below to set Repeat, Tone and Vibrate
  • Once happy, tap on “Done” in the middle of the clock face.

Timer : set timer manually


  • Turn the dial clockwise to the time you want (alternatively, tap on plus and minus  to add or subtract a minute)
  • Tap “Start” and wait
  • When the timer hits zero the alarm sounds off
  • Acknowledge by tapping on “Done”

Timer : set timer from a preset


  • Tap on “Presets” or swipe/scroll up to reveal a list of presets
  • Tap on a preset, for example “Soft boiled egg”
  • Timer changes to the time set by the preset
  • Press “Start” to begin countdown

Stopwatch : simple stopwatch start, stop and reset


  • Tap on “Start” to make stopwatch go off
  • Tap on “Stop” to stop it. Tap on “Start” again, to continue or “Reset” to clear the stopwatch

Stopwatch : recording laps


  • Tap on “Lap” to create a lap
  • Lap counter in the middle rotates to the next number up
  • Lap also creates a blip on the rim of the clock face. It expands and fades out in a few seconds
  • To see the list of laps, tap on the lap counter or swipe/scroll up

Stopwatch Easter egg: time zoom

Finally, let’s have a look at a little playful detail that’s baked into the stopwatch. The stopwatch clock face has two modes: the first one shows seconds on the outer ring and hours on the inner ring. It’s all good and normal, but if you want to see time in finer detail and the dials rotate faster, just tap on the clock face – the view zooms in to display 1/100 seconds on the outside and seconds on the inside. This does not affect the timekeeping in anyway. To switch back, just tap on the clock face again.

That’s it! We’ll be chatting about this app and others in the usual places; the Ubuntu Phone mailing list and the IRC channel.

Read more
Calum Pringle

When we design an app, we consider the different types of information we are communicating and their relationships to one another. This helps us establish what content is of equal importance, what we want to be able to do with it, what is a detailed view of something else and so on.

We use three predominant navigation structures to navigate our apps: flat, contextual and deep.


We call the navigation “flat” when the user moves between main views of functionality that have equal importance. These views are navigated by using the tab navigation structure.


We call the navigation “contextual” when the user moves between different levels of detail within one view. These views are navigated by using the expansion navigation structure.


We call the navigation “deep” when the user moves up and down hierarchical levels of an application. These views are navigated by using the page stack navigation structure.

One last thing

We don’t combine flat with deep navigation in the same view -
the page stack (deep navigation) introduces a back button which, when combined with tabs (flat navigation), could be misinterpreted as another method for navigating between tabs.

And that’s it! Keep these navigation patterns in your mind when you are designing your app.

Read about navigation and the building blocks to make it happen in the App Design Guides.

Read more
Christina Li

A few weeks ago we introduced key screens for our core utility app designs, and we’ve been sketching key journeys ever since to unpack these concepts further.

We use key screens to communicate the overall, high level concept of an app, outlining key journeys is a design technique that gives us a feel for how users can accomplish a typical task when using the app.

Key screens

The main purpose of the calculator app is to enable calculations for simple day to day tasks; “rituals”; such as splitting the bill at a restaurant or working out your budget for groceries.

There were a lot of questions about the visual design of our concepts so far, so this week we thought we’d try sharing our key journeys in a different style of wireframe. Here is a closer look at the calculator app.

Enter a new calculation

There has been some interesting discussion on the mailing list about how to handle the order of operations (or ‘operation precedence’). The driver for this simple view is to support basic calculations. The order of operations will be handled as it normally is – with multiplication and division first, followed by addition and subtraction, without brackets ( ).

E.g., 1 + 2 x 4, will be read as 2 multiplied by 4, add 1, equals 9.


  • A ‘0’ is displayed on start to indicate no calculation
  • User enters ‘1’, a different colour (e.g., orange) is used to indicate the last input
  • User enters ‘+’ and ‘2’, operators are displayed after a number input
  • User enters ‘equals’ on the calculator numpad, and a dash separator line appears with the calculated answer and a line to indicate this calculation could be pulled up to create a new one.

Start a new calculation

We have also been brainstorming ways to create a new calculation. Our concept was originally inspired by the idea of a receipt tape, which we wanted to follow closely, and an idea that came through the mailing list was that of ‘ripping-off’ a calculation by pulling up; creating a new one (awesome idea, Bruno Girin, thanks!).

  • User pulls up to create a new calculation, geo-location, date and time of the calculation will be added to the top of the calculation automatically (e.g., ‘@Tesco, 06/03/13, 10am)
  • The previous calculation has moved to the top, remaining only as a visual hint.

View a calculation

  • The calculations are seen as a continuous list, user can scroll up and down the list freely
  • As user starts to scroll down to view previous calculations, the calculator numpad transitions out. The numpad transitions back into view when user scrolls up and reaches a threshold of the last calculation
  • An interesting note is that the QWERTY keyboard could appear at any time by tapping to edit labels. (This will be explained in the ‘Adding a label’ journey; keep reading).

Delete a calculation

  • To clear a calculation user swipes side way and a label (e.g, ‘clear’) transitions in
  • If the cleared calculation is at the bottom of the list, a ‘0’ is displayed. If the cleared calculation is followed by another calculation, then that calculation will be displayed.

Add a label

We have included the ability to add titles and labels to the calculations to help us when we’re splitting bills or doing our grocery calculations!


  • As mentioned above, geo-location, date and time of a calculation will be added automatically when a new calculation is created
  • User taps to the left of a calculation to start creating and editing labels!

Numpad layout

Also, there’s been a lot of discussion about the layout of the numpad! Based on our key journeys, here’s what we’re thinking to cover daily use scenarios:

As usual, sign up to the Ubuntu Phone mailing list and the IRC channel to discuss more.

Read more
Mika Meskanen

Last week we introduced key screens for our core utility app designs, and we’ve been sketching key journeys ever since to unpack these concepts further.

Whereas the key screens communicate the overall, high level concept of an app, outlining key journeys is a design technique that gives us a feel for how users can accomplish a typical task when using the app.

For today, here is a closer look at the Calendar concepts key journeys

Change to another month

  • To move to the next or the previous month, simply swipe left or right on the month view.
  • Month names in the header roll in sync with the swipe

Change to another day

  • To move to the next or the previous day, swipe left or right on the agenda view
  • Selected day is popped out in month view, but today’s date remains highlighted in Ubuntu accent colour
  • You can also tap on a day number above, to move to that day

Compress the month view into a week view

  • Scrolling up on diary view, collapses the month view into one row, showing one week only and giving more space to display your events

Change from timeline to diary view

  • You can toggle between ‘gapless’ diary view and hourly view by bringing up the toolbar from the bottom edge and tapping on the Timeline / Diary view option

Create an event

  • The option to create a new event can be found in the toolbar, so just swipe up from the edge and tap on New Event
  • To cancel, just tap on outside the card on the top, or push it back down

  • Create Event card pops up with the keyboard, so you can immediately give title to your new event
  • You can also specify date, time, location etc. and add people to the event (details to be iterated)
  • When done, tap Save, and the card will slot into its place in your diary

View event details

  • To view an event in detail simply tap on it
  • Event details open up in full screen, it should be easy to glance when it is, what it is about, where it’s taking place and whose coming
  • If you want to, for example contact any of the people invited, just tap on the name, and their contact details open in a split view*

  • To go back to your diary, swipe up the toolbar and tap on ‘Back’

Remember we are still in the sketching and wireframing phase, visual design will come later and undoubtedly steer the design further!

What’s next?

We need something real to touch and poke, that we can test and improve – so don’t hold back as this is a great time to start prototyping!

As usual, sign up to the Ubuntu Phone mailing list and the IRC channel to discuss more.

* Picture of “Anna Olsson” used under Creative Commons from Isabel Bloedwater.

Read more
Joshua Hoover

Notification about Notes

Throughout last year, as we invested heavily in our new data sync infrastructure, we gradually had to turn off services that were reliant on the old infrastructure and providing little value to our users. Our Notes service was one of these, so last year we removed Notes from the Ubuntu One web UI.

As part of that ongoing strategy to constantly make sure we are spending our time on the right things, we’ll continue to improve our services during 2013. One of these updates, an upcoming database change, will impact how we currently sync Tomboy Notes. By the end of February 2013 we will cease syncing Tomboy Notes to U1, meaning U1 won’t transfer your notes between computers. Those of you still using U1 to sync your notes will need to stop relying on the service to sync or restore notes after new installations.

We realize syncing notes to Ubuntu One was a nice feature for a small set of people, even so, we are contacting the Tomboy developers to help them support our new APIs which utilizes our new U1DB data sync service.

We are sorry for any inconvenience this causes and if you have any questions please contact us.

Update – February 5, 2013
The timing of our post and the deployment of some changes on the server side (unrelated to notes) yesterday couldn’t have been worse. Due to some unforeseen aftereffects of the deployment, notes sync was impacted, which meant when people synced their notes after this update the notes were deleted. We apologize for this. The good news is Tomboy does not delete notes but moves them to a backup folder. If your notes were deleted, please follow the steps in this FAQ. If you can’t restore your notes that way, please contact support for help.

Also, there are some alternatives for syncing notes in Tomboy. We’re providing two suggestions below.

1. Tomboy local backup
Backup your notes to a local folder and sync that folder with Ubuntu One. Note, if you are syncing notes between multiple computers, there may be some issues that arise due to conflicts. Here is how to sync notes with Ubuntu One and Tomboy’s local folder sync setup:

  1. Open Tomboy and open the Preferences menu
  2. Click on the “Synchronization” tab
  3. Click the “Clear” button
  4. Select “Local Folder” from the “Service” drop down menu
  5. Select a folder to sync your notes to from the “Folder Path” menu
  6. Click the “Save” button
  7. Open the Ubuntu One Control Panel and click the “Add a folder from this computer” button under the “Folders” tab and select the folder you chose in step 5

2. Rainy
Timo Dörr created Rainy, a note synchronisation/cloud server for Tomboy that can be used like Ubuntu One’s notes sync service. Rainy is a more advanced option and requires access to a server. If you’re interested, get started here.

Read more
Design Team

Ubuntu: Designing for a good purpose

Ubuntu is the world’s most popular open-source PC operating system. It is used by more than 20 million people in over 240 countries  – and it has been translated into more than 80 languages. From schools in Andalusia to the French police force and rural communities in India, everyone who uses it loves it.

The main goals of the Ubuntu design team are to make Ubuntu appealing, usable and accessible on PCs, mobile devices and, both through these devices and through our web and cloud solutions, to make technology available for everybody.

<h2>Access to technology is a human right</h2>

On September 22, 2012, respected British newspaper The Guardian warned that, due to bank closures, many people in the UK will soon struggle to access basic financial services. Altogether, around 1,200 communities are likely to be affected by the coming closures, with many more expected to follow in the next five years. As their populations grow older, travelling to the next town will become impractical for many of these people. Instead, they will have  to go online.

Communication technologies play crucial roles elsewhere, too. In 2010, the Arab Spring led to revolutions in several North African countries, the protests spreading fast, as ordinary people were mobilised through social networks. And mobile phones play an important role in rural Africa, providing basic services like healthcare information and weather forecasts.

We believe access to technology is not just a luxury. It is, as these examples demonstrate, essential for satisfying basic human needs today. That’s why we consider it a human right.

<h2>Designing amazing experiences</h2>

Working in or with the Ubuntu design team means creating engaging and impactful products. We design experiences for mobile devices, desktop PCs, laptops and TVs, alongside web and cloud-based services. Fundamentally, we believe that these technologies do not need to expensive to be useful, usable, beautiful and accessible.

Designing for Ubuntu involves  many things. But above all, designing for Ubuntu means enabling basic human rights. Designing for Ubuntu is designing for a good purpose.

Read more
Ivo Weevers

The UDS Design Track

One week to go! We’re looking forward to UDS. For me personally it will be my first and I’m thrilled to check out all the interesting sessions and hear your stories about Ubuntu and design. There will also be a very exciting design track in which we hope to work together on many cool topics, such as fonts, Juju GUI, Danish toys, the theater and many more!

For example, we will run some very interesting sessions on Ubuntu font guidelines and error states. We will organize real user-testing with the brand new Juju GUI. According to tradition, we will again organize the design theater. And we also invited two external speakers – one from LEGO and one from a design company – to talk about their experience with co-creation and their work with communities.

We’ll send out a more detailed schedule later this week.

Hope to see you at the Bella Center in Copenhagen next week!

On behalf of the design team,


Read more
Amritpal Singh Bhachu

Academia vs Industry

I have now worked at Canonical, ‘The company behind Ubuntu,’ for almost 4 months. The time has flown by, and I am finally getting up to speed with the working environment, the people and the atmosphere.

So what differences have I noticed between the academic setting and the industrial setting?

My biggest fear of moving into a commercial environment was losing the ‘freedom’ of academia, having to sit in a shirt and trousers all day and work in a 2 by 2, high walled cubicle, doing work that is given to you rather than work that you choose and drive in a direction that excites you.

I’m glad to say that I had nothing to worry about!

At Canonical, there is no requirement for a shirt and trousers (not to say people don’t wear them). There is desk space aplenty, and the teams all sit close enough together to have a conversation, whether that be about work, or just general banter. There is a nice overall tone to the whole working environment. ‘Shit gets done,’ but not at the expense of enjoyment in the environment. That brings me onto the actual work…

Canonical Office in London (you can see my desk!)

The main reason I wanted to step away from academia was that the pace was getting a bit too slow for me. Countless times I have been told over the last five years, academia is about adding your small grain of knowledge to the bigger picture of your chosen field. This frustrated me.

Even though some of the projects I worked on while in academia were extremely rewarding and really made a difference in people’s lives within a short period of time, it can be considered rare for this to happen in academia. Back to life at Canonical, it is really cool and rewarding to see something that you have spent hours working on go live on the website. It gives you that sense of achievement. The pace of work is also much quicker, and I find myself working on several projects and speaking to different people, while at the same time always learning. One of the most interesting aspects of the work is finding a balance between giving the user the best possible experience of using the Ubuntu website and meeting the business and marketing goals of the company.

An example of this are forms. At all costs, from a user’s point of view, you want to avoid forms and especially forms with hundreds of fields in them! But over the last few months, I’ve been able to understand better why the company needs these forms, and I’ve been able to balance out where forms are and how they are implemented.

An example of (part) of one of the forms I’ve been working on

I also thought that leaving academia would see the end of my visits to conferences. This was one of the more enjoyable aspects of academia, a place to go and see what other people are working on, networking and being impressed (as well as hopefully impressing others). To my joy, conferences in industry are just as common. The content however is completely different to what I’ve been used.

During talks at academic conferences, the focus is on results and statistics. In industry, the focus is on experiences, what worked and what didn’t. There are pros and cons to both approaches. I feel that at academic conferences, the quantitative data can sometimes obscure what is actually found by studies, where a user’s thoughts and feelings aren’t taken into account. There is no doubt that the measures are mostly accurate, but just because a button is quickly clicked by each participant with no errors, does it matter that the participants don’t like where the button positioned on the screen? The statistics will usually win over. However, this is an approach that industrial conference speakers could learn a bit more from. The thoughts and feelings of a speaker are all very well, and as they regale stories of their work (or a lot of the time completely unrelated to their work), then I have found myself asking ‘so what?’ If I ever do a talk at an industrial conference, I hope I can find the middle ground between these two approaches, where statistics aren’t the be all and end all, but that I can couple these with qualitative information that I have learnt. Don’t get me wrong, I have read papers and seen presentations, both academically and in industry, that do a great job of doing this already. I hope that I will be able to follow in these footsteps.

The main stage at Reasons to be Creative in Brighton

So, that’s my story 4 months in. I’ve learnt a lot in those 4 months, and it will be interesting to write back in 4 months more to let you know what else I have learnt… and I’m sure there will be loads!

Read more
Calum Pringle

Calum and Mika’s cakes.

We are blogging a lot of cakes, so to economise on space, I’ve paired Mika and I’s latest baking attempts.

photo 3-7 photo 1-8 photo 2-8

Last week was my turn to bake a cake. I was nervous. There’s a lot of pressure, and it is no easy task! So I chose to bake a loaf (but relying on one design seemed to be too much of a case of “putting all your eggs in one basket” so I went for two). A blueberry and apple loaf, and a pistachio loaf (recipes from Hummingbird Bakery).

This week was Mika’s turn, and he didn’t disappoint. A beautiful New York cheesecake (and he had to buy cake baking equipment especially). Go team!

Read more
Mika Meskanen

The release schedule of Ubuntu is tied to a 6 month cycle, also called cadence. Similarly, a lot of our work and planning falls onto our diaries like country festivals on farmer’s calendar.

Ubuntu Developer Summits are obviously the main events. However, if you work on Canonical Design Team, there are plenty of other events to attend to as well.

Last week we were in the Isle of Man having a work sprint with the Product Strategy group. Obviously we took an advantage of the setting and embarked on some off-piste activities in our free time. Here’s a little gallery:

IMG_0518 IMG_5120 IMG_0611 IMG_1665 IMG_5083 IMG_0012

Similar, if not better scenes have also taken place in Florida, California, South Africa…

Read more