make the url bar drop down show typed sites ordered by frecency, not visit date currently, when you click on the url bar drop down, you will get a list of typed sites, ordered by visit date (most recent first). for bug #394038, I've made a change to order these by frecency instead. this is a change in behaviour since firefox 2, so I'm seeking ux- approval from beltzner/mconnor/faaborg. note to dietrich, this change is already part of bug #394038 see also: bug #407429 – Two line autocomplete is slow when clicking on the "show typed urls" drop down bug #386168 – Simplify nsNavHistoryAutoComplete::AutoCompleteTypedSearch

some ideas, questions and comments? 1) should we expose frecency as a sort order for place queries? nsINavHistoryQueryOptions.SORT_BY_FRECENCY_DESCENDING / ASCENDING. this could be useful for extension authors or for people wanting to do interesting things with place: queries. I think we should do this, and I'll log a spin off bug and seek dietrich / mano's opinion. 2) if we don't think the drop down should be frecency descending, would that be an interesting default query in the smart bookmarks folder?

as far as comment #0, beltzner agrees: I believe that the invocation method of that drop-down should not significantly alter the way in which we determine the results of that field, which would support Seth's proposal of "typed entries, ordered by frecency". beltzner brings up a good point that I had not considers. What the patch in the bug #394038 will do is unify the relationship between when you search in the url bar and when you click on the drop down: 1) search = any kind of results that match, ordered by frecency descending (note: with tags currently first) 2) click on drop down = "typed only" results, ordered by frececncy. based on beltzner's comments, I'm considering this part of bug #394038 to have ui-r-+

> 1) should we expose frecency as a sort order for place queries? spun off to bug #411591

this is going to be fixed along with bug #394038

I'm not sure about using the frecency score for this drop down. Traditionally this is meant to be a list of sites that you very commonly go to, and the drop down allows you to revisit common sites using just the mouse. However, with the current implementation my drop down contains a site that I have only been to once, for the first time today. It has high recency, but very poor frequency, resulting in a moderate frecency. What do people think of using this drop down for pure frequency, since we have the history menu and sidebar for pure recency? Pure frequency will map better the previous behavior of this field, right? (I should note that I've never really used the drop down in my daily browsing).

please see https://bugzilla.mozilla.org/show_bug.cgi?id=412730#c13 to summarize, if we go back to date (And not frecency) we will have to do chunking (I think) to fix the perf problem reported in bug #407429. ...or maybe not. perhaps a sub query over moz_historyvisits to find place ids from the typed visits, ordered by date, grouped by place id (with max(visit_date)) would work. using that sub query, we get the place and bookmark info. (question: which title do we use, bookmark or place? if multiple bookmarks, which one?) sorry for the drive by, dietrich!

>if we go back to date (And not frecency) To clarify I think we should use frequency, not date or frecency. For instance, if the top 3 sites I visit are nytimes, google docs, and planet mozilla, these would be the first three listed, regardless of which one I visited last. >question: which title do we use, bookmark or place? We should always use bookmark name over page title since the user specified it

(In reply to comment #5) > However, with > the current implementation my drop down contains a site that I have only been > to once, for the first time today. Seth: Alex wasn't using a frecency build. The "current" implementation that Alex most likely used on the 24th is the old code that sorts things by *date*. (bug 406358) Alex: If you try now with a build from after the 25th, what pages show up when you click the drop down? Additionally, should we do adaptive learning on items that you've selected from the drop down menu? And should things that show up in the menu only be pages that the user has typed in? Meaning the user typed out that url. If a user searches for a website using google on the default home page and always visits the same site, that item wouldn't show up in the drop down because s/he didn't actually type in the url.

>Alex: If you try now with a build from after the 25th, what pages show up when >you click the drop down? The list is nearly the same as my history sorted by visit count, however there are some anomalies, like a page with a visit count of 11 being above a page with a visit count of 47. >Additionally, should we do adaptive learning on items that you've selected from >the drop down menu? I don't think so, because I think keeping this list reasonably stable will give us the biggest usability win. For instance, microsoft office tried using adaptive learning on all of their menus and it really didn't work well. >And should things that show up in the menu only be pages that the user has >typed in? No, I don't think the user will understand that we are using that metric, and also the pupose of the drop down menu is to provide a mouse only interaction for accessing frequently visited sites, so tying it to a keyboard interaction is a little counter intuitive. I think we should think about this menu as the bookmarks toolbar for users who never bookmark a page. Here is a breakdown of the various ways we help people revist pages: -History menu: pure recency -Location bar drop down menu: pure frequency -Most Visited smart bookmark: pure frequency -Results in the awesome bar: frecency with adaptive learning

Why are we looking to reinvent how this is used? Its a shortcut to display previous things you've typed, that's what the widget almost always means where I've seen it (i.e Win95-XP run dialog, Fx2, IE7). Its also not a mouse-only action, hitting down with a blank field (i.e. new tab) yields the same list. Based on how this has always worked, the best answer IMO is ordered by a recency-heavy frecency, only counting typed interactions in the calculation. Basically, the idea is an intelligent list of stuff you've typed recently and want to skip typing again. We'd probably want to cache this as a separate table (25 rows, just need the IDs). Since its a fixed-length list, we could do that after a URL has been typed into the location bar, and only then. Building the UI is just a join against that table at that point, so it'd be pretty fast. Does that all make sense? Seems like its a pretty straightforward special frecency...

(In reply to comment #10) > Basically, the idea is an intelligent list of stuff you've typed recently and > want to skip typing again. We'd probably want to cache this as a separate > table (25 rows, just need the IDs). That's essentially what you get with the adaptive behavior. It logs the selected pages that you've typed in a separate table and puts those first for next time. The adaptive selection works on a prefix match, so an empty search will match all adapted results, so whichever one is used most often will get picked out first. Additionally, we can specially do adaptive learning on drop down selections in addition to the typed prefix matching. This is all already implemented for bug 395739 combined with bug 406359.

(In reply to comment #11) > Additionally, we can specially do adaptive learning on drop > down selections in addition to the typed prefix matching. When I say specially.. I actually mean we get it for free with bug 406359.

This bug can be marked fixed providing the behavior of comment #10 once this list of patches get reviewed and land: Bug 414285 – Refactor AutoCompleteTagsSearch token splitting code and persist tokens (already reviewed) Bug 406359 – Unify the logic for url bar searches and drop down items (refactoring) Bug 414287 – Share search result processing logic as AutoCompleteProcessSearch (refactoring) Bug 395735 – Instrument the location bar auto-complete to report accuracy (new interface) then making use of the refactored code and new interface: Bug 395739 – adaptive learning (match entered text to selected item) in url bar autocomplete But it wouldn't hurt to first get multi-word in ;) Bug 401869 – Allow multiple words search in Auto-complete/Location Bar

>Why are we looking to reinvent how this is used? Its a shortcut to display >previous things you've typed Two things to consider: -if adaptive learning works really well, the user may not type full domains anymore, instead of entering bugzilla.mozilla.org, they might just type "bu" making the list of things the user typed less useful in 3 than it was in 2. -Because the user is likely to type just domains, I think that may lead to an expectation that this list will continue to show top level domains. I think users will expect to get to home pages instead of deep linking into sites with this list, just because it was unlikely for them in the past to type very long URLs.

This will be fixed with bug 395739 to strongly prefer previously typed and selected results.

Taking bug assuming we're fixing this with bug 395739.

Testcase split off from bug 395739.

Checking in toolkit/components/places/tests/unit/test_adaptive.js; /cvsroot/mozilla/toolkit/components/places/tests/unit/test_adaptive.js,v <-- test_adaptive.js new revision: 1.2; previous revision: 1.1 done

VERIFIED Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0