Canonical Voices

Posts tagged with 'featured'

Inayaili de León Persson

The new Ubuntu Resources

Today we’ve launched the alpha version of our latest project: the Ubuntu Resources website.

This is our first responsive project that follows the mobile-first methodology and we’re very excited to share this with everyone!

As you’ll be able to see, we’re not quite done with it yet, but we wanted to share what we’ve created so far, so we can get feedback and keep improving the design and expanding the features.

Ubuntu Resources on a phoneThe new Ubuntu Resources on an Ubuntu-powered phone

A little bit of background

This project grew from the need to separate content like case studies, news, press releases and events, from the core of the Canonical and Ubuntu sites — and it will eventually replace much of what currently is at insights.ubuntu.com. As the site is designed for reading and engaging with longer pieces of content, we thought it would be the ideal place to explore mobile-first and responsive approaches. And we plan to use what we’?ve learned from it to make www.ubuntu.com and our Web Style Guide responsive.

Scaling things down

We started the research phase taking a holistic view of the project, trying to understand what types of content and users we wanted to target. We realised that with limited time and resources we would have to divide the project into different releases, so that we could make sure each aspect of the site was given the attention it deserved.

The first and current release of the site — alpha — focuses solely on small screens. The main goal is that all the content is accessible and the visual style and features will be progressing and being added as we go.

WireframesInitial wireframes across a variety of screen sizes

Reusing existing styles

One of the challenges in this project was deciding how we were going to integrate the existing Web Style Guide, which we’ve been using internally for a while now and will be made public on design.ubuntu.com soon.

Ubuntu Web Style GuideSneak peek of our Web Style Guide

We decided to use a minimal version of the style guide that kept the Ubuntu Resources’ style coherent with www.ubuntu.com and that we could improve on.

You’ll also notice small details that align with our phone design, like the grid, navigation selection and icons, and we’ll be adding even more in the upcoming releases.

What’s coming

Apart from working on the larger screen versions of the site, some of the things we will be looking into for the next iterations are:

  • the ability to subscribe to different types of content
  • more curated topic landing pages
  • content filtering and sorting
  • cleaner URLs
  • the way we handle PDFs and other file formats
  • more content like a press section

Go and have a look at the site and let us know your thoughts. We want to know what you like and what you think can be improved, or any other comments you might have — we’ve included a handy link to the feedback form at the bottom of every page. Enjoy!

Read more
Christina Li

November Brown Bag lunch

Some of us in the Design team have been gathering on a monthly basis to have lunch together and share things we find interesting to us.

Today, I’d like to share with you the Brown Bag lunch we had this week.

Vesa shared with us his interest in photography and showed us some of the shots he took over time.

9690256316_8c4040a4bb_bWestminster at night by Vesa (flickr)

I came across an inspiring research done by Helen Hamlyn Centre for Design at the Royal College of Art in London. The research focused on facilitating older people using mobile phones, rather than designing a simpler phone for them to use.

And, our challenge of the month was to build the tallest paper tower! Each team had 20 pieces of paper and 6 minutes, with 2 rules:

1. You can only use paper to build your tower
2.You can tear or fold the pieces of paper.

Well, I’m happy to report that Rachel, Vesa and Olga proudly won this challenge with their paper tower!

photo (2)

How would you build your tower in 6 minutes?

Read more
Tingting Zhao

In the previous post, we talked about how to design effective user testing tasks to evaluate the usability of an interface. This post continues with this topic by highlighting a number of key strategies that you may need to use when conducting a formative user testing, whose main aim is to identify usability problems and propose design solutions, rather than compare quantitative metrics (summative testing), eg. task completion time and mouse clicks. It is unlikely that the prepared task script could be strictly applied without any changes, since the testing situation tends to be dynamic and often unpredictable. To get useful data, you need to be able to manipulate your task script with flexibilities, while also maintaining consistency.

Changing task orders during testing

Normally, to avoid order effect, the issuing of the tasks should be randomised for each participant. Order effect refers to the effect in which the tasks are presented, which can affect the results, specifically: users may perform better in later tasks as their familiarity with the interface increases; or users may perform worse as they become more fatigued. However, as discussed in the previous post, the tasks are often contextual and dependent on each other, so you need to carefully consider which tasks could be shuffled. For example, it is a good practice to mark on the script to indicate dependent tasks, so that you know these tasks should not be reordered and separated from each other. In other words, the dependent tasks must always be moved together. It is worth noting that the randomisation of task orders may not always be possible for a testing, for example, when the tasks are procedurally related, such as a testing focusing on payment flow.

Sometimes you may need to change the task orders by considering their levels of difficulty. This is useful in the following two scenarios: when you notice a participant appears to be slightly nervous before the testing has started, provide a simple first task to put him/her at ease; or when you observe a participant has failed to solve several tasks in a row, provide one or two easy tasks to reduce the frustration and stress, and boost confidence.

Another type of changing task order is made in response to users’ solicited goals that are associated with a coming task. For example, in one phone testing, after a participant checked the battery level, s/he spontaneously expressed a desire to know if there was a way to switch off some running apps to save battery. In this case, we jumped to the task of closing running apps, rather than waiting until later. This makes the testing feel more natural.

Remove tasks during testing

There are typically two situations that require you to skip tasks:

  • Time restriction

  • Questions being answered with previous tasks

Time restriction: user testing normally has a time limit. Participants are paid for certain lengths of time. Ideally, all the tasks should be carried out by all the participants. However, sometimes they take longer to solve tasks. Or you may discover areas that require more time for investigation. In this case, not all the tasks could be performed by a participant within the given time. Subsequently, you need to be able to quickly decide which tasks should be abandoned for this specific participant. There are two ways to approach this:

  • Omit tasks that are less important: it is always useful to prioritise the tasks in terms of their importance – what are the most important areas that have key questions that need to be answered and require feedback; what could be left for the next testing, if not covered this time?

  • Omit tasks that have already received abundant feedback: skip the tasks from which you have already gathered rich and useful information from other participants.

Questions were answered with previous tasks: Sometimes questions associated with a specific task would be answered while a participant was attempting to solve the previous task – in this case, you could skip this task.

In one of our phone testings, we asked a participant to send a text to a non-contact (a plumber). During the task-solving process, s/he decided to save the number to the contact book first and then send a text. In this case, we skipped the task of ‘saving a number to contact book’.

However sometimes you should not skip a task, even if it might seem repetitive. For example, if you want to test the learnability and memorability of a feature, having the participant perform the same task (with slightly different descriptions) for the second time (after a certain time duration) could afford useful insights.

Add tasks during testing

There are three contexts in which you could consider adding tasks:

  • Where the user formulates new goals

  • Re-examinations

  • Giving the user a second chance

The added task must be relevant to the aim of the testing, and should only be included if the testing time permits.

User formulates new goals: you could add tasks based on user-formulated goals in the task solving process.

For example, in one phone testing, one participant wondered if s/he could customise the tiles on the Windows phone’s home screen. We made this an added task for her/him. Adding tasks based on user articulated new goals follows their thought process and make the testing more natural. It also provides opportunities for us to discover new information.

Re-examinations: sometimes the users may succeed in a task accidently, without knowing how s/he did it. In this case, the same task (with a slightly changed description) could be added to re-assess the usability.

For example, in one phone testing, we had one task: “You want to call you sister Lisa to say thank you for the phone”. One participant experienced great difficulties in performing this task, and only completed it after a long time and by accident. In this case, we added another task to re-evaluate the ease of making a phone call:

“Your call is cut off while you are talking to your sister, so now you want to call her again.”

Similarly in the Gallery app testing, where participants managed to add a picture into a selected album accidently, we asked them to add another picture into a different album.

Re-examination allows us to judge accurately the impact of a problem, as well as to understand the learnability of interface – the extent to which users could detect and learn interaction patterns (even by accident), and apply the rules later.

Giving the user a second chance: in the majority of the user testing, participants used the evaluated interface for the first time. It could be very demanding for them to solve the tasks successfully in their first attempt. However, as the testing progresses, participants might discover more things, such as features and interaction patterns (although possibly by accident). Consequently, their knowledge of the interface may increase. In this case, you could give them another chance to solve the task that they failed earlier in the tests. Again, this helps you to test the learnability of the interface, as well as assess the impact of a problem.

For example, in a tablet testing, one participant could not find the music scope earlier in the testing, but later s/he accidentally discovered the video scope. To test if s/he now understood the concept of dash scopes, we asked the participant to find the music scope again after several other tasks.

Change task descriptions (slightly) during testing

Information gathered from pre-testing brief interview and participants’ testing verbal data could often be used to modify the task description slightly to make the task more realistic to the users. This also gives the user the impression that you are an active listener and interested in their comments, which helps to build a rapport with them. The change should be minor and limited to the details of the scenario (not the aim of the task). It is important that the change does not compromise the consistency with other participants’ task descriptions.

For example, in a tablet testing, where we needed to evaluate the discoverability of the HUD in the context of photo editing, we had this task: “You want to do some advanced editing by adjusting the colour of the picture.” One participant commented that s/he often changed pictures to ‘black and white’ effect. In response to this, we changed the task to “You mentioned that you often change a picture to black and white, and now you want to change this picture to ‘black and white’”. The task change here does not change the aim of the task, nor the requirements for solving the task (in this case, the access to the HUD), but it becomes more relatable to the participant.

Another example is from a phone testing. We changed the task of “you want to go to Twitter” to “you want to go to Facebook” after learning the participant uses Facebook but not Twitter. If we continued to request this participant to find Twitter, it would make the testing become artificial, which would result in invalid data. The aim of the task is to evaluate the ease of navigation in finding an app, therefore changing Twitter to Facebook does not change the nature of the task.

Conclusions

This post outlines a number of main strategies you could use to modify your task script to deal with typical situations that may occur in a formative user testing. To sum up:

Changing tasks orders: randomise tasks for each participant if possible, and move the dependent tasks as a whole; consider the difficulties of the task and issue an easy task to start with if you feel participant is nervous, or provide an easy task if participants failed several tasks in a row. Allow them to perform a later task if they verbalise it as a goal/strategy for solving the current task.

Remove tasks: if time is running out with a particular participant, omit certain tasks. This could be tasks with low priorities; tasks that already have enough feedback from other participants; or tasks the participant has already covered while attempting a previous task.

Add tasks: if time permits, allow users to perform a new task if it is a user initiated goal and is relevant to the testing; repeat a task (with slightly different wording and at an appropriate time) if the user succeeds in a task accidently, or has failed this task earlier, or if the aim is to test the learnability of the system.

Change task description: slightly amend the details of the task scenario (not the aim of the task) based on users’ verbal data to make it more relatable and realistic to the user. This will improve the reliability of the data.

If you have other ways to maneuver the tasks during the testing session, or have situations you are unsure about, feel free to share your experience and thoughts.

Read more
Anthony Dillon

I was recently asked to attend a cloud sprint in San Francisco as a front-end developer for the new Juju GUI product. I had the pleasure of finally meeting the guys that I have collaboratively worked with and ultimately been helped by on the project.

Here is a collection of things I learnt during my week overseas.

Mocha testing

Mocha is a JavaScript test framework that tests asynchronously in a browser. Previously I found it difficult to imagine a use case when developing a site, but I now know that any interactive element of a site could benefit from Mocha testing.

This is by no means a full tutorial or features set of Mocha but my findings from a week with the UI engineering team.

Breakdown small elements of your app or website its logic test

If you take a system like a user’s login and register, it is much easier to test each function of the system. For example, if the user hits the signup button you should test the registration form is then visible to the user. Then work methodically through each step of the process, testing as many different inputs you can think of.

Saving your bacon

Testing undoubtedly slows down initial development but catches a lot of mistakes and flaws in the system before anything lands in the main code base. It also means if a test fails you don’t have to manually check each test again by hand — you simply run the test suite and see the ticks roll in.

Speeds up bug squashing

Bug fixing becomes easier to the reporter and the developer. If the reporter submits a test that fails due to a bug, the developer will get the full scope of the issue and once the test passes the developer and reporter can be confident the problem no longer exists.

Linting

While I have read a lot about linting in the past but have not needed to use it on any projects I have worked on to date. So I was very happy to use and be taught the linting performed by the UI engineering team.

Enforces a standard coding syntax

I was very impressed with the level of code standards it enforces. It requires all code to be written in a certain way, from indenting and commenting to unused variables. This results in anyone using the code, being able to pick up it up and read it as if created by one person when in fact it may have contributed by many.

Code reviews

In my opinion code reviews should be performed on all front-end work to discourage sloppy code and encourage shared knowledge.

Mark up

Mark up should be very semantic. This can be a case of opinion, but shared discussion will get the team to an agreed solution, which will then be reused again by others in the similar situations.

CSS

CSS can be difficult as there are different ways to achieve a similar result, but with a code review the style used will be common practise within the team.

JavaScript

A perfect candidate as different people have different methods of coding. With a review, it will catch any sloppy or short cuts in the code. A review makes sure  your code is refactored to best-practise the first time.

Conclusion

Test driven development (TDD) does slow the development process down but enforces better output from your time spend on the code and less bugs in the future.

If someone writes a failing test for your code which is expected to pass, working on the code to produce a passing test is a much easier way to demonstrate the code now works, along with all the other test for that function.

I truly believe in code reviews now. Previously I was sceptical about them. I used to think that  “because my code is working” I didn’t need reviews and it would slow me down. But a good reviewer will catch things like “it works but didn’t you take a shortcut two classes ago which you meant to go back and refactor”. We all want our code to be perfect and to learn from others on a daily basis. That is what code reviews give us.

Read more
Rosie Zhu

Since we released the initial demo of Ubuntu on phones, we’ve been looking at refining the whole Suru theme — the theme on Ubuntu for phones and tablets — and creating visual guidelines for it.

Two of the things that we evolved were the treatment of the indented style and the corner size of the Ubuntu shape — the squircle. We wanted to make sure these were consistent across the theme so that any designer and developer could follow the same guidelines.

The Ubuntu squircle shapeThe Ubuntu squircle shape

Explorations

There were lots of discussions about what kind of shadows we should use — blurred shadows, sharp shadows or a combination of the two — to represent the indented style, and we went through various iterations.

Variations on grey backgroundVariations on grey

Soon after we started looking into the indented style we decided to look at the corner size of the shape at the same time, as they work together. Since the squircle is not an ordinary shape, it can’t just be scaled up and down as needed, so we arrived at four different corner sizes that can be used in the different sizes necessary across the theme.

The four different corner sizes of the Ubuntu shapeThe four different corner sizes of the Ubuntu shape

One of the main goals for the shadows was to make sure they worked with different images inside the shape and on different backgrounds. We also needed to consider the pressed state of the shape, which has a bigger shadow inside.

Variations of icon on different backgrounds in the normal and pressed statesVariations of Maps icon on different backgrounds in the normal and pressed states

When the shape is used, it’s not always indented (like in popovers and notifications), so we also had to study these variations too.

Final styles

And finally after many iterations, discussions and reviews, here are the current styles of the indented and non-indented shapes.

Telephony icon on different backgroundsTelephony icon on different backgrounds

We’ve started to put these guidelines on design.ubuntu.com, where you can follow their evolution.

Read more
Luca Paulina

Over the last year we have been working on the Juju GUI to reach a broader audience. Juju is a way of building complex cloud environments. It connects different services, allows complex configuration and the ability to scale out quickly and easily. Juju is offered as a command line tool or as a GUI on the web.

The team

For the last 6 months a small dedicated team has been working together to push the design of the Juju GUI forward. The design team consists of 2 user experience designers, Alejandra and Luca, and 2 visual designers, Jamie and Spencer. The project has raised many questions and one of them was what it is like designing a product you don’t use. In this blog post Jamie and Luca attempt to clarify our process.

No assumptions

Luca: As a user experience designer part of my process is to create assumptions to further thought, design and development, these are later validated in interviews with stakeholders, user testing or with the development team. An assumption is something that is generally accepted as being true without proof. I’ll never be a direct user of Juju, therefore creating assumptions for the type of audience that the Juju GUI is designed for is an interesting challenge.

To help build assumptions, ideate and create cohesive user flows that will later be tested I’ve had to run planned and impromptu workshops, ask questions, have daily hangouts with the development team,  run week long sprints, ask more questions and lock myself away in the Juju war room to immerse myself in the world of Juju.

Juju_war_room

Jamie: From a visual perspective this digital product is unlike anything that I’ve worked on in the past. Whereas some rules of typography, hierarchies and readability apply to the design I’ve found myself a lot more focussed on subtle detailing and refinements than ever before. This is because users of the GUI are wanting to complete tasks, they want to be able to deploy their environments as quickly and painlessly as possible. So the design job became about helping them do that without the GUI getting in the way. It is intended to lay lightly across the canvas, aiding users when they need and not obstructing them when they don’t.

Juju GUIThe Juju GUI

Extensive and continuous research

Luca: I’m always surprised by the sheer amount of complexity that the GUI entails. The varying needs of our core target audiences means that we have to conduct a lot of research when we create user flows, ideas and when we’re examining if a feature is needed. Thankfully we have a great user research team which helps find users, conducts the testing and helps interpret the results.

I’ve found that with this particular product the interpretation of feedback has been key to making sure our designs resonate with our users. The feedback is catalogued in a document and shared out amongst the development teams to gain their insights and ideas as well. Solutions are then ideated and the design team then acts upon them creating new designs.

Jamie: The user testing results and feedback from the community has been key to the development of the visual style for the GUI. We’ve been through numerous rounds of testing to get to this stage of design development and each round of tests has moved the design forward. Once a round of testing has been completed the team will review the findings and create design tasks to solve any issues highlighted by the testers. The users we’ve tested with have been high-level cloud architects and system administrators, so familiar with the type of tasks that the GUI performs just not familiar with the way in which we perform those tasks in the GUI. Assumptions we’ve made about the way they would use the GUI have sometimes been mistaken so the design really has been guided by the users.

Juju GUI design evolutionEvolution of Juju’s interface

Constant validation from a multidisciplinary team

Luca: Throughout the project the need for validation on concepts and ideas has been incredibly important. The agile process we use allows us to create wireframes and designs quickly and get them in front the dev team and get their insight and feedback, we’re lucky enough to have a near 24 hour working cycle (Teams in Europe, North America and Australasia). Because of this it’s not uncommon for a design to go through many iterations in a week, for example; the inspector wireframes (pictured below) went through 9 revisions in 10 working days, the complexity of the inspector design and experience was refined and finessed collaboratively with the development team, this has turned the inspector into an integral and very powerful part of the GUI.

Juju inspector wireframesDetailed wireframes for the inspector

Jamie: Working within an agile process has meant that design decisions are required to be made quickly and collaboratively within the team. The design team in London is small so we can share work internally and move designs on sometimes multiple times a day. This means we’re able to keep up with the development cycle that releases every 2 weeks and means that users can see the design evolve far faster than waiting for a yearly or biannual release of the product. As a designer it’s been hard seeing the product not pixel perfect when it’s released but we’re working hard to craft, fine-tune and round the edges of it so it will be a beautiful thing to use and interact with each new release.

Inspector designVisual iterations of the inspector

Questioning language and terminology

Luca: Juju is expanding into a new field of creating clouds by managing services not machines. This means that there really isn’t a language framework that we can rely on and one thing that has been apparent over the last 6 months is the importance of terminology and language for developers. At the beginning of the project it was difficult and time consuming to learn the established vocabulary associated with the cloud and Juju, this gave us a great reason to start questioning words and terms used throughout the GUI. We uncovered words that were already established in other web services and words that didn’t connect with the user. Questioning these words and terms made it clear that not only do we (as non-users) not understand but this would also happen with users and it allowed us to finesse the language in the GUI to something more appropriate.

Good design principles and patterns

Jamie: The GUI is not just the work of the Cloud team. To harmonize the look of the products in the Canonical stable we’ve worked closely with the design team developing the phone OS looking for ways that design patterns developed by them can be applied to the Juju GUI. We’ve also worked with the Web team to see where we can integrate any elements from their UI library. The GUI is a product but it’s not a mobile OS and equally we interact with it in a desktop web browser but it’s not a website, so it ultimately has to have it’s own look. But by pooling the collective design wisdom of the teams who have been crafting interactions in their specific fields and by using patterns and guidelines already defined in this space we can create a interface that is better than the sum these parts but with it’s own clear voice.

Good design practices

Jamie: We like to sketch here. We sketch everything out before any work is done on screen and it’s enormously useful in iterating quickly through problems that users have and trying to come up with multiple solutions to these in a collaborative way. With a small team we can sketch our way through multiple problems towards multiple solutions and then move into applications like Photoshop and Illustrator once we’ve got a clear direction of the UX. This fast way of working also allows us to keep pace with the development cycle and to be able to add features to the GUI each time we do a release. Once a feature of the GUI is open to the world we’ll gather feedback then it’s back to the drawing board to refine it.

Isle of Man workshopUX sketching during a recent sprint

Playing to our strengths

Luca: Most of the processes to provision, create and manage services in the cloud are currently carried out via command line. A priority for us has been to think about how we can use visual language to provide a layer of information and understanding not readily available via the command line. As designers we understand that with colour, structure, layout and flow we can communicate the status of a system or process in a very powerful way. We have made it our goal to bring out the strengths of the GUI by exploring visual metaphors and relationships. We established that the command line is an input output tool, the GUI doesn’t have that type of interaction and offers a more holistic approach, we offer that by having a clear hierarchy and having concise user flows. Early on in the project we made a principle to not compete with the command line but to embrace it, there are users out there who will use Juju just as a command line tool or as the GUI or a mix of both.

Charm-iconsPlayful icons helps users navigate the GUI

Final thoughts

Pretty much everyone in the team has been involved in the conceptual stage of the project, this has helped us create a cohesive product with some really powerful features. I’m sure there are a lot of designers out there working on designs for products that they won’t end up using. We wanted to take the time to highlight how we’ve approached this problem while we’ve been working on the Juju GUI project. The coming months will see a redesign of the the navigation bar, notifications, service blocks and relationship lines. We’ve given you a preview of some of these features in the visuals above.

Read more
Katie Taylor

Wednesday App Clinic – Update

Over the last few weeks, we’ve enjoyed running 2 Wednesday App Clinics. Thanks to all those who sent us their apps and questions. It’s been a fantastic response! It certainly has helped us to see how you’ve been using the design guides and the components, and I hope it has helped you.

The first clinic started with an introduction and then feedback on a Brad Wells’ Blackjack app, and Marcin Le?niowski’s Skydiving logbook app. The second clinic included Michael Zanetti’s GetMeWheels, Daniel Beck’s RamSamSam RSS reader and Szymon Waliczek’s uShopper shopping list apps.

Screenshot from 2013-09-26 10:22:43

If you would like feedback or to ask a particular question (and to see your app featured!) send a screenshot or link to design@canonical.com before 1pm UTC on Tuesday.

To watch previous clinics go to the Ubuntu OnAir youtube channel at http://www.youtube.com/UbuntuOnAir.

The clinics are on Wednesdays at 1pm UTC at http://ubuntuonair.com/ . Join us (or watch later) to find out more.

Read more
Katie Taylor

Since Ubuntu touch was announced, its been fantastic to see the variety of apps you’ve been developing, from shopping lists to word games, to apps that aid your daily commute.

As the Ubuntu Touch platform gets bigger and better, myself and the design team have been receiving more requests for feedback on designs, as well as questions about the App Design Guides and general app design. And although we are available for conversations on irc and in the email lists, what’s been missing is a place to have a more in-depth and visual conversation about app design.

Starting this Wednesday the design team will host a weekly app design clinic on Ubuntu On Air. The clinic is a chance for you to get feedback on your app’s UI, and a forum for you to ask questions about interactions, the Ubuntu brand and guidelines, visual styles, typography, colour… anything design that you want to ask.

If you would like feedback on a particular design, send a screenshot or mockup of your design to design@canonical.com before 1pm UTC on Tuesday.

The first clinic will be this Wednesday 11th September at 1pm UTC at http://ubuntuonair.com/ . Join us (or watch later) to find out more.

Read more
Lisette Slegers

Music app: focus on the content

Music apps that allow users to switch between player and queue mode can be quite complex. Some challenges of music apps in general:

  • Deep navigation through the music library:
    Home › Artists › Artist › Album › Play queue
  • Switching between play queue and library

And a challenge unique for the Ubuntu phone:

Tabs

The Ubuntu Music app is all about your music collection. The home screen shows a list of recently played items and the musical genres in your collection. It is easy to find your way around with the tab navigation.

Navigate to an album

Let’s open one of the albums.

Open an album

Player

Tap on a song to start playing it and enter the player view. This view combines full album art of the item that is currently playing, and a queue of all previous and next items. There are play controls in the toolbar at the bottom of the screen.

Play a song

Queue

For the next example of what you can do with the queue, let’s imagine that we have already queued up a lot more songs from various albums.

Scroll down the list to see what’s coming up in the queue. When our focus changes from the current song to the rest of the queue, the toolbar with play controls contracts. A hint of a progress bar stays on the screen; not to interact with, but as a visual hint to show something is playing and as a reference to where the play controls are.

See what's next in the queue

Users can remove songs from the queue by swiping, and move songs to a different position in the queue with drag and drop.

Bring up the toolbar with play controls to refocus on what is playing now. As the toolbar is swiped up, the queue moves back to the current item.

Back to the currently playing song

Back to the library

The user can go back to their library to find more songs to queue. Patterns for back and overflow in the toolbar are still in development so check the App design guides to find out how exactly this will work.

Back to the library

Back in the library view, we again see a hint of the progress bar to show that items are in the play queue. We bring up the toolbar and see the condensed play controls. The toolbar lets users tap play or pause on the current song, tap on the album art or song title to return to the player view, and open up the overflow actions.

Back to albums

We navigate to another album.

Open another album

Item options

To keep our focus on play controls in the toolbar and keep the toolbar as light as possible, item actions are grouped with the item and accessible via the expansion pattern. This goes for library albums and songs and queued songs. We can queue another song of the album we are looking at with the song options.

Add a song to the queue

What’s next

This is the basic UX concept for the music app. Visual design will play a big part in deciding what exactly goes where, and we will need to test if the controls are easy enough to access. Coming soon are some exciting visuals to connect the dots.

Read more
Tingting Zhao

Previously, Charline Poirier provided an excellent post about how to recruit representative participants for usability testing. To continue the story, we are going to talk about the next stage: developing effective task sets, which is a crucial part of a test protocol.

We conduct usability testing iteratively and throughout the product life cycle. The testing interface could range from being as simple as paper images, to clickable prototypes, to a fully working system.

In order to assess the usability of an interface, we ask users to carry out a number of tasks using the interface. We use tasks that resemble those that users would perform in a real life context, so that the data we collect is accurate. In other words, the user behaviour we observed is representative, and the problems we found are those that users would be likely to encounter.

 

Design testing tasks – ‘a piece of cake’?

 

When I first learnt about usability testing, I thought: ‘It’s simple: you just need to write some tasks and ask people to solve them, and done!’ But after conducting my first ever usability testing, I realised this was not the case.  I had so many questions: I wasn’t sure where to start or what tasks should be used, and there were numerous details that needed to be thought through. You need to carefully craft the tasks.

Now, having conducted hundreds of usability testings, I would like to share my experience with you about how to design effective tasks. There are three main stages involved:

  • Decide on the tasks

  • Formulate the tasks

  • Be tactful in presenting the order of the tasks

 

Stage 1: Decide on the tasks

Before you sit down to compose a set of tasks, you are likely to go through the following stages:

  • Clearly establish the goal of the testing: specifically what are the main features/areas that require feedback. When we conduct testing, we always have a face to face meeting with the design team to understand their focus and needs.

  • ‘Walkthrough’ with the design team: If testing an early prototype that has not been fully implemented, it’s important to go through the prototype with the designers so that you are aware of how it works, what is working and what is broken.

  • Inspection : go through the test interface at least three times. The first time to get an idea of the general flow and interaction of the interface; the second time to ‘put on the user’s hat’, and examine the interface by thinking about what users would do, and pay attention to any possible difficulties they may experience. This is the stage where you could start to write down some of the potential tasks you could use, which cover the features you need to assess, and the predicted problematic areas; and the third time, you should focus on developing tasks when you are going through the interface again. This gives you the opportunity to evaluate the tasks you identified, and add or remove tasks. By the end, you will have a number of potential task banks to work on.

Dumas and Fox (2008, p1131) provide a very good summary of the kind of tasks that are likely to be involved in usability testing. It is in line with those that we used in our testing sessions in most contexts. These include:

  • tasks that are important, such as frequently performed tasks or tasks that relate to important functions;

  • tasks where evaluators predict users will have difficulties;

  • tasks that enable a more thorough examination of the system, such as those that can only be accomplished by navigating to the bottom of the system hierarchy, or tasks that have multi-links or shortcuts;

  • tasks that influence business goals;

  • tasks that examine the re-designed areas;

  • tasks that relate to newly-added features.

For this step, you don’t need to worry about how to phrase the task descriptions, but make sure all areas that you need to investigate are covered by your tasks.

Stage 2: Formulate the tasks

How well the tasks are formulated determines the reliability and the validity of the usability testing and the usefulness of the data. It’s crucial to get this right. You should consider:

  • The formats of tasks to be used
  • The articulation of the tasks

The formats of tasks

The tasks could be categorised into two main formats:

  • Direct tasks or Scenario tasks

  • Open-ended or Closed task

You need to decide what should be used, and when.

Scenario task or Direct task

A scenario task is presented as a mini user story: often it has the character, the context and the necessary details for achieving the goal. For example, to test the browser and bottom menu on the phone:

You are holding a dinner party this Saturday. You want to find a chicken curry recipe from the BBC food site.

A direct task is purely instructional. For instance, to use the above example:

Find a chicken curry recipe from the BBC food site.

Among these two types, we often use the scenario tasks in the testing. This is because it emulates real-world context that participants can easily relate to, and consequently they are more likely to behave in a natural way. This helps to mitigate the artificiality of user testing to a great extent.  The closer they are related to the reality, the more reliable the test results can be (eg. Rubin, 1994; Dumas and Fox, 2008). In addition, some research (eg. Shi, 2010) shows that the scenario tasks work more effectively with Asian participants.

Interesting research: for Indian participants, Apala Lahiri Chavan’s research (Schaffer, 2002) shows that using a ‘Bollywood’ style task would elicit more useful feedback. For example:

Your innocent and young sister is going to get married this Saturday, and you just get a news the prospective groom is already married! So you want to book a flight ticket as soon as possible to find your sister and save her.

The researchers found that Indian participants feel reluctant to make criticisms to the unfamiliar facilitator, but once they phrased the task in a film-like story, the participants became more talkative and open.

Closed task or Open-ended task

 A closed task is specific to what the participants need to do. This type of task has one correct answer, and therefore allows us to measure if participants solved or failed a task. It is the most commonly used format. For example, to test the telephony on the phone:

 You want to text your landlord to say you will give her the rent tomorrow. Her number is: 7921233290.

An open-ended task contains minimum information and less specific direction as to what you want a participant to do. It gives users more freedom to explore the system. This is particularly useful if you want to find out about what areas users would spontaneously interact with, or which ones matter most to them.

For example, in our Ubuntu.com testing, designers wanted to understand what information was important for users to get to know about Ubuntu. In this case, an open-ended task would be appropriate. I used the task:

 You heard your friends mention something called ‘Ubuntu’. You are interested in it and want to find out more about what Ubuntu is and what it can offer you?

There are three main limitations  of using open-ended tasks:

  • Since participants have control over the task, features that require user feedback might be missed; or vise versa, they may spend too much time on something that is not the focus of the testing. The remedy would be to prepare for a number of closed-tasks, so if certain features are not covered by the participants, these could be used.

  • Some participants may experience uncertainty as to where to look and when they have accomplished the task. Others may be more interested in getting the test done, and therefore do not put in as much effort as what they would in reality.

  • You cannot assign task success rates to open-ended tasks, as there is no correct answer, so it is not suitable if a performance comparison is needed.

The articulation of the tasks

  • Avoid task cues that would lead users to the answers. Make sure the tasks do not contain task solving related actions or terms that are used on the system. For example, in the Juju testing we wanted to know if participants understood the ‘browse’ link for browsing all the charms. We asked participants to find out the types of charms that are available instead of saying ‘you want to browse the charms’.

  • Be realistic and avoid ambiguity. The tasks should be those that would be carried out in the real context, and the descriptions should be unambiguous.

  • Ensure an appropriate level of details. It should contain just enough information so that participants understand what they are supposed to do, but not too much that they are restricted from exploring naturally in their own way. The description of context should not be too lengthy, otherwise participants may lose their focus or forget about it. When closed tasks are used, make sure they are specific enough, so it is clear to the participants as to when they would accomplish their goals. For example, compare the description of ‘You want to show your friends a picture’ to ‘You want to show your friends a picture of a cow’ – which one is better? For the former, the goal is more vague and participants would be likely to click on the first image or a random picture, and assume the task is done. As a result, we might miss usability problems. For the latter,  the task communicates the requirements more effectively: it would be accomplished once they found the picture of a cow. Furthermore, it also provides us with more opportunities to assess the navigation and interaction further, as participants need to navigate among the pictures to find the relevant one.

 

Stage 3: Be tactful in presenting the order of the tasks

In general, the tasks are designed to be independent from each other for two reasons: to grant flexibility in terms of changing the orders of the tasks for different participants; and to allow participants to continue to the next task, even if they failed the previous one.

However, in some contexts, we use dependent tasks (proceeding on to one task depends on whether or not participants solved another task successfully ) on purpose, for instance:

  • When there is a logistic flow involved and the stages of procedures must be followed. To use a very simple example, in order to test account ‘log in’ and ‘out’, we need a task for ‘log in’ first, and then a task for ‘log out’.

  • When testing ‘revisiting’/’back’ navigation (eg. if participants could navigate back to a specific location they visited before) and multitasking concepts (eg. if participants know to use the multitasking facility). For example, when testing the tablet, I had the tasks as follows:

You want to write down a shopping list for all the ingredients you need for this recipe using an app

Here, the participants will need to find the note app and enter ingredients.

Then I had several tasks that were not related to the task above, for example:

 You remember that you will have an important meeting with John this coming Thursday at 10:00 in your office. You want to put it on your calendar before you forget.

Then I instructed participants:

You want to continue with your shopping list by adding kitchen roll on it.

 This requests the participants to go back to the note app that they opened earlier, from which we could find out if they knew to use the right edge swipe to get to the running apps – in other words, whether or not they understood the multitasking feature.

Now you will have your first version of tasks, and on completion, you should always try the tasks out by using the interface to check that they all make sense.

 

Summing up

We use tasks to discover the usability and user experience of an interface. The task quality determines how useful and accurate your testing results would be. It requires time to hone your skills in writing tasks.  Let me sum up some of the main points:

  • Define the goal(s) of the testing;

  • Familiarise yourself with the test interface and go through this interface at least 3 times;

  • Use the appropriate task formats and avoid any inclusion of task-solving cues;

  • Ensure the description is realistic, is at the right level of detail, and avoids ambiguity;

  • Consider the ordering of the tasks, and whether or not you need to use dependent tasks;

  • Pilot the task set with yourself.

What happens next, after you have the list of tasks ready for the  the usability testing? It doesn’t end here.

If time allows, we always pilot the tasks with someone to make sure they are understandable, and that the orders of the tasks work. There are always changes you could make to improve the task sets.

In addition, you will realise that once you are in the actual testing,  no matter how perfect the task sets are,  you will need to react instantly and make adjustments in response to the dynamics of the testing environment: we cannot predict what participants will do. It is therefore important to know how to manipulate the task sets in the real testing condition. We will discuss this in the next post.

References

Dumas, J.S. & Loring, B.A. (2008). Moderating Usability Tests: Principles and Practices for Interacting. San Francisco, CA: Morgan Kaufmann.

Rubin, J. (1994). Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests. New York: John Wiley & Sons.

Schaffer, E. (2002) Bollywood technique, http://www.humanfactors.com/downloads/jun02.asp#bollywood

Shi, Q. (2010). An Empirical Study of Thinking Aloud Usability Testing from a Cultural Perspective. PhD thesis. Denmark: University of Copenhagen.

 

 

Read more
Lina Pio

Over the past few weeks we’ve been exploring visual directions for the calendar app. It’s a pretty exciting opportunity to create something fresh and at the same time useful. In this post I’ll take you through some of the directions we’re looking at right now and where we hope to eventually go. At this stage the designs are still under consideration.

Year view

This view offers a lot of challenges particularly given the large amount of information that can be compacted into such a small space. The challenge was to provide something that could inform the user quickly and usefully without overloading the screen with information. Each month is clickable. Individual dates, however, will need to be selected from the month view.

01_year copy

Month view

As with year view, it’s a tough call to keep the month view looking and feeling smooth and simple. Because of this, we decided to use the month view to provide the user with an overview of the dates in that month, from which they could select a date only. Instead of filling in the events inside the month view, the user can see the events at a glance inside the week view. We explored two different ways of laying out the month view visually.
02_month copy    02_month2 copy

Week view

In this view we experimented with the visual layout in terms of how much screen space the chrome took up and how you could visually represent different calendar events using coloured blocks vs coloured dots.

03_week1 copy 04_week2 copy 04_week3 copy 04_week4 copy 04_week5 copy

 

 

Day view

With day view, as with Week view, we tried looking at reducing the chrome around the day box to give more space to what the user most needs to see – the events during that day.

05_day1 copy 06_day2 copy

Event

Event view tends to be a different interface type than the others. Where with the other views a user’s prime activity is to navigate through information, the event is the goal in itself, providing a list of information. Because of this, a white background may be a better solution to presenting large amounts of text, making it easier on the eye. One thing that is still in design at the moment is the ability to select the date and time when creating a new event.

07_new_event1 copy 08_new_event2 copy 09_new_event3 copy 10_event_detail copy 10_event_detail2

We hope you enjoyed going through our visuals and thought process. Watch this space next time for more visuals on date and time picker to go along with event view.

 

Video

Here’s a video to show how the interactions and transitions will eventually function.

Read more
Chee Wong

Right… so where should we start? First post.

Hello, my name is Chee, and I am an industrial designer.

In this post I will share some materials, stories and process during the development of the Ubuntu Edge.

 

D001

We started off by pulling the key elements of the Suru theme, and expanded on that, in order to explore the transition from a digital user experience, to a physical one.

 

0002

0005

0003

Once the rough ideas were formed, the fun part started, as we dived right into visualising the concepts; Pencils, sketching pads, markers, clippings, samples, colour chips and anything else interesting.

 

D003One of the best way to visualise, experiment and refine a design is to materialise it in any way possible. In the process of creating and fine tuning the Ubuntu Edge, we turned to methods known to be the most effective: Model making, 3D CAD, and 3D printing. In our case, we tried it all!

 

0009

0006

D004It’s equally important how the Ubuntu Edge feels in the hand, how it visually presents itself and how certain textures give visual cues to the perceived expression. How each material works alongside each other without creating visual complexity is one of the key role to either make or break a design.

After several rounds of refinement and fine-tuning, we pressed forward with what we have now today as the Ubuntu Edge. From a rendering to visualize the Ubuntu Edge, to one that sit in front of us.

 

I hope you enjoy reading through the process, and lets make it a reality.

The Ubuntu Edge

D005

Read more
Michal Izydorczyk

Shorts visual exploration

Hey

After all the work we have done on the Rituals app designs it was time to start exploring other core apps.

I thought it would be good to share with you our recent exploration of the RSS Reader App.

Please note that those are only the key screens and settings are not covered yet. But this should give you something to get started ;)

Here is the link to the spec with all the font sizes, spacing, and colour values for the gradient backgrounds…

Let me know what you think ;) and I will try to update you on some visuals for the music app next.

This is the home screen of the RSS Reader.

Read more
Katie Taylor

Edges are special to us. We use them for finding apps, tools and system services, so using the edges will be second nature to Ubuntu phone users. By using the launcher, how to launch your favourite app will become ingrained in your muscle memory of the left edge.

The design vision behind Ubuntu for phones includes the use of fast and natural interactions, so taking that to the welcome screen means that if your phone is locked, you can still access the launcher, system services and the right edge. If you have a pin set up, you only need to enter your pin when accessing private data, in the Gallery app or the Dash for example.

 

 

If you’ve flashed your phone recently, you will be able to activate the lock screen for the phone using a temporary hack (love it!). You’ll notice that the blur has not yet been implemented, but will be added later. Thanks to Michael Zanetti for originally posting instructions to the Ubuntu Phone mailing list. Here they are:

To enable the pin lock, log into the phone and create a file /home/phablet/.unity8-greeter-demo, with the content: password=pin

If you want to see the password unlock screen instead, put this into the file:  password=keyboard
For now, the pin is hardcoded to “1234″ and the password is “password”. Note that this functionality can (and will) disappear at any time as we bring all the bits and pieces together. This is a temporary, simple way to enable the visual part of the lock screen for us all to have a play with.

Let us know what you think on the Ubuntu Phone mailing list and the IRC channel.

Read more
Calum Pringle

It’s been a while since our last update to the app design guides so I thought it was about time I shared the latest additions to this growing resource.

Screen sizes

A brief intro to the framework we use for designing for a scalable OS - the grid unit. With a link directly to a more detailed explanation on developer.ubuntu.com.

Read about designing for multiple screen sizes.

FAQs

We’ve started to collect frequently asked questions. This section could be improved if it was a little more ‘live’ so we’ll have a think about that.

Read our most frequently asked questions.

Combo button

When you are receiving a phone call, it is possible to decline the call (of course), or alternatively you can decline and reply with a message. To accommodate this and similar use cases we have designed the combo button. Use the combo button to display secondary variations of the primary action.

See our new combo button.

Option selector

While designing System Settings we have come across many situations where there is a need to select from a list of mutually exclusive options. Use the option selector when you need to select an option from a list.

See our new option selector building block.

Slider

Our slider has gone through a little makeover too.

Take a look here.

Remember, this site is a work in progress, so we will continue to iterate on the content and design. As usual you can find us on the Ubuntu Phone mailing list and the IRC channel.

Read more
Martin Keary

This is a presentation of our ‘Paper’ Motion theme for Ubuntu Mobile.

The theme is informed by the ‘paper’ graphic style of the mobile OS and we have sought to accentuate it wherever possible. Rather than using more overt effects like page curling and folding, we have hinted at the theme by using multiple layers, ‘stacking’ and suggestive effects. Multiple layers of sliding paper can be observed in the animation of the switch button, stacking can be seen occurring on the icons in the launcher and an example of a suggestive page-turning effect can be seen during the ‘App Stacking’ example.

Read more
Lisette Slegers

Research around reading

As you can see in the image above, I have spent some time looking at different types and contexts of reading, trying to understand what the reading experience might be for Ubuntu. The contexts of reading varies from libraries to magazine stands to the sofa in your lounge, and these each have an impact on how and what you read.

Something we all know (from a healthy bit of stalking field research on public transport) is that reading on a phone means you are probably doing something else at the same time. You are waiting for your friends in a restaurant, or on a busy train on your way to work. You open the reader app to quickly check some news.

Meet “Shorts”: leaf through your news while you wait

Paul is in the station, waiting for a train. He has 5 minutes until it arrives.

Shorts wireframe 1He launches Shorts. The app opens up with a view that shows short snippets of articles on the topics that interest him. The items are laid out on the page in the organic grid, similar to the grid that is used for the gallery app.

Shorts wireframe 2

It is going to rain tonight. Paul decides to stay in and cook a meal with his flatmates. All he needs is a recipe. He navigates to one of his topics, Food.

Shorts wireframe 3

Paul selects a recipe and reads through it. He decides it is too elaborate and returns to the topic.

Shorts wireframe 4

He looks further through the topic and taps on another article. This recipe is perfect for tonight! Paul saves it so he can easily find it later.

Check out this video too:

See how this concept also fits with our Design Vision and the other ritual apps?

Next steps

We will be connecting the dots and working on key journeys for Shorts. Follow development progress on Google+, the Ubuntu Phone mailing list and IRC channel.

One last thing

What do you think of the name?

Read more
Michal Izydorczyk

Thank you for all your positive feedback after our first blog post.
We are very excited and are continuing with the designs,
here’s a quick update on how we’re getting on.

During the last few weeks we have been looking at the development of the weather and clock apps. We are also looking at set of gradients that could specify a range of weather conditions.

Here’s the how

A linear colour gradient is specified by two points, and a colour at each point. The colours along the line through those points are calculated using linear interpolation, then extended perpendicular to that line.

* wikipedia.org

 
This is great way to describe temperature and how it changes over 24 hours.

The second part of developing these apps was to create a set of graphic assets that could support the weather icons as well as the clock face.

Using entirely white mono assets was obvious to contrast with the colourful changing backgrounds.

But we quickly realized that the graphic style of our icons used as indicators or toolbar actions did not fit well for those assets. The weather icons, for example, looked a bit too heavy while we wanted something more zen and simple to blend nicely with the minimalistic and elegant design of the apps.

We replaced the solid fills with thin outlines and add some roundness to the end of the strokes. The weather icons have become playful but graceful, while keeping their plain but not to simplistic in the look and feel.

The clock faces are designed following to the same principles. With great results?

You be the judge ;)

 
 
 

Read more
Calum Pringle

We have just published a new chapter on our App Design Guides : how to handle orientation.

To cater for the different orientations of a range of touch devices, we need to design apps for Ubuntu in a responsive way.

Phone orientations

orientation_1

  1. The primary orientation for an app on the phone is portrait.
  2. Consider using landscape orientation when we want to have a full screen experience for a single piece of content, such as watching a video, looking at a photo or gaming.
  3. A phone app automatically fits in the tablet’s side stage, with a flexible height.

Tablet orientations

orientation_2
orientation_3
orientation_4

  1. The primary orientation for an app on the tablet is landscape.
  2. Consider portrait orientation when it will help the user engage with your app; for example reading a magazine or writing a long email.
  3. By supporting portrait, your app automatically supports split screen.

Responsive strategies

Use these strategies to make your app work on screens of both different sizes and orientations.

Position graphic elements relatively

For ease of use we space graphical elements relatively; to both one another and the screen edges.

orientation_5

Decide how your app might show more or less content

  • An app on the tablet’s main stage might show more content than on the phone.
  • orientation_6

  • An app on the phone with a list of content, such as a feed, would show much more content in the side stage as it is taller.
  • orientation_7

  • If your app’s content is larger than what fits in view, for example a map, you might consider showing more or less content depending on shape and orientation.
  • orientation_8

  • If your app’s content is fixed in shape then it can simply scale up or down. For example the same amount of content on the phone would be scaled up on the tablet.
  • orientation_9

A few last things

1. Use extra space constructively
Consider what content your app could show in extra space, be it the history of a calculator, a list of missed calls or even high scores!
2. If your phone app does not scale, it will remain a fixed height in the side stage.

Hope this helps – and as ever please let us know what you think, these guidelines are a work in progress and will grow over time. Feel free to get in touch with us on the Ubuntu Phone mailing list and the IRC channel.

Read more
Inayaili León

Spring cleaning ubuntu.com

Yesterday we’ve launched an updated version of ubuntu.com, which we hope will improve navigation throughout the site and provide visitors with a better understanding of what Ubuntu is.

Research is an important part of what we do, and this update isn’t an exception. The improvements we have made in terms of content and structure of the site are mostly a reflection of what users have told us during testing, such as clarifying the description of what Ubuntu is when you are browsing the Desktop section.

Refocused navigation

By focusing our site navigation on the products themselves, we aim to make it clear for someone who is new to the site that Ubuntu is about all of these things: PCs, phones, tablets — you name it.

Ubuntu.com - New navigation
New ubuntu.com’s product-based navigation

Updated footer

We have introduced a contextual footer at the bottom of most pages. This gives people an opportunity to explore more of the section they’re in and read related resources like news and articles. We have also made the main footer work harder by providing a bird’s eye view of the entire content of the site.

Ubuntu.com - New footer
An overview of ubuntu.com in the updated footer

Ubuntu.com phone page

But the changes are not just about the site’s structure. Visually, ubuntu.com has been evolving ever since it was first launched, and with the latest update, we keep moving towards a cleaner, fresher, but also more modular, approach.

This direction started with the design of the phone and then the tablet sections of the site, which took existing design components and “opened” them up — we’ve added larger margins, lighter text, more space all around.

We then revisited the other sections of the site and standardised the templates and remaining components as much as we could. This exercise took a great deal of close collaboration between design and front-end development: it was important that design decisions were agreed by everyone and that the code reflected those decisions.

The product of this code cleanup had already been made live a few weeks ago, but the more visible side of the cleanup happened right now, with this update.

What we’ll do next

We will be working on, and improving, the way you navigate through ubuntu.com and other websites in the Ubuntu web universe in the coming months, so keep an eye on this blog! And, as always, we’d be delighted to hear your feedback.

Read more