Canonical Voices

Posts tagged with 'design'

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
Mika Meskanen

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

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

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

Clock : what time is it in New York?

 

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

Clock : adding a new city

 

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

Clock Easter egg: sunrise and sunset times

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

Alarm : set an alarm

 

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

Alarm : toggle alarms on and off

 

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

Alarm : create a new alarm

 

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

Timer : set timer manually

 

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

Timer : set timer from a preset

 

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

Stopwatch : simple stopwatch start, stop and reset

 

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

Stopwatch : recording laps

 

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

Stopwatch Easter egg: time zoom


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

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

Read more
Iain Farrell

13.04 wallpaper selection

 

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!

Constant vigilance as Mad Eye Moody would say

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!


Read more
Calum Pringle

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

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

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.

Read more
Iain Farrell

c5f1a741920x1200 (2)Stop the LightBrother typewriterBegonialast breath...
La GomeraLandingFleurs de Prunus 2/4Trazo solitario

13.04 Shortlist in progress, a gallery on Flickr.

A quick update, the previous contributors and I are putting together the finishing touches to what we hope will be a great selection. You can see our working over on a Google spreadsheet we’ve made.

We’ll be packaging and downloading and shrinking and all sorts to get it into the final release on the 14th! More once we have agreement on a selection! :)


Read more
Christina Li

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

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

Key screens

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

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

Enter a new calculation

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

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

 

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

Start a new calculation

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

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

View a calculation

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

Delete a calculation

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

Add a label

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

 

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

Numpad layout

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

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

Read more
Calum Pringle

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.

Read more
Mika Meskanen

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

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

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

Change to another month

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

Change to another day

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

Compress the month view into a week view

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

Change from timeline to diary view

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

Create an event

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

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

View event details

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

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

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

What’s next?

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

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

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

Read more
niemeyer

A small and fun experiment is out:

Read more
niemeyer

Lately I’ve been considering the amount of waste we produce during software development, and how to increase the amount of recycled content. I’m not talking about actual trash, though, but rather about software development artifacts.

Over the years, we’ve learned about and put in practice several means for improving the quality and success rate of projects we create or contribute to. We have practices such as sprints to get people together with high communication bandwidth; we have code reviews for sharing knowledge and improving project quality; we’ve got technical leadership roles to mentor developers and guide the progress of projects; we’ve created kanban boards and burndown charts to help people visualize what they’re going through; and so on.

While all of that seems to have helped tremendously, there’s a sad fact about where we stand: the artifacts of most of these processes are local to their context, and very sensitive to time. That burndown chart is meaningless after it’s burned, and a kanban has no relevant history. Our technical leads indeed guide their teams, but their wisdom stays with the few people that had the chance to interact with them, and subjectively so. That brilliant code review from our best developers has a very limited audience, and rarely carries any meaning just days after it has been accomplished.

That last one is specially interesting. The process of reviewing code is an intense task, very expensive, and that takes a significant portion of the life of an active developer, and even then very little is carried forward as the outcome of that process. We have no effective means or even culture of sharing the generated wisdom to other teams. In fact, we rarely share these details even within the team itself. Why was that line changed like this? Why an interface like that is a bad idea? Who will instruct the new guy next week, and where did we record a bit of the wisdom of the brilliant guy that has left the company recently?

Unfortunately there’s probably no easy solution for this problem. At this point, I mainly recognize that most of the efforts I’ve lead to improve software development for the past several years had a very limited scope. The software itself became immediately better as a result of my efforts, its design became more sensible, and hopefully I contributed a bit to the growth of people around me, but at a company or even community-wide scope, all of these code reviews, sprints, and IRC conversations are buried for very rare revives.

I want to start doing something about this, though. There must be a way to shape these conversations in a more reusable format; in a way that knowledge and agreement can be more proactively preserved and scattered. Perhaps it’s more about how than it is about what. Perhaps we just need to write more posts like this, and cover more topics related to daily development findings. Not sure. I’ll be thinking…

Read more
Amritpal Singh Bhachu

Back to Lecturing for the day

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.

 

Read more
Inayaili León

A fresh-looking Design Blog

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.

Ubuntu Design blog team page
The new Team page

A focus on content and flexibility

Ubuntu Design: Article page

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?

 

Read more
Iain Farrell

?appapáwr[a]Pantano de Orellanagreen plant againRoof Tiles WallpaperCairnGran Canaria IMG_1743mFrozenVanishing by James WilsonEarly morningA Little Quetzal
Here they are! Our lovely wallpapers for the 12.10 release of Ubuntu. Fine plumage I think you’ll agree! As you’ll have seen elsewhere on the web these landed in the release at the time of the freeze last week. A massive thanks to everyone who contributed, the standard was very high this time around, people really thought about their image choices. We’ve also managed to sneak one extra image into the package too, an illustrated Quetzal by popular demand ;) We got a lot of help, in particular I think it’s worth thanking the following people: At Canonical on the design side Otto and Cimi for casting a critical eye and Nick for reminding them to do so and Ken VanDine for packaging so beautifully and making sure they got into the release. In the wallpapers IRC channel Jakob Mühldorfer, Finn Sturdy, Robert Katzki and Fernando García looked over the images, tried to make the package smaller once we had a shortlist, experimented with image compression and followed up with emails late into the night. They also came back over following days to see if there was anything more they could do to help. For next cycle I would propose that we keep the open IRC channel to discuss images and impose a limited time for review, it helped us drive towards a solution and meant anyone interested could come in to help. I’d also like to investigate submission solutions for non Flickr users. This comes up every cycle and it would be great to have a place that people could contribute images to so if anyone reading this has the inclination and time to look into a solution, you’ve got 6 months. Drop me a note and let’s get cracking! :) You can view the 12.10 shortlist, a gallery on Flickr here, thanks again and here’s to an even better selection in 13.04!

Read more
Iain Farrell

?appapáwr[a]Pantano de Orellanagreen plant againwyomingRoof Tiles WallpaperCairn
Gran CanariaIMG_1743mFrozenVanishing by James WilsonBlue dandelionEarly morning
PucatriweGrass stick

12.10 shortlist, a gallery on Flickr.

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


Read more
Calum Pringle

Calum and Mika’s cakes.

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


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

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

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


Read more
niemeyer

I’m glad to announce experimental support for multi-document transactions in the mgo driver that integrates MongoDB with the Go language. The support is done via a driver extension, so it works with any MongoDB release supported by the driver (>= 1.8).

Features

Here is a quick highlight list to get your brain ticking before the details:

  • Supports sharding
  • Operations may span multiple collections
  • Handles changes, inserts and removes
  • Supports pre-conditions
  • Self-healing
  • No additional locks or leases
  • Works with existing data

Let’s see what these actually mean and how the goodness is done.


The problem being addressed

The typical example is a bank transaction: imagine you have two documents representing accounts for different people, and you want to transfer 100 bucks from Aram to Ben. Despite the apparent simplicity in that description, there are a number of edge cases that turn it into a non-trivial change.

Imagine an agent processing the change following these steps:

  1. Is Ben’s account valid?
  2. Take 100 bucks out of Aram’s account if its balance is above 100
  3. Insert 100 bucks into Ben’s account

Note that this description already assumes the availability of some single-document atomic operations as supported by MongoDB. Even then, how many race conditions and crash-related problems can you count? Here are some spoilers that hint at the problem complexity:

  • What if Ben cancels his account after (1)?
  • What if the agent crashes after (2)?

How it works

Thanks to the availability of single-document atomic operations, it is be possible to craft a sequence of changes that manipulate documents in a way that supports multi-document transactional behavior. This works as long as the clients agree to use the same conventions.

This isn’t exactly news, though, and there’s even documentation describing how one can explore these ideas. The challenge is in crafting a generic mechanism that not only does the basics but goes beyond by supporting inserts and removes, being workload agnostic, behaving correctly on crashes (!), and yet remaining pleasant to use. That’s the territory being explored.

The implemented semantics offers an isolation level that allows non-repeatable reads to occur (a partially committed transaction is visible), but the changes are guaranteed to only be visible in the order specified in the transaction, and once any change is done the transaction is guaranteed to be applied completely without intervening changes in the affected documents (no dirty reads). Among other things, this means one can use any existing mechanism at read time.

When writing documents that are affected by the transaction mechanism, one must necessarily use the API of the new mgo/txn package, which ended up surprisingly thin and straightforward. In other words for emphasis: if you modify fields that are affected by the transaction mechanism both with and without mgo/txn, it will misbehave arbitrarily. Fields that are read or written by mgo/txn must only be changed using mgo/txn.

Using the example described above, the bank account transfer might be done as:

runner := txn.NewRunner(tcollection)
ops := []txn.Op{{
        C:      "accounts", 
        Id:     "aram",
        Assert: M{"balance": M{"$gte": 100}},
        Update: M{"$inc": M{"balance": -100}},
}, {
        C:      "accounts",
        Id:     "ben",
        Assert: M{"valid": true},
        Update: M{"$inc": M{"balance": 100}},
}}
id := bson.NewObjectId() // Optional
err := runner.Run(ops, id, nil)

The assert and update values are usual MongoDB querying and updating documents. The tcollection is a MongoDB collection that is used to atomically insert the transaction details into the database. As long as that document makes it into the database, the transaction is guaranteed to be eventually entirely applied or entirely aborted. The exact moment when this happens is defined by whether there are other transactions in progress and whether a communication problem occurs and when it occurs, as described below.

Concurrency and crash-proofness

Perhaps the most interesting piece of the puzzle when coming up with a nice transaction mechanism is defining what happens when an agent misbehaves, even more in a world where there are multiple distributed transaction runners. If there are locks, someone must unlock when a runner crashes, and must know the difference between running slowly and crashing. If there are leases, the lease boundary becomes an issue. In both cases, the speed of the overall system would become bounded by the speed of the slowest runner.

Instead of falling onto those issues, the implemented mechanism observes the transactions being attempted on the affected documents, orders them in a globally agreed way, and pushes all of their operations concurrently.

To illustrate the behavior, imagine again the described scenario of bank transferences:

In this diagram there are two transactions being attempted, T1 and T2. The first is a transference from Aram to Ben, and the second is a transference from Ben to Carl. If a runner starts executing T2 while T1 is still being applied by a different runner, the first runner will pick T1 up and complete it before starting to work on T2 which is its real goal. This works even if the original runner of T1 died while it was in progress. In reality, there’s little difference between the original runner of T1 and another runner that observes T1 on its way.

There’s a chance that T1′s runner died too soon, though, and it hasn’t had a chance to even start the transaction by tagging Ben’s account document as participating in it. In that case, T2 will be pushed forward by its own runner independently, since there’s nothing on its way. T1 isn’t lost, though, and it may be resumed at any point by calling the runner’s Resume or ResumeAll methods.

The whole logic is implemented without introducing any new globally shared point of coordination. It works if documents are in different collections, different shards, and it works even if the transaction collection itself is sharded across multiple backends for scalability purposes.

The testing approach

While a lot of thinking was put onto the way the mechanism works, this is of course non-trivial and bug-inviting logic. In an attempt to nail down bugs early on, a testing environment was put in place to simulate multiple runners in a conflicting workload. To make matters more realistic, this simulation happens in a harsh scenario with faults and artificial slowdowns being randomly injected into the system. At the end, the result is evaluated to see if the changes performed respected the invariants established.

While hundreds of thousands of transactions have been successfully run in this fashion, the package should still be considered experimental at this point, and its API is still prone to change.

There’s one race

There’s one known race that’s worth mentioning, and it was consciously left there for the moment as a tradeoff. The race shows itself when inserting a new document, at the point in time when the decision has been made that the insert was genuinely good. At this exact moment, if that runner is frozen for long enough that would allow for a different runner to insert the document and remove it again, and then the original runner is unfrozen without any errors or timeouts, it will naturally go on and insert the new document.

There are multiple solutions for this problem, but they present their own disadvantages. One solution would be to manipulate the document instead of removing it, but that would leave the collection with ghost content that has to be cared for, and that’s an unwanted side effect. A second solution would be to use the internal applyOps machinery that MongoDB uses in its sharding implementation, but that would mean that collections affected by transactions couldn’t be sharded, which is another unwanted side effect (please vote for SERVER-1439 so we can use it).

Have fun!

I hope the package serves you well, and if you would like to talk further about it, please join the mgo-users mailing list and drop a message.

Read more
Iain Farrell

Trazo solitario by Julio Diliegros - on Flickr

Quantal is well on the way to being the great release we’ve come to expect from Ubuntu so it’s time to add to that sheen with a set of quality wallpapers from our fantastic community. This cycle we’re going to try to make the process better than before by setting out a clearer vision for what we think will make a great set.

Firstly we’re interested in quality not quantity so we’re going to limit ourselves to 10 images on the final CD. We’ll take submissions in the Flickr group as before and don’t forget we need your image licensed as CC by SA. Each Flickr user will be limited to 1 submission to the group so choose carefully!

Secondly I’ve been speaking to Otto, the Lead visual designer at Canonical, to help ensure that what we get feels at home on the desktop. The guidance we’ll follow when selecting images to go into the release is as follows:

  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. They should have a single point of focus, a single area that draws the eye in
  3. We should avoid having anything on the left and top edges as this will clash with the interface elements of the Launcher and Panel
  4. Try your image at different aspect ratios to make sure something important isn’t cropped out on smaller/ larger screens

To shortlist from this collection, as usual, we’ll be going to the people whose images were selected last time around to help us choose the final 10. In doing this we’ll hold a series of public IRC meetings on #1210wallpaper to discuss the selection and 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’s welcome to come to these sessions but please bear 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.

The group’s open for submissions now and we’ll close it at 5pm on the 28th August 2012 to start going through the images.

So, get all your great summer photos out and as always ping me if you have any questions. I’ll be lurking in #1210wallpaper on freenode. I hope it’s been sunnier in places other than the UK!


Read more
Calum Pringle

Olympic Cake

The design team was (mostly) on the Isle of Man last week so we missed a cake day, but this week everything is back to normal (phew). As Matthew couldn’t join us on the island, and to keep him busy, he was nominated for this weeks cake duty –  Let’s hope the Olympic’s brand police don’t catch him!

Matthew used edible glitter and fruit for the colouring of the Olympic rings, on top of five mini Genoese sponges.

Read more
Mika Meskanen

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

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

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

IMG_0518 IMG_5120 IMG_0611 IMG_1665 IMG_5083 IMG_0012

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

Read more
Christian Giordano

Introducing web apps

As you might have heard from the blogosphere, we are going to start to ship our take on web apps. Let me take the opportunity to explain to you some of the reasoning behind them and some of their characteristics.

Why

I would split the why question in more parts.

Is the Web relevant? Today, the Web, besides being the best source for information, is also a major component in how we relate to one another. There are very few applications that don’t use the Web in one way or another.

Are web applications relevant on the Desktop? If you look at the first tabs of your browser window, chances are that these are tabs you keep open and glance at every now and then to check if a change has occurred. This is not optimal! Facebook and your webmail could (and should) be more integrated in your experience. Browsers acknowledged this problem a while ago by introducing desktop notifications and more compact tabs, but the shell itself is in the best position to provide such capabilities.

Are web applications also relevant to other form factors? It is true that in recent years there has been quite some hype about native applications for mobile platforms. While using a native toolkit can provide the developer some initial edge, the advantages quickly fade when more form factors or platforms need to be supported. The speed of how you can globally test changes, and the accessibility of the technology, made the web a very fast paced environment for innovation. Despite having evolved mainly through a consortium, web technologies, with their separation of content and representation, are in a very good position to support multiple screens.
Because of these reasons, it shouldn’t surprise you if the Facebook native application for iOS is rated with just 2 stars whereas the web version for mobile, in many aspects, works much better. The share-ability of the techniques will also make it so that compelling experiences will become more and more common outside of the native space.

Not just web links

One of the major critics about this project has been the comparison to simple web links. Web apps will be far from being simple web links. As a matter of fact, it has been our priority, from UX perspective, to blur the line between native applications and web apps. In fact, if we consider native applications heavily dependent on the Internet connection and web applications which can work offline, there is an obvious overlap. The demo you see today shows the current state of the project, which is already impressive, but in the coming months you will see how these will beautifully blend in the user app mental model.

Conclusions

Unity, thanks to its components (e.g.: Sound Menu, Notify OSD), offers a unique opportunity for web applications to integrate with the shell user experience. There will be design, technological and political challenges, but web technologies are here to stay!

More information is available in the official release post and in the detailed coverage from OMGUbuntu.

Read more