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.Read more
Ubuntu was once described to me by a wise(ish ;) ) man as a train that was leaving whether you’re on it or not. That’s the beauty of a 6 month release cycle. As many of you will already know, each release we include photos and illustrations produced by community members. We ask that you submit your images using free photo sharing site Flickr and that you limit your images this time to 2. The group won’t let you submit more than that but if you change your mind after you’ve submitted, fear not, simply remove one and it’ll let you add another.
As with previous submissions processes we’ve run, and in conjunction with the designers at Canonical we’ve come up with the following tips for creating wallpaper images.
To shortlist from this collection we’ll be going to the contributors whose images were selected last time around to act as our selection judges. In doing this we’ll hold a series of public IRC meetings on Freenode in #1410wallpaper to discuss the selection. In those sessions we’ll get the selection team to try out the images on their own Ubuntu machines to see what they look like on a range of displays and resolutions.
Anyone is welcome to come to these sessions but please keep in mind that an outcome is needed from the time that people are volunteering and there’s usually a lot of images to get through so we’d appreciate it if there isn’t too much additional debate.
Based on the Utopic release schedule, I think our schedule for this cycle should look like this:
As always, ping me if you have any questions, I’ll be lurking in #1410wallpaper on freenode or leave a question in the Flickr group for wider discussion, that’s probably the fastest way to get an answer to a question.
I’ll be posting updates on our schedule here from time to time but the Flickr group will serve as our hub.
Happy snapping and scribbling and on behalf of the community, thanks for contributing to Ubuntu!
Following the success of our new stand design at MWC earlier this
year, we applied the same design principles to the Ubuntu stand at
last month’s Mobile Asia Expo in Shanghai.
With increased floor space, compared to last year, and a new stand
location that was approachable from three key directions, we were
faced with a few new design challenges:
Proposed layout ideas
The final design utilised maximum floor space and incorporated the
positioning of our bespoke demo pods, that proved successful at MWC.
Along with strong branding featuring our folded paper background
with large graphics showcasing app and scope designs and a new aisle
banner. The main stand banners were then positioned in an alternating
arrangement aligned to the left and to the right above the stand.
Aisle bannerRead more
We’re now almost half way through the year and only a few days until summer officially starts here in the UK!
In the last few weeks we’ve worked on:
And we’re currently working on:
If you’d like to join the web team, we are currently looking for a web designer and a front end developer to join the team!
Working on Juju personas and scenarios.
Have you got any questions or suggestions for us? Would you like to hear about any of these projects and tasks in more detail? Let us know your thoughts in the comments.Read more
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:
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
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.
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.
|Operating system||Percentage usage|
|Device||Percentage usage (of 5.41%)|
|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%|
After analysing your numbers, you can also define which combinations to test in (operating system and browser).
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.
We opted for not splashing on an iPad or iPhone, as there are quite a few around the office (retina and non-retina) and the money we saved meant we could buy other less common devices.
Part of our current device suite.
When we started to get a few bug reports from Android Gingerbread and Windows phone users, we decided we needed phones with those operating systems installed. This was our second batch of purchases:
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.
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.
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!
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”
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.
After some device testing to adjust paragraph size for comfortable reading, we settled on having the base font size modified at our grid breakpoints to 14px, 15px and 16px.
By keeping the proportions of the sizes though, it was easy to see that some font sizes and margins were too large in proportion to others at small screens — especially the larger headings like
h1 —, so we tweaked these as needed to improve readability.
A typographic scale can serve as a guide, but you don’t have to stay married to it: adjusting sizes to what feels better is an important step in making sure your text is comfortable to read at various sizes — and the best way to test this is on the actual devices!
Testing ubuntu.com on various devices.
Our typographic scale is defined in pixels, but the sizes are specified in ems in our CSS so they can be scalable.
Differences in the typographic scale from small to large screens.
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!
Even though web fonts are widely supported now, some browsers, like Opera Mini, just don’t support them, so it’s always a good idea to look at your site across various devices and browsers, and turn off the
font-face declarations to see if the fallback fonts that you’ve declared look as good as you can make them and match as closely as possible with the original font. By doing this you’ll make the transition between the fallback font and the web font once it’s finally loaded less obvious and less jarring for the user.
Opera Mini, without the Ubuntu font.
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”
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.Read more
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.
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.
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.
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.
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
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.
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, 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.
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
.opera-mini to the
body of the document. He will be covering this in more detail in a following post in this series.
Opera Mini’s SVG rendering issues.
We have explored the possibility of dynamically changing the colours of our SVG pictograms, but haven’t yet found a solution that is compatible across browsers — we’re open to suggestions!
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.
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.
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)|
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.
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”
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.
Desktop size main navigation and footer on ubuntu.com.
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.
Some 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.
Some of the ideas we sketched during the brainstorming session.
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.
Navigation 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.
First navigation prototype.
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.
Final navigation prototype, after some tweaks.
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”
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.
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.
Our 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.
Our 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.
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.
A 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.
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:
Screenshot 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.
The first two steps we took when creating the initial responsive prototype of ubuntu.com were:
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.
Our 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.
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:
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:
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:
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.
The phone grid.
At the medium screen breakpoint we have:
At the large screen break point we have:
Comparison between small, medium and large screen spacing.
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”
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.
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.
The 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.
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.
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.
Accordions chunk the content nicely at smaller screen sizes.
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”
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.
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.
First version designs.
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.
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.
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:
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.
In terms of the responsive project itself, we defined the priority tasks:
And we also defined what we wouldn’t do at this stage:
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.
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:
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.
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.
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
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…
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:
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
The new DVD designs feature:
- 14.04 wallpaper
- Modified design of the folded paper numerals
- An integrated, 14 module graphic
Trusty Tahr – hidden reveal within the DVD pocket
Design exploration – folded paper numerals
Design exploration – graphic numerals
Alternative Desktop Edition concepts
Alternative Server Edition conceptsRead more
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 sprinting and a wall of sticky notes
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).
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.
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!
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.
A 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.
Initial 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.
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.
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
Every detail matters, and building great software means taking time to remove the papercuts. Ubuntu has over the past 5 years been refined in many ways to feel amazingly comfortable on the cloud. In the very early days of EC2 growth the Ubuntu team recognised how many developers were enjoying fast access to infrastructure on demand, and we set about polishing up Ubuntu to be amazing on the cloud.
This was a big program of work; the Linux experience had many bad assumptions baked in – everything had been designed to be installed once on a server then left largely untouched for as long as possible, but cloud infrastructure was much more dynamic than that.
We encouraged our team to use the cloud as much as possible, which made the work practical and motivated people to get it right themselves. If you want to catch all the little scratchy bits, make it part of your everyday workflow. Today, we have added OpenStack clouds to the mix, as well as the major public clouds. Cloud vendors have taken diverse approaches to IAAS so we find ourselves encouraging developers to use all of them to get a holistic view, and also to address any cloud-specific issues that arise. But the key point is – if it’s great for us, that’s a good start on making it great for everybody.
Then we set about interviewing cloud users and engaging people who were deep into cloud infrastructure to advise on what they needed. We spent a lot of time immersing ourselves in the IAAS experience through the eyes of cloud users – startups and industrial titans, universities and mid-sized, everyday companies. We engaged the largest and fastest-moving cloud users like Netflix, who have said they enjoy Ubuntu as a platform on the cloud. And that in turn drove our prioritisation of paper-cuts and significant new features for cloud users.
We also looked at the places people actually spend time developing. Lots of them are on Ubuntu desktops, but Windows and MacOS are popular too, and it takes some care to make it very easy for folks there to have a great devops experience.
All of this is an industrial version of the user experience design process that also powers our work on desktop, tablet and phone – system interfaces and applications. Devops, sysadmins, developers and their managers are humans too, so human-centric design principles are just as important on the infrastructure as they are on consumer electronics and consumer software. Feeling great at the command line, being productive as an operator and a developer, are vital to our community and our ecosystem. We keep all the potency of Linux with the polish of a refined, designed environment.
Along the way we invented and designed a whole raft of key new pieces of Ubuntu. I’ll write about one of them, cloud-init, next. The net effect of that work makes Ubuntu really useful on every cloud. That’s why the majority of developers using IAAS do so on Ubuntu.Read more
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.
Ubuntu Resources homepage viewed on a Kindle Fire HD
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 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, viewed on a Nexus 7
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.
A 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.
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.
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 in event details
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.
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
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.