All posts in Firefox

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.

Video controls for live feeds: instant replay for the web

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.

2_other_live_player_examples

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.

3_live_mode_player

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.

4_live_mode_player_with_buffer2

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.

5_slider_moving_backwards

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.

7_slider_break

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.

Improving everyone’s favorite feature – address not found

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:

current_network_error

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.

big_three_browsers1

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:

four_suggestions

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!

UI Redundancies

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

Do you use your back button?

Patrick Dubroy suspects you don’t.

Today he spoke at Mozilla about his very interesting research and field studies regarding how people use tabs in Firefox. He found that people who don’t use tabs really aren’t using the back button much – his participants’ median was once per 50 clicks, and that the more tabs a user opens the less they use the back button.

This really gives voice to some of the thoughts I was having about how the back button and tabs are related. In a sense, the back button is allowing you to go back in history blindly – there’s no way (other than remembering) to know where pressing back will take you. Opening new pages in tabs, however, give you a visual indicator of where you’d been, and allows you to skip backwards in time as far as you need. It can also prevent procrastination by showing you what you were doing (“Right, I was answering an email before I opened 5 Wikipedia pages”).

Another problematic relation between tabs and the back button, as Patrick pointed out, is that your 10 open tabs may all have different back histories. How can you possibly be expected to remember all 10 histories? You can’t, and if you have 10 tabs you probably aren’t using back much as a result.

Another problem of the back button is that it doesn’t work with all media (such as Flash sites) and sucks with web applications (like Google documents). I’ve been trapped many times by accidentally pressing back while banking or using a form, only to find that my data has been lost. These sites tend to offer their own navigation methods.

So, what tabs and the back button have in common is that they are ways to manage browsing histories. Tabs may have made an improvement on the back button, but they still present some navigation limitations.

HTML5 video tag update

Some changes are coming for the HTML5 video tag in the nightlies:

– Time-scrubber will be implemented
– Volume control will work (not just mute/unmute)
– Controls will be invisible until mouseover for videos that play on load, and visible until the user presses play for videos that don’t play on load
– Some graphic spiffups:

ffxcontrols_new2

The graphics are being changed (in part because of your feedback) with attention to providing better contrast on differently colored backgrounds.

Other features coming up soon are notification when a video is buffering, and perhaps a time elapsed/total time indication.

The design for the controls is about as simple as it can be, because much like the browser, it is there to help you navigate your content but not compete with your content. I was surprised looking around the web at how over-designed and branded so many video controls are.

diva_video_controls

HTML 5 video tag, pirate edition

Ahoy mateys of the open source seas! Here’s another thing coming in Firefox 3.1: open source HTML 5 video support! This is going to bring some cool new functionality to developers, such as being able to access video elements through the DOM, intersperse video with other web content, and manipulate playback with JavaScript – all without the need for lubber bilge monkey plugins (see blizzard’s post).

A project I took over from the comely wench Wei was to design the controls for the video tag. So, how should they look? The first design iterations focused on geling with Firefox’s overall branding. However, thinking the problem over, these video controls are different from Firefox’s chrome and menus because they appear in the content of a page itself. So, though maintaining Firefox’s brand look & feel throughout the browser is important, I think not interfering with web content is more important. To create “Firefoxy” controls on videos would essentially brand a user’s videos. So, I’m proposing something more neutral and would love feedback:

New Control+Tab Discussion Thread

Thanks everyone for contributing to the discussion on Control+Tab on my posts here and here. We’re going to be making the main thread of discussion from now on here, in dev.apps.firefox’s Google Group, so all the conversation going on in bugs & blogs can come together as we narrow down the design space to the final solution. I encourage everyone who commented earlier will continue to join in!