(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.

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

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:

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.

(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.

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.

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.”)

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.

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.

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.

(more details in the wiki)

The above sketches are based on work by Stephen Horlander.

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:

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.

Watching live video online is generally a great experience. It’s a way to watch important world events without a TV, a way to view with friends without syncing, and still the best way to see a shuttle launch naked.

But online live video could be improved. For instance, there’s usually no way to rewind video to see a clip again, nor a way to pause and watch video from where you left off.  In fact, current implementations of live video have very few features – usually they are adaptations of regular video controls, but with non-interactive elements such as stationary or removed timelines.

We think users would benefit from the ability to pause and go back in live video by keeping some amount of the video buffered.  However, this presents a few design challenges:

• How to visually represent when the user is “live” vs. viewing buffered video

• How to visually represent the amount of video in the buffer

• How to make it easy for the user to jump between live and buffered video

Limi and myself did some brainstorming to develop ways to present this functionality. Below is an idea we had that we’d love feedback on. It’s based on the idea of a “live mode,” which users can enter and exit via the video controls. By default, the user begins in live mode (the box on the right of the timeline). As the user watches the live video, the timeline to the left encompasses how much video has been buffered. So, after one minute the timeline represents one minute in length, and after two minutes it represents two minutes. To give an indication of how much time the bar represents, ticks marking minutes will scroll left as the video plays. Clicking the live mode button or moving the slider back to the live point puts the user back in live mode.

However, eventually the video will reach the maximum that can be buffered. For the purposes of these mockups, we’ll say that 10 minutes is the limit. After the video plays for 10 minutes, the beginning of the video is dropped and no longer accessible. The user sees this as the 0:00 mark disappearing from the timeline, and higher time markers continuing to scroll left.

If the user pauses the video, he exits live mode and the slider moves off of the live mode box. A visual indication will show that the video is no longer live – perhaps by fading the live mode and/or changing the shape and color of the slider. As the video is paused, new live video will be buffered and old video will continue to be dropped, moving the paused slider and the timeline left.

Once the slider has moved back 10 minutes, the new video is no longer buffered: only the ten minutes immediately after the pause is stored. This is so that when the user returns, the video will play from the point they left off and not the somewhat arbitrary 10 minutes before the live video. At this point, the buffered 10 minutes and the live point are no longer connected – a visual indication such as a break of the timeline will indicate this.

So, what do you think?  Was this difficult to understand?  It’s a bit of a shift from commonly understood video control interaction, but I think it may be intuitive once users play with it.  I’ll be eager to find out.

You can read more about our progress in the wiki.

P.S. This is the first blog post I’ve made in awhile, but unfortunately for you I’m going to be posting a lot more frequently, starting now.  Please don’t cry, they won’t all be this long.

Bugzilla lately has been going through a bit of a redesign process. Guy Pyrzak has been leading the initiative and has been making some very useful observations and changes. For instance, he observed that one issue for users is that new users sometimes don’t know where to begin; the initial path to a common action like creating an account or filing a bug isn’t immediately clear. In the recent design iterations, the path for new users – both to file a bug and create a new account – is much more eminent.

As I see it, the main challenge of the Bugzilla page is to cater to both users that see the page a million times a day and new users who just want to file a bug. It may be worth noting that a user filing a bug for the first time might be angry as the result of that bug, and thus less willing to search through menus. I haven’t seen Bugzilla’s data, but I’m guessing that users tend to fall on one of these two sides – very new or very experienced – with less in the middle. So the problem is one of focus – giving the new user a clear path, but not patronizing experienced users.

So here’s my quick suggestion. I like very much Guy’s idea of showing common  actions prominently, and included those in the design below. Other than that, I tried to group relevant data (navigation at top, login info at side) so that possible tasks were separated a bit more clearly.

Note: This is a design for default Bugzilla, not Mozilla-specific Bugzilla. However, since I decided to do a followup post with design suggestions for Mozilla’s Bugzilla, I’m happy to hear feedback about that too.

One area of Firefox that could use some improvement are the warnings we give when pages are not found.  These could be network errors, firewall issues, URL typos, etc.  Curtis Bartley has been looking at this issue and documenting progress here, and Jesse Ruderman started a bug with some insightful comments here.

Ideally, a good error page does two things:

1. Tells you what’s wrong in a way that’s both understandable and diagnosable
2. Helps you decide what to do next

If I type “www.example.cmm” into Firefox now, here’s what I get:

Internet Explorer, Chrome, and Safari all have slight variations on this page.  IE’s isn’t very useful; it gives easy text but no tools. Safari’s design is very minimal, but it does offer search.  Chrome is cutesy, but also intelligently offers suggestions based on what was typed – the most useful of all three.  All three browsers offer additional information via a link, thus removing the bulk of explanation Firefox currently shows.

So what should Firefox do?

For blatant, common URL typos, I think we should redirect straight to the correct URL. Google.com currently goes to http://www.google.com, why shouldn’t google..com or ww.google.com? URLs themselves are an example of forcing users to behave like machines – rather than the preferable reverse – so why not take a step in the right direction by making them more forgiving? (bug freakin’ 175634)

For the addresses that are not blatant typos for existing pages, there’s a few approaches we could take. User-experience-wise, I would love to be able to do better detection of what the problem is and direct the user towards the likely solution. Rather than presenting the user with questions as we do now, we could give them an answer.  We should aim to provide a consistent UI, but perhaps we could change the text sightly based on what the user inputted and try to find the most helpful suggestion. When there’s a very likely solution, that should be the most obvious next step available.

Here’s four scenarios that would cause a 404 today with text customized to what what the user imputed:

While catching all of these scenarios may not be feasible for now, we could be concentrating harder on giving users tools at a 404, not just a warning. I’d love to hear you feedback on this – especially what would help a tech-saavy person such as yourself when you hit a 404.

Just for fun… spoilers!

Firefox has a great user interface. It’s come a long way and a lot of very talented designers have worked to bring it to a place of visual and interaction stability. So, the question of how to improve becomes more difficult, but also more interesting.

This is an observation more than a criticism, but have you ever noticed how many redundancies occur in Firefox? Chrome’s tack has been to eliminate some of these and scrap the interface down to the bare minimum, which is probably going too far, but perhaps there are ways to clean the UI in places without sacrificing functionality or usability.

I’ve been tagged by Joe Drew and Grey Hodge for Seven Things, the syphilis of blog memes.

The rules

1. Link to your original tagger(s) and list these rules in your post.
2. Share seven facts about yourself in the post.
3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
4. Let them know they’ve been tagged.

Seven things

1. I was obsessed with many things as a kid, and one of those was lizards. This started at age 8, when I realized my mom would not let us get a second cat but had no policy regarding reptiles. In the beginning I got geckos and anoles, but eventually I grew my collection to about 15 lizards at a time. At its peak, I was managing complex feeding schedules and vitamin ratios, ordering weekly boxes of live crickets, and seeing a specialized reptile vet when something was sick. I was also the youngest regular participant at monthly Missouri reptile conventions, where my favorite attendees were the biker dudes with iguanas in matching miniature leather jackets.

2. My first website, Jennynet, launched in 1992, when I was 8. It featured a Myst fan site (in ‘93), a care guide for various reptile species (see #1), a form you could fill out if you wanted me to send free stickers in the mail, links, a bio, and a shoutout to various friends and relatives (which proved useless since none had modems). The HTML was written in SimpleText documents, and the graphics were made in Kid Pix.

3. My first official paychecked job was as a train conductor at a zoo.

4. I love altitude, and my favorite physical activities involve it; hang gliding, flying planes, and skydiving. It’s my goal to get certified in all three in the next few years.

5. Two people have proposed to me.

6. My vision is horrible. I’m legally blind (-8 in each eye), and colorblind too. I wanted to be a fighter pilot as a kid, but was told it would never happen because of my vision. Turns out they were lying because of laser correction. Oh well.

7. Last week I nearly rick-rolled Nancy Pelosi. I got tickets to Obama’s inauguration by calling Pelosi’s office early and getting on their list, and subsequently flew to DC for Obamastock (which was awesome). Afterwards, everyone who got tickets was invited to a Pelosi-hosted lunch near the capitol. I went, wondering if Pelosi herself would show up for congressional cold cuts. She did! This was only a short time after Pelosi ruined rick-rolling by releasing a video of her cats which cut to Astley halfway through. So, seeing Pelosi across the room, I realized we had to exact revenge (for the glory of the internets). I turned to my friend Akiva and asked what devices he had on him. He had an iPhone – perfect! I suggested we go up to Pelosi and say oh, Nancy dear, you won’t believe the horrible video of you on YouTube, here, have a look – and then pull an iPhone Astley on her. Unfortunately, by the time our scheme was ready to go, she’d slipped out of the room and we couldn’t find her afterwards.

I’m tagging no one, because this madness must end.