Canonical Voices

Posts tagged with 'design'

Tom Macfarlane

Our stand occupied the same space as last year with a couple of major
changes this time around – the closure of a previously adjacent aisle
resulting in an increase in overall stand space (from 380 to 456 square
metres). With the stand now open on just two sides, this presented the
design team with some difficult challenges:

  • Maximising site lines and impact upon approach
  • Utilising our existing components – hanging banners, display units,
    alcoves, meeting rooms – to work effectively within a larger space
  • Directing the flow of visitors around the stand

Design solution

Some key design decisions and smaller details:

  • Rotating the hanging fabric banners 90 degrees and moving them
    to the very front of the stand
  • Repositioning the welcome desk to maximise visibility from
    all approaches
  • Improved lighting throughout – from overhead banner illumination
    to alcoves and within all meeting rooms
  • Store room end wall angled 45 degrees to increase initial site line
  • Raised LED screens for increased visibility
  • Four new alcoves with discrete fixings for all 10x alcove screens
  • Bespoke acrylic display units for AR helmets and developer boards
  • Streamlined meeting room tables with new cable management
  • Separate store and staff rooms

Result

With thoughtful planning and attention to detail, our brand presence
at this years MWC was the strongest yet.

Initial design sketches

Plan and site line 3D render

 


Design intent drawings

 

 

 

 

 

3D lettering and stand graphics

 

 

 

 

 

Read more
Anthony Dillon

Hack day 2

This week, the web team managed to get away for our second hack day. These hack days give us an opportunity to scratch our own itches and work on things we find interesting.

We wrote about our first hack day in August last year.

Getting started

We began by outlining the day and reviewing ideas that had been suggested on a Google Doc throughout the previous week by everyone on the team. We each voted by marking the ideas we would be interested in working. Then we chose the most voted ones and assigned groups of 2 or 3 people to each.

The groups broke up and turned their idea into a formal project with a list of the tasks required to produce an MVP. Below is a list of the ideas and outcomes from each team.

Performance audit of the current websites

Team: Rich, Andrea, Robin

The team discovered a tool called Lighthouse by Google Chrome which analyses a web page and returns a full audit of the dependent assets and accessibility issues.

The team spent some time trying to create a service using Lighthouse to produce an API, then realised that Google Chrome team had done this work already. The service is called Moonlight. Moonlight is a SaaS to test the performance of a page.

As Moonlight takes a single webpage endpoint to test., we need a way to recursively test pages. The team created a profiling script to gather the references endpoints of a site.

Canonical web team dashboard

Team: Luke, Ant, Yaili

The goal of this project was to motivate the team to improve key areas at a glance. The  metrics we wanted to capture were:

  • Whether the site is up or down
  • Live visitors countsMonthly unique visitors
  • Monthly unique visitorsOpen issues on the project
  • Open issues on the projectOpen PRs on the project
  • Open PRs on the project
  • Information about the last commit to the sites code base
  • PageSpeed insights tests results

We gathered a set of sites we would like to collect these metrics on:

  • www.ubuntu.com
  • www.canonical.com
  • maas.io
  • jujucharms.com
  • landscape.canonical.com
  • design.ubuntu.com
  • design.canonical.com
  • insights.ubuntu.com
  • developer.ubuntu.com
  • community.ubuntu.com
  • summit.ubuntu.com

The team used MERN stack (MongoDB, expressjs, React and Nodejs) and modified its sample project to create a interface which could be displayed depending on the state of the data. For example, the up or down card would display all sites as up but once one went down the card would change to an error state and only display the information about the site that is down. By designing for emotion in this way, we can intelligently utilise the limited space available in a dashboard.

The team also used a few plugins to gather some data:

  • ping-monitor to ping our sites to check if they’re up, down or broken
  • node-http-ping to get response times for the same set of Canonical sites

Storing the data in MongoDB to keep historical data and using the /api endpoint to return the response time and status for each site, the team managed to produce a simplified dashboard showing the available state of our list of sites.

Ubuntu.com dev tools

Team: Graham, Karl


As a team, we have been using gulp scripts to lint and test our code locally and in our CI environments for sometime. But we have never got around to applying these checks to our flagship website, www.ubuntu.com.

The plan here was to implement gulp scripts to lint Sass and JavaScript. And, to also look into further options like spell-checking, auto-prefixing and HTML validation.

The team added Sass linting and borrowed the linting tasks from our styling framework vanilla-framework. This produced a long list of lint issues. The team tracked the lint errors and quickly fixed them to get a passing CI run.

Adding JavaScript linting (jsHint)

The team also implemented JavaScript linting using jsHint on the current JavaScript within the sites code base. This produced a number of JavaScript lint errors which were fixed, ignoring the plugin code.

Finally adding the new linting steps to the Travis configuration. So the linting is tested on each pull request.

Vanilla web components prototype

Team: Barry, Will, Robin

To enable Vanilla on a variety of platforms. This would allow people to use Vanilla in modern web apps.

The team  created a base repository using Polymer’s tools and started creating web components for Vanilla.

They discovered that the styling needs tweaking to be compatible with web components. Possibly just by building a shared styles import which is included in each web component.

The team started by importing vanilla-framework from NPM, then built modular scss files containing only relevant parts from Vanilla, and finally imported the modular style file in web component.

Inside the repository there is a vanilla.html which imports all of the components. Components can individually be included as needed.

This work includes a demo system, with API documentation. The demo system displays the component and the markup used to create it. This is accessed by running `polymer serve` and accessing the site.

This work can be used to build solid web components for use in Polymer and we can also use this work to jumpstart React components.

HTTP/2 on vanillaframework.io

In the midst of all this work. Robin found time to tackle the task of hosting our styling frameworks website on HTTP/2. It’s currently a proof of concept but can now be considered as the start of work item to roll out.

Demo site

Conclusion

Again, this was a successful hack day with everyone busy working on things that interest them. Although there were less completed outcomes this time, we did set up a number of good projects which are ready to be continued.




Read more
Tom Macfarlane

Yakkety Yak

The Yakkety Yak 16.10 release animal artwork is now available to download here.

16.10 release animal

db_yak_logo-artwork

Origami Yak

img_7731

Initial design exploration

Design development – head detail

db_yak_heads

Final Yak

Colourways

T-shirt design

db_yak_t-shirt

Read more
Grazina Borosko

The Yakkety Yak 16.10 is released and now you can download the new wallpaper by clicking here. It’s the latest part of the set for the Ubuntu 2016 releases following Xenial Xerus. You can read about our wallpaper visual design process here.

Ubuntu 16.10 Yakkety Yak

yakkety_yak_wallpaper_4096x2304

Ubuntu 16.10 Yakkety Yak (light version)

yakkety_yak_wallpaper_4096x2304_grey_version

Read more
Tom Macfarlane

Ubuntu Core

Recently the brand team designed new logos for Core and Ubuntu Core. Both of which will replace the existing Snappy logo and bring consistency across all Ubuntu Core branding, online and in print.

 

db_core_logo-aw

 

Guidelines for use

Core

Use the Core logo when the Ubuntu logo or the word Ubuntu appears within the same field of vision. For example: web pages, exhibition stands, brochure text.

Ubuntu Core

Use the Ubuntu Core logo in stand alone circumstances where there is no existing or supporting Ubuntu branding or any mention of Ubuntu within text. For example: third-party websites or print collateral, social media sites, roll-up banners.

The Ubuntu Core logo is also used for third-party branding.

The design process

Extensive design exploration was undertaken considering: logotype arrangement, font weight, roundel designs – exploring the ‘core’ idea, concentric circles and the letter ‘C’ – and how all the elements came together as a logo.

Logotype

Options for how the logotype/wordmark is presented:

  • Following the design style set when creating the Ubuntu brandmark
  • Core in a lighter weight, reduced space between Ubuntu and Core
  • Ubuntu in the lighter weight, emphasis on Core
  • Core on its own

 

db_core_logotype

 

Roundels

Core, circles and the letter ‘C’

 


Design exploration using concentric circles of varying line numbers, spacing and line weights. Some options incorporating the Circle of Friends as an underlying grid to determine specific angles.

Circle of Friends

 

Design exploration using the Circle of Friends – in its entirety and stripped down.

Lock-up

 

db_core_lock-up

How the logotype and roundel design sit together.

Artwork

Full sets of Core and Ubuntu Core logo artwork are now available at design.ubuntu.com/downloads.

Read more
Inayaili de León Persson

A week in Vancouver with the Landscape team

Earlier this month Peter and I headed to Vancouver to participate in a week-long Landscape sprint.

The main goals of the sprint were to review the work that had been done in the past 6 months, and plan for the following cycle.

IRL

Landscape is a totally distributed team, so having regular face-to-face time throughout the year is important in order to maintain team spirit and a sense of connection.

It is also important for us, from the design team, to meet in person the people that we have to work with every day, and that ultimately will implement the designs we create.

I thought it was interesting to hear the Landscape team discuss candidly about how the previous cycle went, what went well and what could have been improved, and how every team member’s opinion was heard and taken into consideration for the following cycle.

 

Landscape team in VancouverLandscape team discussing the previous cycle

 

User interviews

Peter and I took some time aside to interview some of the developers in 1-2-1 sessions, so they could talk us through what they thought could be improved in Landscape, and what worked well. As we talked to them, I wrote down key ideas on post it notes and Peter wrote down more thorough notes on his laptop. At the end of the interviews, we collated the findings into a Trello board, to identify patterns and try to prioritise design improvements for the next cycle.

The city

But the week was not all work!

Every day we went out for lunch (unlike most sprints which provide the usual hotel food). This allowed us to explore a little bit of the city and its great culinary offerings. It was a great way to get to know the Landscape team a little bit better outside of work.

 

Vancouver foodLots of great food in Vancouver

 

Vancouver also has really great coffee places, and, even though I’m more of a tea person, I made sure to go to a few of them during the week.

 

Vancouver coffeeNice Vancouver coffee

 

I took a few days off after the sprint, so had some time to explore Vancouver with my family. We even saw a TV show being filmed in one of our favourite coffee shops!

 

Exploring VancouverExploring Vancouver

 

This was my first time in Canada, and I really enjoyed it: we had a great sprint and it was good to have some time to explore the city. Maybe I’ll be back some day!

Read more
Rae Shambrook

Recently I have been working on the visual design for RCS (which stands for rich communications service) group chat. While working on the “Group Info” screen, we found ourselves wondering what the best way to display an online/offline status. Some of us thought text would be more explicit but others thought  it adds more noise to the screen. We decided that we needed some real data in order to make the best decision.

Usually our user testing is done by a designated Researcher but usually their plates are full and projects bigger, so I decided to make my first foray into user testing. I got some tips from designers who had more experience with user testing on our cloud team; Maria  Vrachni, Carla Berkers and Luca Paulina.

I then set about finding my user testing group. I chose 5 people to start with because you can uncover up to 80% of usability issues from speaking to 5 people. I tried to recruit a range of people to test with and they were:

  1. Billy: software engineer, very tech savvy and tech enthusiast.
  2. Magda: Our former PM and very familiar with our product and designs.
  3. Stefanie: Our Office Manager who knows our products but not so familiar with our designs.
  4. Rodney: Our IS Associate who is tech savvy but not familiar with our design work
  5. Ben: A copyeditor who has no background in tech or design and a light phone user.

The tool I decided to use was Invision. It has a lot of good features and I already had some experience creating lightweight prototypes with it. I made four minimal prototypes where the group info screen had a mixture of dots vs text to represent online status and variations on placement.  I then put these on my phone so my test subjects could interact with it and feel like they were looking at a full fledged app and have the same expectations.

group_chat_testing

During testing, I made sure not to ask my subjects any leading questions. I only asked them very broad questions like “Do you see everything you expect to on this page?” “Is anything unclear?” etc. When testing, it’s important not to lead the test subjects so they can be as objective as possible. Keeping this in mind, it was interesting to to see what the testers noticed and brought up on their own and what patterns arise.

My findings were as follows:

Online status: Text or Green Dot

Unanimously they all preferred online status to be depicted with colour and 4 out of 5 preferred the green dot rather than text because of its scannability.

Online status placement:

This one was close but having the green dot next to the avatar had the edge, again because of its scannability. One tester preferred the dot next to the arrow and another didn’t have a preference on placement.

Pending status:

What was also interesting is that three out of the four thought “pending” had the wrong placement. They felt it should have the same placement as online and offline status.

Overall, it was very interesting to collect real data to support our work and looking forward to the next time which will hopefully be bigger in scope.

group_chat_final

The finished design

Read more
Jouni Helminen

We have been looking at ways of making the Terminal app more pleasing, in terms of the user experience, as well as the visuals.

I would like to share the work so far, invite users of the app to comment on the new designs, and share ideas on what other new features would be desirable.

On the visual side, we have brought the app in line with our Suru visual language. We have also adopted the very nice Solarized palette as the default palette – though this will of course be completely customisable by the user.

On the functionality side we are proposing a number of improvements:

-Keyboard shortcuts
-Ability to completely customise touch/keyboard shortcuts
-Ability to split the screen horizontally/vertically (similar to Terminator)
-Ability to easily customise the palette colours, and window transparency (on desktop)
-Unlimited history/scrollback
-Adding a “find” action for searching the history

email-desktop

Tabs and split screen

On larger screens tabs will be visually persistent. In addition it’s desirable to be able split a panel horizontally and vertically, and use keyboard shortcuts or focusing with a mouse/touch to move between the focused panel.

On mobile, the tabs will be accessed through the bottom edge, as on the browser app.

terminal-blog-phone

Quick mobile access to shortcuts and commands

We are discussing the option of having modifier (Ctrl, Alt etc) keys working together with the on-screen keyboard on touch – which would be a very welcome addition. While this is possible to do in theory with our on-screen keyboard, it’s something that won’t land in the immediate near future. In the interim modifier key combinations will still be accessible on touch via the shortcuts at the bottom of the screen. We also want to make these shortcuts ordered by recency, and have the ability to add your own custom key shortcuts and commands.

We are also discussing with the on-screen keyboard devs about adding an app specific auto-correct dictionary – in this case terminal commands – that together with a swipe keyboard should make a much nicer mobile terminal user experience.

email-desktop

More themability

We would like the user to be able to define their own custom themes more easily, either via in-app settings with colour picker and theme import, or by editing a JSON configuration file. We would also like to be able to choose the window transparency (in windowed mode), as some users want a see-through terminal.

We need your help!

These visuals are work in progress – we would love to hear what kind of features you would like to see in your favourite terminal app!

Also, as Terminal app is a fully community developed project, we are looking for one or two experienced Qt/QML developers with time to contribute to lead the implementation of these designs. Please reach out to alan.pope@canonical.com or jouni.helminen@canonical.com to discuss details!

EDIT: To clarify – these proposed visuals are improvements for the community developed terminal app currently available for the phone and tablet. We hope to improve it, but it is still not as mature as older terminal apps. You should still be able to run your current favourite terminal (like gnome-terminal, Terminator etc) in Unity8.

Read more
Steph Wilson

Back in June we hosted a competition that asked developers to use the AdaptivePageLayout component from the UI toolkit to create an app that converges across devices. We had some very impressive entires that used the component in different ways; choosing a winner was hard. However, after testing all the apps the design team chose a winner: the Timer App.

How does the AdaptivepageLayout work?

The AdaptivePageLayout component eliminates guesswork for developers when adapting from one form factor to another. It works by tracking an infinite number of virtual columns that may be displayed on a screen at once. For example, an app will automatically switch between a 1-panel and 2-panel layout when the user changes the size of the window or surface, by dragging the app from the main stage to the side stage.

You can read more about convergence and how the adaptive page layout works in the App design guides.

Timer app

The Timer app impressed the design team the most with its slick transitions, well thought-out design and ease of use. It used the AdaptivepageLayout well when it translated to different screens.

Design feedback

  • Design: well-considered touches with design, animation and various cool themes.
  • Usability: a favourite is the ability to drag seconds / minutes / hours directly on the clock.
  • Convergence: adjusts beautifully to different screen sizes.

Screen Shot 2016-08-09 at 09.10.32

Screen Shot 2016-08-09 at 09.14.14

Timer app

Other entries

Thank you to all who participated in making their apps look even more slick. Here are the other entries:

2nd: AIDA64 App

  • Design: clean, readable with clear content
  • Usability: pretty flawless
  • Convergence: Adaptive Page Layout suits this type of application well and is used well

3rd: Movie Time

  • Design: functional with good management of all the content
  • Usability: live results for search works smoothly as well as trailer links
  • Convergence: the gridview of poster art lends itself well to various screen sizes

4th: Ubuntu Hangups

  • Design: clean and follows guidelines well
  • Usability: easy to message / chat, with user-friendly functionality
  • Convergence: easy to use particularly on Phone and Tablet

5th: uBeginner

  • Design: basic and clean
  • Usability: information is well-presented
  • Convergence: uses the Adaptive Page Layout well

Try it yourself!

To get involved in building apps, click here.

Read more
Andrea Bernabei

Refreshed scrollbars!

You may have noticed that the scrollbars available on Ubuntu Touch and the Unity8 environment have recently received a huge overhaul in both visual appearance and user experience. More specifically, we redesigned the Scrollbar component (which is already provided in the Ubuntu UI Toolkit) and added a new ScrollView component that builds on top of it and caters for convergence.

Technical note to app developers: the Scrollbar component is still available for compatibility purposes, but we recommend transitioning to the new and convergent ScrollView.

How did we do it?

The process was as follows:

  • Interaction design was specified
  • Applied visual style to the component
  • Prototyped the component
  • Iterated over design and performed user testing
  • Sent for review to the SDK team and integrated into the UI toolkit.

We started by researching the field, exploring the possibilities and thoroughly analyzing the history of the scrollbar component. The output of this step was an interaction specification. The visual design team picked that up and applied our visual style to the component, ensuring a consistent visual language across all the elements provided by the UI Toolkit.

Once we had a first draft of the interaction and visual specs, we created a prototype of the component.
We then iterated over the design choices and refined the prototype. While iterating we also took into account the results of the user testing research that we conducted in the meanwhile. The testers found the new scrollbars easy to use and visually appealing. The only pain point highlighted by the research were the stepper buttons, that were deemed a bit small. We refined them by creating a new crispier graphic asset and by tweaking their size as well as the visual feedback they provided, especially when being hovered with a mouse.

Once we were happy with the result, we submitted our work to be reviewed by the SDK team. The SDK team are the final gatekeeper and decide whether the implementation of a component is ready to be merged to the UI Toolkit or not. The review process can be lengthy, but it is of great help in ensuring a higher code quality, less bugs and clearer documentation. Once the SDK team gave the green light, the component was merged to the next release of the UI Toolkit.

What did we change?

A critical requirement of the new solution was to be “convergence-ready”. Convergence means implementing a UI that scales not just across form factors, but also across different input devices. This is particularly important in the case of scrolling, as it must be responsive to all input devices.

The new ScrollView can be interacted with using the touchscreen of your phone or tablet, but thanks to convergence, now your tablet can turn into a full fledged computing device with a hardware keyboard and a pointer device, such as a mouse. The component must be up to the task and adapt to the capabilities provided by the input device which is currently in use.

At any time, the new scrollbar can be in one of the 3 following modes:

  • Indicator mode, where the scrollbar is a non-interactive visual aid;
  • Thumb mode, that allows quick scrolling using a touch screen;
  • Steppers mode, optimized for pointer devices interactions.

Let’s go through the modes in more detail.

Indicator mode

Whenever the user scrolls content without directly interacting with the scrollbar, i.e. he or she performs a flick or uses the mouse wheel or keyboard keys, the scrollbar gently fades in as an overlay on top of the content. In this mode the scrollbar is not interactive, and just acts as a visual aid to provide information about the position of the content. The indicator gently fades out following a short timeout after the surface stops scrolling.

Please note: we will be replacing these images with GIFs soon.

scrollview-touch

 

Thumb mode

Imagine you want to send a picture to a friend of yours, but the file is somewhere down the very lengthy grid of pictures. Let’s also suppose you’re using a smartphone or tablet and you have no mouse or keyboard connected to it. Wouldn’t it be handy to have a way to quickly scroll a long distance without having to repeatedly flick the list? We designed Thumb mode to address that use case.

When the content on screen reaches a length of 10 or more pages, the thin indicator provided by the indicator mode grows thicker into an interactive thumb. That marks the transition to the Thumb mode. While the scrollbar is in Thumb mode you can drag the thumb using touchscreen to quickly scroll the content.

The component still fades out when the user stops interacting with the surface and the surface stops scrolling, in order to leave as much real estate to the application content as possible.

Stepper mode

scrollview-pointer

When the user is interacting with the UI using a pointer device, they expect a different experience than a touchscreen. Pointer devices allow for much more precise interactions and also provide different ways of interacting with the UI components, such as hovering. A good convergent component exploits those additional capabilities to provide the best user experience for the input device which is currently in use.

When the user hovers over the area occupied by the (initially hidden) scrollbar, the bar reveals itself, this time in what we call Stepper mode.

This mode is optimized for pointer device interactions, although it can be interacted with using touchscreen as well. More generally, for a component to be defined convergent the user must be able to start interacting with it using one input device (in this case, a mouse) and switch to another (e.g. touch screen) whenever they wish to. That transition must be effortless and non disruptive.

When in Stepper mode, the scrollbar has a thick and interactive thumb. This is similar to the Thumb mode we presented in the previous section. However, Stepper mode also provides a semi-transparent background and the two clickable stepper buttons desktop users are already accustomed to. The steppers buttons can be clicked to scroll a short distance. Holding a stepper button pressed will scroll multiple times.

The areas above and below the thumb are also interactive. You can click/tap or press-and-hold to scrolling by one or more pages.

Once the user moves the pointer away from the scrollbar area and the surface stops scrolling, the component elegantly fades out, just like in the other modes.

Visual convergence

We put a lot of efforts into making the transitions between the different modes as smooth and visually pleasing as possible. The alignment of the sub components (the thumb, its background, the stepper buttons), their sizes, their colours have been carefully chosen to achieve that goal.

When the bar grows from Indicator to Thumb modes and vice versa, it does so by anchoring one side and expanding only the opposite one. This minimizes unexpected movements and produces a simple yet crisp animated transition. Those same principles also apply to the transitions from thumb to stepper modes and indicator to stepper and vice versa. We wanted to create transitions that would look elegant but not distrustful.

The new scrollbar also provides visual aids to indicate when a pointer device is hovering over any of the sub components. Both the stepper buttons and the thumb react to hovering by adjusting their colours.

Scroller variations

Interaction handling convergence

A lot of effort has gone into tweaking the interactions to provide an effortless interaction model. Here’s a summary of how we handle touch screen and pointer devices:

  • Thumb mode features a thicker interactive thumb to allow quick scrolling using touch screen;
  • Press-and-holding the steppers buttons provides an effortless way to perform multiple short scrolls;
  • Press-and-holding the areas above and below the thumb makes provides easy multiple page scrolling;
  • Mouse hovering is exploited to reveal or hide the scrollbar;
  • Visual feedback on press/tap;
  • Visual feedback on pointer device hover.

It is a lot of small (and sometimes trivial!) details that make up for a great user experience.

Some of you might be wondering: “what about keyboard input?”

I’m glad you asked! That is an important feature to realize full convergence. The ScrollView components handles that transparently for you. Scrolling content using the keyboard is just as easy as scrolling using the touchscreen or any pointer device:

  • Arrow keys trigger a short scroll;
  • PageUp/PageDown trigger a page scroll;
  • Home/End keys trigger scrolling to the top/bottom of the content, respectively
  • Holding a key down triggers multiple scrolls;

What did we achieve?

The new scrollbars fully implement our vision of convergence. The user can interact with any of the input device he has available and switch from one to the other at any time. The interactions feel snappy and we think the component looks great too!

We can’t wait for you to try it and let us know your opinion!

What does the future hold?

The focus so far has been on getting the right visual appearance and user experience.

However, in order to have a complete solution, we also need to make sure adding such a feature as scrollbars to the applications does not come with a big performance drawback. Ideally, all the scrollable surfaces (images, text fields, etc) should include a scrollbar and that means it’s very important to provide a component that is not just easy to use and visually appealing but also extremely performant.

There are two main aspects where the performance of this component comes into play: the performance of interactions, so that they happen immediately and without unexpected delays. I believe we’re in a very good shape there. The second is: the time it takes to create a scrollbar when an application needs one; this affects application startup time and the time it takes to load a new view that holds scrollable content.

A few changes have already been implemented, which has resulted in a speed-up of about 25%. These changes should be released with OTA13.

If you have ideas or want to provide any feedback, here are the contact details of the people who worked on this project.

IRC: #ubuntu-touch channel on FreeNode server

Alternatively, start a thread on the ubuntu-phone mailing list.

Read more
Steph Wilson

Last week we released phase 1 of the new App Design Guides, which included Get started and Building blocks. Now we have just released phase 2: Patterns. This includes handy guidance on gestures, navigation and layout possibilities to provide a great user experience in your app.

Navigation: user journeys

Find guidance for utilizing components for effective and natural user journeys within your UI.

750w_Navigation_UserJourney (2)

Layouts: using Grid Units

Use the Grid Unit System to help visualise how much space you have in order to create a consistent and proportionate UI.

750w_Layouts_GridUnitSystem

More to come…

More sections will be added to patterns in the future, such as search, accessibility and communication.

Up next is phase 3: System integration; which includes the number of a touchpoints your app can plug into inside the Ubuntu operating system shell, such as the launcher, notifications and indicators.

If you want to help us improve these guides, join our mailing list. We’d love to hear from you!

Read more
Steph Wilson

Meet the newest member of the design team, UX designer Raul Alvarez, who will be working on the Ubuntu convergence story. Raul will be bringing new ideas to improve our apps to allow for a seamless experience across all devices. We caught up with him to tell us more about his background and what attracted him to the open source world of Ubuntu.

raul

 

You can find Raul’s blog here and reach out to him on Twitter using his handle @raulalgo.

Tell me about your background

If we go all the way back to university, I started as a computer engineer student, but after a while I got to a point where I was rather burnt out by it. Then almost by chance, I ended up studying another degree in Advertising and PR. When studying my second degree I gained a fresh perspective. I was coming from studying maths and physics to then finding myself in classes for Spanish, history, law, and eventually design, which is where I got hooked.

I turned 30 and decided to move to London, as everyone in the small town of Salamanca (West Spain) was either getting married or bored; I was the latter. I wanted to challenge myself to do the most difficult things and push a bit more. I moved into designing Forex trading apps, which was a great experience with very smart people. I got to work very close with the developers too.

I then went into e-commerce as a designer, which was another diverse industry I wanted to learn from. Getting into something I know nothing about is key for me. It’s tricky, as people want experience, but once I’m there and I learn, I feel that I have the ability to take a fresh look at things. From studying advertising and knowing how apps are build I could bring those disciplines together to work on different platforms.

Canonical was a company I wanted to be part of. Just so happens they were looking for a designer, and now here I am!

Do you have any projects you’re working / or have worked on?

In the late days of my computer engineering degree, me and some fellow students started our own business. It was when the Social Network movie was out and everyone wanted to be Mark Zuckerberg; and so did we. We created a photography social network that was like a Flickr wannabe, or closer to what 500px is now. We had good intentions and we worked very hard on it. However, we lacked the business vision and strategy to push it forward. We had two choices: we close it off and do something else, or we find a better way to make money.

Salamanca is a small town and has little going on, but it just so happened that a company was doing mobile apps on demand for clients. Instead of hiring more people when they had large spikes of work, they would reached out to other companies. My three partners were playing the role of developers and I was the designer. We spent four years designing mobile apps for various clients specific needs, most came from the advertising industry. We had some startups come to us who didn’t have much money and we would help them advertise and prototype their apps. It was always a rather constrained working environment with a low budget and working with trial and error.

What attracted you to the open source world of Ubuntu?

For me, being here is amazing because I had been using a laptop that ran Ubuntu in my uni days. I’ve always known open source and the ideas around it. I remember playing with Linux when I was at high school too.

What does UX mean to you?

User Experience (laughs). But seriously, I think the term ‘UX’ is thrown back and forth a lot and people forget what it means. It’s a lot of ideas that could or could not be UX.

People might think that UX is just associated with apps and web design. But it’s not. If you think about user experience, it’s in everything. You can use user experience to build your hotel for instance. I could say how is the lobby going to be decorated, what is the uniform going to be like, do I want the guests to find a little chocolate under their pillow? THAT is defining the user experience. You don’t need to do a lot of research. Well, you can research user experience in other hotels, that would be one approach. Or you can say I have this vision I want to make my approach work. For this you need good judgement and to think about people, but also be prepared to take risks.

One of the parts I enjoy most about designing is whenever I don’t know what I’m going to do. That is the fun bit.

What have you learned in your first week at Canonical?

I came here thinking I knew how complex an operating system was. I wasn’t even close. I realised the complexity was way down below, every single little thing is taken into account, which amazes me. Then I realised the scale of the task. It’s amazing how much work is going on here. I have a lot of respect for it.

What is your proudest achievement?

Making a decision like: I’m stuck and I need a change. I made the effort to move to a different country and to change my degree. It has always been very natural for me to take risks, but I didn’t realize how scary it actually is until I stop and think about it.

Read more
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 </><style=”font-weight: 400;”>homepage</><style=”font-weight: 400;”> and we’re very happy to announce that it is now live!

Juju is an application and service modelling tool that enables you to quickly model, configure, deploy and manage applications in the cloud. Juju comes with ready-made solutions for everything you need – these solutions are encapsulated in Charms and Bundles:

  • Charms contain all the instructions necessary to deploy, manage and scale cloud applications.
  • Bundles are collections of charms that work together, deploying an entire application or chunk of infrastructure in one go.

The new Juju Charm store allows you to explore the growing ecosystem of over 300 charms and bundles – everything you need to build your app.

You can now get started with the featured charms and bundles at the top or explore the whole collection of categories:

Screen Shot 2016-07-18 at 12.53.40

 

We’ve surfaced key categories and highlighted their most popular services:

Screen Shot 2016-07-18 at 12.54.36

Screen Shot 2016-07-18 at 12.55.28

 

The search stays the same for now, but we’re working on improvements which will be released in the near future:

 

Screen Shot 2016-07-18 at 12.59.10

 

You can explore bundles and view charm details:

Screenshot 2016-07-10 14.10.08

Screenshot 2016-07-10 14.11.20

 

And deploy your chosen charm, using the GUI or CLI:

 

Screenshot 2016-07-10 14.13.20

 

Check it out at:https://jujucharms.com/store

 

How did we arrive at this solution?

We’ve summarised four of the most important stages of the project for you to get an insight into our design process.

  1. Defining the problem

You may want a shiny new design, but if you don’t understand the problems that you are trying to solve you’ll probably find yourself having to redesign the whole page again in no time. We therefore began by identifying the issues that we wanted this new design to tackle,  and laying out the new store requirements.

This is what the store homepage looked like before the redesign:

 

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

 

The original goal of this page was to feature the breadth of the software available for Juju. However, there were a number of elements in our previous design that didn’t facilitate a smooth browsing experience. As the Juju ecosystem grew, we found the need to increase the store’s performance by:

  • Providing a more curated selection to users when they arrive at the store
  • Highlighting the most popular and interesting charms and bundles for users to get started
  • Providing better discovery methods for browsing
  • Encouraging exploration
  • Reducing cognitive load
  • Helping visitors find what they’re looking for with the least amount of friction.

 

  1. Understanding our audience

Before making any design decisions we:

  • Conducted a round of user testing to uncover friction points and reveal insights into our users’ behaviour and needs.
  • Dived into our site’s analytics to learn more about how current users are moving across the store.
  • Looked at conversion, bounce rate and page views.
  • Identified what search terms are used most and what terms and categories were the most popular.
  • Tagged our content to increase findability.

It’s a surprisingly large amount of prep work but absolutely essential – all this research enabled us to gain some insight into our audience and allowed the definition of use cases which we then used as a basis for our designs.

 

  1. Researching our competitors

We also undertook a competitor benchmarking project with the aim of:

  • Comparing our general practices and performance with that of our competitors
  • Identifying the strengths and weaknesses of our competitors and review that against our own.
  • Identifying pitfalls to avoid and ways in which we could improve our page.

IMG_2367_4352b

 

  1. Test the performance

Testing the design enabled us to continuously iterate towards a solution that, when finalised, was very well received by the community. We love conducting user testing sessions to see how our designs are performing, and it’s hard to over-emphasise the importance of watching actual people interact with your design!

We’ve enjoyed every stage of this process and are very happy it is now available to the public. We’d welcome any feedback, please don’t hesitate to share it here. Check it out here

 

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