Confirmed users
187
edits
User:David Regev/Ubiquitous Firefox: Difference between revisions
User:David Regev/Ubiquitous Firefox (view source)
Revision as of 03:37, 23 January 2011
, 23 January 2011More copyediting
David Regev (talk | contribs) m (Archive.org links) |
David Regev (talk | contribs) (More copyediting) |
||
| Line 28: | Line 28: | ||
What would browsers look like if they were first designed today? Like Descartes, I’d like to purge our assumptions and start from scratch, basing ourselves not on browser design from the ’90s but on how people actually use the Web today and will in the foreseeable future. | What would browsers look like if they were first designed today? Like Descartes, I’d like to purge our assumptions and start from scratch, basing ourselves not on browser design from the ’90s but on how people actually use the Web today and will in the foreseeable future. | ||
The 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. | # '''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 [http://?? 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. | # '''Ubiquity.''' Mozilla Labs’ [[Labs/Ubiquity/Ubiquity_0.5_User_Tutorial|Ubiquity]] (see this [http://?? introductory video]) should be the primary mechanism by which the system is controlled. The arguments for this are many, but needn’t be repeated here. | ||
# '''Tabs.''' The tab bar is one of the most popular features of modern browsers. Although tabs are arguably administrative debris, I believe that keeping them for now will allow us to create a browser that is not too foreign for people (unlike my [[User:David Regev/Firefox ZUI|<abbr title="Zooming User Interface">ZUI</abbr> mockup]]). At the very end, I will revisit this issue briefly. | # '''Tabs.''' The tab bar is one of the most popular features of modern browsers. Although tabs are arguably administrative debris, I believe that keeping them for now will allow us to create a browser that is not too foreign for people (unlike my [[User:David Regev/Firefox ZUI|<abbr title="Zooming User Interface">ZUI</abbr> mockup]]). At the very end, I will revisit this issue briefly. | ||
| Line 39: | Line 39: | ||
[[Image:Ubiquitous Firefox – Figure 0.png|thumb|center|640px|Figure 0: The Browser Template ([http://www.flickr.com/photos/davidregev/5342557416/ annotated version])]] | [[Image:Ubiquitous Firefox – Figure 0.png|thumb|center|640px|Figure 0: The Browser Template ([http://www.flickr.com/photos/davidregev/5342557416/ annotated version])]] | ||
Stripping | Stripping all <abbr title="User Interface">UI</abbr> from the browser, 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 1: Integrate Ubiquity == | ||
| Line 45: | Line 45: | ||
=== Step 1a: Ubiquitize all commands === | === Step 1a: Ubiquitize all commands === | ||
All commands that Firefox | 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 | ''If and when this task will be needed, I am available to assist with this undertaking.'' | ||
=== 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 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 === | ||
The | The Ubiquity hotkey is currently <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 we’ve replaced the menu bar with Ubiquity commands, 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 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="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 === | === Step 1c: The Firefox Button === | ||
| Line 62: | Line 62: | ||
* This is the ''only'' real button in the entire interface. Thus, if a new user is trying to figure out what to do, it will be relatively difficult to miss the one and only button displayed—the unusually large one with the Firefox icon in the corner. Eliminating the choice between this button and any other is a big win due to [http://en.wikipedia.org/wiki/Hick's_Law Hick’s Law], reducing the time required to acquire the button and improving its discoverability. | * This is the ''only'' real button in the entire interface. Thus, if a new user is trying to figure out what to do, it will be relatively difficult to miss the one and only button displayed—the unusually large one with the Firefox icon in the corner. Eliminating the choice between this button and any other is a big win due to [http://en.wikipedia.org/wiki/Hick's_Law Hick’s Law], reducing the time required to acquire the button and improving its discoverability. | ||
* In order to make it more obvious that the logo is clickable, the button will light up and pulse whenever the mouse cursor is moving in its direction. Users will, thus, quickly discover that the button wants them to come closer. | * In order to make it more obvious that the logo is clickable, the button will light up and pulse whenever the mouse cursor is moving in its direction. Users will, thus, quickly discover that the button wants them to come closer. | ||
* '''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. | * '''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. Generally, 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 a Ubiquity hint into a standard Ubiquity dialogue. | ||
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. | 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. | ||
| Line 71: | Line 71: | ||
What are the problems with the traditional location bar? | What are the problems with the traditional 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 | # ''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 status mode, the current page’s location is displayed; in editing mode, whatever the user has recenly typed is displayed. Thus, when the location text has been edited, it ceases to display the current location, and does not upate 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 | # ''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 them 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’s 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 its purpose to average users. 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. | ||
# ''It’s always visible.'' In Desktop browsers, the location bar is always visible—but it is not always useful. It is needed when the user wants to know the current location or to change it manually. Most of the time, however, it is a waste of valuable screen real estate—space that could have been devoted to content. In other words, the location bar is clutter and administrative debris. | # ''It’s always visible.'' In Desktop browsers, the location bar is always visible—but it is not always useful. It is needed when the user wants to know the current location or to change it manually. Most of the time, however, it is a waste of valuable screen real estate—space that could have been devoted to content. In other words, the location bar is clutter and administrative debris. | ||
# ''It’s optimized for one command.'' Just as the location bar was designed to display only one type of status, the <abbr title="Uniform Resource Locator">URL</abbr>, it was designed to process only one type of command, ‘take me to this <abbr title="Uniform Resource Locator">URL</abbr>’. Over time, the editing mode has been expanded to allow entering page titles and web searches and to display various widgets. Due to clashes with the location bar’s traditional design, progress in adding more and more command-like functionality has been slow. For example: Should the location bar display the current location or the command used to get there? When calling a command on a selection, does it make sense to display it all in the location bar, which conceptually relates more to the page as a whole (and its location)? When the user has built a complex command but has not yet run it, what should be displayed if the focus changes or if the user navigates elsewhere? These are some of the questions raised. Finally, due to its shape, the location bar has gotten more cluttered as more informative widgets have been added to it (Identity button, feed icon, bookmark star, and items added by extensions). Due to space constraints, it is difficult to transform this clutter into clear information design, especially when this design has to accommodate two modes. | # ''It’s optimized for one command.'' Just as the location bar was designed to display only one type of status, the <abbr title="Uniform Resource Locator">URL</abbr>, it was designed to process only one type of command, ‘take me to this <abbr title="Uniform Resource Locator">URL</abbr>’. Over time, the editing mode has been expanded to allow entering page titles and web searches and to display various widgets. Due to clashes with the location bar’s traditional design, progress in adding more and more command-like functionality has been slow. For example: Should the location bar display the current location or the command used to get there? When calling a command on a selection, does it make sense to display it all in the location bar, which conceptually relates more to the page as a whole (and its location)? When the user has built a complex command but has not yet run it, what should be displayed if the focus changes or if the user navigates elsewhere? These are some of the questions raised. Finally, due to its shape, the location bar has gotten more cluttered as more informative widgets have been added to it (Identity button, feed icon, bookmark star, and items added by extensions). Due to space constraints, it is difficult to transform this clutter into clear information design, especially when this design has to accommodate two modes. | ||
All these issues point back to one point: the dual-mode paradigm of the location bar is a barrier | 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). | ||
=== Step 2a: The ''browse'' Command === | === Step 2a: The ''browse'' Command === | ||