Link Targeting

From MozillaWiki
Revision as of 23:07, 21 September 2009 by Eyaler (talk | contribs) (Moving Focus after Closing Tabs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Background

What follows is an analysis of some of the window opening features of some modern tabbed browsers:

Firefox Browsers

There are several ways links can be opened in Firefox:

  • regular links, which replace the current document when loaded
  • links that open new windows by using the "target" attribute (e.g. targeting a new blank or named window)
  • links that are opened by script without sizing or positioning parameters (basically the same as those opened using the "target" attribute)
  • links that are opened by script using paramaters (called window "features") that set the size and position of the window.
  • links sent from external applications e.g. via DDE on Windows.

These different types are handled in different ways by Firefox 1.0 and Deer Park Alpha 2.

There are several places links can be opened as well:

  • Replacing the document loaded in the most recently focused tab/window
  • A new tab in the most recently focused window
  • A new window

When a link is opened in the foreground, when it is closed the previous tab is selected

Firefox 1.0

All links that would open a new window, whether by using the "target" attribute, or by using script are opened in new windows.

Options exist for sending links opened by external applications into each of the places where links can be opened, with the default being the last tab/document in the most recently focused window.

Options exist for forcing links that would open new windows by use of the "target" attribute or script into new tabs or replacing the same document, but these were hidden in Firefox 1.0 because they were not yet well tested.

Deer Park Alpha 2

All links that would open a new window, whether by using the "target" attribute or by using script are opened in new windows, with the exception of those sent by external applications, which are opened in new tabs.

The same collection of options as those which existed in 1.0 are present, except the ones for the "target" attribute/script opening are now exposed in the user interface.

Microsoft Internet Explorer 7 Beta 1

All links that would open new windows open new tabs, whether from internal sources ("target" attribute, script) or external applications. When a tab opened in the foreground is closed, the previous adjacent tab is selected.

There are only three preferences in IE 7 beta for XP. They are:

  • always open pop-ups in a new window (default off)
  • always switch to new tabs when they are created (default off)
  • enable tabbed browsing (requires restart) (default on)

Apple Safari 2.0

Safari defaults to having tabbed browsing turned off entirely, with none of the standard shortcuts or UI appearing until after the feature is activated using the "Enable Tabbed Browsing..." option in the Tabs preferences pane.

Once this feature is enabled, all links that would open new windows, whether from internal sources ("target" attribute, script) or external applications open new windows.

There is an option to control where links from external applications are opened - windows or tabs. There are no options to control where internal links are targeted

Camino 0.9

All links that would open new windows open new windows. When a tab opened in the foreground is closed, the previous adjacent tab is selected.

Options exist to target links opened by external applications into a new tab, a new window, or reuse the most recent tab in the most recent window. There is no option to control where internal links are targeted.

Opera 8.0

All links that would open new windows open new tabs (called "pages"). There are options to control how (maximized, tiled, same as last size) and where (at end of tabstrip or next to current tab) these new tabs are opened, including an option to "always maximize, even popups".

When a tab is closed, the focus shifts to the previously selected tab. If the previously selected tab had been closed, focus shifts to the next tab to the right (if it exists).

Current Flaws

Tabbed browsing is designed to make managing multiple documents easier than the tools provided by most operating systems. A variety of user classes find multiple document browsing useful - experienced computer users, those who use the internet heavily either for recreational, educational or work purposes (e.g. employees at companies who rely on a large number of internal tools). While the level of familiarity with technology varies a large amount within this group, users within this group are usually well aware of multitasking and the skills required to do it.

The other class of user is the home user, many of whom use the computer and internet for a small set of targeted uses - email, chat, a small amount of recreational web surfing etc. This is a fairly large contingent.

More and more, as Firefox gains marketshare and aspires towards significant mainstream penetration, working well for this latter group becomes important. The Firefox project charter [1] targets the "widest possible set of people".

Lack of Discoverability

Tabs currently suffer from a lack of discoverability due to few obvious access points, lack of user education etc. There are a number of strategies that could be adopted to improve this situation, but those are mostly outside the scope of this document. Link Targeting intersects discoverability though in two very different ways:

  • There is an argument that forcing more links into new tabs than windows would promote discoverability. The other is that
  • Lack of user understanding of multitasking (many users are novices and don't aspire to be anything more given their usage patterns) means when users are presented with tabs as a result of some default configuration setting, they are not equipped to deal with it due to lack of experience.

The best demonstration of the second point is to consider the worst case scenario of a novice using a Firefox browser configured the way Deer Park Alpha 2 is by default:

  1. User has page open in single browser window
  2. User receives an IM, clicks on IM window and clicks link sent by friend
  3. Link opens in new tab in browser window

The user looks at the page and is now done with it. They now want to get back to where they were before. With Firefox 1.0's behavior they could click the Back button to go back (although see discusson on this in the Complex Options section below). With Internet Explorer 6.0 and earlier's behavior on Windows they could close the new window that was opened using either the X button, the File menu or the keyboard shortcut and be presented with their previous page, which is most often the window underneath the newly opened one. With Deer Park Alpha 2 they need to:

  1. Notice that the new document has opened in a tab (i.e. notice the tab strip)
  2. Discover how to close the current tab

This involves them discovering the X button on the far right of the tab strip. The user might first be inclined to click the X button on the window (most users don't remember keyboard shortcuts, at least few further than clipboard operations and those implemented fairly consistently across Windows applications - Ctrl+W is not). This would present them with a warning dialog about closing multiple tabs. They are now yanked into a new world of tabbed browsing. Is this dialog the first exposure to the concept of tabbed browsing we want novices to have?

The user might also use Ctrl+W (although less likely, see above) or the File menu and discover the Close Tab item there.

All of this assumes they even notice the tab strip at all. The tab strip is about the same size as the Info bar and appears in the same spot. We have good evidence that shows that users don't notice the Info bar. The tab strip might be sligthly more noticeable assuming the page the user is on has a meaningful title (and the user noticed the title) and icon, instead of something like Untitled Document - but that's not always the best assumption.

It should be clear that extreme novices are being discussed here, but as we work towards more penetration it is these users we must be thinking of - people who have not made the conscious decision to use our software because it simply came on their computer by way of corporate deployment, ISP, hardware or "by a friend/relative" distribution.

It should also be clear that none of these flaws means that we shouldn't pursue implementation of better discoverability aids, see the brief Tab Discoverability section below.

Complex, Inconsistent Options

Divergence Between Web and Client Applications

Firefox allows links opened from documents (either via the "target" attribute or scripts) and links opened from external applications to be targeted differently, and exposes this all the way up to the user interface. The reasoning for the different implementation locations is related to the different link sources, and slightly different code paths, although the decision to open in a new tab or a new window eventually propagates through a single interface (nsIBrowserDOMWindow).

The flaw in this really is that there is a distinction at all between web and client applications. Companies like Google are pushing richer and richer web application experiences to users. Because of this development model, the behavior when opening a link from GMail (which opens links in new windows using the "target" attribute) is different than when opening a link from Thunderbird or Microsoft Outlook (which are external applications and are thus opened as new tabs by default in Deer Park Alpha 2 (or whatever else the user has set that option to).

(This default setting exposes all classes of users to tabs - while there are numerous novice-level management and discoverability flaws with tabs that remain to be fixed and might cause a number of the issues described above in "Lack of Discoverability")

The fact of the matter is that there should be no differentiation between where links open. An application is an application, regardless of the details of how and where it is implemented.

The only case where this should be different is where an application requests a window with specific placement and size. This is often used by media viewers and other rich applications to show information, media content etc. Firefox already includes a control to force links opened in new windows via script with sizing and positioning features into new windows, regardless of the tab settings. This mode is not the default though and should be - it makes the "Force links targeted into new windows into new tabs" preference more useful, rather than exposing the user to web applications opened in windows that are oddly sized (either too large or too small, depending on the user's window layout).

Poor Target Options

Firefox continues to offer the destructive "most recent tab/document in the most recent window" option, even though this is a rather dangerous choice. In practice, it is all too common for web applications with complex state to lose this when they are navigated away from. This can result in data loss for the user when they have to repeat a complex sign up wizard or re-enter an email. I refer to this option as the "destroy a random tab" option, because if you spend any amount of time away from the browser (e.g. writing a letter in Microsoft Word) and then click on a link in an IM window or in a mail client, you probably don't recall what tab or window was last selected. This was the justification for sending external links to new tabs in the first place. Given the lack of use for this target, it is my contention that it should be removed from the UI entirely.

Some have mentioned the desire to have a tab act as a target for external links (so that all links could be sent to it rather than creating a lot of tabs when reading email, for example - this is one use of the "most recent tab/document" option), although I would argue that that's more in the realm of the extension space.

Other Options

There are other extraneous or poorly worded options in the Tabbed Browsing section, but those are outside the scope of this document.

Closing Tabs

There are some usability issues surrounding the action of closing a tab that haven't been answered well by many of the existing solutions. Opportunity exists for user testing and interaction design to resolve these issues.

UI Widgets for Closing Tabs

Safari, Camino and Opera all provide a close button on each tab, which has the advantage of directly tying the control with the item that will be closed, but has the disadvantages of being easily clicked accidentally and taking up valueable space on the tabstrip (especially of concern when there are many open tabs).

Other systems use a single close button on the tabstrip which will always close the currently selected tab, which has the advantage of saving space and of always being in the same position, but the disadvantage of not being closely associated with the item that will be closed.

Moving Focus after Closing Tabs

When a tab is closed, there are several potential heuristics that could be used to select which of the remaining tabs will obtain focus. The two most popular are:

  • always give focus to tab on right (ie: "close to right")
  • always give focus to previously selected tab
    • where if previously selected tab is closed, then select tab on right

The first heuristic has the advantage of being consistent; focus is always shifted the same way. However, some small-sample usability studies have shown that users frequently open tabs to accomplish some intermediate step in their task (ie: read a definition) and once the tab is closed they wish to be returned to the previously selected tab to continue with their main task.

One potential way of detecting this would be to give focus to the previously selected tab when:

  • a new tab has opened with focus
  • focus does not move from that tab before it is closed
  • new tabs are not opened in the background (Bug 327562)

(see also bug 374165 for a suggested change in the heuristics for tabs opened in background.)

Solutions

Defaults

Because of potential novice confusion and our historic reluctance to force a new windowing model on users, the importance of consistency in application behavior regardless of implementation medium, I believe that in Firefox 1.5 links targeted at new windows should open in new windows, regardless of their source. For releases past Firefox 1.5, steps can be taken to evangelize the efficiency aspects of tabbed browsing and make them more usable for mouse based users (which generally most novices are). See the Tab Discoverability section below for some brief discussion on how this might be achieved.

Options

The set of options available to users then becomes:

Links that open new windows should be opened in:
(*) new windows
( ) new tabs in the most recent window

[x] Hide the tab bar when only one web site is open
[ ] Always bring new tabs to the front [1]
[x] Warn when closing multiple tabs

The set of options controlling links opened from documents and external applications is replaced by the two radio buttons at the top (shown above) and the option to replace an existing document is removed from the UI. The "new tabs in the most recent window" option should really be automatically selected somehow as the user begins to use tabs a lot. Safari provides a convenient hook for this in its "Enable Tabbed Browsing" action, which is the gateway that it could use to reconfigure the defaults, but I don't think we want to go down the path of disabling tabbed browsing by default simply to make the best defaults here more obvious.

The "new tabs" option should set the options for both external applications AND internal links, and in both cases ensure that when the tabs opened by this process are closed, the last tab that the user was looking at is selected. There has been some discussion about this and for best consistency and usability compared to the "new windows" option this is the most intuitive thing to do. The other mode is used mostly only by users who use "background queues" of web pages opened from hub pages (like CNN.com or search results) in background tabs by the non-discoverable Ctrl+Click or context menu methods.

[1] Rewording this preference should also be done, this is not really within the scope of this document, but the current text: "Select new tabs opened from links" is awful, has confused pretty much everyone I've seen read it and does nothing to advertise its association with a very specific mode of tabbed browsing usage - the background queue.

Tab Discoverability

Assuming opening tabs instead of windows becomes the default at some point, we will need to do more to explain to people what they are. Darin suggested showing an info balloon under the tab strip the first time a tab is opened. A convenient way to open a new tab is also required, as well as a more discoverable way to close them (Both Safari and Camino place close buttons on each individual tab).

A comprehensive discussion on improving education surrounding tabs is not within the scope of this document however, and should be pursued independently.

For Firefox 1.5

In order of priority:

  1. Set all link targeting behavior to open new windows where windows are requested, regardless of source.
  2. Set the window restrict option to 2 (so that when the user chooses to have tabs opened instead of windows, windows with specific sizing parameters are not opened in oddly sized tabs).
  3. Set the re-select-on-close behavior to select the previously viewed tab, when tabs opened by document or external sources are closed.
  4. Combine all targeting options into a single boolean value, controlled by two radio buttons (see Options section above).
  5. Re-word the "Select new tabs opened from links" preference so that it's more understandable.

This creates a set of defaults that is familiar to IE users and novices, functions as expected, and provides a streamlined, understandable set of tabbed browsing options that does as the user expects.