Confirmed users
187
edits
User:David Regev/Ubiquitous Firefox: Difference between revisions
m
→Step 2: Replace the Location Bar: Narrowed abbreviation
David Regev (talk | contribs) m (Revert keyboard styling) |
David Regev (talk | contribs) m (→Step 2: Replace the Location Bar: Narrowed abbreviation) |
||
| 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 | # ''It’s modal.'' First introduced in [http://en.wikipedia.org/wiki/Mosaic_(web_browser) <abbr title="National Center for Supercomputing Applications">NCSA</abbr> Mosaic] (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 recently typed is displayed. Thus, when the location text has been edited, it ceases to display the current location, and does not 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 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 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. | ||