Canonical Voices

Lina Pio

Over the past few weeks we’ve been exploring visual directions for the calendar app. It’s a pretty exciting opportunity to create something fresh and at the same time useful. In this post I’ll take you through some of the directions we’re looking at right now and where we hope to eventually go. At this stage the designs are still under consideration.

Year view

This view offers a lot of challenges particularly given the large amount of information that can be compacted into such a small space. The challenge was to provide something that could inform the user quickly and usefully without overloading the screen with information. Each month is clickable. Individual dates, however, will need to be selected from the month view.

01_year copy

Month view

As with year view, it’s a tough call to keep the month view looking and feeling smooth and simple. Because of this, we decided to use the month view to provide the user with an overview of the dates in that month, from which they could select a date only. Instead of filling in the events inside the month view, the user can see the events at a glance inside the week view. We explored two different ways of laying out the month view visually.
02_month copy    02_month2 copy

Week view

In this view we experimented with the visual layout in terms of how much screen space the chrome took up and how you could visually represent different calendar events using coloured blocks vs coloured dots.

03_week1 copy 04_week2 copy 04_week3 copy 04_week4 copy 04_week5 copy

 

 

Day view

With day view, as with Week view, we tried looking at reducing the chrome around the day box to give more space to what the user most needs to see – the events during that day.

05_day1 copy 06_day2 copy

Event

Event view tends to be a different interface type than the others. Where with the other views a user’s prime activity is to navigate through information, the event is the goal in itself, providing a list of information. Because of this, a white background may be a better solution to presenting large amounts of text, making it easier on the eye. One thing that is still in design at the moment is the ability to select the date and time when creating a new event.

07_new_event1 copy 08_new_event2 copy 09_new_event3 copy 10_event_detail copy 10_event_detail2

We hope you enjoyed going through our visuals and thought process. Watch this space next time for more visuals on date and time picker to go along with event view.

 

Video

Here’s a video to show how the interactions and transitions will eventually function.

Read more
Chee Wong

Right… so where should we start? First post.

Hello, my name is Chee, and I am an industrial designer.

In this post I will share some materials, stories and process during the development of the Ubuntu Edge.

 

D001

We started off by pulling the key elements of the Suru theme, and expanded on that, in order to explore the transition from a digital user experience, to a physical one.

 

0002

0005

0003

Once the rough ideas were formed, the fun part started, as we dived right into visualising the concepts; Pencils, sketching pads, markers, clippings, samples, colour chips and anything else interesting.

 

D003One of the best way to visualise, experiment and refine a design is to materialise it in any way possible. In the process of creating and fine tuning the Ubuntu Edge, we turned to methods known to be the most effective: Model making, 3D CAD, and 3D printing. In our case, we tried it all!

 

0009

0006

D004It’s equally important how the Ubuntu Edge feels in the hand, how it visually presents itself and how certain textures give visual cues to the perceived expression. How each material works alongside each other without creating visual complexity is one of the key role to either make or break a design.

After several rounds of refinement and fine-tuning, we pressed forward with what we have now today as the Ubuntu Edge. From a rendering to visualize the Ubuntu Edge, to one that sit in front of us.

 

I hope you enjoy reading through the process, and lets make it a reality.

The Ubuntu Edge

D005

Read more
Michal Izydorczyk

Shorts visual exploration

Hey

After all the work we have done on the Rituals app designs it was time to start exploring other core apps.

I thought it would be good to share with you our recent exploration of the RSS Reader App.

Please note that those are only the key screens and settings are not covered yet. But this should give you something to get started ;)

Here is the link to the spec with all the font sizes, spacing, and colour values for the gradient backgrounds…

Let me know what you think ;) and I will try to update you on some visuals for the music app next.

This is the home screen of the RSS Reader.

Read more
Iain Farrell

Hello everyone! I’m delighted to be kicking off the next wallpaper selection process for the 13.10 release of Ubuntu coming this October. As you can see from the Saucy Salamander release schedule, we hit UI freeze on August 29th of this year and we’d like to get all your lovely community submitted images ready before then. To get involved submit your images to the Flickr group for submissions.

I’ve also made the above short video to encourage new people to get involved, share it around as hopefully it’s a good intro to the process and if you have ideas or comments then let me know, I can make additional ones as we go.

With some help from designers in Canonical we’ve come up with the following tips for creating wallpapers images.

  1. Images shouldn’t be busy and filled with too many shapes and colours, a similar tone throughout is a good rule of thumb.
  2. A single point of focus, a single area that draws the eye into the image, can also help you avoid something too cluttered.
  3. The left and top edges are home to Ubuntu’s Launcher and Panel so be careful to consider how your images look in place so as not to clash with the interface.
  4. Try your image at different aspect ratios to make sure something important isn’t cropped out on smaller/ larger screens at different resolutions.
  5. Take a look at the wallpapers guidance on the Ubuntu Wiki regarding the size of images. Our minimum resolution is 2560 x 1600.

To shortlist from this collection we’ll be going to the contributors whose images were selected last time around to act as our selection judges. In doing this we’ll hold a series of public IRC meetings on Freenode in #1310wallpaper to discuss the selection. In those sessions we’ll get the selection team to try out the images on their own Ubuntu machines to see what they look like on a range of displays and resolutions.

Anyone is welcome to come to these sessions but please keep in mind that an outcome is needed from the time that people are volunteering and there’s usually a lot of images to get through so we’d appreciate it if there isn’t too much additional debate.

So, to get this show on the road here’s the outline for this cycle.

  • 12/07/13 – Kick off 13.10 wallpaper submission process
  • 23/07/13 – First get together on #1310wallpaper at 19:30 GMT
  • 16/08/13 – Submissions deadline at 18:00 GMT – Flickr group will be locked and the selection process will begin
  • 23/08/13 – Deliver final selection in zip format to Launchpad
  • 29/08/13 – UI freeze for latest version of Ubuntu with our fantastic images in!

As always, ping me if you have any questions, I’ll be lurking in #1310wallpaper on freenode or leave a question in the Flickr group for wider discussion, that’s probably the fastest way to get an answer to a question.

I’ll be posting updates on our schedule here from time to time but the Flickr group will serve as our hub.

Happy snapping and scribbling and on behalf of the community, thanks for contributing to Ubuntu! :)


Read more
Katie Taylor

Edges are special to us. We use them for finding apps, tools and system services, so using the edges will be second nature to Ubuntu phone users. By using the launcher, how to launch your favourite app will become ingrained in your muscle memory of the left edge.

The design vision behind Ubuntu for phones includes the use of fast and natural interactions, so taking that to the welcome screen means that if your phone is locked, you can still access the launcher, system services and the right edge. If you have a pin set up, you only need to enter your pin when accessing private data, in the Gallery app or the Dash for example.

 

 

If you’ve flashed your phone recently, you will be able to activate the lock screen for the phone using a temporary hack (love it!). You’ll notice that the blur has not yet been implemented, but will be added later. Thanks to Michael Zanetti for originally posting instructions to the Ubuntu Phone mailing list. Here they are:

To enable the pin lock, log into the phone and create a file /home/phablet/.unity8-greeter-demo, with the content: password=pin

If you want to see the password unlock screen instead, put this into the file:  password=keyboard
For now, the pin is hardcoded to “1234″ and the password is “password”. Note that this functionality can (and will) disappear at any time as we bring all the bits and pieces together. This is a temporary, simple way to enable the visual part of the lock screen for us all to have a play with.

Let us know what you think on the Ubuntu Phone mailing list and the IRC channel.

Read more
Lisette Slegers

In my previous blog post, we looked at the key screens for Shorts, the organic grid and the reading view. You can read about the list view behaviour in this document. In this post, I would like to look at journeys for adding and editing content, sharing an article and adjusting the reading view.

Sharing and adjusting the reading view

From the reading view, pull up the toolbar to reveal options:

Reveal reading options

Options for adjusting the reading view are:

  • Font size
  • Light / dark theme

Article view options

Any changes made to the reading view are persistent until the view is changed again.

Adding things to read 

There are different options for adding content to the Shorts app. All of the options described here are for when the user already has feed subscriptions in the app; the first use scenario is not yet covered. To get to the different options for adding content, pull up the toolbar from the topic view:

Adding content

1. Adding a topic

Adding a topic

Adding a new topic with feed suggestions makes finding things to read much easier for users who don’t understand RSS. However, suggesting feeds for subjects could easily become quite complex; for example feeds related to ‘News’ are location specific. Whether we can suggest feeds for users will depend on if we can automate this process.

2. Adding feeds

Add feeds 1

Add feeds 2

When adding one or more feeds, the user needs to select a topic to organise it under. Selecting the topic is done with the expanded option selector.

3. Add online accounts

This might not be possible for version 1, but being able to read articles that were posted on your social networks would be a great feature to have in Shorts. Connecting to social networks will be done through Ubuntu Online Accounts.

4. Import subscriptions

Exact functionality for importing and exporting subscriptions will depend on the how the file manager works.

5. Other

Depending on browser functionality, it might be possible to add feeds from the browser.

Edit topics

In Shorts, feeds are organised under topics. Occasionally, users might want to change the names of their topics and the organisation of their feeds. Under ‘edit topics’, users can:

1. Change topic names

Edit topic names

2. Change topic organisation by adding a new one

Edit topics: add a new one

3. Moving feeds into a different topic

Move feeds into a different topic

The above proposal lets users drag feeds from one topic and drop it into another. The list of feeds under a topic could be very long, so there is an option to collapse the topic. Whether this is possible depends on the drag and drop pattern available in the SDK. Drag and drop is not the easiest thing to do on a touchscreen. A possible alternative would be to long-press on a feed, go into selection mode and have move topic as one of the options.

4. Deleting feeds or entire topics 

Same as in the messaging menu, we will use the swipe to delete pattern – this will soon be in the app design guides.

Next steps

We aim to make the app powerful but simple by having the more complex options easily accessible where they are needed, and to cater for both advanced and novice users. Do you think this app can work without pages and pages of settings? Looking forward to hear your feedback and ideas. You can follow our progress on Google+, the Ubuntu Phone mailing list and IRC channel. Next thing to do is look at first use and no content scenarios.

Read more
Calum Pringle

It’s been a while since our last update to the app design guides so I thought it was about time I shared the latest additions to this growing resource.

Screen sizes

A brief intro to the framework we use for designing for a scalable OS - the grid unit. With a link directly to a more detailed explanation on developer.ubuntu.com.

Read about designing for multiple screen sizes.

FAQs

We’ve started to collect frequently asked questions. This section could be improved if it was a little more ‘live’ so we’ll have a think about that.

Read our most frequently asked questions.

Combo button

When you are receiving a phone call, it is possible to decline the call (of course), or alternatively you can decline and reply with a message. To accommodate this and similar use cases we have designed the combo button. Use the combo button to display secondary variations of the primary action.

See our new combo button.

Option selector

While designing System Settings we have come across many situations where there is a need to select from a list of mutually exclusive options. Use the option selector when you need to select an option from a list.

See our new option selector building block.

Slider

Our slider has gone through a little makeover too.

Take a look here.

Remember, this site is a work in progress, so we will continue to iterate on the content and design. As usual you can find us on the Ubuntu Phone mailing list and the IRC channel.

Read more
Lina Pio

One of the key challenges with designing calendar applications is the number of ways you can display your time, whether it’s by year, month, week or day. After a lot of good old fashioned hard work, we refactored navigation by making the tab header the key to switching between views. Although the direction I’ll take you through in this article is strong and clean, it’s still a work in progress, and as such, can still change. The images are small in this article, to get a closer look at all of them collected together, download the PDF here.

The latest designs in this article show you how we’ve aimed to solve:

  • Navigation between different calendar views
  • Gestures to help quick navigation
  • Editing events
  • Creating events
  • How this will potentially look and feel

 

Different views

There are 5 different view templates inside the calendar app we are focusing on. They are:

  • Year
  • Month
  • Week
  • Day
  • Event

 


Navigating between different views using title header bar

You can move through the different views by tapping on the title header bar to toggle the view mode options. Just like our patterns, this title is scrollable – so that you can scroll through the view modes which don’t fit the width of the screen. Also like our pattern, swiping to the left or right moves along to the next or previous unit (year/month/week/day/event) in its category. For reference, take a look at Calum’s excellent post on this.

To get a better idea, click here to see a video of the prototype which formed the base of this navigation model and allowed us to test it out, comparing and contrasting it against other design directions. It was enough to give us a feel for the potential final build.

 

Navigating between views using spread and pinch gestures

To aid fast navigation for pro users and to also add an element of fun, we’ve decided to enable zooming in and out between views using finger spreading and pinch gestures similar to zooming in and out in a map app.

 Spreading fingers gesture: This zooms in to the next view; the next view offering more detail, close up.

     E.g. A user spreads when on the year view. This opens up the month view. Spreading on the month view opens up the week view, and so on.

Pinching fingers gesture: This zooms out, to a less detailed view – the previous view in the view hierarchy.

     E.g. A user pinches on month view, the system responds by taking the user to the year view.

 

An event

An event has several detail fields. In order of appearance they are:

  • Event name
  • Time
  • Description
  • Location
  • Guests
  • This happens (how many times does this event happen in the series? Or is it a one time event?)
  • Remind me
  • Timezone

 

Editing an event

A bottom edge swipe on an event page brings up the toolbar with the edit button.

[NOTE: toolbar menu options within the calendar and across the whole system have not been finalised, this image of the toolbar is a placeholder to give an idea of how to edit]

The edit mode shows the boxes around the fields allowing the user to type and change the event details. The toolbar in edit mode is always present. It shows cancel and save options.

 

Creating an event

A bottom edge swipe on year, month, week and day views brings up the toolbar with the option ‘New’ to create a new event. Pressing this brings up a similar template to the ‘Edit’ mode, the only difference being the blank forms.

 

Visuals

The visuals in the image below are an exploration of how this can potentially look and feel. This is still very much still in progress, but gives a strong hint of what’s to come.

 

 

I hope you like our thoughts and directions on this, and that this article gives a stronger idea of what the final app will look and behave like.

Watch this space for my upcoming articles focusing on: an in depth look at events – (including guest contacts, location views, time and date pickers etc) calendar synching with external accounts, calendar settings, and calendar mode inside the indicators.

Read more
Martin Keary

This is a presentation of our ‘Paper’ Motion theme for Ubuntu Mobile.

The theme is informed by the ‘paper’ graphic style of the mobile OS and we have sought to accentuate it wherever possible. Rather than using more overt effects like page curling and folding, we have hinted at the theme by using multiple layers, ‘stacking’ and suggestive effects. Multiple layers of sliding paper can be observed in the animation of the switch button, stacking can be seen occurring on the icons in the launcher and an example of a suggestive page-turning effect can be seen during the ‘App Stacking’ example.

Read more
Lisette Slegers

Research around reading

As you can see in the image above, I have spent some time looking at different types and contexts of reading, trying to understand what the reading experience might be for Ubuntu. The contexts of reading varies from libraries to magazine stands to the sofa in your lounge, and these each have an impact on how and what you read.

Something we all know (from a healthy bit of stalking field research on public transport) is that reading on a phone means you are probably doing something else at the same time. You are waiting for your friends in a restaurant, or on a busy train on your way to work. You open the reader app to quickly check some news.

Meet “Shorts”: leaf through your news while you wait

Paul is in the station, waiting for a train. He has 5 minutes until it arrives.

Shorts wireframe 1He launches Shorts. The app opens up with a view that shows short snippets of articles on the topics that interest him. The items are laid out on the page in the organic grid, similar to the grid that is used for the gallery app.

Shorts wireframe 2

It is going to rain tonight. Paul decides to stay in and cook a meal with his flatmates. All he needs is a recipe. He navigates to one of his topics, Food.

Shorts wireframe 3

Paul selects a recipe and reads through it. He decides it is too elaborate and returns to the topic.

Shorts wireframe 4

He looks further through the topic and taps on another article. This recipe is perfect for tonight! Paul saves it so he can easily find it later.

Check out this video too:

See how this concept also fits with our Design Vision and the other ritual apps?

Next steps

We will be connecting the dots and working on key journeys for Shorts. Follow development progress on Google+, the Ubuntu Phone mailing list and IRC channel.

One last thing

What do you think of the name?

Read more
Matthew Paul Thomas

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.

The main Settings screen of

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.

In the “Data usage” screen of

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.

The “phone+camera” screen of

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.

There was a square grid of icons with headings, like on Ubuntu for PC. A variation where the headings doubled as controls. A triangular grid of the same icons, just for fun. Text lists of subcategories, interspersed with occasional controls as list items. And an amalgam of the grid and list models.

Another text-based list, this time using two lines of text for each subcategory. An arrangement of tiles of different sizes for varying prominence of categories. And finally a list using both icons and text.

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.

Read more
Alejandra Obregon

Ubuntu.com update

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.

Ubuntu global navigation menu

Read more
Michal Izydorczyk

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 ;)

 
 
 

Read more
Calum Pringle

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

orientation_1

  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

orientation_2
orientation_3
orientation_4

  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.

orientation_5

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.
  • orientation_6

  • 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.
  • orientation_7

  • 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.
  • orientation_8

  • 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.
  • orientation_9

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.

Read more
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 ivankamajic.com)

Read more
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 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.

Read more
Inayaili León

Spring cleaning ubuntu.com

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.

Ubuntu.com - New navigation
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.

Ubuntu.com - New footer
An overview of ubuntu.com in the updated footer

Ubuntu.com phone page

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.

Read more
Michal Izydorczyk

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 ;)

 

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