Growing Our Design Community

As we build towards to the next Ubuntu Developer Summit in a few weeks, we have been getting our blueprints and plans in place to have a comprehensive set of discussions at the event. Unfortunately I won’t be there, fortunately due to an impending bundle of baby joy that will be entering my life, but I will be remotely participating. Be sure to join us there, there is no excuse, people. :-)

As part of these plans I have been having some wonderful discussions with Ivo Weevers who is the head of the Canonical design team and who reports directly to Mark Shuttleworth. Ivo is passionate about helping the design team at Canonical and the community to work closely together, and we have been discussing what problems we need to solve, and how to resolve them. In the past there have been concerns in the community that it is difficult for our community to actively participate in design and Ivo and I are keen to solve these challenges.

There are many topics to be discussed and we are currently fleshing out the schedule for UDS, but I am keen to solicit feedback about one particular piece of this puzzle.

Thankfully we are not trying to figure out the puzzle of opening one of these instruments of frustration.

As many of you will know, Ubuntu is a meritocracy; when people do great work, they have more influence over the project. As an example, our developers who work hard and become approved core-dev or MOTU contributors have more influence over our development operations than those who have not put in this level of development work. Now, before the haters start hatin’, I agree that Ubuntu is not a perfect meritocracy in that some Canonical staff members have direct influence over Ubuntu in a way that the community are unable to contribute. Examples of this include our infrastructure and systems teams, and to a degree this also includes the design team.

In a world in which everyone has a strong opinion about design, I believe that part of solving this challenge is that we need a means in which we can highlight the great designers from not-so-good designers. To be clear, this does not necessarily mean designers who agree with the Canonical design team, but instead designers who are collaborative, talented, contribute significant and sustained work, and bring their expertise forward to improve Ubuntu…the very same criteria we use to judge other areas of expertise in the project.

In the development world we have a pretty well defined way of assessing the cream of the development crop while still providing an opportunity for everyone to be able to ascend and aspire to that level of quality. We have methods of contributing that can build up a body of work that can then be reviewed and direct upload rights can be granted when the quality requirements are met. To do this we have the following:

  1. A clear definition of things that prospective developers can do.
  2. A simple means in which non-uploaders can contribute their work.
  3. Criteria that we can use to assess the quality of this body of work (e.g. technical quality, effectively following our guidelines and principles, providing a significant and sustained body of work etc).

I was chatting to Ivo about this and we would like to define the same three equivalent attributes for the design part of Ubuntu. Namely, we need to be able to point to things that people can do, have a means of reviewing this work effectively, and importantly, define criteria of what makes a great designer. I would propose that we apply these assessments to create an equivalent to core-dev in the development team but for designers. This way everyone can contribute more widely, but we can have a team of reliable, effective, community contributors that works closely with the Canonical design team and a clear means in which anyone can learn how to gain the skills to join this team.

I wanted to open up this discussion to the community to get your feedback and then we can review the feedback and discuss it at UDS and then start formulating a plan for the 13.04 cycle. In putting forward your suggestions, please bear in mind that we need to make the solution light-weight for everyone involved, both new contributors and those who will be reviewing the work of others.

  • Martin Owens

    I’ve sent you an email with my advice.

  • Nicu Buculei

    A great designer is someone who: - design things people want to use and make them more productive; - work well with those around: other designers, developers, QA. etc.; - ca swallow his pride and accept feedback, improve his work based on that. If you want to add community contributors, the most important thing is for them to be good team players and wanting to learn – this is the bazaar, not the cathedral where you use primadonna designers.

  • Alan Bell

    I think there needs to be a shift towards more functional design. A change from artists to architects. Several of the klunky things on the desktops are as a result of striving to achieve a cosmetic picture (trough behind window buttons, top bar shadow) rather than the natural result of a beautiful architecture. I am thinking things like NeXTSTEP, BeOS, RiskOS, QNX as examples of architected systems. The other big thing I would like incorporated in the Canonical design process is accessibility. It is massively easier and quicker to design the transcript of what a screen reader should narrate when interacting with software than it is to draw graphical storyboards – but this isn’t part of the process so doesn’t get done.

  • Jasna Ben?i?

    This is awesome that you wrote a post about design.. It would be great if design team would be more open like development team on social networks…That way people who are not in Canonical nor community yet, would have an easier entrance to Ubuntu world of contribution. Ubuntu devs and you give a lot of chances and calls for volunteers to join up. So, it would be great that design team does the same (and other teams which are not so open like you and dev team). I hope people won’t get me wrong. This open approach via social networks brought me into Ubuntu world of “contributing” for which I hope it will be bigger.

  • Anders Feder

    I agree a lot with what Alan Bell said. There has been too much room in the current Ubuntu UI for artists come up with something for the occasion, leading to a in my humble opinion quite nasty patchwork of styles and intents. Good design should be made up for the occasion but rather flow naturally from the underlying architecture.

  • Aidan Delaney

    You could have a look at how the gnome design team make themselves quite open. They have a well-maintained wiki (https://live.gnome.org/Design) and their UI mockups are available to anyone to implement (https://github.com/gnome-design-team). The HIG is, as always, quite important.

    You don’t have to like thir design to see that the process is open (though I personally love the designs).

  • http://twitter.com/davelab6 Dave Crossland

    Please consider publishing the gist of it Martin :)

  • Marcappuccino

    There was a point mentioned somewhere that developers code first, then design. I think developers should find a design that looks good, then build the code around that UI, of course still being functional.

  • Thorsten Wilms

    Assessing the quality of design work requires a context of what is to be achieved, from a global level (the whole project) down to a specific level (a task, tool, interaction bug or whatever the scope of the work may be).

    Keeping track of who does significant and sustained work asks for infrastructure. A wiki is not enough and too expensive (manual labour) in maintenance.

    There are motivations outside of just being a nice, generous person for designers. “May I get a nice portfolio piece out of this?” The negative side of that might make the designer a little autistic, the positive side of it will make the designer a steward of quality and internal consistency. You should plan for it.

  • numpty

    Developers should be decoupling their code from any particular UI design as much as they can, not designing around a specific one. There are all sorts of reasons why, not least that the desktop and mobile UIs for any given app will often be quite different.

  • Felipe Erias

    “we need to be able to point to things that people can do”

    That’s a good question. What do you expect to get out of this?

    Community support for resource-consuming tasks like user testing or fine-tuning visuals? More design ideas for the modules that Canonical maintains? A way to link community designers with upstream for those other modules that Canonical doesn’t maintain? A way to encourage collaboration between designers and community or private software creators?

  • Jay Lane

    This is a good thing!! For sure. Unity can look truly beautiful. I really do think the default icons need a refresh.

    These are a cracking icon set:

    http://www.omgubuntu.co.uk/2012/09/nitrux-umd-gets-updated

    On my desktop:

  • Marcappuccino

    Yes, but this is how we end up with things like the new qt Ubuntu one client

  • Anonymous

    Great feedback, Aidan. Thank-you.

    So it seems like in summary you are suggesting:

    • A wiki outlining how to participate and areas of required design.
    • A repository that anyone can submit UI proposals for the areas of required design.
    • A HIG that keeps designs in-line with the design conventions of the given project.

    Does this sound about right?

  • Anonymous

    Thanks, Alan. Do you have any thoughts on how to more neatly engage accessibility into the design process?

  • Anonymous

    These are great suggestions, but a bit vague. Can I ask a few more details:

    • You say “design things people want to use and make them more productive” – does this mean that great designers only work on the design challenges that affect most users?
    • You say “work well with those around: other designers, developers, QA. etc” – what specifics do you mean by “working well” – what specific characteristics define someone who works well and someone who doesn’t work as well?

    Thanks!

  • Anonymous

    Hi Felipe,

    These are all good questions. Maybe we could sub-divide this into practical areas where people can participate. Some examples could include:

    • User testing and research on existing design proposals.
    • Contributing to foundational design pieces (e.g. the HIG, typography etc).
    • Refinements to existing designs.
    • Creating new design proposals around design-requirements.

    Does this sound about right?

  • Richard Gaskin

    There was a job posting at Canonical for a position which included drafting a HIG for Ubuntu – do you know the status of that? One of my UDS-Q tasks was to summarize that for x-plat devs, but I’ve been unable to turn up info on it thus far. TIA -

  • Marcappuccino

    WT lib through wine?

  • Jay Lane

    Indeed it is Sir and well spotted!! WT works great under Wine 1.4 onward, including the Chinese version. I also use the font aliasing script which make Wine’s fonts look great.

    PM me if you need any help with setup.

    Thx

    J

  • Alan Bell

    sure, when doing storyboarding include along with the pictures, the transcript of what orca should say, and how you should navigate around the user interface in question using the keyboard. This would go for things like the dash, software centre, it would have exposed the problem with the shortcuts overlay earlier and indicators would probably work better.

  • corian

    http://www.imagooo.de free hand coding