User:Auk/Bookmarks: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (→‎Searching: rename to Search)
(→‎Search: interface)
Line 13: Line 13:
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.
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.
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 [[User:Dria/On Tagging#Searching|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 <span lang="fr" style="font-style: italic">aussi</span>. 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 ==
== Menu ==
Inevitably, ...
Inevitably, ...

Revision as of 20:21, 6 August 2006

Here are my thoughts on the future of bookmarking in Firefox. This draft is a KISS outlook, and ultimately personally preferred in favor of my Tagging Model. While the tag model come 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.

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