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…

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

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

The Winning Group with their Ubuntu prizes

Several things frustrated me however.

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

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

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

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

Bright Club Dundee Performers

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

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

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

Why change?

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

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

The new Team page

A focus on content and flexibility

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

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

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

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

The Ubuntu font

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

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

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

Small screens

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

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

What’s next

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

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

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

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

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

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

Speak to you all tomorrow

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

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!

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.

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!

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.

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:

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

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.

Every weekly team meeting someone is tasked with baking a cake. Ivanka baked for this week’s cake day – check out her cheesecake! So you know, this is not going to become a culinary blog, but cake day is a good reason to post! Being a designer is not (always) a piece of cake.

?Rob Pike just wrote an article/talk that is the best background on the origins of Go yet.

It surprises me how much his considerations match my world view pre-Go, and in a sense give me a fulfilling explanation about why I got hooked into the language. I still recall sitting in a hotel years ago with Jamu Kakar while we went through the upcoming C++0x standard (now C++11) and got perplexed about how someone could think that having details such as rvalue references and move constructors into the language specification was something reasonable.

Rob also expressed again the initial surprise that developers using languages such as Python and Ruby were more often the ones willing to migrate towards Go, rather than ones using C++, with some reasonable explanations about why that is so. While I agree with his considerations, I see Python going through the same kind of issue that caused C++ to be what it is today.

Consider this excerpt from PEP 0380 as evidence:

If yielding of values is the only concern, this can be performed without much difficulty using a loop such as

for v in g:
    yield v

However, if the subgenerator is to interact properly with the caller in the case of calls to send(), throw() and close(), things become considerably more difficult. As will be seen later, the necessary code is very complicated, and it is tricky to handle all the corner cases correctly.

A new syntax will be proposed to address this issue. In the simplest use cases, it will be equivalent to the above for-loop, but it will also handle the full range of generator behaviour, and allow generator code to be refactored in a simple and straightforward way.

This description has the same DNA that creates the C++ problem Rob talks about. Don’t get me wrong, I’m sure yield from will make a lot of people very happy, and that’s exactly the tricky part. It’s easy and satisfying to please a selection of users, but often that leads to isolated solutions that create new cognitive load and new corner cases that in turn lead to new requirements.

The history of generators in Python is specially telling:

• PEP 0234 [30-Jan-2001] – Iterators – Accepted
• PEP 0255 [18-May-2001] – Simple Generators – Accepted
• PEP 0288 [21-Mar-2002] – Generators Attributes and Exceptions – Withdrawn
• PEP 0289 [30-Jan-2002] – Generator Expressions – Accepted
• PEP 0325 [25-Aug-2003] – Resource-Release Support for Generators – Rejected
• PEP 0342 [10-May-2005] – Coroutines via Enhanced Generators – Accepted
• PEP 0380 [13-Feb-2009] – Syntax for Delegating to a Subgenerator – Accepted

You see the rabbit hole getting deeper? I’ll clarify it further by rephrasing the previous quote from PEP 0380:

If [feature from PEP 0255] is the only concern, this can be performed without much difficulty using a loop [...] However, if the subgenerator is to interact properly with [changes from PEP 0342] things become considerably more difficult. [So we need feature from PEP 0380.]

Yet, while the language grows handling self-inflicted micro-problems, the real issue is still not solved. All of these features are simplistic forms of concurrency and communication, that don’t satisfy the developers, causing community fragmentation.

This happened to C++, to Python, and to many other languages. Go seems slightly special in that regard in the sense that its core development team has an outstanding respect for simplicity, yet dares to solve the difficult problems at their root, while keeping these solutions orthogonal so that they support each other. Less is more, and is not always straightforward.

Today’s API design fail case study is Iconv. It is a library designed to convert text from one encoding to another. The basic API is very simple as it has only three function calls. Unfortunately two of them are wrong.

Let’s start with the initialisation. It looks like this:

iconv_t iconv_open(const char *tocode, const char *fromcode);

Having the tocode argument before the fromcode argument is wrong. It goes against the natural ordering that people have of the world. You convert from something to something and not to something from something. If you don’t believe me, go back and read the second sentence of this post. Notice how it was completely natural to you and should you try to change the word order in your mind, it will seem contrived and weird.

But let’s give this the benefit of the doubt. Maybe there is a good reason for having the order like this. Suppose the library was meant to be used only by people writing RPN calculators in Intel syntax assembly using the Curses graphics library. With that in mind, let’s move on to the second function as it is described in the documentation.

size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft,
 char* * outbuf, size_t * outbytesleft); 

In this function the order is the opposite: source comes before target. Having the order backwards is bad, but having an inconsistent API such as this is inexcusable.

But wait, there is more!

If you look at the actual installed header file, this is not the API it actually provides. The second argument is not const in the implementation. So either you strdup your input string to keep it safe or cast away your const and hope/pray that the implementation does not fiddle around with it.

The API function is also needlessly complex, taking pointers to pointers and so on. This makes the common case of I have this string here and I want to convert it to this other string here terribly convoluted. It causes totally reasonable code like this to break.

char *str = read_from_file_or_somewhere();
iconv(i, &str, size_str, &outbuf, size_outbuf);

Iconv will change where str points to and if it was your only pointer to the data (which is very common) you have just lost access to it. To get around this you have to instantiate a new dummy pointer variable and pass that to iconv. If you don’t and try to use the mutilated pointers to, say, deallocate a temporary buffer you get interesting and magical crashes.

Passing the conversion types to iconv_open as strings is also tedious. You can never tell if your converter will work or not. If it fails, Iconv will not tell you why. Maybe you have a typo. Maybe this encoding has magically disappeared in this version. For this reason the encoding types should be declared in an enum. If there are very rare encodings that don’t get built on all platforms, there should be a function to query their existence.

A better API for iconv would take the current conversion function and rename it to iconv_advanced or something. The basic iconv function (the one 95% of people use 95% of the time) should look something like this:

int iconv(encoding fromEncoding, encoding toEncoding,
  errorBehaviour eb,
  const char *source, size_t sourceSize,
  char *target, size_t targetSize);

ErrorBehaviour tells what to do when encountering errors (ignore, stop, etc). The return value could be total number of characters converted or some kind of an error code. Alternatively it could allocate the target buffer by itself, possibly with a user defined allocator function.

The downside of this function is that it takes 7 arguments, which is a bit too much. The first three could be stored in an iconv_t type for clarity.

Normally the Ubuntu/Canonical Design Team are busy working on our own projects, but it makes a really good change to work on other Free Software design problems for a change. Starting at 22:00 UTC (15:00 PDT) on Monday 7 May 2012, you can join us for the next Ubuntu Design Theatre at the Ubuntu Developer Summit in Oakland, California:

• Live audio-only stream from Room 201
• Freenode #ubuntu-uds-room-201
• Live notes from Room 201

Bring your design issues along and lets see how we can improve them! There should be visual designers, user interface designers, brand designers, … and the many other people who try and work to make users’ lives better with Free Software.

In the year 2000 IBM showed off the WatchPad, a computer on your wrist, but one perhaps ahead of its time and still needing a little bit of design-love. Of course, we love highlighting beautiful design when it does finally come along, and in the last few days the beautiful Pebble smartwatch has appeared over the horizon.

As well as being “just a watch” with a long-lasting e-paper display it has a Bluetooth wireless connection, opening up all sorts of possibilities for expansion; particularly showing notifications, SMS messages, or status and calendar updates without having to check a mobile phone directly. Once it’s on your wrist the possibilites are there for all sorts of apps (not just fancy clocks!).

In under one week they’ve raised $5 million in pre-orders from 35,000 individuals—taking the Kickstarter record for the largest amount raised through crowd-funding. A finished product does not just happen by itself, it requires lots of expertise; industrial design for the water-tight casing, ergonomics to make sure it fits on your wrist, electronics layout design for the battery, buttons and e-ink screen …and some firmware (embedded computer software) to make it all work.

Andrew Witte (second from the left in the dream team) is the Lead Engineer working on the firmware and an Ubuntu fan. Andrew’s desk on a typical day has a sprawl of cables, a Lego car, some low-level JTAG programmers, USB prototyping cables, several half-finished Pebble boards …and, in the middle is Xubuntu (Ubuntu running with an XFCE desktop) for the development and debugging.

Lots of open source is also being used to make the watch tick. The firmware development toolchain is CodeSourcery GCC for compiling, OpenOCD for working with the JTAG, and GDB (the GNU debugger) for finding all hard to solve bugs. One of the main parts of the Pebble is the Bluetooth interface for talking to smart phones, for which many hours have been spent testing with Ben Lam’s Python-based ‘LightBlue’ framework and utilities like hcitool. If that’s all getting a bit technical, Andrew notes that The Gimp and ImageMagick (both in the Ubuntu Software Centre) are used for processing the bitmaps and pictures before they are sent to the Pebble watch prototypes.

The race is on for the first person who can get a prototype in August 2012 and integrate Ubuntu’s libnotify-osd work with the Pebble watch, in time for Ubuntu 12.10 in six months time! For those with a pre-order, it will be possible to vote on additional-colour in addition to Artic White, Cherry Red and Jet Black. We’re hoping that Ubuntu Orange wins!

The Pebble Kickstarter campaign runs until 18 May 2012. To vote later for a colour (such as Ubuntu Orange!) you need to pre-order in the colour-Pebble category ($125+shipping).

Some of original sketches for Ubuntu Arabic are about to go on display in Berlin! We’ve talked before about the work done by Rayan Abdullah on drawing and designing the original calligraphy behind the Ubuntu Arabic for the Ubuntu Font Family and from tomorrow you will be able to see that work for yourself.

Until 27 May 2012 you can see some of those original sketches and designs featuring in the Typobau exhbition at the Körnerpark Gallery in Neukölln, Berlin,

It includes many of Rayan’s design projects from the last decade, including the Bundesadler (the Federal Eagle of Germany) and his many Arabic graphic design and typography projects including the logos and typefaces for Burberry, McDonalds, Nokia Pure Arabic and the Ubuntu Font Family Arabic script coverage.

For keen visitors, the grand opening is this week, at 19:00 on Friday 20 April 2012. Or for anyone visiting Messe Berlin in May 2012 for Linuxtag 2012 you will still be able to catch the exhibition. Just take the S-Bahn ring anti-clockwise to S-Neukölln and see Ubuntu and Rayan’s exhibition at the same time as Linuxtag!

The “Typobau” exhibition runs between 21 April 2012 and 27 May 2012, 10:00–20:00, Tuesday—Sunday, at Körnerpark Galerie, Schierker Strasse 8, Berlin-Neukölln

Over the past two years, Ubuntu has introduced a suite of status menus — known to Ubuntu geeks as “indicators” — in the top corner of the screen.

In Ubuntu 12.10, we plan to refine these menus to address several long-standing problems. If you’re a programmer, tester, or visual designer, there are plenty of opportunities for you to help out.

In updating the design, our general theme has been improving relevance — showing menus, and items in menus, only when they are relevant to you. For example, if you never use a VPN, it shouldn’t take up space in the network menu. If you never use Gwibber, it shouldn’t take up space in the messaging menu. If you never use a Bluetooth device, you shouldn’t need to see the Bluetooth menu. And so on.

System menu

The biggest change to the structure, though, is a straightforward simplification. The two menus at the end of the menu bar, the user and system menus, will merge. As well as saving space, this will fix three main problems:

• “Switch User Account” and “Log Out” were in different menus, despite being closely related. Now, they’ll be in the same menu. (“Lock Screen” and “Switch User Account” will become one and the same command.)
• It’s been hard to find which version of Ubuntu you are using. This will now have a dedicated menu item.
• Finding the Ubuntu Help has also been difficult. That will now have an always-present menu item too.

One more detail. When Ubuntu used a home icon to represent the Nautilus file manager, usability testing found that people thought it was a launcher or starting point. (This isn’t surprising, given the strong connotations of Home in other applications.) The Unity Dash, meanwhile, is exactly that kind of starting point. So one possibility under discussion is changing the Dash launcher icon to a home icon — which the Dash already uses for internal navigation anyway.

How is that relevant to the status menus? It raises the possibility that we could use the Ubuntu logo, if it won’t be in the launcher, as the title of the system menu instead. We plan to test this against the powercog icon, and see which works better.

Clock menu

Many improvements can be made to the clock menu, but the design will remain much the same.

We’d like to add the ability to set a basic alarm, and if it’s set, this will be shown using an icon in the menu title.

If you’re a programmer and know your way around C and GObject, another simple enhancement would be populating the coming events section of the menu from a Web calendar, such as Google Calendar.

Sound menu

The sound menu design will remain unchanged in 12.10. As with the clock menu, though, there are plenty of minor improvements to work on.

Network menu

Ubuntu’s network menu is powered by Network Manager, and our design is a visual presentation of where we’d like to take it in future. It simplifies the current menu by using consistent on/off switches for connection types, removing needless separators, and showing less common functions — mobile broadband and VPNs — only if you have set them up in the Network settings.

Bluetooth menu

As with the network menu, we’d like to simplify the Bluetooth menu by using on/off switches and reducing separators.

Battery menu

The battery menu design will stay the same.

Messaging menu

We plan to simplify the messaging menu by removing the default Chat, Mail, and Broadcast items. Instead, messaging programs will show up only if you have set them up, and will show up under their own names. As well as shortening the menu, this will solve the problem that nobody knows what “Broadcast” means.

In Ubuntu for Android, the messaging menu will naturally expand to show missed calls, voicemail, and SMS messages.

And finally, Ubuntu One will at long last be banished from the messaging menu, moving instead to the menu next door…

Sync menu

The new Sync menu will be present if you use any services such as Ubuntu One, SparkleShare, or Dropbox, that carry out non-urgent synchronization over the network. (Continuing the relevance theme, the menu won’t be present at all if you haven’t signed up for any of those services yet.)

From this menu, you’ll be able to turn each service off and on — turning them off if you’re trying to download something in a hurry, for example. You’ll also be able to access their settings, if they have any.

Keyboard menu

We’d like to make two main improvements to the keyboard menu.

First, combining it with the input method menu. So that if you use input methods (such as for Chinese, Japanese, or Korean), you don’t have two separate menus for controlling your keyboard.

And second, making the menu title an icon that represents the current input method or keyboard layout, instead of a generic keyboard icon with added text. (Visual designers could help us here, in finding an elegant way to generate an icon based on the letter code for each layout.)

So long, printing menu, we hardly knew you

In Ubuntu 12.04, a printing status menu appears whenever any print jobs are in progress. Unfortunately, it’s not that noticeable.

So in 12.10, we plan to replace it with a temporary printing item in the launcher. This will correspond to a minimized window listing your recent print jobs. You can close it when done, or just ignore it, as you see fit.

What’s next

As these designs are fleshed out, the individual specifications will be updated in the ‘Unity Application and System Indicators’ section of The Toolkit.

This is a lot of work, and you’re welcome to help out if you can. Pop in to the #ubuntu-unity channel on IRC, or get in touch on the unity-dev@ mailing list.

In the open source community, we celebrate having pieces that “do one thing well”, with lots of orthogonal tools compounding to give great flexibility. But that same philosophy leads to shortcomings on the GUI / UX front, where we want all the pieces to be aware of each other in a deeper way.

For example, we consciously place the notifications in the top right of the screen, avoiding space that is particularly precious (like new tab titles, and search boxes). But the indicators are also in the top right, and they make menus, which drop down into the same space a notification might occupy.

Since we know that notifications are queued, no notification is guaranteed to be displayed instantly, so a smarter notification experience would stay out of the way while you were using indicator menus, or get out of the way when you invoke them. The design story of focusayatana, where we balance the need for focus with the need for awareness, would suggest that we should suppress awareness-oriented things in favour of focus things. So when you’re interacting with an indicator menu, we shouldn’t pop up the notification. Since the notification system, and the indicator menu system, are separate parts, the UNIX philosophy sells us short in designing a smart, smooth experience because it says they should each do their thing individually.

Going further, it’s silly that the sound menu next/previous track buttons pop up a notification, because the same menu shows the new track immediately anyway. So the notification, which is purely for background awareness, is distracting from your focus, which is conveying exactly the same information!

But it’s not just the system menus. Apps can play in that space too, and we could be better about shaping the relationship between them. For example, if I’m moving the mouse around in the area of a notification, we should be willing to defer it a few seconds to stay out of the focus. When I stop moving the mouse, or typing in a window in that region, then it’s OK to pop up the notification.

It’s only by looking at the whole, that we can design great experiences. And only by building a community of both system and application developers that care about the whole, that we can make those designs real. So, thank you to all of you who approach things this way, we’ve made huge progress, and hopefully there are some ideas here for low-hanging improvements too

For another cycle a selection of images has been put forward for inclusion in Ubuntu. As there have been some questions on other blogs about the process I thought it was worth doing a quick refresher. Each release we ask the community contributors whose images were included in the last release if they’d like to help choose the images that should go into the up coming release. This release we are endebted to the following Flickr users and community members:

• madeinkobaia
• SirPecanGum
• bolorino
• Deacon MacMillan
• Noah Bertilson
• Micheo
• Fix Peña
• Fejes Ádám
• federica_miglio
• Difusa
• Hugo.Cliff
• Mohamed Malik
• Dh0r
• paco • espinoza
• pr09studio
• Belhor_
• Emilio Merlino
• erin_estes
• j_baer
• fernando garcía redondo
• followtheseinstructions