All posts by jmorrow

Mechanical Turk Studies Show IE Users’ Discontent, a Growing Interest in Chrome

You’re probably familiar with the whole European Commission/Microsoft browser case. Long story, but basically the EC accused Microsoft of harming consumer choice by bundling Internet Explorer with Windows, Microsoft offered to present users with a browser ballot, I wrote about how a ballot wasn’t a great solution but should be designed well, yadda yadda.  Last month, Microsoft agreed to show the browser ballot choices in random order, rather than fixed. Definitely an improvement!

I still wondered what effect, if any, item order and other variables would have on what browser people would choose. Would certain design changes on the ballot have a big impact on users? And how could Firefox optimize its space on the ballot to be most effective?

Mechanical Turk: The Odds are Good, the Goods are Odd

My colleague Alex Faaborg suggested that I try using Amazon’s Mechanical Turk to get some answers to these questions. Mechanical Turk lets users create tasks that they need humans (called workers) rather than computers to perform. Workers select tasks that look interesting to them and are paid a small amount for each task completed. I was pretty skeptical about using any pay-for-answers service at first. My fear was that workers would be a strange grabbag of too-technically-competent-to-be-representative people who would go through tasks at lightening speed, barely reading them, to get the most profit out of their time. But I was curious about how well the system worked and tried it out with a series of tests.  Some of these presented workers with ballots, and others asked workers to compare different aspects of Mozilla’s branding within the ballot.

I was actually amazed at how well the Turk performed, and especially at the ludicrous speed at which workers responded. Within four hours I had the time of about four hundred workers, each spending an average of three minutes on a short seven-question survey that I thought would take 20 seconds. To my surprise, the vast majority of free-form answers were filled in with thoughtful detail. Numbers of people this large, for that kind of time, for so little money (each worker was paid ten cents USD) was pretty sweet. It’s frightening how the hive mind’s torrential force is so easily bribed.

The bad news is that as suspected, the Turk workers are a strange sample. They skewed heavily towards living in North America and being more technical than an average users. Of my workers, 49.35% were already using Firefox (compared with 31.34% worldwide), and only 18.44% were using Internet Explorer (compared with 55.53% worldwide).  However, those free-form answers were pretty effective at separating geeks from n00bs, and it’s n00bs I was interested in.

So what are the results already?

Ok, ok. For the majority of tests, I presented users with a browser ballot with some small variables changed – maybe a different Firefox logo, a different description, etc – and had users select a browser as though they were being given the ballot when starting Windows. Unsurprisingly, no change to Firefox’s logo nor description on the ballot made a statistically significant difference to what browser workers selected.  But people were in the mood for change: 29.09% of people wanted to switch browsers when presented with the ballot. Internet Explorer users were most likely to want a new browser – 38.03% of them changed teams. Opera users were most loyal, with 92% staying on Opera. 70.53% of Firefox’s users wanted to stay with Firefox.

Of those Firefox users who wanted to switch, 51.79% wanted to try Chrome. Of Chrome users who wanted to switch, 50% wanted to try Firefox. It’s not too surprising that there’s crossover – both Chrome and Firefox attracted the more tech-saavy users who followed browser innovation to some degree. What’s interesting is that the main reasons people gave for switching to Firefox and Chrome from any browser were related to brand recognition. Nearly everyone who wanted to switch to Firefox said they’d “heard good things” about it, or that an acquaintance had recommended it. Most switching to Chrome mentioned using and liking Google’s search engine and being curious to see what else Google could do. In Firefox’s case, recognition was based on recommendation. In Chrome’s case, recognition was all about the familiar logo associated with successful searching.

Of Internet Explorer users – the only ones who will actually see the ballot – 22.53% wanted to switch to Chrome, 8.45% to Firefox, and 7.04% to Opera.  I should note that I believe the high Chrome percentage is partially because this sample of people make part of their income through the browser and are thus more familiar with the Google brand than your average European Joe. However, it does show a huge momentum towards Chrome, fueled by that all-important brand recognition.

So what else made people switch browsers? Workers had many associations with browsers – even those they didn’t use. They described both Chrome and Firefox as fast, easy to use, and innovative.  Most users sticking with Internet Explorer described it as being familiar, or that they were content with their current browsing experience.  However, there was one association that workers only made with Firefox: security. Nearly every comment relating to security and privacy was in support of Firefox, and most of those who would consider switching to Firefox mentioned this as a personal priority.

Below is a graph of how the workers responded to the ballot. Unsurprisingly, most people voted for the browser they were using, shown by a strong top-left to bottom-right diagonal.

If these results were extrapolated, it would dramatically change the browserscape of Europe. Internet Explorer would lose 38.03% of its European market share, Chrome would gain 10.11% the European share, and Firefox would gain 3.79%. Again, these results are highly skewed towards Chrome because of the Mechanical Turk sample, but I do think that Chrome will probably emerge as a big winner of the ballot screen. The Google brand is well known and well established, and I believe it will cause users to recognize Google as a brand they already use thus try Chrome.

I’ll see your Pocahontas and raise you Speaker for the Dead

Speaker for the Dead vs. Avatar

Herdict and its Tasty, Anonymized, Aggregated Data

Nothing sucks on the web like not being able to go to the site you want. Page not found and 404 errors are an inconvenience that entirely halt your workflow. What’s worse than not being able to access a site is not being given relevant information to fix the problem. When users are presented with an error message, they tend to do whatever will make the error go away to get back to their task. Page not found errors can’t be dismissed, because they’re shown instead of the content wanted.

What creates an added level of frustration is not being given information on what the problem is. When users get a Page not found error, they likely have two questions in mind:

  1. Is this problem on my end, or not?
  2. If the problem is on my end, how can I fix it?

These are questions that have been hard for browsers to answer. Currently, Firefox’s network error pages aren’t incredibly useful. They’re certainly not as useful as Chrome’s, which use Google Link Doctor to find possible matches both for subdirectories and domains. That won’t necessarily tell the user if the problem is on their end or not, but it will help if the problem is a typo.

So how could a browser tell users if the problem is on their end or not, without infringing on their privacy? One project that currently takes a stab at this is Herdict, which Johnathan Zittrain’s been working on at Harvard University’s Berkman Center for Internet and Society. What Herdict does is let computer users tell the “herd” – via a Firefox extension – what sites are accessible. The aggregated data can tell if a site is down (because no one can access it), or blocked by a firewall (because only some people can access it), or likely on the user’s end (because everyone else can access it). Not only does that answer the question of “is this problem on my end,” but it may start to answer questions like “is this problem only experienced by my country, network provider, or device?”

Useful stuff! Does it have a place in the browser, and specifically in Firefox? I think that getting and submitting anonymized data should have an increased role in the browser, and especially where it promotes transparency and information to the user. Mitchell Baker has been writing about data, and how Mozilla could be treating aggregated, anonymized data as a public asset that should be freely available. Especially in situations where sites are being blocked and censored, giving users knowledge of the situation seems to align with Mozilla’s goals of transparency and viewing the web as global public resource that must remain open and accessible.

One way something like Herdict could be incorporated is through those Page not found errors. If there were an option on these to submit anonymized data, we could build a pretty accurate view of accessibility information for a website and share it. Allowing users to submit data when there’s a problem is something many programs do already – especially for crashes. This is good design; it makes users feel better by registering the annoyance they feel as a useful data point to developers. Here’s some sketches of what it could look like to incorporate Herdict’s aggregated accessibility data with these error messages:

1. No available information on a site:

2. Site is blocked due to local firewall:

3. Site is down for a country:

4. Site is down for everyone:

Relocating Firefox’s Add-ons Manager

In my last post, I described some of the ways that we’d like to improve the add-ons manager. First, we’d like to fix some of the add-ons manager’s usability problems, such as confusing installation processes and distracting notifications. There’s also some new functionality that the add-ons manager needs to provide, such as better information about add-ons and incorporation of newer projects such as personas. It was clear from the feedback that developers as well as users would like to see the maintenance and configuration of add-ons become easier.

The Add-ons Manager as a Tab

The current add-ons manager window sometimes gets in the way (with apologies to Gizmodo)

A few commenters on my last post highlighted problems caused by the add-ons manager being a separate window. It can get lost among other windows, be as distracting as a pop-up ad when giving a notification, and means part of the browser UI being modified is obscured. A potential solution that I think addresses these well is moving the add-ons manger into the content area of the Firefox, so that it runs in a tab. Here’s a few benefits this design provides:

  1. Gives more screen real estate to the add-ons manager. This would allow enough room for useful add-on information, scanning an entire add-ons inventory, and functionality like add-on preferences.
  2. Presents a less fragmented browser experience. Firefox’s chrome is basically a frame in which users go about their online life. But to modify that frame, users have to jump outside of it and onto a floating window. Modifying add-ons in the content space means the user never has to leave their tabbed browsing. Also, they can see all changes their add-ons make rather than having those changes obscured by a window.
  3. Allows for a similar add-ons experience across different devices. Running the add-ons manager in a tab means that an internet-capable device does not need a separate window or menu to modify add-ons – any device which can open a window can use add-ons in the same way as a desktop computer. Add-on management on mobile devices, tablet computers, and fullscreen mode would all provide the same experience. This is a huge win as the web becomes less about the device it runs on and more about the user, who may access the web on multiple devices.

Designing such an add-ons manager is a challenge we’re actively engaged in. The final design must feel like it’s a part of Firefox rather than a website, even if it’s displayed within a tab. It must also be unspoofable. Below is a rough wireframe of the design direction that we are considering.

Redesigning Firefox’s Addons Manager

When I ask Firefox users why they love Firefox, the answer often isn’t because of Firefox. Rather, it’s a particular Firefox add-on that provides functionality that has become invaluable to users. From developer add-ons like Firebug to social add-ons like StumbleUpon, a single add-on can fundamentally change how users interact with the web.

Firefox users get starry-eyed when describing their favorite add-ons

The reason add-ons are so important is because they are a fundamental way that users take control of their online life. Firefox touts its customizability as one of its main selling points, but users’ ability to customize their browsing experience is dependent on the talent and creativity of the add-on developer community. I’ve written in the past about the importance of Firefox providing a user experience ideal for as many people as possible right out of the box, without add-ons installed. But each user is truly unique and uses the web in increasingly different ways. That’s why it’s so important that add-ons be trivial to find, install, and begin using.

The Current Add-ons Manager

Add-ons are currently installed, maintained, and configured via the add-ons manager in Firefox. This window, found under the Tools menu, provides an inventory of installed add-ons and allows users to update, install, remove, enable, and disable them.

The current add-ons manager works, but could use some love

The add-ons manager has been largely unchanged since 2007, and it badly needs a redesign. One reason is that it has several usability problems that would provide significant benefit to users if fixed. For instance, the process of updating add-ons is currently characterized by interrupting important tasks such as startup. Locating a particular installed add-on currently involves navigating through categories such as extensions and plugins. Even experienced users I talked to find the distinction between these categories hazy. A redesign to address current issues should insure that installing and updating add-ons is trivial, notifications are non-disruptive, and the interface provides clear information about the state of a user’s add-ons.

However, a successful redesign of the add-ons manager must not only fix problems, but add functionality. This is because the scope and functionality of add-ons has increased dramatically and will continue to expand in future versions of Firefox. The current add-ons manager gives only the name of an add-on, an icon, a version number, and a one-sentence description. Users could benefit from more information, such as a description or a screenshot showing what UI the add-on will change. Added functionality is also needed because of new ways to modify Firefox, such as Jetpacks and Personas. These are similar to current add-ons in that users can choose items to download for added functionality, but they are installed, managed, and used differently. A redesigned add-ons manager must be able to incorporate emerging projects like these.

Redesign Priorities

From fixing current usability problems to adding needed functionality, there’s a lot that needs to be tackled in the add-ons manager redesign. To help focus the effort, the main areas to address can be described as five priorities:

1. Maintaining and Configuring

  • Allowing users to quickly locate a particular add-on by name or by type
  • Providing simple, usable controls for basic add-on operations
  • Allowing new forms of add-ons, such as Jetpacks and Personas, to be maintained and configured easily alongside traditional add-ons

2. Updating

  • Updating add-ons automatically by default. I’m increasingly convinced that most users, once they’ve decided an add-on is trusted, do not want to manually update it. They especially do not want to be reminded to update when they are starting the browser
  • Allowing users the option to update add-ons manually, update only a particular add-on manually, and possibly to undo an update

3. Installing

  • Streamlining the install process to as few steps as possible
  • Providing the user with clear indications of what action is needed, especially when some add-ons require a restart and some do not

4. Discovering

  • Providing a compelling first-run experience to new add-ons users, including clearly showing what functionality add-ons provide and what they will change
  • Providing a usable, findable way on the add-ons manager to search all existing add-ons, only requiring a visit to AMO when greater community involvement or information is sought

5. Troubleshooting

  • Providing ways to determine if a particular add-on may be causing performance problems, such as ranking by size, CPU, etc
  • Giving clear communication and instructions if there is a security problem with an add-on

This is still very much a working list open to feedback and changes (especially via comments here or on the wiki).  Basically, what I’d like to focus on is making add-on usage less disruptive and more accessible. Experienced and especially technical users tend to be very aware of add-ons and the functionality they provide. These users may see add-ons mentioned in the tech press, may talk to their friends about their favorite add-ons, and might even get involved in the add-on developer community. These are the users who say “I can’t imagine a world without add-on X.” But the benefit of add-ons is felt almost soley by this group. There are thousands of add-ons available that can improve the online experience of just about any user.  Both users and developers deserve an add-ons manager that helps make customizing the browsing experience simple.

How could Microsoft’s Proposed Browser Ballot be More Effective?

(Note: This is my personal opinion and doesn’t reflect Mozilla’s official position nor any formal statement from Mozilla)

In my post on October 15, I wrote about the European Commission (EC)’s investigation of Microsoft due to its bundling of Internet Explorer (IE) with Windows, which the EC viewed as potentially harming consumer choice and innovation on the web. Microsoft, to appease the EC, proposed that Windows users be presented with a ballot in which they could choose which browser to install. I said at the time, and in a subsequent post, that creating a ballot would not successfully address the EC’s concerns nor provide a good experience to users. However, since the EC seems to be giving Microsoft the go-ahead to design a ballot, it seems that the best we can do is consider how to design a ballot that causes the least amount of harm to users.

Here are two broad principles that are important in ballot design.

Principle 1: A ballot should be clear and simple

A ballot should present the voter with the information they need to make an informed choice, but no more. The verbal and graphic language on the ballot should be organized so that readers follow a consistent path through the ballot’s information.  Many viewing the browser ballot will not be familiar with the browser as a separable element from the operating system, so clear and precise language is vital.

In interaction design, the complexity of a new task can be lessened by leveraging against what the user already knows and expects. For instance, it’s usually best to display the instructions in the top left for western readers, and before the the possible ballot choices (Kimball and Kropf 2002). It is also recommended that the instructions be as close to the first task as possible, because it provides the highest chance that voters will read them (Dillman and Christian 2002 (pdf)).

Other recommendations to make a ballot simple and clear include:

  • Instructions written short and simply, and in an active, affirmative style (Sanders and McCormick 1993)
  • No unnecessary information or clutter around the choices (Niemi and Herrnson 2003)
  • No text smaller than 12pt (Roth 1994), left justification preferred (Dillman 1978), shading and highlighting used to direct the voter’s focus (Kimball and Kropf 2002)
  • Ballot items listed in a single row or column (Darcy and Schneider, 1989). Failure to do this is part of what caused the ballot problems in Florida during the 2004 US Presidential election
  • Enough spacing between lines to highlight groupings of visual elements (Dillman 2000)
  • No ambiguity over which button corresponds to which choice (Kimball and Kropf 2002)

Principle 2: A ballot should be impartial

I wrote in my previous post about how ballot order can influence voters. Another important factor is how much physical space on the ballot each item is designated.

The current design runs into some problems with designated space per item, swayed in favor of IE. For instance, in the current design:

  • The user must double-click on an Internet Explorer icon, labeled “Internet Explorer”, to launch the ballot
  • The ballot appears within Internet Explorer browser chrome
  • Internet Explorer is mentioned repeatedly within the ballot, Bing is shown as the default search engine, and the IE logo appears as a favicon multiple times

The current space allocation for IE is roughly 3.35 times as much as the other browsers.

ie_ballotshaded

Current ballot: 3.35 times more space given to IE than the other browsers

piechart_browserballot

Allocation of visual space for each ballot choice

This space that IE occupies in the top left of the ballot is particularly important because it’s where users begin an eye scan of a new page.  As an anonymous source pointed out to me, Microsoft mentions this in their layout guidelines:

“All things being equal, users first look in the upper left corner of a window, scan across the page, and end their scan in the lower right corner.  They tend to ignore the lower left corner.

But in interactive UI, not all things are equal so different UI elements receive different levels of attention. Users tend to look at interactive controls—especially controls in the upper left and center of the window—and prominent text first”

Improving the ballot based on these principles

In summary, the ballot would be improved by being simpler, clearer, and be presented with equal weight to each browser.

Here’s a version similar to the current proposal but with these principles in mind:

top_buttons

Follow-up to “Microsoft Proposes a Browser Ballot” Post

It seems that my previous post has set up a lot of debate on the topic of Microsoft’s proposal and the browser space overall. I’ve been reading through the feedback and have been impressed by the constructive and insightful comments (as well as some less constructive). It’s clear that this is a subject people care about and have many excellent ideas on, and I’m thrilled to see this debate playing out. The nature of innovation and user choice on the web and how it pertains to the operating system and corporate interests is one of huge importance.

Many people agreed that changing the order of browsers on the ballot would mainly effect users uninterested in deciding what browser they use. This being presumably a majority of current internet users, what I want to avoid is systematic bias – particularly one that causes the majority of users to receive an outcome that is not optimal for them. That’s essentially the problem with having a ballot: it forces users to make a decision they likely don’t care about, and thus end up with an experience that may not be right for them. As a user experience designer, my rule of thumb is that if the user is ever asked to make a decision he doesn’t care about, the design has problems.

Naturally, I’m very happy to admit that I do believe Firefox is the best browsing experience available. That said, my proposals in which Firefox received ordering preference according to market share were intended to be illustrative of the problems with having a ballot rather than as highly desired solutions. Any ballot is likely to contain preset systematic biases that swing certain voters. Normalizing for all of these is unlikely to be possible, so how to best minimize them is a good discussion to have.

The wider issue of how to best help users make appropriate choices without needlessly overburdening them with the complexity of the choice is itself exciting: we face it daily in politics, economics, medicine, etc. It’s a space that I hope we can continue explore on this blog and in the wider internet community.

Microsoft Proposes a Browser Ballot for European Windows Users, it is Not Awesome

(Note: This is my personal opinion and doesn’t reflect Mozilla’s official position or any formal statement from Mozilla)

Background on the European Commission/Internet Explorer case

This January, the European Commission (EC) announced it would investigate Microsoft’s bundling of Internet Explorer (IE) with Windows. The EC thought that perhaps throwing an IE in with every copy of Windows was harming competition between web browsers and reducing consumer choice. And you can see their point: Internet Explorer makes up 67.7% of the European browser market, and Firefox comes in second at 25.3% (as of Q1 2009).

As Mozilla is an interested party in the browser market in Europe, Mitchell Baker created a list of potential principles to be followed in the EC case, which Microsoft drew on heavily in their settlement proposal. The third principle she wrote was that Windows must enable people to choose other browsers.

In response to this, Microsoft came up with an all-American proposal: a vote! Give users a ballot in XP, Vista, and Windows 7, and let them pick the browser they want from a list. Liking the cut of that gib, the EC gave Microsoft the go-ahead begin formal market testing of the ballot. On October 7, the EC announced a formal settlement proposal. Awesome, right?

Wrong.

A ballot isn’t a great solution

A ballot is simply not a good way to create more “user choice” on the web. While literally giving users a choice, the ballot is unlikely to let users make an informed choice. A user simply can’t choose a browser that’s “right for them” based on a logo and a couple sentences. Side-by-side comparison works for items with easily comparable traits, like price or size or length of time. But browsing experience is just that: an experience. No one can rate experiences they’ve never had.

Another problem with the ballot design, as Asa Dotzler points out, is that IE still has the advantage since pressing “Install” for any other browser besides IE means a long installation process that may make the user quit or cancel. In fact, only 57% of users who click “download Firefox” on the Mozilla website ever complete the installation, and those are people who know they actually want to use Firefox.

Harvey Anderson addresses a few more concerns with the ballot, such as that it appears IE could become the default browser if the ballot is ignored or misunderstood. I won’t repeat his points, very sound. For now, since the EC seems to be moving forward with the ballot proposal, let’s consider how a ballot could be designed as well as possible.

The current ballot design

The current design that Microsoft has proposed includes a whopping 10-17 browsers to choose from. The five most popular (IE8, Firefox, Safari, Opera, and Chrome) would be grouped together on the first screen, and the rest would be visible if the user scrolls horizontally. At first, it was proposed that the browser be listed in order of market share (first IE, then Firefox, etc). However, since unfair market share is the reason the EC got hot and bothered in the first place, the current design puts the browsers in alphabetical order by name of the company that creates them. That means the first item is Apple Safari, then Google Chrome, etc.

Current Microsoft ballot proposal

So what’s the problem?

This ordering is about the worst option possible, both for user choice and the web as a whole. Microsoft wrote in their proposal that “nothing in the design and implementation of the Ballot Screen and the presentation of competing web browsers will express a bias for a Microsoft web browser or any other web browser,” but this is exactly what the current design does. Windows users presented with the current design will tend to make only two choices: IE because they are familiar with it, or Safari because it is the first item.

Users selecting the IE logo because it is the image they associate with using the internet isn’t too surprising. After all, many users do not know or care that other browser are available. But the disproportionate advantage to Safari is what really makes this design poor.

The problem is that for the user, screens such as this one are a roadblock to the task they they actually want to perform (in this case, using the internet). And, as Asa notes, the most common user behavior when confronted by a roadblock is to take the action they believe will most effectively remove it.  Because of this, in user experience design it’s standard practice to present two paths through a setup: a well-marked “express” path of giant buttons and recommended options presented first in lists, and the “advanced” path for users interested in tailoring their configuration. This allows users who do not want to configure options to quickly get the setup that is designed for most people. By presenting Safari as the first item in a list, this ballot implies that it is the item recommended to most users.

Compounded with this problem is the fact that first placement on a ballot gives an advantage even outside of computing. Daniel Ho and Kosuke Imai found by analyzing California election results that ballot order gives some advantage to major party candidates, but a huge advantage to minor party candidates who may increase their voter share by 50% simply by being listed first. The fact that the first item on the ballot gets an advantage isn’t really debated: many studies have confirmed this (Darcy 1986; Faas and Schoen 2007; Miller and Krosnick 1998; Koppel and Steen 2004; Gierzynski et al. 1997). And there are many reasons for this to be the case. Susan King Roth’s study of voting found that one reason for first-item preference is that western readers begin a visual scan on the top left of a page. When users are presented with unfamiliar tasks, such as an installation screen they’ve never encountered, they have expectations about how to approach it: they try to recognize patterns in the design from similar tasks they’ve completed. (Dillman and Jenkins (1995, 1997)) This is both why western readers begin visually at the top left of a new page, and defer to previous software installers they’ve seen in assuming the first item is the safe bet. Miller and Krosnick also cite the primacy effect as a reason people choose the first item: if given many possibilities, it is a natural response to choose the first one.

So what’s so bad about presenting Safari as the first, recommended item? Aside from being unfair to the other browsers, the problem is that past consumer choice has shown that Safari does not provide an ideal browsing experience on Windows. Taking IE out of the equation because of its advantage as the bundled browser, the free market really does show what Windows users prefer. Safari has the smallest market share of the five other browsers at 2.6%. Frankly, Safari is a good browser for Apple computers, but Apple hasn’t put much effort to make it competitive on Windows. It’s just not their priority. So, by listing Safari first, the ballot is presenting as the recommended item the browser that is least likely to be the one the user wants. This leads to users having a bad experience using the web, and ultimately hurts the user and the market.

How can the design be improved?

So, what would be the best order of the five most popular browser on a ballot? Unfortunately this is a bit of a least-of-evils question, because as we’ve seen the ballot is not a good way to give users choice, and the first item on the ballot will always be given an advantage. With that in mind, here are two ways the order could be improved to address problems with the current ballot:

1. Randomize the order of the top five browsers each time

A randomized ballot would have the benefit by giving no browser the significant advantage of the first spot. It unfortunately does not provide users with any information about what browsers are preferred, but at least it does not give undue advantage to an unpopular browser each time as the current design does.

2. Order of market share, excluding Internet Explorer. (Firefox, Chrome, Opera, Safari, IE)

Holding aside IE because of its bundling advantage, placing the browsers in order of popularity gives some guidance to the user. A user can’t truly judge if a browser is right for them from a couple lines and a logo, so knowing what other users have chosen is actually not the worst way to make a decision. This is essentially crowdsourcing: if 60% of users prefer a particular browser, there’s essentially a 60% chance that a particular user will prefer it. IE still gets the huge benefit of its logo, familiar to nearly everyone who will see the ballot.  In fact, I predict this will be an even bigger factor than browser order. That’s why placing the IE logo last does not put it at a real disadvantage.

3. Edit 10/15/2009 at 4:50pm PST: Probability ordering by market share

I wanted to add one more option to this list that may be the strongest.  It’s an idea I’d been knocking around for a couple days, which Wladimir Palant and Ben Morrow came up with independently: probability ordering by market share.  For the first four spots, give each browser essentially the percentage chance of being first that they have of the total market share.  So, Mozilla would be first about 50% of the time, Chrome would be first 30% of the time, Opera 15%, and Safari 5%.  This allows for the market forces to have some weigh over placement, but doesn’t consistently benefit one browser. The problem is, it still puts some users at a disadvantage who randomly get a less popular browser as the first on the ballot.

Animation in Firefox: Area 1 of 3: Movement of toolbar items within rows

For the next three posts, I’m going to be highlighting three areas of the Firefox user interface that could benefit from animation. Stephen Horlander and myself have been looking at Firefox with an eye towards where movement could make Firefox an easier, more appealing, and perhaps even faster experience with movement.

First, it should be asked why we would add animation Firefox. Animation in the browser is a tool, but not a goal unto itself. Wherever animation is used, it should be with a purpose (not “it looks cool”) and benefit to the user (not “makes user look cool.”)

afi011

Like many web technologies, animation is a useful but easily abused tool. The early web and the dawn of the .gif saw animation heinously overused with blinking, spinning, and scrolling animations added to sites because they looked cool.

As the web calmed down a bit and web and interactive design began to develop, designers and developers found that animation could be beneficial to users. For instance, it can make tasks seem more like real-world affordances, and thus easier to visually understand. It could give users feedback on how digital objects were being moved or manipulated. And yes, they could make interactive experiences more visually appealing.

The first area we feel could benefit from animation is the movement of toolbar items within their rows on the Firefox chrome. This includes buttons like Home and Reload, the bookmark bar, and tabs. Currently, these items can all be shifted and reordered, but little visual feedback is given for these tasks. For tabs, only a thin strip shows where a dragged tab will be dropped.

current_tabdrop

By adding animation to the process of rearranging items, not only will Firefox feel more lightweight and adaptable, but it will be more visually clear what the user is manipulating and how the UI will be changed by letting go. For instance, animations of tabs being manipulated is essentially live preview of tab rearrangement: if a tab is slid to the right and an animation shows it doing so, releasing it only makes permanent what is being shown. This is similar to the tab animation motion currently in Safari and Chrome.

tab_rearranging_animation

Because tab tearoff and tab rearrangement would utilize similar mouse movement, some thresholds should be added to prevent users from accidentally performing an unintended action. As Shorlander recommended, a “soft snap” could make tabs within a region of the tab bar slide, and falling outside that region causes them to tear off.

Slight animation could also give newly created tabs the feeling of organic growth into the browser.

new_tab_animation

(more details in the wiki)

The above sketches are based on work by Stephen Horlander.

Different use cases for live video want different display options

In my last blog post about live video controls, I post some sketches of a prototype which could store some live video in a buffer for playback.  Thanks to everyone for the feedback, which was all useful.  I did want to draw attention to one point that James Heaver touched on: different uses of live video benefit from different ways of displaying the current time.  James uses the example of watching a live football game, where knowing what quarter the game is in is more useful than knowing the actual time.  In other cases, knowing the actual time (“4:30pm”) rather than the relative time (“you’ve watched for 4 minutes”) is more useful.  Here’s some examples of uses for live video that could require different time displays:

live_video_options_2

As we develop the video controls, allowing developers the flexibility to decide which display time and/or labels suite their content will be important.  Some video players today allow for toggling between relative and absolute time by clicking the timestamp: certainly an easy way to allow for both, if not very discoverable.  We may find there’s other ways to improve usability for high traffic events, such as sports games or shuttle launches, by storing buffered video remotely rather than having users buffer it individually.  Gerv points out that dynamically degrading video over time can allow for more content to be buffered, and Faaborg notes that there are instances that the user may want to save as much video as possible: two excellent points, which stress that making the video tag open and adaptable for the many kinds of content it can display is a primary objective.