User:Auk/Bookmarks
Here are my thoughts on the future of bookmarking in Firefox. This draft is a KISS outlook, and personally preferred in favor of my Tagging Model. While the tag model comes from the point of view that the current bookmarks model must not be broken, and so adds next-gen technology onto that, this model throws out what has been before (for the most part) and builds a system that is simple but effective and — hopefully — in the long run easier to use.
Add
A given url can be bookmarked or not bookmarked. There is not so much 'adding' a bookmark as 'bookmarking a page'. If a page is in the bookmark index, Bookmarks -> Bookmark This Page appears checked, and the Bookmark toolbar toggle button appears toggled on.
When a page is bookmarked, it's text should be scanned, common words and characters (the, a, comma, period) removed, and the text saved (space delimiters for words?) in the SQLite .db file.
This should be carried on in the background, or perhaps simply a progress bar in the statusbar, and not stop the UI usage flow — no Add dialog, no nothing, but a toggled button.
In accordance with manual tagging, the toolbar button could feature a drop-down with a 'Tag option'...or something.
Remove
Ever accidentally hit delete on a bookmark? Might it have changed your life if you still had it? It would be a little wasteful to keep all data for bookmarks that are supposed to be deleted, so I have decided on a compromise.
When a bookmark is deleted, the description, index, and all data except the title and URI are deleted from the DB. In addition, the 'deleted' flag is set to True.
In the UI, you can resurrect bookmarks (by navigating to a special Trash...directory) and their other data is then repopulated and the deleted flag set False.
Search
I feel the primary mechanism of finding a bookmark should be searching. Some may argue this is a technical user's way of operating — text en lieu of point-and-click. However, I've watched many (my parents, generic other non-techies and techies alike) pull up Google in favor of thier bookmarks time and time again.
Why? This had been said before by more knowledgeable people, so I'll keep it brief. A search can be succint and generic at the same time. Documents have many aspects, few of which a user will remember at any given time. Search allows taking just one of these and jumping straight to it. I often find myself checking multiple folders in my bookmarks because the first folder I checked, which applied to one aspect of the page, is not where I put it.
The search mechanism scans the text index of a page mentioned in the Add section and finds matches and close matches to the search query. Results are ordered bby how close they match the query, or by how recently they were bookmarked. A lot like Google.
A problem with removing words from the text index is that it makes it nearly illegible to humans. E.g., we can rule out showing excerpts in search results (again like Google). Perhaps it would be better to index the joining words as well, and skip over them in the search algorithm with a blacklist.
Interface
The searching interface should be integrated and easily available. The quite popular article by Dria fits very closely to what I have in mind. However, I have a few ideas I feel should differ. Call it a superset.
- Autocomplete in the URL bar
- Entry in the search bar
The first has numerous advantages, one of which is that a user does not have to explicitly search thier bookmarks; they can merely start typing for a page they remember. (A URI is not required, any term will work.)
However, there are disadvantages aussi. The main one is speed. Waiting for the autocomplete suggestions to pop up or watching results appear at noticeably different times can be confusing and irritating.
Putting an entry in the search bar is the most obvious option. Basically, this has the (dis)advantages that are the opposite of autocomplete in the url bar.
Menu
Inevitably, people are going to want a menu. It's hard to be thrown straight into a new paradigm, ever if you're already using it without realizing (most people use Google on a regular basis). Sometimes a menu just works better.
It would look something like:
- [x] Bookmark This Page
- Bookmark All Tabs
- --------
- Search Bookmarks
- Manage Bookmarks
- --------
- {Tag}
- {Tag}
- {Tag}
- {Tag}
- {You get the idea}
However, a menu brings up some issues with our (this article's) minimal-interaction policy. We could auto-generate tags from the indexed text of a bookmarked page, but this would require complicated matching-and-rescanning to generate hierarchies and prevent the list of items from running hundreds long. Then, after implementation it would probably not work very well.
We could show the most recently used/added bookmarks, or the ones flagged important (also show up on bookmarks toolbar).
We could make the user manually manage his tags. I don't like it, but it really seems the only available option.
Dria mentions a tag suggest feature that somewhat resembles my auto-generation idea. However, his idea is a suggestion, that can be pruned by the user. I think that makes a big difference.
However, there are also things that can in no way be auto-generated from the text. For example, I often bookmark pages for their design alone. The content of the page isn't really good enough to merit coming back to. Currently, I put these in Web -> Ideaboosters. But, it would be incredibly useful to tag these with, say, Web Design or Web -> Cool Design etc. Manual tagging needs to be let in.
Syncing
Also see: User:Dria/On_Tagging#Syncing
I don't like the idea of a centralized service, even though we all know Mozilla can never do evil :). It just seems too...yeah.
However, we can't expect users to set up their own servers etc. A centralized service does seem the way to go. If this is the case, however, there should be a option (Bookmarks -> Manage Bookmarks -> Syncing...) to edit the servers used.
Mozilla should also:
- Notify the user that their bookmarks will be stored online, on Mozilla's servers.
- Notify that it is possible to store them elsewhere
- Keep a strict no-peek policy where they don't look inside users bookmark files, even for legitimate purposes such as bigfixing or other software improvement.
- NOT create a bookmark account with an install of Firefox. Online bookmark account must be created EXPLICITLY, and the password and username chosen then. When a user installs Firefox, their bookmarks and other user data are completely isolated on their local drive.
- Legal agreement as such.
Yes, I'm a crazy liberal :)
Remote access
It would be nice to have a web interface (login required!) from which a user on-the-go (relative's house, hotel...) can get their bookmarks (bookmarks.mozilla.org?).
Manual tagging
Yes, we have to let manual tagging and a bookmarks manager in the door. We can still keep it as simple as possible.
Check out a pic of the F-Spot photo manager and the current Firefox bookmarks manager.
Now check out my mish-mashed idea of a new bookmarks manager.
There are a few incorrect things in the mockup:
- New Folder button should be New Tag, and needs a new icon.
- Each tag in the sidebar should have it's own text box, aligned to the right.
- Properties panel should take up bottom half of the bookmarks listing panel.