We recently introduced Vanilla framework, a light-weight styling framework which is intended to replace the old Guidelines framework as the basis for our Ubuntu and Canonical branded sites and others.

One of the reasons we created Vanilla was because we ran into significant problems trying to use Guidelines across multiple different sites because of the way it was made. In this article I’m going to explain how we structured Vanilla to hopefully overcome these problems.

You may wish to skip the rationale and go straight to “Overall structure” or “How to use the framework”.

Who’s it for?

We in Canonical’s design team will definitely be using Vanilla, and we also hope that other teams within Canonical can start to use it (as they did with Guidelines before it).

But most importantly, it would be fantastic if Vanilla offers a solid enough styling basis that members of the wider community feel comfortable using it as well. Guidelines was never really safe for the community at large to use with confidence.

This is why we’ve made an effort to structure Vanilla in such a way that any or all of it can be used with confidence by anyone.

Limitations of Guidelines

Guidelines was initially intended to solve exactly one problem – to be a single resource containing all the styling for ubuntu.com. This would mean that we could update Guidelines whenever we needed to update ubuntu.com’s styling, and those changes would propagate across all our other Ubuntu-branded sites (e.g.: cn.ubuntu.com or developer.ubuntu.com).

So we simply structured the markup of these sites in the same way, and then created a single hosted CSS file, and linked to it from all the sites that needed Ubuntu styling.

As time went on, two large problems with this solution emerged:

• As over 10 sites were linking to the same CSS file, updating that file became very cumbersome, as we’d have to test the changes on every site first.
• As the different sites became more individual over time, we found we were having to override the base stylesheet more and more, leading to overly complex and confusing local styling.

This second problem was only exacerbated when we started using Guidelines as the basis for Canonical-branded sites (e.g.: canonical.com) as well, which had a significantly different look.

Architecture goals for Vanilla

Learning from our experiences with Guidelines, we planned to solve a few specific problems with Vanilla:

• Website projects could include only the CSS code they actually needed, so they don’t have to override lots of unnecessary CSS.
• We could release new changes to the framework without worrying about breaking existing sites, allowing us to iterate quickly.
• Other projects could still easily copy the styles we use on our sites with minimal work

To solve these problems, we decided on the following goals:

• Create a basic framework (Vanilla) which only contains the common elements shared across all our sites.
  • This framework should be written in a modular way, so it’s easy to include only the parts you need
• Extend the basic framework in “theme” projects (e.g. ubuntu-vanilla-theme) which will apply specific styling (colours etc.) for that specific brand.
  • These themes should also only contain code which needs to be shared. Site-specific styling should be kept local to the project
• Still provide hosted compiled CSS for sites to hotlink to if they like, but force them to link to a specific version (e.g. vanilla-framework-version-0.0.15.css) rather than “latest” so that we can release a new version without worry.

Sass modularisation

This modular structure would be impossible in pure CSS. CSS itself offers no mechanism for encapsulation. Fortunately, our team has been using Sass to write our CSS for a while now, and Sass offers some important mechanisms that help us modularise our code. So what we decided to create is actually a Sass mixin library (like Bourbon for example) using the following mechanisms:

Default variables

Setting global variables is essential for the framework, so we can keep consistent settings (e.g. font colours, padding etc.). Variables can also be declared with the !default flag. This allows the framework’s settings to be overridden when extending the framework:

We’ve used this pattern in each of the Vanilla themes we’ve created.

Separating concerns into separate files

Sass’s @import feature allows us to encapsulate our code into files. This not only keeps our code tidier, but it means that anyone hoping to include some parts of our framework can choose which files they want:

Keeping everything in a mixin

When a Sass file is imported any loose CSS is compiled directly to the output. But anything declared inside a @mixin will not be output unless you call the mixin.

Therefore, we set a goal of ensuring that all parts of our library can be imported without any CSS being output, so that you can import the whole module but just choose what you want output into your compiled CSS:

Namespacing

To avoid conflicts with any local sass setup, we decided to namespace all our mixins with the vf- prefix – e.g. vf-grid or vf-header.

Overall structure

Using the aforementioned techniques, we created one base framework, Vanilla Framework, which contains (at the time of writing) 19 separate “modules” (vf-buttons, vf-grid etc.). You can see the latest release of the framework on the project’s homepage, and see the framework in action on the demo page.

The framework can be customised by overriding any of the global settings inside your local Sass, as described above.

We then extended this basic framework with three branded themes which we will use across our sites:

• Ubuntu Vanilla Theme
• Canonical Vanilla Theme
• Cloud Vanilla Theme

You can of course create your own themes by extending the framework in the same way.

NPM modules

To make it easy to include Vanilla Framework in our projects, we needed to pick a package manager to use for installing it and tracking versions. We experimented with Bower, but in the end we decided to use the Node package manager. So now anyone can install and use any of the following packages:

• vanilla-framework
• ubuntu-vanilla-theme
• canonical-vanilla-theme
• cloud-vanilla-theme

Hotlinks for compiled CSS

Although for in-depth usage of our framework we recommend that you install and extend it locally, we also provide hosted compiled CSS files, both minified and unminified, for the Vanilla framework itself and all Vanilla themes, which you can hotlink to if you like.

To find the links to the latest compiled CSS files, please visit the project homepage.

How to use the framework

The simplest way to use the framework is to hotlink to it. To do this, simply link to the latest version (minified or unminified) directly in your HTML:

However, if you want to take full advantage of the framework’s modular nature, you’ll probably want to install it directly in your project.

To do this, add the latest version of vanilla-framework to your project’s package.json as follows:

Then, after you’ve npm installed, include the framework from the node_modules folder:

The future

We will continue to develop Vanilla Framework, with version 0.1.0 just around the corner. You can track our progress over on the project homepage and on Github.

In the near future we’ll switch over ubuntu.com and canonical.com to using it, and when we do we’ll definitely blog about it.

We have given our monochromatic icons a small facelift to make them more elegant, lighter and consistent across the platform by incorporating our Suru language and font style.

The rationale behind the new designs are similar to that of our old guidelines, where we have kept to our recurring font patterns but made them more streamlined and legible with lighter strokes, negative spaces, and a minimal solid shape.

What we have changed:

• Reduced and standardized the strokes width from 6 or 8 pixels to 4.
• Less solid shapes and more outlines.
• The curvature radius of rectangles and squares has been slightly reduced (e.g message icon) to make them less ‘clumsy’.
• Few outlines are ‘broken’ (e.g bookmark, slideshow, contact, copy, paste, delete) for more personality. This negative space can also represent a shadow cast.

Less solid shapes

Before

After

Lighter strokes

Before

After

Negative spaces

Before

After

Font patterns 

Oblique lines are slightly curved

Arcs are not perfectly rounded but rather curved

Uppercase letters use right or sharp angles

Vertical lines have oblique upper terminations.

Nice soft curves

Action

Devices

Indicators

Weather

.gsa-example { margin: 1em 0; } .gsa-example p { display: none; } .gsa-grid { font-size: 14px; color: #555; border: 0.5px solid #CCC; } .gsa-grid-header { height: 30px; line-height: 30px; text-align: center; background: #F3F3F3; border-bottom: 0.5px solid #CCC; } .gsa-grid-container { display: table; width: 100%; height: 80px; } .gsa-grid-part { display: table-cell; text-align: center; vertical-align: middle; } .gsa-grid-margin { font-size: 12px; background: #FBFFCF; } .gsa-grid-content { background: #D6FED6; } .gsa-grid-panel { position: relative; background: #FFECDE; } .gsa-grid-panel:before { content: ''; position: absolute; left: 0; top: 0; bottom: 0; width: 0.5px; background: #666; } .gsa-grid-panel:first-child:before { display: none; } .gsa-grid-mcl-margin { background: #FBFFCF; } .gsa-grid-mcl-gutter { background: #CFFFFF; } .gsa-grid-mcl-column { background: #C3CBE4; } .gsa-pseudocode { font-size: 1em; margin-bottom: 1em; } .post-content h2 { margin-top: 0.863em; }

Following the article “To converge onto mobile, tablet, and desktop, think Grid Units”, here is a technical description of the way the Grid System behave. We will go through the following concepts: a Grid Unit, a Layout, a Panel, and a Multi-Column Layout.

Grid Unit

A Grid Unit (GU) is a virtual subdivision of screen space. The actual size, in pixels, of one Grid Unit is assigned by the OS depending on the device’s screen size and density, freeing the developer from worrying about these device-specific details. For more description of the system and its benefits, please see this design blog posting.

Note: There are only three target short-side screens in the grid system: 40, 50, and 90. A Grid Unit can not contain a fractional number of pixels, so if the screen width can not divide by the desired number of Grid Units (40, 50, or 90), the remainder becomes side margins.

Grid Unit Calculation

The width of a single Grid Unit is calculated as follows:

• The width of the short edge of the screen is divided by the desired number of grid units (integer division).
• The remainder, if any, gives us the size of the margins.
• The quotient gives us the size of one Grid Unit.

In pseudocode:

margins = total_width mod layout_grid_units
grid_width = total_width - margins
grid_unit_width = grid_width / layout_grid_units

Example with a 540×960 screen and a 50 GU Layout

margins = 540 mod 50 = 40
grid_width = 540 - margins = 500
grid_unit = grid_width / 50 = 10

Example with a 1600×2560 screen and a 90 GU Layout

margins = 1600 mod 90 = 70
grid_width = 1600 - margins = 1530
grid_unit = grid_width / 90 = 17

Layout

A Layout represents the desired number of Grid Units for the short edge of the screen. That number will be used to calculate the width of a single Grid Unit in pixels, using the method described in the Grid Units section. For touch devices, the available layouts are 40 GU, 50 GU (phones or phablets), and 90 GU (tablets).

Landscape Grid Units Count Calculation

The number of Grid Units in Landscape Orientation is calculated as follows:

• The width of the long edge of the screen is divided by the width of of a single grid unit (integer division).
• The remainder, if any, gives us the size of the margins.
• The quotient gives us the number of Grid Units in the Landscape Orientation.

In pseudocode:

margins = total_width mod grid_unit_width
grid_width = total_width - margins
grid_unit_count = grid_width / grid_unit_width

Example with a 540×960 screen, 50 GU Layout and 1 GU = 10px

margins = 960 mod 10 = 0
grid_width = 960 - margins = 960
grid_unit_count = grid_width / 10 = 96

Panel

A Panel is a group of Grid Units. The amount of Grid Units can be any of the Layout sizes (according that it fits in the total amount of Grid Units), or variable for the remaining part.

Examples

90 GU Layout

147 GU Layout

Try more combinations using the Grid System Tool.

Multi-Column Layout

A Multi-Column Layout is a set of columns that can be defined inside of a panel. It contains the following properties:

• Side margins (before the first column and after the last column)
• Gutters (between two columns)
• Columns

It can use from one to six columns. In 40, 50 and 90 GU Panels, the Multi-Column Layouts have been manually selected. For other widths, an algorithm tries to find the best candidate.

The margins and gutters tend to have a 2 GU width, but it can vary depending on the available possibilities.

Examples

3 Columns in a 50 GU Panel

3 Columns in a 60 GU Panel (variable)

Try more combinations using the Grid System Tool.

Last week the SDK team gathered in London for a sprint that focused on convergence, which consisted of pulling apart each component and discussing ways in which each would adapt to different form factors.

The SDK provides off-the-shelf UI components that make up our Ubuntu apps; however now we’re entering the world of Unity 8 convergence, some tweaking is needed to help them function and look visually pleasing on different screen sizes, such as desktop, tablet and other larger screens.

To help with converging your app, the Design Team have created a set of predefined grid layouts screen targets: 40, 50, 90 GU (grid units), which makes life a lot easier to visualize where to place components in different screen sizes.

Scheduled across the week were various sessions focusing on different components from the SDK such as list items, date and time pickers; together with patterns like the Bottom Edge and PageStack. Each session gathered developers, visual and UX designers, where they ran through how a component might look (visual), the usability (UX) and how it will be implemented (developer) on different form factors.

Here’s the mess they made…

Main topics covered:

– Multi-column layouts, panel behaviors and pagestack

– Header, Bottom Edge and edit mode

– Focus handling

– List item layouts

– Date and time pickers

– Drop-down menus

– Scrollbars

– Application menu

– Tooltips

Here are some of the highlights:

• Experiments and explorations were discussed around how the Bottom Edge will look in a multi-column view, and how the content will appear when it is revealed in the Bottom Edge view. Also, design animations were explored around the ‘Hint’ and how they will appear on each panel in a multi-column layout.

• Explorations on how each panel will behave, look and breakpoints of implementing on different grid units (40,50,90).

• A lot of discussion was had around the Header; looking at how it will transform from a phone  layout to a multi-column view in a tablet or desktop. Currently the header holds up to four actions placed on the right, a title, and navigational functions on the left, with a separate header section underneath that acts as a navigation to different views within the app. The Design Team had created wireframes that explored how many headers would appear in a multi-column layout, together with how the actions and header section would fit in.

• Different list item layouts were explored, looking at how many actions, titles and summaries can be placed in different scenarios. Together with a potentially new context/popover menu to accompany the leading, trailing and default options.

• The Design Team experimented with a new animation that happens during a focused state on the desktop.

• The new system exposes all the features of a components, so developers are able to customize and style it more conveniently.

Overall the convergence sprint was a success, with both the SDK and Design Team working in unison to reach decisions and listing priorities for the coming months. Each agreed that this method of working was very beneficial, as it brought together the designers and developers to really focus on the user and developer needs.

They enjoyed some downtime too…

Arrival dinner at Byron Burgers

Out in Soho

Wine tasting in the office (not a regular occurrence)

In the converged world of Unity-8, applications will work on small mobile screens, tablets and desktop monitors (with a mouse and keyboard attached) as if by magic. To achieve this transformation for your own app with little to no extra work required when considering the UI, simply design using grid units for a few predetermined virtual screen targets. Combined with Ubuntu off-the-shelf UI components built with convergence in mind, most of the hard work is done, freeing developers and designers to focus on what’s most important to their users.

What’s a grid unit? And why 40, 50, or 90 of them?

A grid unit (GU) is a virtual measure of screen space that’s independent of device hardware details like pixels or aspect ratio: those complexities are mapped under the covers by Ubuntu. Instead, by targeting just three ‘fixed’ virtual GU portrait widths—40, 50, and 90 GU— you’re guaranteed to be addressing the largest number of devices, including the desktop, to a high degree of design quality and consistency where relative spacing and content sizing just works.

The 40, 50, and 90 GU dimensions correspond to smaller smartphones, larger smartphones/phablets, and tablets respectively in portrait mode. These particular panel-widths weren’t chosen arbitrarily: they were selected by analyzing the most popular device specs on the market and picking the portrait dimensions that would embrace the largest number of possibilities most successfully, including for the desktop (more on that later).

For example, compact phones such as the BQ Aquarius E4.5 are best suited to the 40 GU-wide virtual portrait screen, offering the right balance of content to screen real estate for palm-sized viewing. For larger phones with more screen space such as the Meizu MX4, the 50 GU layout is most fitting, allowing more room for content. Finally, for edge-to-edge tablet portrait layouts for the N7 or N10, the 90 GU layout works best.

Try this exercise

Having trouble envisioning the system in action? Close your eyes and imagine a two-dimensional graph paper divided into squares that can adapt according to just three simple rules:

• It can only be 40, 50, or 90 whole units along the short edge but the long edge can be variable
• The long edge (in landscape mode or on the desktop) will be the whole number of GUs that carves out the maximum area rectangle that will fit within any given device’s physical screen in landscape mode based on the physical dimension of the GU determined from portrait mode (in pixels)
• The last rule is simple but key: the squares of the graph paper must always be square—the graph paper, just to push the image a bit too far—is made of something more like graphene than polypropylene (no squeezed or stretched GUs allowed.)

Try it for yourself here: https://dl.dropboxusercontent.com/u/360991/canonical/grid-units/grid-units.html

There is one additional factor that can impact the final available screen area, but it’s a bit of a technical convolution. The under-the-covers pixels to grid unit mapping can’t include fractional pixels (this may seem like an obvious point, admittedly). But at the end of the day, the user sees the largest possible version of the 40, 50, or 90 GU wide virtual screen that’s possible on any given device. That means that all you have to do as a designer or developer is plan for the virtual dimensions we’ve been talking about, and you’re assured your user is getting the best possible rendering.

Though the system may seem abstract at first, the benefits of this system are all to easy to understand from a developer or designer standpoint: it’s far more predictable and simpler to design for layouts that follow rules rather than trying to account for a universe of idiosyncratic device possibilities. In addition, by using these layouts as the foundation, the convergence goal is much more easily achieved.

What about landscape & desktop? Use building blocks

By assembling these key portrait views together, it’s far easier to achieve landscape and desktop layouts than ever before. For example, if your app lends itself to a two panel layout, simply join together 40 and 50 GU phone layouts (that you’ve already designed) to achieve a landscape layout (or even a portrait tablet layout!)

Similarly, switching from portrait to landscape mode on tablet—also a desktop-friendly layout—could be as simple as joining a 40 GU layout and a 90 GU layout for a total of 130 GU, which fits nicely within both 16:9 and 16:10 tablet landscape screens as well as on any desktop monitor.

Since landscape and desktop layouts are the least predictable due to device variations and manual stretching by users, you can designate that of one of your panel layouts be of flexible width to fill the available space using one of these strategies:

• Center the layout in the available space
• Stretch or squeeze the layout to fit the available space
• Combine these two, depending on the individual components within the layout

More complex layouts can also be achieved by joining three or more portrait layouts, too. For example, three 40 GU layouts can be joined side by side, which happen to fit perfectly into a 4:3 landscape tablet screen.

Columns, too

To help developers even further with one of the most common layouts—columnar or grid types—we’re adding a capability that maintains column-to-content size relationships across devices and the desktop the same way that type sizes are specified. This makes it very simple to achieve the proper content readability and density regardless of the device. For example, by specifying a “medium” sized column filled with “small” type, these relative relationships can be preserved throughout the converged-device experience without having to manually dig into pixel measurements.

The column capability can also adapt responsively to extra wide, variable landscape layouts, such as 16:10 aspect ratio tablets or manually stretched desktop layouts. This means that as more space becomes available as a user stretches the corners of the app window on the desktop, additional columns can be added on cue, providing more room for content.

Putting it all together across all form factors

By making screen dimensions virtual, we can minimize the vagaries of individual hardware specs that can frustrate device-convergent thinking and help developers focus more on their user’s needs. A combination of snap-together layouts, automated column layouts, and adaptive UI toolkit components like the header, list component, and bottom edge component help ensure users will experience a consistent, elegant journey from mobile to desktop and back again.

Check out the video interview here :)

Community members at the Sprint

Victor and Andrew are two inspiring Community developers that have devoted their spare time to contribute to the Ubuntu Touch Music App team. I sat down with them during the Washington Device Sprint in October where they told us how they drew inspiration from the Design Team, and what drives them to contribute to Ubuntu.

You can read more about Victor and Andrew through their blogs, where they post interesting articles on their work and personal projects.

From left to right: Riccardo, Andrew, Filippo and Victor

Hey guys, so when did you first get involved with Ubuntu?

Victor: “I started to contribute to the Ubuntu platform in March/April 2013 where I noticed there was no music app, so I started putting one together. It was pretty sketchy to start with, but it worked. I didn’t have a device to test it on so I mostly tested it using the platform on my desktop – so things were a bit hit and miss.

There was also another developer doing a music app, and at the time there was no core capability of playing music through an application for the proposed devices. Michael Hall (Open Source Software Developer) and Alan Pope (Engineering Manager) pulled Daniel Holm and I together, where we merged our core bases and started the music core app.

We didn’t have as much time as other applications, so we more or less sprinted like we are now to get things done. It was very spec driven and specific, which was helpful but sometimes it was hard to put together a full vision of what the designers wanted. So now we are redoing it from the feedback we have gathered, and it’s going pretty well. A little more agile than it was previously as to do thing faster, but it’s been fun the whole time. It’s nice to work on an application that people need and gets visibility, never get sick of hacking at it.”

Andrew: “I’m from North London, where I’m currently studying Software Engineering at Oxford Brookes University. I was working on my own music app where I just taught myself how to do things using my own framework, then I saw that these guys at Ubuntu had a similar problem to me, and so I thought I’d provide a patch. This then built up from there, and now here I am!”

Steph: “It’s amazing that someone can be in their bedroom writing codes and then suddenly your app is on a phone!”

Victor: “The other great thing about it is the Community Managers make it easy and apparent that you can contribute to different projects.”

Andrew: “Yeah someone just got in contact with me and asked me if I wanted to join the team and told me how open source projects work.”

What inspired you to contribute?

Victor: “A lot of my original inspiration was from what the Design Team had previously done. The previous iteration design spec was very large for the music app and it wasn’t as future driven, more just visually pleasing.”

Do you find it hard to implement some designs?

Victor: “We try to make it as close to the designs as we can, but obviously there’s compromises. There was some very flow driven things such as: sized cover arts that were hard to implement, but we can implement them now. It’s nice because they use the same pattern from other applications.”

Andrew: “Usually we just tell the designer that this is just not possible.”

What is it about open source that you like?

Victor: “I have been a user since 2006, but I have never been a large open source developer myself. It is hard to get involved with when you don’t know what you want to contribute to.”

Andrew: “Most applications are so developed already, so you would have to learn the existing code base and develop on it, whereas if you start a new you know everything from the get-go. Seeing your application on the device and knowing it can be on other devices too, is pretty exciting!”

How does it fit into your lifestyles?

Victor: “I’m a software engineer as well, so I write a lot of code. I haven’t really done QML or QT until I started doing these applications with the Ubuntu platform, so it has been a learning experience. I am learning something new from experienced people.”

Have you made any other applications for Ubuntu?

Victor: I’ve made a few games like Piano Tiles, and another that’s kind of like a clone of that but in QML – It’s a simple app but a good time waster haha.”

How much time does it take you to develop an app?

Victor: “It took me like a day. Andrew made a game last night! In 2 hours…”

Andrew: “Yeah we did! Loads of us at the sprint just got together in a room and made a few games.”

So you’re used to working remotely, does that put a barrier against things?

Andrew: “It sometimes delay things. However, you start to build this image of a person, so when you actually get to meet them you start to understand how they are and what makes them tick.

Victor: “Depends on how personal it really needs to be. If you are collaborating together and it’s mostly writing code and coming up with ideas, it doesn’t necessarily need to be face-to-face. It is obviously nicer, but you also get the benefit if the other person is a night owl in a different country where sometimes our hours overlap, two different chunks of time we’re working in.

Andrew: “There’s usually someone on IRC to speak to, it’s like a 24 hour operation haha.”

What’s the vibe like in the Community at the moment?

Victor: “It’s a pretty small Community at the moment, with close ties. Everyone is receptive to feedback, so if it was larger Community I don’t think it would be as receptive.”

Steph: “Thanks for your time guys!”

Here’s a sneaky preview of the music app, more will be revealed soon:

Album detail

Landing page

We sat down with some of Ubuntu’s unsung Community heroes at the recent Devices Sprint in Washington D.C.

Riccardo and Filippo are two young and passionate developers who have adapted their own software to benefit the whole of the Ubuntu Community. We spoke about how and why they contribute to Ubuntu, and what motivates them to keep giving.

(Community gathering at the Sprint)

Riccardo Padovani 

Italian Community site:

http://ubuntu.it/

Personal blog:

http://blog.rpadovani.com/

So Riccardo, how did you get involved in Ubuntu?

I started 3 years ago with the Italian Ubuntu Community as they were looking for someone who could manage the website. I was young and wanted to learn about computer science, so I started for myself. While I was contributing I started to understand what was behind the Ubuntu project and their philosophy, and I thought this was a great project for software. So then I started to do stuff for Ubuntu Touch, where I made new friends and at the same time improved my English and computer science skills.

How does working in the Italian Ubuntu Community fit into your lifestyle?

I’m at University, so in the evenings instead of watching television I open my notebook and do some coding. For me it’s very fun. It’s not something I do because someone is telling me to, I do it for me. I prefer writing code than watching TV haha.

What kind of things have you contributed to Ubuntu so far?

Last year I was mainly working on the Reminder App, but now more recently I’ve started to contribute towards the Web Browser. As I use Ubuntu as my main phone I love seeing the improvements in the software I use everyday, as I know I can do something to improve it. People will benefit when the phone is released, more so on the Italian Community Site for example: when there’s something wrong and someone reports it to me, loads of people can see my work and I can fix it. It’s awesome, as I am getting better experience at the same time.

How did you start to contribute to the Community? How does it work?

I started to use Ubuntu in 2008, but before 2012 I did nothing until I found a project I wanted to get involved with. I think for every project and Community you need to find something you love and want to improve. Opening a new bug when something is wrong is the first step to contributing to an Ubuntu project.

First you find out how the Community works and then you begin to know who you can speak to, which then graduates into a natural evolution.

Does your Community regularly meet-up?

It depends on the team, as some teams are split and do different things. Every 6 months we have a meeting where we can have a beer and socialise. The rest of the year we try to do public hangouts, and then private hangouts on what we’re doing in the next month or so.

Do you find these sprints helpful?

I think during this sprint it takes more energy to do code, because I’m busier talking to people and learning new things. For the people who can or have taught me something I can meet them and say thank you in person, it is nice.

Filippo Scognamiglio

Personal blog:

http://swordfishslabs.wordpress.com/

Hey Filippo, so tell me how did you get involved with Ubuntu?

I started with some gaming applications where I first made MineSweeper. MineSweeper is not in the Ubuntu Store at the moment due to some technicalities and design issues, but it’s all working and should be implemented soon. I also made another game called Ubuntu Netwalk where you connect sources of energy to destinations and then rotate the pieces to solve the puzzle.

I started a new project that was completely unrelated to Ubuntu, which was a terminal emulator. A terminal emulator is a program that emulates a video terminal within some other display architecture.

I published a video of my work and no one cared at the start, but then a few months after I made another video and everyone loses their mind! I was really busy answering emails and questions about it. Then David Planella (Ubuntu Community Team Manager) approached me and asked me to import the terminal to the Ubuntu Touch, as the engine was the same, and so that’s where my Ubuntu story really began.

So, what’s your background?

I am currently studying Computer Engineering at University back in Italy.

Being part of a Community, what does it mean?

I wasn’t part of the Community before doing something relevant, then I got a part after I was approached. Usually people first start with commenting on the forums or fixing bugs, where you begin to build a presence in the Community. For me it was just like falling from the sky, now I want to be more involved in the Community. I never knew all these guys, today I only knew Riccardo, Alan Pope (Engineering Manager) and David Planella through email exchange, that’s it!

How’s the Sprint going for you? 

The Sprint itself is a nice opportunity to see the USA as it is my first time here. For me it is a great opportunity to finally meet the people I have been working with remotely and say thanks. I find it hard when I work from home as you’re on your own, but now I’m here at the sprint I can go grab people and interact more.

When I compare myself to my schoolmates who aren’t involved in Ubuntu or other projects, I can see the benefits it will give me in my career after university.

What motivates you? 

I get motivated by the people I can learn from. In Ubuntu I’m involved with people who are much more experienced than me, so they can teach me new things and I can produce at the same time. Learning from others on your own project or part of Ubuntu is not possible with closed source projects, because with closed source you can have an opinion on what’s good or not. They can’t tell you should do this, they simply have an external point of view.

Another good thing about open source is that you can do a lot more things with less effort. My terminal was taken from another terminal, if it wasn’t open source I would have had to write the terminal from the engine to the user interface. I drew influenced from other engines that have been made and then adapted it to my needs, of which those people who made that engine probably took it from someone else – that’s the beauty of open source.

I am happy if my project goes on and influences something/someone else, and they can take my software and adapt it to their own needs.

(From left to right: Riccardo, Andrew, Filippo and Victor)

(Community meal out)

Last week was a week of firsts for me: my first trip to America, my first Sprint and my first chili-dog.

Introducing myself as the new (only) Editorial and Web Publisher, I dove head first into the world of developers, designers and Community members. It was a very absorbing week, which after felt more like a marathon than a sprint.

After being grilled by Customs, finally we arrived at Tyson’s Corner where 200 or so other developers, designers and Community members gathered for the Devices Sprint. It was a great opportunity for me to see how people from each corner of the world contribute to Ubuntu, and share their passion for open source. I especially found it interesting to see how designers and developers work together, given their different mind sets and how they collaborated together.

The highlight for me was talking to some of the Community guys, it was really interesting to talk to them about why and how they contribute from all corners of the world.

(From left to right: Riccardo, Andrew, Filippo and Victor)

(The main Ballroom)

(Design Team dinner. From the left: TingTing, Andrew, John, Giorgio, Marcus, Olga, James, Florian, Bejan and Jouni)

I caught up with Olga and Giorgio to share their thoughts and experiences from the Sprint:

So how did the Sprint go for you guys?

Olga: “It was very busy and productive in terms of having face time with development, which was the main reason we went, as we don’t get to see them that often.

For myself personally, I have a better understanding of things in terms of what the issues are and what is needed, and also what can or cannot be done in certain ways. I was very pleased with the whole sprint. There was a lot of running around between meetings, where I tried to use the the time in-between to catch-up with people. On the other hand as well, Development made the approach to the Design Team in terms of guidance, opinions and a general catch-up/chat, which was great!

Steph: “I agree, I found it especially productive in terms of getting the right people in the same room and working face-to-face, as it was a lot more productive than sharing a document or talking on IRC.”

Giorgio: “Working remotely with the engineers works well for certain tasks, but the Design Team sometimes needs to achieve a higher bandwidth through other means of communication, so these sprints every 3 months are incredibly useful.

What a Sprint allows us to do is to put a face to the name and start to understand each other’s needs, expectations and problems, as stuff gets lost in translation.

I agree with Olga, this Sprint was a massive opportunity to shift to much higher level of collaboration with the engineers.

What was your best moment?

Giorgio: “My best moment was when the engineers perception towards the efforts of the Design Team changed. My goal is to better this collaboration process with each Sprint.”

Did anything come up that you didn’t expect?

Giorgio: “Gaming was an underground topic that came up during the Sprint. There was a nice workshop on Wednesday on it, which was really interesting.”

Steph: “Andrew a Community Developer I interviewed actually made two games one evening during the Sprint!”

Olga: “They love what they do, they’re very passionate and care deeply.”

Do you feel as a whole the Design Team gave off a good vibe?

Giorgio: “We got a good vibe but it’s still a working progress, as we need to raise our game and become even better. This has been a long process as the design of the Platform and Apps wasn’t simply done overnight. However, now we are in a mature stage of the process where we can afford to engage with Community more. We are all in this journey together.

Canonical has a very strong engineering nature, as it was founded by engineers and driven by them, and it is has evolved because of this. As a result, over the last few years the design culture is beginning to complement that. Now they expect steer from the Design Team on a number of things, for example: Responsive design and convergence.

The Sprint was good, as we finally got more of a perception on what other parties expect from you. It’s like a relationship, you suddenly have a moment of clarity and enlightenment, where you start to see that you actually need to do that, and that will make the relationship better.”

Olga: “The other parties and the Development Team started to understand that initiated communication is not just the responsibility of the Design Team, but it’s an engagement we all need to be involved in.”

In all it was a very productive week, as everyone worked hard to push for the first release of the BQ phone; together with some positive feedback and shout-outs for the Design Team :)

(Unicorn hard at work)

There was a bit of time for some sightseeing too…

It would have been rude not to see what the capital had to offer, so on the weekend before the sprint we checked out some of Washington’s iconic sceneries.

(The Washington Monument)

We saw most of the important parliamentary buildings like the White House, Washington Monument and Lincoln’s Statue. Seeing them in the flesh was spectacular, however, I half expected a UFO to appear over the Monument like in ‘Independence Day’, and for Abraham Lincoln to suddenly get up off his chair like in the movie ‘Night at the Museum’ – unfortunately none of that happened.

(The White House)

D.C. isn’t as buzzing as London but it definitely has a lot of character, as it embodies an array of thriving ethnic pockets that represented African, Asian and Latin American cultures, and also a lot of Italians. Washington is known for getting its sax on, so me and a few of the Design Team decided to check-out the night scene and hit a local Jazz Club in Georgetown.

(Twins Jazz Club)

On the Sunday, we decided to leave the hustle and bustle of the city and venture to the beautiful Great Falls Park, which was only 10-15 minutes from the hotel. The park was located in the Northern Fairfax County along the banks of the Potomac River, which is an integral part of the George Washington Memorial Parkway. Its creeks and rapids made for some great selfie opportunities…

(Great Falls Park)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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! 

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.

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

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.

Aisle banner

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!

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

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!

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.

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.

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

BrowserStack 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

• See your site like the rest of the world does. On the Nokia X2-01
• “Mobile first” CSS and getting Sass to help with legacy IE
• Outdated Browser
• Modern IE

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

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

• Fluid Type
• Designing For The Reading Experience
• Unicode For A Multi-Device World
• Typecast
• FitText

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.

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?

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

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.

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

Pictograms, 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’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.

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

• Asset Fonts by Josh Emerson
• Picturefill 2.0: Responsive Images And The Perfect Polyfill
• Responsive Images Done Right: A Guide To And srcset
• Picturefill
• Imager.js
• Ten reasons we switched from an icon font to SVG