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:
Here are the best links shared by the design team over the last month:
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.
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:
Here are the best links shared by the design team over the last month:
We previously posted about the clock app’s new look and today we are getting to know one of the developers behind the clock ( as well as other community apps.) Bartosz Kosiorek gives us a glimpse into developing for Ubuntu and how he got started.
1) First, can you give us a bit of background about yourself and tell us how you started developing for Ubuntu?
My name is Bartosz and I’m from Poland. Currently I’m the developer for the Ubuntu Clock and Ubuntu Calculator. I started contributing to Ubuntu in 2008, by submitting bug reports into launchpad and fixing translations. Later I participated in the One Hundred Papercuts project. I made SRU verifications and eventually started developing.
My adventure with Ubuntu started from Ubuntu 8.10 (Interpid Idex). Previously I tried many different distributions (Debian, Fedora, SuSE etc.). I chose Ubuntu because it is easy to use and after installation, I have fully functional system. I like that after Ubuntu is installed, there are no duplicate applications and those already installed work perfectly with the system.
2) How long have you been working on the Clock and Calculator? How did you get involved in these projects?
I started to develop for Ubuntu about two years ago when I first heard about Ubuntu Touch and convergence. I started by contributing to Ubuntu Core Apps by testing, submitting bug reports and patches. Most commits were done for Ubuntu Calculator and Ubuntu Clock by fixing bugs which were approved by Riccardo Padovani, Mihir Soni and Nekhelesh Ramananthan. After some time, I became member of Ubuntu Core Apps. It’s very fun to work with these guys and the Ubuntu community. I’ve learned a lot about Qt/QML and user experience design.
3) How do you approach implementing a design in your apps?
Generally I follow the design document during implementation and sometimes find parts that need to be improved. After speaking with the Ubuntu UX team, we discuss various issues and agree on a final design solution. Sometimes the UX team gives us freehand, so we could design some parts by ourselves (eg. Stopwatch, Welcome Wizard, Landscape View). It’s really fun to work with such awesome guys.
4) What feature would you like to see in the future?
I think from user perspective, longer battery life is a very important topic. The power usage is higher with white background: https://www.quora.com/Does-a-white-background-use-more-energy-on-a-LCD-than-if-it-was-set-to-black especially with OLED screen. I wish that Ubuntu Touch came with a darker theme, to save battery on OLED screens.Read more
Here are the best links shared by the design team during the shortest month of the year:
Juju is a cloud orchestration tool with a lot of unique terminology. This is not so much of a problem when discussing or explaining terms or features within the site or the GUI, but, when it comes to external sources, the context is sometimes lost and everything can start to get a little confusing.
So a project was started to create embeddable widgets of information to not only give context to blog posts mentioning features of Juju, but also to help user adoption by providing direct access to the information on jujucharms.com.
This project was started by Anthony Dillon, one of the developers, to create embeddable information cards for three topics in particular. Charms, bundles and user profiles. These cards would function similarly to embedded YouTube videos, or embedding a song from Soundcloud on your own site as seen bellow:
Multiple breakpoints of the cards were established (small, 300px and below. medium: 301px to 625px and large: 626px and up) so that they would work responsively and therefore work in a breadth of different situations and compliment the user’s content referring to a charm, bundle or a user profile without any additional effort for the user.
We started the process by determining what information we would want to include within the card and then refining that information as we went through the different breakpoints. Here are some of the initial ideas that we put together:
We wrote down all the information there could be related to each type of card and then discussed how that might carry down to smaller card sizes and removed the unnecessary information as we went through the process. For the profile cards, we felt there was not enough information to display a profile card above 625px break point so we limited the card to the medium size.
Just enter the bundle or the charm name and the card will be generated for you to copy the code snippet to embed into your own content.
You can create your own here: http://www.jujugui.org/community/cards
Below are some examples of the responsive cards are different widths:
Here are the best links shared by the design team during the first month of the year:
Our cloud design team has just returned from a trip to Cape Town for our mid-cycle sprint. We have the luxury of being collocated in London and working closely throughout the whole year, but these sprints give us an invaluable opportunity to collaborate with other stakeholders and engineers working around the world. We get together to define priorities and review progress on our goals for this cycle.
We can showcase upcoming features and designs and get feedback from a variety of sources.
This time we also heard from cloud architects who are building data centres with the products we design. It gave us an insight into how our products are being received in the field – what is working well in reality, what we need to do more of.
The week mainly involves lots of talking, drawing, presenting and discussing topics and we work to a tight schedule.
But we also get a chance to socialise and get to know people we work with in different time zones, which I think is just as valuable as the working bit.
At the end of the week we plan in detail for the next few weeks based on the outcomes of our conversations.
It’s an exciting time to be at Canonical. A new version of our provisioning product MAAS has just been released and it’s a huge evolution and something we’re very proud of.
The new Juju GUI just went live today! It has a completely revamped interface to make it easier to build and manage your cloud applications and services.
Our Autopilot tool for building OpenStack clouds will have a really nice set of new options in our next release.
Below are some photos of our week in Cape Town. I’m looking forward to our next Ubuntu release in April and the evolution of the cloud tools that come with it.
If you’d like to join the fun, get in touch, we’re hiring!
Here are the best links shared by the design team in December:
Here are the best links shared by the design team in November:
Here are the best links shared by the design team in October:
We sat down with Dekko star Dan Chapman to get an insight into how he got involved with Ubuntu and his excitement for the release of the Pocket Desktop.
Dan has been an active member of the Community since 2013, where he has worked closely with our Design Team to create one of our first convergent showcase apps: Dekko. He also helps out with the Ubuntu QA community with package testing and automated tests for the ubuntu-autopilot-tests project.
The Dekko app is an email client that we are currently developing to work across all devices: mobile, tablet and desktop. If you are interested in contributing to Dekko, whether that be writing code, testing, documentation, translations or have some super cool ideas you would just like to discuss. Then please do get in touch, all contributions are welcomed!
I first got involved with the Community in 2013, where Nicholas Skaggs introduced me to the Quality Team to write test cases for automated testing for the Platform. I can’t remember why I started exactly, but I saw it as an opportunity to improve it. Ever since then it’s been a well worth it experience.
I like the fact that in the Community everyone has a common goal to build something great.
I study from home at the moment so I have to divide my time between my family, Ubuntu and my studies.
What I do for Ubuntu and my course are quite closely tied. The stuff I do for Ubuntu is giving me real life practical skills that I can relate to my course, which is mainly theory based.
I’m actually doing a project at the moment that is to do with my work on Dekko, but it’s for interacting with an exchange server and implementing a client side library. Hopefully when that’s done I can bring it into Dekko on a later date. I try to keep my interests parallel.
Quite a large proportion of my time goes towards Ubuntu.
I find it more than effective. I mean it would be great to meet people face-to-face too.
Being able to have a full-blown computer in my pocket. As soon as it’s available i’m having the pocket desktop.
I do yes. The rest of the family do too. I even got my eldest boy, who’s 9 to use it, as well as my partner and mother-in-law.
It’s been great actually because i’m useless at design. There’s always something to improve on, so even if the designs aren’t ready there’s still enough to work on. There hasn’t been big waits in-between or waiting for you guys as you’re busy. The support is there if you need it.
The only challenge is getting the design before the toolkit components are ready. It was a case of creating custom stuff and trying to not cause myself too much pain when I have to switch. The rest has been plain sailing as they toolkit is a breeze to use, and the Design team keep me informed of any changes.
I speak to a fair few of them now through Telegram, that seems to be the place to talk now there’s an app for it. It’s nice you can ping your question to anyone and you’ll get an immediate response relatively quickly. Alan Pope, always gives you answers.
It is exciting as it’s something different. I don’t think there’s competition, as we all have different target audiences we are reaching to. I’m really excited about where the Platform is heading.
Here’s a selection of the links we shared in September:
We believe that the first impression matters, especially when it comes to introducing a new product to a user for the first time. Our aim is to delight the user from the moment they open the box, through to the setup wizard that will help them get started with their new phone.
Devices have become an essential part of our everyday lives. We choose carefully the ones we want to adopt, taking into account all manner of factors that influence our lifestyle and how we conduct our everyday tasks. So when buying a totally new product, with unfamiliar software, or from a new brand, you want to make the first impression count in order to seduce and reassure the user that this product is for them.
The out of the box experience (OOBE) is one of the most important categories of software usability. It essentially says how easy your software is to use, as well as introducing the user into your brand through visual design and tone of voice, which can convey familiarity and trust within your product.
We started to look at research around users past experiences when setting up a new device and their feelings about the whole process. We also took a look at what our competitors were doing, taking into account current patterns and trends in the market.
From gathering this research we started to simplify as much as possible the OOBE workflow. Taking into consideration the good and the bad things, we started to define our design goals:
First of all we started from the smallest screen, taking the existing screens we have for mobile and assessing the design faults and bugs.
In order to create a consistent experience across all devices, we drew together common first experiences found on the mobile, tablet and desktop:
One of the major changes we wanted to achieve was to give the user the same experience across all devices, moving us closer to achieving a seamless convergent platform.
The secondary screens created more space for forms, which helped us to define a consistent and intuitive animation between screens.
The implementation of the OOBE has already begun and we cannot wait for you to open the box and experience it on your new Ubuntu device.
UX Designer: Andreea Pirvu
Visual Designer: Grazina BoroskoRead more
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.