409023 - Autocomplete should prefer prefix to substring

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect)

Description

[Jeffrey Baker]

Attachment: Screenshot

The location bar autocomplete appears to choose internal substring matches over prefix matches.  In the attached screenshot, you can see that http://foo.quux.com?blah=string is preferred over http://string.quux.com, which makes little sense to this user.

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I think this is a good idea. Not sure if it's covered by another bug.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Individually all of these comments (like don't show 404 pages) seem logical, but I'm tending to think that we should land edward's adaptive learning code (bug 395739), and let it organically pick up the user's preferences.  This should effectively allow you to prefer prefix over substrings, unless there are some results where you always search for a substring, or the end of the string, etc.

Something that weights what you entered with what you selected is by definition optimized, as opposed to a series of guesses of what we think the most logical way is to rank results.

Comment 3

[Jeffrey Baker]

I think your statement of "by definition" may be overstating the quality of the new autocomplete from the user's perspective.  Although your argument is logically appealing, and despite the fact that the system sometimes produces a surprising and useful result, I think it's a step backwards from the usability of the  old autocomplete.

In the old system, the results were stable.  I knew, after some time, that I could type "ars" and "arstechnica.com" would be the first result.  I knew I could use "bug" for "bugzilla.mozilla.org", and so on.  This allowed me to build up a huge library of shortcuts for my favorite web sites.  I never looked at the results, because I knew that a single stroke of the tab key would get a known result.  It was just like tab completion in the unix shell.

With the new system, I am force to look at the results, because they are not stable.  If I have two sites that I visit with approximately equal frequency, and they share some string in the URL or title, the top position will change between the two.  Since the results keep changing, I find that I have to actually read the list, and pick the one I want with the mouse.  This is much slower.

Maybe I simply haven't given the new system enough time to train, but after a month I find it increasingly frustrating.

Comment 4

[Benjamin Smedberg]

Alex, I think that adaptive learning might be a decent long-term solution, but I think it's important to treat new upgraders to the best solution possible: I know that one of the most frustrating parts of learning to use the new URLbar was typing "wash" and washingtonpost.com wasn't the top choice... adaptive learning might fix that, after a few times, but it gives a really bad first impression... and I've seen users where if a feature doesn't do what they want the first time around, they declare that feature "too hard" and never use it again.

Comment 5

[Roman R.]

I agree with the last two commenters. I don't want to give the adaptive code time to learn. I want to get predictable results NOW and all the time (or as often as possible). If there's a burning desire to use the adaptive algorithm, make it an option to be chosen by advanced users.

Comment 6

[Ed Lee :Mardak]

Another way to look at this is the adaptive can only adapt to results selected by the user. If none of the results look good, nothing will be chosen. The adaptive learning can help address the issue by having the user type out something longer the first time and requiring only a single letter the next time.

I've been working on bug 410133 to better rank results for results like attachment 295214 [details] (vs typing p and getting back all httP results)

If you want, you can try these builds to see if they do more of what you want with this preference to prefix to substring.

https://build.mozilla.org/tryserver-builds/2008-01-02_23:[e-mail]-prefer_front.count_visits/

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

>Maybe I simply haven't given the new system enough time to train, but after a
>month I find it increasingly frustrating.

It hasn't landed yet, but it should make the types of interactions you described really solid and predictable, except for any part of the tile or URL:

>I knew, after some time, that I
>could type "ars" and "arstechnica.com" would be the first result.  I knew I
>could use "bug" for "bugzilla.mozilla.org", and so on.

If you've tried using Quicksilver on OS X, the adaptive learning feels really logical.  This is because it is based on a direct action (typing the text and selecting the result), as opposed to a very indirect action (frecency).

I'm not against us trying optimizations like favoring prefixes when we lack any data on the user's behavior, but when we land the adaptive learning I really think it should override any hard coded assumptions.

Comment 9

[Michael]

Similar approaches have been tried before, and didn't sit well with users.  For example. Microsoft used adaptive menus in Office and Windows, where results you selected frequently would be moved to the top of a menu, and results you rarely or never chose would be hidden.  This made it really hard to find menu options.

Apple just changed its Spotlight results algorithm in Leopard to show matching applications at the top, before file matches.  The reason is that the user was most likely looking for an application, and having the application hidden among a long list of files made it harder to find.

The older version of autocomplete virtually always gave me what I wanted, often with 1 keystroke.  This version often requires typing most of the name of the site.  For example, weather.com is particularly hard to get through autocomplete.  I have to type "weather." before ANY url with weather.com actually appears at the top of the list, because I've also visited CNN, which has the word weather in its title - 7 words into the title!  Essentially, autocomplete is useless in this case, as I now have to look through the list and navigate with my keyboard or mouse to choose the right option.  Ignoring autocomplete altogether would actually be faster for weather.com.

If you wanted to display substring matches *beneath* the first 10 autocomplete matches, separated by a divider to make it clear that the results are being chosen differently, that might make sense, because then the user can see strings that are conceptually similar rather than similar by prefix.  But the current algorithm is definitely counterintuitive, and rarely produces the correct result, even after multiple trials.

Comment 10

[Jeffrey Baker]

Attachment: Screenshot

The awesomeness of the bar is even further reduced in Firefox 3 Beta 3.  See the attached screenshot.  The autocomplete is returning results where the search string is a kilobyte deep in the query string rather than exact prefix matches on hostnames.  Whatever algorithm is in use here is deeply silly.

Now, I realize that the full awesomeness maybe hasn't landed, but adaptive learning is also blocking-firefox3:- which means that there's some danger that Firefox3 will ship with the current fully-broken autocomplete system.  I think that would be a shame.

Comment 11

[Roman R.]

The OS field should probably be changed to all.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

>where the search string is a kilobyte deep in the query string rather than exact >prefix matches on hostnames.

Mardak: can we rank significantly reduce the relevance of matches that are very far into the string?

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

comment #6 is on the money - adaptive learning will help, but on first presentation, we should be doing what's most sensible so that users can pick the right things for the algorithm to eventually adapt to. Put another way: adaptive learning helps a system learn about exceptions to rules, but that relies on the system having sensible rules in the first place.

Anyway, not willing to block on this, but it would be seriously nice to have.

Comment 14

[Ed Lee :Mardak]

With the fix for bug 393678, it's more difficult to match against a substring because searching will try to filter out non-prefix/wordboundary matches.

Comment 15

[Nickolay_Ponomarev]

This is not fixed - I have getsatisfaction.com/twitter/... above twitter.com for "t" or "twitter". You may argue it's a wontfix, given that bug 393678 is fixed, though...

I guess the main issue here is that people upgrading from fx2 will be disappointed the shortcuts they are used to don't work anymore. I'm not sure how this can be fixed without collecting some data in fx2 to use for adaptive results in fx3.

Comment 16

[AndrewM]

(In reply to comment #15)
> This is not fixed - I have getsatisfaction.com/twitter/... above twitter.com
> for "t" or "twitter". You may argue it's a wontfix, given that bug 393678 is
> fixed, though...
> 
> I guess the main issue here is that people upgrading from fx2 will be
> disappointed the shortcuts they are used to don't work anymore. I'm not sure
> how this can be fixed without collecting some data in fx2 to use for adaptive
> results in fx3.

But if you type in 't' or 'twitter' once and then select the result from autocomplete, adaptive learning makes that the top result for the next time you type in 't' or 'twitter', right? So I don't really see it as shortcuts being "broken", you just need to use them once to in effect create the shortcut in the first place and then after that they'll work fine :)

Comment 17

[Ed Lee :Mardak]

(In reply to comment #15)
> This is not fixed - I have getsatisfaction.com/twitter/... above twitter.com
> for "t" or "twitter"
Both the urls are matching "t" for twitter because twitter starts after "...com/twitter" or ".://twitter". Both are preferring prefix matches to substrings. So WFM.

Bug 424454 got fixed, so typed pages are more likely to go up top, so twitter.com will be more likely to be the first result even before adaptive learning.

If that doesn't do it for you, perhaps you're looking for bug 409895.