Canonical Voices

Femma

Last week the design team had two interns undertaking their work experience at the London office.

Our first student is studying computer science for her GCSEs and has an interest in Python programming and software engineering. The second student is studying Geography and IT and had a general interest in IT.

The tasks

We wanted them to experience what working in the design team is like, so we set them two tasks:

Task 1 – Create a poster of your work experience

We asked them to keep a note of the key things that they had been doing and what they learned throughout the week.

They were then asked to create two paper versions of their posters, which were reviewed by one of our visual designers. After being reviewed, the designers helped the student to create a final electronic version, which they could take back to school with them.

Task 2 – Convergence tablet

We asked them to use the convergence tablet as their device during the week for user testing purposes.

We wanted them to:

  • Send emails
  • Take notes
  • Update social media
  • Take images
  • Organise their gallery
  • Share something with a friend
  • Play games
  • Play music
  • Read news articles or other articles

We asked for feedback on:

  • What they liked about convergence
  • What would they like to see on the tablet?
  • What was their favourite app
  • What can we improve?

They were expected to talk through their feedback for 15 minutes with two designers.

Feedback

By the end of the week we wanted our interns to have the confidence to present their findings to us, as well as experience a review process with their poster designs.

The feedback we got from our first student – who used the tablet for 4 days, in between her other tasks – said: ‘ready, not a prototype, sleek and lightweight’. What she liked most about it was that ‘it can be a whole computer if you connect it’. She also liked the UbuntuStore.

The feedback we got back from our second student – who used the tablet in between tasks of making bootable USB drives and learning code – was that he ‘likes how it has the capability to … just pick it up and plug it into a monitor … Because it means that you don’t have to carry anything around, just a tablet.’
His favourite app was the Browser, he said ‘because it gives you access to everything’ and he thought it was ‘better than Safari because Safari blocks a lot of things like Flash’. He thought that the camera was of ‘good quality and focused quickly’ and felt it was easy to take photos and videos.

We also received suggestions on what they wished to see in the future and what they thought could be improved, which was great to see from the student demographic. We have captured all of this and can incorporate some of these ideas.

Work experience poster

With the help of one of our visual designer’s, we reviewed our first student’s paper designs and helped bring her poster to life.

work-experience-poster

This poster was the fruits of her labour and she was then tasked with finishing it off at home, ready to take back to school with her.

Our London office really values the work our work experience interns undertake in the week they are here during the summer. Many of them tend to have interests in technology and our open source nature is a good way to give them a flavour of the Ubuntu design and engineering process.

Want to be an intern at Canonical?

If you’re a student and like what you’ve seen so far, and would like to undertake your work experience with us please do get in touch with Stefanie Davenoy – stefanie.davenoy@canonical.com.

Read more
Elvi

Over the past few months, the Juju team has been working on a whole redesign of the Juju store

Screen Shot 2016-07-18 at 12.53.40

 

Screen Shot 2016-07-18 at 12.54.36

Screen Shot 2016-07-18 at 12.55.28

 

 

Screen Shot 2016-07-18 at 12.59.10

 

Screenshot 2016-07-10 14.10.08

Screenshot 2016-07-10 14.11.20

 

 

Screenshot 2016-07-10 14.13.20

 

 

 

Screen Shot 2016-07-11 at 13.36.52Screen Shot 2016-07-11 at 13.37.10

 

 

 

IMG_2367_4352b

 

 

Read more
Steph Wilson

photo_2016-07-08_13-59-27

You can now follow us on Dribbble and Behance for design inspiration.

See things like: the Ubuntu #reinvent digital campaign, Juju embeddable card and Suru app icon designs.

Follow us :)

Read more
Inayaili de León Persson

Getting Vanilla ready for v1: the roadmap

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.

Future-thinking: defining a high level roadmap

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.

 

Vanilla roadmap in TrelloThe Vanilla framework roadmap Trello board

 

Contributing: defining the process for adding new patterns

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.

 

Vanilla process diagramDiagram of the process to submit a new pattern to Vanilla

 

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.

Defining browser support guidelines

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.

Future tasks

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:

  • Defining the accessibility standards that all patterns will have to follow, and adding automated tests to the build process to ensure they are adhered to
  • Conducting an internal accessibility audit and making as many changes as we can to improve accessibility
  • Redesigning the dedicated Vanilla website to include the new documentation we are writing and other pieces of useful information, including the style guide itself — all living together in one single site
  • And, obviously, making sure that Vanilla has its own logo — as any respectable framework does :)

Final words

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
karlwaghorn-moyce

Vancouver sprint recap: MAAS and Juju

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 :)

Vancouver sprint

Vancouver sprint

Vancouver sprint

Read more
Joseph Williams

Juju Lithuania sprint recap

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.

13616221_10209952745325460_1919613808_o

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.

13589133_10209952745245458_1275611017_o

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.

13616195_10209952745285459_595293251_o

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
Grazina Borosko

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.

 

IMG_4973

OFFF  space in the Design Musem

OFFF

OFFF 2016 book and program

What is the festival about?

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.”

 

Ustwo

Ustwo

Hey studio

Hey studio

A word of advice…

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.

 

Nonformat

Non-Format

Joshua Davis deisgn

Joshua Davis design

Why you should go to the festival

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!

 

Mark Adamson

Danny Sangra

 

 

Read more
Paty Davila

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.

photo_2016-06-17_15-25-12

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.

What is CTA?

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.

Topics covered:

  • CTA Level 1-4 test cases and developed a new testing tool for pre-install applications.
    We reviewed the content and proposed design for all five of Migu scopes with design team’s input.
  • Also, we discussed the new RCS (Rich Communication Suite) integration with our Messaging app and prepared demos [link] for MWC Shanghai, Asia’s biggest mobile event happening at the end of this month.
  • And explored ideas around the design of mCloud service integration with our storage framework.

Achievements

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.

Downtown in Beijing

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…

photo_2016-06-17_15-23-56

Michi has creatively named this one as snake juice.

Team dinner :)

A large team dinner.

photo_2016-06-28_15-40-59

The famous Great Wall of China.

The city lights of Beijing :)

The city lights of Beijing :)

Read more
Luca Paulina

Juju GUI 2.0

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

  • Add charms and bundles from the charm store
  • Configure services
  • Deploy applications to a cloud of their choice
  • Manage charm settings
  • Monitor model health

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.

1. Improve the functionality of the core features of the GUI

  • Organised similar areas of the core navigation to create a better UI model.
  • Reduced the visual noise of the canvas and the inspector to help users navigate complex models.
  • Introduced a better flow between the store and the canvas to aid adding services without losing context.
Hero before
Hero after

‹ ›

Empty state of the canvas

 

Hero before
Hero after

‹ ›

Integrated store

 

Hero before
Hero after

‹ ›

Apache charm details

 

2. Reduce cognitive load and pace the user

  • Reduced the amount of interaction patterns to minimise the amount of visual translation.
  • Added animation to core features to inform users of the navigation model in an effort to build a stronger concept of home.
  • Created a symbiotic relationship between the canvas and the inspector to help navigation of complex models.
Hero before
Hero after

‹ ›

Mediawiki deployment

 

3. Provide an at-a-glance understanding of model health

  • Prioritised the hierarchy of status so users are always aware of the most pressing issues and can discern which part of the application is effected.
  • Easier navigation to units with a negative status to aid the user in triaging issues.
  • Used the same visual patterns throughout the web app so users can spot problematic issues.
Hero before
Hero after

‹ ›

Mediawiki deployment with errors

 

4. Surface functions and facilitate task-driven navigation

  • Established a new hierarchy based on key tasks to create a more familiar navigation model.
  • Redesigned the inspector from the ground up to increase discoverability of inspector led functions.
  • Simplified the visual language and interaction patterns to help users navigate at-a-glance and with speed to triage errors, configure or scale out.
  • Surfaced relevant actions at the right time to avoid cluttering the UI.
Hero before
Hero after

‹ ›

Inspector home view

 

Hero before
Hero after

‹ ›

Inspector errors view

 

Hero before
Hero after

‹ ›

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.



<>

Read more
Luca Paulina

Design in the open

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:

  • We used different digital locations for storing their design outcomes and assets (Google Drive, Google Sites and Dropbox).
  • The entire company used Google Drive so it was ideal for access, but its lacklustre performance, complex sharing options and poor image viewer meant it wasn’t good for designs.
  • We used Dropbox to store iterations and final designs but it was hard to maintain developer access for sharing and reference.
  • Conversations and feedback on designs in the design team and with developers happened in email or over IRC, which often didn’t include all interested parties.
  • We would often get feedback from teams after sign-off, which would cause delays.
  • Decisions weren’t documented so it was difficult to remember why a change had been made.

Finding the right tool

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:

  • Issues should be created for each project.
  • All designs/ideas/wireframes should be added inline to the issues.
  • All conversations should be held within GH, no more email or IRC conversations, and notes from any meetings should be added to relevant issues to create a paper trail.

Reaction

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:

  • Most employees of Canonical have a GH account and can see our work and provide feedback without needing to adopt a new tool.
  • Project management and key stakeholders are able to see what we’re doing, how we collaborate, why a decision has been made and the history of a project.
  • Provides us with a single source for all conversations which can happen around the latest iteration of a project.
  • One place where anyone can view and download the latest designs.
  • A single place for people to request work.

Conclusion

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.

GH_conversation_new_navigation

Read more
Steph Wilson

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).

delete_me_my_pic

You can read Davide’s blog here, and reach out to him on Github and Twitter with @davidedc.

Tell us a bit about your background?

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.

What do you think makes a good project manager?

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.

Apart from calendars, Kanban boards and post-it notes  – what else can be used to help teams collaborate smoothly?

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”.

What brings you to the Open Source world?

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.

Have you got any side projects you’re currently working on?

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!

What was the most interesting thing you’ve learned in your first week here?

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
Steph Wilson

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.

What is OwnCloud?

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.

We covered:

  • First case usage – the first point of entry for the user, maybe a file manager or a possible tooltip introduction.
  • Convergent thinking – how the app looks across different surfaces.
  • Top-level navigation – using the header to display actions, such as settings.
  • Using Online Accounts to sync other accounts to the cloud.
  • Using sync frequency or instant syncing.

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.

 

Read more
Andrea Bernabei

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.

What I do at Ubuntu

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.

My talk – “Standing on the shoulders of giants: developing Ubuntu convergent apps with Qt”

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.

A slideshow or an app? How about both!

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!

The sourcecode and the PDF version of the presentation is available here and my fork of the QML presentation system is available here.

And here’s a screenshot of the livecoding view in action (sparkling particle effect included) :)

livecoding_Screenshot_2016-06-15_09-13-38

The morning

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!

13173300_1020935067988814_8428457406371463764_o

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).

And then it came to lunchtime…

Food…Italian food

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…

13131744_1020935184655469_8301292868650133109_o

Afternoon talks

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 :)

13131322_1020935404655447_4502313797681298972_o

Closing remarks

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
James Mulholland

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:
http://ubuntuonair.com/

image

For more information regarding Dan Wood and his work, be sure to stop by his Google Plus. You can also stop by Dan’s Owncloud Telegram Group anytime and talk about the application with its creator.

We look forward to seeing you there!

Read more
Grazina Borosko

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.

Top 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
Carla Berkers

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.

Alpha release: getting the basics right

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:

  1. Choose the cloud configuration from a range of OpenStack optionsChoose cloud configuration
  1. Select the hardware the cloud should be built on
    Select the hardware
  1. View deployment status while the cloud is being built
    View deployment status
  1. Monitor the status and usage of the cloud
    Monitor 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.

Beta release: feedback and improvements

Providing a better overview: increased clarity in the dashboard

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.

dashboard-sketches

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:
Improved dashboard graphs

Setting users up for success: information and help before the process begins

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.

Increasing transparency of the process: helping users anticipate what they need and when configuration is complete

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.

Autopilot walk-through

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.

BR_step-by-step

GA release: getting Autopilot ready for the general public

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.

Testing without the hardware: try Autopilot on VMware

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!

Supporting customisation:  user-defined roles for selected hardware

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.

Machine roles

Allowing users more control: a scalable cloud on monitored 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.

BR-Nagios

The benefits of early release

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.

 

Read more
Rae Shambrook

Colour palette updates

Over the past few months, we’ve given you a peek into our evolving Suru design language with our wallpaper, convergence and Clock App blog posts.

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.

colour_palette

The new palette

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.

 

nearby_scopes
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.

Changing the use of orange

Previously orange was liberally used throughout our SDK, however such wide-ranging use of orange caused a number of UX issues:

  • Orange is so close to red that, at a glance, components could be misconstrued to be in an error state when in fact their current state was nominal.
  • Because orange is so close to red, the frequent use of orange made it harder for users to pick out actual error states in the UI.
  • Orange attracts the eye to wherever it is used, but frequently these elements didn’t warrant such a high level of visibility.

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:

  • Improved visual hierarchy
  • Made error states instantly recognisable
  • Enabled the use of an orange frame as the keyboard navigation focus state

Usage of blue

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.

 

Inbox
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.

The future for the palette

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
Steph Wilson

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.

Why do we need design guidelines?

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.

What’s to come?

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…

Screen Shot 2016-05-03 at 09.50.13

Screen Shot 2016-05-11 at 14.35.25

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.

All new sections

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.

Over to you…

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