Canonical Voices

Posts tagged with 'design'

Inayaili de León Persson

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

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

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

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

Developers sprintingDevelopers sprinting and a wall of sticky notes

Things we learned

Make sure you have a solid grid

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

Use Modernizr for feature detection

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

SVG icons and pictograms

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

Things we had to work on

Defining visual layout across screen sizes

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

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

Canonical wireframeA wireframe created for canonical.com

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

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

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

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

Animations

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

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

The process going forward

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

Read more
Mark Shuttleworth

Every detail matters, and building great software means taking time to remove the papercuts. Ubuntu has over the past 5 years been refined in many ways to feel amazingly comfortable on the cloud. In the very early days of EC2 growth the Ubuntu team recognised how many developers were enjoying fast access to infrastructure on demand, and we set about polishing up Ubuntu to be amazing on the cloud.

This was a big program of work; the Linux experience had many bad assumptions baked in – everything had been designed to be installed once on a server then left largely untouched for as long as possible, but cloud infrastructure was much more dynamic than that.

We encouraged our team to use the cloud as much as possible, which made the work practical and motivated people to get it right themselves. If you want to catch all the little scratchy bits, make it part of your everyday workflow. Today, we have added OpenStack clouds to the mix, as well as the major public clouds. Cloud vendors have taken diverse approaches to IAAS so we find ourselves encouraging developers to use all of them to get a holistic view, and also to address any cloud-specific issues that arise. But the key point is – if it’s great for us, that’s a good start on making it great for everybody.

Then we set about interviewing cloud users and engaging people who were deep into cloud infrastructure to advise on what they needed. We spent a lot of time immersing ourselves in the IAAS experience through the eyes of cloud users – startups and industrial titans, universities and mid-sized, everyday companies. We engaged the largest and fastest-moving cloud users like Netflix, who have said they enjoy Ubuntu as a platform on the cloud. And that in turn drove our prioritisation of paper-cuts and significant new features for cloud users.

We also looked at the places people actually spend time developing. Lots of them are on Ubuntu desktops, but Windows and MacOS are popular too, and it takes some care to make it very easy for folks there to have a great devops experience.

All of this is an industrial version of the user experience design process that also powers our work on desktop, tablet and phone – system interfaces and applications. Devops, sysadmins, developers and their managers are humans too, so human-centric design principles are just as important on the infrastructure as they are on consumer electronics and consumer software. Feeling great at the command line, being productive as an operator and a developer, are vital to our community and our ecosystem. We keep all the potency of Linux with the polish of a refined, designed environment.

Along the way we invented and designed a whole raft of key new pieces of Ubuntu. I’ll write about one of them, cloud-init, next. The net effect of that work makes Ubuntu really useful on every cloud. That’s why the majority of developers using IAAS do so on Ubuntu.

Read more
Inayaili de León Persson

Ubuntu Resources — beta 2!

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

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

Filtered search

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

Search result filtersSearch results filters

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

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

Layout and font sizes

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

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

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

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

‘Add to’

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

Colour consistency

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

Darker grey textDarker grey in event details

Even more changes

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

Next steps

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

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

Read more
niemeyer

As part of the on going work on Ubuntu Touch phones, I was invited to contribute a Go package to interface with ubuntuoneauth, a C++ and Qt library that authenticates against Ubuntu One using the system account made available by the phone owner. The details of that library and its use case are not interesting for most people right now, but the work to interface with it is a good example to talk about because, besides the result (uoneauth) being an external and independent Go package that extends the qml package, ubuntuoneauth is not a QML library, but rather a plain Qt library. Some of the callbacks use even traditional C++ types that do not inherit from QObject and have no Qt metadata, so offering that functionality from Go nicely takes a bit more work.

What follows are some of the highlights of that integration logic, to serve as a reference for similar extensions in the future. Note that if your interest is in creating QML applications with Go, none of this is necessary and the documentation is a better place to start.

As an initial step, the following examples demonstrate how the original C++ library and the Go package being designed are meant to be used. The first snippet contains the relevant logic taken out of the examples/signing-main.cpp file, tweaked for clarity:

int main(int argc, char *argv[]) {
    (...)
    UbuntuOne::SigningExample *example = new UbuntuOne::SigningExample(&a);
    QTimer::singleShot(0, example, SLOT(doExample()));
    (...)
}

SigningExample::SigningExample(QObject *parent) : QObject(parent) {
    QObject::connect(&service, SIGNAL(credentialsFound(const Token&)),
                     this, SLOT(handleCredentialsFound(Token)));
    QObject::connect(&service, SIGNAL(credentialsNotFound()),
                     this, SLOT(handleCredentialsNotFound()));
    (...)
}

void SigningExample::doExample() {
    service.getCredentials();
}

void SigningExample::handleCredentialsFound(Token token) {
    QString authHeader = token.signUrl(url, QStringLiteral("GET"));
    (...)
}
 
void SigningExample::handleCredentialsNotFound() {
    qDebug() << "No credentials were found.";
}

The example hooks into various signals in the service, one for each possible outcome, and then calls the service’s getCredentials method to initiate the process. If successful, the credentialsFound signal is emitted with a Token value that is able to sign URLs, returning an HTTP header that can authenticate a request.

That same process is more straightforward when using the library from Go:

service := uoneauth.NewService(engine)
token, err := service.Token()
if err != nil {
        return err
}
signature := token.HeaderSignature("GET", url)

Again, this gets a service, a token from it, and signs a URL, in a “forward” way.

So the goal is turning the initial C++ workflow into this simpler Go API. A good next step is looking into how the NewService function is implemented:

func NewService(engine *qml.Engine) *Service {
        s := &Service{reply: make(chan reply, 1)}

        qml.RunMain(func() {
                s.obj = *qml.CommonOf(C.newSSOService(), engine)
        })

        runtime.SetFinalizer(s, (*Service).finalize)

        s.obj.On("credentialsFound", s.credentialsFound)
        s.obj.On("credentialsNotFound", s.credentialsNotFound)
        s.obj.On("twoFactorAuthRequired", s.twoFactorAuthRequired)
        s.obj.On("requestFailed", s.requestFailed)
        return s
}

NewService creates the service instance, and then asks the qml package to run some logic in the main Qt thread via RunMain. This is necessary because a number of operations in Qt, including the creation of objects, are associated with the currently running thread. Using RunMain in this case ensures that the creation of the C++ object performed by newSSOService happens in the main Qt thread (the “GUI thread”).

Then, the address of the C++ UbuntuOne::SSOService type is handed to CommonOf to obtain a Common value that implements all the common logic supported by C++ types that inherit from QObject. This is an unsafe operation as there’s no way for CommonOf to guarantee that the provided address indeed points to a C++ value with a type that inherits from QObject, so the call site must necessarily import the unsafe package to provide the unsafe.Pointer parameter. That’s not a problem in this context, though, since such extension packages are necessarily dealing with unsafe logic in either case.

The obtained Common value is then assigned to the service’s obj field. In most cases, that value is instead assigned to an anonymous Common field, as done in qml.Window for example. Doing so means qml.Window values implement the qml.Object interface, and may be manipulated as a generic object. For the new Service type, though, the fact that this is a generic object won’t be disclosed for the moment, and instead a simpler API will be offered.

Following the function logic further, a finalizer is then registered to ensure the C++ value gets deallocated if the developer forgets to Close the service explicitly. When doing that, it’s important to ensure the Close method drops the finalizer when called, not only to facilitate the garbage collection of the object, but also to avoid deallocating the same value twice.

The next four lines in the function should be straightforward: they register methods of the service to be called when the relevant signals are emitted. Here is the implementation of two of these methods:

func (s *Service) credentialsFound(token *Token) {
        s.sendReply(reply{token: token})
}

func (s *Service) credentialsNotFound() {
        s.sendReply(reply{err: ErrNoCreds})
}

func (s *Service) sendReply(r reply) {
        select {
        case s.reply <- r:
        default:
                panic("internal error: multiple results received")
        }
}

Handling the signals consists of just sending the reply over the channel to whoever initiated the request. The select statement in sendReply just ensures that the invariant of having a reply per request is not broken without being noticed, as that would require a slightly different design.

There’s one more point worth observing in this logic: the token value received as a parameter in credentialsFound was already converted into the local Token type. In most cases, this is unnecessary as the parameter is directly useful as a qml.Object or as another native type (int, etc), but in this case UbuntuOne::Token is a plain C++ type that does not inherit from QObject, so the default signal parameter that would arrive in the Go method has only a type name and the value address.

Instead of taking the plain value, it is turned into a more useful one by registering a converter with the qml package:

func convertToken(engine *qml.Engine, obj qml.Object) interface{} {
        // Copy as the one held by obj is passed by reference.
        addr := unsafe.Pointer(obj.Property("plainAddr").(uintptr))
        token := &Token{C.tokenCopy(addr)}
        runtime.SetFinalizer(token, (*Token).finalize)
        return token
}

func init() {
        qml.RegisterConverter("Token", convertToken)
}

Given that setup, the Service.Token method may simply call the getCredentials method from the underlying UbuntuOne::SSOService method to fire a request, and block waiting for a reply:

func (s *Service) Token() (*Token, error) {
        s.mu.Lock()
        qml.RunMain(func() {
                C.ssoServiceGetCredentials(unsafe.Pointer(s.obj.Addr()))
        })
        reply := <-s.reply
        s.mu.Unlock()
        return reply.token, reply.err
}

The lock ensures that a second request won’t take place before the first one is done, forcing the correct sequencing of replies. Given the current logic, this isn’t strictly necessary since all requests are equivalent, but this will remain correct even if other methods from SSOService are added to this interface.

The returned Token value may then be used to sign URLs by simply calling the respective underlying method:

func (t *Token) HeaderSignature(method, url string) string {
        cmethod, curl := C.CString(method), C.CString(url)
        cheader := C.tokenSignURL(t.addr, cmethod, curl, 0)
        defer freeCStrings(cmethod, curl, cheader)
        return C.GoString(cheader)
}

No care about using qml.RunMain has to be taken in this case, because UbuntuOne::Token is a simple C++ type that does not interact with the Qt machinery.

This completes the journey of creating a package that provides access to the ubuntuoneauth library from Go code. In many cases it’s a better idea to simply rewrite the logic in Go, but there will be situations similar to this library, where either rewriting would take more time than reasonable, or perhaps delegating the maintenance and stabilization of the underlying logic to a different team is the best thing to do. In those cases, an approach such as the one exposed here can easily solve the problem.

Read more
Inayaili de León Persson

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

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

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

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

First responsive prototypeFirst ubuntu.com responsive prototype.

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

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

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

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

Reading list

Read more
Inayaili de León Persson

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

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

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

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

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

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

Ubuntu Resources

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

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

Ubuntu Resources beta homepageUbuntu Resources homepage.

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

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

Phone gridThe phone grid.

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

Canonical.com

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

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

From this project, we took away:

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

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

Folded paper backgroundThe new folded paper background.

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

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

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

Reading list

Read more
Inayaili de León Persson

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

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

Web style guideWeb style guide front page.

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

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

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

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

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

The main goals of this exercise were:

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

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

The document started with the more broad and general rules:

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

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

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

We then moved on to forms rules:

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

And tables rules:

And finally JavaScript rules:

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

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

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

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

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

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

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

Reading list

Read more
Inayaili de León Persson

Making ubuntu.com responsive: intro (1)

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

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

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

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

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

We will be covering:

  1. Intro (this post!)
  2. Setting the rules
  3. Making the rules a reality
  4. Pilot projects
  5. Lessons learned
  6. Scoping the work
  7. Approach to content
  8. Making our grid responsive
  9. Adapting our navigation to small screens
  10. Dealing with responsive images
  11. Updating font sizes and readability
  12. Ensuring performance
  13. JavaScript considerations
  14. Testing on multiple devices

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

Read more
Tom Macfarlane

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

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

MWC_blog_1

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

MWC_blog_visual

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

CAN MWC Reception Desk RevA.vwx

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

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

MWC_blog_2

Read more
Daniel Oliver

New Apps header

The new apps header features max. 4 slots that can be arranged and combined in order to fulfil user needs in every screen.

Header_slots

Header’s values

We want to provide our users with the right amount of contextual information for them to know:

1- Where they are at (inside the app, in a particular view).

2- Where they can go inside the app in order to find content (navigate across different views).

3- What they can achieve in any given view (compose a message, crop a picture…).

The new header provides clarity by always showing the user where they are at, consistency by providing a way to navigate across main views inside the apps, and priority by surfacing the most important actions in every screen.

header_balance

Header’s elements

The elements are the building blocks of the header, the controls that can placed inside the slots mentioned above.

There’s different categories of elements and each of them have to be positioned carefully in the header in order to create slick experiences across our apps.

header_glossary

 

Title

One of the main values behind the new header is Clarity: we want the user to be clear about where they are at any moment.

That’s why the only mandatory element for our header is the title; you can leave some other slots empty, but every header has to have a title.

header_title

Tabs

A Tab is a control that allow users to navigate across views directly from the header.

The main views of your app are the different faces  in how content is organised and visualised.

header_telephonyExample: 

Our telephone app has two main views: Dialer and Contacts. Placing a tabs on the telephony header, allows users to toggle between this two views quickly.

Tabs placement

Place the tabs right to the title.

According to our interface values “right” means moving forward, and that’s what a tab precisely is, moving forward to the next view represented by the tab icon.

header_actions_tabs

Actions

Actions allow users to accomplish a direct goal in every screen (compose a message , edit, crop a picture…) Give priority to the actions that will be used more often and place them in the header.

header_AB

Example: Our address book app has a clear primary action which is add a new contact to the list.Placing that action straight to the header will make the user accomplish the goal quicker and smoother.

Actions placement

Place the actions right to the title as well.

header_actions_placement

In case you want to mix tabs and actions on the same header,  keep the tabs as close to the title as possible, creating a natural block to navigate across the views; place the actions after them.

header_actions_tabs

Back

After the main views of your app, subsequent views will use a back button in the header to navigate back to the main views. Back always returns to the previous view of an app, until the user reaches the main view again.

header_gallery

Example: Our gallery app has 3 main views: Photos, events and albums. Once the user gets to a detail view, the header of that view has a back button that returns the user to them main view where he came from.

Back placement

There’s only one place where you can place the back, and that’s the top left slot. According to our interface values, that’s a place where user has to intentionally stretch the finger and make an effort to trigger.

header_back_placementDrawer

So we’ve already introduced a few elements, but what happens when there’s not enough free slots on the header to place all your tabs and actions? Our solution is the drawer: an overflow where users will find all the controls not available straight on the header.

header_drawer_g

Example: Our gallery app has 3 main views: Photos, events and albums; and it also has the “take a picture” action on the header. In order to keep the header clear, we’ve decided to place the main views inside a drawer, and surface “take a picture” on the header. In this particular case, the drawer contains the main views of the app.

Inside the drawer

The drawer can contain some of the elements that couldn’t fit in the header’s slots. If  the drawer is placed on the top left slot, then it will contain tabs (main views); if the drawer is placed on the top right slot, then it will contain extra actions.

header_drawer

 

Drawer placement

The drawer works as a metaphorical extension of the header, so placing it at the first or last slot helps reinforce that idea.

header_drawer_placement

 

 

Search

Search is a special action that allows users to rapidly locate a desired piece of content. And since search can be a really important use case in apps, we are providing a special experience for it.Triggering search will refresh the standard header into a search header, displaying the osk at the same time, and removing the focus from the content. (for more information on search read search pattern)

header_search

Example: Our notes app presents search as one of the main action in the header. Once the user hits on the search icon the header transitions to the search header.

Search placement

There’s only one place in the header where you can place search: top right slot.

 

header_search_placement

 

Implication with the drawer:  In the scenario where you need a back button, a drawer and a search; the search will need to be kept in the top left slot in order to reinforce the search pattern across all our system.

 

header_search_p_2

Header layout

The four slots on the header can be arranged as follows:

Layout A

1 slot at the left of the title and max. 2 slots on the right

header_gallery_A

When to use it

  • You need to use a Back button in order to display detail screens for your app content.
  • Your app has a large number of main views and you need the drawer to display all of them.
  • You prefer to use the slots on the right to display actions, then you have to use a drawer to place the main views.

Layout B

max. 3 slots right to the title

header_telephony B When to use it

  • You don’t need a back button.
  • You want to place tabs at the right for the user to be able to switch views easily.
  • Most of the actions to be performed on the app are contextual (related to the content) and there’s no need to surface those actions on the header.

Behaviour

According to our user interface values, content is always the priority; that’s why the header is just a tool the disappears when users don’t need it. By scrolling down, the header will disappear. By scrolling up  the header will slide in again.

 

header_behavIt might be scenarios where users will need the header present at all times (i.e. Header with tabs) in that justified case, it’s possible to set the header fixed on the screen.

 

 

 

Read more
Michal Izydorczyk

Ubuntu 14.04 LTS wallpaper

Hey

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

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

wallpaper_blog_post

And here some examples of the things I was exploring…

wallpaper_blog_post

Read more
Mark Shuttleworth

Check out “loving the bottom edge” for the most important bit of design guidance for your Ubuntu mobile app.

This work has been a LOT of fun. It started when we were trying to find the zen of each edge of the screen, a long time back. We quickly figured out that the bottom edge is by far the most fun, by far the most accessible. You can always get to it easily, it feels great. I suspect that’s why Apple has used the bottom edge for their quick control access on IOS.

progresion

We started in the same place as Apple, thinking that the bottom edge was so nice we wanted it for ourselves, in the system. But as we discussed it, we started to think that the app developer was the one who deserved to do something really distinctive in their app with it instead. It’s always tempting to grab the tastiest bit for oneself, but the mark of civility is restraint in the use of power and this felt like an appropriate time to exercise that restraint.

Importantly you can use it equally well if we split the screen into left and right stages. That made it a really important edge for us because it meant it could be used equally well on the Ubuntu phone, with a single app visible on the screen, and on the Ubuntu tablet, where we have the side stage as a uniquely cool way to put phone apps on tablet screens alongside a bigger, tablet app.

The net result is that you, the developer, and you, the user, have complete creative freedom with that bottom edge. There are of course ways to judge how well you’ve exercised that freedom, and the design guidance tries to leave you all the freedom in the world while still providing a framework for evaluating how good the result will feel to your users. If you want, there are some archetypes and patterns to choose from, but what I’d really like to see is NEW patterns and archetypes coming from diverse designs in the app developer community.

Here’s the key thing – that bottom edge is the one thing you are guaranteed to want to do more innovatively on Ubuntu than on any other mobile platform. So if you are creating a portable app, targeting a few different environments, that’s the thing to take extra time over for your Ubuntu version. That’s the place to brainstorm, try out ideas on your friends, make a few mockups. It’s the place you really express the single most important aspects of your application, because it’s the fastest, grooviest gesture in the book, and it’s all yours on Ubuntu.

Have fun!

Read more
Daniel Oliver

Loving the bottom edge

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

Hmmm…. Feels good!

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

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

Be perfect, be yourself, be exciting

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

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

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

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

Progression

 

 

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

1. Make them connect smoothly

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

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

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

Some examples of great ranged gestures:

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

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

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

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

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

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

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

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

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

3. Make it visually sexy

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

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

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

4. Hint, reveal, commit

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

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

left edgeHint. Reveal. Commit.

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

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

Prioritise. Really, PRIORITISE

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

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

quick draw

Provide a visual cue

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

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

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

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

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

visual hint

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

Common patterns

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

Zooming out

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

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

zoom out

Toggle

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

2 faces

Controls

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

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

Quick draw

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

quick draw

Make it great!

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

 

 

 

 

 

Read more
Iain Farrell

Happy by Sergei Pozdnyak

The submissions process for Ubuntu 14.04 is now closed. If you’d like to look at the images head over to the Flickr Group. From here on a group of dedicated and splendid individuals will get together to select the images that are going to go into the next release of Ubuntu. We’ll be hanging out on #1404wallpaper on Freenode and you can come listen in :)

We generally welcome discussion but please remember that a decision is needed from the time that people volunteer so not too much additional debate.

We’ll start with a meeting tomorrow, Friday 7th March, at 19:00GMT.


Read more
Inayaili de León Persson

Ubuntu Resources — beta!

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

Feedback

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

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

1. Understanding which site you are visiting

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

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

New landing pages

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

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

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

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

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

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

Topic introsNew introductions to the topics.

Learnings from Canonical.com

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

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

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

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

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

Next steps

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

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

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

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

Read more
niemeyer

As originally shared on Google+, and as a follow up of the previous post covering OpenGL on Go QML, a new screencast was published to demonstrate the latest features introduced around OpenGL support in Go QML:

Refrences:

Read more
Katie Taylor

App Design Clinic #8

This week we dedicated the short clinic to sizing, and ensuring widgets and items are usable (touchable).

We covered…

  • The Ubuntu grid unit – for more information, see http://developer.ubuntu.com/api/qml/sdk-1.0/UbuntuUserInterfaceToolkit.resolution-independence/)
  • Minimum touch target size – 4×4 gu
  • A sneak preview of the updated widgets coming to Ubuntu Touch

If you missed it, or want to watch it again, here it is:

 

 

The next App Design Clinic will on Wednesday 26th February. Please send your questions and screenshots to design@canonical.com by 1pm UTC on Tuesdays to be included in the following Wednesday clinic.

Read more
Katie Taylor

App Design Clinic #7

This week in App Design Clinic #7 we reviewed 3 apps: SocketWorld (for finding and comparing plug types), Flashback (an entertainment app using Trackt) and Capitals (a game about capital cities).

For this session we covered questions such as
- First use prompting and introductions
- Margins and alignment
- App structure, linking from one part of your app to another

If you missed it, or want to watch it again, here it is:

 

 

Please send your questions and screenshots to
design@canonical.com by 1pm UTC on Tuesdays to be included in the following Wednesday clinic.

The next App Design Clinic will be in 2 weeks, on Wednesday 12th February.

Read more
Bejan Alizadeh

Sheets transition

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

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

Step by step


Video: Sharing a photo in photo gallery mode

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

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

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

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

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

Your feedback

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

Read more
Inayaili de León Persson

New year, new website: the new canonical.com

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

The brief

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

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

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

The journey

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

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

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

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

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

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

Sketching ideasGenerating ideas: some of our sketches

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

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

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

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

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

The result

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

Read more