6 January 2008 - 7:42Not Just Awesome
It’s been over two months since I first posted about the AwesomeBar [ed.agadak.net], and some of you have been able experience the power of the learning behavior. Frequently visited sites are easily accessed with just a single letter. These “automatic bookmarks” bubble up to the top of the location bar autocomplete list just after selecting a result once.
However, I noticed that the list contained many “random” results below the adaptive learning results for these single-letter-bookmarks. Looking at the highlighted portions, they would be in the middle of words and all over the url. Or in the case of ‘p’, the list would contain pages that matched http which isn’t too useful when searching.
The adaptive learning won’t be useful if the user can’t find anything of interest to select out of the list. Sure, one could keep typing and typing to filter out more pages and find something specific, but that requires typing more.. (and people are lazy! 😛 )
So I decided to improve the quality of the pre-adaptive results [bugzilla.mozilla.org]. Now matches near the beginning of the title or on word boundaries (and ends of words) are given preference. The same applies to the url, so matches near the front (like the domain) are preferred as well. Matching more helps as well, so top level pages are preferred over sub-pages with long, mysterious ?queries. 🙂
However, even with smarter matching of the title or url, the ordering might not be the one you want. Perhaps you have a page with the same title on the internet and locally for development, and you want one over the other. Only so much can be done without making things overly complex and slow, so that’s where the adaptive learning can fill in the gap.
There are builds available for people to try: Win32 zip (installer exe), OS X dmg, Linux tbz2 [build.mozilla.org]. These contain the changes for smarter matching results as well as the adaptive learning.
(The highlighted portion doesn’t necessarily correspond to the smart-matched portion.)
So hopefully with these combined, people will need only to type a fewer letters to find a page they want initially and then type a single letter to find it again. (Are people lazy or am I making them lazy? .. I mean efficient! 😀 )
9 Comments | Tags: AwesomeBar, Mozilla
What can I say other than “awesome”? Hopefully this makes it into final without too much Tp regression 🙂
I filed a bug on this:
https://bugzilla.mozilla.org/show_bug.cgi?id=404261
Checkin plz. 🙂
Will the awesome bar highlight necessarily the smart-matched portion?
Will it work cleanly with non-english and non-ascii characters?
Will it be easy to make some extension to ignore the prefixes or to increase the rating of the affix part? – esp, making inconsistent almost the same rate for ‘c’ that consistent, unload/load, etc.
That’s because I think that would be wise in some languages and that would be a great extension
This rocks. However, there’s a stage before even this where the user will have no results in the awesomebar – when they first start using it. And it happens again if you clear your history.
In both cases the problem goes away if Awesomebar also searched bookmarks, since in the new-profile usecase, a ‘firefox picks’ bookmarks folder would be enough to get the bar up and running. I guess this must have been considered and rejected for some reason?
If bookmarks do get folded into this – keyword searches really need more love. They’re a great feature, but you’ll never see them in autocomplete, so they’re not really discoverable.
Oh one more thing. I know theres concert over perf WRT the autocomplete stuff, which might be a reason for rejecting bookmark searches.
An ugly hack: mark all bookmarks as visited /now/ when history is cleared. Advantages = no impact on autocomplete perf, disadvantages = will surprise the user.
If FF3 ships without bookmark searching in the awesomebar, I’ll have a go at an addon to ‘Mark all bookmarks as visited’ to get this effect, that’ll do me.
Is there a significant difference between the 4:29 and 4:39 versions, just out of curiosity? I went with the more recent, sorta on principle….
[…] the work on the AwesomeBar [ed.agadak.net], I’ve noted before that getting relevant results [ed.agadak.net] in the location bar to select is important before the adaptive behavior is […]
[…] Way to Awesome For the work on the AwesomeBar [ed.agadak.net], I’ve noted before that getting relevant results [ed.agadak.net] in the location bar to select is important before the adaptive behavior is […]
This is the worst shit i have seen …..
Will go back to EI now hate stupid engineers that think they know what users want.
The bar can only hold a hand full of links and is useless now