Bookmarks Design Discussion
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. (XXX This needs more work and description, not sure how this can work out.)
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 (as opposed to the entire bookmarks list, which will be accessible from a sidebar). 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 also 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 tags. In most other cases, you'll probably have queries that are ANDs of multiple queries. In both of these cases, we should be able to properly label things that the user drags to the bookmarks menu. Some queries like OR queries we won't be able to do this for. Users advanced enough to do this will probably understand the error.
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.
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, .....