See things like: the Ubuntu #reinvent digital campaign, Juju embeddable card and Suru app icon designs.
Follow us :)Read more
We have been using our front end framework Vanilla across our sites for a while now, so it might surprise you to know that its first official version (let’s call it v1) hasn’t yet been released.
In preparation for v1 (which we are tentatively aiming for early September), there are a few tasks that we have been, and will be, working on to make sure that Vanilla is as robust as we can make it, and to make the process of using and improving it clear.
It’s important that long-term, ongoing projects have defined goals that people can focus on and strive for. Having short, mid and long-term goals makes it easier to prioritise and concentrate efforts on tasks that will get you closer to achieving the ultimate vision for the project.
The first thing we did in order to outline a roadmap for Vanilla was to collect all the things that we felt needed to happen for it to be ready for release, things we’d like to improve, and wishlist items that might not be urgent but that we would like to tackle at some point in the future.
With this list at hand, we organised the tasks by priority and added them to a roadmap board in Trello, which is open for anyone to have a look at. You can see which tasks we are working on during the current two-week sprint, and which tasks are queued to be done next.
Releasing Vanilla v1 does not mean that Vanilla will then be finished. As a working style guide that is used across Canonical on various different projects with different needs, new patterns will emerge and existing ones will have to be improved to be more flexible.
We thought that it would be good to document the process that a pattern should follow in order to become a Vanilla pattern, so after a little bit of brainstorming, we created a diagram that shows the different steps that should be taken from before submitting a pattern proposal to its full acceptance as a Vanilla pattern.
Most of the steps in the diagram happen in just a few seconds, but it is good to be able to visualise the entire process.
As Vanilla itself, this process diagram is not really finished. Once we start using it more frequently, we will probably have to make some adjustments to improve it. Also, there are a few branches of the process that we still need to include, namely how a pattern is added to a theme as opposed to the main Vanilla framework, and how an existing pattern (in a website of Vanilla theme) can be promoted to Vanilla.
As part of this task, we also updated the existing GitHub template that pops up when you submit a new issue on the Vanilla repository to include the option of submitting a pattern proposal.
The proposals will be reviewed on a fortnightly basis by the web team during the Vanilla working group meetings. We are pondering how we can make these meetings open to anyone who’d like to participate, as we know that lots of you would like to contribute with new patterns and improvements. We’d be happy to hear your ideas on how this could work.
While internally, in the web team, we tend to agree on and follow consistent browser support guidelines, the process isn’t documented.
We want to make sure that Vanilla is built following the latest web standards, and that people can build sites with it that will work on as many form factors as possible, so we thought defining the browser support guidelines that we want contributors to follow was a vital step in preparation for the v1 release.
The document isn’t yet finished, but we are working on it as we speak and will be sharing it soon enough.
You can see the roadmap that we have planned for Vanilla in preparation for v1 and after in Trello, but there are few key tasks that we want to carry out before September that we’d like to highlight:
This is all from me for now! Barry is writing a companion post that will go into more detail about the technical tasks that are being done on Vanilla, which he will be publishing soon.
We would love to know if you have any ideas on how to improve Vanilla — share your thoughts in the comments.Read more
This was my first cycle sprint within the Cloud design team and my first time to Vancouver, Canada #winner
Having only been with Canonical for 8 weeks and working closely my fellow design colleagues, it was a great opportunity for me meet and collaborate with product engineers working around the world.
Not only was it great to meet engineers but also to sit in meetings with them and learn more about our products, giving me further insight and understanding into MAAS. Discussing new features, sketching, presenting and planning during the week really helped us to evolve our thinking about what we plan to deliver in the next few months. I also had the chance to showcase recent designs and get feedback from a variety of people across different areas of the business.
An exciting new project I worked on whilst at the sprint was Snapcraft.io, a tool that enables you to deliver and package your app to any Linux desktop or cloud server. I was given the task of creating a micro website promoting this tool and showcasing how easy it is to use to setup your app.
But it wasn’t just all #workworkwork… as the evenings gave us opportunity to socialise and get to know different people and explore the city of Vancouver.
It’s an exciting time to be at Canonical with big product releases on the horizon. I’m looking forward to our releases of MAAS 2.0 and Juju 2.0!
Below are some photos of our week in Vancouver. Enjoy :)
Last month the Juju design team was away in Lithuania, Vilnius on a working sprint. We met up with the distributed development team to help tackle technical and design issues.
These sprints take away the barrier of time zones — which usually make it harder to ask engineers questions about features that are being designed.
Everyday started with a run down of the workshops and discussions that would happen on that day. This made sure everyone was aware and welcome (and very much encouraged) to join the sessions and give their valuable insight or just widen their knowledge of the product.
The day would then play out in an enjoyable whirlwind of knowledge, clarity and alarming amounts of progress as queries would be answered in real time without the assistance of an email client or a hangout session.
At lunch time the Juju team took the fantastic opportunity to explore the city. Walking the cobbled streets and enjoying the vast range of foods from a variety of different cultures. While we were there we ate everything from classic Lithuanian cuisine to a big shared spread of Mexican food.
At the end of the day we would go through all of the things which were accomplished and have lightning talks (short presentations of work to the rest of the team) about the work that had been completed. This is a fantastic exercise for design as it lets us show wireframes, prototypes, research or just flat visuals for the features that are being implemented within Juju and gives the engineers a chance to see and discuss the work directly with the designers. Lightning talks are also great for engineering as they can show features that are under development or just talk through the back end of the solution.
This has been my fourth sprint with Canonical and they never cease to be valuable as they promote collaboration, forward thinking and team bonding. I look forward to the team’s next adventure and the challenges that we will conquer.Read more
Here are the best links shared by the design team over the last month:
Every year since 2001, creatives from different design disciplines meet and share their ideas and innovations about digital, interaction and print design in the design festival called OFFF.
This festival was previously held in different countries, but has now found its home in Barcelona at the Design Museum. For three days the festival was jam-packed full of inspirational ideas and speakers such as Paula Scher, Tony Brook, Joshua Davis and many more.
OFFF space in the Design Musem
OFFF 2016 book and program
The festival gives a great overview of design trends, work processes and implementation practices, as well as generating ideas and inspiration from around the world. A festival organizer claimed that: “it is more than just a Festival hosting innovative and international speakers, it is more than a meeting point for all talents around the world to collaborate, it is more than feeding the future. OFFF is a community inviting all those who are eager to learn to participate and get inspired by a three-day journey of conferences, workshops, activities, and performances.”
Before coming to the festival make sure you have a list of speakers you would like to hear, because there are 50 different talks taking place covering a wide scope of topics. It was interesting to hear designers sharing their experiences in design, such as self-initiated projects, dealing with clients, social life versus private, time management and working in a team and solo difficulties.
Joshua Davis design
Being surrounded by creative people for a three days helps you look at your work from the different perspectives. It is always healthy to leave your comfort zone and talk to other creators to see what kind of issues other people have, and how they are solving them. There’s no wrong or right way in the creative process. There are different ways which might work for you, and some that don’t. Inspiring talks give you energy and make you believe that anything is possible to achieve; you just need to do it!
Last week I was invited to Beijing to take part in the China Launch Sprint. The focus of the sprint was to identify action items in our product roadmap for the next devices that will ship Ubuntu Touch in the Chinese market later this year.
I am a lead UX designer in the product strategy team currently doing many exciting things, such as designing the convergence experience across the Ubuntu platform. I was invited to offer design support and participate in the planning of the work we will be doing with our industry partner, China Mobile, after reviewing the CTA test results.
CTA stands for China type approval which is a certificate granted to a product that meets a set of regulatory, technical and safety requirements. Generally, type approval is required before a product is allowed to be sold in a particular country.
The sprint was very productive and a great experience to sync up with old and new faces. We were all excited to explore ideas and work together on the next steps for China Mobile and Ubuntu.
I had some downtime to explore the city and have a taste of Beijing’s most interesting local dishes and potions with people I met from the sprint…Read more
Juju is a cloud orchestration tool which enables users to build models to run applications. You can just as easily use it to deploy a simple WordPress blog or a complex big data platform. Juju is a command line tool but also has a graphical user interface (GUI) where users can choose services from a store, assemble them visually in the GUI, build relations and configure them with the service inspector.
Juju GUI allows users to
Over the last year we’ve been working on a redesign of the Juju GUI. This redesign project focused on improving four key areas, which also acted as our guiding design principles.
Empty state of the canvas
Apache charm details
Mediawiki deployment with errors
Inspector home view
Inspector errors view
Inspector config view
The project has been amazing, we’re really happy to see that it’s launched and are already planning the next updates.
As the Juju design team grew it was important to review our working process and to see if we could improve it to create a more agile working environment. The majority of employees at Canonical work distributed around the globe, for instance the Juju UI engineering team has employees from Tasmania to San Francisco. We also work on a product which is extremely technical and feedback is crucial to our velocity.
We identified the following aspects of our process which we wanted to improve:
I’ve always been interested in the concept of designing in the open. Benefits of the practice include being more transparent, faster and more efficient. They also give the design team more presence and visibility across the organisation. Kasia (Juju’s project manager) and I went back and forth on which products to use and eventually settled on GitHub (GH).
The Juju design team works in two week iterations and at the beginning of a new iteration we decided to set up a GH repo and trial the new process. We outlined the following rules to help us start:
As the iteration went on, feedback started rolling in from the engineering team without us requesting it. A few developers mentioned how cool it was to see how the design process unfolded. We also saw a lot of improvement in the Juju design team: it allowed us to collaborate more easily and it was much easier to keep track of what was happening.
At the end of the trial iteration, during our clinic day, we closed completed issues and uploaded the final assets to the “code” section of the repo, creating a single place for our files.
After the first successful iteration we decided to carry this on as a permanent part of our process. The full range of benefits of moving to GH are:
As a result of this change our designs are more accessible which allows developers and stakeholders to comment and collaborate with the design team aiding in our agile process. Below is an example thread where you can see how GH is used in the process. I shows how we designed the new contextual service block actions.
Meet the newest member of the Design Team, project manager Davide Casa. He will be working with the Platform Team to keep us all in check and working towards our goals. I sat down with him to discuss his background, what he thinks makes a good project manager and what his first week was like at Canonical (spoiler alert – he survived it).
You can read Davide’s blog here, and reach out to him on Github and Twitter with @davidedc.
My background is in Computer Science (I did a 5 year degree). I also studied for an MBA in London.
Computer science is a passion of mine. I like to keep up to date with latest trends and play with programming languages. However, I never got paid for it, so it’s more like a hobby now to scratch an artistic itch. I often get asked in interviews: “why aren’t you a coder then?” The simple answer is that it just didn’t happen. I got my first job as a business analyst, which then developed into project management.
I think the soft skills are incredibly relevant and crucial to the role. For example: gathering what the team’s previous experience of project management was, and what they expect from you, and how deeply and quickly you can change things.
Is project management perceived as a service or is there a practise of ‘thought leadership’?
In tech companies it varies. I’ve worked in Vodafone as a PM and you felt there was a possibility to practice a “thought leadership”, because it is such a huge company and things have to be dealt with in large cycles. Components and designs have to be agreed on in batches, because you can’t hand-wave your way through 100s of changes across a dozen mission-critical modules, it would be too risky. In some other companies less so. We’ll see how it works here.
Indeed one of the core values of Agile is “the team”. I think people underestimate the importance of cohesiveness in a team, e.g. how easy it is for people to step forward and make mistakes without fear. A cohesive team is something that is very precious and I think that’s a regularly underestimated. You can easily buy tools and licenses, which are “easy solutions” in a way. The PM should also help to improve the cohesiveness of a team, for example creating processes that people can rely on in order to avoid attrition, and resolve things. Also to avoid treating everything like a special case to help deal with things “proportionally”.
I like coding, and to be good coder, one must read good code. With open source the first thing you do is look around to see what others are doing and then you start to tinker with it. It has almost never been relevant for me to release software without source.
I dabble in livecoding, which is an exotic niche of people that do live visuals and sounds with code (see our post on Qtday 2016). I am also part of the Toplap collective which works a lot on those lines too.
I also dabble in creating an exotic desktop system that runs on the web. It’s inspired by the Squeak environment, where everything is an object and is modifiable and inspectable directly within the live system. Everything is draggable, droppable and composable. For example, for a menu pops up you can change any button, both the labelling or the function it performs, or take apart any button and put it anywhere else on the desktop or in any open window. It all happens via “direct manipulation”. Imagine a paint application where at any time while working you can “open” any button from the toolbar and change what the actual painting operation does (John Maeda made such a paint app actually).
The very first desktop systems all worked that way. There was no concept of a big app or “compile and run again”. Something like a text editor app would just be a text box providing functions. The functions are then embodied in buttons and stuck around the textbox, and voila, then you have your very own flavour of text editor brought to life. Also in these live systems most operations are orthogonal: you can assume you can rotate images, right? Hence by the same token you can rotate anything on the screen. A whole window for example, or text. Two rotating lines and a few labels become a clock. The user can combine simple widgets together to make their own apps on the fly!
I learned a lot and I suspect that will never stop. The bread and butter here is strategy and design, which in other companies is only just a small area of work. Here it is the core of everything! So it’ll be interesting to see how this ‘strategy’ works. And how the big thinking starts with the visuals or UX in mind, and from that how it steers the whole platform. An exciting example of this can be seen in the Ubuntu Convergence story.
That’s the essence of open source I guess…
Indeed. And the fact that anti-features such as DRM, banners, bloatware, compulsory registrations and basic compilers that need 4GB of installation never live long in it. It’s our desktop after all, is it not?Read more
The Ubuntu App Design Clinic is back! This month members of the Design Team James Mulholland (UX Designer), Jouni Helminen (Visual Designer) and Andrea Bernabei (UX Engineer) sat down with Dan Wood, contributor to the OwnCloud app.
OwnCloud is an open source project, self-hosted file sync and share app platform. Access & sync your files, contacts, calendars & bookmarks across your devices.
You can contribute to it here.
If you missed it, or want to watch it again, here it is:
The next App Design Clinic is yet to be confirmed. Stay tuned.
QtDay is the only Italian event dedicated to Qt. It is held yearly by Develer and brings together company products that are developed using Qt, as well as Qt developers and customers who want the latest developments and solutions in the Qt world. This year the conference was held in Florence, where I was lucky enough to attend and present.
I had previously attended the 2011, 2012 and 2014 QtDay events whilst I was studying Computer Science at the University of Pisa. This year it was different because Develer invited me to give a talk about Ubuntu and Qt. The funny thing was e I was already planning on sending my presentation to the Call for Proposals anyway! So I was already prepared.
My role in Canonical is UX Engineer, basically a developer acting as the bridge between designers and engineers. It is a pretty cool job, and I’m very lucky to be part of such an energetic team.
Over the last year there was a strong push in both the Design and Engineering teams working on Ubuntu Touch to finalize and deliver the convergent experience. This was a great opportunity to spread the word about how to develop convergent apps for the new Ubuntu platform, and get developers interested in where we are and where we are heading.
When I first thought about giving the presentation, I decided it would only be about the current state of the UI components provided by Ubuntu SDK, with a strong focus on their “convergent” features, and how to use them to realize your convergent apps. However, as time went by I realized it would have been more interesting for developers to also get some context about the platform itself, and how to best integrate their apps with the platform.
By the time QtDay arrived, the presentation had almost doubled in size! You can find it here.
This is a detail the geeks in the audience might be interested in…I thought it would be neat to talk about the development of Qt/QML apps and use the same framework to implement the presentation as well!
That’s right, the presentation is actually a QML application that uses (a modified version of) the QML presentation system available as a Qt Labs addon. Having the power of Qt underneath your presentation means you can do pretty much everything You’re not tied to the boundaries set by the “standard” presentation systems (such as Beamer, LibreOffice Impress, Microsoft Powerpoint, etc) anymore!
In my case, I exploited that to implement a live-coding view as a pull-down layer that you can open on-demand whenever you want by using keyboard shortcuts. Once the livecoding view is open, you can write code (or use the code automatically provided when you’re at one of the special “Livecoding!” slides) in the text editor on the left side and see the result in the right side in real time without leaving or interrupting your presentation. You can also increase or decrease the font size, and there’s also a sparkling particle effect that follows the cursor to make it easier for the audience to follow your changes to the text. That’s only one of the things you can do once you replace your “standard” presentation with a full featured application. If you’re a software developer then I highly recommend giving it a try for your next presentation!
And here’s a screenshot of the livecoding view in action (sparkling particle effect included) :)
The conference was held in the middle of Florence at the Hotel Londra Conference Centre. It was quite a nice location I have to say! Very easy to reach as it is very close to the main railway station, Santa Maria Novella.
My talk was in the first time slot after the main keynote, which was good because, you know, that meant I could relax and enjoy the rest of the day!
I started by giving an overview of the current state of Ubuntu and the fact that it’s doing great in the Cloud field. Ubuntu can now scale to run on IoT devices as well as phones, tablets, notebooks, servers and Clouds.
I then presented the concept of convergence and how the UI components provided by the Ubuntu SDK can be best utilised to create great convergent apps, including some livecoding. Livecoding is fun because it gives a pragmatic idea of how to go from theory to practice, and also keeps the attendees awake, because they know things can go wrong at any moment (demo effect) and they enjoy that, for some reason :)
After UI components section, I went on to talk about platform integration topics such as the app lifecycle management, the app isolation features, and the integration with the Content Hub which is the secure way to share data between applications.
I then briefly talked about internationalization and how to publish your application on the Ubuntu Store (it’s very easy!)
For this occasion, I brought with me a BQ M10 tablet, which is the convergent Ubuntu tablet that we released just a few months ago! I connected it to a bluetooth mouse and keyboard, and set it up on a table for people to try. Lots of people played with it. After the talk it was exciting to see the audience interest in the whole convergence story.
The other talks during the morning were very interesting as well, I particularly enjoyed Marco Piccolino’s “A design system and pattern libraries can significantly improve the quality of your UI” (Find the slides here).
The food was great and, coming from the UK, I enjoyed it even more. Big kudos to Develer (the company behind the event) for finding such a good catering company!
Here’s a pic of the goodies available during coffee breaks. Mmmm…
The afternoon talks were as interesting as the morning ones. Marco Arena, from the Italian C++ Community, gave a talk about QCustomPlot, which is a library to draw graphs and plots using Qt (slides here).
If you’re interested in Virtual Reality, partially BCI (Brain Computer Interface) and machine learning, make sure you check out the slides of Sebastiano Galazzo’s talk (once they’re available, at that page). His project involves manipulating what the user sees in a Google Cardboard by reading his/her brain waves to interpret emotions. Pretty neat.
Stefano Cordibella’s presentation was about his experience optimizing the startup time of an application running on embedded hardware (using Qt4). They exploited the power of the QtQuick Loader component and other QML tricks to decrease the loading time of the application.
Check his slides out if you’re interested in QML optimization. I’m sure you’ll find them useful.
The final talk I attended was more of a roundtable about how to contribute to the development of Qt itself, led by Giuseppe D’Angelo, who has the role of “Approver” in the Qt Project Open Governance Model.
As a result of attending that roundtable not only I started contributing to Qt (See the changes I contributed to here), but I also improved theQt Wiki Contribution Guidelines so that it will be easier for other people to start contributing. The power of open source and open governance! :)
The closing talk also included a raffle, where a couple of developers won an embedded devboard sponsored by Atmel. I’ve been quite lucky with Qt-related raffles in the past, but this wasn’t one of those days, oh well :)
What a great day it was. I want to thank Develer for organizing the conference and the guys from Community team (Alan Pope, David Planella, Daniel Holbach) and Zsombor Egri from the SDK team at Canonical for providing feedback and ideas for the presentation.
It was also great to see so many people interested in the convergence story and in the M10 tablet. The technology has great potential and it’s our job to make the best of it :)
See you all at the next QtDay!
Note: the pictures are courtesy of Develer’s QtDay Facebook page.Read more
We’re very happy to announce the return of the Ubuntu App Design Clinics.
The first session is planned for 4.00PM BST on Friday the 17th of June, with subsequent sessions occurring at 4.00PM BST on Thursdays.
We’ll be on camera talking to Dan Wood regarding his work on the OwnCloud App. Feel free to drop in and join the discussion via IRC:
We look forward to seeing you there!Read more
Here are the best links shared by the design team over the last month:
Last year we were working on OOBE redesign with the aim to improve first user experience with Ubuntu phone. Now the Design Team is working on the second part of this project which we call Edge Education.
The purpose of Edge Education is to aid discoverability and to educate users into using them naturally. For example, did you know what you can access the whole system by swiping from the edges of the screen.
How many edges Ubuntu phone has?
At the moment, the Ubuntu phone has four edges that can be interacted with in six ways.
Left short swipe
If you short swipe across the left edge you will open the launcher.
Left long swipe
You can quickly come back from any app to the Dash by a long left swipe.
Swiping from the top edge will give you access to indicator menus.
Right long swipe
Long swipe from the right edge will open the switcher to let you move between open apps.
Right short swipe
Swiping from the right edge you will switch between your current and previous app (ALT-TAB interaction).
Bottom swipe (app specific)
Swiping from the bottom edge brings you different functionality depending if you are in app or scope. Not all apps has a bottom edge. If an app has a bottom edge you will know this by seeing a bottom edge hint. For example, you can add a new contact by swiping from the bottom edge in the Contacts app. By doing bottom edge swipe in the scopes you can quickly favourite and unfavorite your scopes.Read more
OpenStack is the leading open cloud platform, and Ubuntu is the world’s most popular operating system for OpenStack. Over the past two years we have created a tool that allows users to build an Ubuntu OpenStack cloud on their own hardware in a few simple steps: Autopilot.
This post covers the design process we followed on our journey from alpha to beta to release.
We started by mapping out a basic Autopilot journey based on stakeholder requirements and designed a first cut of all the necessary steps to build a cloud:
After the initial design phase Autopilot was developed and released as an alpha and a beta. This means that for over a year, there was a product to play around with, test and improve before it was made generally available.
Almost immediately after the engineering team started building our new designs, we discovered that we needed to display an additional set of data on the storage graphs. On top of that, some guerilla testing sessions with Canonical engineers brought to light that the CPU and the storage graphs were easily misinterpreted.
After some more competitive research and exploratory sketching, we decided to merge the graphs for each section by putting the utilisation on a vertical axis and the time on the horizontal axis. This seemed to improve the experience for our engineers, but we also wanted to validate with users in usability testing, so we tested the designs with eight participants that were potential Autopilot users. From this testing we learned to include more information on the axes and to include detailed information on hover.
The current graphs are quite an evolution compared to what we started with:
Before a user gets to the Autopilot wizard, they have to configure their hardware, install an application called MAAS to register machines and install Landscape to get access to Autopilot. A third tool called Juju is installed to help Autopilot behind the scenes.
All these bits of software work together to allow users to build their clouds; however, they are all developed as stand-alone products by different teams. This means that during the initial design phase, it was a challenge to map out the entire journey and get a good idea of how the different components work together.
Only when the Autopilot beta was released, was it finally possible for us to find some hardware and go through the entire journey ourselves, step by step. This really helped us to identify common roadblocks and points in the journey where more documentation or in-app explanation was required.
Following our walk-through, we identified a number of points in the Autopilot journey where contextual help was required. In collaboration with the engineering team we gathered definitions of technical concepts, technical requirement, and system restrictions.
Based on this info, we made adjustments to the UI. We designed a landing page with a checklist and introduction copy, and we added headings, help text, and tooltips to the installation and dashboard page. We also included a summary panel on the configuration page, to guide users through the journey and provide instant feedback.
Perhaps the most rewarding type of feedback we gathered from the beta release — our early customers liked Autopilot but wanted more features. From the first designs Autopilot has aimed to help users quickly set up a test cloud. But to use Autopilot to build a production cloud, additional features were required.
One of the biggest improvements for GA release was making it easy to try Autopilot, even for people that don’t have enough spare hardware to build a cloud. Our solution: try Autopilot using VMware!
In the alpha version a user could already select nodes, but in most enterprises users want more flexibility. Often there are different types of hardware for different roles in the cloud, so users don’t always want to automatically distribute all the OpenStack services over all the machines. We designed the ability to choose specific roles like storage or compute for machines, to allow users to make the most of their hardware.
The first feature we added was the ability to add hardware to the cloud. This makes it possible to grow a small test cloud into a production sized solution. We also added the ability to integrate the cloud with Nagios, a common monitoring tool. This means if something happens on any of the cloud hardware, users would receive a notification through their existing monitoring system.
This month we are celebrating another release of OpenStack Autopilot. In the two years since we started designing Autopilot, we have been able to add many improvements and it has been a great experience for us as designers to contribute to a maturing product.
We will continue to iterate and refine the features that are launched and we’re currently mapping the roadmap for the months ahead. Our goal remains for Autopilot to be a tool for users to maintain and upgrade an enterprise grade cloud that can be at the core of their operations.
Suru is based on Japanese aesthetics: minimalism, lightness and fluidity. This is why you will see the platform moving to a cleaner and more modern look.
Naturally, part of this evolution is colour. The new palette features a lightened set of colours with clearly defined usage to create better visual hierarchy and an improved aesthetic sense of visual harmony.
On the technical side, SDK colour handling has been improved so that in the future colour usage will be more consistent and less prone to bugs.
The new palette has also expanded in scope with more colours to enable the creation of designs with greater depth, particularly as we move towards convergence, and reflects the design values we wish to impart onto the platform.
Like our SDK, the colour palette has to be scalable. As we worked on visual designs for both apps and the shell, we found that having a colour palette which only contained six colours was too limiting. When approaching elements like the indicators or even shadows in the task switcher, light grey and dark grey weren’t going to be deep enough to stand out on a windowed view, where you have wallpaper and other windows to compete with.
The new palette is made up of thirteen colours. Some noticeable differences are an overall lighter look and additional greys. Purple is gone and we’ve added a yellow to the palette. This broader palette works to solve bugs where contrast and visibility were an issue, especially with the dark theme.
How we came to choose the colours was by iteratively reworking the visual designs across the whole platform and discovering what was needed as we designed. The greys came about when we worked on the revamped dark theme and shell projects, for example the upcoming contextual menus. While we added several new greys, the UI itself has taken on a less grey look.
App backgrounds have been upped to white, the grey neutral button has been lightened to Porcelain (a very light grey) in order to keep the button from looking disabled. These changes were made to improve visibility and contrast, to lighten the palette across the board and to keep everything consistent.
The previous design of the Nearby scope (left) and the updated design using the new palette (right) The background is lighter, buttons don’t look as disabled and text is higher contrast against the background.
The new palette allows developers to have more flexibility as the theme is now dynamic, rather than the colours being hard-coded to the UI as they were previously. In fact, our palette theme is built upon a layering system for which you can find the tutorial here.
Previously orange was liberally used throughout our SDK, however such wide-ranging use of orange caused a number of UX issues:
Around the same time as these issues were identified, we were also working on the design of focus states for keyboard navigation.
A focus state needs to be instantly visible so that a user can effortlessly see which item is focused without having to pause, look harder, and think.
After exploring a wide range of different concepts, we settled on using an orange frame as our keyboard navigation focus state. However the use of this frame only worked if orange in all other areas was significantly toned down.
In order to fix the UX issues with the overuse of orange and to enable the use of an orange frame as our keyboard navigation focus state, the decision was made to be much more selective as to where and when orange should be applied. The use of orange should now be limited to a single hero item per surface in addition to its use as our keyboard focus state.
This change has:
For many years blue has been used in Ubuntu to alert the user to activities that are neutral (neither positive or negative). Examples include the Launcher pips changing to blue to give the user a persistent notification of an app alert, or the messaging menu indicator changing to blue to indicate unread messages.
Previously in some (but not all) cases orange was being used to represent select and activity states but effective keyboard navigation had not yet been designed for Unity.
As part of our work on focus states, we also needed to consider a consistent visual language for select states, with a key requirement being that an item could be both focused and selected at the same time.
After much research, experimentation and testing, blue was chosen as the Ubuntu selected state colour. Blue has also returned to being used for natural activity, for example in progress bars. The use of blue for selected and other activity states works with almost all other elements, on both dark and light backgrounds, and stands out clearly and precisely when used in combination with a focus state.
Now that our usage of colour is more precisely and consistently defined (with orange = focus, blue = selected and neutral activity), you will see use of orange minimised so that it stands out as a focus state and more blue to replace orange’s previous selection and activity use.
The sections headers now use blue to indicate which section is selected. This works well with the new focus frame that can be present when keyboard navigation is active.
Colour is important for aesthetics (the palette needs to visually work together) but it also needs to convey meaning. Therefore a semantic approach is critical for maximum usability. Some colours have cultural meanings, other colours have meanings applied by their context.
By extending the colours in our palette and organising them in a semantic way, we have created a stable framework of colour that developers can use to build their apps without time consuming and unnecessary work. We can now be confident that our Suru design values are being consistently applied to every colour related design problem as we move forward with designing and building convergence.Read more
In the coming months we will be rolling out the new app design guidelines, which will give you the latest toolkit best practices and patterns so you can make your own convergent app for Ubuntu.
The guidelines are a big part of communicating design practices and philosophy to the community and the wider audience. Without it, we wouldn’t have consistency in our design language and people who want to develop or design on Ubuntu wouldn’t be able to maintain the identity we so love.
Throughout the guide you will see the rationale behind our design values through the development our Suru visual language and philosophy.
We are going to start releasing parts of the Building Blocks section first, which contains all the components you need to start building your application.
Back in November last year we took a look at defining styles for the guide e.g. how to illustrate examples of best practice. The guide will feature UI examples of how the component will look inside an app across screen sizes, as well as breaking them apart so you can see what goes where and how.
Here’s a sneak peak…
After user testing on the current design guide, users said it was hard to find content as it was lost in the large amounts of text, so we have given the guide a bit of a nip and tuck by balancing visuals and text accordingly.
As well as ‘Get Started’, ‘Patterns’ and ‘Building blocks’ we will now introduce: ‘System integration’ and ‘Resources’ to the list, as well as an overview page for each section highlighting key areas.
System integration will feature the number of a touchpoints your app can plug into inside the Ubuntu operating system shell, such as the launcher, notifications and indicators. For example, you can add a count emblem over your app icon inside the Launcher to show unread messages or available updates.
The ‘Resources’ section will feature downloads such as grid layout templates, the new colour palette and our icon set.
We can’t wait to see your app designs and hope that our design practices will help you achieve a great user experience on Ubuntu.Read more
At the beginning of the year our team – who look after the core websites in the Ubuntu ecosystem – decided to adjust our project delivery process and go full-on Scrum. This is hardly shocking news these days. Actually, you can find way more people writing about how they decided to ditch Scrum and what a terrible idea it was to begin with. But for us, it seemed like a good thing to try and so far the results are promising.
Happy Web Team sprinting on the 16.04 release day
Scrum was born as a framework to manage the development of complex products where the traditional project methodologies failed. It has a very simple set of rules that are best explained by its founding fathers Ken Schwaber and Jeff Sutherland in the Scrum Guide. Unfortunately, over the years the simple framework has been – on the one hand – contaminated with various additional concepts and on the other, diluted by assumption that Scrum can work in any context or on a pick-and-choose basis.
When you think Scrum do you think user stories, burndown charts and planning poker?
Well, that is what I thought before I realised that all these things are NOT part of Scrum but the optional additions, which sometimes can help but sometimes can be detrimental.
I joined the Canonical Web Team at the end of last year in a project manager’s role. At that point, the team was experimenting with introducing some of the Scrum artifacts, like sprint planning and retrospective, into an already familiar Kanban method.
Standups were a daily bread for the team and kept everyone in the loop. Retrospectives made us reflect on the ways we work and how we can improve. Team members were skilled at planning their tasks and progressing through their work. The fact that we are a relatively small team based in the same space also helped with communication and collaboration.
It felt like the partial adoption of Scrum was not really allowing us to reap all positive effects. We operated on a one week sprint basis. We had planning sessions at the start of the sprint but they were mostly focused on tasks for individual team members rather than team working out what we can complete each sprint and how to make it happen. We also didn’t involve the stakeholders in our meetings, so often team members didn’t have a good understanding of the business context behind the projects.
Our log of current and incoming work was massive, recorded in few different places, and often not very well defined. We work with multiple stakeholders from different functions and product lines. We also have a handful of internal projects aimed at improving our ways of working (for example a great Vanilla framework initiative you can read about here). It was a challenge for us to understand our short and long term priorities. It also felt that we can benefit if we make the stakeholders a part of the prioritisation and planning exercise.
Our team was one leg in the Scrum already and it intuitively felt that pushing it further could help us resolve at least some of the above mentioned problems.
We extended the duration of our sprints to two weeks in order to have enough time to complete usable product increments. Bonus – it reduced the overhead of weekly planning and review sessions.
We shifted our thinking about what we take on each sprint from the task level items to the backlog level items which ideally, should be demonstrable at the end of the sprint. The goal is also to get better at understanding our velocity, improve estimation and therefore be more accurate in planning what we can accomplish in two week’s timeframe.
This change created a more sustainable work pace while at the same time added a sense of urgency around most important work. Sprint clock is ticking, we know what we planned to complete and from day one we do our best to succeed. As mentioned by one of our developers, “Team now has bi-weekly rhythm and greater visibility of overall team goals in any given sprint. There is a constant march of progress”.
Product backlog is one of the Scrum artifacts and our team didn’t really have one before. We decided to replace all docs and tools where we captured upcoming projects with one simple spreadsheet, hosting all briefs and other relevant project info. This allowed us to surface all the work that team had in the pipeline, including the internal improvements that didn’t have any owners outside of the Web Team. This new format supports us in defining and building the consensus about our priorities.
One additional shift related to our estimation process. We decided to discard task estimating altogether for the simplicity and focus only on the backlog items. The principle is that the higher the project is in the backlog, the more we break it down into small increments so our estimates are more accurate. We started with a big backlog refining session to get a better understanding of what we have in the pipeline. We now use the burnup chart which I update at the end of the sprint and it helps us to predict when, roughly, we may get to the projects that are further down the pipeline.
We decided to introduce new meetings and slightly alter the existing ones. Every two weeks our Tuesday schedule is pretty hectic but it feels like it actually saves us time in the long run.
We start with a sprint review meeting for all team members and stakeholders. That’s where we look at what was planned for the sprint, demo what we completed and – if needed – explain what we didn’t manage to finish and why. We then move to the backlog planning session with the same group, agreeing what should make its way to the next sprint, clarifying outstanding questions and talking through new briefs that came in the meantime.
The second set of meetings involves only the Web Team. We first run our usual retrospective and after that, we plan the next sprint in details. We discuss all backlog items planned for the sprint, identify tasks needed to complete them and team members pick what they will be working on. After this exercise, even without estimating, we get a pretty good idea whether we’re overloaded or we need to add more work.
So far the review and planning meeting with the business turned out well and helped to improve the communication, understanding of everyone’s work, and consensus about the priorities. As one of team members pointed out, “stakeholders now have to agree to work beforehand and any ad-hoc work inserted into the iteration visibly impacts on our initial commitment”.
The beauty of Scrum is that it’s lightweight and in principle, simple to understand. It doesn’t mean however that running projects with Scrum is not difficult. Below I outlined what I see currently as our key challenges.
Some of our web projects have strict launch dates as they are tied to specific events, such as a launch of new device. More often than not, these fall somewhere within the sprint duration so we can’t simply finish them at the end of the sprint. One way of addressing it would be to schedule them in the preceding sprint however we are rarely able to gather all necessary bits of information beforehand. For now, we just accept the fact that some items in our sprint have a higher priority and need to be released before the sprint ends.
More often than not, by the end of the sprint we realise that we won’t complete all scheduled backlog items. We try not to make a big drama out of it – apparently it happens roughly half of the time even for mature Scrum teams – but at times, it deflates a sense of accomplishment. We can definitely improve how we break our backlog items, and our estimates are still sometimes based on a wishful thinking. There is also too much temptation to add more to a backlog than our velocity predicts – we try to resist it, with mixed effects.
Introducing stakeholders to our planning and review process was seen by the whole team as a huge improvement, yet working with clients – either internal or external – is not always a piece of cake. We sometimes struggle to get good briefs and all necessary information before the sprint starts, and every now and then we get a cheeky request to fit something new in. It’s a long process to get everyone follow the rules and we are only at the beginning!
This seems to be quite a common problem for many Scrum teams – how should we deal with bugs and small requests (like copy changes) that come during the duration of the sprint? We considered postponing them until the next planning meeting where we would determine which ones we add into a sprint. Eventually, we decided we would spend more time discussing and planning these things than it actually takes to resolve them. Therefore, we assume that a small percentage of team’s velocity (about 10%) will be spent on dealing with these. That’s not quite in line with Scrum principles and we don’t have a good way to measure yet what’s the actual impact of such work.
Scrum doesn’t work everywhere and for everyone but our team is happy with the direction we moved to, which often comes back in our retrospectives. Empowerment, openness, collaboration, and better structure have been mentioned by several team members. It’s really remarkable how easily everyone adjusted to the new process and team’s commitment to make the whole thing work has been invaluable.
We are only in our seventh sprint now and are still on the steep learning curve, making adjustments as needed. Like anything in this world, Scrum is not perfect but maybe the greatest thing about it is that it keeps continuous adaptation at its core so within each cycle, we can look back and change what we don’t like.
Before we started our transition to Scrum I completed the Scrum Master and Product Owner training classes with Martine Davos at Skills Matter in London, UK, which I highly recommend for any Scrum newbies.Read more
Here are the best links shared by the design team over the last month:
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.