User:David Regev/Ubiquitous Firefox: Difference between revisions

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

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

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

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

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

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

</div>

== Step 1: Integrate Ubiquity ==

All commands that Firefox includes 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.

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

The Ubiquity hotkey is currently <code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Ctrl</code>+<code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">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 we’ve replaced the menu bar with Ubiquity commands, the <code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Alt</code> key is free for invoking 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="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Alt</code> is held, thus solving the modality problem. A modal version of the dialogue can be kept and assigned <code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Alt</code>, <code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">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.

All these issues point back to one point: the dual-mode paradigm of the location bar is a barrier to 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 editing 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/in/set-72157625790500322/ annotated version])]]

The next step is to move the status mode of the location bar into the content area, attached to the page. 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 metadata 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/in/set-72157625790500322/ annotated version])]]

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

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

[[Image:Ubiquitous Firefox – Figure 5.png|thumb|center|640px|Figure 5: Inline Tab History ([http://www.flickr.com/photos/davidregev/5342557548/in/set-72157625790500322/ annotated version])]]

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/in/set-72157625790500322/ annotated version])]]

Much of this interaction model was inspired by Bret Victor’s [http://worrydream.com/Scrolltabs/ Scrolltabs] demo, which was proposed as a different 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.

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

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/20081225095154/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="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Ctrl</code> key is now free for another function: quasimodal Find (similar to [http://web.archive.org/20080224100153/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="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">Alt</code> and <code style="display: inline-block; padding: .2em .3em; font-size: .85em; line-height: 1; font-family: sans-serif; border-radius: .3em; background: -moz-linear-gradient(top, #D2D2D2, white); color:  #323232; text-shadow: 0 0 2px white; box-shadow: inset 0 0 1px white, inset 0 0 .4em #C8C8C8, 0 .1em 0 #828282, 0 .11em 0 rgba(0,0,0,.4), 0 .1em .11em rgba(0,0,0,.9);">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.

How would ''you'' redesign the browser?