Canonical Voices

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

How we introduced Scrum to the Web Team

At the beginning of the year our team – who look after the core websites in the Ubuntu ecosystem – decided to adjust our project delivery process and go full-on Scrum. This is hardly shocking news these days. Actually, you can find way more people writing about how they decided to ditch Scrum and what a terrible idea it was to begin with. But for us, it seemed like a good thing to try and so far the results are promising.

Happy Web Team sprinting Happy Web Team sprinting on the 16.04 release day

What is Scrum?

Scrum was born as a framework to manage the development of complex products where the traditional project methodologies failed. It has a very simple set of rules that are best explained by its founding fathers Ken Schwaber and Jeff Sutherland in the Scrum Guide. Unfortunately, over the years the simple framework has been – on the one hand – contaminated with various additional concepts and on the other, diluted by assumption that Scrum can work in any context or on a pick-and-choose basis.

When you think Scrum do you think user stories, burndown charts and planning poker?

Well, that is what I thought before I realised that all these things are NOT part of Scrum but the optional additions, which sometimes can help but sometimes can be detrimental.

Life before Scrum

I joined the Canonical Web Team at the end of last year in a project manager’s role. At that point, the team was experimenting with introducing some of the Scrum artifacts, like sprint planning and retrospective, into an already familiar Kanban method.

What worked

Standups were a daily bread for the team and kept everyone in the loop. Retrospectives made us reflect on the ways we work and how we can improve. Team members were skilled at planning their tasks and progressing through their work. The fact that we are a relatively small team based in the same space also helped with communication and collaboration.

What didn’t work

It felt like the partial adoption of Scrum was not really allowing us to reap all positive effects. We operated on a one week sprint basis. We had planning sessions at the start of the sprint but they were mostly focused on tasks for individual team members rather than team working out what we can complete each sprint and how to make it happen. We also didn’t involve the stakeholders in our meetings, so often team members didn’t have a good understanding of the business context behind the projects.

Our log of current and incoming work was massive, recorded in few different places, and often not very well defined. We work with multiple stakeholders from different functions and product lines. We also have a handful of internal projects aimed at improving our ways of working (for example a great Vanilla framework initiative you can read about here). It was a challenge for us to understand our short and long term priorities. It also felt that we can benefit if we make the stakeholders a part of the prioritisation and planning exercise.

Life after Scrum

Our team was one leg in the Scrum already and it intuitively felt that pushing it further could help us resolve at least some of the above mentioned problems.

Sprint changes

We extended the duration of our sprints to two weeks in order to have enough time to complete usable product increments. Bonus – it reduced the overhead of weekly planning and review sessions.

We shifted our thinking about what we take on each sprint from the task level items to the backlog level items which ideally, should be demonstrable at the end of the sprint. The goal is also to get better at understanding our velocity, improve estimation and therefore be more accurate in planning what we can accomplish in two week’s timeframe.

This change created a more sustainable work pace while at the same time added a sense of urgency  around most important work. Sprint clock is ticking, we know what we planned to complete and from day one we do our best to succeed. As mentioned by one of our developers, “Team now has bi-weekly rhythm and greater visibility of overall team goals in any given sprint. There is a constant march of progress”.

Introducing a backlog

Product backlog is one of the Scrum artifacts and our team didn’t really have one before. We decided to replace all docs and tools where we captured upcoming projects with one simple spreadsheet, hosting all briefs and other relevant project info. This allowed us to surface all the work that team had in the pipeline, including the internal improvements that didn’t have any owners outside of the Web Team. This new format supports us in defining and building the consensus about our priorities.

One additional shift related to our estimation process. We decided to discard task estimating altogether for the simplicity and focus only on the backlog items. The principle is that the higher the project is in the backlog, the more we break it down into small increments so our estimates are more accurate. We started with a big backlog refining session to get a better understanding of what we have in the pipeline. We now use the burnup chart which I update at the end of the sprint and it helps us to predict when, roughly, we may get to the projects that are further down the pipeline.

Meetings, meetings and few more meetings

We decided to introduce new meetings and slightly alter the existing ones. Every two weeks our Tuesday schedule is pretty hectic but it feels like it actually saves us time in the long run.

We start with a sprint review meeting for all team members and stakeholders. That’s where we look at what was planned for the sprint, demo what we completed and – if needed – explain what we didn’t manage to finish and why. We then move to the backlog planning session with the same group, agreeing what should make its way to the next sprint, clarifying outstanding questions and talking through new briefs that came in the meantime.

The second set of meetings involves only the Web Team. We first run our usual retrospective and after that, we plan the next sprint in details. We discuss all backlog items planned for the sprint, identify tasks needed to complete them and team members pick what they will be working on. After this exercise, even without estimating, we get a pretty good idea whether we’re overloaded or we need to add more work.

So far the review and planning meeting with the business turned out well and helped to improve the communication, understanding of everyone’s work, and consensus about the priorities. As one of team members pointed out, “stakeholders now have to agree to work beforehand and any ad-hoc work inserted into the iteration visibly impacts on our initial commitment”.

Scrum isn’t always a walk in the park

The beauty of Scrum is that it’s lightweight and in principle, simple to understand. It doesn’t mean however that running projects with Scrum is not difficult. Below I outlined what I see currently as our key challenges.

Launch deadlines vs. sprint schedule

Some of our web projects have strict launch dates as they are tied to specific events, such as a launch of new device. More often than not, these fall somewhere within the sprint duration so we can’t simply finish them at the end of the sprint. One way of addressing it would be to schedule them in the preceding sprint however we are rarely able to gather all necessary bits of information beforehand. For now, we just accept the fact that some items in our sprint have a higher priority and need to be released before the sprint ends.

Sprint planning and estimates

More often than not, by the end of the sprint we realise that we won’t complete all scheduled backlog items. We try not to make a big drama out of it – apparently it happens roughly half of the time even for mature Scrum teams – but at times, it deflates a sense of accomplishment. We can definitely improve how we break our backlog items, and our estimates are still sometimes based on a wishful thinking. There is also too much temptation to add more to a backlog than our velocity predicts – we try to resist it, with mixed effects.

Getting stakeholders on board

Introducing stakeholders to our planning and review process was seen by the whole team as a huge improvement, yet working with clients – either internal or external – is not always a piece of cake. We sometimes struggle to get good briefs and all necessary information before the sprint starts, and every now and then we get a cheeky request to fit something new in. It’s a long process to get everyone follow the rules and we are only at the beginning!

Bugs and business as usual

This seems to be quite a common problem for many Scrum teams – how should we deal with bugs and small requests (like copy changes) that come during the duration of the sprint? We considered postponing them until the next planning meeting where we would determine which ones we add into a sprint. Eventually, we decided we would spend more time discussing and planning these things than it actually takes to resolve them. Therefore, we assume that a small percentage of team’s velocity (about 10%) will be spent on dealing with these. That’s not quite in line with Scrum principles and we don’t have a good way to measure yet what’s the actual impact of such work.

Happy Scrum, everyone!

Scrum doesn’t work everywhere and for everyone but our team is happy with the direction we moved to, which often comes back in our retrospectives. Empowerment, openness, collaboration, and better structure have been mentioned by several team members. It’s really remarkable how easily everyone adjusted to the new process and team’s commitment to make the whole thing work has been invaluable.

We are only in our seventh sprint now and are still on the steep learning curve, making adjustments as needed. Like anything in this world, Scrum is not perfect but maybe the greatest thing about it is that it keeps continuous adaptation at its core so within each cycle, we can look back and change what we don’t like.

Want to learn how to be a Scrummaster or Product Owner yourself?

Before we started our transition to Scrum I completed the Scrum Master and Product Owner training classes with Martine Davos at Skills Matter in London, UK, which I highly recommend for any Scrum newbies.

Read more
Grazina Borosko

April marks the release of Xerus 16.4 and with it we bring a new design of our iconic wallpaper. This post will take you through our design process and how we have integrated our Suru visual language.

Evolution

The foundation of our recent designs are based on our Suru visual language, which encompasses our core brand values, bringing consistency across the Ubuntu brand.

Our Suru language is influenced by the minimalist nature of Japanese culture. We have taken elements of their Zen culture that give us a precise yet simplistic rhythm and used it in our designs. Working with paper metaphors we have drawn inspiration from the art of origami that provides us with a solid and tangible foundation to work from. Paper is also transferable, meaning it can be used in all areas of our brand in two and three dimensional forms.

Design process

We started by looking at previously released wallpapers across Ubuntu to see how each has evolved from each other. After seeing the previous designs we started to apply our new Suru patterns, which inspired us to move in a new direction.

Ubuntu 14.10 ‘Utopic Unicorn’’

wallpaper_unicorn

Ubuntu 15.04 ‘Vivid Vervet’

suru-desktop-wallpaper-ubuntu-vivid (1)

Ubuntu 15.10 ‘Wily Werewolf’

ubuntu-1510-wily-werewolf-wallpaper

Step-by-step process

Step 1. Origami animal

Since every new Ubuntu release is named after animal, the Design Team wanted to bring this idea closer to the wallpaper and the Suru language. The folds are part of the origami animal and become the base of which we start our design process.

Origarmi

To make your own origami Xerus squirrel, you can find the instructions here.

Step.2 Searching for the shape

We started to look at different patterns by using various techniques with origami paper. We zoomed into particular folds of the paper, experimented with different light sources, photography, and used various effects to enhance the design.

The idea was to bring actual origami to the wallpaper as much as possible. We had to think about composition that would work across all screen sizes, especially desktop. As the wallpaper is a prominent feature in a desktop environment, we wanted to make sure that it was user friendly, allowing users to find documents and folders located on the computer screen easily. The main priority was to not let the design get in the way of everyday usage, but enhance it aesthetically and provide a great user experience.

After all the experiments with fold patterns and light sources, we started to look at colour. We wanted to integrate both the Ubuntu orange and Canonical aubergine to balance the brightness and played with gradient levels.

We balanced the contrast of the wallpaper color palette by using a long and subtle gradient that kept the bright and feel look. This made the wallpaper became brighter and more colorful.

Step.3 Final product

The result was successful. The new concept and usage of Suru language helped to create a brighter wallpaper that fitted into our overall visual aesthetic. We created a three-dimensional look and feel that gives the feeling of actual origami appearance. The wallpaper is still recognizable as Ubuntu, but at the same time looks fresh and different.

Ubuntu 16.04 Xenial Xerus

Xerus - purple

Ubuntu 16.04 Xenial Xerus ( light version)

Xerus - Grey

What is next?

The Design Team is now looking at ways to bring the Suru language into animation and fold usage. The idea is to bring an overall seamless and consistent experience to the user, whilst reflecting our tone of voice and visual identity.

Read more
Jamie Young

Ubuntu orange update

Recently, you may have seen our new colour palette update in the SDK. One notable change is the new hex code we’ve assigned to Ubuntu Orange for screen use. The new colour is #E95420.

We have a post coming soon that will delve deeper into our new palette but for now we just wanted to make sure this change is reflected on our website while at the same time touching on it through our blog. Our Suru visual language has evolved to have a lighter feel and we’ve adjusted the hex value in order to fit in with the palette as a whole.

We’ve updated our brand colour guidelines to take into account this change as well. You can find the new hex as well as all the tints of this colour that we recommend using in your design work.

Read more
Inayaili de León Persson

Redesigning ubuntu.com’s navigation

Last month, the web team had an offsite (outside of the office) week sprint in Holborn, central London. We don’t all work on exactly the same projects in our day-to-day, so it’s nice to have this type of sprint, where everyone can work together and show each other what we’ve been working on over the last few months.

 

Web team in HolbornThe web team in our offsite in Holborn

 

One of the key items in the agenda for the week was to brainstorm possible solutions for the key areas we want to improve in our navigation.

The last time we did a major redesign of ubuntu.com’s navigation was back in 2013 — time flies! So we thought now would be a good time to explore ways to improve how users navigate Ubuntu’s main website and how they discover other sites in the Ubuntu ecosystem.

Collaborative sketching

On the second day of the sprint, Francesca walked us through the current version of the navigation and explained the four key issues we want to solve. For each of the issues, she also showed how other sites solve similar problems.

While the 2013 navigation redesign solved some of the problems we were facing at the time (poor exposure of our breadth of products was a big issue, for instance) other issues have emerged since then that we’ve been meaning to address for a while.

After Francesca’s intro, we broke into four groups, and each group sketched a solution for each of the issues, which was then presented to everyone so we could discuss.

 

Karl presenting sketches to rest of the teamDiscussing the team’s sketches

 

By having everyone in the team, from UX and visual designers, to developers and project managers, contribute ideas and sketch together, we were able to generate lots of ideas in a very short amount of time. We could move the project forward much more quickly than if one UX or one designer had to come up with ideas by themselves over days or weeks.

Improving the global navigation

 

ubuntu.com global navigation barubuntu.com’s global navigation bar

 

The main things to improve on the global navigation were:

  • Some users don’t see the light grey bar above the main orange navigation
  • Some users think the links in the global nav are part of the ubuntu.com site
  • Important sites sit under the “More” link and do not have enough visibility
  • On the new full width sections, the global nav, main nav and “breadcrumb” form a visual sandwich effect that could create confusion

It was interesting to see the different groups come up similar ideas on how to improve the usability of the global navigation. Some of the suggestions were more simple and others more involved.

The main suggestions for improvement that we discussed were:

  • Rename the “More” link as “More sites” to make it more clear
  • Increase the number of links shown by default by using the full width of the page
  • Explore using different colours for the background, such as a dark grey
  • Explore having a drawer that exposes all Ubuntu sites, instead of the links being on display all the time (like the Bloomberg website)

 

Bloomber's global navigation closed

 

Bloomber's global navigation openOn Bloomberg.com when you click the “Bloomberg the Company & Its Products” link at the top (above) you open a large drawer that exposes the Bloomberg universe of sites.

 

Improving the main navigation

 

ubuntu.com's main navubuntu.com’s main navigation with a dropdown that lists second level links

 

The main ubuntu.com nav is possibly the most crucial part of the navigation that we would like to improve. The key improvements we’d like to work on are:

  • Having the ability to highlight key sections or featured content
  • Rely less on the site’s IA to structure the navigation as it makes it hard to cross-link between different sections (some pages are relevant to more than one section)
  • Improve the visibility of content that lives in the third level (it is currently only accessible via the breadcrumb-style navigation)

Even though the proposed solutions were different from each other, there were some patterns that popped up more than once amongst the different groups:

  • Featured content within the navigation (eg. the original Boston Globe responsive redesign, and Amazon.co.uk)
  • Links that live in more than one place (eg. John Lewis, Marks & Spencer and other retailers)
  • The idea of using the mega menu pattern

 

Boston Globel's original responsive menuIn the first version of the Boston Globe’s redesigned website, the main navigation included simple featured content for each of the sections

 

John Lewis mega menu Home & Garden section

John Lewis mega menu Baby & Child sectionOn the John Lewis website, you can get to nursery furniture from “Home & Garden > Room” and “Baby & Child > Baby & Nursery”

 

Amazon.co.uk displays seasonal ads in their mega menuThe main navigation on Amazon.co.uk includes featured ads

 

Solving the third level links issues

 

ubuntu.com's third level breadcrumb-style navubuntu.com’s breadcrumb-style navigation showing third level links

 

The main issues with the current third level links are:

  • We are using a recognisable design pattern (the breadcrumb) in a not so typical way (as second and third level navigation)
  • When you click on a third level link, you lose the visibility of the second level links, making it harder to understand where you are in the site
  • The pattern isn’t flexible: some of our labels are long, and only a small number of links fit horizontally, even on a large screen

One thing that we are almost certain of is that we will not be able to remove third level links completely from our site, so we need to improve the way we show them.

The most interesting suggestions on how to handle this issue were:

  • Include a table of contents for the section at the top of pages (like GOV.uk)
  • Key third level links could be highlighted in the main navigation menu

 

GOV.uk third level navOn GOV.uk, sections which have sub-sections include an overview of all the sub-sections at the top of every page. This makes it easier to understand the type and breadth of content of that section

 

Improving the footer

 

ubuntu.com's footerubuntu.com’s “fat footer” with three levels of links

 

Ubuntu.com’s footer is certainly the simplest of the problems we want to solve in terms of navigation. But, nonetheless, there are some issues with the current solution:

  • There are too many levels of links in the footer
  • The download section is hidden in the second footer level, despite being one of the main top level links

The most popular idea that came out of the sketching session was to use the space available better, so that sections can be listed in a masonry type grid, rather than one per column like they currently are.

This means we’d need fewer columns to list all important content and expose the IA of the site. It also means we can ditch the middle level of the current footer design (which now holds the About, Support and Download sections).

Next steps

The next step in the navigation redesign project is to build prototypes to test some of the ideas we had in our workshop, and refine the visual direction. We want to see if the assumptions we’ve made are true, and if the patterns are easy and intuitive to use across different screen sizes and devices.

We will then do some user testing and iterate based on the feedback we get.

We might also have to do some IA work alongside the redesign of the main navigation, if we do want to have links that are listed in different sections and if we want to present more curated links based on user tasks in each of the sections.

Stay tuned!

Read more
Anthony Dillon

The Juju web resources are made up of two entities: a website jujucharms.com and an app called Juju GUI, which can be demoed at demo.jujucharms.com.

Applying Vanilla to jujucharms.com

Luckily the website was already using our old style guidelines, which we refactored and improved to become Vanilla, so I removed the guidelines link from the head and the site fell to pieces. Once I NPM installed vanilla-framework and included it into the main sass file things started to look up.

A few areas of the site needed to be updated, like moving the search markup outside of the nav element. This is due to header improvements in the transition from guidelines to Vanilla. Also we renamed and BEMed our inline-list component, so I updated its markup in the process. The mobile navigation was also replaced with the new non-JavaScript version from Vanilla.

To my relief with these minor changes the site looked almost exactly as it did before. There were some padding differences, which resulted in some larger spacing between rows, but this was a purposeful update.

All in all the process of replacing guidelines with Vanilla on the website was quick and easy.

Now into the unknown…

Applying Vanilla to Juju GUI

I expected this step to be trickier as the GUI had not started life using guidelines and was using entirely bespoke CSS. So I thought: let’s install it, link the Vanilla framework and see how it looks.

To my surprise the app stayed together, apart from some element movement and overriding of input styling. We didn’t need the entire framework to be included so I selectively included only the core modules like typography, grid, etc.

The only major difference is that Vanilla applies bottom margin to lists, which did not exist on the app before, so I applied “margin-bottom: 0” to each list component as a local override.

Once I completed these changes it looked exactly as before.

What’s the benefit

You might be thinking, as I did at the beginning of the project, “that is a lot of work to have both projects look exactly the same”, when in fact it brings a number of benefits.

Now we have consistent styling across the Juju real estates, which are tied together with one single base CSS framework. This means we have exactly the same grid, buttons, typography, padding and much more. The tech debt to keep these in sync has been cut and allows designers to work from a single component list.

Future

We’re not finished there, as Vanilla framework is a bare bones CSS framework it also has a concept of theming. The next step will be to refactor the SCSS on both projects and identify the common components. The theme itself depends on Vanilla, so we have logical layering.

In the end

It is exciting to see how versatile Vanilla is. Whether it’s a web app or web site, Vanilla helps us keep our styles consistent. The layered inheritance gives us the flexibility to selectively include modules and extend them when required.

Read more