From MozillaWiki
Jump to: navigation, search

Please comment in the discussion section rather than changing this page.

Rethinking Firefox Bookmarking

Places brings many new capabilities to the bookmarks and history system. However, the UI for accessing and managing bookmarks has not really changed that much. In this document, we describe some potential future directions.


Bookmarks work very well for pages that are revisited often. For these pages, the small mental overhead of filing in the proper place for easy retrieval is offset by the benefit that the user recieves. Firefox currently handles this case very well.

However, other important use-cases are not handled well. Some of the use-cases we would like to handle (see also Bookmarks Use Cases for lots of ideas) are:

  • Research: The user is researching a topic such as airline flights. They want to collect certain pages together and possibly remember key information from them such as time and cost. The user may, but does not necessarily, care about convenient future access.
  • To-do list: The user wants to remember a page to come back to. For example, directions to a party on the weekend, or an article to finish reading. They want to come back to it no more than a few times, and is not interested in permanent storage.
  • Long-term recall: The user wants to remember a page, but is not interested in accessing it frequently. For example, a HOWTO on configuring a piece of hardware that would not be needed until the OS is re-installed, or an obscure but potentially useful page on the company intranet.

There are other goals:

  • It should be as easy as possible to get a basic amount of bookmarking and recall, even for new users. The current system doesn't do this. Most users use autocomplete + Google.
  • If the previous goal is successful, we will need to be able to handle large numbers of bookmarks smoothly. The current system does not handle more than about 20 bookmarks in the menu.
  • Don't significantly change the UI for people that have learned to use the current system. Most people will not want to learn something new, and will be upset if their bookmarks have moved. It should be possible to slowly transition to the new features.

Autolinks in the toolbar

Many seasoned Firefox users can probably recall seeing a novice user's browser and noticed that the bookmarks toolbar has only the default bookmarks on it. Many inexperienced users don't even realize that the toolbar can be customized or removed. Even when they have commonly visited sites, they probably rely on other, less efficient methods of navigating to the page.

The autolink proposal would populate the unused right portion of the toolbar with the user's favorite non-bookmarked pages. If the user has populated their entire toolbar to the width of the window, no autolinks would be displayed.

The problem with many "automatic" proposals is that the spacial memory of the bookmark is lost when the links move around. Making the user comfortable with always knowing where to expect their bookmarks to be is an important requirement.

We should therefore seldom change the links around. Populating on startup is probably sufficient; the user should never see the links being moved around, even if they visit a site many times (making it their "favorite" site).

We should also try to keep bookmarks in the same location. When the toolbar is initially populated, we can use their N favorite non-bookmarked pages. We can then track clicks to these toolbar buttons. Some will probably be clicked on, while others will not. For those that are clicked on, we should "lock" those buttons and always use that index. For those buttons that are not clicked on, we will replace them with the user's new favorite unbookmarked pages.

It would also be possible to force eviction of a given item or to lock the item in place:


Open question: Should we also populate the autolinks with bookmarks that are not in the toolbar? Some sites may be frequently visited through buried bookmarks. We might be helping some users if we also include these.

Enhancing the "Places" window

This mock-up of the places window has several change over the current view.


On the left, the hierarchy has been removed. The hierarchy here causes visual clutter, but more importatly, it is confusing. The view of one's bookmarks hierearchy without the actual bookmarks can be surprising and cause one to wonder where the bookmarks went.

Removing the hierarchy also gives us more flexibility. In this view, the main "fixed" items at the top have been given very large icons. The user-specified items and folders are shown in small icons below. This also reinforces the currently mysterious separation between the items the user can edit and those that they cannot.

The history view in this mockup uses the view of history you can see by reading this newsgroup post.

The view shows a list of days in the middle column. A visual representation of the browsing per time is shown in green (this example only has a small bump). This allows the user to easily select different days to view history, without having a calendar which confused people before.

The bookmark "inbox"

The old bookmarks system has mental overhead associated with creating each bookmark. The user has to go to a sub-item on a menu, and has to decide where to file the bookmark before it can be added. If they don't want to file it, it gets added to the end of their bookmarks menu, which is probably not visible if they use the feature much.

We would like to support one-click bookmarking with a system that better manages a large list of bookmarks. In this mock-up, a "star" button is added to the bookmarks toolbar. Clicking on the star adds the current page to your "Bookmarks Inbox" A.K.A. "New Bookmarks".


Clicking on the down-arrow next to the star brings up the most recent items in the bookmarks inbox. When a bookmark is added, it is marked as "unread" (even though the user is currently on the page) and appears bold. When they visit the page again, it becomes "read" and is no longer bold. This is to support the "to-do list" metaphor: bookmarked pages that have not been visited are more prominent to allow easier finding. We should also support "Mark as unread" in the context menu for the menu.

As more items are added, older items fall off the bottom of the menu. They would still be accessable though the Places UI by clicking "View all bookmarks and tags" at the bottom. The full UI would also allow tagging and filing into bookmarks folders:


As shown, this capability would be alongside the current bookmarks menu and toolbar. Bookmark|Add Bookmark would still work, and would still default to the menu for those used to it.

However, it would be nice to unify the bookmarks menu and bookmarks inbox so there isn't yet another place where you have to go hunting for bookmarks. Perhaps we can just import the bookmarks menu as-is, add new bookmarks at the top, and add the read/unread capability. The "star" button would just be the quick way of adding something to the bookmarks menu. The danger is that this would surprise people who actually use the bookmarks menu and are used to new things going at the bottom. In this scheme, the small drop-down arrow next to the star button would only be used for tagging options.

Open question #1: Is this the best way to expose the items in the inbox? First, the target of the small down arrow may not be big enough, and is not obvious for many new users. Perhaps we want to add a separate button like IE? Perhaps unifying with the bookmarks menu is the right way.

Open question #2: How can we better present this list? The mock-up menu is only an improvement over the bookmarks menu because new ones appear at the top. Perhaps we should have "last week's bookmarks", etc. sub-menu at the bottom. It would be really great if we could get a scrolling view of all of them in that popup.

Archiving bookmarks

One common problem with bookmarks is that it is cluttered with many old items. the bookmarks view above has a "Clean up bookmarks..." button on the toolbar. This button would "somehow" move all bookmarks not visited in "a while" to the "Archived Bookmarks" folder as seen on the left (the hierarchy would probably be preserved).

This allows the user to clean up their bookmarks without having to worry that someday they'll need the bookmark; all bookmarks are always preserved in the archive.

Open question: How does the user choose what to archive? Perhaps we show a list of all bookmarks to archive when this button is pressed, and have a big button "Don't archive this". The user could then review the list and remove any items they don't want removed.


In the image above describing the star button, there are some tagging-related items in the drop-down menu. The first, "Tag page..." would bring up a tag-entry dialog box.

The second item sets the "default tag" which is applied to all pages when the star button is clicked. This allows the user to go into "research mode" where all bookmarked pages should be filed as a certain category. They would set the default tag to "wine" and then research wine tasting, clicking the star button for each interesting page.

We might want to have a "tags" toolbar control. Obsessive-compulsive taggers could add it to their toolbar and just type in tags for any web pages without having a dialog box appear.

Open question: how does this get cleared? It also needs to be made a little easier; as-described it's a little obscure. Perhaps a checkbox in the add tag window that says "use as default." It seems likely that this entire concept is too obscure, and the second item should be "Tag as XXX" where XXX is the list of the last tags used.

Viewing tags

Here is a potential tag viewing mode:



It is common that a small part of a page contains most of the value of the page. For example, the time and price of an airline ticket, or the address of a winery that you want to visit. For this task, we introduce "notes," which are enhanced bookmark descriptions, a little-known feature of the old bookmarks system.

To add a note, the user can select text and right-click.


The selected text would get appended to the current note for the page, and the note pane would appear (this is using the same content as the tagging view in the previous section):


This pane would appear whenever the user visits a page where they have added a note. It would also be toggle-able from the View menu.

Viewing notes

One of the most important reasons for notetaking is the ability to have all the information in one place. To view notes added to pages, the user can click on "View notes" in any bookmark or tag view:


We should also put any notes in tooltips where it makes sense, such as in the bookmarks menu and in the places view.

This provides all the information that they have noted for all pages in one convenient view. For example, the use would tag their airline pages with the same tag, and would be able to call all of them up at once to compare.

Open question: What happens if a note is added to a page that is not bookmarked? Perhaps we want to add it to the bookmark inbox.