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.
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, .....