In late 2008, I sketched initial designs for what became Gnome’s System Settings utility. This centralized most operating system settings in a single window, without the need to reopen menus or switch between multiple windows if you didn’t find the setting you were looking for the first time. It made Ubuntu, and other Gnome-based systems, much easier to configure.

Five years later, we’re building a phone operating system. So once again, we need a centralized system settings interface.

What other phone OSes do

The first step in designing this was a competitor evaluation of how other phone systems present system settings.

iOS 6.1.4.

iOS is highly consistent in using a hierarchy of list items for Settings. But their design is rather awkward in three ways. First, the top-level Settings screen is very long, usually containing 30 or more top-level categories. Second, Apple originally tried to include application-specific settings inside the system-wide Settings, which made them hard to find while using the app. Some apps (including nearly all the default ones) still do that, but nowadays most put settings in their own UI. And third, the top-level “General” settings category is a bit of a junk drawer — containing subcategories for everything from auto-lock to accessibility, software updates to Siri.

Android 4.2: Tapping “Set mobile data limit” checks the checkbox. Tapping “Mobile data” flashes the switch label, but does nothing else. Tapping “?” opens a menu of more settings.

Android’s Settings similarly uses a hierarchy of lists, though some sections use dialogs instead. It has other consistency problems, too. Sometimes checkboxes are on the left, sometimes on the right. Tapping a checkbox label toggles the checkbox, but tapping a switch label doesn’t toggle the switch — sometimes it navigates to a different screen, other times it does nothing at all. Sometimes a screen’s heading contains a Back button, sometimes it doesn’t. Sometimes it contains a “?” dropdown menu of more settings, and sometimes it doesn’t. All this shows the importance of system settings having, if not a single designer, at least strong design guidelines.

An impressive aspect of Android’s Settings is that they can display in either portrait or landscape mode.

Windows Phone 8.

The Windows Phone design emphasizes typography and visual simplicity. It’s a bit rough around the edges: for example, the “photos+camera” settings screen uses ten font variations, and the main heading doesn’t fit on the screen. Windows Phone also groups “system” and “applications” settings on separate screens, but the separation needs work: for example, the voicemail sound effect is set in one of the “system” screens, while the voicemail number is set in one of the “applications” screens.

A nice detail in Windows Phone’s Settings is the use of summary values. The row you would tap, to navigate to a settings screen, often contains a line of small text summarizing the current settings values. This can save you from having to visit the other screen at all.

Learning from others

This competitor evaluation revealed three main issues. First, the difficulty of organizing system settings versus application settings. Apple tried to group them all together in iOS, but that lacks in-app discoverability. Microsoft used “system” and “applications” categories in Windows Phone, but suffers from poor sorting. It seems more likely that we can solve the sorting problem than the discoverability problem. So, as with Ubuntu for PC, Ubuntu Phone will have “System Settings”, not just “Settings”. Applications will be responsible for presenting their own settings.

Second, there is a tension between categorizing settings, and promoting frequent or urgently used settings. Categorizing by itself is tricky enough: different people might look for the same setting in different places. (For example, iOS sometimes mirrors subcategories of settings inside multiple categories.) A search function may help, but is not a complete answer, because people still need to know what settings are available in the first place. Categorization becomes even trickier when trying to provide quick access to settings like flight mode or orientation lock. Indicators at the top of the screen may help with this, by providing quick access to frequently used functions, like they do on Ubuntu for PC.

Third, it can be useful to reveal current state of settings as part of the navigation to those settings. This is usually done in text, with summary values, but an icon could work too. For example, a Bluetooth settings icon might be dull when Bluetooth is off, bright when it is on, and have an emblem when it is paired to any device.

User journeys

Two user journeys influenced the design of the System Settings interface.

The primary journey is someone wanting to solve a problem. Maybe their Internet connection is not working. Maybe they’re wondering if they can save battery. Maybe a cabin attendant has asked them to put the phone into flight mode. Maybe a friend has been messing around with their phone and they want to stop it from happening again. This person usually will be in a hurry, and sometimes irritated. They’ll want to get in and out as quickly as possible.

The secondary journey is an adventurous new owner, starting out with their phone, wanting to explore what it is capable of. They have more time to read explanations, and to explore cross-references between categories.

Designing the overview

Next, I sketched out nine possible layouts for the overview screen — the first thing people would see when they entered System Settings.

Selecting the most promising elements from each of the nine layouts, I passed them on to one of our visual designers, Rosie Zhu. She produced mockups of three possibilities, and with help from Marcus Haslam we decided on one final layout.

The design promotes frequently- and urgently-needed settings at the top, categorizes other settings compactly, and places bureaucratic stuff (“About This Phone” and “Reset Phone”) right at the bottom.

This is far from a final mockup. We need to finalize the icon style, and fine-tune control sizes, use of color, use of lines, and so on. But the basic layout is in place for engineers to start work. (Contact Sebastien Bacher if you’d like to help out with the code.)

Designing individual screens

Meanwhile, I have been busy designing individual settings screens. This has helped reveal missing controls in the UI toolkit, so they can be implemented for app developers to use them too.

Links to designs for the individual screens, as well as the design for the overview screen, are on the System Settings wiki page. Your feedback on any of the designs is welcome, either here, or on the ubuntu-phone@ mailing list.

I’d like to give an update on upcoming plans for Ubuntu.com and to respond to recent concerns about the positioning of the community within the website.

Earlier in the year we worked on an evolution of Ubuntu.com to reflect the expanded scope of the project in the main site structure. Our re-structuring conversations went beyond the existing website to cover the broader Ubuntu web ecosystem. We wanted to review how users gained access to key websites that were not linked to directly from Ubuntu.com. For example: developer.ubuntu.com, design.ubuntu.com, askubuntu.com…

Our target users for these journeys were mainly community members or those new to Ubuntu who might be interested in getting involved or finding out more about how the community and Canonical work together to create Ubuntu.

Our proposed solution consisted of a global navigation menu that was to go across all key sites so that – no matter which site users arrived at – they would be able to reach the main destinations in our ecosystem. This was to include a new community site that has been under discussion for some time by Canonical employees and members of the community. One key factor for this community site is the ability for community members to have direct input so that the site reflects current community topics and areas of focus. By adding it to the global navigation we hoped to increase traffic and make it more accessible across the Ubuntu web ecosystem.

We created some prototypes to test our proposals in terms of interaction, design, site positioning, labeling etc. Laura Czajkowski helped us reach UK-based community members who came into the office to meet with an independent researcher to test the prototypes. Based on the feedback, we have made amendments and planned to implement the work in two phases:

Phase one of the restructure consisted of updating Ubuntu.com to reflect the expanded scope of the project.

Phase two is in progress and consists of adding the global navigation to all the key sites and making sure they work together across domains etc.

I’m sure you can understand that there is a large amount of coordination that needs to go into a restructure of this scale, across a number of sites, on different domains, that are managed and maintained by different teams across Canonical and beyond.

The limited scope of phase one meant the community link was temporarily dropped from the primary navigation menu. We appreciate why this might cause concern in the community, specially in the absence of an understanding of the broader context of our global navigation project. The global navigation project will restore the balance and provide access to various key community sites that need to be surfaced and will benefit from the increased traffic this new positioning will drive.

All of this work is in progress and we are aiming to go live with the changes by the end of this month.

I hope this will address some of the concerns in the community about this topic and that our roadmap shows how we will improve Ubuntu.com for all our audiences.

Thank you for all your positive feedback after our first blog post.
We are very excited and are continuing with the designs,
here’s a quick update on how we’re getting on.

During the last few weeks we have been looking at the development of the weather and clock apps. We are also looking at set of gradients that could specify a range of weather conditions.

Here’s the how

A linear colour gradient is specified by two points, and a colour at each point. The colours along the line through those points are calculated using linear interpolation, then extended perpendicular to that line.

* wikipedia.org

 
This is great way to describe temperature and how it changes over 24 hours.

The second part of developing these apps was to create a set of graphic assets that could support the weather icons as well as the clock face.

Using entirely white mono assets was obvious to contrast with the colourful changing backgrounds.

But we quickly realized that the graphic style of our icons used as indicators or toolbar actions did not fit well for those assets. The weather icons, for example, looked a bit too heavy while we wanted something more zen and simple to blend nicely with the minimalistic and elegant design of the apps.

We replaced the solid fills with thin outlines and add some roundness to the end of the strokes. The weather icons have become playful but graceful, while keeping their plain but not to simplistic in the look and feel.

The clock faces are designed following to the same principles. With great results?

You be the judge ;)

We have just published a new chapter on our App Design Guides : how to handle orientation.

To cater for the different orientations of a range of touch devices, we need to design apps for Ubuntu in a responsive way.

Phone orientations

1. The primary orientation for an app on the phone is portrait.
2. Consider using landscape orientation when we want to have a full screen experience for a single piece of content, such as watching a video, looking at a photo or gaming.
3. A phone app automatically fits in the tablet’s side stage, with a flexible height.

Tablet orientations

1. The primary orientation for an app on the tablet is landscape.
2. Consider portrait orientation when it will help the user engage with your app; for example reading a magazine or writing a long email.
3. By supporting portrait, your app automatically supports split screen.

Responsive strategies

Use these strategies to make your app work on screens of both different sizes and orientations.

Position graphic elements relatively

For ease of use we space graphical elements relatively; to both one another and the screen edges.

Decide how your app might show more or less content

• An app on the tablet’s main stage might show more content than on the phone.

• An app on the phone with a list of content, such as a feed, would show much more content in the side stage as it is taller.

• If your app’s content is larger than what fits in view, for example a map, you might consider showing more or less content depending on shape and orientation.

• If your app’s content is fixed in shape then it can simply scale up or down. For example the same amount of content on the phone would be scaled up on the tablet.

A few last things

1. Use extra space constructively
Consider what content your app could show in extra space, be it the history of a calculator, a list of missed calls or even high scores!
2. If your phone app does not scale, it will remain a fixed height in the side stage.

Hope this helps – and as ever please let us know what you think, these guidelines are a work in progress and will grow over time. Feel free to get in touch with us on the Ubuntu Phone mailing list and the IRC channel.

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 by @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)

 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.

Yesterday we’ve launched an updated version of ubuntu.com, which we hope will improve navigation throughout the site and provide visitors with a better understanding of what Ubuntu is.

Research is an important part of what we do, and this update isn’t an exception. The improvements we have made in terms of content and structure of the site are mostly a reflection of what users have told us during testing, such as clarifying the description of what Ubuntu is when you are browsing the Desktop section.

Refocused navigation

By focusing our site navigation on the products themselves, we aim to make it clear for someone who is new to the site that Ubuntu is about all of these things: PCs, phones, tablets — you name it.

New ubuntu.com’s product-based navigation

Updated footer

We have introduced a contextual footer at the bottom of most pages. This gives people an opportunity to explore more of the section they’re in and read related resources like news and articles. We have also made the main footer work harder by providing a bird’s eye view of the entire content of the site.

An overview of ubuntu.com in the updated footer

But the changes are not just about the site’s structure. Visually, ubuntu.com has been evolving ever since it was first launched, and with the latest update, we keep moving towards a cleaner, fresher, but also more modular, approach.

This direction started with the design of the phone and then the tablet sections of the site, which took existing design components and “opened” them up — we’ve added larger margins, lighter text, more space all around.

We then revisited the other sections of the site and standardised the templates and remaining components as much as we could. This exercise took a great deal of close collaboration between design and front-end development: it was important that design decisions were agreed by everyone and that the code reflected those decisions.

The product of this code cleanup had already been made live a few weeks ago, but the more visible side of the cleanup happened right now, with this update.

What we’ll do next

We will be working on, and improving, the way you navigate through ubuntu.com and other websites in the Ubuntu web universe in the coming months, so keep an eye on this blog! And, as always, we’d be delighted to hear your feedback.

Hi everyone, following our process post last week I’m excited to share the first round of visual exploration for three of our core utility apps; clock, weather and calendar (calculator and an updated notepad soon too I promise!).

It is important to note that this is still an early stage in the design process.

Our aim was to extend the look and feel we have already established in the phone demo to the family of apps. The style we call Suru.

What we’ve concentrated on (while the functionality is being prototyped from our wireframes) is how to develop the look and feel of the apps. The accuracy of the information on the screens is yet to be developed. We’ll work on the layout of the information once we’ve started to focus on a single app.

These last few weeks we have looked at developing a mood board and colour scheme for the utility apps. For example, we’ve used a combination of gradients and photo-manipulation to showcase different temperatures from locations in the weather app. We have started now to think how this gradient could influence the look of the other apps; maintaining individual styles but feeling still within a family of apps defined “rituals”  metaphor.

Following our design vision, we aim to focus on the essential information in each view, with a minimal, sophisticated feel. You’ll notice from these images that we’ve tried to be as clean as possible.

In the next couple of weeks we are going to concentrate on refining each concept. Even though we have a direction for layering, materials and textures they all still need a bit of love. Enjoy ;)

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:

• Calendar
• Calculator
• Clock
• Weather

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!

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.

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.

The community team for wallpaper selection got together last week #1304wallpaper on Freenode and between us we’ve determined that we’d like to submit the following images as our delightful wallpaper selection for 13.04.

Many thanks to everyone who came to discuss options and help with the selection and in particular those who highlighted that some of the images shortlisted previously might not be the submitted user’s own image and or appear in other distros. Your constant vigilance is much appreciated!

So what now? Well the compressed file has been uploaded to a bug marked against the wallpapers package on Launchpad and this is where Seb, Didrocks and others will ensure that the images make it into the release before UI freeze.

Thank you again to everyone who helped and to Ken, Seb, John and Didrocks for the final push.

I’m still signed into #1304wallpaper most of the day, UK time so come find me or drop me a mail if you have any questions, concerns or the like.

See you next cycle/ rolling release!

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.

Flat

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.

Contextual

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.

Deep

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.

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.

We’ve been making great progress from both design and development on our four core utilities for Ubuntu on phones so, while we are iterating these concepts, we thought this was a good time to share more of the inspiration behind the apps designs. This helps us keep our goals in sight, not only on the design side but throughout development.

A day in the life

It’s morning. An alarm sounds. I turn over. I look at the clock. It’s going to be a busy day. I get out of bed.

I shower. I finish showering. I wonder what I should wear. I wonder what I will I do at the weekend. I check the weather.

It’s lunch time. We go to a restaurant. We pay. We work out the bill.

It’s evening. I check my todo list. I check my calendar. I’ve got a date. I send a message.

It’s night. I check the weather. I check my calendar. I check the time.

(Photo credits: heredfordcat, roberstinnett, Jacob Bijani and  Phoenix Dark-Knight)

Sound familiar?

Without something to support these daily routines we think we’d be lost entirely, and we don’t think we’re alone in that!

The opportunity

The opportunity with the Clock, Weather, Calculator and Calendar apps on the Ubuntu phone is to create a consistent experience which impacts the daily lives of our users. A suite of apps that are used as part of a daily ritual; sophisticated, consistent and content focussed.

Let’s call them Ubuntu’s rituals

An alarm sounds. I turn over. I look at the clock.

The Clock app

• The same clock face for every feature; adjust with easy gestures.
• Something to delight; it’s the first thing you see in the morning and the last thing you see at night.

I wonder what I should wear.

The Weather app

• Check the weather today and yesterday, tomorrow and the weekend.
• Make it contextual; do I need my umbrella? (terribly British example!)

We work out the bill.

The Calculator app

• Tear off the strip of calculations and jot down your notes.
• It’s all about the task; this app helps you work out your budgets and bills, not the definition of Pi!

I check my todo list. I check my calendar.

The Calendar app

• Organise your life your way by month, week or daily diary.
• Again, it’s about the task and the context; use the calendar app as a todo list, a diary, a planner, a journal, a life log; and the calendar will behave how you need it to.

What does this mean?

When we design and build an app, we always have a key story in mind. Whenever we think “oh it’d be really cool if…” we remind ourselves of this story; therefore it helps us to produce an app that is simple, streamlined and delightful to use.

“Ubuntu rituals” inspired the concept of these four apps and we will use this to guide us through further iterations of both design and development.

So where can I see this?

Follow our development progress on Google+ as well as the usual places; the Ubuntu Phone mailing list and IRC channel.

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.

In my last post, I spoke about my transition from academia to industry. One thing that I felt I would miss were the opportunities to speak to students, and watch their progression throughout the year. So when I was asked to go back to the University to give a talk, I jumped at the chance.

So I prepared what I was going to talk about and set off to the School of Computing at the University of Dundee to meet these talented students. My first job was to help assess their group pressure projects which they had been tasked with the week before. The theme was educational games. Over the next 2 hours, I sat and was amazed by what the groups had produced in such a short period of time.

The Winning Group with their Ubuntu prizes

Several things frustrated me however.

Each group had 3 minutes to present their game and explain what they did. But they all focussed on showing gameplay and illustrated some of the code that they used. A number of groups stood up and highlighted that they felt their game wasn’t very good because they didn’t have strong coders in their team. When I asked them questions about the processes that they had been through before coding, they all showed evidence of brainstorming, wireframing and design. My biggest issue however was that most of the groups started coding before they considered who the user would be, and therefore, they considered a user to meet the code, rather than producing the code for a specific user.

So this lead me to change what I wanted to talk to them about, and I did an interactive session with the 80 odd students to develop a user profile for the remit they had been given. We looked at who the user group was, what were the characteristics of this user, where would they want to play the game, why they would want to play the game and how they would play the game. We brainstormed on a whiteboard and agreed on which attributes to keep, and which to remove. This was all done in half and hour. The students really took on board the importance of considering the user, and how quickly it could be done for the projects that they would be presented with going forward in their education.

It was the most enjoyable lecture that I had ever taken, and I look forward to doing it again soon.

On another note, later that evening I made my triumphant return to the land of stand up comedy. I was invited back to do Bright Club Dundee having performed last year. It was great fun to do, even though I don’t think I’ll be looking at a change in career anytime soon! Below is a photo of the performers….you can quite clearly see the fear in our eyes!

Bright Club Dundee Performers

If you want to see my set (which contains strong language and little humour) then follow this link.

It’s been a long time coming, but we’ve finally done it: the Design Blog has a new look!

Let me take you through the main aspects we wanted to improve on.

Why change?

The last blog design was nearly four years old. With its small font sizes and crammed pages, the text was difficult to read and the images didn’t have space to breathe.

In updating it, we wanted it to appear lighter and cleaner. We wanted to move the visual design forward and let the living and breathing parts of the site — the articles and images themselves — take centre stage.

The new Team page

A focus on content and flexibility

One of the main objectives of this new design was to make the reading experience more pleasurable, losing unnecessary details that were crowding the page, so our readers can focus on the content.

We needed a design that could accommodate not just the content we have now, but also the kind of content we expect to see in the future. So we’ve introduced a grid that’s flexible as well as strong. It makes the article pages look more balanced and harmonious, making it easier for the reader to focus on the text and the images.

Speaking of images, we also wanted to make it easier for authors (and encourage them) to include large images in their articles, if available, to really show off the work.

It all comes down to flexibility: an article page should look great when it has no images at all, but the grid and the design should be flexible enough that, when images exist, they are allowed to shine.

The Ubuntu font

Our font is beautiful, but we weren’t using it to its full potential before. One of the goals of this design is to show off the Ubuntu font, its different weights and how great it works at different sizes.

This an example of a block quote, showing the flexibility of the Ubuntu font.

We increased the baseline font size and started applying a new typographic scale (based on a modular scale) which we will introduce to the main websites soon.

Small screens

Although we have taken steps to improve the way content displays on small screens, there are still a few more things we can do to improve the browsing experience on mobile devices.

Because the new design is so clean, it reads well on smaller screens, especially the article pages, which are the most important part of the blog. Other elements, like the footer and navigation, have been tweaked slightly for easier access on smaller screens.

What’s next

As with most projects, we’re not done yet. There are a few things that we’d like to improve further — like the small-screen experience — and some more functionality we’d like to add, but we believe this is a good first step.

As you can see now, the URL for this blog remains associated with Canonical. Another important point we need to address is the relationship between this blog and the Ubuntu Brand Guidelines site, as they are in fact just two aspects of the overarching Ubuntu design concept.

Now let’s hear your thoughts! What do you think of this updated design? And what would you like to see us writing about in the future — what would make interesting articles for you?

Today the group closed on submissions for the 12.10 wallpaper selection. The team of us involved are still working to add/ remove and refine this collection before the 30th. We’ve got a few more than our 10 target, we’ll review this number tomorrow based on quality and what we can include.

Join us on #1210wallpaper on freenode to chat through this selection with us!

To everyone who has given up their evening to go through this, thanks!

Speak to you all tomorrow