User:David Regev/Ubiquitous Firefox: Difference between revisions

<div style="border: 1px solid #AAAAAA; background-color: #F9F9F9; font-size: 95%; display: table; padding-right: 10px;">

* [[#Step_0:_The_Browser_Template|Step 0: The Browser Template]]

* [[#Step 1: Integrate Ubiquity|Step 1: Integrate Ubiquity]]

** [[#Step 1a: Ubiquitize all commands|Step 1a: Ubiquitize all commands]]

** [[#Step 1b: Reuse the Alt key|Step 1b: Reuse the <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code> key]]

** [[#Step 1c: The Firefox Button|Step 1c: The Firefox Button]]

* [[#Step 2: Replace the Location Bar|Step 2: Replace the Location Bar]]

** [[#Step 2a: The browse Command|Step 2a: The ''browse'' Command]]

** [[#Step 2b: Display Page Info Inline|Step 2b: Display Page Info Inline]]

** [[#Step 2c: Edit URLs Easily with Ubiquity Hints|Step 2c: Edit <abbr title="Uniform Resource Locator">URL</abbr>s Easily with Ubiquity Hints]]

* [[#Step 3: Rethink Back/Forward|Step 3: Rethink Back/Forward]]

** [[#Step 3a: Inline Tab History|Step 3a: Inline Tab History]]

** [[#Step 3b: The History Scroller|Step 3b: The History Scroller]]

** [[#Step 3c: Solving the ‘Too Many Tabs’ Problem|Step 3c: Solving the ‘Too Many Tabs’ Problem]]

* [[#Step 4: App Tabs, Find, and Downloads|Step 4: App Tabs, Find, and Downloads]]

** [[#Step 4a: App Tabs|Step 4a: App Tabs]]

** [[#Step 4b: Revamp Find|Step 4b: Revamp Find]]

** [[#Step 4c: Inline Downloads|Step 4c: Inline Downloads]]

* [[#Step 5: The Future|Step 5: The Future]]

This design will start with a few First Principles:

# '''Administrative debris bad, content good.''' This is the guiding principle behind this entire endeavour. It will allow us to design a browser where valuable space is not wasted on chrome and administrative debris but, instead, is devoted to content. Content will now have a chance to be its own interface.

# '''Ubiquity.''' Mozilla Labs’ [[Labs/Ubiquity/Ubiquity_0.5_User_Tutorial|Ubiquity]] should be the primary mechanism by which the system is controlled. The arguments for this are many, but needn’t be repeated here.

=== Step 0: The Browser Template ===

[[Image:Ubiquitous Firefox – Figure 0.png|640px|center|Figure 0: The Browser Template ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

Stripping the browser from all <abbr title="User Interface">UI</abbr>, other than tabs, we are left with this debris-less window. This shall serve as the template on top of which features will be re-added in the following steps.

=== Step 1: Integrate Ubiquity ===

==== Step 1a: Ubiquitize all commands ====

All commands that Firefox has should be available through Ubiquity. The interface for each of those commands will have to be redesigned to be more Ubiquity-like (or “Ubiquitous”). This will require someone to take on the arduous task of designing each of these new commands until all previous commands have been replaced.

: ''Note:'' If and when this task will be needed, I am available to help with this undertaking.

The current Ubiquity hotkey is <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Ctrl</code>+<code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Space</code>. This has two problems: it’s a bit complex, and the dialogue it invokes is [http://en.wikipedia.org/wiki/Mode_(computer_interface) modal]. Now that the menu bar has been replaced by Ubiquity, the <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code> key is free to invoke Ubiquity instead. Not only is this a simpler hotkey, thus solving the complexity problem, but it is also easy to hold while typing (or mousing). It can be used [http://en.wikipedia.org/wiki/Mode_(computer_interface)#Quasimodes quasimodally], where the Ubiquity dialogue appears only as long as <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code> is held, thus solving the modality problem. A modal version of the dialogue can be kept and assigned <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code>, <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code> as a hotkey.

==== Step 1c: The Firefox Button ====

[[Image:Ubiquitous Firefox – Figure 1.png|640px|center|Figure 1: The Firefox Button ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

* '''Ubiquity hints.''' Whenever the cursor is hovering over ''anything'' that will invoke some sort of command, a transient transparent Ubiquity dialogue (indicated by the dotted outline in the above mockup) will appear. It will show the command that would be run upon clicking the object. In the above example, the cursor is hovering over the Firefox button itself, so no command hint is given. Instead, crucial information is given in order to teach the user about invoking Ubiquity in the future. Clicking on the Firefox button (or holding <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code>) will transform the Ubiquity hint into a standard Ubiquity dialogue.

=== Step 2: Replace the Location Bar ===

# ''It’s modal.'' First introduced in [http://en.wikipedia.org/wiki/Mosaic_(web_browser) <abbr title="National Center for Supercomputing Applications">NCSA Mosaic</abbr>] (as far as I can tell), the location bar was a clever innovation. It combined two separate functions into one: displaying the location of the current page, and accepting commands to change the current location. This reduced the number of similar-looking widgets into one unified concept. Unfortunately, this introduced two modes: a status mode, and an editing mode. In editing mode, the location text ceases to update as the page location changes. The user must keep the current mode in mind in order to avoid misinterpreting the location bar text. Otherwise, mode errors may occur. Moreover, when in editing mode, there is no way to recall the current location definitively without resetting the location bar, thus losing whatever the user had edited up to the point.

# ''It’s unreadable.'' <abbr title="Uniform Resource Locator">URL</abbr>s were not designed to be readable by normal humans. In fact, the first web browser, [http://en.wikipedia.org/wiki/WorldWideWeb WorldWideWeb], did not expose them to the user. Even today, [http://jonoscript.wordpress.com/2010/02/18/some-people-cant-read-urls/ people don’t read <abbr title="Uniform Resource Locator">URL</abbr>s]. Unfortunately, we are stuck with this aspect of the Web for now. we must, therefore, make <abbr title="Uniform Resource Locator">URL</abbr>s more human-readable in some other way: present the <abbr title="Uniform Resource Locator">URL</abbr> in a modified form that people are more likely to read and comprehend. There have been attempts in the past to display a breadcrumb trail in Firefox’ location bar. These efforts have not yet been fruitful, partly due to the location bar’s modality: as soon as the mode changes from status mode to editing mode, text jumps around and the location bar’s contents change dramatically. This breaks the conceptual unity that the location bar was supposed to allow in the first place. Finally, even with a breadcrumb trail, the location bar does a poor job of indicating to average users its purpose. It is unlabelled, it is disconnected from the page it is describing, and it looks more like a place for code than a status display, due to being an editable text field rather than something like the status bar. In short, its usage is not discoverable enough and can actually scare users away from discovery.

All these issues point back to one point: the dual-mode paradigm of the location bar is a barrier for progress. The solution is to separate the two modes and evolve the interface from there. This means that the interface for displaying page status should be separate from the one for running commands (including the command for navigating to a page.

==== Step 2a: The ''browse'' Command ====

The Ubiquity replacement for the command mode of the location bar is the '''‘browse’''' command. Calling this command yields the same suggestions as for Firefox’s “awesomebar”, integrated into Ubiquity’s suggestions. In order for this command (and Ubiquity in general) to be as discoverable as the location bar, new tabs will bring up Ubiquity automatically (modally), with ''browse'' pre-filled. Switching tabs will dismiss it, while switching back to the new tab will bring it back. Essentially, the dialogue “lives” in new tabs.

[[Image:Ubiquitous Firefox – Figure 2.png|640px|center|Figure 2: The ''browse'' Command ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

==== Step 2b: Display Page Info Inline ====

The next step is to move the status-display functionality of the location bar into the content area. Like with mobile browsers, the page info moves with its page, thus disappearing off the top as the user scrolls down. This will allow one to focus on content, without distraction. Since the page info can be scrolled away, its new design can take up more space than the location bar, allowing better information design. The page info area is also a prime target for enhancement by extensions. In the following mockup, for example, Adblock Plus and Greasemonkey are both running on the page. Moreover, since Ubiquity is now integrated and commands are now a common means of navigation (hopefully), it makes sense to display the method used to get to a specific page. This will reinforce the learnability of the commands. Finally, all the information and statistics that were previously available in the Page Info dialogue can now be called here and displayed inline—all without getting in the way of content.

[[Image:Ubiquitous Firefox – Figure 3.png|640px|center|Figure 3: Display Page Info Inline ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

==== Step 2c: Edit <abbr title="Uniform Resource Locator">URL</abbr>s Easily with Ubiquity Hints ====

[[Image:Ubiquitous Firefox – Figure 4.png|640px|center|Figure 4: Edit <abbr title="Uniform Resource Locator">URL</abbr>s Easily with Ubiquity Hints ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

Once this system of Ubiquity hints is in place, the way in which users are taught functionality is greatly improved. It is now possible to add commands and to expand the capabilities of existing commands without significantly contributing to bloat. Commands can now be more discoverable: point to one and you’ve practically learned it. Once this is exposed to individual sites, the rest of the Web may take advantage of Ubiquity, leading to more debris-less design. For example, say I’m using Gmail. I point to a button on Gmail’s text-editing toolbar, and a transparent hint pops up, telling me that that button will run the ‘''bold'' this’ command. From now on, I know exactly how to make text bold without needing to switch to my mouse or to memorize a keyboard shortcut. If I install that command from Gmail, I now have access to this feature anywhere.

The Back and Forward functions have been standard for web browsers since the beginning. These functions are a necessary aspect of the standard browsing model: follow a link and it is loaded in-place, replacing the previous page wholly. If we are to rethink the Back and Forward buttons, we must also consider the standard browsing model. It is not difficult to see a number of problems with this model. Listing these problems will help us come up with a better, more modern, model.

# ''It hides your trail.'' Whenever you follow a link, the page you’re on simply disappears. Poof! And a new one magically takes its place. There is no visual indication of what is happening, no attempt at information design at all. The best you have is a bare-bones list of page titles completely hidden behind the Back/Forward drop-down.

# ''The Forward “history” is mutable.'' Whereas the Back button’s history is reliable and doesn’t change, the Forward button’s history is not immutable. If you go back three pages and follow a link, the three pages that were previously part of the tab’s history are now gone, replaced by the new page. One might have expected that the new page would have been inserted into the history in that place, or at least appended to the list at the end, but it’s not. Your browsing history for that tab is now incomplete. The only way to revisit a lost page is to dig through your browsing history, using an interface that preserves context even less, and hope you find it.

# ''It is one-dimensional.'' Related to the previous issue, a browsing session can seldom be represented by a linear list. Modern tabbed browsing is more often a two-dimensional tree (as demonstrated [http://xkcd.com/214/ by xkcd], and explored in my [[User:David Regev/Firefox ZUI|Firefox <abbr title="Zooming User Interface">ZUI</abbr>]] mockup). The way browsing history is handled, thus, conforms more to browsing as it was when browsers were first introduced rather than to how it is today.

# ''Page transitions are awkward.'' Click on a link. What happens? In an ideal world, I suppose, the new page would simply appear immediately. In the real world, and for the foreseeable future, the new page takes time to load. What happens in between? The previous page remains displayed for a bit, but it is only partially active. Interacting with the page, such as by clicking on objects or by scrolling, is hit-or-miss and unpredictable. At some unpredictable point during the transition, the page completely disappears, and the new page starts loading. No matter how short or long this transition is, one thing is certain about it: it wastes time. During this wasted time, the browser is mostly useless and the user’s train of thought is put on hold, at risk for being lost altogether.

# ''Revisits are unpredictable.'' Go back a few pages. What happens? If you’re lucky, the intended page loads without delay and looks exactly as you remember it. If you’re unlucky, the page will reload, forcing you to wait. If you’re really unlucky, the page won’t load at all, but you will instead see a scary and unhelpful dialogue about POSTDATA.

#* Tabbed-browsing power users have a workaround here as well: if you think you might need to refer back to a page, leave it open in another tab. This eliminates the upredictability of going back to that page, as it’s simply a matter of switching tabs. This does, however, contribute to tab proliferation.

==== Step 3a: Inline Tab History ====

In step 2b, the tab was transformed from a proxy for its current page into a container for that page. The next logical step is to allow that container to contain more than one object; instead of just that page, it could contain all pages in its history.

[[Image:Ubiquitous Firefox – Figure 5.png|640px|center|Figure 5: Inline Tab history ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

In the mockup, the user has just clicked on ‘Google Search’. Instead of the page becoming unusable and morphing into a new page, the view scrolls as the new page slides into view while loading. In the mockup, the new page is in the process of scrolling into view. If the user wished, this automatic scroll can be interrupted by manually scrolling (either by mouse or by keyboard). Switching back and forth between pages in the tab’s history is now greatly simplified: just scroll up or down. In this more visual representation of history, what you see is what you get; going back to a page displays it exactly as it was, completely predictably. The darker 640px indicates the currently-focused page. Only that page is active. When the previous page lost focus, its state was frozen and saved. An unread page in the Forward history, however, gets loaded in the background fully and then frozen until the user chooses to view it. Scrolling up a little more or clicking on the previous page slides it back into focus. Its state is then restored and the later page is frozen and saved.

==== Step 3b: The History Scroller ====

[[Image:Ubiquitous Firefox – Figure 6.png|640px|center|Figure 6: The History Scroller ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

Much of this interaction model was inspired by Bret Victor’s [http://worrydream.com/Scrolltabs/ Scrolltabs] demo, which was proposed as a solution to the ‘too many tabs’ problem. The way tabs display three favicons instead of a page title will allow tabs to take up less space on the tab bar and will, therefore, free up space for more tabs. This extra space, however, will not be needed as much, as the next step will dramatically decrease the need for too many tabs in the first place. The final interaction aspect of the History Scroller will present its own solution to the ‘too many tabs’ problem.

==== Step 3c: Solving the ‘Too Many Tabs’ Problem ====

[[Image:Ubiquitous Firefox – Figure 7.png|256px|center|Figure 7: Solving the ‘Too Many Tabs’ Problem ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

When one traverses one of these tab trees, there is usually a predictable and liner order in which the page at each node is read. This is the depth-fist order (which is arguably more efficient than a breadth-first order). Such a flow was boosted by Firefox 3.6 when spawned tabs were made to appear adjacent to their parent and in order. What if we simply collapsed the tree into a single dimension, preserving its natural reading order? This is what the diagram shows.

* Middle-clicking on links no longer spawns new tabs. The same goes for new tabs spawned forcibly by web pages. Instead, the new page is inserted into the history without the content area scrolling to that page automatically. This is the functionl equivalent of clicking on a link and quickly scrolling up a little. This allows the user to continue reading the current page until the end, at which point the unread page will be immediately available.

* The current page and all pages opened from it in the background form the active page group. This is visually styled in the History Scroller. In the mockup, this is indicated by the darker border around the four items in the active tab group.

=== Step 4: App Tabs, Find, and Downloads ===

==== Step 4a: App Tabs ====

Consider the archetypal web application: Gmail. Gmail is designed such that following links in the interface modify the display in-place. Repeating the entire interface in a new page below the current one would not make sense. In fact, it would be detrimental to Gmail’s usability. Besides, Gmail’s links typically modify only the page’s anchor, not the rest of the <abbr title="Uniform Resource Locator">URL</abbr>. Normally, following a link to an anchor causes the content area to scroll to that point in that page. In Gmail, however, it modifies Gmail’s own content area. Gmail also has its own navigation system, such that the traditional Back and Forward buttons are not necessary. Finally, Gmail is designed such that it is generally left open for long periods of time. Following external links, therefore, should not deactivate Gmail’s interface.

* No History Scroller. Internal links always open in-place, like they already do in standard Firefox. Navigation is dealt with by the application, though the standard Back and Forward commands remain available through Ubiquity.

* External links (to outside the application) open in a new tab. This is a singular tab that collects all external links from that application. That tab is placed directly to the right of the app tab and is visually attached to it.

* The tab shows only one favicon on top, and appears narrower than other tabs.

==== Step 4b: Revamp Find ====

In order to keep Firefox’s interface [http://web.archive.org/web/20080221100719/http://rchi.raskincenter.org/index.php?title=Monotony_in_The_Humane_Interface monotonous], Ubiquity should be the sole way of executing commands via the keyboard. Keyboard shortcuts, therefore, should be eliminated. A well-tuned instance of Ubiquity can replace these shortcuts in an efficient—and more humane—manner. The <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Ctrl</code> key is now free for another function: quasimodal Find (similar to [http://web.archive.org/web/20080224100153/http://rchi.raskincenter.org/index.php?title=Text_Specification#LEAP_AND_CREEP LEAP]. (It may prove better, however, to switch the usage of the <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Alt</code> and <code style="padding: 0px 1px; background: #FAF6F6; border: 1px solid #EDD; border-right: 2px solid #BAA; border-bottom: 2px solid #BAA; border-radius: 3px; font: 90% sans;">Ctrl</code> keys.)

Showing a tab’s entire history inline provides a nice benefit to how Find works: once Find has finished searching the current page, it can move down to the next one. Thus, it will be easy to find anything within the tab’s entire history. Moreover, text should be indexed when a tab is closed (in addition to thumbnails), allowing closed tabs to be searched and restored in the future.

==== Step 4c: Inline Downloads ====

=== Step 5: The Future ===

# Keep the History Scroller. Instead of a tab bar, show different tabs as windows arranged on a plane. Zooming out reveals these tabs. When zoomed out, a tab may be selected or moved around the plane. This approach (without the History Scroller) is basically that taken by <del>Tab Candy</del>[[Firefox/Projects/TabCandy|Firefox Panorama]] (though the tab bar was kept in the end).

[[Image:Ubiquitous Firefox – Figure 8.png|640px|center|Figure 8: The Future ([http://www.flickr.com/photos/davidregev/??????????/ annotated version])]]

My preferred direction is to integrate with Panorama. The History Scroller and Panorama compliment each other. The former deals with the ‘too many tabs’ problem by minimizing the number of tabs needed to be open at once, while the latter makes the interface for dealing with many tabs more efficient and useful. Similarly, the former is an attempt to present a better interface for a tab’s history, while the latter presents a better interface for tabs. ''Ideas welcome on how to integrate the two ideas.''