Canonical Voices

Posts tagged with 'communication'

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
John Lea

How is Unity designed?  How can I contribute to this process?  Why did you make thus and such decision? The Unity Design Team is frequently asked these questions, and this article aims to de-mystify our design process and highlight the different ways in which volunteer contributions can help improve the Ubuntu user experience.

Before diving into the design process, let’s take a look at the types of contributions Ubuntu receives.  Ubuntu contributions can be divided into two equally valuable categories: whole project contributions and piecemeal contributions.

Whole project contributions are autonomous projects created by a single developer or a group of community developers and designers working together.  One example of such a project is the excellent http://ubuntu-tweak.com.  Some user experience design tasks require frequent ongoing high bandwidth dialogue between design team members; this is easier to achieve when a small group of contributors take responsibility for the end to end delivery of a project.  Whole project contributions empower the project contributors to take complete control of all aspects of the user experience design.

Piecemeal contributions are contributions that help one individual aspect of a larger project.  Examples of piecemeal contributions include bug reports, small patches and suggestions on how to improve public design specifications.  Coordination is required to ensure that the piecemeal contributions fit together into a coherent whole.  Thus some of the user experience responsibility is ceded from individual piecemeal contributors to the project’s steering team.  In the case of the Ubuntu desktop, the design decisions are coordinated by the Unity Design Team.  In this environment, many elements are contributed by external designers and developers, but the areas of user experience design that require high bandwidth, frequent communication are dealt with by the Unity Design Team.

 


1. Divining the future

Before we get started on designing anything, we need a long term vision and strategy of where we want to be in several years time, and a high level roadmap of what we need to do in order to get there.  My personal take on the Ubuntu vision is that Ubuntu aims to “help humanity by creating a fully open source free software platform that becomes the platform of choice for all computing devices and form factors”.  By virtue of reading this article you are probably one of the small minority of the population who cares and feels passionately about the benefits of open source computing.  But when the majority of people consider buying or using a product, they make a decision based on cost, personal utility, and user experience.  ‘Open source’ versus ‘closed proprietary software’ doesn’t often come into the equation.  So if we are going to succeed in making Ubuntu the platform of choice for the world, one of the things we need to do is deliver a user experience that surpasses the standard set by our closed source proprietary software competitors.  And to do this we need a vision to aim for, of where the world is going to be in 2, 5, and 10 years time.

To help shape our strategy and roadmap we listen to what the brightest minds are saying by:

  • attending conferences
  • reading articles, blogs and forums
  • watching people’s behaviour
  • reading and watching sci-fi books and films
  • and trying to live observant, interesting lives… ;-)

 

How you can be a visionary and help shape the world

If you have a vision of the future or ideas about new ways of doing things, make yourself heard.  Everything from talks at conferences to ideas posted on http://brainstorm.ubuntu.com/ are thrown into the Ubuntu mixing pot, so if you have a great idea, tell people about it.  The more time invested in exploring your idea and communicating it to the world the more influence it is likely to have; a paper presented by a PHD student who has spent a year exploring a particular topic has a better chance of being influential that one or two forum postings.

 


2. The first step in designing a feature; what problem are we trying to solve?

The development of a feature starts as soon as resource becomes available.  After selecting the next appropriate item from our roadmap, the first questions we ask are “what problem(s) are we trying to solve?” and “what are our objectives?”.  One useful tool to help define the problem is to explore the problem using user narratives, and think about the impact of the problem on different personas (user archetypes which represent patterns of behaviour and common goals).  Another useful tool is to undertake requirements capture with members of the target audience.

 

How you can contribute to defining the problems

If you are suggesting either a new feature or a change to existing functionality, first state the problems you are trying to fix.  This opens the door to exploring different possible solutions, and ultimately finding the optimal way to meet the requirement.  Including user narratives in bug reports/mailing list postings/etc… can open up productive discussions that explore different ways of tackling the problem.  They also make it easier for others to understand the problem you are investigating, and therefore improve the likelihood of a solution being built.

 


3. What thinking has already gone in to trying to solve this problem?

Once the problem that we are trying to solve is clearly defined, the next step is to assemble the previous thinking that has gone into the problem area.  Understanding what has gone before and the current state of the art is the starting point from which new connections can be made, concepts built upon and extended, and new ideas created.  Mailing lists, bug reports, and forums are scoured for pertinent information and products relevant to the problem space are examined.  In addition to the collation of previous thinking, fresh research can also be conducted to generate new insights.  This solid understanding of the existing problem space is a elemental ingredient of the design process.

 

How you can contribute to the background research

If a discussion on a design problem is taking place, either in your own project, in a bug report or on a mailing list, feel free to add pertinent information from related fields or descriptions of how others have tackled related problems.  Throwaway opinions are cheap, but considered  background research is a very valuable contribution.

 


4. Ideation

Ideation requires high bandwidth communication between all participants, both for the rapid expression and debate of ideas, and to ensure that everyone in the multi-disciplinary group rapidly gains and retains a shared understanding of the problem space.  When starting a new project at Canonical, we have found it very beneficial to get all the developers, visual designers, UX architects, etc… who will eventually work on the new feature together in a single physical location and spend a week brainstorming and exploring ideas.  In addition, these design exploration sessions help gel the feature team together, and the interpersonal bonds that are established improve team communication and set a positive tone of discourse that persists throughout the entire course of the project.

During these ideation sessions, we:

  • Spread out all gathered information and explore patterns and structures.
  • Jointly brainstorm and sketch ideas.
  • Discuss all areas of the problem space, propose and iterate multiple ideas for tackling all the different aspects of the problem.
  • Examine the problem from different angles; user costs and benefits, technical possibilities, strategic direction, competitive landscape, fit with roadmap, etc…

At the end of this stage we will have a collection of ideas for solving the problem.  And this collection of ideas will have been discussed and examined by the whole feature team.

 

How you can participate in ideation

At a small scale you can make piecemeal contributions to ideation by participating in bug report discussions and offering different ideas for solving the problem.  As a larger scale you can get involved in ideation by joining or starting a community project team that is focused on delivering a feature.  Propose an idea, gather some developers and designers together, and start your design process!

 


5. User Experience design

User Experience design starts with the ideas generated in ideation, and through an iterative process evolves the concepts and fleshes out the interaction details.  Typically a UX architect will take the lead on designing a feature, and as they work through this process they will continually bounce ideas off other members of the feature team and other designers.   User testing is also utilised to provide feedback and inform the evolution of the design.   The UX architect’s work will also be reviewed with the overall UX lead to ensure consistency and linkage with all the other projects that are being designed and developed in parallel.

User Experience architects have a number of tools at their disposal for designing and defining the functionality of a feature or product.   Multiple tools are used simultaneously in order to approach the design from different perspectives; for example wireframes show grouping and hierarchy of elements at a specific moment in time, so they are frequently combined with use cases or sequence diagrams to ensure that the user journey centric viewpoint is also considered.

For very tactile and interactive elements, designing through prototype iteration is an invaluable technique.  An example of this in action is the recently released launcher reveal prototype.   In addition to defining the functionality, user experience design also involves taxonomy, association mapping, and personas.

 

How you can participate in User Experience design

As user experience design builds on top of steps 1-4,  before starting the first task is to make sure these preparation steps are complete.  In the case of adding a piecemeal UX design contribution to a bug, this involves reviewing the bug discussion and satisfying yourself that these preparation steps have been adequately completed.  If you are working on a whole project, make sure that all the previous steps have been conducted jointly with the other members of the project team.

Then start designing!  Look at design patterns that can be utilised, and keep an open mind by looking at mobile and web patterns in addition to established desktop design patterns.  Some good starting points are ‘About Face 3: The Essentials of Interaction Design’ by Alan Cooper, ‘Designing Interfaces’ by Jenifer Tidwell and also the pttrns mobile app design pattern showcase.  Approach the design from different perspectives; to learn more about the mechanics of using use cases to take a user journey centric approach I recommend the excellent ‘Writing Effective Use Cases’ book by Alistar Cockburn.  And keep looking at the design through the eyes of the personas you are targeting, otherwise you may end up designing the product just for yourself!

The artifacts you produce will vary depending on the projects requirements, but should include at the very least elements of layout design (wireframing), functional design (use cases, prototypes, etc…) and Information Architecture (hierarchy maps).

 


6. Visual design

Visual design is the marrying of form and function, it affects user confidence and comfort and makes for a compelling experience.  As we work through each level of the design process, we are both iterating the design and adding further detail.  We start with coarse brushes making wide strokes and work our way to the point where we are using fine brushes to refine the final intricate attributes.  Human beings perceive visual information before they perceive analytical information, and Visual design is about reducing the mental workload for our audience whilst delivering a delightful and cohesive aesthetic experience.

 

How you can participate in Visual design

If you are working on a whole project contribution, fire up your design programs of choice and start iterating the visual design!  For piecemeal contributions a great place to start is theme, icon and wallpaper design.  For a good example of a great community visual design contribution take a look at the Faenza icon theme by ~tiheum.

 


7. Implementation

Development resource is the biggest bottleneck to getting new features implemented, so the most valuable way you can make piecemeal contributions is by taking items from the bug list and submitting patches.  Implementation is also part of the design process, because as a feature is built even more understanding is gained and further refinements are iterated.

 

How you can participate in implementing new features and fixes

Pick a bug from underneath either the “Design changes signed off but not handed over” header at http://people.canonical.com/~platform/design/ or “Upstream projects that can be worked on” at http://people.canonical.com/~platform/design/upstream.html .  If you have any questions about a bug ping either myself (JohnLea), swilson, or nuthinking in #unity-design on Freenode IRC .  The Ubuntu wiki Unity page is good place to start finding out more about how you can help with the implementation of Unity.

 


8. Identifying user facing bugs and QA

After a feature lands it is time to start identifying bugs.  A good starting point is to look at the UX specification of a feature, and check that the implementation matches design.  Where there is a divergence, citing the relevant part of the specification in the bug report is both useful and will also raise the bug’s priority.  On the other hand, designs are never perfect and it may be that there is a bug with the design itself.  In this case it is also useful to cite the issue in the relevant UX specification as part of the bug report.  Unity UX specifications are available at http://design.canonical.com/the-toolkit/ , and we are currently working to increase the number of specifications that are publicly available.  Also all the design bugs that are currently queued for implementation are publicly available at underneath the “Upstream projects that can be worked on” header at http://people.canonical.com/~platform/design/upstream.html .

 

How you can participate by reporting bugs

If you are reporting a user facing bug affecting any part of Ubuntu, make sure the bug is marked as ‘also affects project’ ayatana-design.  The bug will then be triaged by the Unity design team, and if accepted it will enter the stack of bugs that are awaiting implementation.  Sometimes a bug will be marked as ‘Opinion’.   This means that the issue is acknowledged but the exact change request detailed in the bug is not currently scheduled for implementation.  This may be because further consideration is required, or because a project that will fix the bug in a different way is currently in the pipline.  Bug reports are one of the most useful ways you can contribute, every single bug that is reported to ayatana-design is reviewed by the Unity design team.

 


9. User testing

This will be coming soon in a subsequent article…

Read more
Inayaili León

If you’ve ever had to create Ubuntu or Canonical related design materials, chances are you had a look at the Brand Guidelines, which, until now, have only existed in the form of bulky PDFs. Those days are over, as we happily introduce the brand new Ubuntu Brand Guidelines site, where you can read the guidelines and download the assets necessary to create your projects.

Ubuntu Brand Guidelines homepage
Ubuntu Brand Guidelines homepage

You can learn more about the Ubuntu brand values and the brand assets, such as our logos, colour palette and pictograms, and how to use them. You can also consult some of our Web-specific guidelines, look at examples of design work that has been done, and download assets like the logos and pictograms.

Ubuntu Brand Guidelines - Brand assets section
Brand assets section on the Brand Guidelines site

This is the first iteration of the site: lots of content is being prepared and will be added later on, and we will also work on some refinements to the asset download process, as well as adding many more useful downloads, such as templates and photography.

Among the more frequently requested assets are HTML and CSS snippets and templates that can simply be copied and pasted on internal and external projects, so the designer or developer can be certain everything looks as it should. This is in the works, but it’s something that takes a little bit more time to get just right, so please bear with us.

For now, we’d be delighted to get your feedback on this first version: have you found anything particularly useful on the site? What would you like to see there that you think it’s missing? How do you think it can be improved?

We hope we enjoy the online Ubuntu Brand Guidelines!

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

Big thanks to everyone who turned up at the Ubuntu Developer Summit in Orlando to discuss Ubuntu’s future on new devices!

Now, following Mark Shuttleworth’s keynote announcement and a number of initial UDS sessions on tablets, TVs and smartphones, we are setting up new channels to pick up the conversation.

We’ve got three new mailing lists for everyone to participate in. Just follow these links and sign up (click ”Join the team” on the right-hand side):

See also our previous post: Getting in touch with us

Read more
Christian Giordano

Getting in touch with us

During the past UDS’ we have been repeatedly asked a better way to be reached. There are many reasons why a community member could feel the need of contacting us, and we are more than happy to hear and help if possible!

As follow up we are looking into restructuring our communication channels so that there will be a clear way to approach us based on the topic or support required. This might require some weeks and you will be promptly notified when this will take place.

For the time being, we are committed to be present in a room that the community appropriately created on irc.freenode.net. Feel free to join the #ubuntu-design channel if you need to ping any of the Design Team! You can see our IRC nicknames from the team page (just keep in mind that most of us live in the GMT+0 timezone).

Talk to you soon!

Read more