Canonical Voices

Posts tagged with 'featured'

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

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

As the number of Juju users has been rapidly increasing over the past year, so has the number of new solutions in the form of charms and bundles. To help users assess and choose solutions we felt it would be useful to improve the visual presentation of charm and bundle details on manage.jujucharms.com.

While we were in Las Vegas, we took advantage of the opportunity to work with the Juju developers and solutions team to find out how they find and use existing charms and bundles in their own deployments. Together we evaluated the existing browsing experience in the Juju GUI and went through JSON-files line by line to understand what information we hold on charms.

carla.jpg

We used post-its to capture every piece of information that the database holds about a bundle or charm that is submitted to charmworld.

 

We created small screen wireframes first to really focus on the most important content and how it could potentially be displayed in a linear way. After showing the wireframes to a couple more people we used our guidelines to create mobile designs that we can scale out to tablet and desktop.

With the grouped and prioritised information in mind we created the first draft of the wireframes.

 

In order to verify and test our designs, we made them modular. Over time it will be easy to move content around if we want to test if another priority works better for a certain solution. The mobile-first approach is a great tool for making sense of complex information and forced us to prioritise the content around user’s needs.

jaas-store

First version designs.

Read more
Inayaili de León Persson

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

Following the designers and developers sprint, we had a full web team workshop day to discuss our findings and plan the work for the following weeks.

Planning and scoping was tricky because we had to balance the work required to make the site responsive with incoming work requests from the business — there was a big release of Ubuntu coming up and lots of content updates along with it.

We carried out a few team exercises that helped us to deconstruct the project into smaller chunks that we could prioritise and plan around other commitments, so that it didn’t feel like building the Titanic but rather something more manageable.

Creating a wishlist

Initially, it’s good to have an idea of what each person considers important for the project.

The simplest way to capture everything you want to do in a project is to write all ideas on separate sticky notes. This approach helps to identify common themes and priority tasks.

This is a good opportunity to get the entire team together in a room and give everyone space to say what they hope to achieve in the near, and not so near, future.

At the end, though, it’s only natural that you’ll be left with a huge amount of ideas, so it’s necessary to organise them into groups, like projects or topics.

Dividing work into phases

Following the wishlist exercise, and based on the resources and time available, fixed deadlines, and business goals, the list was trimmed down into four time frames:

  • To be completed before the Ubuntu 14.04 LTS release
  • To be completed for the release
  • To be completed soon after release
  • To be completed later

If you have hard deadlines for other projects that are in your team’s plate, start adding those into a calendar overview (we used four sticky notes columns) and discuss what can be done within the time that is left available.

For example, we knew that, in preparation for Ubuntu’s presence at the Mobile World Congress at the end of February, the content of the tablet and phone sections of the website would have to be updated ahead of any responsive work going live.

Defining high priority tasks

In terms of the responsive project itself, we defined the priority tasks:

  • Update our CSS with the components that had been created for the two initial responsive projects and that would be useful across our sites
  • Find an initial solution for main, second and third level navigation, and multiple footers
  • Create updated image assets where necessary

And we also defined what we wouldn’t do at this stage:

  • Rewrite copy
  • Restructure and reorder content
  • Change the information architecture of the site
  • Update the site’s visual style

It was important to have these restrictions in place in order to keep the scope of the project as small and as feasible as possible. Most times, it’s impossible to do everything you wanted in the first instance of moving to responsive, so deciding what would be the biggest wins for the amount of time you have available is an important step in planning the work.

At the end of the workshop, we all felt more comfortable with the amount of work ahead: following a few simple exercises, we had identified pain points, set realistic goals and expectations, and established priorities.

Content risk assessment

Matt went through all the pages of the site to assess what, in terms of the design, could become an issue once the site was responsive and once the content had to fit into small screens. These findings were added to a document divided into five different types of content:

  • Images
  • Graphs
  • Tables
  • Layout and behaviour
  • Text

With this document we could see how much work we potentially would have when transitioning all the pages of the site to the updated responsive styles, and which would be the trickier problems to solve.

Estimating time

With the content inventory at hand, Ant estimated the degree of difficulty of converting each page for responsive, using a scale of 1 to 3. He then estimated how many ‘points’ he should be able to get done in one day, which left us with an estimated time of completion of the first pass at fixing rendering issues.

Something to bear in mind when estimating times is that, while fixing the rendering issues that came with converting all the pages of the site to the responsive styles proved faster than initially estimated, the testing across different devices and screen sizes that followed was time-consuming for both designers and developers.

The complexity of testing and how long you should allow for it will depend on the site’s design and the CSS being used: for example, when using newer techniques you should allow for enough time to create suitable fallbacks for browsers with fewer capabilities. Another thing to keep in mind is that testing across devices should be done as you go, rather than at the very end of the process. Just a quick look at a couple of different devices and browsers (for example, previous Android versions and Opera Mini) before you start the estimation process will you give you clearer idea of the amount of work that lies ahead.

Even though our time estimates were a little off, creating those spreadsheets and dividing the work into very small blocks made us feel more in control, and, as we ticked pages off, it made us feel motivated.

Conclusion

When you’re working on a large living and breathing website, you know that all the updates and changes that come along with it don’t stop just because you want to make your site responsive. It’s important that everyone involved understands that you should be putting your website first, and that responsive is not necessarily the top priority. That’s why it’s important to be smart about the way you plan the project and give yourself some parameters to work within — the transition isn’t going to happen overnight.

Read the next post in this series: “Making ubuntu.com responsive: approach to content”

Read more
Giorgio Venturi

With the unstoppable rise of mobile apps, some pundits within the tech industry have hastily demoted the mobile web to a second-class citizen, or even dismissed it as ‘dead’. Who cares about websites and webapps when you can deliver a superior user experience with a native app?

Well, we care because the reality is a bit different. New apps are hard to discover; their content is locked, with no way to access it from the outside. People browse the web more than ever on their mobile phones. The browser is the most used app on the phone, both as starting point and a destination in the user journey.

Installing
Source: xkcd

At Ubuntu, we decided to focus on improving the user experience of browsing and searching the web. Our approach is underpinned by our design principles, namely:

  1. Content is king: UI should recede in the background once user starts interacting with content
  2. Leverage natural interaction by using gestures and spatial metaphors.

In designing the browser, there’s one more principle we took into account. If content is our king, then recency should be our queen.

Recency is queen

People forget about things. That’s why tasks such as finding a page you visited yesterday or last week can be very hard: UIs are not designed to support the long-term memory of the user. For example, when browsing tabs on a smartphone touchscreen, it is hard to recognise what’s on screen as we forgot what that page is and why we arrived there.

Similarly, bookmarks are often a meaningless list of webpages, as their value was linked to the specific time when they were taken. For example, let’s imagine we are planning our next holiday and we start bookmarking a few interesting places. We may even create a new ‘holidays’ folder and add the bookmarks to it. However, once the holiday is the bookmarks are still there, they don’t expire once they have lost their value. This happens pretty much every time; old bookmarks and folders will eventually start cluttering our screen and make it difficult to find the information we need.

Therefore we redesigned tabs, history and bookmarks to display the most recent information first. Consequently, the display and the retrieval of information is simplified.

Browser tabs

In our browser, most recent tabs come first. Here is how it works:

Browser tabs

In this way, users don’t have to painstakingly browse an endless list of tabs that may have been opened weeks or days ago, like in Mobile Safari or Chrome.

History

Browser history has not changed much since Netscape Navigator; modern browser still display a chronological log of all the web pages we visited starting from today. Finding a website or a page is hard because of the sheer amount of information. In our browser we employ a clustered model where you display the last visited websites, not every single page. On tap, you then display all webpages for that websites, starting from the most recent. In this way scanning the history log is much easier and less painful.

Browser history

Loving the bottom edge

We believe the bottom edge is the most pleasurable edge to use. It is easily accessible at any time and ergonomically friendly to the typical one-hand phone hold. Once discovered, it will slowly build into our muscle memory and become a natural and intuitive way of interacting with the application.

Bottom edge

This is why we combined tabs and history and made them accessible through the bottom edge. As a team, we spent months building and refining a sleek, intuitive and fluid user experience.

Here’s a sneak preview of how it will look like:


Video: Browser interactions

Bottom edge gesture will have three stages:

  1. Dragging from the bottom edge will hint and reveal the most recently viewed tab
  2. Continue dragging and the full tab spread is revealed
  3. Keep on dragging and browser history will be fully revealed.

All elements will support gestural interaction: user can swipe to delete a tab or a website from history.

That’s all for now. In the next blog post, we will talk more about gestural interaction in Browser. Stay tuned!

Read more
Alejandra Obregon

Last week a few of us flew to Las Vegas for a Juju sprint at the world-famous Flamingo casino (where Hunter S. Thompson stayed in Fear and Loathing).

It was the first time in Las Vegas for most of us so we weren’t quite sure what to expect…

fear-and-loathing-in-las-vegas

And while there were plenty of distractions within reach at any stage…




…we managed to get through a large amount of work!




The focus of the sprint was to explore ideas and define specs for work we will be delivering in the next six months. Amongst other things we covered topics such as:

  • A new search and browse experience for charms and bundles
  • The best way to prioritise and present information to help users to assess and select charms and bundles. For this we employed a mobile-first methodology. Carla will be writing more about this in an upcoming post
  • How to improve the juju service block
  • Lots of other exciting features we should be able to unveil soon!

So by the end of the sprint we felt a little bit more like this…

If you want to find out more about Juju visit Ubuntu.com

Or have a play with Juju itself! Juju is the quickest way to deploy services to any cloud running Ubuntu.

We are currently hiring designers, UX consultants and engineers to work on Juju. Maybe you could come along to Vegas next time!

Read more