Canonical Voices

Posts tagged with 'featured'

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

The new DVD designs feature:

Desktop Edition
- 14.04 wallpaper
- Modified design of the folded paper numerals

Server Edition
- An integrated, 14 module graphic

14.04_DVD_bundle_FINAL

Trusty Tahr – hidden reveal within the DVD pocket

pocket_reveal

Design exploration – folded paper numerals

14.04_folded_numerals

Design exploration – graphic numerals

1404_numerals

Alternative Desktop Edition concepts

14.04_desktop_concepts

Alternative Server Edition concepts

14.04_server_concepts

Read more
Inayaili de León Persson

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

At this point in time, once the pilot projects were either completed or underway, we had already:

We had a better understanding of what was involved in working on this type of project, with different constraints and work flows. With lots of ideas and questions floating in our minds, we decided that the best next step was for designers and front-end developers to spend two or three days right after the release of the new canonical.com website to discuss and capture the findings.

It’s important to take time to take in the pros and cons of certain approaches we try as a team, so that we can try to avoid repeating past mistakes and keep doing more of the things that make projects run smoothly and produce great results.

Developers sprintingDevelopers sprinting and a wall of sticky notes

Things we learned

Make sure you have a solid grid

Our new responsive grid seemed to adapt well from large to small screens (I will be publishing a post on this later in the series, so stay tuned!) and this was mostly because when we initially created the CSS and HTML we opted for using percentage and relative units rather than absolute units (like pixels).

Use Modernizr for feature detection

The introduction of Modernizr to our developer tools proved essential to easily detect features across browsers, such as SVG support, and provide adequate fallbacks and is something we’ll keep using in the future.

SVG icons and pictograms

We started the move from bitmap-based images to SVG for things like pictograms and UI elements. This was easy from a design perspective, as all of our icons and pictograms are already created as SVGs (as well as other formats). There were some hiccups when we tested the PNG fallback solution in some operating systems and browsers, like Opera Mini. But more on this in an upcoming post dedicated to images!

Things we had to work on

Defining visual layout across screen sizes

We were used to creating large, desktop-focused visuals and we had the tools to do so quickly — our style guide. Because the deadlines were looming, we decided we wouldn’t create lots of different mockups for each page in canonical.com and instead create flat mockups for large screen and work alongside the developers on how that would scale and flow in small and medium sized screens.

The wireframes were kept as linear as possible — they were more of a content and hierarchy overview to guide the visual designers — , and the content was produced so that it wasn’t too long for small screens.

Canonical wireframeA wireframe created for canonical.com

The problem with this approach was that, even though we all agreed with the general ways in which the content and visual elements would reflow from small to large screens, by creating comps for the large screen problems invariably arose and reflows that sounded great in our own minds didn’t really work as easily or smoothly as we thought.

It’s important that you define how you’re going to tackle this issue: in this case, canonical.com was designed from scratch, so it was more difficult to visualise how a large design could adapt to a small screen across the team. In the case of ubuntu.com, though, the tight scope means we’re adapting existing designs, so it makes sense to work almost exclusively in the browser and test it at the same time.

Canonical prototypesInitial small screen canonical.com prototypes: ‘needs work’

In the future, when we need to produce mockups we will make sure they are created initially for smaller screens and then for larger screens. When mockups aren’t necessary — for example, if we’re creating pages based on existing patterns — we are already building directly in code, for small screens first, and enhancements are added as the available screen space gets bigger.

Animations

Even though the addition of CSS animations to our repertoire made for more interesting pages, making sure that they are designed to work well and look good across different screen sizes proved harder than expected.

In the future, we’ll need to carefully think about how having (or not having) an animation impacts small screens, how the animation should work from small to large screens, and what the fallback(s) should be, instead of assuming that the developers can simply rescale them.

The process going forward

As a final note, it’s important to mention that in a fast-paced project, where decisions need to be made quickly and several people are involved in the project, you should keep a register of those decisions in a central location, where everyone can access them. This could be anything from a solution for a bug to even the decision of not fixing an issue, along with the reasoning behind it.

Read the next post in this series: “Making ubuntu.com responsive: scoping the work”

Read more
Inayaili de León Persson

Ubuntu Resources — beta 2!

A new version of the Ubuntu Resources site is now live, with many tweaks and layout improvements targeted mainly at visitors using medium-sized screens, such as tablets.

Resources homepage on a Kindle Fire HDUbuntu Resources homepage viewed on a Kindle Fire HD

Filtered search

If you search for a specific term, you can now filter the search results by topic (such as cloud, phone, support, etc.) or type (case study, white paper, event, etc.). Further down the line, we’d like to expand this so people are able to sort the results by date, popularity and more, and filter by date, language and other options.

Search result filtersSearch results filters

Still on the subject of search, some users mentioned that their phones didn’t necessarily show a “Go” button in the keypad when typing inside the search box, so we’ve added a search icon which doubles as a “Go” button inside the input field but doesn’t get in the way if you have no need for it.

Search input field on a Nexus 7Search input field, viewed on a Nexus 7

Layout and font sizes

We’ve added a maximum width to text areas instead of the full width text blocks that were optimised for small screen view, so visitors to the site using tablets and other medium sized screens won’t have to deal with really long text lines. This can be seen in screens such as the homepage and topic landing pages, but most importantly in single article views, where we’ve also moved the content that followed the article text to the right hand side. In future versions of the site, we might review the order in which these right column elements appear and perhaps their content too.

News page on iPadA news page with sidebar viewed on an iPad

Following the typographic scale that we introduced in the new canonical.com website, the font sizes and spacing between elements in medium sized views have also been updated: everything is slightly larger, as there is more screen real estate and elements can have a little more breathing space.

We’ve made some tweaks to the spacing between elements, namely in the homepage and landing pages, like adding more space between articles to make lists clearer to understand.

‘Add to’

We’ve also added links to “Add to Instapaper” and “Add to Pocket” in single article view screens, which we hope will be useful for anyone that wants to save a resource for later.

Colour consistency

A hardly noticeable change, but one that we thought was important in order to keep consistency across different Ubuntu products and platforms was the update of the grey colour we were using in tags, labels and event details. The new grey now matches the new phone greys: we went from #AEA79F to a slightly darker and more readable #888888. If warm grey is used on dark aubergine, the HEX reference is now #B2B2B2.

Darker grey textDarker grey in event details

Even more changes

We’ve also fixed many other bugs and issues like 404 pages, incorrect tagging, elements’ positioning, incorrect title tags, errors in the email sharing default text, and more.

Next steps

In the next few weeks we’ll be focusing on extending our styles to accommodate larger screens nicely and improving the medium screen size layouts based on the feedback we’ll receive from users.

We hope you have a look at the updated site and let us know your thoughts on it. You can use the handy feedback link at the bottom of the site or just comment here!

Read more
Inayaili de León Persson

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

The rules document we drafted proved a useful and good guide for those few development days, and a proof of concept was created and presented to the rest of the team.

When we all sat down to review the result, a few things were clear:

  • Even though lots (and lots) of tweaks and design thinking were needed, our desktop style guide did not look bad at all in small screens — the result was promising
  • The main places where things looked broken were custom hero and background images
  • Some one-off overriding styles applied in some pages did not play well in small screens, as they might have been added in absolute sizes (like pixels) or weren’t flowing as they should
  • Some pages that were long on the desktop quickly became very long at small screen sizes

First responsive prototypeFirst ubuntu.com responsive prototype.

Since this was a ‘quick and dirty’ test of some common-sense responsive rules, a lot had not been done in the code that would eventually have to be done, such as:

  • Refactoring the original Sass files to be mobile-first
  • Cleaning up the existing Sass files as much as possible: as websites grow, the need for custom, one-off exceptions increases, so we needed to set aside some time to rationalise some of these sneaky overrides

However, the exercise showed us that our existing framework was indeed flexible enough to be converted to be responsive, but it also showed us that we still had a lot of work to do!

Read the next post in this series: “Making ubuntu.com responsive: pilot projects”

Reading list

Read more
Inayaili de León Persson

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

Making www.ubuntu.com responsive has been an ongoing goal of ours for a while, and we’ve been discussing and preparing for it for over a year. However, the rest of the world doesn’t wait, and the work doesn’t stop coming in!

We knew that a couple of other projects, namely Ubuntu Resources and the new Canonical site, were going to have to be completed before the main site, and that they would have to follow mobile-first and responsive philosophies, which posed a few questions:

  • How were we going to manage three consecutive projects trying to find solutions for similar problems?
  • Which project was going to influence which? If we did something new on a new project, how was that going to affect ubuntu.com in the future?
  • In the case of canonical.com, the site structure was much simpler than ubuntu.com: how would solutions developed for such a case apply to something more complex?
  • Ubuntu Resources had a start date before the responsive ubuntu.com project, but a completion deadline after it: how would this impact the responsive solutions we were going to try to come up with?

These and other questions seemed to us tricky to solve at the time. However, we had time and resourcing constraints, and deadlines that we just had to work with.

In the end, the work that we did (and are still doing) on the two other sites helped and influenced the work that we’d be doing on ubuntu.com.

Ubuntu Resources

We launched the alpha version of Ubuntu Resources in November last year. This was our first look into creating a mobile-first website. We’ve recently released the beta version, which is still focused on improving the small screen experience. Right now, we are working on the medium screen size layouts of the site, which should be going live very soon.

Even though work on this project started before work on responsive ubuntu.com, we knew the deadline for completion of its final stages (adapted to large screen sizes) was likely to be after the first release of the retrofitted ubuntu.com.

Ubuntu Resources beta homepageUbuntu Resources homepage.

These are some of the lessons we’ve learnt whilst working on this project:

  • To save space at the top of the screen and allow for more content to be visible, the global navigation (which links to other sites within the Ubuntu universe) could be relegated to the bottom of the screen, in small screens. To keep its visibility, we added a link from the site’s main navigation
  • Simply decreasing the typographic scale that we were using in our style guide wasn’t enough for small screens. We had to slightly reduce the largest sizes and increase the smallest ones to improve readability
  • Space is at a premium in small screens, so we massively reduced row and box padding and margins between elements
  • We’ve reused the grid from the Ubuntu phone, which divides the portrait phone screen in 40 square grid units (horizontally) and where spaces between elements are usually counted as one or more grid units. Since the objective was to have a more condensed version of margins and padding across the small screen version of the site, using this grid allowed for more flexibility, with much smaller spaces between elements, without having to create a new grid — reuse and recycle!
  • It was important to keep the strong Ubuntu brand at the top of the screen, even on small screens, and to keep the navigation as straightforward to use as possible. This meant keeping the Ubuntu orange navigation background and a clear Ubuntu logo (when at first we tried a simplified version of the logo without the Ubuntu wordmark, user feedback revealed landing on the site was confusing, as they didn’t recognise the simplified logo or why the word “resources” was in the navigation)

Phone gridThe phone grid.

Ubuntu Resources navigation before
Ubuntu Resources navigation afterBefore (top) and after (bottom) Ubuntu Resources navigation: with and without the full Ubuntu logo.

Canonical.com

Early this year we launched the new and improved canonical.com, which is mobile-first and responsive.

While we were working on canonical.com, work on Ubuntu Resources was paused, which meant we could borrow some of the learnings from Resources but we’d need to find solutions to other problems we hadn’t yet addressed, such as scaling from small to medium and large screen sizes and defining those breakpoints.

From this project, we took away:

  • The medium screen size font sizes, again slightly adjusted for readability
  • Improved spacing between elements and padding on medium sized screens, which can be larger than in smaller screens, but slightly tighter than large screens
  • The use of the new folded paper background, developed for the phone designs
  • The use of flat colour blocks (mainly white and dark aubergine) to divide content, as opposed to divider lines
  • The use of SVG images for interface elements and icons, and a PNG fallback for non-supporting browsers
  • Patterns for reflowing images next to text in small screens: in most instances, when the image is to the left of the text, it can be moved above it in smaller screens; if the image is to the right of the text, it can be moved below it in smaller screens
  • An accordion pattern for small screens and tabs for larger screens

Margins in small, medium and large screensFrom left to right: comparison between margins and padding in small, medium and large screens.

Folded paper backgroundThe new folded paper background.

Small and large tabsTabs in small screens (left) and large screens (right).

Once canonical.com was launched, it was time to get back onto making ubuntu.com responsive. We felt that testing out ideas and strategies in smaller responsive projects before going full speed on our largest site was a positive experience, and would advise teams in similar scenarios to try and follow a similar strategy if the prospect of starting with your most popular site seems daunting or is simply impractical.

Read the next post in this series: “Making ubuntu.com responsive: lessons learned”

Reading list

Read more
Inayaili de León Persson

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

The front end framework that powers www.ubuntu.com represents the visual evolution of the site over the past few years: designs have become cleaner, lighter and more open. It was designed without responsiveness in mind, but it has proven flexible, robust and great for our needs: user experience designers can quickly create wireframes for new and updated pages based on existing patterns and developers can create new pages that look good with little input from designers.

Web style guideWeb style guide front page.

Even though the framework uses a fixed-width container to wrap the content, the containers within it were built to percentages, which means that if that surrounding container were to be removed, the site would become fluid.

Ubuntu.com with no wrapperOne page of the current site without a wrapping container.

We didn’t want to lose the work that has been put into this style guide. After a long discussion, we agreed that even though we were going to convert the CSS powering the site into mobile-first — so the media queries would be added for larger screen sizes instead of the other way around —, we were going to keep the desktop version as it was initially defined in the style guide.

This is likely a restriction that many other teams share: where there is a will and need to make an existing site responsive, but no budget and/or resources to start from scratch.

We decided that it would be a good idea if our developers, Anthony, Graham, and Karl, could sit in a room for a few days and create a ‘quick and dirty’ prototype of what our current site, using the current styles, would look like in a responsive world.

The main goals of this exercise were:

  1. To see how disastrous, or indeed how well, the style guide would play when a handful of responsive guidelines were applied
  2. To give the developers a better understanding of the effort required and issues involved in converting the existing stylesheets into a mobile-first, responsive format

We created a Google doc, structured in the same way as our style guide, where we laid out some rules that would get the developers started on the prototype.

The document started with the more broad and general rules:

  • Try to create breakpoints that fit our content, instead of just random device-specific sizes
  • Try to keep breakpoints to a minimum, with fluid designs in between each breakpoint

We then laid out some scaffolding (layout and grid) rules:

  • Content that is divided in half or thirds should convert into single column when it becomes too narrow
  • If the content is divided into quarters, there might be a step in the middle (halfs)
  • In rows that include an image to the left or right of the text, the image should move above or below the text, respectively
  • Hero images might need to be looked at individually rather than a single rule for all
  • Experiment reducing padding inside rows and boxes incrementally as the screen size decreases
  • Remove column dividers at smaller screen sizes

We then moved on to forms rules:

  • Our forms are already quite vertical, at this stage, make sure we are using correct HTML5 input types

And tables rules:

And finally JavaScript rules:

  • No forcing of equal-height boxes
  • Make tabbed content into expanding/collapsing accordion widgets

Many of our styles didn’t need changing at this stage and this was all written down in the doc too.

We also knew that, at this point, we couldn’t look into trickier problems such as the navigation, the typographic scale or how our multiple footers would play in a small screen, so we decided to leave this for later.

Multiple navigation levels in ubuntu.com
Multiple footers on ubuntu.com

Navigation and multiple footers were too complex an issue to be solved at this early stage.

Now it was time for the developers, with this doc in hand, to take a first go at making www.ubuntu.com responsive!

Read the next post in this series: “Making ubuntu.com responsive: making the rules a reality”

Reading list

Read more
Inayaili de León Persson

Making ubuntu.com responsive: intro (1)

We’ve known for a while it was time to convert our main site, www.ubuntu.com, into a responsive site, and we’re now nearing the end of the project!

The main www.ubuntu.com site receives millions of visitors every month and it holds information on the variety of Ubuntu products and services, allowing people to download Ubuntu, get in touch with Canonical or find support.

In an ideal scenario, if you were going to convert a non-responsive site into a responsive one, you would start from scratch and do everything right and perfectly from the beginning. But what would be the fun in that?

In reality, starting from scratch on a site the size of ubuntu.com is just not practical or easily achievable. We evolve, grow and iterate the site constantly for releases, upgrades, launches and design updates. It is a living, breathing site, and we can’t really afford to stop, and start again. We realise other teams will also be faced with this reality, so we want to share the journey we have taken and some lessons we learned along the way.

In this series of posts, we’ll document the process we’re following in making that transition. We hope to give others an insight into what’s going on behind the scenes, the obstacles we’re facing, the solutions we’ve tried, the questions we have, and basically the nitty gritty of a real world responsive retrofitting project.

We will be covering:

  1. Intro (this post!)
  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 readability
  12. Ensuring performance
  13. JavaScript considerations
  14. Testing on multiple devices

I’ll update the list above with links to new posts as we go along. We’d love to hear your thoughts, questions and solutions you’ve tried in your own projects, and how we can make this series more useful: leave your comments below, and we hope you enjoy the posts!

Read more
Tom Macfarlane

Last month at Mobile World Congress Ubuntu’s presence was stronger than ever. Our third year at MWC and we made some significant design changes to our stand.

In such a large exhibition space, strong branding is key. We designed five large banners – made from fabric and stretched across metal frames – that were suspended above the stand. Each banner was then individually illuminated by a series of spotlights creating maximum impact and high level brand presence, while still maintaining the stands open and welcoming feel.

MWC_blog_1

The back walls and a new hanging aisle banner all featured the folded paper background with large graphics showcasing app and scope designs from the phone and tablet. We also dedicated one wall to the Ubuntu Carrier Advisory Group (CAG).

MWC_blog_visual

Continuing our clean and precise design approach we used the Ubuntu shape (the squircle) to create bespoke pods, reception desk and demo unit – with warm white LED down lighting around the top and base and lightboxes to illuminate the Circle of Friends on the reception desk.

CAN MWC Reception Desk RevA.vwx

Integrating elements from our phone and tablet design across print and 3D environments builds a strong brand/design coherence in everything we do. We’re very happy with the new stand design and feedback from MWC has been very positive.

http://news.softpedia.com/news/Ubuntu-s-Booth-at-MWC-2014-Looks-Spectacular-428834.shtml

MWC_blog_2

Read more
Michal Izydorczyk

Ubuntu 14.04 LTS wallpaper

Hey

For the last couple of weeks we’ve been working on the new Ubuntu Wallpaper. It is never easy trust me. The most difficult part was to work out the connection between the old wallpapers and the new look and feel – Suru. The wallpaper has become an integral part of the ubuntu brand, the strong colours and gradated flow are powerful important elements. We realised this when looking from a distance at someone laptop it really does shout UBUNTU.

We spent some time looking at our brand guidelines as well as previous wallpaper thinking how to connect the old with the new and how to make the transition smooth. I did start with simple shapes and treated them as a separate sheets of paper. After a while we moved away from that idea simply because Suru is about simplicity and minimalism.
When we got the composition right we started to play with colours, we tried all our Ubuntu complimentary colours but we were not entirely happy. Don’t get me wrong ;) they did look nice but it didn’t feel like a next step from our last wallpaper…

wallpaper_blog_post

And here some examples of the things I was exploring…

wallpaper_blog_post

Read more
Daniel Oliver

Loving the bottom edge

The bottom edge is the most pleasurable edge to use. Grab a phone, any phone, and slide your thumb up over the bottom edge, then back. Go on, do it a few times. Feel good? Yeah, our extensive research suggests this feels pretty amazing to pretty much everyone.

Hmmm…. Feels good!

That’s why we’ve given the bottom edge to you, the developer, for your app. It’s the best one and we thought you could make the best use of it. If you want to create a truly “Ubuntu!” experience for your app you’ll want to invest in thoughtful but also creative interpretations of this edge in your app.

In fact, getting THIS ONE THING perfect is the most important thing you do when you bring your app to Ubuntu. Pretty much everything else is just… you know, obvious. But creating a bottom edge experience that is exactly perfect for your app and consistent with our values is where the magic happens.

Be perfect, be yourself, be exciting

There is no one answer for “the bottom edge”. There are definitely some values we can apply to judge if it’s a GREAT bottom edge, and there are several patterns that you’ll see, but you should start with a blank canvas and set yourself the goal of making your bottom edge experience YOURS.

Just to get the creative juices flowing, here are three great examples:

Think phases. Go beyond “one thing” in the gesture

The bottom edge swipe very naturally lends itself to what we call a “ranged gesture”. This is a gesture where going further does more. In other words, a great bottom edge will often be more than a simple transition. For example, you are unlikely to be great if you just reveal a toolbar, or pause a movie. You’ve got the opportunity to take several (well, two, at most three) logical “steps” on the way from the bottom edge up to the full stretch of the thumb.

Progression

 

 

When we design ranged gestures, though, we have to do a couple of things right to make them feel slick.

1. Make them connect smoothly

If your bottom edge gesture is going to have two phases, make sure that you pick two things which are related, so that the second one feels like a natural extension of the first.

A good example is the way we use the left edge: a little bit of left edge shows your *favourite* apps, a lot shows you ALL the apps. Seeing “all the apps” is a natural place to go if seeing your favourite apps wasn’t enough… it’s “more apps”. That makes a really good ranged gesture.

If the second phase was totaly unrelated to the first, it would feel jarring. Don’t do that!

Some examples of great ranged gestures:

  1. In a movie player, start with the player controls, then go further to reveal the chapter selection, and maybe even further to pop out of the movie to show other movies available on the device.

  2. In a map, use the bottom edge to zoom out. This is very sexy because the further you go the further you zoom, and zooming back is very naturally a tap where you want to zoom in.

  3. In a calendar, use the bottom edge to go from day to week to month to year view, like zooming out in time.

  4. In a turn-based game, use the bottom edge to pause the game and present game options.

  5. Go radial – present a radial menu of 5 top actions. Make it fade in beautifully so people want to use the bottom edge just to see those things show up. Make it fast so you just have to slide to one of them and release to invoke the action. Slick. Fast. Yum.

2. Be reversible. Let people change their mind easily.

Your user might not have intended to invoke the bottom edge, so it should always be possible for them to change their mind before they let go and slide back down, at which point their app is unchanged, they haven’t switched mode or done anything that they have to undo. Sliding back down is like saying “Oops, not down this corridor!” and you should respect that perfectly.

So, don’t pause or commit to any change until the finger is lifted off the screen – make sure that someone can unwind the use of the edge just by changing direction.

Actually… I don’t need to create a new note

3. Make it visually sexy

This is a FANTASTIC opportunity to show off some really beautiful visual design and motion graphics skills. A really beautiful set of transitions or effects will make people say “ooooh!”. If you get this really right, you’ll see people showing their friends that experience. “Check this out!”. “Ooooooh”. “Do it again!”. “Aaaaah.”, “Can I try?”…. that’s what you want to get when you show it to friends and family before you reveal it to the world.

Trust us, there are a million options for you, but to make it really work well will take a lot of thought and testing…. but it’s definitely worth it! Remember the “desktop cube” and how much fun it was to show people that? Now imagine getting the same reaction to your bottom edge… that’s what you’re shooting for.

The very best bottom edge experience will have movement associated with every tiny move of your finger. It will feel “on rails”, as you move your finger up it feels like you are totally in control of the scene that is unfolding, all the way up to the point where the final phase of your experience “clicks” into place, the final commit.

4. Hint, reveal, commit

We have a pattern we call “hint, reveal, commit”. For any substantial change that a gesture might drive, we want first to hint that it will happen, then we want a stretch of the gesture which reveals the first part of the change without actually making it happen, and finally we want a “click” which is the commit.

hint reveal commit A good example is the launcher. First, we show a shadow. If you just tap at the edge, all you see is that shadow, briefly. That’s the hint. There is “something on the edge”. If you slide a little bit from the edge, you start to see the launcher and the app dims slightly. That’s the reveal, it tells you what’s coming, but still lets you change your mind. And finally, before the launcher is fully revealed, there is a point at which it “clicks” into place. That’s the commit. Letting go of the screen after the commit, you KNOW you will have the launcher.

left edgeHint. Reveal. Commit.

Now, here’s the fun part. With a ranged gesture, you want to think about hint, reveal, commit for EACH PHASE of the gesture. It’s OK for the commit of one phase to immediately give you a hint of the next – you are, after all, in mid-gesture. In fact, that’s what we usually do ourselves, we show the second phase hint at the same time as the first phase commit.

The reveal is usually the place where  you want to make it feel like the user is in total control: have something that tracks the movement of the finger up the screen; it could be fading something in, or moving something in response to that movement. The important thing is that every tiny movement of the finger should reveal more, or less, until the commit.

Prioritise. Really, PRIORITISE

You have one bottom edge. Only one. It’s the sexiest thing for a user to do. They can even do it without looking where they are pressing – it’s an instinctive thing, pure muscle memory.

So you should think carefully about what’s REALLY IMPORTANT and CENTRAL in your app. Maybe there is something that the user will do all the time and you want to make it easy for them to do it fast, no hunting and pecking for buttons. Maybe there’s a natural “zoom out” expression in your app (those are usually good if you can make them beautifully visual). There is only one first phase to your bottom edge, it’s the first thing people will try – make it great, choose wisely!

quick draw

Provide a visual cue

Having a magical bottom edge that nobody discovers is no fun at all!

We can’t guarantee that every app will use the bottom edge. Some apps will be so straightforward that a bottom edge experience would be superfluous – just for show. And we don’t want that.

So users can’t be CERTAIN there is a bottom edge worth trying. That’s risky, because if they try  it a few times and get no result, they’ll stop trying it for apps which DO have a great bottom edge. So, you want to provide some sort of cue that it’s worth their while to give it a go.

Sometimes you can provide that cue as part of a transition into the app. You could show the stuff that’s in there, and animate it away into the edge after a few seconds during the app launch, so people know its there. That might be enough.

You might also want to leave a visual cue on the screen all the time. If you do, though, keep it REALLY small. Just a hint, just a clue, just a taste. For example, you might have a teeny little tab with a (+) on it if that edge holds the magic for adding something. Or you might have a teeny tab with the word “London” on it, if the bottom edge will reveal more cities, starting with London. Or just a highlighted line might do the trick.

visual hint

Be creative on the cue. Make it fit with the story you are telling. There are a million possibilities and only one is best for your particular design. Have fun, but don’t forget the cue!

Common patterns

Yes, if you’re stuck for inspiration, there are a few common patterns you might want to consider. We put this LAST because we really think you want to be inspired by the essence of YOUR APP, not just following a pattern that works elsewhere, in case you miss a chance to invent something really great for yourself and for others.

Zooming out

Many apps have the idea of an “outer” layer, or levels. Maps are an obvious case, calendars also have the idea of a “wider view” (days, weeks, months, years). But the concept of “taking a step back from the coal face” is very common. For example, in a word processor, you might step back to switch between files. In a browser, you might step back to switch between tabs. In a game, you might step back to change settings or invite a friend to play. In Evernote, stepping back from the current note might show you other notes in the same album, or other albums altogether.

By scaling down the content (objects, time, space) we offer a quicker way to navigate across large amounts of content. Step back, go HERE is a great way to get around.

zoom out

Toggle

If your app has two, and only two, main faces, then the bottom edge is a fast, controlled way to switch between them. You can do a nice cross-fade, or a page-over effect that makes the user feel in control.

2 faces

Controls

If your app has a set of controls – for example, a music player – then the bottom edge might be a great way to bring those smoothly onto the screen.

A great idea is to think carefully about the various controls, and have a ranged gesture which reveals steadily more. For example, first just play, pause, back and forward, then things like chapter selection which provide a broader view of the content.

Quick draw

Your app may have a particular thing that you want people to be able to do instantly, with nothing but a reflex reaction. For example, a note-taking app might use the bottom edge as a quick-draw “new note” facility.

quick draw

Make it great!

This is bottom edge is something unique to Ubuntu – we’ve given it to you because it really is the prime edge from a user perspective, and the app has all the user’s attention. It’s worth taking time to think carefully, try a range of options, test them on your friends, and craft it beautifully.

 

 

 

 

 

Read more
Inayaili de León Persson

Ubuntu Resources — beta!

Today we’ve released a new version of Ubuntu Resources with some new functionality and design improvements, and we’ve now moved from alpha to beta!

Feedback

We asked visitors to the site to give us their feedback based on their visits on their mobile devices, and we received lots of useful comments since we launched the alpha version of the site in November.

Several of the comments focused on the same themes, which became our areas of focus for this release, such as:

1. Understanding which site you are visiting

Because of the way we were using the Circle of Friends roundel without the “ubuntu” wordmark next to the word “resources”, many people didn’t understand that was the name of the site. In this iteration, we went back to using the standard brand extension, reducing the overall size of the logo and making that more clearly the title of the site and homepage link.

Navigation before and afterNavigation before (left) and after (right).

New landing pages

2. Understanding the variety of content that the site has to offer

Some people thought they had landed on the “Ubuntu Blog”, because of the way the homepage and other topic pages were laid out.

We’ve designed landing pages that are more curated and show the most recent and featured content with the option to see all archived content related to that topic near the bottom of the screen.

3. Learn more about the topics presented (cloud, server, etc.)

A common mistake when designing for brands you’re familiar with is to think other people will have the same understanding of it as you do.

Some people that we showed the site to and that were not too familiar with Ubuntu or Canonical did not understand exactly what we meant by “Server” or “Ubuntu on phones”, for example. Links to learn more about these topics used to be at the bottom of screens, so we moved that content to the top of the topic landing pages for easier access if you’re new to the subject.

Topic introsNew introductions to the topics.

Learnings from Canonical.com

With the launch of the new Canonical website in January, we changed the way some of our small screen patterns work:

  • We’ve updated the font sizes, so they are now slightly larger
  • We’ve updated the background of the pages
  • We’ve change the way content is divided, reducing the number of lines and using different blocks of colour instead

These were fed back into Ubuntu Resources so that we can keep our patterns as consistent as possible across sites.

In terms of the less visible updates, we’ve also:

  • Improved the pre-populated messages when content is shared
  • Tweaked the style of the tags which can be used to navigate the site
  • Fixed some bugs in the rendering of SVG icons

Next steps

In the next iteration of the site, we will be focusing mainly on layout improvements for medium sized screens (think tablets), as at the moment the site is still only displaying the small screen style sheet regardless of screen size.

We’ve already started to improve the search functionality, so that it’s possible to filter search results, but visitors should only be seeing these changes in the next release, in a few weeks.

Once we’ve built the site to scale up to large screen sizes smoothly, and have integrated all the top-priority functionality, the plan is for it to replace the current Insights website.

If you haven’t checked it out yet, head to Ubuntu Resources and feel free to send us your comments via the feedback link in the site’s footer.

Read more
Vesa Rautiainen

In January when the winter weather was at its worst in London we packed our laptops, designs and prototypes and headed to Cape Town, South Africa for Client Platform Sprint. This design sprint was a mid cycle checkpoint and the target was to get some important 14.04 designs, including Dash and Right edge swipe, reviewed and finalized.

It was an intense week with lots of review sessions and a tight schedule. But after the day’s work was done we tried to make most of our time in this astonishing place. The trip wouldn’t have been complete without visiting those vineyards, white-sand beaches and of course THE Table Mountain.

All in all it was a great work week in the sun with some bits of free time activities. Easily beats a regular week at the office. Some pictures from the trip:

Right Edge designRight Edge design

Trying to nail the DashTrying to nail the Dash

Camps Bay

Camps Bay

Table Mountain

Table MountainCape Town

Read more
Bejan Alizadeh

Sheets transition

We’ve recently been exploring how the share transitions should work when you’re previewing a photo in gallery mode. Our main goal is that there is a consistent transition for sharing photos across the phone.

This is the latest iteration of the explorations we’ve been doing, and, as such, these transitions are still work in progress, but certainly worth sharing.

Step by step


Video: Sharing a photo in photo gallery mode

The first transition happens when you select “Share” from the toolbar. This takes you to a ‘content picker’ mode where you can select where you’d like to share your photo (Facebook, Twitter, etc.).

The intention is that the ‘content picker’ transition is similar to the ‘page stack’ one — which takes you deeper into the app — but because you’re going into a ‘content picker’ mode the transition needs to be slightly different. That difference is the direction: instead of going from right to left it goes bottom to top.

Once you’ve selected how to share your photo, the screen splits slightly below where you’ve tapped (in the example, below Facebook), and there is a subtle transparency fade so that the transition is less jarring.

In the next step, the transition takes you to an embedded Facebook share page, where you can write a description about the photo you’re posting. Once you select the description box, the OSK keyboard comes from the bottom to top, something that is always consistent across the phone.

When you click “Post”, a similar transition to the selecting share transition, but reversed, takes you back to the photo.

Your feedback

As I’ve mentioned before, this is still work in progress, but we’re really interested in hearing your thoughts — let us know what you think in the comments.

Read more
Inayaili de León Persson

New year, new website: the new canonical.com

We’ve been talking about it for a while and we are now happy to reveal Canonical’s brand new website.

The brief

We thought that it was more than appropriate that, in the year that Canonical commemorates its 10th anniversary, our website got some love, so that’s exactly what we set out to do.

Canonical on devicesThe homepage of the new canonical.com on various devices

The main goal of this redesign was to create a website that clearly communicates what Canonical is and does. To present our services, describe our role in the creation of Ubuntu and to give users an understanding of the principles behind Canonical as a company.

The journey

We set out to distill the Canonical site into its most essential components. This required a huge amount of editing as the site had grown over time. This was not a straightforward task, but there were a few things that we knew would get us very close to that goal:

  • Clearly define canonical.com’s audiences and make sure the new site’s content was created with them in mind
  • Move the content that dates easily (events, news, etc.) from the site to a searchable repository
  • Move all detailed product and service information to www.ubuntu.com to make it more easy to find

We started preparing to move a lot of the content that previously lived on the site a few months ago when we started the Ubuntu Resources project — a place for content such as news, events, press releases, white papers and case studies.

Ubuntu Resources (currently in ‘alpha’) is also our first responsive site, and a lot of the lessons we have been learning from it, code- and design-wise, have been applied to the new canonical.com, like the small screen site navigation and the global Ubuntu sites navigation.

Carla has published a very interesting post on how she used stakeholder interviews to define the website’s key journeys and audiences. This research was instrumental in keeping the content of the site focused and the information architecture as simple as possible.

Before moving onto a digital format, we did a lot of collaborative sketching, churning out ideas on how we could illustrate each page’s message.

Sketching ideasGenerating ideas: some of our sketches

Even though we were working towards a fairly tight deadline, we went through several content, design and code iterations, with copywriters, designers and developers working closely together and improving as much as possible until we were happy with the results.

Canonical status boardOur ever-changing analog status board — sometimes only sticky notes will do!

The visual design borrowed most of the underlying patterns from www.ubuntu.com, such as the grid and font sizes. Ubuntu’s website has been evolving into a more ‘open’ design and the new Canonical website takes that idea even further by removing the main content container and increasing spacing between elements.

We also brought in new patterns, influenced by the design work that is being done on the phone and tablet, like the grid used in small screens, the Ubuntu shape (the squircle) and the folded paper background.

Phone patterns on canonical.comUsing the squircle and the folded paper background on the new canonical.com

The result

We’re very happy with the result, and we think it achieves the goals we set out to accomplish. Now that the site is launched though, it’s up to everyone who visits it to let us know how we did: do let us know your thoughts in the comments!

Read more
Bejan Alizadeh

Messaging interaction

We’ve currently been working on user interaction for sending and deleting multiple SMSs and we thought it would be nice to show you where we’re going with it.

Here are some of things that we’ve had to consider when making these interactions user friendly:

  • making sure the transitions fit within our paper metaphor — for example, when you select a message thread we wanted it to feel like it’s taking you deeper into the app
  • just like with the visual assets, transitions also need to be consistent — for example, whenever you’re diving deeper into any app the transition should be similar
  • making room for scrolling and seeing more messages without the keypad taking too much space
  • making sure it’s clear when a message is pending
  • initial exploration into how to navigate back within an app


Video: Sending messages


Video: Deleting messages

As with many of the current interactions, these are work in progress — we’ll be keeping you updated with any further developments.

Read more