Canonical Voices

Posts tagged with 'education'

Paul Sladen

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:

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.

Read more
Paul Sladen

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

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  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 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 or “Upstream projects that can be worked on” at .  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 , 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 .


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
Paul Sladen

Ispravka ?irili?nog fonta «?» «? ? ? ?» «? ? ? ?»!
????? ?????? ??? «?»:

Amélie Bonet at Dalton Maag has drawn up redesigns for a number of the Cyrillic and Serbian/Balkans characters that weren’t as clear, or ideal as they could have been. If you use these characters, please help give feedback about whether the suggested improvements are sufficient, or whether they could be improved further. For Greek, there is also a proposed fix to monospace Gamma:

Many appreciations to those who reported the original bugs about the Ubuntu Font Family. We have tried to follow up to the original reports at Blog Russia and at (thank you to ????????? ???????? and also all those on the #ubuntu-rs IRC channel.

Please comment directly on the bug reports. You can use your own language if it is easier (eg. Russian, Serbian, English, Greek…). ??????? ???????!

Read more
Paul Sladen

To celebrate Software Freedom Day 2011 we got sent one of the banners showing the new SFD logo. The logo design is based around a custom-modified version of the Ubuntu Font Family (the fonts come with source code, and modification is allowed as long as you follow the rules).

There are some photographs showing the development of the logo components, and how it even includes the subtle outline of Tux the penguin, the mascot of the Linux kernel that forms the base layer of the Ubuntu operating system and other Free Software distributions.

Frederic Muller has added more details are on bug #838287, and there’s a case study of the modifications changed from Ubuntu Bold Italic when making the Software Freedom Day logo. Photos from SFD2011 events around the world are starting to appear on Flickr.

Marcus Haslam, brand lead for the Ubuntu project reminds everyone that if you’re representing the Ubuntu brand itself, you must only use an unmodified version of the Ubuntu typeface. This is to keep consistency across the brand.

Read more
Paul Sladen

The BBC just put up a five-minute audio slideshow “The story of how we got our alphabets” about the development of western writing, starting in 3,000 BC in Mesopotamia with various attempts at proto-writing systems and then Cuneiform script.

It shows the history of the alphabet, stemming from the Phoenician alphabet and continuing to the Semitic alphabets based around consonants (Arabic and Hebrew) and those derived further via Greek and its addition of vowel sounds (Latin and Cyrillic).

With the development of the Ubuntu Font Family we’re getting to the stage where it’s possible to demonstrate some the similarity using the font itself. The diagram on the right shows Hebrew on the left, Arabic on the right and Greek, Cyrillic and Latin in the centre columns. As Dr James Clackson notes in the slideshow, things are fairly consistent up until T/?/?, after which the additions and expansions of letters diverge in each alphabet system.

The term Alphabet comes from the first two letters in the Greek—and other similar—alphabets: ??, ??, AB, ??, ??.

The diagram in this first cut can likely be improved with input from a knowledgeable linguist/palaeolinguist. Please get in contact, or leave suggestions and corrections below if you know how to improve it!

Read more
Jeremy Foshee

On Saturday September 11th the Kernel Team will take the first in what I hope to be a series of steps toward educating ourselves and our community in the triage of the thousands of bugs that pass our way daily.

My goal for this event is to begin the process of training those interested in helping with kernel bugs in the way we process our bug tickets. This first event is meant to help us both educate and document. The information on the first ever Triage Summit is located on the wiki here.

As with everything we do, your feedback is appreciated. Please don’t hesitate to send us e-mail to the team list at or even on the wiki page itself. Your feedback will go a long way toward our plans for future events like this.

The schedule for Saturday is as follows:

1) at 1400 UTC we will hold a General session centered around providing information as to where to locate us, who our upstreams are and where to find them as well as the new subsystem breakdown of bugs to help us gather related issues more easily and get them in front of the right people.

2) at 1500 UTC there will be a session on Graphics and all of its related bits and bytes. There will be a focus on basic, effective triage for this subset as well as locations to find troubleshooting information and further reading on Graphics issues

3) at 1600 UTC there will be a session on audio bugs and the related subsystem parts involved there. This session will also have a basic troubleshooting and location portion so as to guide those interested in triaging audio bugs with further information.

4) at 1700 UTC we will have something of a lightning round in which we briefly discuss the USB/Firewire and Bluetooth stacks as well as helpful debugging and triage steps for this subset of bugs

As stated before, your feedback on these sessions as well as the documentation that will be provided will be most helpful to us. You are also welcome to approach us for other avenues of support. We are always looking for more help on a variety of kernel related areas such as documentation, bugs and spelling/grammar applications :-) so please don’t hesitate to ask how you can help.

I look forward to seeing a great many of you at the Summit on Saturday!


Read more