Canonical Voices

Posts tagged with 'usability'


Before I get started I want to provide a cast-iron caveat here: I am not a professional interface designer. While I have an interest in interaction design and usability, it is not my profession and most of my experience is from working on spare-time projects and developing interfaces for those projects. In other words…the views expressed here are not born from formal training.

OK, with that out of the way I just wanted to talk about menus a little. Recently we released Ubuntu 11.10 Beta 1 and there was the requisite review on OMG! Ubuntu! and the conversation in the reader comments rather unsurprisingly descended into a debate about the menus and window controls in Ubuntu 11.10.

Let me explain the source of the debate. Here is a screenshot of Firefox in Ubuntu 11.10:

As you can see there are no windows buttons up there in the top-left corner of the screen and the menus are not visible either. All you can see is the application title. If you hover over the application title the windows buttons and menus appear so you can use them.

Now, I can understand how this has caused some controversy; the screams of armchair usability pundits rattling off concerns of “this is a regression in discoverability of the menu and windows buttons” can be heard in the galleys of that OMG! Ubuntu article. Conceptually I see their point; if the menu is not visible, and it is not in the application window, how do people find it?

This is a misnomer though. Usability and interaction design is all about balancing the effectiveness and discoverability of an interface with the aesthetics of a beautiful, desirable product that we want to use. We don’t just want to build functional technology; we want to build desirable, pleasurable technology that fits into our lives.

If the argument is that we need to expose functionality for it to become discoverable we can do this but such exposed functionality is often not beautiful and desirable. As an example, this is Microsoft Word with all the toolbars switched on

Clearly having everything switched on does not create a beautiful and desirable interface, and I can understand the retort to this would be “sure, Jono, but menus and window controls are a basic and common function in an interface, so we should prioritize their discoverability and visibility“. I am not sure I would agree with this. While they are an important and useful function in Unity, the point I take issue with is that they need to be visible all the time for people to understand where they are and how they function.

My thesis as to why is pretty simple: people learn by exploration. Let’s do a quick exercise. Write down on a piece of paper the last three devices that you purchased. They might televisions, cell phones, kitchen appliances, games consoles, or whatever else. Every one of these devices comes with it’s own interface to operate it. Now, how many of those devices did you sit down and read the instructions for? I am willing to bet it was close to none.

You learned those devices by poking around, trying things out, clicking, pressing, pushing, and otherwise playing with and exploring it. Many of these devices will have had entirely new interfaces to you which you had not used before, yet you figured them out. Some elements of the interfaces will have been obvious (e.g. buttons protruded to indicate that they can be pressed) and some elements less-so.

This is why I think the menu and window controls decision makes sense. People like to explore, and it will take next to no time for Ubuntu users to discover that hovering over the text in the panel will display the menu and the window controls. The same can be said for discovering that if you hit the left side of the screen the Launcher appears. The point here is that when you have discovered that the menu is there, you don’t need it to be visible all the time.

Instead you can hide it and present a far less cluttered interface. Put it this way, let’s look at the two options:

Personally I think the latter looks far sleeker, less cluttered and pleasant to use. Having used Ubuntu 11.10 for a month or so, this small change has really been a nice touch and I am pleased that these small touches continue to refine the Ubuntu experience into a truly desirable and powerful product that is simple and effective for everyone.

Read more

I want to share a short story with you folks as the basis for a little challenge I wanted to set. Let me start at the beginning.

A little while back John Lea, a member of the Canonical Design Team filed this bug. The essence of the bug was grounded in one of the check-boxes on one of the pages of the Ubuntu installer:

The third-party software check-box is a useful little feature in which some non-free components can be easily installed at the install time if the user so desires so. The check-box is designed to solve the problem where things don’t work because there is no Open Source solution available.

The bug was proposing that the check-box be ticked by default with the goal of ensuring that the user does not get a broken experience. When I first learned of the bug report this struck me that it had some legal and policy ramifications. In my mind this is not as simple as just changing a default – my take was that if the check-box was ticked by default it would be a definitive change in policy for the Ubuntu project – it would include non-free components by default (even if a user could un-check it to not have this components installed).

I felt my responsibility in this case was to ensure that due process and transparent published governance was used to respond to the bug. As such I asked the Ubuntu Technical Board to provide comment and input. They had their public meeting (meeting log) and voted unanimously of 5-0 against the proposal in the bug report.

So that is the end of that, right?

Well, not really. I don’t want us to dismiss the rationale and ethos behind John’s original proposal in the bug report. John wants to solve the valuable and important problem of users installing Ubuntu and things not working, largely because a closed-source tool was not installed to bring that support in the absence of an Open Source solution. As we move to take Ubuntu to the masses we are going to face various cases in which we can’t offer an Open Source solution or the required quality in that Open Source solution for a given use case. Examples of this include Flash support, MP3 playback, some graphics drivers etc.

While a broken experience will not help us get over the chasm, I am also of the view that we should not sacrifice our values and philosophy; freedom is not a chore that restrains us from delivering a great user experience but a feature that we need to celebrate and encourage.

Thus we face the classic tale of Freedom vs. Functionality in the Open Source community. How do we deliver a great user experience, but one that maintains our commitment to freedom, particularly in those cases where no free solution exists?

I feel uncomfortable saying we need to significantly compromise on either side of the line. We should never compromise in delivering a wonderful user experience that just works, but we should also never compromise in delivering a Free Software Operating System. What’s more, I feel like we haven’t uncovered all of the options available in striking this balance in the installer.

It strikes me that our goal here is for the installer to understand what capabilities can be delivered on the user’s system with Free Software, but to inform the user of their options regarding non-free additions that may offer a better experience. Then the user gets to decide. If they are unwilling to use non-free software, they understand that some things may not work. If they are happy to use non-free elements, they can get that experience without jumping through hoops. All the while this would ensure that we are free by default but non-free functionality would only be a click away if the user chooses so. This way we empower the user.

It is with this that I wanted to present a challenge to our growing design community. I think this topic is a valuable one for us to discuss at our next Ubuntu Developer Summit but thought it could be useful to open the discussion in the community now in preparation for the event. How do you feel we could best solve this? Anyone want to propose some mock-ups or put together a spec?

Read more