Archive for April, 2010

Removing Firefox’s Status Bar and Rehousing Add-on Icons (Part 1 of 2)

By On April 29, 2010 In Add-ons, Features, Firefox, Next Version, User Experience With 123 Comments Permanent Link to Removing Firefox’s Status Bar and Rehousing Add-on Icons (Part 1 of 2)Permalink

One of the major goals in redesigning Firefox is presenting a simpler, cleaner, and smaller user interface. Firefox currently has more chrome (space taken up with user interface) than any of the major browsers, and all that chrome reduces screen space given to page content. We’d like to be more efficient with space in Firefox, maximizing the usefulness of the interface and the amount of content shown.

The process of reducing Firefox’s chrome has meant looking critically at each part of the interface and how it’s being used. The goal is to find places where chrome can be minimized, both through efficient redesign and pure removal where functionality just isn’t providing enough benefit. This process led us to an obvious candidate for chrome reduction: the status bar. In addition to taking up page content, the status bar is the only part of Firefox’s permanent UI located on the bottom of the browser. This placement leads to the status bar being easily obscured, and sometimes requires resizing the window to view. For an entire toolbar of UI, it seems this slacker may not be pulling its weight in usefulness.

The status bar is home to a few pieces of functionality. However, with the new Firefox design, much of this functionality is already being relocated to the top of the browser. Other parts are not extremely useful.

  1. Add-ons icons
  2. Link URL preview (answers “where does this link go?”)
  3. Resize window control
  4. Current loading task
  5. Progress bar for page loading
  6. Notification that the page has finished loading
  7. Link to Download Manager with download summary

Already we can start crossing items off this list. #3, the window resize control, does not require a toolbar. #4, the currently loading task, is not widely useful; most messages display unintelligible processes which are flickered too fast to be read. #5, the progress bar, we’re already planning to move to the top of the browser, attached to the tab that is loading. #6, the “Done” announcement, should be handled in the negative: if the progress bar is gone, the page is done. #7, the download manager link, we’re also planning to move to the top of the browser.

So, two pieces of functionality remain: add-ons icons, and link URL preview. Let’s look at add-ons first.

Add-ons are tricky to plan for because developers can do whatever they want with them, and put them anywhere in the UI. Also, add-on icons in the UI can do anything, from affect page content to launch a menu. Unlike the other parts of Firefox’s chrome, we have no control over the function and placement of add-ons. The best we can do is provide a space for add-ons, recommend add-on developers take advantage of it, and give them tools to do so.

An idea that’s been bounced around is saving the area to the right of the URL bar for add-ons. This is similar to what Chrome does.

The benefit of this placement is that it doesn’t add any additional UI to Firefox. The problem is that while this works for one or two add-ons, the more icons the user installs, the smaller the space for the URL and search becomes. Heavy add-on users would eventually have to choose between not having all the add-ons they want or having less space to browse and search. A better solution would be useful both to users who have only a few add-ons and users that have many.

One way we could handle this is by considering add-on icons to be modifiable, movable objects that the user can control. Since we can’t know what these icons will do nor launch, we can’t make decisions about their placement based on functionality. Why not gives users the ability to modify their placement, just as users can modify the bookmarks on their toolbar and the buttons on their UI? It seems inconsistent that we’ve been giving users easy control of so many objects in the Firefox UI, but not the placement of add-on icons.

By treating add-ons as movable objects, we can modify the appearance of add-on icons based on where they’re placed in the UI. For instance, let’s assume an add-on icon by default displays in the bookmarks bar. It would then display as a regular 16 x 16 icon. However, if the user moves that add-on icon to the upper toolbar of the window, we could draw a border for it so that it has a consistent look with the other buttons in the toolbar. Moving it elsewhere, such as to the top of the window, would produce a different look. The user would then have the ability to modify their interface depending on how they use their add-ons.

Next, incorporating add-ons that display more than an icon in the interface.

The Best Design Process Fits the Task

By On April 7, 2010 In User Experience With Comments Off on The Best Design Process Fits the Task Permanent Link to The Best Design Process Fits the TaskPermalink

My colleague Alex Faaborg wrote an excellent blog post (in response to my last post in response to Ivanka Magic’s post) about some of the limitations of the contextual design process and designing using personas. I fully agree with most of what he writes, and wanted to draw attention to some of his points to present a more complete picture.

Contextual Design isn’t a Hammer, the World isn’t only Nails

Contextual design isn’t a blunt tool that can be blindly applied to any design problem. It’s an extremely structured, formal process that is best used when approaching a complex design task with highly diversified users. A task it was ideal for, for instance, was my thesis project in which my team designed a mobile device for Nasa engineers to report and diagnose problems. We were working in a complex space and for very specific users, where the very structure of workflow of tasks had to be redesigned before solutions could be considered. By following the contextual design process nearly to the letter, my team was able to explicitly shift our focus first to the user and the user’s space, then to the user’s workflow, then to the workflow within a system, and finally to design solutions that corrected the problems the user faced.

Every problem truly has its own “context,” and choosing an appropriate design process to fit the task at hand is an important challenge in user experience design. This process, even for simpler design tasks, should resemble at its core contextual design and the specifically the scientific method. It should begin by identifying the problem. It should progress to a phase of research and investigation into users and user needs. It should enter an iterative design phase, in which ideas are tried out, tossed aside when shown not to work, and improved upon. It should be subjected to user testing, and the subsequent data should inform the design.

I do disagree that studying users in-depth is less useful when designing for a larger audience. It’s true that the most you could say about what Ubuntu users have in common is that they are humans who use Ubuntu, and they certainly aren’t as similar as the relatively few Nasa engineers I was designing for. But all users have some similarities that they’ll apply to tasks. For instance, in general humans can learn, humans try to understand new tasks by leveraging what they know about other tasks, humans like to not be bothered, humans like to feel respected, humans like to feel in control, etc. Human similarities means that giving a few humans a task will allow the designer to draw inferences about what other humans will do in similar circumstances. User testing is basically this: extrapolating from a few people in a specific context what others in the same context will do. It’s valuable information, and something I think we should be doing much more user testing in open source.

Personas can be Useful for Shared Language and Understanding in a Design Team

Faaborg brings up personas (not the lightweight Firefox theme, but the notion of creating a small set of hypothetical users who embody the attributes of users you are designing for) as an idea that’s not useful when designing a product as universal as an operating system or browser. The usefulness of personas in user experience design is a bit of a hot button issue. Personally, I have found them to be useful, but only in response to user data and within a design team. Faaborg mentions that Microsoft created “aspirational” personas – the hypothetical user they were designing for who they wanted to create. I can see why this could be useful in marketing, but in user experience I believe you should design for the users you have and not the ones you want. Personas are useful if, when you did that user testing, certain participants with similar backgrounds behaved in similar ways. For instance, in Firefox, certain users perform all browser operations with their mouse. Other users, especially ones who consider themselves tech-saavy, tend to use key commands. We’re designing a browser for both of these groups, so giving them explicit names and characteristics can help create a shared language for a design teams to think of these groups in. It’s not the only way to approach data, but it’s one clear method of giving a lot of data and shared understanding an explicit label so it can be described without citing or explaining the shared understanding.  Also, we do this naturally by saying things like “my mom couldn’t do this,” “my grandpa won’t get it,” “the Linux guys’ll be mad.” Why not be explicit about user groups, give them names, and in the process be nicer to your poor old mother?

Ubuntu Buttons: Redesign them if There’s Cause to, Mmkay?

Faaborg’s advice on what to focus on for the actual task of redesigning Ubuntu’s windows is dead on. What I hope the Ubuntu team will focus on are issues like visual language that explains the task, natural mapping, target size and shape (will these controls be blocked by other windows? are they hard to hit? is it easy to hit the wrong one if you’re in a hurry?). I hope they will identify user-centered reasons that the buttons should be designed rather than changing them because they’re old or it seems like time for change. And, of course, I hope they’ll test their design with users and explain their rationale.

That Pesky Design Process

By On April 7, 2010 In User Experience With Comments Off on That Pesky Design Process Permanent Link to That Pesky Design ProcessPermalink

Lead Ubuntu designer Ivanka Majic has been taking some flak for her recent blog post about redesigning buttons in Ubuntu’s window manager. And, rightly so; she opens by asking several vague questions, says analysis happened in the form of a sketch, and then reveals that Ubuntu’s window manager buttons will be redesigned. “Is it better or worse? It is quite hard to tell,” she writes.

Unfortunately, Aza Raskin was right when he Tweeted that this kind of “wishy-washy design speak” hampers the fledgling growth of design in open source. We’ve heard criticisms that user experience is just “change for change’s sake,” or that it’s all subjective opinion with no structure behind it. When user experience decisions fail to follow a design process or are described poorly, it does resemble arbitrary change for the sake of change.

However, there’s no excuse for design decisions, in open source or elsewhere, to be arbitrary. While good user experience design does involve creativity and risk-taking, it is not art: it is not left up to the particular tastes of the creator. The goal of user experience design is to solve problems and improve how people interact with technology. The path from a design problem to a solution is one that designers handle differently, but at its core should always resemble the scientific method: a deliberate process that improves and changes based on data. Hugh Beyer and Karen Holtzblatt refer to this as the contextual design process. I’d like to outline the basics of this process as they describe it in their book, Contextual Design. While many variations on this system can be formulated to adapt to various problems, it’s a solid way to approach a design task with a well-defined structure that prevents arbitrary decisions.

Step 1: Contextual Inquiry

In this step, the designer’s goal is to understand the users of the system they are designing. This can be accomplished by interviewing people in the environment they will use the product in to discover who the users are, what problems they face, and what goals they wish to accomplish.

Who are Ubuntu’s users? What kinds of tasks do they use Ubuntu’s window manager for? What do we know about their current usage of Ubuntu’s window manager? What problems are they currently facing? Why are they facing these problems? Let’s sit down with users and find out who they are and what their current experience with Ubuntu is like.

Step 2: Work Modeling

At this step, the designer analyzes what he has learned in the Contextual Inquiry stage. Now the users and their world are known, but this information is often intangible; creating data models that represent the users’ world help identify its structure, successes, and failures. In practice, the most important part of modeling this information is identifying “breakdowns” – places where users encounter problems or frustrations. At Carnegie Mellon’s HCII, we identified these on our models with big red lightening bolts: they are the key towards successful redesign, because they show where the current system is failing the user.

Now that we know Ubuntu’s users and have modeled their work, what breakdowns do they experience? Where in users’ workflow do inefficiencies and frustrations occur? What slows users down and makes their window management a poor experience?

Step 3: Work Redesign

It’s tempting in tech to jump to a technical solution to a problem, but this misses the mark. It is the user’s workflow where problems were identified, and this is the first place to look to solve them. The designer should now identify how the workflow can be improved structurally to avoid breakdowns. Shelley Evenson recommends making storyboards at this stage; drawing the user a new workflow that fixes the structural problems identified.

Now that we’ve identified how Ubuntu’s users’ workflow is impeded by the current design of the window manager, how could this workflow be improved? How could particular window management tasks be improved?

Step 4: User Environment Design

Now that the designer knows how users’ workflow can be improved, it’s time to look at the function and system that he’s designing for. At this stage the designer must decide how the parts of the system work together from users’ point of view. While a system will have a defined technical structure, what users mentally model the system to be is different and more relevant to them. How the system is presented to users should be explicit and distinct from the system’s technical structure.

From the point of view of users, what are the relevant parts of Ubuntu’s window manager and how are they related? How will users understand the various control and window functionality within the system of their Ubuntu desktop?

Step 5: Mock-up Solutions and Test Them

At this point, how users’ experience can be improved structurally has been identified. It’s time to apply that understanding to actual design solutions. This should begin as rough sketches which should be tested with users at very early (or low fidelity) stages. Some designers even begin testing when all they have are paper sketches, having a participant pretend they are using an actual system while the designer moves paper to simulate one. In this way, problems and successes are identified early. That information should guide the design as it becomes higher and higher fidelity. At each stage, user testing should refine the design, and the design should respond to this data and become more solidified at each pass.

Here’s five sketches of how Ubuntu’s window manager can be improved: time to test them with actual users. With these results, perhaps quick prototypes can be banged together in JavaScript, Flash, etc. Once we’ve done user tests with those, it should become clear which design directions are performing best.

Step 6: Ship it! But Consider your Community

The designer has now done the research, the design, the testing – it’s time to get this thing implemented and out the door. But now the designer must carefully consider their organization, community, or company. Every change to a system that people use will create pain, anger, and force users to relearn their habits. It should never be done lightly or curtly. In open source, we have the advantage of transparency. Rather than waiting until Step 6 to debut the design, we can and should be talking openly about it all along. But it’s especially at this stage, when the decision is made, that being respectful of the community is crucial.  A designer can expect that a design won’t be popular just from a screenshot, so explaining the process above – the rationale, the research, the work, the decision-making – is the way to show the design decision is far from arbitrary. A designer in open source can follow the most rigorous and careful design process imaginable, but if they blog saying “Here it is, you’re welcome,” the community has a reason to be upset.

Knowing what I do about Ubuntu users and the Ubuntu community, how can I explain the design decisions that have been made? How can I talk about the relevant points of my design research and process so the users know that this decision has been made in a sincere attempt to improve their workflow? How can I argue successfully for my design, knowing that users will be upset at having to change their work habits?

So, that’s the roughly contextual design process as Beyer and Holtzblatt describe it. Yes, this process is highly formal and structured, and few designers out of school follow it exactly to the letter. However, serious user experience designers use variations on this process for their work. The decisions they make should never be or appear arbitrary.  Designers should be constantly trying to understand users, design for those users, and determine if a design is successful through testing with users.

I hate to call out Majic in particular here, but I did want to highlight that more goes into successful user experience design than her post suggested. And indeed, this might just be a problem of communication: a rigorous design process may have been masked by sloppy language. Given that (in my opinion) Ubuntu’s user experience has been blossoming and improving by leaps and bounds over the past few years, I suspect that Majic and the rest of her team do indeed follow successful design practices. But especially in open source, designers need to carefully consider the implications of what they publish. I should know this, because I’ve said some stupid things in my blog and have been rightly called out on them. Designing in open source is a new animal, and we’re only starting to find effective ways to harness the incredible power of open source communities towards improving user experience. But if a designer makes a decision that appears arbitrary, you have every right to call them out on it. It’s not enough to design well: designers must successfully argue for their designs and the rationale behind them.

Add-ons Manager Redesign Update

By On April 1, 2010 In Add-ons, Firefox, Next Version With Comments Off on Add-ons Manager Redesign Update Permanent Link to Add-ons Manager Redesign UpdatePermalink

Greetings! I want to tell you about some changes to the add-ons manager you’ll be seeing in Firefox’s trunk release very soon.

Add-ons in the Content Area, Oh my!

The biggest change you’ll see is that the add-ons manager will no longer appear in a separate window, but in a tab in Firefox’s content space. This represents a big shift in Firefox’s interaction model. You can read more about the reasons for in-content display here, but the summary is that displaying in content:

  • Allows for similar display across devices
  • Allows for quick updates from external sites, like Mozilla Add-ons (AMO)
  • Gives more screen real estate to tasks, allowing for less constrained interaction
  • Eliminates the need to manage small, easily-hidden windows

Eventually, we’d like to move many of Firefox’s various “extra” windows (Download Manager, Bookmarks Library, etc) into the content area. The add-ons manager, by being the first, will hopefully provide a solid working model that will guide the redesign and improvement of Firefox’s other windows.

So, what will you see when this thing lands in trunk? Something like this:

Ugh, These Icons Aren’t Final, Are they?

No, they’re not. Can you not read giant ridiculous gradient-heavy starbursts?! These are not the final graphics nor colors; they’re placeholders for now. In redesigning the add-ons manager, interaction design and visual design were kept deliberately separate. What you’ll see in trunk is a reflection of the new interactions in the add-ons manager – viewing in a tab, configuring and installing add-ons, etc. The final visual look will come later. This is partially because there’s still kinks to work out before the final graphics are created, and we’d like the community to try out the manager before it’s 100% done.

A Model for Firefox’s “Extra” Windows

There’s another reason the graphics aren’t final. If Firefox’s extra windows are going to move into the content area,  they have to feel very different from the rest of the web. They need to feel fundamentally a part of the browser itself. They also need to feel like a part of Firefox and the operating system. Additionally, they need to feel like each other. One of the goals here is to make Firefox’s look and feel more cohesive. The browser is the one stable part of the browsing experience. The web is a dizzying array of different content, and the browser should provide a dependable framework for exploring it. Right now, Firefox’s style is inconsistent in many places, both in design and interaction.

It looks like different parts of Firefox were made by different people at different times because, well, they were. Compare that to a product with fewer people working on each feature’s interface and a much shorter turnaround cycle.

Incongruous design is often a result of software having an organic development cycle over a long period of time; different parts begin to look and feel very different to each other.

One way to mitigate against organic growth creating dissimilar design is to make and use style guides. Firefox follows them for code and terminology, but we don’t have much for interaction and interface design. So, before we can really bring all these extra windows to content, we need a clear picture of the interactions and style that we’re following. Starting this process has been contingent on the new Firefox theme becoming solidified. Stephen Horlander‘s done incredible work here, and we can feel confident moving forward with a plan for these other windows. This is a separate project that I’m starting up and will be blogging about in the future.

Design Influences

Even though the graphics and style are not yet final, I wanted to point out some of the projects that influenced the interaction of the add-ons manager redesign. Nothing is ground-breakingly new in the manager, and this is deliberate; I was trying to find the simplest interactions that would work for a wide variety of content and users.

One simple interaction being used is the two-panel design itself.  “Zooming in” to information by moving right has become a standard of application design. All major operating systems have a similar interaction here: selecting an item on the left shows its contents and/or details on the right (the opposite is true for right-to-left language readers). This design is already being used in Firefox for the History sidebar, Bookmarks Sidebar, and Library.

The basic layout of the addon manager’s “digest” and “detailed” view are similar to the layout of addons on addons.mozilla.org (AMO). Luckily for us, AMO had a recent redesign and solved many of the problems of displaying add-on information. Giving summary information in a list helps find an add-on of interest, and more information is available on click. Using a similar style to AMO was also important because of how intrinsically the add-ons manager and AMO  are related. Treating add-ons differently within Firefox would mean that add-ons users would have to learn two systems rather than one.

Other bits of the design are inspired by small interactions I’ve seen other applications get right.  For instance, add-ons in the manager can be downloaded from within the manager. But, popping open the Downloads Manager to show a progress bar would clutter the interaction. I looked around for an elegant way to do in-content downloads, and found it in the video player Miro. Miro elegantly turns the download button for a video into a progress bar, meaning the user does not need to look away from the target they clicked on. They also incorporated pause and stop button beautifully into the bar itself. The new add-ons manager handles the progress bar very similarly.

Another element of Miro I thought was a good idea was the very subtle “Show More” button, which gives an expanded view of the selected item.  This works well for add-ons as well as videos, and thus the redesign has a similar link.

The view of multiple add-ons was also inspired by task-management application Things, which also groups right-paneled items into expandable boxes.

Better close out before this gets too much longer.  Tune in next time for: why themes are hard. Hopefully I’ll have a better title by then.