User:David Regev/Ubiquitous Firefox: Difference between revisions

__NOTOC__

{| class="wikitable collapsible" style="float: right; margin: 0px 0px 0px 10px;"

|-

| <div style="margin-left: -10px; margin-right: 10px; font-size: 95%;">

With our First Principles at hand, we can now design a truly modern browser, starting with a clean slate and restoring browsing functionality step-by-step.

[[Image:Ubiquitous Firefox – Figure 0.png|thumb|center|640px|Figure 0: The Browser Template ([http://www.flickr.com/photos/davidregev/5342557416/ 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.

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.

Since Ubiquity will be the principle mechanism of accessing Firefox’s commands, it must be more discoverable. There are several ways of accomplishing this task, each one necessary. The first enhancement is to provide a dedicated button in the interface for invoking Ubiquity.

Note how Ubiquity hints build upon earlier steps: these hints can be shown for every command because all commands have been Ubiquitized. This work will allow us to extend the Firefox interface later and add elements while retaining the Ubiquity interaction model and its richness.

The location bar is arguably the most important piece of administrative debris in every popular browser since the beginning of the Web. One could argue that Ubiquity should be integrated into the location bar (such as with [[Taskfox]]), instead of using the Firefox button. However, the traditional location bar has numerous problems that make its interaction paradigm not ideal. Due to these issues, I believe that we must find an alternative to the location bar.

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.

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|thumb|center|640px|Figure 2: The ''browse'' Command ([http://www.flickr.com/photos/davidregev/5342557480/ annotated version])]]

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|thumb|center|640px|Figure 3: Display Page Info Inline ([http://www.flickr.com/photos/davidregev/5342557490/ annotated version])]]

One of the benefits of the location bar’s modality is that the current <abbr title="Uniform Resource Locator">URL</abbr> is very easy to modify. How to do so easily within the proposed interaction paradigm is not immediately obvious. With our previous introduction of Ubiquity hints (step 1c), however, this problem is solved. Pointing at anything that will run a command when clicked on will bring up a hint—a transparent preview of the command that will be run. Thus, such hints will appear when pointing at links, whether in content or in the page info area. Editing that command (and the <abbr title="Uniform Resource Locator">URL</abbr>) is as easy as hitting the hotkey. Therefore, it is now simple to edit not just the current page’s location but that of any link, in addition to any other command that is exposed in the interface.

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.

Can we solve all of these problems with one redesign? Yes!

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.

This is still not a complete solution. Not all of the problems are satisfactorily solved. Moreover, we’ve created a new one: how do you quickly navigate back to a specific page from a while ago? Finally, there is another form of administrative debris that I’ve been neglecting: the scrollbar. Shouldn’t it be there, or at least be replaced by something better? The next step will answer these questions with one solution.

[[Image:Ubiquitous Firefox – Figure 6.png|thumb|center|640px|Figure 6: The History Scroller ([http://www.flickr.com/photos/davidregev/5342557596/ 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.

Where do tabs come from? They are either created from scratch manually (via the New Tab command or button), or spawned from another tab. Which way causes the most tabs? By far, it is the latter. All those tabs together can always be traced back to one Ur-tab—the root node in a branching tree of pages. If each of these trees could be contained within one tab, the number of tabs would fall drastically. The ‘too many tabs’ problem would disappear.

* The History Scroller automatically hides when maximized/full-screen on small screens, so as not to take away room from content. It may be brought into view by moving the pointer to the right edge of the screen (in mousing environments) or by swiping the page to the left (in touch environments).

App Tabs can be viewed as a partial replacement for the Bookmarks Toolbar. Since this feature is already being integrated into Firefox proper, there is no need to extol its virtues here. I do, however, need to explain how app tabs relate to our reimagined tabs.

Sites that do not require such an interaction model need not be pinned as app tabs.

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

There are many other improvements that Find requires. They are, however, mostly orthogonal to the current discussion. To see more ideas on how I think Find could be improved, see my ‘[[User:David Regev/Firefox Search, Revamped|Firefox Search, Revamped]]’ (which is written for Firefox’s current interface, but can easily be modified for this proposal).

Downloads always open in the background in-place, in the content area—like any other page. They may be moved via drag-and-drop, just as other pages may be saved. They may also be renamed, even when downloading.

Both the tab bar and History Scroller are, technically, administrative debris. Nonetheless, they are both intimately tied to the content and are more information-rich than all the debris that we have managed to eliminate. The tab bar, in particular, has proven itself as the killer feature of modern browsers. This is why it made sense to take tabs as a given at the beginning of this exercise.

----