All posts in Next Version

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

By On June 16, 2010 In Add-ons, Features, Firefox, Next Version, User Experience With Comments Off on Removing Firefox’s Status Bar and Rehousing Add-on Icons (Part 3 of 2) (wut) Permanent Link to Removing Firefox’s Status Bar and Rehousing Add-on Icons (Part 3 of 2) (wut)Permalink

It’s World Cup month! Let’s start it out right. With another post about removing the status bar.

I know I implied in my last post that you’d be free of this topic forever, but something was bothering me. A piece of the puzzle was missing. I talked it over with my skilled user experience cohorts last week. Whiteboards were involved. I think the kinks were worked out.

The problem with putting add-on icons in the bookmark bar by default is that Firefox’s interface could become easily overcrowded if add-ons add more than just a 16 by 16 pixel icon. If an add-on creates a long horizontal widget, for instance, the whole bookmark bar could taken up after its installation.

Also, many add-ons have come to rely on bottom-anchored functionality – partially because of the location of the status bar. Firebug, for instance, uses a status bar button because its interface is anchored to the status bar.

My first post on this topic noted that users should be able to easily move their add-on icons and widgets wherever they want just by dragging it – to the bookmarks bar, the UI panel, the title bar, wherever. This is still going to be a huge benefit to users who wish to configure their browser. Where add-on icons should be encouraged to install by default is the open question. My proposal is this:

When a user has no add-on installed, there is no status bar.

As soon as the user installs one add-on that wants to use the status bar, a small bar appears in the bottom right of the Firefox window. It’s only long enough to accommodate the add-on icons and widgets the user currently has installed.

If the user hovers over the status bar, a small arrow appears on its left.  If the user clicks this arrow, the status bar shrinks into a small button in the bottom of the window.  This button gives a faint glow as the status bar animates into it.  If clicked, this button will bring the status bar into visibility again.  The button is only visible if the user mouses near it, minimizing visual clutter.

The benefit of this design is that only the smallest possible status bar is shown, and if the user prefers it can be entirely dismissed. The panels for rich interaction would still be added to the API, as well as a way for add-ons to identify themselves as acting on the current page content (perhaps via a subtle “glow” effect).

I think this design addresses the multiple goals for add-ons in the ui: minimal disruption to current add-on functionality, minimal visual clutter, and trivial configuration if the user wishes to modify the default behavior.

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

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

Recently, I wrote about Firefox’s status bar and how we’d love to remove it, relocate its functionality, and dedicate that area back to page content. Though many add-ons currently place icons in the status bar, these icons could be displayed elsewhere in Firefox’s user interface. By treating add-ons as UI elements that users can move within Firefox’s UI, the bottom of the browser window could be dedicated to content while the functionality of add-ons preserved.

I proposed that by default, add-on icons display in the bookmark bar of the Firefox window.

But, if the user wishes, he can move the add-on icons to other areas. Firefox can subtly change the appearance of an add-on icon to visually match where it is placed.

Several commenters on my previous post noted that they preferred add-ons in the bottom right of the window, both because of particular add-on functionality and familiarity. Indeed, it should certainly be an option to reenable the status bar, and one way to do this should be to drag an add-on icon to the bottom of the window in customize mode.

The cases that would be especially suited to enabling the status bar are add-ons that require long, horizontal space in the main UI. Especially newer add-ons built by Jetpacks are increasingly using this horizontal space in creative ways. If users want this kind of functionality, giving up a significant portion of the bookmark bar should not be the only way to achieve it.

While this horizontal layout that some add-on developers choose is useful for many kinds of information display, it takes up a lot of space in Firefox’s interface and may not always be necessary. Providing API support for rich content panels that launch off of add-on icons could allow add-ons to provide rich interactive content, accessible with a click, that takes up little UI.  This is a win for developers because it would enable them to easily add rich content to their add-ons.  It’s also a win for users, because accessing rich add-on content won’t always mean sacrificing interface space.  Some possible uses for such panels include:

Firefox engineer Dietrich Ayala and Labs engineer Myk Melez are already at work to add an API to Jetpack that will allow these panels to launch from add-ons.

Defeating the Cookie Monster: How Firefox can Improve Online Privacy

By On June 2, 2010 In advertising, Features, Firefox, Next Version, Privacy, Security, User Experience With Comments Off on Defeating the Cookie Monster: How Firefox can Improve Online Privacy Permanent Link to Defeating the Cookie Monster: How Firefox can Improve Online PrivacyPermalink

As we choose priorities for the next version of Firefox’s features and development, the Firefox team has been considering the state of the web and looking for areas where online content has changed faster than browser functionality. One area of concern is the growing use of private user data, especially by advertisers. User data being silently and persistently passed between sites and advertisers is disturbing for those with an interest in user choice and transparency on the web.

Privacy vs. Security

Privacy and security are related but distinct topics. Security refers to the prevention of material harm to the user. Avoiding theft, fraud, and data loss are all security issues. Browsers have been working to improve security for decades, prompted by increasingly sophisticated viruses, malware, and other exploits.
Privacy is a broader topic than security. It refers to users’ control over what they reveal about themselves online, whether or not what they reveal might lead to material harm. All internet users reveal some information about themselves to some sites, but the user has privacy if his discretion determines what information is shared with whom.

Firefox has Local Privacy but Needs Network Privacy

The Firefox team has already done some great work on local privacy with improvements such as Private Browsing mode, Clear Recent History, and Forget about this Site. These features give users better control over when their data is exposed and hidden on their own computer. However, wider privacy issues surface when data is shared over a network.

One major problem of the modern web is the ability for private user data to be collected by advertising companies via third-party cookies.

If sites provide rich interaction, they usually require user data. The problem occurs when users willingly share data with a site they trust, but unknowingly their data is shared with other sites and companies via third-party cookies. This is common practice and a growing revenue model online. It first received national attention in November of 1999, when the Federal Trade Commission held a workshop on online profiling and reported that it presented a privacy concern to consumers. The practice has grown since then, despite some failed attempts at regulation by the US’s Federal Trade Commission, the Interactive Advertising Bureau, and Britain’s Office of Fair Trading.

Any website you visit can contain ads and other components that send cookies from your browsing session on the domain you trust to an advertising domain. These third-party cookies can be used to track information about users across multiple sites and multiple browsing sessions, allowing web habits to be profiled and tracked. This data can tell companies limitless kinds of information, such as what purchases you make, what news you read, your income, if you’ve applied for work, and what dating sites you prefer. One manifestation of this data sharing is seeing to ads targeting users based on data and actions from other sites.

The ability for advertisers to gain and use this data violates user privacy for several reasons:

  • It’s nearly impossible to detect. Much of the data-sharing happens in the background during a browsing session without asking or notifying the user. Users usually only discover what has happened when they are seeing targeted ads (long after the data has been transferred).
  • It occurs without user consent. Of the sites that are even aware of third-party cookie sharing, few give users control over how their data is shared with advertisers. Sites that do offer preferences sometimes phrase them in ways that disguise their purpose, such as “do you want relevant content to be shown based on your usage” rather than “do you want ads to be shown based on your personal data.”
  • It contradicts the user’s reasonable expectation of privacy. Some sites that knowingly share data present a false image of being responsible with user data. They may show the user preferences that imply control, assure users that their data is “safe,” or offer to let users read a lengthy privacy policy in order to hide their actual practices. Of course there’s a very special hell set aside for sites that change privacy settings to be more permissive once users have already signed up and entrusted their data.
  • It’s nearly impossible to prevent. Even a user who is privacy conscious and reads all privacy policies, keeps his privacy settings up to date, and avoids sites that don’t guarantee privacy isn’t necessarily safe. Any site he’s given data to could potentially use it without asking, and third-party cookies could be sent via ads and web bugs without the knowledge of the site’s owners. Heck, any site could be scraping identifiable information from his digital fingerprint.
  • It potentially embarrasses the user. Data sharing via third-party cookies takes information given by the user at some point in time and exposes it at another time. While the user may be discrete about where he is viewing certain content and even use Private Browsing Mode for items to not appear in history, advertisers using third-party cookies can expose user actions at times out of the user’s control.

So what can Firefox do to improve its story on privacy?

1. Provide intelligent defaults for third-party cookie behavior

Simply disabling third-party cookies isn’t the solution. Third-party cookies are necessary for legitimate web functionality such as embedded content, session management, mashups, etc. Most bank websites depend on third-party cookies for functions such as bill paying. The goal should not be to outright disable third-party cookies, but to be more intelligent about what behavior is allowed.

The http-state working group is currently working to produce a specification in multiple documents to lay out how clients should behave with regard to cookies (see current drafts here). Dan Witte, the cookie module owner at Mozilla, has been in communication with them and is doing his own work to develop a modern cookie standard. The goal is to create a guideline that Mozilla can follow that aligns with our Manifesto to protect user choice on the web. Dan’s already working on one way Firefox could address the problem by enabling third-party cookies, but only temporarily. His idea is to keep third-party cookies active only for the life of one tab. When the tab is closed, the cookies are deleted – advertisers could not track users from site to site. Dan will be blogging about this later with more details on his work.

2. Give users better control over how sites can access their information in Preferences

Currently, Firefox gives users precise, fine-grained control over the many ways that sites can access user data. All the user needs to do is change their on each Preference panel that effects site privileges:

As can be seen above, the current Firefox interface gives each site privilege type – saving passwords, cookies, etc – its own separate preference window. This design is framed around the implementation model rather than the user’s mental model, meaning it’s designed in a way that corresponds with how it was built rather than how users perceive the action they want to take. Having an individual window for each permission makes sense from an implementation standpoint, because each site privilege is separate in code. From the user’s perspective, however, it’s impossible to tell what privileges a particular site has. A better design would present controls in a site-centric rather than technology-centric view. If a user decides that he doesn’t trust site X and doesn’t want it to have any access, it would be more efficient to control all of site X’s access in one – not 15 – Preference windows. Alex Faaborg made this mockup to illustrate how a site-centric UI could be achieved:

While all of Firefox’s Preferences need to be improved, including site-centric privacy controls like Alex’s above for Firefox 4.0 would go a long way towards putting users back in control of their data.

3. Give users better control of their data while they are browsing

While a site-specific Preference panel will help users have better fine-grained control of their privacy when they’re configuring Firefox, there’s some options and information that can be exposed while the user is browsing. If a site has access to geolocation, for instance, this should be constantly indicated in Firefox’s interface. If a site is storing a password, this should be easy to change or remove without opening Preferences. Firefox’s Site Identity Button, which currently gives very little information about a site, could be improved to give information about a site’s privileges and the ability to change them.

It’s our goal for Firefox 4.0 to give users more control of their data, both by literally giving them controls and, more importantly, creating intelligent defaults that protect a user’s privacy and anonymity without breaking web functionality. It’s my hope that even simply exposing what access sites have to data will be positive for the web by eroding the sense of false security that many sites try to create for their users and creating awareness of and control over how, where, and when data is being shared.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Add-ons Manager Redesign Update

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

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

Add-ons in the Content Area, Oh my!

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

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

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

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

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

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

A Model for Firefox’s “Extra” Windows

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

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

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

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

Design Influences

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

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

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

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

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

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

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

Themes and Personas in the Add-ons Manager

By On March 4, 2010 In Features, Firefox, Next Version, User Experience With Comments Off on Themes and Personas in the Add-ons Manager Permanent Link to Themes and Personas in the Add-ons ManagerPermalink

Personas and Themes are a bit of a strange beast in the add-ons kingdom. Themes completely change the look of Firefox, from its color and menus to the shape of buttons. Currently, Firefox needs to restart to switch Themes. Personas, or “Backgrounds” as I’ll refer to them here, are a kind of light-weight skinning which puts an image behind Firefox’s user interface, but makes no other changes. These can be applied without a restart.

This gets slightly complicated when a Theme and a Background are used at the same time. For instance, if someone wants to use a Theme with circular buttons, but also a freakin Twilight Background behind them. So, the UX question: how explicitly should we make the difference between Backgrounds and Themes in the user interface for the add-ons manager?

One solution is to ignore most of the complexity: allow users to use both a Theme and a Background and simply mark what is being used. This makes for the simplest interface, but can lead to the user being confused about results (“Why does using this Theme disable my other Theme, but my Background remains the same?”).

Or, we could be more explicit about it: give the user an indication that they can only have two items, and only one of each type.

Towards a Cleaner Firefox Startup

By On February 25, 2010 In Firefox, Next Version, User Experience With Comments Off on Towards a Cleaner Firefox Startup Permanent Link to Towards a Cleaner Firefox StartupPermalink

Notifications when Starting Firefox

What should happen when you start up Firefox?

Nothing. No notifications, no updates; nothing but a clean window ready to browse. This simple startup has been a goal for the Firefox user experience team for awhile (Faaborg has outlined our plan for eliminating startup dialogs here). As add-ons manager updates are among the worst current offenders, moving these notifications away from the startup process has been one of my goals in its redesign.

Why is it so important to make Firefox’s startup clean? The obvious reason is speed. Notifications and updates appearing and then requiring dismissal wastes valuable seconds. But there’s also interaction drawbacks when windows pop up. If a user is launching Firefox, he probably has a goal in mind, and that goal is unlikely to be updating his add-ons. By seeing an update notification, the user is being distracted from the task he wanted to achieve and forced to give some of his attention to a new task: dealing with or closing the notification.

Crashing Without Session Restore

However, what if we took this one step further, and didn’t try to automatically restore a user’s session after a crash? What if instead there was just one window, ready to go, with a link to restore the previous session?

Currently, if Firefox crashes once, the session restores when Firefox is reopened. If Firefox crashes twice in a short space of time, it’s assumed to be because of bad content from the session. That’s when Firefox throws its famous “Well, this is embarrassing” screen, and gives the option to restore the full or partial session.

This is fine in the expected case of the user crashing because of bad content and wanting to restore their session and get back to work. The problem is that forcing Firefox to quit, or deliberately crashing it, are increasingly becoming alternatives to quitting. Since websites often throw warnings before they close and stalling sites can mean waiting until a command can go through, it can be much faster to crash than quit normally. Here’s a couple ways this can go wrong:

Scenario 1:

Sally has 15 windows open, each with lots of tabs. A few websites she opened are starting to stall. Sally could wait until those pages resolve their issues, but her session is getting bloated and she really just wants to start over with a fresh session. Rather than wait for the stalling pages, Sally forces Firefox to quit. However, when she reopens Firefox, it tries to restore the session she doesn’t want. Sally quickly forces Firefox to quit a second time. Now she has the new session she wanted, because Firefox assumed her two crashes were due to bad content bringing down the browser.

Scenario 2:

Oliver’s first date with Annah is going great, and she’s come back to his apartment. Oliver knows the way to win her over is to show her that hilarious video with a cat falling down stairs. Annah sits down with Oliver at the computer, and Oliver goes to open Firefox. But, he hesitates. The last time he used Firefox, did he quit the browser normally, or did he force a quit, or did he crash, or did he turn his computer off? If it’s any of the last three, his last browser session will automatically display in front of his innocent date. Oliver isn’t sure he wants that. He opens Chrome instead.

If we give a link to restore a session rather than restore it automatically, Sally can use crashing the browser as a way to get a new session and Oliver can ignore his last session and watch his video.  When someone actually crashes they only need to click once, and they’re back where they started.

Newer Entries →