Canonical Voices

Posts tagged with 'featured'

Grazina Borosko

April marks the release of Xerus 16.4 and with it we bring a new design of our iconic wallpaper. This post will take you through our design process and how we have integrated our Suru visual language.

Evolution

The foundation of our recent designs are based on our Suru visual language, which encompasses our core brand values, bringing consistency across the Ubuntu brand.

Our Suru language is influenced by the minimalist nature of Japanese culture. We have taken elements of their Zen culture that give us a precise yet simplistic rhythm and used it in our designs. Working with paper metaphors we have drawn inspiration from the art of origami that provides us with a solid and tangible foundation to work from. Paper is also transferable, meaning it can be used in all areas of our brand in two and three dimensional forms.

Design process

We started by looking at previously released wallpapers across Ubuntu to see how each has evolved from each other. After seeing the previous designs we started to apply our new Suru patterns, which inspired us to move in a new direction.

Ubuntu 14.10 ‘Utopic Unicorn’’

wallpaper_unicorn

Ubuntu 15.04 ‘Vivid Vervet’

suru-desktop-wallpaper-ubuntu-vivid (1)

Ubuntu 15.10 ‘Wily Werewolf’

ubuntu-1510-wily-werewolf-wallpaper

Step-by-step process

Step 1. Origami animal

Since every new Ubuntu release is named after animal, the Design Team wanted to bring this idea closer to the wallpaper and the Suru language. The folds are part of the origami animal and become the base of which we start our design process.

Origarmi

Step.2 Searching for the shape

We started to look at different patterns by using various techniques with origami paper. We zoomed into particular folds of the paper, experimented with different light sources, photography, and used various effects to enhance the design.

The idea was to bring actual origami to the wallpaper as much as possible. We had to think about composition that would work across all screen sizes, especially desktop. As the wallpaper is a prominent feature in a desktop environment, we wanted to make sure that it was user friendly, allowing users to find documents and folders located on the computer screen easily. The main priority was to not let the design get in the way of everyday usage, but enhance it aesthetically and provide a great user experience.

After all the experiments with fold patterns and light sources, we started to look at colour. We wanted to integrate both the Ubuntu orange and Canonical aubergine to balance the brightness and played with gradient levels.

We balanced the contrast of the wallpaper color palette by using a long and subtle gradient that kept the bright and feel look. This made the wallpaper became brighter and more colorful.

Step.3 Final product

The result was successful. The new concept and usage of Suru language helped to create a brighter wallpaper that fitted into our overall visual aesthetic. We created a three-dimensional look and feel that gives the feeling of actual origami appearance. The wallpaper is still recognizable as Ubuntu, but at the same time looks fresh and different.

Ubuntu 16.04 Xenial Xerus

Xerus - purple

Ubuntu 16.04 Xenial Xerus ( light version)

Xerus - Grey

What is next?

The Design Team is now looking at ways to bring the Suru language into animation and fold usage. The idea is to bring an overall seamless and consistent experience to the user, whilst reflecting our tone of voice and visual identity.

Read more
Inayaili de León Persson

Redesigning ubuntu.com’s navigation

Last month, the web team had an offsite (outside of the office) week sprint in Holborn, central London. We don’t all work on exactly the same projects in our day-to-day, so it’s nice to have this type of sprint, where everyone can work together and show each other what we’ve been working on over the last few months.

 

Web team in HolbornThe web team in our offsite in Holborn

 

One of the key items in the agenda for the week was to brainstorm possible solutions for the key areas we want to improve in our navigation.

The last time we did a major redesign of ubuntu.com’s navigation was back in 2013 — time flies! So we thought now would be a good time to explore ways to improve how users navigate Ubuntu’s main website and how they discover other sites in the Ubuntu ecosystem.

Collaborative sketching

On the second day of the sprint, Francesca walked us through the current version of the navigation and explained the four key issues we want to solve. For each of the issues, she also showed how other sites solve similar problems.

While the 2013 navigation redesign solved some of the problems we were facing at the time (poor exposure of our breadth of products was a big issue, for instance) other issues have emerged since then that we’ve been meaning to address for a while.

After Francesca’s intro, we broke into four groups, and each group sketched a solution for each of the issues, which was then presented to everyone so we could discuss.

 

Karl presenting sketches to rest of the teamDiscussing the team’s sketches

 

By having everyone in the team, from UX and visual designers, to developers and project managers, contribute ideas and sketch together, we were able to generate lots of ideas in a very short amount of time. We could move the project forward much more quickly than if one UX or one designer had to come up with ideas by themselves over days or weeks.

Improving the global navigation

 

ubuntu.com global navigation barubuntu.com’s global navigation bar

 

The main things to improve on the global navigation were:

  • Some users don’t see the light grey bar above the main orange navigation
  • Some users think the links in the global nav are part of the ubuntu.com site
  • Important sites sit under the “More” link and do not have enough visibility
  • On the new full width sections, the global nav, main nav and “breadcrumb” form a visual sandwich effect that could create confusion

It was interesting to see the different groups come up similar ideas on how to improve the usability of the global navigation. Some of the suggestions were more simple and others more involved.

The main suggestions for improvement that we discussed were:

  • Rename the “More” link as “More sites” to make it more clear
  • Increase the number of links shown by default by using the full width of the page
  • Explore using different colours for the background, such as a dark grey
  • Explore having a drawer that exposes all Ubuntu sites, instead of the links being on display all the time (like the Bloomberg website)

 

Bloomber's global navigation closed

 

Bloomber's global navigation openOn Bloomberg.com when you click the “Bloomberg the Company & Its Products” link at the top (above) you open a large drawer that exposes the Bloomberg universe of sites.

 

Improving the main navigation

 

ubuntu.com's main navubuntu.com’s main navigation with a dropdown that lists second level links

 

The main ubuntu.com nav is possibly the most crucial part of the navigation that we would like to improve. The key improvements we’d like to work on are:

  • Having the ability to highlight key sections or featured content
  • Rely less on the site’s IA to structure the navigation as it makes it hard to cross-link between different sections (some pages are relevant to more than one section)
  • Improve the visibility of content that lives in the third level (it is currently only accessible via the breadcrumb-style navigation)

Even though the proposed solutions were different from each other, there were some patterns that popped up more than once amongst the different groups:

  • Featured content within the navigation (eg. the original Boston Globe responsive redesign, and Amazon.co.uk)
  • Links that live in more than one place (eg. John Lewis, Marks & Spencer and other retailers)
  • The idea of using the mega menu pattern

 

Boston Globel's original responsive menuIn the first version of the Boston Globe’s redesigned website, the main navigation included simple featured content for each of the sections

 

John Lewis mega menu Home & Garden section

John Lewis mega menu Baby & Child sectionOn the John Lewis website, you can get to nursery furniture from “Home & Garden > Room” and “Baby & Child > Baby & Nursery”

 

Amazon.co.uk displays seasonal ads in their mega menuThe main navigation on Amazon.co.uk includes featured ads

 

Solving the third level links issues

 

ubuntu.com's third level breadcrumb-style navubuntu.com’s breadcrumb-style navigation showing third level links

 

The main issues with the current third level links are:

  • We are using a recognisable design pattern (the breadcrumb) in a not so typical way (as second and third level navigation)
  • When you click on a third level link, you lose the visibility of the second level links, making it harder to understand where you are in the site
  • The pattern isn’t flexible: some of our labels are long, and only a small number of links fit horizontally, even on a large screen

One thing that we are almost certain of is that we will not be able to remove third level links completely from our site, so we need to improve the way we show them.

The most interesting suggestions on how to handle this issue were:

  • Include a table of contents for the section at the top of pages (like GOV.uk)
  • Key third level links could be highlighted in the main navigation menu

 

GOV.uk third level navOn GOV.uk, sections which have sub-sections include an overview of all the sub-sections at the top of every page. This makes it easier to understand the type and breadth of content of that section

 

Improving the footer

 

ubuntu.com's footerubuntu.com’s “fat footer” with three levels of links

 

Ubuntu.com’s footer is certainly the simplest of the problems we want to solve in terms of navigation. But, nonetheless, there are some issues with the current solution:

  • There are too many levels of links in the footer
  • The download section is hidden in the second footer level, despite being one of the main top level links

The most popular idea that came out of the sketching session was to use the space available better, so that sections can be listed in a masonry type grid, rather than one per column like they currently are.

This means we’d need fewer columns to list all important content and expose the IA of the site. It also means we can ditch the middle level of the current footer design (which now holds the About, Support and Download sections).

Next steps

The next step in the navigation redesign project is to build prototypes to test some of the ideas we had in our workshop, and refine the visual direction. We want to see if the assumptions we’ve made are true, and if the patterns are easy and intuitive to use across different screen sizes and devices.

We will then do some user testing and iterate based on the feedback we get.

We might also have to do some IA work alongside the redesign of the main navigation, if we do want to have links that are listed in different sections and if we want to present more curated links based on user tasks in each of the sections.

Stay tuned!

Read more
Jouni Helminen

Visual design of convergent apps

It is an exciting time as we’re starting to see more and more of the new, convergence-enabled UI toolkit and features for Unity 8 come to life. Some classic X11 apps (Gimp, Libre Office and a few others) are already running on Unity 8 using new hardware from our partners, including the award winning M10 tablet from BQ – very cool.

At the same time, we want to help people write or port more applications to our platform, using our modern UI toolkit designed to smoothly flow the user experience through touch and pointer inputs, a range of screen and keyboard types and all of the permutations in between! It has been an interesting design challenge to imagine, design, and begin to build a world where all interfaces, regardless of input type or form factor, all emerge from the same core user experience and design language.

Where we are now

Our UX and SDK teams have been working on version 1.3 of Qt based UI toolkit, which allows developers to write applications that can be used comfortably with both touch and pointer interfaces. The work is still very much in progress, but some of it can be used today. You can check out the developer docs here.

Suru, our visual design language, has evolved into a new, much lighter, flatter and modern approach. It not only looks great (in our humble opinion), but helps app developers design good looking and well-functioning apps with less effort. Continuous visual and user experience refinements will will be rolling out across the whole OS (scopes, shell and apps) this coming year.

The new design guidelines for UX and UI patterns as well as Suru will be out soon. In the meanwhile hopefully these example apps will inspire you to have a look at the developer docs, get active on IRC and have a go yourself. We will also be releasing design source files and templates for the refreshed UI toolkit so that you can start applying them in your own app designs.

Dekko – Email

email-phone-tablet

The first example app is Dekko – the default email client  for mobile and tablet devices from BQ and Meizu. We have been very lucky to have the incredible talents of our community member Dan Chapman working on the development of Dekko, and the app is progressing at a fantastic rate. James Mulholland helped Dan with the UX and I have been working on the UI.

Like many apps, Dekko uses a list view to represent the primary level, and a detail view to show the secondary level. Where there’s room, these views can be displayed side by side, but on small screen screens or very shrunk windows, a PageStack showing only the list becomes the primary screen. On larger screens or expanded windows, the page stack automatically progresses into the familiar two-panel configuration. This adaptive layout is common on responsive websites, and our SDK team have built a component in the UI toolkit that does most of the hard work for you – AdaptivePageLayout.

email-desktop

The list item, which lives in the list component, is another example of ready made component that helps developers write convergent apps with less effort. The new ListItem in our toolkit has useful, well designed default layouts baked in when using ListItemLayout. It is also optimised for both touch and pointer interaction – via ListItemActions. A common pattern of interacting with list items on touch devices is to drag them left or right revealing key actions such as delete. When using a pointer, however, you would typically right click and use the contextual menu to access the same actions. Our UI Toolkit supports both types of input at all times, so you could drag the item left or right using a mobile or touch-enabled monitor, or right click using a mouse. We believe users should be free to mix how they interact with our components using whatever means is at their disposal and to their liking.

This behaviour is already baked into our ListItem component, so users will have a consistent experience when using apps, and developers will save time not having to roll their own solutions.

Music

 convergence-music
The music app is another example of the super talented Ubuntu community getting involved in building some of our core apps together with our internal teams. You might remember Andrew Hayzen and Victor Thompson from a previous interview on this blog. They have since been adding features and functionality to the app, and a convergent music app using multiple panels is currently working in a branch and will be landing in the master release soon. We are also looking at adding support for streaming music functionality, keep an eye out for this in the near future :)

music-closeup

The multi-panel music app reacts to window size changes intelligently – the album cards resize and shuffle themselves on window size changes. On smaller screen devices we have a persistent “Now playing” control bar at the bottom of the screen, but on larger screen sizes we have enough real estate to reimagine the play bar as an extra panel on the right with “Now playing” information, along with cover art, controls and a scrollable queue.

Calendar

convergent_calendar

The calendar app has been on the phone for a while but until now it hadn’t really had any UI design love or designs for larger screens.  We wanted to apply our visual language in the context of an app that is by default very minimal, allowing the few design elements to stand on their own.

Suru, our visual language, is light and flat, minimizing distractions, with carefully selected tones of gray, consistent spacing and margins to help the content breathe. We’ve added considered splashes of highlight colours that enhance the visual hierarchy without overwhelming it.

On the calendar app we are again making use of multiple panels, surfacing several layers when we have the real estate available. The same feature set of the app is of course available on all sizes, and the navigation feels intuitive with whatever input method or screen size you are using.

calendar-closeup

This design hasn’t been implemented yet, and in fact we are looking for new developers to join our Community Team. If you are a developer who would like to get involved in writing some of the core apps people use on Ubuntu – get in touch with alan.pope@canonical.com – we would love to hear from you!

Hopefully these examples have given inspiration and pointers to anyone who would like to have a go at designing apps for convergent Ubuntu. If you have any questions, don’t hesitate to reach out – jouni.helminen@canonical.com

 

Read more
Steph Wilson

MWC stand: open for business

Take a look at the final pictures of the stand taken yesterday before we opened for business today!

Pods at MWC

Phone demo pods ready to be played with :)

Entrance to stand MWC

Entrance to the stand  “Phone + OpenStack + NFV + IoT”

Canonical meeting room MWC

The Canonical meeting room

Read more
Steph Wilson

With MWC just two days away, the final preparations are now in full swing. The stand is looking bigger and brighter than ever and we cannot wait to share it with you.

Final preperations: MWC

IMG_4176

Final prep: MWC

 

Read more
Steph Wilson

It’s day 3 and the stand is nearing completion. The funky lights have been fitted, the meeting rooms have curvaceous walls inspired by the Ubuntu shape, and the cloud and phone demo pods are ready to rock some products for you to try.

Stay tuned tomorrow for some final pictures of behind the scenes at MWC!

Canonical-Build-Photos-9

One of the meeting rooms

photo_2016-02-19_15-55-27

 

Canonical-Build-Photos-7

Rectangular demo pods that will feature various cloud products

Read more
Steph Wilson

It’s day two behind the scenes at MWC and the stand is starting to take shape. The iconic orange Ubuntu flags are up, the walls and doors have been assembled, and the flooring has been put down. We are nearly there…

Day 2: MWC

 

Day 2: MWC

Day 2: MWC

Stay tuned tomorrow to see our final preparations for the stand.

Read more
Steph Wilson

With Mobile World Congress just around the corner, work has now commenced on our biggest stand to date!

Over the next week we will be posting pictures of the stand so you can see how it all comes together.

Day one:

Day 1 MWC

This year we are in the Main Hall – taking up more space :)

Day 1 MWC

Day 1 MWC

The flags are up!

Stay tuned for more pictures of the stand tomorrow

 

Read more
Inayaili de León Persson

A new look for tablet

Today we launched a new and redesigned tablet section on ubuntu.com that introduces all the cool features of the upcoming BQ Aquaris M10 Ubuntu Edition tablet.

Breaking out of the box

In this redesign, we have broken out of the box, removing the container that previously held the content of the pages. This makes each page feel more spacious, giving the text and the images plenty of room to shine.

This is something we’ve wanted to do for a while across the entire site, so we thought that having the beautiful, large tablet photos to work with gave us a good excuse to try out this new approach.

 

The overview page of the tablet section of ubuntu.com, before (left) and after

 

For most of the section, we’ve used existing patterns from our design framework, but the removal of the container box allowed us to play with how the images behave across different screen sizes. You will notice that if you look at the tablet pages on a medium to small screen, some of the images will be cropped by the edge of the viewport, but if you see the same image in a large screen, you can see it in its entirety.

 



From the top: the same row on a large, medium and small screen

 

How we did it

This project was a concerted effort across the design, marketing, and product management teams.

To understand the key goals for this redesign, we collected the requirements and messaging from the key stakeholders of the project. We then translated all this information into wireframes that guide the reader through what Ubuntu Tablet is. These went through a few rounds of testing and iteration with both users and stakeholders. Finally, we worked with a copywriter to refine the words of each section of the tablet pages.

 

Some of the wireframes

 

To design the pages, we started with exploring the flow of each page in large and small screens in flat mockups, which were quickly built into a fully functioning prototype that we could keep experimenting and testing on.

 

Some of the flat mockups created for the redesign

 

This design process, where we start with flat mockups and move swiftly into a real prototype, is how we design and develop most of our projects, and it is made easier by the existence of a flexible framework and design patterns, that we use (and sometimes break!) as needed.

 


Testing the new tablet section on real devices

 

To showcase the beautiful tablet screen designs on the new BQ tablet, we coordinated with professional photographers to deliver the stunning images of the real device that you can enjoy along every new page of the section.

 

One of the many beautiful device photos used across the new tablet section of ubuntu.com

 

Many people were involved in this project, making it possible to deliver a redesign that looks great, and is completed on time — which is always good a thing :)

In the future

In the near future, we want to remove the container box from the other sections of ubuntu.com, although you may see this change being done gradually, section by section, rather than all in one go. We will also be looking at redesigning our navigation, so lots to look forward to.

Now go experience tablet for yourself and let us know what you think!

Read more
Barry McGee

Maybe, like me, you seen more of the inside of your gym in January than you had for the six months previous. New year, new diet, new me.. or something like that.

A big creeping problem in recent years is that websites have been on an all out binge, and not just over the winter holidays — big videos, big images, fancy fonts, third-party libraries — they just can’t get enough of ’em.

Average page weights increased by 15% in 2014 and although I haven’t yet seen any similar research done for 2015 yet, I’m willing to bet that trend did not reverse.

Last week I was tasked with making some performance optimisations to the Ubuntu online tour.

This legacy codebase stretches all the way back to 2012, and as such was not benefitting from some of the modern tools we now have at our disposal as web developers.

We have been maintaining our largest codebases such as ubuntu.com and canonical.com to ensure they are as performant as they can be but this Ubuntu tour repository slipped through the cracks somewhat.

We have users all over the world and many of them don’t enjoy the luxury of fat internet pipes that we enjoy in our London office. Time to trim the fat…

At first look, I noted on load of the site it required 235 HTTP requests to download 2.7MB of data. Chunky Charlie!

 

Network waterfall screenshot

 

Delving into the codebase, I immediately spotted some big areas ripe for improvement:

  • The CSS files were not being concatenated nor were they minified.
  • The Javascript was also being loaded in separate files, also un-minified.
  • The image assets were uncompressed.
  • The HTML was un-minified.

Beyond that – I ran the site URL through Google’s PageSpeed Insights and also discovered;

  • Browser cacheing was not being being leveraged as static assets did not have any Expires headers specified
  • There were quite a few CSS and javascript dependancies blocking rendering of the page.

As you see, the site was only scoring a lowly 46/100, not great.

 

Google Page Speed Insights screenshot

 

For jobs such as this, my first weapon of choice is the task runner, Gulp. It’s quick and easy to drop Gulp on top of any existing site and use some of it’s wide array of plugins to optimise source assets for performance.

For this job I used gulp-concat, gulp-htmlmin, gulp-imagemin, gulp-minify-css, gulp-renamegulp-uglify, gulp with critical & gulp-rev.

Explaining how to use each of them is beyond the scope of this article but you can view my Gulpfile.js and accompanying package.json file to see what I did.

When retro-optimising a site, you might find you have to make certain compromises such as placing “src” folders inside folders you are optimising to store the original documents, then output the optimised versions into the original folder to ensure everything is backwards compatible and you haven’t broken any relative links. You should also be careful when globbing Javascript files as they may need to be loaded in a certain order to prevent race conditions. This is also true when concatenating and including Javascript libraries such as jQuery.

In an ideal world, you would not deploy any files from the repository you have compiled locally. They should be ignored by version control and compiled on the fly by running your task runner on the server using a continuous integration engine such as Jenkins or Travis CI. This is much cleaner and will prevent merge conflicts when multiple developers are working on the same codebase.

So — when we have all of the above configured and then run it over our legacy codebase, how much weight did it shave?

 

Network Waterfall - After

 

Good news! Now to load the site, we only need 166 HTTP (-29%) requests to download 2.2MB(-18%) of data. Slim(mer) Jim for the win!

This should mean our users with slower connections will have a much improved experience.

When we run the leaner site now deployed through Google Pagespeed Insights – we now get a much healthier score also.

 

Google Pagespeed - After

 

This was a valuable exercise for our team and reminded us we not only have a responsibility to keep all our new and upcoming work performant but we should also address any legacy sites still currently in use wherever possible.

A leaner web is a faster web and I’m sure that’s something we can all get behind.

 

Read more
Femma

We arrived in Helsinki on Sunday evening, ready to start our week long SDK sprint on Monday. Our hotel was in a nice location, by the sea.

The work stuff

The SDK is a core part of Ubuntu and provides an array of components and flexibility needed to create applications across staged and windowed form factors, with good design and user experience in mind.

The purpose of the sprint was to have the designers and engineers come together to work on tools and components such as palette themes, bottom edge, header, scrollbars, focus handling, dialogs, buttons, menus, text selections and developer tasks such as IDE, packaging and application startup.

Monday morning started with walking into our venue that looked somewhat like a classroom.

 

Classroom

The first task of the day required some physical activity of moving all the tables around so that the environment was much more conducive to a collaborative sprint.

Jouni presenting

Each day we broke off into working groups for our respective sessions and ironed out any existing issues, as well as working through new and exciting features that would enhance different SDK components.

Theme palette sessionJamie, Pierre and Zsombor working hard on the colour palette.

Jamie the professor

Old school pointing devices, Jamie gives it a go, looking very much like a professor!

What we achieved

During the course of the week we achieved what we’d set out to do:

  • Amended the theme palette to include any missing colours and then apply these to various components
  • Completed the implementation and release the bottom edge component into the staging environment
  • Completed the section scrolling prototype and have it reviewed by visual design and UX
  • Completed the portrait and landscape edit mode header prototype
  • Worked out behaviour of complex SDK components for focus handling and added some best practice examples to the specification
  • Communicated and gained concensus on the context menu design, who are now gearing up for some pre-requisite work and then implementation of context menus
  • Prepared the visual rules for buttons and made the Ubuntu shape ready to use for buttons
  • Completed the design for sliders  
  • Discussed a tree view component for navigation
  • Created a first draft of tabs wireframes and functionality agreed
  • Created a first draft of text selections visuals and reviewed, UX and functionality was discussed ready to include in the specification
  • Created the Libertine packaging project and containers
  • Tidied up the IDE
  • Created some Snapp packages and got them working
  • Ramped up some new  investigative work that arose in our collaboration

The planets aligned… literally

In the early hours of Wednesday morning  (before breakfast) a few of us managed to witnessed a planetary conjunction (Venus, Mars and Jupiter) which was truly amazing… a surprise benefit of sprinting in the arctic circle.
Even though there were a few hours of daylight, we managed to embrace the cold and stand outside to enjoy the beautiful views during lunch and coffee breaks.

The bay

All in all, it was a very productive and fun sprint. We left with a sense of accomplishment and camaraderie.

Read more
Matthieu James

An expanded device mono icon set

We will soon push an update of the Suru icon theme that includes more device icons in order to support the Ubuntu convergence story.

Because the existing icon set was focused on mobile, many of the new icons are very specific to the desktop, as we were missing icons such as hard disk, optical drive, printer or touchpad.

When designing new mono icons, we need to make sure that they are consistent with the graphic style of the existing set (thin outlines, rare solid shapes, etc).

A device, like a printer or a hard disk, can be quite complex if you want to make it look realistic, so it’s important to add a level of abstraction to the design. However the icon still has to be recognisable within the right context.

At the moment, if you compare the Suru icon theme to the symbolic mono icons in Gnome, or to the Humanity devices icons, a few icons are missing, so you should expect to see this set expand at some point in the future — but the most common devices are covered.

In the meantime, here is the current full set:

Device icon set

Read more
Steph Wilson

Today we celebrate our amazing Ubuntu Community and show our appreciation for all the hard work put into making Ubuntu what it is today.

Ubuntu is not just an operating system, it is a whole community in which everybody collaborates with everybody to bring to the life a wonderful human experience. When you download the ISO, burn it, install it and start to enjoy it, you know that a lot of people made magnificent efforts to deliver the best Ubuntu OS possible.

To show our appreciation, the Community Managers and Designers have nominated several community application developers to receive a special thank you for their outstanding work:

  • Dan Chapman (dekko)
  • Boren Zhang (dekko)
  • Kunal Parmar (calendar)
  • Stefano Verzegnassi (docviewer)
  • Riccardo Padovani (calculator, notes)
  • Bartosz Kosiorek (calculator, clock)
  • Roman Shchekin (shorts, docviewer)
  • Joey Chan (shorts)
  • Victor Thomson (music, weather)
  • Andrew Hazen (music, weather)
  • Nekhelesh Ramananthan (clock)
  • Niklas Wenzel (terminal, dekko/platform)

We’ll send everyone an official Ubuntu keychain and sticker pack.


 

We also got hold of some other special Ubuntu items and because it is impossible to pick favourites, names were drawn out of a hat:

1 

 

The following folks will be receiving a special Ubuntu gift from us:


3rd prize: An official Ubuntu hat – Niklas Wenzel

 

2nd prize: An official Ubuntu pad from Castelli – Andrew Hazen

 

1st prize: An official Ubuntu wireless mouse from Xoopar – Joey Chan

 

Well done guys!

Community Appreciation Day merchandise pack

Models not included.


Show your appreciation:

  • Ping an IRC Ubuntu channel and leave a thank you
  • Send an email to a mailing list; you can do it to a LoCo mailing list
  • On social media:
  • Or if you see a community member in the street, go up to them and give them a well-deserved pat on the back :)

For everyone who works out of passion and love for Ubuntu: we thank you, and hope it will encourage more contributors to join and make Ubuntu even better!

Read more
Inayaili de León Persson

Ubuntu 15.10 is here!

And ubuntu.com has a brand new homepage too!

The new homepage gives a better overview and links to all Ubuntu products. We also wanted to give visitors easy access to the latest Ubuntu news, so we’ve included a ‘latest news’ strip right below the big intro hero with links to featured articles on Ubuntu Insights.

We’ve also improved the content and flow of the cloud section, and brought the phone and desktop sections up to date.

Let us know what you think. And try the new Ubuntu 15.10!

ubuntu.com homepage before and after release

Read more
Robin Winslow

Last weekend I went to my first Pycon, my second conference in a fortnight.

The conference runs from Friday to Monday, with 3 days of talks followed by one day of “sprints”, which is basically a hack day.

PyCon has a code of conduct to discourage any form of othering:

Happily, PyCon UK is a diverse community who maintain a reputation as a friendly, welcoming and dynamic group.

We trust that attendees will treat each other in a way that reflects the widely held view that diversity and friendliness are strengths of our community to be celebrated and fostered.

And for me, the conference lived up to this, with a very friendly feel, and a lot of diversity in its attendants. The friendly and informal atmosphere was impressive for such a large event with more than 450 people.

Unfortunately, the Monday sprint day was cut short by the discovery of an unexploded bomb.

Many keynotes, without much Python

There were a lot of “keynote” talks, with 2 on Friday, and one each on Saturday and Sunday. And interestingly none of them were really about Python, instead covering future technology, space travel and the psychology of power and impostor syndrome.

But of course there were plenty of Python talks throughout the rest of the day – you can read about them on my other post. And I think it was a good decision to have more abstract keynotes. It shows that the Python community really is more of a general community than just a special interest group.

Van Lindberg on data economics, Marx and the Internet of Things

In the opening keynote on Friday morning, the PSF chairman showed that total computing power is almost doubling every year, and that by 2020, the total processing power in portable devices will exceed that in PCs and servers.

He then used the fact that data can’t travel faster than 11.8 inches per nanosecond to argue that we will see a fundamental shift in the economics of data processing.

The big-data models of today’s tech giants will be challenged as it starts to be quicker and make more economic sense to process data at source, rather than transfer it to distant servers to be processed. Centralised servers will be relegated to mere aggregators of pre-processed data.

He likened this to Marx seizing the means of production in a movement which will empower users, as our portable Things start to hold the real information, and choose who to share it with.

I really hope he’s right, and that the centralised data companies are doomed to fail to be replaced by the Internet of Autonomous Things, because the world of centralised data is not an equal world.

Does Python have a future on small processors? Isn’t it too inefficient?

In a world where all the interesting software is running on light-weight portable devices, processing efficiency becomes important once again. Van used this to argue that efforts to run Python effectively on low-powered devices, like MicroPython, will be essential for Python as a language to survive.

Daniele Procida: All I really want is power

The second keynote was just after lunch on Friday, Daniele Procida, organiser of DjangoCon Europe openly admitted that what he really wanted out of life was power. He put forward the somewhat controversial idea that power and usefulness are the same thing, and that ideas without power are useless.

He made the very good point that power only comes to those who ask for it, or fight for it. And that if we want power not to be abused, we really need to talk about it a whole lot more, even though it makes people uncomfortable (try asking someone their salary). We should acknowledge who has the power, and what power we have, and watch where the power goes.

He suggested that, while in politics or industry, power is very much a rivalled good, in open source it is entirely an unrivalled good. The way you grab power in the open source community is by doing good for the community, by helping out. And so by weilding power you are actually increasing power for those around you.

I don’t agree with him on this final point. I think power can be and is hoarded and abused in the open source community as well. A lot of people use their power in the community to edge out others, or make others feel small, or to soak up influence through talks and presentations and then exert their will over the will of others. I am certainly somewhat guilty of this. Which is why we should definitely watch the power, especially our own power, to see what effect it’s having.

The takeaway maxim from this for me is that we should always make every effort to share power, as opposed to jealously guarding it. It’s not that sharing power in the open source community is inevitable or necessarily comes naturally, but at least in the open source community sharing power genuinely can help you gain respect, where I fear the same isn’t so true of politics or industry.

Dr Simon Sheridan: Landing on a comet: From planning to reality

Simon Sheridan was an incredibly most humble and unassuming man, given his towering achievements. He is a world-class space scientist who was part of the European Space Agency team who helped to land Rosetta on comet 67P.

Most of what he mentioned was basically covered in the news, but it was wonderful to hear it from his perspective.

Naomi Ceder: Confessions of a True Impostor

When, a short way into her Sunday morning keynote, Naomi Ceder asked the room:

How many of you would say that you have in some way or another suffered from imposter syndrome along with me?

Almost everybody put their hands up. This is why I think this was such an important talk.

She didn’t talk about this per se, but contributing to the open source community is hard. No-one talks about it much, but I certainly feel there’s a lot of pressure. Because of its very nature, your contributions will be open, to be seen by anyone, to be criticised by anyone. And let’s face it, your contributions are never going to be perfect. And the rules of the game aren’t written down anywhere, so the chance of being ridiculed seem pretty high. Open source may be a benevolent idea, but it’s damned scary to take part in.

I believe this is why less than 2% of open source contributors are female, compared with more like 25-30% women in software development in general. And, as with impostor syndrome, the same trend is true of other marginalised groups. It’s not surprising to me that people who are used to being criticised and discriminated against wouldn’t subject themselves to that willingly.

And, as Naomi’s question showed, it is not just marginalised people who feel this pressure, it’s all of us. And it’s a problem. As we know, confidence is no indicator of actual ability, meaning that many many talented people may be too scared to contribute to open source.

As Naomi pointed out, impostor syndrome is a socially created condition – when people are expected to do badly, they do badly. In fact I completely agree with her suggestion that the existing Wikipedia definition of impostor syndrome (at the time of writing) could be more sensitively phrased to define it as a “social condition” rather than a “psychological phenomenon”, as well as avoiding singling out women.

While Naomi chose to focus in her talk on how we personally can try to mitigate feelings of being an impostor, I think the really important message here is one for the community. It’s not our fault that open source is scary, that’s just the nature of openness. But we have to make it more welcoming. The success of the open source movement really does depend on it being diverse and accepting.

What I think is really interesting is that stereotype threat can be mitigated by reminding people of their values, of what’s important to them. And this is what I hope will save open source. The more we express our principles and passion for open source, the more we express our values, the easier it is to counter negative feelings, to be welcoming, to stop feeling like impostors.

A great conference

Overall, the conference was exhausting, but I’m very grateful that I got to attend. It was inspiring and informative, and a great example of how to maintain a great community.

If you want you can now go and read about the other talks.

(Also published on robinwinslow.co.uk)

Read more
Robin Winslow

The weekend before last, I went to PyCon UK 2015.

I already wrote about the keynotes, which were more abstract. Here I’m going to talk about the other talks I saw, which were generally more technical or at least had more to do with Python.

Summary

The talks I saw covered a whole range of topics – from testing through documentation and ways to achieve simplicity to leadership. Here are some key take-aways:

The talks

Following are slightly more in-depth summaries of the talks I thought were interesting.

Friday

Leadership of Technical Teams – Owen Campbell

There were two key points I took away from this talk. The first was Owen’s suggestion that leaders should take every opportunity to practice leading. Find opportunities in your personal life to lead teams of all sorts.

The second point was more complex. He suggested that all leaders exist on two spectra:

  • Amount of control: hand-off to dictatorial
  • Knowledge of the field: novice to expert

The less you know about a field the more hands-off you should be. And conversely, if you’re the only one who knows what you’re talking about, you should probably be more of a dictator.

Although he cautioned that people tend to mis-estimate their ability, and particularly when it comes to process (e.g. agile), people think they know more than they do. No-one is really an expert on process.

He suggested that leading technical teams is particularly challenging because you slide up and down the knowledge scale on a minute-to-minute basis sometimes, so you have to learn to be authoritative one moment and then permissive the next, as appropriate.

Document all the things – Kristian Glass

Kristian spoke about the importance, and difficulty, of good documentation.
Here are some particular points he made:

  • Document why a step is necessary, as well as what it is
  • Remember that error messages are documentation
  • Try pair documentation – novice sitting with expert
  • Checklists are great
  • Stop answering questions face-to-face. Always write it down instead.
  • Github pages are better than wikis (PRs, better tracking)

One of Kristian’s main points was that it goes against the grain to write documentation, ‘cos the person with the knowledge can’t see why it’s important, and the novice can’t write the documentation.

He suggested pair documentation as a solution, which sounds like a good idea, but I was also wondering if a StackOverflow model might work, where users submit questions, and the team treat them like bugs – need to stay on top of answering them. This answer base would then become the documentation.

Saturday

Asking About Gender – the Whats, Whys and Hows – Claire Gowler

Claire spoke about how so many online forms expect people to be either simply “male” or “female”, when the truth can be much more complicated.

My main takeaway from this was the basic point that forms very often ask for much more information than they need, and make too many assumptions about their users. When it comes to asking someone’s name, try radically reducing the complexity by just having one text field called “name”. Or better yet, don’t even ask their name if you don’t need it.

I think this feeds into the whole field of simplicity very nicely. A very many apps try to do much more than they need to, and ask for much more information than they need. Thinking about how little you know about your user can help you realise what you actually don’t need to know about your user.

Finding more bugs with less work – David R. MacIver

David MacIver is the author of the Hypothesis testing library.

Hypothesis is a Python library for creating unit tests which are simpler to write and more powerful when run, finding edge cases in your code you wouldn’t have thought to look for. It is stable, powerful and easy to add to any existing test suite.

When we write tests normally, we choose the input cases, and we normally do this and we often end up being really kind to our tests. E.g.:

What Hypothesis does it help us test with a much wider and more challenging range of values. E.g.:

There are many cases where Hypothesis won’t be much use, but it’s certainly good to have in your toolkit.

Sunday

Simplicity Is A Feature – Cory Benfield

Cory presented simplicity as the opposite of complexity – that is, the fewer options something gives you, the more simple and straightforward it is.

“Simplicity is about defaults”

To present as simple an interface as possible, the important thing is to have many sensible defaults as possible, so the user has to make hardly any choices.

Cory was heavily involved in the Python Requests library, and presented it as an example of how to achieve apparent simplicity in a complex tool.

“Simple things should be simple, complex things should be possible”

He suggested thinking of an “onion model”, where your application has layers, so everything is customisable at one of the layers, but the outermost layer is as simple as possible. He suggested that 3 layers is a good number:

  • Layer 1: Low-level – everything is customisable, even things that are just for weird edge-cases.
  • Layer 2: Features – a nicer, but still customisable interface for all the core features.
  • Layer 3: Simplicity – hardly any mandatory options, sensible defaults
    • People should always find this first
    • Support 80% of users 80% of the time
    • In the face of ambiguity do the right thing

He also mentioned that he likes README driven development, which seems like is an interesting approach.

How (not) to argue – a recipe for more productive tech conversations – Harry Percival

I think this one could be particularly useful for me.

Harry spoke about how many people (including him) have a very strong need to be right. Especially men. Especially those who went to boarding school. And software development tends to be full of these people.

Collaboration is particularly important in open source, and strongly disagreeing with people rarely leads to consensus, in fact it’s more likely to achieve the opposite. So it’s important that we learn how to get along.

He suggests various strategies to try out, for getting along with people better:

  • Try simply giving in, do it someone else’s way once in a while (hard to do graciously)
  • Socratic dialogue: Ask someone to explain their solution to you in simple terms
  • Dogfooding – try out your idea before arguing for its strength
  • Bide your time: Wait for the moment to see how it goes
  • Expose yourself to other social situations, where arguments are less acceptable

All of this comes down to stepping back, waiting and exercising humility. All of which are easier said than done, but all of which are very valuable if I could only manage it.

FIDO – The dog ate my password – Alex Willmer

After covering fairly common ground of how and why passwords suck, Alex introduced the FIDO alliance.

The FIDO alliance’s goal is to standardise authentication methods and hopefully replace passwords. They have created two standards for device-based authentication to try to replace passwords:

  • UAF: First-factor passwordless biometric authentication
  • U2F: Second-factor device authentication

Browsers are just starting to support U2F, whereas support for UAF is farther off. Keep an eye out.

Data Visualisation with Python and Javascript – crafting a data-visualisation for the web – Kyran Dale

Kyran spoke about visualising data, and demoed using Scrapy and Pandas to retrieve the Nobel laureatte data from Wikipedia, using Flask to serve it as a RESTful API, and then using D3 to create an interactive browser-based visualisation.

(Also published on robinwinslow.co.uk)

Read more
Robin Winslow

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

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

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

Who’s it for?

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

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

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

Limitations of Guidelines

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

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

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

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

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

Architecture goals for Vanilla

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

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

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

  • Create a basic framework (Vanilla) which only contains the common elements shared across all our sites.

    • This framework should be written in a modular way, so it’s easy to include only the parts you need
  • Extend the basic framework in “theme” projects (e.g. ubuntu-vanilla-theme) which will apply specific styling (colours etc.) for that specific brand.

    • These themes should also only contain code which needs to be shared. Site-specific styling should be kept local to the project
  • Still provide hosted compiled CSS for sites to hotlink to if they like, but force them to link to a specific version (e.g. vanilla-framework-version-0.0.15.css) rather than “latest” so that we can release a new version without worry.

Sass modularisation

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

Default variables

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

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

Separating concerns into separate files

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

Keeping everything in a mixin

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

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

Namespacing

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

Overall structure

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

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

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

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

NPM modules

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

Hotlinks for compiled CSS

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

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

How to use the framework

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

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

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

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

The future

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

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

Read more
Peter Mahnke

Ubuntu is a big Open Source project and there are a lot of websites in our community. The web team at Canonical literally doesn’t even know how many sites there are. We have heard there are over 200 ubuntu.com subdomains alone, but we know that there are many more that are owned by local groups and teams outside that single ubuntu.com domain.

Traditionally most of our work has been on www.ubuntu.com and www.canonical.com, but over the years, we have designed, often built and occasionally are responsible for the content of a series of key sites like: insights.ubuntu.com, design.ubuntu.com, developer.ubuntu.com, design.canonical.com. And we have often attempted to provide on-brand versions of wiki and WordPress templates.

As the number of sites grew, we got tired of re-creating grids, templates, CSS all the time.

Enter guidelines

To resolve these issues, we created Ubuntu web guidelines. Instead of sites of cobbled together CSS and a borrowed grid, guidelines gave us something far more formalised and systematic. A grid, typography, core styles and pattern, all with our beautiful Ubuntu brand guidelines. We were not only able to maintain a whole set of sites from a single hosted set of CSS files, but others could borrow and use it easily. We even transitioned the guidelines to be responsive without breaking our sites. You can read more in our series of posts Making ubuntu.com responsive.

Exit guidelines

Around two years ago, the web team started supporting the design and development of some of Canonical’s cloud apps, including Juju, MAAS, and Canonical OpenStack Autopilot installer. These apps have a different look and feel than ubuntu.com. And they often have special requirements, for example, MAAS is likely to be run in data centres without internet access for things like fonts, images, or CSS, that the guidelines did not natively support.

We looked at how to best adapt the guidelines to work with these web apps. We looked at how we were already making www.canonical.com work, essentially overriding the Ubuntu branded guidelines and decided to change the entire approach.

Enter Vanilla

For Vanilla, we wanted to start over, but not have to rewrite everything. So our quick list of project goals was:

  • Minimise the changes to our existing html
  • Create a core theme that distilled the guidelines to its basic Ubuntu-ness
  • Make everything more modular, easy to add or remove components
  • Make it easy for anyone to create themes for each new project that could borrow from other themes
  • Create themes for ubuntu and canonical websites
  • Remove our reliance on javascript
  • Make it work stand-alone
  • Make it easy to build, develop and update
  • Invite other people both inside and outside Canonical to start using the framework

The future

So now we are close to releasing the first version of Vanilla. Canonical.com and ubuntu.com will be moved over the coming months. Then we will look at moving other projects, like MAAS, jujucharms.com, Landscape to the framework.

Please keep reading these posts, you can see Ant’s first post, Introducing Vanilla. And take a look at the project on GitHub and let us know what you think.

Read more
Benjamin Keyser

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

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

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

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

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

Try this exercise

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

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

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

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

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

What about landscape & desktop? Use building blocks

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

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

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

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

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

Columns, too

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

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

Putting it all together across all form factors

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

 

 

 

Read more
Robin Winslow

Despite some reservations, it looks like HTTP/2 is very definitely the future of the Internet.

Speed improvements

HTTP/2 may not be the perfect standard, but it will bring with it many long-awaited speed improvements to internet communication:

  • Sending of many different resources in the first response
  • Multiplexing requests to prevent blocking
  • Header compression
  • Keep connections alive
  • Bi-directional communication

Changes in long-held performance practices

I read a very informative post today (via Web Operations Weekly) which laid out all the ways this will change some deeply embedded performance principles for front-end developers. Namely:

Each of these practices are hacks which make website setups more complex and more opaque, but with the goal of speeding up front-end performance by working around limitations in HTTP. Fortunately, these somewhat ugly practices are no longer necessary with HTTP/2.

Importantly, Matt Wilcox points out that in an HTTP/2 world, these practices might actually slow down your website, for the following reasons:

  • If you serve concatenated CSS, Javascript or image files, it’s likely you’re sending more content than you strictly need to for each page
  • Serving assets from different domains prevents HTTP/2 from reusing existing connections, forcing it to open extra ones

But not yet…

This is all very exciting, but note that we can’t and shouldn’t start changing our practices yet. Even server-side support for HTTP/2 is still patchy, with nginx only promising full support by the end of 2015 (with Microsoft’s IIS, surprisingly, putting other servers to shame).

But of course the main limiting factor will, as usual, be browsers:

  • Firefox leads the way, with support since version 36
  • Chrome has support for spdy4 (the precursor to HTTP/2), but it isn’t enabled by default yet
  • Internet Explorer 11 supports HTTP/2 only in Windows 10 beta

As usual the main limiting factor will be waiting for market share of older versions of Internet Explorer to drop off. Braver organisations may want to be progressive by deliberately slowing down the experience for people on older browsers to speed up the more up-to-date and hence push adoption of good technology.

If you want to get really clever, you could serve a different website structure based on the user agent string, but this would really be a pain to implement and I doubt many people would want to do this.

Even with the most progressive strategy, I doubt anyone will be brave enough to drop decent HTTP/1 performance until at least 2016, as this is when nginx support should land; Windows 10 and therefore IE 11 will have had some time to gain traction and of course Internet Explorer market share in general will have continued to drop in favour of Chrome and Firefox.

TL;DR: We front-end developers should be ready to change our ways, but we don’t need to worry about it just yet.

Originally posted on robinwinslow.co.uk.

Read more