User:Auk/Bookmarks

Here are my thoughts on the future of bookmarking in Firefox. This draft is a KISS outlook based upon and inspired by several other articles. This model throws much of what has been before 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'. Think a tool bar toggle-button Bookmark This Page, or a check-menu-item Bookmarks -> Bookmark This Page.

When a page is bookmarked, it's text should be scanned and saved for later searching ease (technical details of this to be argued) in the SQLite .db file.

This should be carried on in the background, or perhaps simply a progress bar in the status bar, and not stop the UI usage flow — no add dialog, no nothing, but a toggled button.

In accordance with manual tagging, the tool bar 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 wasteful to keep all data for bookmarks that are supposed to be deleted; so, keep just enough to resurrect it later.

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 filter) 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 grand-parents, generic other non-techies and techies alike) pull up Google in favor of their 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 succinct 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 common mistake in search interfaces/algorithms is that they only match exact character matches. This is bad. Things can often be spelled many ways, or say the page author made a typo. Matching multiple words only when they're lined up is also bad — a search for 'lichtenstein pudding' should find both 'Lichtenstein pudding is delicious.' and 'In Lichtenstein they make delicious pudding.' Searching for 'lichtenstein puding' [sic] should bring up those same results.

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.

• Auto-complete 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 their bookmarks; they can merely start typing for a page they remember. (A URI is not required, any term will work.)

However, there are disadvantages as well. The main one is speed. Waiting for the auto-complete 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 auto-complete in the url bar.

So, implement both. The url bar would work much like it does now, only it's results would be pulled in a more sophisticated way. The search box entry would give full-blown searching interface and results goodness.

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 tool bar).

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 user name chosen then. When a user first 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.