Canonical Voices

Posts tagged with 'recentwork'

John Lea

Introduction to task switching

A key part of any operating system user interface is how it enables the user to switch between multiple tasks. In most desktop operating systems tasks are encapsulated into windows, and the most frequently used method of multi-tasking is window switching. Desktop OSs have multiple methods of window switching (e.g Alt-tab, clicking on indicators, notifications, etc…) however the most common means of window switching is via using what is variously termed a Launcher, Taskbar or Dock. Traditionally there has been a 1:1 correlation between each window and its representation in the Taskbar (see Windows2000 or Gnome2).


(Ubuntu Hardy Heron used Gnome2 which featured one taskbar icon per window)

With Windows XP, Microsoft introduced a way to aggregate multiple windows that belonged to the same application into a single task bar button. This change was primarily focused towards personas who made heavy use of multi-tasking; this feature only switched on when the number of windows represented in the Taskbar exceeded the length of the Taskbar. It gave the benefits of increasing the number of windows that could be comfortably represented in the available task bar space, and reduced the time and effort it took the user to visually scan a crowded Taskbar and identify an application. The cost of this change was that an additional click was required to switch to a window that was not the most recently focused window of that application.

Windows XP desktop
(The WindowsXP desktop that introduced the concept of representing multiple windows with one taskbar icon)


Unity’s current window switching functionality

Fast forwarding to 2009, when working on the original designs for Unity we knew that window switching was one of the key areas of any OS’s user interface, and we set out to design a window switching paradigm that would surpass the utility and usability of the contemporary competition at the time (Windows 7 and OSX Snow Leopard). The Launcher was only 50% of that equation, the other 50% was a set of functionality we termed the ‘Spread’.

The Spread designs were completed, prototyped and tested well before the launch of Unity with 11.04, but unfortunately due to the huge number of other items that needed to be completed before we could launch a brand new desktop shell, the decision was made to postpone the development of this feature and use the Compiz equivalent of this functionality as a stop-gap measure.

Ubuntu 11.04 desktop
(Compiz window switching in Ubuntu 11.04)

While using the Compiz window switching functionality enabled us to hit 11.04 launch deadline, there are a number ways in which it could be improved. Since then many many bugs, mailing list and forum postings have also requested the same set of functionality that was postponed as a result of this decision. Requests we frequently receive include:

  • Please make it easier to tell one window from another, all terminals look very similar!
  • Make it easier to select windows using keyboard navigation and shortcuts
  • I would like to be able to easily close windows from the window switcher view
  • Can you make it clearer to see which application’s windows are currently being displayed (in the switcher view)?
  • I find it difficult to see which window is currently focused in the window switcher view, can this be improved?
  • Can you find a way to make window switching faster?

Window switching requirements

After researching the window switching problem space and examining the use cases that a window switcher needs to support, we distilled the findings into a set of design requirements. These were:

  • To aid window identification, the window previews should to be as large as possible, taking maximum advantage of the available screen real estate.
  • Window switching needs to be very intuitive and easy to understand for new users. In user testing, a user who has never used Ubuntu before must be able to switch windows without encountering any difficulty.
  • More experienced users should be offered an accelerated method of ultra-fast window switching.
  • Users should be presented with all the information that is pertinent to making a window switching decision, but no more.
  • The window switching mechanism should follow the activity/task hierarchy, in order to minimise time needed to identity the required application, support intensive multi-tasking use cases with very large numbers of windows, simplify the Launcher ordering problem, and make the most efficient use of the Launcher’s screen real estate.

A very brief introduction the ‘Spread’

So now with 12.04 almost behind us, we have dusted off our original Spread designs and given them a light spring clean ahead of development starting in 12.10. So without further ado…

This design shows when happens when a user clicks on the Firefox icon to spread the available windows. The maximum amount of screen real estate is dedicated to making the window previews as large as possible. Moving the pointer over any of the previews will display the window name in a window title bar, and a close button is included so that any window can be dismissed directly from this view. When in this view users can also directly switch to spreads of other running applications by clicking on application icons in the Launcher.

In addition to pointing and clicking with a mouse or trackpad, power users can perform all window switching actions without taking their hands off the keyboard. Holding down the SUPER key will reveal the Launcher with numbers overlaid on top of the individual Launcher icons.

Pressing a number performs the equivalent action to a left click, so if a app is already focused pressing its number will reveal a spread of its windows.

When the spread is revealed, numbers are displayed in the bottom left corner of the previews. Pressing a number will then select the relevant window and close the Spread. Added together this allows a power user to switch to any window of any application just by using the SUPER and NUMBER keys. In addition users will be able to navigate the Spread by using cursor keys to move the orange focus box and ENTER to select.

Another new feature is the ghost window ‘New Window’ option. Previously if a user wanted to open a new window for an application that was already running they had to either middle click on the application’s Launcher icon or press CTRL+N. The problem was that new users had no easy way of discovering these options. When using the Spread, a user can select the ghost window to open a new window of the currently focused application. This feature has even more benefits in a multi-monitor context, and if a application does not support multiple windows this option is not displayed.

Other features include the ability to filter the windows by typing…

and of course this new functionality apples to the SUPER+W spread of all windows on the desktop.


Multi-monitors, workspaces, and all the other gory details

This article only takes a very brief look at a few of the Spread’s features, and barely scratches the surface of the Spread design. A lot of thought has also gone into designing how the spread works in multi-monitor and/or multi-workspace environments, and if you are interested in learning more and reading all the gory details of how every corner case and eventuality is handled, head over to Unity Switching section of the The Toolkit to read the full spec.

Read more
Charline Poirier

Every three months, I conduct benchmark usability testing.  I’m calling these tests ‘benchmark testing’ because the aim of these sessions is to measure our progress towards achieving a great user experience with Ubuntu.  Last testing took place in October 2011.  I am now preparing for testing 12.04 to take place a couple of weeks from now.

When I publish the results of usability testing, I get many questions about my process.  So I have thought that the best way to explain how I approach usability is to take you along the preparation and execution of my benchmark testing. Over the next month, I will take you, step by step through my process, from recruiting participants, to writing a test protocol to conducting and analysing usability sessions and writing up results.  This will afford you the possibility of ‘accompanying me’, so to speak, and of conducting usability in parallel, if you are so inclined.

For this post, I walk through the first stage of any testing: recruiting participants.

Recruiting

This is a crucial part of any successful and meaningful testing.  Some argue that just anyone you can get hold of will do.  This attitude, in my view, puts the software before the people who will use it, and carries the implicit assumption that software, by its very nature, is usable. But the simple fact, which we actually all realise, is that it isn’t. Take music players, for instance.  The challenge for this type of software is to fit into the lives of people who want to listen to music.  It doesn’t have to work well for those who don’t listen to music but who are, for instance, heavily into photo editing.  In a word, testing your software with your grandmother or your partner might not provide all the feedback you need to create a user-friendly product if they are not engaged in the activities your software is meant to facilitate.

So, the basic idea is:  in preparing the testing, recruit the right people. The type of participants you work with will determine the quality and reliability of the results you get.

There are some basic rules for writing a screener questionnaire.

Rule 1:  Recruit according to your testing goals

Is your goal to test, for instance, adoption: that is, are you going to assess how new users respond to your software the first time they encounter it and how delighted they are by it?  Alternatively, is your goal to test learning: do you want to assess how easily a novice can figure out how to use your software and how they progress over time? Or are you really interested in expert usage:  do you want to assess how performative your software is in a specific context of use involving expert tasks?  There are, of course, other scenarios as well.  The point here is that you need to be clear about your goal before you begin.

With Unity, we have 2 basic goals:  1) adoption:  we want to know how easy to use and attractive Unity is to someone who has not encountered it before; and 2) expert usage:  we want to know how performative Unity is with highly competent users who are fairly familiar with it.

Given these very different goals, I will need to conduct 2 different user testing sessions with different recruiting screeners or questionnaires, and different protocols.

In this blog, I concentrate on my first project, to test for adoption.

Rule 2:  Know your software

You need to review your software carefully:  you need to (1) identify the main purpose of the software and the activities or tasks that it is meant to facilitate; and (2) identify where you think potential usability weaknesses are.

When I prepare a usability test, and before I even think about recruiting participants, I spend a significant amount of time trying out the software, and even more time discussing with the designers and developers their own concerns.  From this evaluation of the usefulness and usability of the software, I’m able to sketch a profile of participants.  Bear in mind that, given my goals as set out above, the participants will need to be able to use the software right away even if they’ve never used Ubuntu, since I am not testing for learning.

Given what Unity aims to allow users to do, we need to confirm (or not) in the testing that Unity users can easily get set up for and can conduct at least the following activities:

  • writing, saving, printing documents
  • finding, opening applications
  • listening to music
  • watching a movie
  • managing and editing photos
  • customising their computer: organising icons and short-cuts and changing setting
  • browsing the internet
  • communicating

Additionally, the OS should make it easy for users to:

  • multi task
  • navigate and use special features like alt-tab
  • be aware of what’s going on with their computer
  • create short-cuts
  • understand icons, notifications and generally the visual language

In this instance, I want as well to test the new features we have designed since 11.10

Given my goals, my recruitment screener should be written in a way that will provide me with participants who engage in these activities on a regular basis.

Rule 3: Make sure you have an appropriate number of participants, with an appropriate range of expertise, with appropriately different experiences

I’ve often heard it said that all you need is a handful of participants – for example, 5 will do.  While this may be true for very specific testing, when your participants come from a homogeneous group (for example, cardiologists, for testing a piece of cardiology software), it is not true generally.  Much more often, software is meant to be used by a variety of people who have differing goals, and differing relevant experience and contexts of use.

You need to take these into account for 2 purposes: 1) to be able to test the usefulness and appropriateness of the software for different users; and 2) to be able to assess the reasons and origins of any usability problem that you find – these can be explained by comparing differences between users. A usability problem will have a different design solution if it is created by a user’s lack of expertise than if it is created by a shortcoming of the software that stumped all user groups.  It will also help rate the severity of the discovered problems.

Some of the factors a competent recruiting will take into account are:

Different levels of expertise: for example, in the case of software for photo-editing, you probably need to assess the ease of use for people who have been editing their photos for more than 5 years, and for those who have been editing for less than 1 year.  Expertise can be reflected in the length of time they have been engaged in the activity and also in the complexity of their activities.  You may want to recruit people who do basic editing, like eliminating red-eye; and then, to compare their use of your software to the use by people who do special effects, montages, presentations and the like.  This way, you get feedback on a wide range of the software’s features and functionalities.

Different kinds of uses:  potential users will have different needs and different potential uses for the software.  For example, if the software is healthcare related, it may well be used by doctors, nurses, radiologists – and sometimes even patients.  It is useful, when considering recruiting, to include participants from these various professions and other walks of life, so that you will be able to determine how well your software serves the range of needs, processes and work conditions represented by the likely (range of) users.

Different operating systems:  you may want to select participants who use, at least, Windows, Mac and Ubuntu. Users who are new to Ubuntu have acquired habits and expectations from using another OS. These habits and expectations become with time equated with ease of use for these users because of their familiarity.  Recruiting participants with different habits and expectations will help you to understand the impact of these expectations as well as receptivity to innovation.

Recruiting your participants with precision will allow you to understand the usability of your software in a complex and holistic way and will dictate more innovative and effective design solutions.

Keep in mind, however, that the more diverse the kinds of persons who you envisage will be primary users for the software are, the larger the number of participants you will need.  You should recruit at the very least 5 similar participants per group – for instance, in the healthcare example, at least 5 doctors, 5 nurses, and 5 patients.

A few more things to consider explicitly putting into your questionnaire/screener, particularly if you are writing it for a recruiting firm:

It is advisable to have a mix of male and female participants;

Participants from different age groups often have different experiences with technologies, and so you should include a good mix of ages;

The perceived level of comfort with a computer can also help the moderator understand the participant’s context of use.  A question about how participants assess themselves as computer users can very often be helpful;

You should always add a general open question to your screener to judge the degree of facility with which the potential participant expresses ideas and points of view.  The moderator is dependent on the participant to express, in a quite short amount of time, the immediate experience of using the software.  Consequently, being able to understand the participant quickly and precisely is vital to obtaining rich and reliable data.  The individual who makes the recruitment needs to be able to evaluate the communication proficiency of the potential participant.

Rule 4: Observe the basics of writing the recruitment screener

The most reliable way to obtain the desired participants is to get them to describe their behaviours rather than relying on their judgment when they respond to the screening questionnaire.  For example, if you want a participant who has a good experience in photography, instead of formulating your questions as:

Question:  Do you have extensive experience in photography?

Choice of answers:

Yes
No

You should formulate your question in a way to make sure the person has some level of familiarity with photography:

Question:  During the last 6 months I have taken:
Choice of answers:
between 20 and 50 photos a month [Recruit]
Less than 20 photos a month [Reject]

By matching potential participants to actual behaviours, you can make a reasonable guess, for example, here, that someone who has been taking 50 photos every months in the last 6 months is indeed competent in photography, whereas when you rely on the person’s own assessment that they have extensive experience, you can’t know for sure that they are using the same criteria as you do to evaluate themselves.

Your screener should be created from a succession of questions representing a reasonable measure of familiarity and competence with the tasks you will test in your software.

That said, your screener should not be too long, as the recruitment agency personnel will probably spend no more than 10 minutes to qualify candidates they are speaking with on the phone.  At the same time though, you need to ensure that you cover questions about all the key tasks that you will ask participants to perform during the test.

Summing up

Let me sum up the basics I’ve just covered by showing you the requirements I have in my screener for testing the ease of use of Unity by the general public user, not necessarily familiar with Ubuntu. They include that:

  1. there should be a mix of males and females;
  2. there should be a variety of ages;
  3. participants should not have participated in more than 5 market research efforts (because people who regularly participate in market research might not be as candid as others would be);
  4. there should be a mix of Windows, Mac and Ubuntu users;
  5. participants should:
    • have broadband at home (being an indicator of interest in and use of computer during personal time);
    • spend 10 hours or more per week on computer for personal reasons (which shows engagement with activities on computer);
    • be comfortable with the computer, or be a techy user;
    • use 2 monitors on a daily basis (I want to test our new multi-monitor design) to carry out a variety of activities online (part of the designs I want to test relate to managing documents, photos, music, and so forth and  I want my participants to be familiar with these activities already);
    • use alt-tab to navigate between applications and documents (another feature I intend to test for usability);
    • have a general interest in technologies (I want to make sure that their attitude towards new technologies is positive, so they are open naturally to our design);
    • express ideas and thoughts clearly.

 

In closing let me add that testing with friends and relatives is very difficult at many levels.  First, you can’t ask all the questions you need to:  there are many ‘common understandings’ that prevent the moderator from asking ‘basic/evident/challenging’ questions that might need to be asked to participants. Second, participants might not be sincere or candid about their experience:  someone who knows you and understands your commitment to the software might not express what they think, and they may not identify problems they are experiencing and thus, they might minimise the impact of a usability issue or even take the blame for it.  Third, of course, they might not fit as precisely as they should the recruitment screener.

Feel free to use this screener to recruit participants if you would like to conduct testing sessions along with the ones I will be doing at Canonical.

In a couple of days, I will write a blog post about writing the protocol for this round of testing  – which is the next step you’ll need to take while you’re waiting for participants to be recruited.

Read more
Paul Sladen

Back in 2008 Nick Ellery noticed that the default printer test page used more ink that it really needed to: Bug #298935 (“test print uses far too much ink”). Millions and millions of these pages get printed every year, so any saving in ink will be amplified. In addition, it still had the pre-2010 Ubuntu logomark: Bug #933489 (“Ubuntu Printer test page has old branding”). Hopefully, the ink saving will help save the planet and everyone will benefit from something slightly prettier.

Scan of new Ubuntu 12.04 Printer Test Page. The design is scaled to fit any size, not just A4 and US-Letter

With the first Ubuntu 12.04 Beta release now out and having been in prepartion over the last fortnight, there’s been a chance to look over and see if the Design Team can assist with reponding to any bugs that might have been missed for too long.

One year ago there were a number of good suggestions for making the test printouts to be more reusable, for instance by including a calendar or origami shape and would be good to incorporate in the future. Perhaps you can come up with a good design and suggest it for the next release cycle building up to Ubuntu 12.10?

Thank you to Lucas Camargo for experimenting with thinning the previous template. To Emily Maher on the design team for working on a more compact circular design that matches the rest of Ubuntu (and should use even less ink). And to Lars Ubernickel and Till Kamppeter for writing and uploading the new bannertopdf support code that pulls in the design and sends it out to the printer with debugging information appended.

Read more
Stewart Wilson

For the multi-monitor design project, we have been making use of prototypes to develop and test some of the finer interactions of the system. One such crucial element is the reveal of the Launcher, particularly as we are exploring having a Launcher on each display. The motivation for making the Launcher available from any display is to allow the user to launch and switch applications, without having to travel onto another display to do so.

So, here is a prototype for the Launcher reveal, which we would like to share and get some feedback on.
 
 

Download the prototype application and source code

It is worth pointing out that this prototype concentrates on the detailed interactions for the Launcher reveal only. This is not the more fully featured multi-monitor prototype, mentioned in a previous post (first shown at the October 2011 USD), which will be shared a little further down the line.
 
 

Launcher Reveal Considerations

With a Launcher available on each display, we have chosen to hold the cursor briefly at the edge of any display which does not sit on the left-most edge of the extended desktop, allowing the user to push against the edge to reveal the Launcher. Important considerations here are:

  • The Launcher reveal must be reliable and easy to achieve when required
  • The Launcher reveal must not be too sensitive: there is already an issue with false positives for the reveal, when targeting items near the left edge of the screen (eg. the browser Back button)
  • The user should be able to pass quickly and easily onto the display to the left – they will not always be looking for a Launcher reveal.
  • Related to the previous point, if a user overshoots onto a display to the right (when targeting items such as scrollbars on the far right of a left-located display), it should be quick and easy for them to correct their position back onto the other display.
 

Running the Prototype

The prototype is a C++ Qt application. Download the archive and unpack it. You may be able to launch the application by just double-clicking on it. If this doesn’t work, you will need to launch the executable from the terminal. The steps are as follows:

  • Unpack the downloaded archive to a suitable location. In this example, we unpack onto the Desktop.
  • Open the LauncherReveal folder on the Desktop and try double-clicking the LauncherReveal executable to launch it.
  • If this doesn’t work, launch the Terminal application.
  • Type ‘cd Desktop/RevealLauncher’ to change to the directory which contains the executable (replace ‘Desktop’ with the directory you have unpacked the archive contents into if necessary)
  • Type ‘sudo ./LauncherReveal’ to launch the executable. To grant permission for the system to run the executable, you will then be prompted to enter your login password.

We have used quite a low-level language and framework for the prototype because it needs to create windows across multiple displays and to manipulate the position of the mouse cursor.

You can run the prototype on a PC with a single display, and try out the Launcher reveal. However, the prototype really becomes interesting when you run it with more than one display attached, and check out the Launcher reveal across all displays.

This prototype concentrates on the Launcher reveal only, so there are lots of things (windows, top bar) which do nothing. The prototype will only work properly for multiple displays with the same height, organised in a row. Being a prototype, this is essentially throw away code, which lives just to explore a very specific set of interactions, for a limited configuration of hardware.

In order to reveal the Launcher, you push the cursor into the left edge of a display for a fraction of a second (100ms by default). This works on any display (not just the far-left display), as we hold the cursor at the edge of a display when it crosses from either the left or right. Push a little more (a further 150ms by default) and the cursor will break through onto the next display.

The images of the browser window are used to test for false positives and overshooting problems when trying to target the Back button on the far left, and the vertical scrollbar on the far right.

 

Tuning the Parameters

You will notice a panel with lots of parameters to tweak. We have chosen defaults which work well for the small sample of people and hardware we have tested the prototype with so far – informal ad-hoc testing at this stage. Here is an explanation of each parameter and the trade-offs they represent:

Launcher reveal: push for 100 ms
The length of time the user must push against the left edge of the display to reveal the Launcher. For lower values, you get a more responsive-feeling Launcher, but you also get more unwanted reveals when targeting items on the left of the display (eg. the browser back button). Try tuning this value up to 200ms for less unwanted reveals, but you’ll need to push a little harder for those reveals that you want.

Pass display edge: push for 150 ms
Once the Launcher has revealed, we don’t want the cursor to break straight onto the next display, so we continue to hold the cursor for a little more time on a left-most edge. This gives the user the opportunity to stop pushing and move to target a Launcher icon. Lower values make it easier to move from one screen to another, but more likely that you will break though onto the next display when you wish to target something in the Launcher.

Event sampling period: 50 ms
The event sampling period is the size of the time-slices which are used to determine when the user has stopped pushing. A time-slice which collects no mouse events will result in an ‘end-of-push’ condition, cancelling a Launcher reveal or movement across a display edge. Lower values will increase the chances of an unwanted ‘end-of-push’ condition (for gentler pushes or older hardware). This period must be large enough to divide the previous time values into multiple time-slices, otherwise they just degrade into timer delays.

Cursor travels freely after crossing display edges for 1000ms
In order to allow the user to quickly correct an overshoot onto another display (when targeting items to the left or right extremities of a display), we temporarily drop the hold-at-edge behaviour once the cursor crosses an edge. Lower values give the user less time to make any corrections, but making this value too large results in missed edge-holds and Launcher reveals.

Cursor travels freely at velocities over 1000000 pixels/sec
In the prototype, we have prioritised easy, predictable Launcher reveals over travelling very quickly across the extended desktop. The user can still travel across the desktop fairly quickly, although they will be detained for a fraction of a second at any edges in the way. If you want to try out an alternative prioritisation (quick travel across the extended desktop, requiring a slower, more careful and deliberate targeting of the edge for a Launcher reveal), then drop this value down from the very high default value (which effectively disables this feature), to something in the region of 2000-5000 pixels/sec.

Hold cursor at right edge of displays (true)
We found that symmetric behaviour, with respect to holding the cursor on display edges, feels more natural, and also makes it easier to target items near the right edge of a display. However, this feature can be disabled, in order to evaluate whether less intervention on cursor movement might be preferable.

Show Launcher proximity shadow (true)
A shadow will appear at the left edge of a display to improve the discoverability and feedback for the Launcher. It grows out as the cursor approaches the edge, and then grows further still when the user pushes against the edge, providing feedback that the push is being recognised and the Launcher is about to reveal.

 

How It Works

You can check out how the prototype works by looking at the source code. If you know some C++ and Qt, you should hopefully be able to make some sense of it.

Fundamental to the interactions here, is the ability to determine when the user starts to push against an edge, and when they stop. We measure the duration of the push to see if we should reveal the Launcher or let the cursor through onto the next display. It is straightforward to determine when the push starts: we identify the first mouse move event which crosses a display edge. But how to determine when the push ends is more difficult. Jason Smith, on the DX team, came up with the neat solution of splitting the entire duration of the push into smaller time slices. For each time slice, we count the number of mouse move events coming in. As soon as a time slice expires which has collected no mouse events, then we have the end of our ‘push’.

Read more
Stewart Wilson

Over the past few months we have been working on improving the multi-monitor experience in Ubuntu. We took the opportunity at UDS in November to get some feedback on a prototype, which shows how we are planning to develop the multi-monitor experience over the next few cycles:

Here is a short video of the prototype in action at UDS:

Multi-monitor prototype at UDS

http://www.youtube.com/watch?v=lbwNMnNUGFA

We invested in a six monitor rig and the prototype to test a number of different display configurations and to ensure that our design ideas scale well. However, our main focus for Precise is to ensure that we deliver a reliable and supportive experience for the core use cases, such as connecting to a second display or projector, disconnecting displays and using a closed laptop with an external display.

So here is the Phase 1 specification, scoped for the next couple of cycles, incorporating the feedback we got from the prototype and sessions at UDS:

http://design.canonical.com/the-toolkit/unity-multi-monitor-interactions/

Work continues now on the prototype, which will be used to conduct usability testing on the launcher, spread, window management and workspace interactions for multiple monitor setups.  We will be publishing the prototype on this site (the Ubuntu prototype application, along with the Qt C++ source code) in the near future, so keep tuned for more Multiple Monitor news.

Read more
Marcus Haslam

Mark Shuttleworth’s keynote this week at the Ubuntu Developer Summit includes introducing Juju, including a big slide showing off the new Juju logo. Below is the story of how that logo it came into being. The Juju project is done. We asked the Juju community to help, and out of out of love for the brand they responded:

Juju logo

Juju was finally released to all the Dev-Ops out there, and so it’s time for a little look back on how the Juju logo come into being. Four months ago in the middle of July 2011 the Design Team received a request for some help with a new logo. This was for a project what was just on the edge of the RADAR and nobody was quite sure how big it would get!

Abi R had a number of ideas for logos, the most interesting where the wavey “magic carpet” designs. After that Robbie introduces some ideas around the letter ‘e’ as the project has still called Ensemble at the time, and Abi had a couple of further goes at developing that into a cuboid concept to go with the atoms. These all got collected up and attached to the bug report that you can read.

Ensemble was about to get a rebrand, to become Juju. Juju is a west-African system of beliefs, and has the ‘u’ sound much more akin to the other ‘Ubuntu’ and “Unity’ words that the family projects working within Ubuntu tend to get. This is when the call went out to the Design blog for some new ideas. Martin Owens did a sun/shield design making use of the circle concept seen in the Ubuntu Circle of Friends, and the other suggestion from “Birdy” was for a concept around a flying bird.

Mark Shuttleworth also suggested something around the topic of “connections”. So with everything in the basket, from Flying Carpets to Flying birds when it was time to sit down and play with the designs. What you can see here is the first concept presented to Mark for review.

This didn’t really have the “connections” aspects (Juju is about magically plugging components together to semi-automatically build a bigger system). The other things that didn’t seem to work was the dots on the ‘j’s in the word ‘juju’, so what you see is a slightly modified version of the Ubuntu Font Family. There’s the circle, there’s the connections, and also the Canonical/Ubuntu “dots” at the joins. It’s spells “juju” in the logo if you unwrap it in the right way, and spells “WW” in morse code!

After all Juju can only do two thirds of the server configuration site to make a website for you, you still have to do the other third! Thanks all for the juju designs. I hope you’ve enjoyed reading about this as much as I enjoyed trying to put everyone’s ideas together into one pot.

To read more about Juju visit juju.ubuntu.com and learn how you can ‘charm’ even the largest cloud or cluster deployments.

Read more
Inayaili León

We’re happy to unveil the brand new Ubuntu App Developer website today, a place where developers who want to create Ubuntu applications can find all the information they need and get in touch with the Ubuntu app developer community to share ideas, ask questions and get all the news and events.

Ubuntu App Developer website homepage
Ubuntu App Developer’s website new homepage

The brief

The goal of this project was to create a website that would centralise the best resources on developing Ubuntu applications; a place where developers could find not only all the tools and information necessary to get started on Ubuntu app development, but also a place where they can be a part of an engaged community of other developers who are equally eager to learn and happy to share their knowledge.

Our timeframe was very limited: just under 10 weeks to plan, research, design and build the site. This, of course, had an impact on what could be created. We spent quite a lot of time scoping down the project, making sure the essential information was included and the site was built in a way that it could grow organically, over time.

Ubuntu Developer Website schedule
Planning the App Developer website

Research

Research is one of the most important parts of creating sites (or, to that matter, anything that people will use). As experienced designers, we can make informed guesses on what people will want to see on a given page, but sometimes people’s expectations can be quite different from our initial thoughts. With this in mind, we knew that even though we spent a few intense weeks sketching, brainstorming, covering the Millbank walls with post-its and wireframes, having day-long workshops and listening to what all the key people in this project had to say, ultimately, we had to put our thoughts in front of the developers we were making this site for. And so we did.

Ubuntu App Developer site wireframe
One of the many sketches that were done

John Oxton, the Web Team’s UX architect, as someone more qualified to go through this phase, will write a more detailed follow-up post that will focus mainly on the research phase of the App Developer site, the tools used, the main findings, the solutions, etc.

The brand, from a developer’s perspective

The Ubuntu App Developer website is part of the main Ubuntu family of websites. With this in mind, we had to make sure it adhered very closely to the Ubuntu brand guidelines. But we also wanted it to have a life of its own, so that it wouldn’t just be a copy of ubuntu.com.

One of the key assets of the Ubuntu brand guidelines are the Voice, Audience and Developer sliders, which are a tool in understanding what the design direction of any product should be, whether it is a banner, a brochure, a cd cover, a site, etc.

Ubuntu brand guidelines slides page
One of the detailed pages on the sliders in the Ubuntu brand guidelines

Here’s a quick overview of the sliders:

  • The Voice slider determines whether a piece is representative of the Ubuntu community or if it’s representative of Canonical. This doesn’t reflect the position of the person creating the work, but of the work itself.
  • The Audience slider determines the type of user you are talking to. The work can be consumer- or enterprise-oriented.
  • The Developer slider determines whether the work is targeted towards end-users or developers. In this case, an advanced user would still not be a developer.

If you’re creating design assets for Ubuntu, you should be familiar with these: have a read of the guidelines as they go into a lot more detail, and do get in touch if you have any questions!

After talking to the stakeholders of this project, we were able to position the sliders as follows:

  • Voice: Community
  • Audience: Consumer
  • Developer: Developer

This was the first time we created a website that was so directly targeted at developers. A brand is something that evolves over time, and this was a great opportunity to evolve the Ubuntu brand in this direction and to explore a new area of the guidelines that hadn’t been looked at in depth before.

Ubuntu App Developer design direction sketches
Some quick notes and sketches exploring the design direction for the site

We wanted to create something that conveyed the idea of blueprints. This led to a design that makes use of outlines, widely spaced dots and that is clean and direct.

Ubuntu App Developer website's navigation detail
The App Developer’s site navigation follows closely the one of the main Ubuntu sites, with its own flavour

Ubuntu App Developer site's box detail
Detail of one of the reusable components of the App Developer’s site

Second round of testing

Trying to get as much feedback from our target users as possible, we showed a more finalised site to a few more developers. Again, John will write about the research side of this project in more detail soon, here on the blog.

The road ahead

This project was a highly rewarding and highly intense team effort. Everyone worked incredibly hard, but we had a lot of fun. Too many great ideas for the site had to be put aside for the future, as our time was so constrained, but rest assured all these were captured in a very exciting roadmap.

The website is now in the hands of the fantastic Ubuntu App Developer community and the Canonical Community Team, and we hope to see it grow with lots of content created by anyone who would like to contribute. Have a look at the site and tell all your friends about it! We’d love to hear your thoughts.

Read more
Paul Sladen

UbuntuBetaArabicF in print,

A beta of Ubuntu Font Family Arabic, in print as part of the testing and debugging process for the Arabic coverage. The Arabic script support will cover Arabic, Urdu, Pashto, Kashmiri and other written languages using the base Arabic script.

The magazine is an intriguing tri-lingual production published by the Cultural Office of Saudi Arabia in Germany with the layout prepared by Professor Rayan Abdullah’s team at Markenbau. The magazine starts with German and English articles using Latin script at one cover (reading left-to-right) and articles written in Arabic from the other cover (reading right-to-left).

Ubuntu Arabic, now has horizontal, instead of diagonal dots

Following on from the recent posts about adding Kashmiri/Pashto ringed characters and the Arabic update from the start of 2011, the most significant change to highlight is the that the diagonal dots (?i???m / ??????) have been changed to a horizontal layout.

The resulting arrangement is now closer to an equilateral triangle, and the dots closer to a circle.

(Thank you to Abdallah, Björn Ali Göransson, Chamfay, Masoud, Muhammad Negm, Nizarus, Reda Lazr and others who each took the time to comment and give feedback about the earlier diagonal dot angle).

Read more
Paul Sladen

It’s been five years since people spotted the last Ubuntu billboards in the wild. This time Mauricio Pretto sent a set of photographs of driving between the airport in Porto Alegre, Brazil and the Fórum Internacional Software Livre (International Free Software Forum) venue where Canonical and Ubuntu have a stand for FISL 2011:
Venha visitar a Canonical e conhecer as novidades do Ubuntu
Designing for a surface 7 metres × 3.6 metres is a little different than for on-screen or a brochure, especially as the Ubuntu/Canonical Brand Guidelines don’t have a dedicated section for billboards yet! The design here was originally sketched by David Cotter for the Computex Show, and updated by Emily Maher for the FISL request.

Mauricio noted that the billboard guides people to “Come visit Canonical and learn more about Ubuntu” in Portuguese:

Venha visitar a Canonical e conhecer as novidades do ubuntu!

FISL, Centro de Eventos da PUC, de 29 Junho até 2 Julho

Emily gave a bit of background about the further work that needs exploring before the brand guidelines (they are guidelines after all, not hard policy) can be extended to cover super large formats:

I had been discussing this with Marcus Haslam, the Lead Brand Designer at Canonical … we want to work a few more things out before creating a dedicated piece in the guidelines and we need to make some adjustments, for example, the large format dots do not translate well on to such a large format. The dots were almost invisible when viewed from below, so we need to run some more tests at various sizes of the dots next to text and get proofs so we know how best to advise people.

Emily felt it was perhaps a little soon to lay down definite guidelines; but on the branding side the guidelines still translate, with the photograph angle, colours and border-style still applying directly.

Has anyone in Brazil spotted the billboards yet, or would you like to see billboard templates covered as part of the resources in the The Brand Toolkit?

Read more
Inayaili León

We all know Ubuntu is great, but we want even more people to know just how great. With this in mind, we thought we’d give the visitors of ubuntu.com the tools to spread the word about Ubuntu.

As of today, you can see Tweet and Like buttons on some of the key pages of the website, such as Ubuntu for you, the Features pages, or the Download page.

Sharing features on Ubuntu for you page

This is the first step towards something bigger. In the pipeline are the introduction of more ways of sharing the Ubuntu message with friends, family and (why not?) your entire social network. For now, we’ve focused on the two most popular services.

Sharing a page from ubuntu.com on Twitter
Sharing your favourite pages of the Ubuntu website on Twitter is a breeze. Before tweeting, you can customise your message too.

We’d love to get your feedback, hear your suggestions, and know your ideas on how you can tell the world just how lovely Ubuntu is. As an Ubuntu lover and active member of the community, what tools do you think would help you and be most valuable in sharing your experience of Ubuntu?

Finally, if you love Ubuntu, help us spread the word: visit ubuntu.com and share those links with as many people as you can!

Read more