Bookmarks Design Discussion
Contents
Bookmarks Design Discussion
Rationale
People interact with the web very differently today than they did when the concept of web bookmarks was first created. With search engines and directories such as google, yahoo, opendirectory, etc. returning fast and mostly accurate results, it's often easier to search for a page based on keywords you remember from it, than it is to hunt through your static bookmarks.
Many people still use bookmarks in the traditional way -- bookmarking pages, manually placing them into a folder hierarchy, and then visually scanning (or searching by title) to locate a particular bookmark. The favicon in particular helps the visual scanning.
I would guess that most people don't use any hierarchy; they bookmark pages as they come to them, and they end up going to an overpopulated Bookmarks list that's all but unusable from the Bookmarks menu.
Bookmarks will be closely tied to the Annotations Service, providing ways to add additional information about the bookmarked pages.
Bookmark Labels
Instead of asking users to create a hierarchy of bookmarks, we would instead have users apply one or more labels to each bookmark. Making a bookmark will involve tagging the current page with one or more labels, instead of "Bookmark this page". The latter operation can still exist, and can apply a default "Favorites" or similar label.
Since a bookmark can have multiple labels associated with it, the interaction with the set of bookmarks will be through keyword and label searches, and not directly by hierarchy. Hierarchy can be displayed in the bookmarks menu and toolbar (see next section).
Bookmark labels can be hierarchical; for example, using : to denote a hierarchy level, a bookmark with a label of Work:Reference would have that as one of its explicit labels, but also have an implicit label Work. It does not have an implicit label Reference, however. Querying for all bookmarks with a label of Work would include all bookmarks labelled Work, Work:Reference, Work:Blogs, etc.
Within each label, order will be preserved amongst bookmarks. If a query is done for Work:Reference, all bookmarks with an explicit Work:Reference label will always be displayed in the same order, and will be reorderable. If multiple labels are included in a query, however, no order will be enforced or remembered.
An alternative to the use of : for a short tag hierarchy could be the support for ordered tags such as work reference, work blog, etc. All tags are separate and searchable as single tags. For example, a search for social+bookmarks as a flat search would show bookmarks with any order of tags (e.g. bookmarks social software) while "social bookmarks" would only show bookmarks with this sub-string of ordered tags. This concept can represent well sorted directories such as “wiki Firefox bookmarks design�?. Any sub-order of tags could be searched: "bookmarks design", "firefox bookmarks", etc. The support of simple wildcards or special operators would allow to search for "wiki * bookmarks" where bookmarks can have any position right from wiki. A search for "^wiki" could be used to show all bookmarks where wiki is the first tag.
Interacting with complex queries
When users view a label, either from the bookmarks manager, menu, etc., presenting and interacting with the bookmarks inside it is straightforward: bookmarks can reordered, added, deleted, etc.
When a category is a more complex query such as "Work AND Important", or "Important OR Incomplete", presentation becomes more complex. In some cases, such as RSS, the user can't even change the title or delete it. Even for local bookmarks, what happens if the user tries to add or delete a bookmark to a complex query, or reorder them?
In some cases, we can magically assign the proper labels when a bookmark is added to a complex query. If it is just an AND clause, the bookmark gets all the necessary tags. In other cases, this won't be possible. How will these "special" categories be presented so that it is clear that you can't do some things?
Separating out Bookmarks, the Bookmarks Menu, and the Bookmarks Toolbar
The Bookmarks Menu and Toolbar are only able to display a hierarchy, whereas with labels, a single bookmark may have more than one label "parent". Unlike the current scheme, the Bookmarks Menu and Toolbar will be separate from the list of bookmarks; the user will have explicit control over each bookmark that appears in the menu or sidebar (as opposed to the entire bookmarks list, which will be accessible from a sidebar or "bookmarks manager" opened in a tab). In the default configuration, things will behave much as they do now -- bookmarking a page will tag it with a default bookmark tag, and will optionally add it to the menu. The Toolbar will behave the same way, except that users have always had control over what appears in the toolbar. The only change to the toolbar is that it will no longer be a "Folder" in the bookmarks menu, but will be its own separate container.
Hierarchy can be created in the bookmarks folder by creating special query folders that will display as its children the results of that query. A simple query can be just for an individual label; however, complex queries can be possible. Additional bookmark providers can create new bookmark types and containers that can be present in the menu or the toolbar.
We will have to take care to make this behavior intuitive to users who are used to the old bookmark system and just want to create folders inside their bookmark menu/toolbar and put links in them. The menu/toolbar hierarchy should be visible when categorizing bookmarks (perhaps at the bottom of any labels) with the folders visible. People, who may not realize the correspondence between a label and the separate bookmark menu entry, should even be able to put stuff in the sub-folders of the bookmarks menu.
In most cases, the entries in the bookmarks folder will be simple "soft links" to single tags. Adding a bookmark to one of these links should add the tag. In other cases, this won't be possible (see "Interacting with complex queries" above).
If linking tags gets too complicated, we could also create separate tags that live in the bookmarks menu. For example "$MENU:Programming" could be the name of the programming tag that appears inside the bookmarks menu. The difference is that this would not be linked to a separate "Programming" tag you have at the root tag level.
This case solves some of the edge cases of the previous approach where it might be confusing that the two separate things are linked. But now there is a new problem of not realizing that there could be two separate things labeled "Programming". If all interaction is done through selecting lists and autocompleted lists, this might not be confusing.
Separating the Interfaces of the Favorites and the Web Index
The graphical interfaces for bookmarks must address two different purposes. One is quick access to websites and the other one is managing a personal index. Both concepts have been kept in one interface so far but it would be better to have two tailored interfaces: one for fast access to frequently visited websites following the design principles of program menus or sidebars with a small number of items, and the other one for managing and searching the personal WEB INDEX ("permanent history") of marked and tagged websites. For more details please see: http://pubnotes.wordpress.com/2007/10/14/rethinking-bookmarks-ui/
Interaction With Other Bookmark Providers
Bookmark providers that provide items will be subject to the same labelling mechanism. However, bookmarks that provide containers will be a special case, since they will live a dual item/container life. RSS bookmarks in particular will, .....
