Canonical Voices

Luca Paulina

A few weeks ago we launched ‘Machine view’ for Juju, a feature designed to allow users to easily visualise and manage the machines running in their cloud environments. In this post I want to share with you some of the challenges we faced and the solutions we designed in the process of creating it.

A little bit about Juju…
For those of you that are unfamiliar with Juju, a brief introduction. Juju is a software tool that allows you to design, build and manage application services running in the cloud. You can use Juju through the command-line or via a GUI and our team is responsible for the user experience of Juju in the GUI.

First came ‘Service View’
In the past we have primarily focused on Juju’s ‘Service view’ – a virtual canvas that enables users to design and connect the components of their given cloud environment.

Service_view

This view is fantastic for modelling the concept and relationships that define an application environment. However, for each component or service block, a user can have anything from one unit to hundreds or thousands of units, depending on the scale of the environment, and before machine view, units means machines.

The goal of machine view was to surface these units and enable users to visualise, manage and optimise their use of machines in the cloud.

‘Machine view’: design challenges
There were a number of challenges we needed to address in terms of layout and functionality:

  • The scalability of the solution
  • The glanceability of the data
  • The ability to customise and sort the information
  • The ability to easily place and move units
  • The ability to track changes
  • The ability to deploy easily to the cloud

I’ll briefly go into each one of these topics below.

Scalability: Environments can be made up of a couple of machines or thousands. This means that giving the user a clear, light and accessible layout was incredibly important – we had to make sure the design looked and worked great at both ends of the spectrum.

Machine view

Simple_machine_view

Glanceability: Users need simple comparative information to help choose the right machine at-a-glace. We designed and tested hundreds of different ways of displaying the same data and eventually ended up with an extremely cut back listing which was clean and balanced.

A tour of the many incarnations and iterations of Machine view…

The ability to sort and customise: As it was possible and probable that users would scale environments to thousands of machines, we needed to provide the ability to sort and customise the views. Users can use the menus at the top of each column to hide information from view and customise the data they want visible at a glance. As users become more familiar with their machines they could turn off extra information for a denser view of their machines. Users are also given basic sorting options to help them find and explore their machines in different ways.

More_menu

The ability to easily place and move units: Machine view is built around the concept of manual placement – the ability to co-locate (put more than one) items on a single machine or to define specific types of machines for specific tasks. (As opposed to automatic placement, where each unit is given a machine of the pre-determined specification). We wanted to enable users to create the most optimised machine configurations for their applications.

Drag and drop was a key interaction that we wanted to exploit for this interface because it would simplify the process of manually placing units by a significant amount. The three column layout aided the use of drag and drop, where users are able to pick up units that need placing on the left hand side and drag them to a machine in the middle column or a container in the third column. The headers also change to reveal drop zones allowing users to create new machines and containers in one fluid action keeping all of the primary interactions in view and accessible at all times.

Drag and drop in action on machine view

The ability to track changes: We also wanted to expose the changes that were being made throughout user’s environments as they were going along and allow them to commit batches of changes altogether. Deciding which changes were exposed and the design of the uncommitted notification was difficult, we had to make sure the notifications were not viewed as repetitive, that they were identifiable and that it could be used throughout the interface.

Uncommitted_SV

Uncommitted_MV

The ability to deploy easily to the cloud: Before machine view it was impossible for someone to design their entire environment before sending it to the cloud. The deployment bar is a new ever present canvas element that rationalises all of the changes made into a neat listing, it is also where users can deploy or commit those changes. Look for more information about the deployment bar in another post.

The change log exposed

The deployment summary

We hope that machine view will really help Juju users by increasing the level of control and flexibility they have over their cloud infrastructure.

This project wouldn’t have been possible without the diligent help from the Juju GUI development team. Please take a look and let us know what you think. Find out more about Juju, Machine View or take it for a spin.

Read more
Giorgio Venturi

Canonical and Ubuntu at dConstruct

Brighton is not just a lovely seaside town, mostly known for being overcrowded in Summer by Londoners in search for a bit of escapism, but also the home of a thriving community of designers, makers and entrepreneurs. Some of these people run dConstruct, a gathering where creative minds of all sorts converge every year to discuss important themes around digital innovation and culture.

When I found out that we were sponsoring the conference this year, I promptly jumped in to help my colleagues in the Phone, Web and Juju design teams. Our stand was situated in the foyer of the Brighton Dome, flashing the orange banner of Ubuntu and a number of origami unicorns.

The Ubuntu Stand

Origami Unicorns

We had an incredibly positive response from the attendees, as our stand was literally teeming with Ubuntu enthusiasts who were really keen to check our progress with the phone. We had a few BQ phones on display where we showed the new features and designs.

Testing the phone

For us, it was a great occasion to gather fresh impressions of the user experience on the phone and across a variety of apps. After a few moments, people started to understand the edge interactions and began to swipe left and right, giving positive feedback on the responsiveness of the UI. Our pre-release models of BQ phones don’t have the final shell and they still display softkeys, as a result some people found this confusing. We took the opportunity to quickly design our own custom BQ phone by using a bunch of Ubuntu stickers…and viola, problem solved! ;)

Ubuntu phone - customised

Our ‘Make your Unicorn’ competition had a fantastic response. To celebrate the coming release of Utopic Unicorn and of the BQ phone, the maker of the best origami unicorn being awarded a new phone. The crowd did not hesitate to tackle the complex paper-bending challenge and came up with a bunch of creative outcomes. We were very impressed to see how many people managed to complete the instructions, as I didn’t manage to go beyond step 15..

Ubuntu fans

Twitter   Search - #dconstruct #ubuntu

Read more
Luca Paulina

Come and meet us at dConstruct

Ubuntu is sponsoring the dConstruct “Living with the network” event on the 5th of September at the Brighton Dome. Stop by for a chat with the team, grab some goodies and enter our competition for a chance to win an Ubuntu Phone.

nexus4_hero_shots

Read more
Robin Winslow

On release day we can get up to 8,000 requests a second to ubuntu.com from people trying to download the new release. In fact, last October (13.10) was the first release day in a long time that the site didn’t crash under the load at some point during the day (huge credit to the infrastructure team).

Ubuntu.com has been running on Drupal, but we’ve been gradually migrating it to a more bespoke Django based system. In March we started work on migrating the download section in time for the release of Trusty Tahr. This was a prime opportunity to look for ways to reduce some of the load on the servers.

Choosing geolocated download mirrors is hard work for an application

When someone downloads Ubuntu from ubuntu.com (on a thank-you page), they are actually sent to one of the 300 or so mirror sites that’s nearby.

To pick a mirror for the user, the application has to:

  1. Decide from the client’s IP address what country they’re in
  2. Get the list of mirrors and find the ones that are in their country
  3. Randomly pick them a mirror, while sending more people to mirrors with higher bandwidth

This process is by far the most intensive operation on the whole site, not because these tasks are particularly complicated in themselves, but because this needs to be done for each and every user – potentially 8,000 a second while every other page on the site can be aggressively cached to prevent most requests from hitting the application itself.

For the site to be able to handle this load, we’d need to load-balance requests across perhaps 40 VMs.

Can everything be done client-side?

Our first thought was to embed the entire mirror list in the thank-you page and use JavaScript in the users’ browsers to select an appropriate mirror. This would drastically reduce the load on the application, because the download page would then be effectively static and cache-able like every other page.

The only way to reliably get the user’s location client-side is with the geolocation API, which is only supported by 85% of users’ browsers. Another slight issue is that the user has to give permission before they could be assigned a mirror, which would slightly hinder their experience.

This solution would inconvenience users just a bit too much. So we found a trade-off:

A mixed solution – Apache geolocation

mod_geoip2 for Apache can apply server rules based on a user’s location and is much faster than doing geolocation at the application level. This means that we can use Apache to send users to a country-specific version of the download page (e.g. the German desktop thank-you page) by adding &country=GB to the end of the URL.

These country specific pages contain the list of mirrors for that country, and each one can now be cached, vastly reducing the load on the server. Client-side JavaScript randomly selects a mirror for the user, weighted by the bandwidth of each mirror, and kicks off their download, without the need for client-side geolocation support.

This solution was successfully implemented shortly before the release of Trusty Tahr.

(This article was also posted on robinwinslow.co.uk)

Read more
Iain Farrell

Verónica Sousa's Cul de sac

Verónica Sousa’s Cul de sac

Ubuntu was once described to me by a wise(ish ;) ) man as a train that was leaving whether you’re on it or not. That’s the beauty of a 6 month release cycle. As many of you will already know, each release we include photos and illustrations produced by community members. We ask that you submit your images using free photo sharing site Flickr and that you limit your images this time to 2. The group won’t let you submit more than that but if you change your mind after you’ve submitted, fear not, simply remove one and it’ll let you add another.

As with previous submissions processes we’ve run, and in conjunction with the designers at Canonical we’ve come up with the following tips for creating wallpaper images.

  1. Images shouldn’t be too busy and filled with too many shapes and colours, a similar tone throughout is a good rule of thumb.
  2. A single point of focus, a single area that draws the eye into the image, can also help you avoid something too cluttered.
  3. The left and top edges are home to Ubuntu’s Launcher and Panel so be careful to consider how your images look in place so as not to clash with the user interface. Try them out on your own desktop, see how they feel.
  4. Try your image at different aspect ratios to make sure something important isn’t cropped out on smaller/ larger screens at different resolutions.
  5. Take a look at the wallpapers guidance on the Ubuntu Wiki regarding the size of images. Our target resolution is 2560 x 1600.
  6. Break all the rules except the resolution one! :D

To shortlist from this collection we’ll be going to the contributors whose images were selected last time around to act as our selection judges. In doing this we’ll hold a series of public IRC meetings on Freenode in #1410wallpaper to discuss the selection. In those sessions we’ll get the selection team to try out the images on their own Ubuntu machines to see what they look like on a range of displays and resolutions.

Anyone is welcome to come to these sessions but please keep in mind that an outcome is needed from the time that people are volunteering and there’s usually a lot of images to get through so we’d appreciate it if there isn’t too much additional debate.

Based on the Utopic release schedule, I think our schedule for this cycle should look like this:

  • 08/08/14 – Kick off 14.10 wallpaper submission process.
  • 22/08/14 – First get together on #1410wallpaper at 19:30 GMT.
  • 29/08/14 – Submissions deadline at 18:00 GMT – Flickr group will be locked and the selection process will begin.
  • 09/09/14 – Deliver final selection in zip format to the appropriate bug on Launchpad.
  • 11/09/14 – UI freeze for latest version of Ubuntu with our fantastic images in it!

As always, ping me if you have any questions, I’ll be lurking in #1410wallpaper on freenode or leave a question in the Flickr group for wider discussion, that’s probably the fastest way to get an answer to a question.

I’ll be posting updates on our schedule here from time to time but the Flickr group will serve as our hub.

Happy snapping and scribbling and on behalf of the community, thanks for contributing to Ubuntu! :)


Read more
Benjamin Keyser

Bringing Fluid Motion to Browsing

In the previous Blog Post, we looked at how we use the Recency principle to redesign the experience around bookmarks, tabs and history.
In this blog post, we look at how the new Ubuntu Browser makes the UI fade to the background in favour of the content. The design focuses on physical impulse familiarity – “muscle memory” – by marrying simple gestures to the two key browser tasks, making the experience feel as fluid and simple as flipping through a magazine.

 

Creating a new tab

For all new browsers, the approach to the URI Top Bar that enables searching as well as manual address entry has made the “new tab” function more central to the experience than ever. In addition, evidence suggests that opening a new tab is the third of the most frequently used action in browser. To facilitate this, we made opening a new tab effortless and even (we think) a bit fun.
By pulling down anywhere on the current page, you activate a sprint loaded “new tab” feature that appears under the address bar of the page. Keep dragging far enough, and you’ll see a new blank page coming into view. If you release at this stage, a new tab will load ready with the address bar and keyboard open as well as an easy way to get to your bookmarks. But, if you change your mind, just drag the current page back up or release early and your current page comes back.

http://youtu.be/zaJkNRvZWgw

 

Get to your open tabs and recently visited sites

Pulling the current page downward can create a new blank tab, and conversely dragging the bottom edge upward shows you already open tabs ordered by recency that echoes the right edge “open apps” view.

If you keep on dragging upward without releasing, you can dig even further into the past with your most recently visited pages grouped by site in a “history” list. By grouping under the site domain name, it’s easier to find what you’re looking for without thumbing through hundreds of individual page URLs. However, if you want all the detail, tap an item in the list to see your complete history.

Blog Post - Browser #2 (1)
It’s not easy to improve upon such a well-worn application as the browser, it’s true. We’re hopeful that by adding new fluidity to creating, opening and switching between tabs, our users will find that this browsing experience is simpler to use, especially with one hand, and feels more seamless and fluid than ever.

 

 

Read more
Tom Macfarlane

Mobile Asia Expo 2014

Following the success of our new stand design at MWC earlier this
year, we applied the same design principles to the Ubuntu stand at
last month’s Mobile Asia Expo in Shanghai.

MAE_2014_stand

With increased floor space, compared to last year, and a new stand
location that was approachable from three key directions, we were
faced with a few new design challenges:

  • How to effectively incorporate existing 7m wide banners into
    the new 8m wide stand?
  • How to make the stand open and approachable from three sides
    with optimum use of floor space and maintaining the maximum
    amount storage space possible?
  • How to maintain our strong brand presence after any necessary
    structural changes?

Proposed layout ideas

MAE_drawing_1

MAE_drawing_2

MAE_drawing_3 Final layout
The final design utilised maximum floor space and incorporated the
positioning of our bespoke demo pods, that proved successful at MWC.
Along with strong branding featuring our folded paper background
with large graphics showcasing app and scope designs and a new aisle
banner. The main stand banners were then positioned in an alternating
arrangement aligned to the left and to the right above the stand.

MAE_drawing_4

Aisle banner

Ubuntu_hanging_banner_Preview

MAE_stand_front

MAE_stand_back

Read more
Inayaili de León Persson

Latest from the web team — June 2014

We’re now almost half way through the year and only a few days until summer officially starts here in the UK!

In the last few weeks we’ve worked on:

  • Responsive ubuntu.com: we’ve finished publishing the series on making ubuntu.com responsive on the design blog
  • Ubuntu.com: we’ve released a hub for our legal documents and information, and we’ve created homepage takeovers for Mobile Asia Expo
  • Juju GUI: we’ve planned work for the next cycle, sketched scenarios based on the new personas, and launched the new inspector on the left
  • Fenchurch: we’ve finished version 1 of our new asset server, and we’ve started work on the new Ubuntu partners site
  • Ubuntu Insights: we’ve published the latest iteration of Ubuntu Insights, now with a dedicated press area
  • Chinese website: we’ve released the Chinese version of ubuntu.com

And we’re currently working on:

  • Responsive Day Out: I’m speaking at the Responsive Day Out conference in Brighton on the 27th on how we made ubuntu.com responsive
  • Responsive ubuntu.com: we’re working on the final tweaks and improvements to our code and documentation so that we can release to the public in the next few weeks
  • Juju GUI: we’re now starting to design based on the scenarios we’ve created
  • Fenchurch: we’re now working on Juju charms for the Chinese site asset server and Ubuntu partners website
  • Partners: we’re finishing the build of the new Ubuntu partners site
  • Chinese website: we’ll be adding a cloud and server sections to the site
  • Cloud Installer: we’re working on the content for the upcoming Cloud Installer beta pages

If you’d like to join the web team, we are currently looking for a web designer and a front end developer to join the team!

Juju scenariosWorking on Juju personas and scenarios.

Have you got any questions or suggestions for us? Would you like to hear about any of these projects and tasks in more detail? Let us know your thoughts in the comments.

Read more
Inayaili de León Persson

Making ubuntu.com responsive: final thoughts

This post is part of the series ‘Making ubuntu.com responsive‘.

There are several resources out there on how to create responsive websites, but they tend to go through the process in an ideal scenario, where the project starts with a blank slate, from scratch.

That’s why we thought it would be nice to share the steps we took in converting our main website and framework, ubuntu.com, into a fully responsive site, with all the constraints that come from working on legacy code, with very little time available, while making sure that the site was kept up-to-date and responding to the needs to the business.

Before we started this process, the idea of converting ubuntu.com seemed like a herculean task. It was only because we divided the work in several stages, smaller projects, tightened scope, and kept things simple, that it was possible to do it.

We learned a lot throughout this past year or so, and there is a lot more we want to do. We’d love to hear about your experience of similar projects, suggestions on how we can improve, tools we should look into, books we should read, articles we should bookmark, and things we should try, so please do leave us your thoughts in the comments section.

Here is the list of all the post in the series:

  1. Intro
  2. Setting the rules
  3. Making the rules a reality
  4. Pilot projects
  5. Lessons learned
  6. Scoping the work
  7. Approach to content
  8. Making our grid responsive
  9. Adapting our navigation to small screens
  10. Dealing with responsive images
  11. Updating font sizes and increasing readability
  12. Our Sass architecture
  13. Ensuring performance
  14. JavaScript considerations
  15. Testing on multiple devices

Note: I will be speaking about making ubuntu.com responsive at the Responsive Day Out conference in Brighton, on the 27th June. See you there!

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

When working on a responsive project you’ll have to test on multiple operating systems, browsers and devices, whether you’re using emulators or the real deal.

Testing on the actual devices is preferable — it’s hard to emulate the feel of a device in your hand and the interactions and gestures you can do with it — and more enjoyable, but budget and practicability will never allow you to get a hold of and test on all the devices people might use to access your site.

We followed very simple steps that anyone can emulate to decide which devices we tested ubuntu.com on.

Numbers

You can quickly get a grasp of which operating systems, browsers and devices your visitors are using to get to your site just by looking at your analytics.

By doing this you can establish whether some of the more troublesome ones are worth investing time in. For example, if only 10 people accessed your site through Internet Explorer 6, perhaps you don’t need to provide a PNG fallback solution. But you might also get a few less pleasant surprises and find that a hard-to-cater-for browser is one of the preferred ones by your customers.

When we did our initial analysis we didn’t find any real surprises, however, due to the high volume of traffic that ubuntu.com sees every month even a very small percentage represented a large number of people that we just couldn’t ignore. It was important to keep this in mind as we defined which browsers, operating systems and devices to test on, and what issues we’d fix where.

Browsers (between 11 February and 13 March 2014)
Browser Percentage usage
Chrome 46.88%
Firefox 36.96%
Internet Explorer Total 7.54%
11 41.15%
8 22.96%
10 17.05%
9 14.24%
7 2.96%
6 1.56%
Safari 4.30%
Opera 1.68%
Android Browser 1.04%
Opera Mini 0.45%
Operating systems (between 11 February and 13 March 2014)
Operating system Percentage usage
Windows Total 52.45%
7 60.81%
8.1 14.31%
XP 13.3%
8.84 8.84%
Vista 2.38%
Linux 35.4%
Macintosh 6.14%
Android Total 3.32%
4.4.2 19.62%
4.3 15.51%
4.1.2 15.39%
iOS 1.76%
Mobile devices (between 12 May and 11 June 2014)
5.41% of total visits
Device Percentage usage (of 5.41%)
Apple iPad 17.33%
Apple iPhone 12.82%
Google Nexus 7 3.12%
LG Nexus 5 2.97%
Samsung Galaxy S III 2.01%
Google Nexus 4 2.01%
Samsung Galaxy S IV 1.17%
HTC M7 One 0.92%
Samsung Galaxy Note 2 0.88%
Not set 16.66%

After analysing your numbers, you can also define which combinations to test in (operating system and browser).

Go shopping

Based on the most popular devices people were using the access our site, we made a short list of the ones we wanted to buy first. We weren’t married to the analytics numbers though: the idea was to cover a range of screen sizes and operating systems and expand as we went along.

  • Nexus 7
  • Samsung Galaxy S III
  • Samsung Galaxy Note II

We opted for not splashing on an iPad or iPhone, as there are quite a few around the office (retina and non-retina) and the money we saved meant we could buy other less common devices.

Testing devicesPart of our current device suite.

When we started to get a few bug reports from Android Gingerbread and Windows phone users, we decided we needed phones with those operating systems installed. This was our second batch of purchases:

  • Samsung Galaxy y
  • Kindle Fire HD (Amazon was having a sale at the time we made the list!)
  • Nokia Lumia 520
  • LG G2

And, last but not least, we use a Nexus 4 to test on Ubuntu on phones.

We didn’t spend much in any of our shopping sprees, but have managed to slowly build an ever-growing device suite that we can test our sites on, which is invaluable when working on responsive projects.

Alternatives

Some operating systems and browsers are trickier to test on in native devices. We have a BrowserStack account that we tend to use mostly to test on older Windows and Internet Explorer versions, although we also test Windows on virtual machines.

browserstackBrowserStack website.

Tools

We have to confess we’re not using any special software that synchronises testing and interactions across devices. We haven’t really felt the need for that yet, but at some point we should experiment with a few tools, so we’d like to hear suggestions!

Browser support

We prefer to think of different levels (or ways) of access to the content rather than browser support. The overall rule is that everyone should be able to get to the content, and bugs that obstruct access are prioritised and fixed.

As much as possible, and depending on resources available at the time, we try to fix rendering issues in browsers and devices used by a higher percentage of visitors: degree of usage defines the degree of effort fixing rendering bugs.

And, obviously: dowebsitesneedtolookexactlythesameineverybrowser.com.

Read the final post in this series: “Making ubuntu.com responsive: final thoughts”

Reading list

Read more
Anthony Dillon

table.highlight { margin-bottom: 0; } table.highlight td { text-align: left; font-size: 0.8em; line-height: 1.6; border: 0; }

This post is part of the series ‘Making ubuntu.com responsive‘.

The JavaScript used on ubuntu.com is very light. We limit its use to small functional elements of the web style guide, which act to enhance the user experience but are never required to deliver the content the user is there to consume.

At Canonical we use YUI as our JavaScript framework of choice. We have many years of using it for our websites and web apps therefore have a large knowledge base to fall back on. We have a single core.js which contains a number of functions called on when required.

Below I will discuss some of the functions and workarounds we have provided in the web style guide.

Providing fallbacks

When considering our transition from PNGs to SVGs across the site, we provided a fallback for background images with Modernizr and reset the background image with the .no-svg class on the body. Our approached to a fallback replacement in markup images was a JavaScript snippet from CSS Tricks – SVG Fallbacks, which I converted to YUI:

The snippet above checks if Modernizr exists in the namespace. It then interrogates the Modernizr object for SVG support. If the browser does not support SVGs we loop through each image with .svg contained in the src and replace the src with the same path and filename but a .png version. This means all SVGs need to have a PNG version at the same location.

Navigation and fallback

The mobile navigation on ubuntu.com uses JavaScript to toggle the menu open and closed. We decided to use JavaScript because it’s well supported. We explored using :target as a pure CSS solution, but this selector isn’t supported in Internet Explorer 7, which represented a fair chunk of our visitors.

mobile-open-navThe navigation on ubuntu.com, in small screens.

For browsers that don’t support JavaScript we resort to displaying the “burger” icon, which acts as an in-page anchor to the footer which contains the site navigation.

Equal height

As part of the guidelines project we needed a way of setting a number of elements to the same height. We would love to use the flexbox to do this but the browser support is not there yet. Therefore we developed a small JavaScript solution:

This function finds all elements with an .equal-height class. We then look for child divs or lis and measure the tallest one. Then set all these children to the highest value.

Using combined YUI

One of the obstacles discovered when working on this project was that YUI will load modules from an http (non secure) domain as the library requires. This of course causes issues on any site that is hosted on a secure domain. We definitely didn’t want to restrict the use of the web style guide to non secure sites, therefore we need combine all required modules into a combined YUI file.

To combine your own YUI visit YUI configurator. Add the modules you require and copy the code from the Output Console panel into your own hosted file.

Final thoughts

Obviously we had a fairly easy time of making our JavaScript responsive as we only use the minimum required as a general principle on our site. But using integrating tools like Modernizr into our workflow and keeping top of CSS browser support, we can keep what we do lean and current.

Read the next post in this series: “Making ubuntu.com responsive: testing on multiple devices”

Reading list

Read more
Anthony Dillon

This post is part of the series ‘Making ubuntu.com responsive‘.

Performance has always been one of the top priorities when it came to building the responsive ubuntu.com. We started with a list of performance snags and worked to improve each one as much as possible in the time we had. Here is a quick run through of the points we collected and the way we managed to improve them.

Asset caching

We now have a number of websites using our web style guide. Because of this, we needed to deliver assets on both http and secure https domains. We decided to build an asset server to support the guidelines and other sites that require asset hosting.

This gave us the ability to increase the far future expires (FFE) of each file. By doing so the file is cached by the server and not resupplied. This gives us a much faster round trip speed. But as we are still able to update a single file we cannot set the FFE too far in the future. We plan to resolve this with a new and improved assets system, which is currently under development.

The new asset system will have a internal frontend to upload a binary file. This will provide a link to the asset with a 6 character hexadecimal attached to the file name.

/ho686yst/favicon.ico

The new system restricts the ability to edit or update a file. Only upload a new one and change the link in the markup. This guarantees the asset to stay the same forever.

Minification and concatenation

We introduced a minification and concatenation step to the build of the web style guide. This saves precious bytes and reduces the number of requests performed by each page.

We use the sass ruby gem to generate minified and concatenated CSS in production. We also run the small amount of JavaScript we have through UglifyJS before delivering to production.

Compressed images

Images were the main issue when it came to performance.

We had a look at the file sizes of some of our key images (like the ones in the tablet section of the site) and were shocked to discover we hadn’t been treating our visitors’ bandwidth kindly.

After analysing a handful of images, we decided to have a look into our assets folder and flag the images that were over 100 KB as a first go.

One of the largest time consuming jobs in this project was converting all images that could to SVGs. This meant creating pictograms and illustrations as vectors from earlier PNGs. Any images that could not be recreated as a vector graphic were heavy compressed. This squeezed an alarming amount out of the original file.

We continued this for every image on the site. By doing so the total reduction across the site was 7.712MB.

Reduce required fonts

We currently load a large selection of the Ubuntu font.

<link href='//fonts.googleapis.com/css?family=Ubuntu:400,300,300italic,400italic,700,700italic%7CUbuntu+Mono' rel='stylesheet' type='text/css' />

The designers are exploring the patterns of the present and ideal future to discover unneeded types. Since the move from normal font weight to light a few months ago as our base font style, we rarely use the bold weight (700) anymore, resorting to normal (400) for highlighting text.

Once we determine which weights we can drop, we will be able to make significant savings, as seen below:

google-fonts-beforeandafterReducing loaded fonts: before and after

Using SVG

Taking the leap to SVGs over PNG caused a number of issues. We decided to load SVGs as opposed to inline SVGs to keep our markup clean and easy to read and update. This meant we needed to provide four different coloured images for each pictogram.

pictopack-smiles

We introduced Modernizr to give us an easy way to detect browsers that do not support SVGs and replace the image with PNGs of the same path and name.

Remove unnecessary enhancements

We explored a parallaxing effect for our site’s background with JavaScript. With worked well on normal resolution screens but lagged on retina displays, so we decided not do it and set the background position to static instead — user experience is always paramount and trumps visual enhancements.

Future improvements

One of the things in our roadmap is to remove unused styles remaining in the stylesheets. There are a number of solutions for this such as grunt-uncss.

Conclusion

There is still a lot to do but we have definitely broken the back of the work to steer ubuntu.com in the right direction. The aim is to push the site up to 90+ in the speed page tests in the next wave of updates.

Read the next post in this series: “Making ubuntu.com responsive: JavaScript considerations”

Reading list

Read more
Anthony Dillon

This post is part of the series ‘Making ubuntu.com responsive‘.

When working to make the current web style guide responsive, we made some large updates to the core Sass. We decided to update the file and folder structure of our styles. I love reading about other people or organisations Sass architectures, so I thought it would be only right to share the structure that has evolved over time here at Canonical.

Let’s get right to it.

  • core.scss
  • core-constants.scss
  • core-grid.scss
  • core-mixins.scss
  • core-print.scss
  • core-templates.scss
  • patterns
    • patterns.scss
    • _arrows.scss
    • _blockquotes.scss
    • _boxes.scss
    • _buttons.scss
    • _contextual-footer.scss
    • _footer.scss
    • _forms.scss
    • _header.scss
    • _helpers.scss
    • _image-centered.scss
    • _inline-logos.scss
    • _lists.scss
    • _notifications.scss
    • _resource.scss
    • _rows.scss
    • _slider.scss
    • _structure.scss
    • _tabbed-content.scss
    • _tooltips.scss
    • _typography.scss
    • _vertical-divider.scss

I won’t describe each file as some are self-explanatory but let’s just go through the core files to understand the structure.

core.scss contains the core HTML element styling. Such as img, p, ul, etc. You could say this acts as a reset file customised to match our style.

core-constants.scss is home to all variables used throughout. This file contains all the set colours used on the site. Base font size and some extra grid variables used to extend the layout.

core-grid.scss holds the entire responsive grid styles. This file mainly consists of generated code from Gridinator which we extended with breakpoints to modify the layout as the viewport gets smaller. You can read more about how we did this in “Making ubuntu.com responsive: making our grid responsive”.

core-mixins.scss holds all the mixins used in our Sass.

core-templates.scss is used to hold full pages styling classes. Without applying a template class to the <body> of a page you get a standard page style, if you add a template class, you will get the styles that are appropriate for that template.

webteam frontend working on web style guideWeb team front end working on the web style guide.

Divide and conquer

Patterns were originally all in one huge scss file, which became difficult to maintain. So we decided to split the patterns file apart in a pattern folder. This allows us to find and work in a much more modular way. This involved manually working through the file. Removing all the components styles into a new file and import back into the same position.

Naming conventions

Our mission when setting up the naming convention for our CSS was to make the markup as human readable as possible.

We decided early on to almost use a object oriented, inheritance system for large structural elements. For example, the class .row can be extended by adding the .row-enterprise class which applies a dark aubergine background and modifies the elements inside to be display correctly on a dark background.

We switch to a single class approach for small modular components, such as lists. If you apply the class .list the list items are styled with our simple Ubuntu list style. This can be modified by changing the class to .list-ubuntu or .list-canonical, which apply their corresponding branding themed bullets to the items.

list-stylesList styles.

The decision to use different systems arose from the desire to keep the markup clean and easy to skim read by limiting the classes applied to each element. We could have continued with the inheritance system for smaller elements but that would have lead to two or more classes (.list and .list-canonical) for each element. We felt this was overkill for every small component. For large structural elements such as rows it’s easier to start with a .row class and have added functionality and styling by adding classes.

Mixins

We mainly use mixins to handle browser prefixes as we haven’t yet added a “prefixer” step to our build system.

A lot of our styles are quite specific and therefore would not benefit from being included as a mixin.

A note on Block, Element, Modifier syntax

We would like to have used the Block, Element, Modifier (BEM) syntax as we think it is a good convention and easy for people external to the project to understand and use. Since we started this project back in 2013 with the above syntax, which is now used on a number of sites across the Canonical/Ubuntu web real estate, the effort to convert every class name to follow the BEM naming convention would far outweigh the benefits it would return.

Conclusion

By splitting our bloated patterns file into multiple small modular files we have made it much easier to maintain and diagnose bugs within components. I would recommend anyone in a similar situation to find the time to split the components into separate files sooner rather then later. The effort grows exponentially the longer it’s left.

Introducing linting to the production of the guidelines will keep our coding style the same throughout the team and help readability to new members of the team.

Read the next post in this series: “Making ubuntu.com responsive: ensuring performance”

Reading list

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

All our designs are created using the Ubuntu font, and the websites are not exception. Ubuntu.com was already using a carefully refined and tested typographic scale that we have evolved over the years.

Early in the project, we had decided that the large screen view of the website would be kept, so we would be reusing the original styles (with some updates and clean up) and it became the typographic scale for the desktop view.

Adjust as needed

When working on the pilot responsive projects like Ubuntu Insights and canonical.com, we’ve used that original scale and reduced it, keeping the proportions.

After some device testing to adjust paragraph size for comfortable reading, we settled on having the base font size modified at our grid breakpoints to 14px, 15px and 16px.

By keeping the proportions of the sizes though, it was easy to see that some font sizes and margins were too large in proportion to others at small screens — especially the larger headings like h1 —, so we tweaked these as needed to improve readability.

A typographic scale can serve as a guide, but you don’t have to stay married to it: adjusting sizes to what feels better is an important step in making sure your text is comfortable to read at various sizes — and the best way to test this is on the actual devices!

Testing devicesTesting ubuntu.com on various devices.

Use ems

Our typographic scale is defined in pixels, but the sizes are specified in ems in our CSS so they can be scalable.

Small, medium and large spacingDifferences in the typographic scale from small to large screens.

Reuse existing patterns

We have a weekly designers meeting where we talk about new patterns we’re working on in our separate projects across the entire design team. This way, we minimise the risk of creating new patterns when existing ones are in place, and when something new is created it can be shared with the rest of the team to use.

So we made sure to show our updated typographic scale and get everyone’s feedback on it, including designers from the apps and platforms teams. The best part was that we had reached similar conclusions about which sizes worked best in small screens (the variation was in the decimals) so we were all being consistent when it came to mobile!

Remember fallback fonts

Even though web fonts are widely supported now, some browsers, like Opera Mini, just don’t support them, so it’s always a good idea to look at your site across various devices and browsers, and turn off the font-face declarations to see if the fallback fonts that you’ve declared look as good as you can make them and match as closely as possible with the original font. By doing this you’ll make the transition between the fallback font and the web font once it’s finally loaded less obvious and less jarring for the user.

Opera MiniOpera Mini, without the Ubuntu font.

Conclusion

There are a few simple things you can do when transitioning from a fixed-width to a responsive website. The focus should be to improve readability, so it’s vital to check as many pages and screens of your site in different devices. And remember that picking a typographic scale is not as simple as taking numbers out of a generator: you have to see it in action and adapt it to your project.

We’d love to hear how you handled typography in your responsive projects — leave your thoughts in the comments area!

Read the next post in this series: “Making ubuntu.com responsive: our Sass architecture”

Reading list

Read more
Jouni Helminen

Malta Sprint

Our Apps and Platform teams took part at a design/engineering sprint on the beautiful island of Malta in May, and we thought we would share some pics to show a peek into “behing the scenes” and people working on the apps and operating system.

The sprint itself was a great experience, with over 150 people, engineers and designers, working together and planning out the next steps. Refined designs for mobile apps such as Browser, Camera and Telephony suite (Dialer, Contacts and Messaging) were unveiled and implementation got well underway, and on the platform team Scopes are starting to look really beautiful on the phone. There were plenty of tech demos and talks ranging from Cloud to Convergence to Mobile to Internet of Things – it was great to see everyone hacking, designing and discussing together about super exciting things. A good reminder that although Canonical has grown in size, at the core it still feels like a startup in a good sense.

It is an interesting time coming up to the release of the phone hardware, and these two weeks at Malta were a brilliant opportunity for all teams to sync up, work hard and squeeze in some R&R in the evenings too. Sun, great grilled seafood and the historical buildings of Valeta – it was fantastic to work in such a beautiful setting, and we cannot wait to get all the new goodies in the hands of people.

IMG_2665

20140522-DSC05138ubuntu_team

20140519-DSC01071

20140519-DSC01063

Screen Shot 2014-06-10 at 23.22.09

Read more
Benjamin Keyser

Cueing up users

The bottom edge swipe gesture is simple and accessible for users, so it’s strategic for application developers. By giving instant access to the most needed settings, controls, and views through the bottom edge, app developers have a powerful tool for crafting more useful and usable experiences.

In earlier postings we’ve talked about how the bottom edge can be harnessed effectively, but helping users to get curious about this special place on the interface is the key to unlocking the full value of an app. The solution is simple and elegant: smart cues.

What is a cue?

1-telephone_bottom_edge_hint

On first glance, the bottom edge cue is just a tiny label space that pops up when an app is opened, looking much like a simple tab or handle. When the user grabs it, or simply swipes up, anywhere along the bottom edge, the edge is activated normally.

The cue component can stay on screen as a label, or retract to a minimal handle that doesn’t clog the screen or distract from the user’s primary task. Finally, and perhaps most interestingly, the cue can become an app indicator bar, reminder the user about which settings are currently selected.

How to cue

For many apps, the bottom edge is ideal for providing a simple, always-accessible way for users to compose a new item like a message, note or add to a list of things. A cue for this purpose can be as straight forward as a “Create New” text label that slides up when the app is loaded to remind users of the action, but then retracts neatly to either a simple handle, or altogether, as the user interacts with other parts of the application. The minimized cue can remain on top of the screen if desired, providing users with an unobtrusive but persistent cue.

Combination cue and indicators

2-camera_bottom_zoom

While a simple cue such as “create new” may be just right sometimes, but in some cases where settings or controls are located in the bottom edge, cues can work even harder, providing the user with an indicator bar of current setting. For example, in the camera app, the bottom edge cue shows the current flash setting and whether GPS tagging of photos is enabled. If the user triggers the bottom edge, controls for all of these settings are revealed.

Please and cues

Before you finalize your app design, think about how the bottom edge can help you deliver the most pleasing and effective user experience. Part of this plan should include the best use of the bottom edge cue, either as a label, a settings indicator, or both. Make it easy for users to discover what the bottom edge can do, and get more from your application.

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

Deciding how you’re going to handle responsive images is a big part of most responsive projects — also, one that usually causes many headaches!

We had really interesting discussions within the team to try to find out which options were out there, being used by other people, and whether those solutions could be useful (and possible) for us.

There is a range of solutions and opinions on this matter, but ultimately it’s all down to the content and types of images your website actually has to handle, and the technical and resource limitations of your team.

We tried to keep an open mind as to what would be possible to achieve within a very small timeframe: we wanted to find a solution that would work for our content, that would be achievable within our deadlines, and obviously, that would improve the experience of the visitors to our site.

Making an image inventory

Before discussing any potential solutions, it’s important to understand exactly what type of images are used on your site, how they are created, who creates them, how they are added to the site and in which locations, how the images play with the content and whether there are different levels of importance (UI icons, purely decorative images, infographics, editorial images, etc.).

You might realise you only use UI icons and vector illustrations, or that all your images are decorative and secondary, or even that all your images are photos commissioned to professional photographers and photojournalists that add great value to your content and designs. It’s only after doing this inventory that you’ll have sufficient information to decide what to do next and what your site needs.

On ubuntu.com there are five different types of image assets:

  • Pictograms: from an existing set of pre-approved pictograms, created in various formats, in a small subset of colours
  • Illustrations: usually created using two or more pictograms, or in a similar style, in vector format
  • Photography: these can be product shots of devices, screengrabs of our operating system and applications, and sometimes other types of photographic images
  • Logos: not only Ubuntu and Canonical’s own logos, but several partner logos
  • Backgrounds: these can be anything from dot patterns to textured backgrounds

Ubuntu image arsenalPictograms, illustrations, photography, logos and backgrounds are part of the image arsenal of ubuntu.com.

The pictograms and illustrations are always created in vector format and can easily be exported to an SVG. Similarly, many of the logos we use on the site can be sourced in an SVG format, but many times this isn’t possible. The photography and backgrounds used on the site, however, are usually provided to us in bitmap format, that lose definition when scaled up.

With this inventory in mind, we knew we’d have to come up with different solutions for the different types of assets rather than a single solution for all images.

Scalable vectors: pictograms, illustrations and logos

We investigated the possibility of creating a font for our icons and even started this process, but quickly decided that the lack of consistent browser support wasn’t acceptable.

The decision to move from GIF and PNG icons to SVG was relatively straightforward for us, as all our icons and pictograms are created in vector format from the outset. This would allow us to have crisp, scalable icons in most browsers, whether the device has a retina screen or not.

It was at this point that we thought it would be a good idea to finally introduce Modernizr into our toolset. With Modernizr we could target browsers that don’t support SVG and serve them with a PNG image replacement.

We did run into some browser support issues, mainly with Opera Mini which doesn’t support background-size (necessary if you’re scaling the same image asset instead of creating copies at different sizes) but does support SVG. To solve this problem, Ant wrote a JavaScript snippet that detects Opera Mini and adds the class .opera-mini to the body of the document. He will be covering this in more detail in a following post in this series.

Opera Mini rendering issuesOpera Mini’s SVG rendering issues.

We have explored the possibility of dynamically changing the colours of our SVG pictograms, but haven’t yet found a solution that is compatible across browsers — we’re open to suggestions!

Bitmap formats: photography and backgrounds

This is where things usually get trickier: how do you create a balance between serving users the best quality image they can get and saving their bandwidth?

Ideally, we’d have had the time to add the ability of images to be called on the fly in the size needed, so that the user didn’t have to download a size that was not intended for his or her screen size. This is something that we still want to work on, but just couldn’t justify to be added to the scope of this first iteration of the responsive transition.

Eventually we decided to use Imager.js — made by the BBC News developers — for responsive imaging in the markup. We chose this solution as it has simple syntax and is being used in production on high traffic websites, so it was proven to work. It seemed like a simple solution that fit our needs. In simple terms, the script runs through the page, looking up placeholder elements and replacing them with the closest available image size based on the width of the container.

CSS helper classes

We’ve created three CSS classes that can be used to hide/show images and other elements according to the size of the viewport:

  • .for-small: only shows in the smallest media query viewport
  • .for-medium: only shows in the small and medium media query viewports
  • .not-for-small: doesn’t show in the smallest media query viewport

These classes give us enough flexibility to decide which images should be visible based on our breakpoints in cases where we need more control. This means if we change the breakpoints, the classes will inherit the change.

File size

Initially we were planning on creating several versions of the images on the site, for small, medium and large screen sizes, but we found out that some of the current images on the site had a much larger file size than they needed to — for example, some transparent PNGs were being used when transparency was not a requirement.

With the limited time available, we opted for focusing on reducing file sizes as much as possible for existing images as a priority. This way, we’d make our pages smaller but small higher density screens would still see crisp images, since at smaller sizes they’d be reduced to about half their original size.

You can see a comparison of the file size per section of the site before and after this process.

Section Size before Ubuntu 14.04 LTS release (KB) Size after Ubuntu 14.04 LTS release (KB)
Homepage 434 193
About 1460 1787
Cloud 2809 2304
Desktop 3794 2571
Download 2921 3990
Management 991 1102
Partners 2243 2320
Phone 6943 2021
Server 1483 636
Support 679 480
Tablet 3318 1829
TV 603 733

We obtained these sizes using a combination of YSlow and PhantomJS.

Some of the sections were expanded for the Ubuntu 14.04 LTS release in April, which justifies some of the increases. The desktop, phone and tablet sections, however — the worst offenders — saw a significant reduction in file size, mainly from switching to the most appropriate file format instead of all PNGs.

Another way to create more consistency and file size savings across the site was the introduction of a pictogram and logo package. Instead of creating pictograms ad-hoc as needed, we now have a defined set of pictograms in a central location that can be reused across the site, in all its different colour variations. Because the pictograms and many of the logos are provided in an SVG format, they can be scaled to the size that is needed.

Ideas for the future

Despite the visible improvements, there are plenty of things we’d still like to explore in the way we handle images in a responsive world.

We are currently working on an asset server that will allow us to dynamically request different sizes and formats of assets (for example, SVG to PNG), which we can offset, crop, etc., right from the src property, also being far more cacheable with long expiry times. It will also make it easier to share assets, as they will be located at a permanent URL and will become findable through a database and metadata, which should encourage reuse.

These were the solutions we came up with and worked best with your timescales and resources. We’d love to hear how you’ve handled images in your responsive projects too, so let us know in the comments!

Read the next post in this series: “Making ubuntu.com responsive: updating font sizes and increasing readability”

Reading list

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

One of the biggest challenges when making the move to responsive was tackling the navigation in ubuntu.com. This included rethinking not only the main navigation with first, second and third level links, but also a big 3-tier footer and global navigation.

Navigation in large screens

Footer in large screensDesktop size main navigation and footer on ubuntu.com.

1. Brainstorming

Instead of assigning this task to a single UX designer, and with the availability of everyone in the team very tight, we gathered two designers and two UX designers in a room for a few hours for an intensive brainstorming session. The goal of the meeting was to find an initial solution for how our navigation could work in small screens.

We started by analysing examples of small screen navigation from other sites and discussing how they could work (or not) for ubuntu.com. This was a good way of generating ideas to solve the navigation for our specific case.

Guardian, BBC, John Lewis navigationSome of the small screen navigation examples we analysed, from left to right: the Guardian, BBC and John Lewis.

We decided to keep to existing common design patterns for small screen navigation rather than trying to think of original solutions, so we stuck with the typical menu icon on the top right with a dropdown on click for the top level links.

Settling on a solution for second and third level navigation was trickier, as we wanted to keep a balance between exposing our content and making the site easy to navigate without the menus getting in the way.

We thought keeping to simple patterns would make it easier for users to understand the mechanics of the navigation quickly, and assumed that in smaller screens users tend to forgive extra clicks if that means simpler and uncluttered navigation.

SketchesSome of the ideas we sketched during the brainstorming session.

2. Prototyping

With little time on our hands, we decided we’d deliver our solution in paper sketches for a prototype to be created by our developers. The starting point for the styling of the navigation should follow closely that of Ubuntu Insights, and the remaining tweaks should be built and designed directly in code.

Ubuntu Insights navigationNavigation of Ubuntu Insights on large and small screens.

We briefed Ant with the sketches and some design and UX direction and he quickly built a prototype of the main navigation and footer for us to test and further improve.

Initial navigation prototypeFirst navigation prototype.

3. Improving

We gathered again to test and review the prototype once it was ready, and suggest improvements.

Everyone agreed that the mechanics of the navigation were right, and that visual tweaks could make it easier to understand, providing the user with more cues about the hierarchy of the content.

Initially, when scaling down the screen the search and navigation overlapped a small amount before the small screen menu icon kicked in, so we also thought it would be nice to animate the change of the amount of padding between widths.

We also made sure that if JavaScript is not available, when the user clicks on the menu icon the page scrolls down to the footer, where the navigation is accessible.

Final navigation prototypeFinal navigation prototype, after some tweaks.

Some final thoughts

When time is of essence, but you still want to be able to experiment and generate as many ideas as possible, spending a couple of hours in a room with other team members, talking through case studies and how they can be applied to your situation proved a really useful and quick way to advance the project. And time and time again, it has proved very useful to invite people who are not directly involved with the project to give the team valuable new ideas and insights.

We’re now planning to test the navigation in our next quarterly set of usability testing, which will surely provide us with useful feedback to make the website easier to navigate across all screen sizes.

Read the next post in this series: “Making ubuntu.com responsive: dealing with responsive images”

Reading list

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

A big part of converting our existing fixed-width desktop site to be responsive was to make sure we had a flexible grid that would flow seamlessly from small to large screens.

From the start, we decided that we were going to approach the move as simply as possible: we wanted the content our grid holds to become easier to read and browse on any screen size, but that doesn’t necessarily mean creating anything too complex.

Our existing fixed-width grid

Before the transition, our grid consisted of 12 columns with 20px gutters.

The width of each column could be variable, but we were working with 57px columns and 40px padding on each side of the main content container.

GridOur existing fixed-width desktop grid.

Inside that grid, content can be divided into one, two, three or four columns. In extreme cases, we can also use five columns, but we avoid this.

Grid overlaidOur grid laid over an existing page of the site.

We also try keeping text content below eight columns, as it becomes harder to read otherwise.

Adding flexibility

When we first created our web style guide, we decided that, since we were getting our hands dirty with the refactoring of the CSS, we’d go ahead and convert our grid to use percentages instead of pixels.

The idea was that it would be useful for the future, while keeping everything looking almost exactly the same, since the content would still be all held within a fixed-width container for the time being.

Using percentagesA fixed-width container holding percentage-based columns.

This proved one of the best decisions we made and it made the transition to responsive much smoother than we initially thought.

The CSS

We used Gridinator to initially create our basic grid, removed any unnecessary rules and properties from the CSS it generated and added others we needed.

The settings we’ve input, in case you’re wondering, were:

  • Number of columns: 12
  • Column width: 57px
  • Column margins: 20px (technically, the gutters)
  • Container margin: 40px
  • Body font size: 16px
  • Option: percentage units

Gridinator settingsScreenshot of our Gridinator settings.

We could have created this CSS from scratch, but we found this tool saved us some precious time when creating all the variations we needed when using the grid.

You can have a peek into our current grid stylesheet now.

First prototypes

The first two steps we took when creating the initial responsive prototype of ubuntu.com were:

  • Remove the fixed-width container and see how the content would flow freely and fluidly
  • Remove all the floats and positioning rules from the existing CSS and see how the content would flow in a linear manner, and test this on small screen devices

When we removed the fixed-width container, all the content became fluid. Obviously, there were no media queries behind this, so the content was free to grow to huge sizes, with really long line lengths, and equally the columns could shrink to unreasonably narrow sizes. But it was fluid, and we were happy!

Similarly, when checking the float-free prototype, even though there were quite a few issues with background images and custom, absolutely positioned elements, the results were promising.

Float free prototypeOur first float-free prototype: some issues but overall a good try.

These tests showed to us that, even though the bulk of the work was still ahead of us, a lot had been accomplished by simply making the effort to convert our initial pixel-based columns into percentage based ones. This is a test that we think other teams could be able to do, before moving on to a complete revamp of their CSS.

Defining breakpoints

We didn’t want to relate our breakpoints to specific devices, but it was important that we understood what kind of screen sizes people were using to visit our site on.

To give you an idea, here are the top 10 screen sizes (not window size, mind) between 4 March and 3 April 2014, in pixels, on ubuntu.com:

  1. 1366 x 768: 26.15%
  2. 1920 x 1028: 15.4%
  3. 1280 x 800: 7.98%
  4. 1280 x 1024: 7.26%
  5. 1440 x 900: 6.29%
  6. 1024 x 768: 6.26%
  7. 1600 x 900: 5.51%
  8. 1680 x 1050: 4.94%
  9. 1920 x 1200: 2.73%
  10. 1024 x 600: 2.12%

The first small screen (360×640) comes up at number 17 in the list, followed by 320×568 and 320×480 at numbers 21 and 22, respectively.

We decided to test the common approach and try breakpoints at:

  • Under 768px: small screen styles
  • Between 768px and under 986px: medium screen styles
  • 986px and up: large screen styles

This worked well for our content and was in line with what we had seen in our analytics numbers.

At the small screen breakpoint we have:

  • Reduced typographic scale
  • Reduced margins and padding
  • Reduced main content container padding

At this scale, following what we had done in Ubuntu Resources (now Ubuntu Insights), we reused the grid from the Ubuntu phone designs, which divides the portrait screen into 40 squares, horizontally.

Phone gridThe phone grid.

At the medium screen breakpoint we have:

  • Increased (from small screen) typographic scale
  • Increased margins and padding
  • Increased main content container padding

At the large screen break point we have:

  • The original typographic scale
  • The original margins and padding
  • The original main content container padding

Small, medium and large screen spacingComparison between small, medium and large screen spacing.

Ideas for the future

In the future, we would like to use more component-specific breakpoints. Some of our design components would work better if they reflowed or resized at different points than the rest of the site, so more granular control over specific elements would be useful. This usually depends on the type and amount of content the component holds.

What about you? We’d love to know how other people have tackled this issue, and what suggestions you have to create flexible and robust grids. Have you used any useful tools or techniques? Let us know in the comments section.

Read the next post in this series: “Making ubuntu.com responsive: adapting our navigation to small screens”

Reading list

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

If you’re transitioning a fixed-width website into a responsive one with several time and resource constraints, updating all your content to be mobile-friendly will likely not be an option.

It’s important to understand what your constraints are and work within them. This is what makes a good designer great — you could even say it’s the definition of our jobs.

This was certainly our case: very early in the process of converting ubuntu.com into a responsive site we knew we wouldn’t be able to edit the existing content. We did, however, follow a few ‘content rules’, and this is something you can define within your projects too.

Evergreen content

We created the Ubuntu Insights site to hold dated content like case studies, news and white papers, and to keep a constant influx of fresh content into ubuntu.com and other Ubuntu sites. Not only did creating Ubuntu Insights allow us to keep ubuntu.com fresh, it gave us a place to move a lot of the detailed content that previously existed on the main site to. We end up with fewer pages and also with shorter pages, which is one of the challenges of converting a site to be responsive with no content updates: the pages become too long.

Ubuntu InsightsThe latest iteration of Ubuntu Insights.

We’ve been working on this project for a few months now, and will be releasing its final update soon, which will include a dedicated press area.

No content or information architecture updates

Once you go back to work you’ve completed some time ago, it’s natural that you start seeing lots of things, big and small, you want to improve. However, when the scope of a project is really tight (and which project isn’t?), it’s important not to fall into temptation.

Updating the structure and content of the website in preparation for making it responsive was not an option for us, as that would involve a fair number of people and time that were not at our disposal.

We decided to flag anything we’d want to look at again in the future, but moving things around was out of the question.

A couple of sections of the site were going to suffer some changes that might impact content and information architecture, but those had been flagged at earlier stages, and we knew to only start reviewing and working on those later on in the responsive project.

No hidden content

A decision we made early on was that we weren’t going to hide any content from small screens.

We could still use common patterns like accordions and tabs to show content in a more digestible format, but all content should be available in small screens, just as it would in larger screens.

AccordionAccordions chunk the content nicely at smaller screen sizes.

Future plans

Improving the content on ubuntu.com will be a gradual process. As new pieces of content are added and updated, we’re now making sure that content is optimised for a smaller screen experience, being mindful of endless scrolling and keeping the message clear and focused on each page and section of the site.

Looking at mobile first has already pushed us towards simplifying our content. We’re trying to think about shorter, more carefully written text that relies less on images and animations. This includes paring down on charts, cutting out text that really is there to support images, and considering the reason for existence of any new fourth-level pages.

In the future, we’ll likely want to do a content revamp of the entire site, but that’s a huge project on its own and probably one that deserves its own series of posts.

We’d love to hear about your experiences and tips on improving content for a responsive iteration of your sites: add your thoughts in the comments section!

Read the next post in this series: “Making ubuntu.com responsive: making our grid responsive”

Reading list

Read more