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!

In the coming months, users will start noticing things looking more and more different on Ubuntu. As we gradually roll out our new and improved Suru visual language, you’ll see apps and various other bits of the platform take on a lighter, more clean and cohesive look.

Why refresh apps at all?

As Ubuntu brings convergence to life—embracing today’s as well as future devices—our visual style and UI Toolkit need to evolve to support the new world. The changes taking place platform-wide make it simpler for designers and developers to integrate convergence from inception, and help apps come to life equally on mobile or desktop without a lot of additional work. As we apply new convergence UI and UX patterns to general-purpose components like lists and checkboxes, we also seek out opportunities to work with community developers and designers to put the thinking and new components into practice. The Clock app has been one such opportunity.

The Redesign

Our clean, crisp and lucid Suru visual language and style works well with the added functionality required for convergence. There’s less visual distraction and noise than ever, providing a clear pathway to making the most of the new toolkit’s convergence functionality.

Our Suru visual design language is based on origami, with graphic elements containing meaningful folds and shadows to create the illusion of paper and draw focus to certain areas. Using the main clock face’s current animation (where the clock flips from analog to digital on touch) as inspiration, it seemed natural to place a fold in the middle of the clock. On touch, the clock “folds” from analog to digital.

To further the paper look, drop shadows are used to give the illusion of layers of paper. The shadow under the clock face elevates it from the page, adding a second layer. The drop shadows on the clock hands add yet another layer.

As for colours, the last clock design featured a grey and purple scheme. In our new design, we make use of our very soon-to-be released new color palette. We brightened the interface with a white background and light grey clock face. On the analog clock, the hour and second hands are now Ubuntu orange. With the lighter UI, this subtle use of branding is allowed to stand out more. Also, the purple text is gone in favor of a more readable dark grey.

The bottom edge hint has also been redesigned. The new design is much more minimal, letting users get used to the gesture without interrupting the content too much.

In the stopwatch section, the fold is absent from the clock face since the element is static. We also utilize our new button styling. In keeping with the origami theme, the buttons now have a subtle drop shadow rather than an inward shadow, to again create a more “paper” feel.

This project has been one of my favorites so far. Although it wasn’t a complete redesign (the functionality remains the same) it was fun seeing how the clock would evolve next. Hope you enjoy the new version of the clock, it’s currently in development so look out for it on your phones soon and stay tuned for more visual changes.

Visual Design: Rae Shambrook

UX Design: James Mulholland

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.

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.

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.

Jamie, Pierre and Zsombor working hard on the colour palette.

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.

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

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:

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:

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!

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:
  • UCA Day Facebook
  • Google Plus
  • Hashtag #ucaday on Twitter
• 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!

After many hours of research, testing and never-ending questions about structure, design, aesthetics and function, we’re very happy to announce that Jujucharms has a new homepage!

All through this site redesign, our main aim has been to make complex content easy to digest and more fun to read. We’ve strived to create a website that not only looks beautiful, but also succeeds in thoroughly explaining what Juju is and the way it can improve your workflow.

Key content is now featured more prominently. We wanted the homepage to be illustrative and functional, hence the positioning of a bold headline and clear call to action which users immediately see as they access the site.

One of the key change between the old homepage and the new is the addition of two visual diagrams, which we have made sure to optimise for whichever device users may be accessing the site with. The first diagram explains the most relevant aspects of the service and how users can incorporate it into their workflow (Fig. 1). The second explains the different elements that compose Juju and the way the service works at a technical level (Fig. 2).

Figure 1.

Figure 2.

After scrolling, visitors encounter a section which allows direct access into the store, encouraging them to explore the wide range of services it offers. This allows for a more hands-on discovery and understanding of what Juju is – users can either start designing straight away, test it, or explore the site if they wish to find more information before trying it out.

Overall, we’ve made sure to re-design our homepage in a way that truly benefits our audience. In order to do so we conducted numerous user testing sessions throughout the development of the site and re-iterated the designs based on our user’s feedback. This approach enabled us to understand which content and elements should be prioritised and define the best way to evolve the design.

We collaboratively reviewed and analysed our findings as a team throughout the process and made decisions on next steps to take. After quite a few iterations we hope to have designed a homepage which reflects the core concept and benefits of Juju, and that it becomes something that users will want to come back to.

We hope you like it and look forward to hearing your thoughts about it!

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!

We sat down with Dekko star Dan Chapman to get an insight into how he got involved with Ubuntu and his excitement for the release of the Pocket Desktop.

Dan has been an active member of the Community since 2013, where he has worked closely with our Design Team to create one of our first convergent showcase apps: Dekko. He also helps out with the Ubuntu QA community with package testing and automated tests for the ubuntu-autopilot-tests project.

The Dekko app is an email client that we are currently developing to work across all devices: mobile, tablet and desktop. If you are interested in contributing to Dekko, whether that be writing code, testing, documentation, translations or have some super cool ideas you would just like to discuss. Then please do get in touch, all contributions are welcomed!

Dan can be reached by email dpniel@ubuntu.com or pop by #dekko on irc.freenode.net or see his wiki page https://wiki.ubuntu.com/dpniel

Early Dekko exploration

What inspired you to contribute?

I first got involved with the Community in 2013, where Nicholas Skaggs introduced me to the Quality Team to write test cases for automated testing for the Platform. I can’t remember why I started exactly, but I saw it as an opportunity to improve it. Ever since then it’s been a well worth it experience.

What is it about open source that you like?

I like the fact that in the Community everyone has a common goal to build something great.

How does it fit into your lifestyle?

I study from home at the moment so I have to divide my time between my family, Ubuntu and my studies.

What I do for Ubuntu and my course are quite closely tied. The stuff I do for Ubuntu is giving me real life practical skills that I can relate to my course, which is mainly theory based.

Have you made your work with the Ubuntu Community an integral part of your studies as well?

I’m actually doing a project at the moment that is to do with my work on Dekko, but it’s for interacting with an exchange server and implementing a client side library. Hopefully when that’s done I can bring it into Dekko on a later date. I try to keep my interests parallel.

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

Quite a large proportion of my time goes towards Ubuntu.

How is it working remotely?

I find it more than effective. I mean it would be great to meet people face-to-face too.

Dekko development

What are you most excited about?

Being able to have a full-blown computer in my pocket. As soon as it’s available i’m having the pocket desktop.

Do you use your Ubuntu phone as your main device?

I do yes. The rest of the family do too. I even got my eldest boy, who’s 9 to use it, as well as my partner and mother-in-law.

How is it working with the Ubuntu Design Team?

It’s been great actually because i’m useless at design. There’s always something to improve on, so even if the designs aren’t ready there’s still enough to work on. There hasn’t been big waits in-between or waiting for you guys as you’re busy. The support is there if you need it.

Have you faced any challenges when working on an app for many form factors (phone, tablet, desktop etc)?

The only challenge is getting the design before the toolkit components are ready. It was a case of creating custom stuff and trying to not cause myself too much pain when I have to switch. The rest has been plain sailing as they toolkit is a breeze to use, and the Design team keep me informed of any changes.

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

I speak to a fair few of them now through Telegram, that seems to be the place to talk now there’s an app for it. It’s nice you can ping your question to anyone and you’ll get an immediate response relatively quickly. Alan Pope, always gives you answers.

What are you thoughts on the Pocket Desktop?

It is exciting as it’s something different. I don’t think there’s competition, as we all have different target audiences we are reaching to. I’m really excited about where the Platform is heading.

The future of convergent Dekko

We believe that the first impression matters, especially when it comes to introducing a new product to a user for the first time. Our aim is to delight the user from the moment they open the box, through to the setup wizard that will help them get started with their new phone.

Devices have become an essential part of our everyday lives. We choose carefully the ones we want to adopt, taking into account all manner of factors that influence our lifestyle and how we conduct our everyday tasks. So when buying a totally new product, with unfamiliar software, or from a new brand, you want to make the first impression count in order to seduce and reassure the user that this product is for them.

The out of the box experience (OOBE) is one of the most important categories of software usability. It essentially says how easy your software is to use, as well as introducing the user into your brand through visual design and tone of voice, which can convey familiarity and trust within your product.

How did we do it?

We started to look at research around users past experiences when setting up a new device and their feelings about the whole process. We also took a look at what our competitors were doing, taking into account current patterns and trends in the market.

From gathering this research we started to simplify as much as possible the OOBE workflow. Taking into consideration the good and the bad things, we started to define our design goals:

• Design for seduction
• Simplicity
• Introduce the brand through design
• Transform the setup wizard

What did we change?

First of all we started from the smallest screen, taking the existing screens we have for mobile and assessing the design faults and bugs.

In order to create a consistent experience across all devices, we drew together common first experiences found on the mobile, tablet and desktop:

• Choosing a language
• Wifi setup
• Choosing a Time Zone
• Choosing a lock screen option

One of the major changes we wanted to achieve was to give the user the same experience across all devices, moving us closer to achieving a seamless convergent platform.

What did we achieve?

• We achieved our main aim in creating the same visual experience across all devices.

• We defined two types of screens: Primary screen (left), Secondary screen (right)

The secondary screens created more space for forms, which helped us to define a consistent and intuitive animation between screens.

• All the dialogs were transformed where possible into full screens. We kept the dialogs only to communicate to the user confirmation or error messages.

• The desktop installer was simplified and modernized.

The implementation of the OOBE has already begun and we cannot wait for you to open the box and experience it on your new Ubuntu device.

UX Designer: Andreea Pirvu

Visual Designer: Grazina Borosko

We’ve got a new CSS framework at Canonical, named Vanilla. My colleague Ant has a great write-up introducing Vanilla. Essentially it’s a CSS microframework powered by Sass. The build process consists of two steps, an open source build, and a private build.

Open Source Build

While there are inevitably componants that need to be kept private (keys, tokens, etc.) being Canonical, we want to keep much of the build in the open, in addition to the code. We wanted the build to be as automated and close to CI/CD principles as possible. Here’s what happens:

Committing to our github repository kicks off a travis build that runs gulp tests, which include sass-lint. And we also use david-dm.org to make sure our npm dependencies are up to date. All of these have nice badges we can link to right from our github page, so the first thing people see is the heath of our project. I really like this, it keeps us honest, and informs the community.

Not everything can be done with travis, however, as publishing Vanilla to npm, updating our project page and demo site require some private credentials. For the confidential build, we use Jenkins. (formally Hudson, a java-based build management system.).

Private Build with Jenkins

Our Jenkins build does a few things:

1. Increment the package.json version number
2. npm publish (package)
3. Build Sass with npm install
4. Upload css to our assets server
5. Update Sassdoc
6. Update demo site with new CSS

Robin put this functionality together in a neat bash script: publish.sh.

We use this script in a Jenkins build that we kick off with a few parameters, point, minor and major to indicate the version to be updated in package.json. This allows our devs push-button releases on the fly, with the same build, from bugfixes all the way up to stable releases (1.0.0)

After less than 30 seconds, our demo site, which showcases framework elements and their usage, is updated. This demo is styled with the latest version of Vanilla, and also serves as documentation and a test of the CSS. We take advantage of github’s html publishing feature, Github Pages. Anyone can grab – or even hotlink – the files on our release page.

The Future

It’d be nice for the regression test (which we currently just eyeball) to be automated, perhaps with a visual diff tool such as PhantomCSS or a bespoke solution with Selenium.

Wrap-up

Vanilla is ready to hack on, go get it here and tell us what you think! (And yes, you can get it in colours other than Ubuntu Orange)

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

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

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

Who’s it for?

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

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

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

Limitations of Guidelines

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

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

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

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

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

Architecture goals for Vanilla

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

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

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

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

Sass modularisation

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

Default variables

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

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

Separating concerns into separate files

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

Keeping everything in a mixin

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

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

Namespacing

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

Overall structure

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

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

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

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

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

NPM modules

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

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

Hotlinks for compiled CSS

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

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

How to use the framework

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

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

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

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

The future

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

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

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

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

What we have changed:

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

Less solid shapes

Before

After

Lighter strokes

Before

After

Negative spaces

Before

After

Font patterns 

Oblique lines are slightly curved

Arcs are not perfectly rounded but rather curved

Uppercase letters use right or sharp angles

Vertical lines have oblique upper terminations.

Nice soft curves

Action

Devices

Indicators

Weather

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

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

Grid Unit

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

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

Grid Unit Calculation

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

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

In pseudocode:

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

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

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

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

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

Layout

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

Landscape Grid Units Count Calculation

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

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

In pseudocode:

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

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

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

Panel

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

Examples

90 GU Layout

147 GU Layout

Try more combinations using the Grid System Tool.

Multi-Column Layout

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

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

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

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

Examples

3 Columns in a 50 GU Panel

3 Columns in a 60 GU Panel (variable)

Try more combinations using the Grid System Tool.

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

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

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

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

Here’s the mess they made…

Main topics covered:

– Multi-column layouts, panel behaviors and pagestack

– Header, Bottom Edge and edit mode

– Focus handling

– List item layouts

– Date and time pickers

– Drop-down menus

– Scrollbars

– Application menu

– Tooltips

Here are some of the highlights:

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

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

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

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

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

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

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

They enjoyed some downtime too…

Arrival dinner at Byron Burgers

Out in Soho

Wine tasting in the office (not a regular occurrence)

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

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

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

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

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

Try this exercise

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

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

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

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

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

What about landscape & desktop? Use building blocks

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

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

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

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

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

Columns, too

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

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

Putting it all together across all form factors

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

Check out the video interview here :)

Community members at the Sprint

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

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

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

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

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

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

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

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

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

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

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

What inspired you to contribute?

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

Do you find it hard to implement some designs?

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

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

What is it about open source that you like?

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

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

How does it fit into your lifestyles?

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

Have you made any other applications for Ubuntu?

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

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

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

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

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

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

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

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

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

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

Steph: “Thanks for your time guys!”

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

Album detail

Landing page

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

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

(Community gathering at the Sprint)

Riccardo Padovani 

Italian Community site:

http://ubuntu.it/

Personal blog:

http://blog.rpadovani.com/

So Riccardo, how did you get involved in Ubuntu?

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

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

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

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

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

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

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

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

Does your Community regularly meet-up?

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

Do you find these sprints helpful?

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

Filippo Scognamiglio

Personal blog:

http://swordfishslabs.wordpress.com/

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

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

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

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

So, what’s your background?

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

Being part of a Community, what does it mean?

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

How’s the Sprint going for you? 

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

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

What motivates you? 

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

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

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

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

(Community meal out)

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

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

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

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

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

(The main Ballroom)

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

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

So how did the Sprint go for you guys?

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

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

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

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

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

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

What was your best moment?

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

Did anything come up that you didn’t expect?

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

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

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

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

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

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

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

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

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

(Unicorn hard at work)

There was a bit of time for some sightseeing too…

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

(The Washington Monument)

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

(The White House)

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

(Twins Jazz Club)

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

(Great Falls Park)

A few weeks ago we launched ‘Machine view’ for Juju, a feature designed to allow users to easily visualise and manage the machines running in their cloud environments. In this post I want to share with you some of the challenges we faced and the solutions we designed in the process of creating it.

A little bit about Juju…
For those of you that are unfamiliar with Juju, a brief introduction. Juju is a software tool that allows you to design, build and manage application services running in the cloud. You can use Juju through the command-line or via a GUI and our team is responsible for the user experience of Juju in the GUI.

First came ‘Service View’
In the past we have primarily focused on Juju’s ‘Service view’ – a virtual canvas that enables users to design and connect the components of their given cloud environment.

This view is fantastic for modelling the concept and relationships that define an application environment. However, for each component or service block, a user can have anything from one unit to hundreds or thousands of units, depending on the scale of the environment, and before machine view, units means machines.

The goal of machine view was to surface these units and enable users to visualise, manage and optimise their use of machines in the cloud.

‘Machine view’: design challenges
There were a number of challenges we needed to address in terms of layout and functionality:

• The scalability of the solution
• The glanceability of the data
• The ability to customise and sort the information
• The ability to easily place and move units
• The ability to track changes
• The ability to deploy easily to the cloud

I’ll briefly go into each one of these topics below.

Scalability: Environments can be made up of a couple of machines or thousands. This means that giving the user a clear, light and accessible layout was incredibly important – we had to make sure the design looked and worked great at both ends of the spectrum.

Glanceability: Users need simple comparative information to help choose the right machine at-a-glace. We designed and tested hundreds of different ways of displaying the same data and eventually ended up with an extremely cut back listing which was clean and balanced.

The ability to sort and customise: As it was possible and probable that users would scale environments to thousands of machines, we needed to provide the ability to sort and customise the views. Users can use the menus at the top of each column to hide information from view and customise the data they want visible at a glance. As users become more familiar with their machines they could turn off extra information for a denser view of their machines. Users are also given basic sorting options to help them find and explore their machines in different ways.

The ability to easily place and move units: Machine view is built around the concept of manual placement – the ability to co-locate (put more than one) items on a single machine or to define specific types of machines for specific tasks. (As opposed to automatic placement, where each unit is given a machine of the pre-determined specification). We wanted to enable users to create the most optimised machine configurations for their applications.

Drag and drop was a key interaction that we wanted to exploit for this interface because it would simplify the process of manually placing units by a significant amount. The three column layout aided the use of drag and drop, where users are able to pick up units that need placing on the left hand side and drag them to a machine in the middle column or a container in the third column. The headers also change to reveal drop zones allowing users to create new machines and containers in one fluid action keeping all of the primary interactions in view and accessible at all times.

The ability to track changes: We also wanted to expose the changes that were being made throughout user’s environments as they were going along and allow them to commit batches of changes altogether. Deciding which changes were exposed and the design of the uncommitted notification was difficult, we had to make sure the notifications were not viewed as repetitive, that they were identifiable and that it could be used throughout the interface.

The ability to deploy easily to the cloud: Before machine view it was impossible for someone to design their entire environment before sending it to the cloud. The deployment bar is a new ever present canvas element that rationalises all of the changes made into a neat listing, it is also where users can deploy or commit those changes. Look for more information about the deployment bar in another post.

We hope that machine view will really help Juju users by increasing the level of control and flexibility they have over their cloud infrastructure.

This project wouldn’t have been possible without the diligent help from the Juju GUI development team. Please take a look and let us know what you think. Find out more about Juju, Machine View or take it for a spin.