Closed Bug 393508 Opened 17 years ago Closed 16 years ago

Mockup: Location Bar Autocomplete for Firefox 3

Categories

(Firefox :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3

People

(Reporter: faaborg, Assigned: faaborg)

References

()

Details

(Whiteboard: [places-ui])

Attachments

(1 file, 1 obsolete file)

This is a tracking bug for mockups of the autocomplete interface in the location bar.  Due to to the attachment size limit images will be hosted on people.mozilla.com.  Check the most recent comment or URL for the latest iteration.
Status: NEW → ASSIGNED
Whiteboard: [places-ui]
Assignee: nobody → faaborg
Status: ASSIGNED → NEW
Text from iteration 1:

Type anything into the location bar, and Firefox will try to take you where you want to go
---
This shows all of the possible areas that can be displayed, however it is very unlikely that a search will trigger every area.

We may calculate each section in order, but the results themselves will never reorder (like with spotlight).
---
Locations:  the way the location bar behaves today
---
The results under "locations" are essentially the same as the location bar today: URLs are filtered based on starting with what the user entered, and then ranked by frecency.

Bookmarked pages are now denoted with a star on the far right.

In this example, the names of the user's bookmarks and history did not contain the word "moz"
---
Google:  for many users, navigational searches have replaced both bookmarking and remembering URLs
---
Because this search contains two words, no locations match. 

This feature allows the user to walk up to any installation of firefox, and directly navigate to pages based on remembered google queries.

The downside are obvious privacy implications: this feature would be turned off when in private browsing mode.
---
This functionality is based on the Safari extension Inquisitor by David Watanabe.
---
Bookmarks:  quick access based on name
---
Here the user finds a commonly accessed bookmark by entering it's name.
---
Tags:  view all pages that have a particular tag 
---
Tag results are only displayed if the text is a perfect match.

What happens when the user selects the tag will be covered in a separate set of mockups.
Attachment #278014 - Attachment is obsolete: true
Attachment #278014 - Attachment is patch: false
Attachment #278014 - Attachment mime type: text/plain → image/png
Blocks: 393529
Depends on: 387718
Here are some notes on why I think this UI is superior to a flat list of results:

1) The search algorithm becomes a little more transparent: in Firefox 3 we are going to start searching bookmarks and history, but how is the user supposed to know that is possible?  Do users know that you can type in the name of a bookmark into the location bar in Safari right now? (I didn't know this for quite awhile).  Once users see results appear, they will think "ah, I can search for that kind of stuff here, cool."

To give another example of the search algorithm being more transparent, if we match on title and the user is looking at the URL (because it is on the left) they are going to think wtf.  If we match on tag and we don't even show the tag, they are going to think WTF.  In this UI, it is clear whether the result matched on URL, Title or Tag.

2)  Backwards compatible: If we promote results above other results that start with what the user has entered, they may be annoyed because they are used to the current behavior of the location bar.

3)  Self describing features are easily to explain to others:  If the user wants to show this feature to someone else, it is very clear: "hey, Firefox 3 now searches both bookmarks and history in the location bar, look (pointing to "bookmarks" and "history" on the side)."

4)  Even the best search algorithm can't know everything:  Let's say that I visit site A and B about the same amount but A is bookmarked.  When I do a search and both A and B appear, but I know exactly where to look to select A (the bookmarks section) so I can locate it very quickly.  The algorithm won't be able to know that I was only looking for the bookmarked site A unless I provide some kind of clue (like the * that beltzner was talking about), but that is a lot of extra work.  This also would apply for tag C, assuming it contains the same text as sites A and B.  The user can quickly move their gaze to different sections instead of having to do a linear visual scan of the results.

5)  Human Readable: this UI allows us to swap the location of titles and URLs based on the section.   URLs aren't very human readable, but bookmark titles are (in fact the user may be written them).  We can't swap the location of the page/bookmark titles and URLs unless we break the sections up.

6)  Only good way to integrate google results:  We can't just throw the google results in, we need to break up the list and mark them separately.
Here is possible solution that I have proposed before:
http://features20.blogspot.com/2007/07/natural-languange-navigation-finally.html

The main difference is that this is three column view. The bad side of that is that it is not standard, the good side is that it takes much fewer keyboard clicks to do what you want.
(In reply to comment #3)
> Link to iteration 1:
> http://people.mozilla.com/~faaborg/files/granParadisoUI/places_UnifyingSearch_i1.png
> 
It looks awesome, but I think tagged results should appear before history.
(In reply to comment #3)
> Link to iteration 1:
> http://people.mozilla.com/~faaborg/files/granParadisoUI/places_UnifyingSearch_i1.png
> 
I think I don't understand what locations are since they must be in history or bookmarks for firefox to know they exist
Idea for the next iteration: what if when you started typing, the location bar grabbed the focus.  This would be somewhat similar to how Find as You Type used to grab the focus (accessibility.typeaheadfind was set to false in Firefox 2, or maybe for 1.5).

Navigating to a new URL is a really common interaction, certainly more common than FAYT, so it makes sense to streamline the process, even down to removing the mouse movement to give the location bar the focus.

While accel-l is a pretty clear shortcut (as long as you know that it is called the "location bar"), you have to both remember the keyboard shortcut, and then remember to use it.

If anything in the content area had the focus, we obviously wouldn't move the focus to the location bar, similar to how FAYT used to work.
>I think I don't understand what locations are since they must be in history
>or bookmarks for firefox to know they exist

In the next iteration I think I am going to call that section something like "URL starts with."  It's a clunky name, but that's what the first section literally is. The latter bookmarks and history sections include matches against the title, and other sections of the URL.  Results in the "URL starts with" section won't be duplicated below, and I would imagine that normally you won't see both sections when entering a query.  If you enter a space, you definitely wouldn't see the "url starts with" section.
What about calling it simply URLs or Adresses
This feature rocks.  I hope comments like these aren't premature, or, you know, stupid in this context:

* I'm not sure separate categories for "Locations", "Bookmarks", "History" are useful.  I'd rather see one category for my stuff, and a separate category for suggestions from Google or other search providers.

* Um, starred pages should always be on top, right?

* Likewise, a page should get points (appear higher in the results) if I've visited it many times.

* This really ought to do a full text search of my starred pages and history.  That sounds like a lot of work to implement, but the way I use history now I have a pretty poor hit rate, and this could be a big win for me as a user...

Here are most of the planned changes for iteration 2:

General:
-Typing grabs the focus, similar to FAYT
-First section is called locations, second second is called Title, results appear based on what you matched

Tags:
-display the actual results under the tag itself

Search:
-Google is the last section, however the search only proceeds if you select it, causing the list to grow
-Play around with integrating sponsored results, to make the interface more acceptable to google

Alex adds:  

for location results, precedence give to urls that start with the search term
(In reply to comment #12)
> Search:
> -Google is the last section, however the search only proceeds if you select it,
> causing the list to grow

Was this requested by Google? I'm only asking 'cause this would really seem to harm findability of this great feature. How about just one result and a "Scroll here for more results" line that expands as you get to Google's section?
(In reply to comment #1)
> Because this search contains two words, no locations match. 
Couldn't multiple words be used to match locations? Urls don't have spaces, but they generally contain words compressed into a single word /because/ it's a url. E.g., https://intranet/PhoneBook or http://news/Firefox3HasSuperCoolAutocomplete. 

Hopefully those pages' titles have the correct spaced out words, but if not, matching all typed keywords separated by spaces would match "phone book" or "firefox cool".

(In reply to comment #13)
> for location results, precedence give to urls that start with the search term
In addition to the multi-word functionality, this would give the old functionality more power. E.g., using the news url from above, typing "news cool".


(In reply to comment #12)
> -Typing grabs the focus, similar to FAYT
One potential problem that currently affects FAYT is that websites can grab keystrokes before they reach FAYT, or in this case -- the location bar. The website can do something with the key press and choose whether or not something else (FAYT) gets the key.

There's the privacy issue that I didn't think about when first mentioning this -- I was more concerned about the user experience for sites that /do/ choose not to pass the keys on to FAYT. That functionality is needed for sites like Gmail that give keyboard commands that trigger just by typing the letter.

In the case of Gmail, it only catches /certain/ letters, so even with FAYT, you might begin a search if you happen to start typing with the letter "w" but not "c" (compose). But I suppose this could be handled by the site itself -- "if you want to provide this functionality, you might confuse users that try typing to change locations"


On a site note of FAYT + Autocomplete.. "Results in page" section?
>Was this requested by Google? I'm only asking 'cause this would really seem to
>harm findability of this great feature. How about just one result and a "Scroll
>here for more results" line that expands as you get to Google's section?

Not at all, we haven't approached them yet with this potential feature.  I'm proposing this change due to the massive privacy concerns of passing everything the user types into the location bar to a third party search engine.
alex:  for tag matching, dietrich and I were thinking it would be a case insensitive exact match (and not contains).

so if I have a page tagged with "Calendar" and I type "cal" I would not see it, but if I typed "Calendar" or "calendar" I would.

what do you think?
>a case insensitive exact match (and not contains)

Yeah, I said "perfect match" in the mockup, but I really should have said case insensitive exact match.  Out of curiosity, are tags converted to lower case?
(In reply to comment #18)
> Out of curiosity, are tags converted to lower case?
> 

no
(In reply to comment #15)
> Couldn't multiple words be used to match locations? Urls don't have spaces, but
> they generally contain words compressed into a single word /because/ it's a
> url.

I'd go further and say we have a positive match if all entered terms are part of the address, the page title, the bookmark title, the tags (why would I look for an actual tag in the location bar rather than a tagged location?), etc.. Grouping doesn't allow that, as well as it forbids other things like a free ranking of the results.

Frankly, I think this goes into the wrong direction. Fine-grained searches belong to the sidebars or the Places organizer. The autocomplete popup is starting to look like a complex, multidimensional grid. It's already looking crowded in attachment 278014 [details], even though the scroll bar is missing and there's a lot of unobtrusive gray.
(In reply to comment #12)
> -Typing grabs the focus, similar to FAYT

As Edward Lee pointed out, I'm afraid this could have some pretty serious usability implications with shortcuts in web applications. (And I'm all for more keyboard shortcuts in web apps)

And like Dão, I actually prefer to see all the results together. The way it works right now is quite good to me, except for multiple-keyword match and that search keywords should only match the beginning of words, and maybe some tweaking to the order results are displayed, based on where the matches occurred.
>The autocomplete popup is starting to look like a complex, multidimensional grid.

It is rather unlikely that a search is going to match every category, so the odds of seeing the level of complexity shown in the first part of the mockup are (I think) low.  We should probably actually play around with this thing to get a sense of if we like the behavior or not.

>pretty serious usability implications with shortcuts in web applications.

Can we check the page to see if it is using keyboard shortcuts, and then disable location bar fayt?

(In reply to comment #22)
> >pretty serious usability implications with shortcuts in web applications.
> 
> Can we check the page to see if it is using keyboard shortcuts, and then
> disable location bar fayt?

My fear is that it could cause disastrous situations. What if you get so accustomed to typing the URL right away that for a moment you forget the page has keyboard shortcuts (maybe you didn't even know it did!), and then ends up firing one big combo of actions? You could end up losing important stuff this way. Or maybe the website automatically focused a textbox for you, and you end up submitting a form.

(Speaking about focus, the great thing about accel-L IMO is that it won't fail you like the find keys, the space bar and the backspace key unfortunately eventually do, when the keyboard focus is somewhere you didn't expect it to be.)
>My fear is that it could cause disastrous situations.

That's the web pages fault.  If we continue to design around hypothetical boundary cases, we are never going to improve our UI.  Isn't saving hundreds of millions of people 1 second per location bar interaction more than worth the extremely rare case of annoyance?

Anyway, if we capture the focus, then the web site can't do anything un-undoable.  The number of web sites without keyboard shortcuts vastly outnumbers the number of web sites with them, so I think it is overall worth streamlining the most common interactions.  Boundary users can turn it off entirely, or download some type of extension that white lists certain sites like gmail.
(In reply to comment #22)
> >The autocomplete popup is starting to look like a complex, multidimensional grid.
> 
> It is rather unlikely that a search is going to match every category, so the
> odds of seeing the level of complexity shown in the first part of the mockup
> are (I think) low.  We should probably actually play around with this thing to
> get a sense of if we like the behavior or not.

What I meant is that every single search term should have a match in _any_ of the categories. For example, you could tag this page with "fayt" and then type "bugz fayt".

> >pretty serious usability implications with shortcuts in web applications.
> 
> Can we check the page to see if it is using keyboard shortcuts, and then
> disable location bar fayt?

Isn't fayt off by default? There's probably a good reason for that. I think it's main problem is that you occasionally start typing if you /expect/ a text field within the page to have focus. In that case, kicking off the new big autocomplete UI (or even the old one) would be more annoying than the current fayt bar.

(In reply to comment #24)
> >My fear is that it could cause disastrous situations.
> 
> That's the web pages fault.  If we continue to design around hypothetical
> boundary cases, we are never going to improve our UI.  Isn't saving hundreds of
> millions of people 1 second per location bar interaction more than worth the
> extremely rare case of annoyance?

I'm not so sure. I think many casual users barely type into the Location Bar. So at least, this should eventually be off by default.
I fear that the focus grabbing will break the standardized convention of "space/shift+space" scrolling down and up. I'm heavily opposed against the idea, the browser should stay out of my way - the webpage is the target of my attention. If I'm ready to navigate to a new URL I signal that to Firefox: I click the favicon (which is broken in Minefield due to Larry's popup) or hit Ctrl-L. I'm doing an explicit context switch.
It's annoying enough if web pages grab focus when you don't expect it, like www.cyberport.de with its search box, Firefox should go down this path.
Depends on: 395735
Iteration 2: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_UnifyingSearch_i2.png

Text from the mockup:

==Problem 1: Discoverability== 

I didn't start using this feature until Seth literally walked in to my office and said "hey I implemented searching on title in the location bar."  With the current UI, there is no indication that this ability is now available, or that we changed anything.

==Proposed Solution: Self Describing Field==

The location bar is now self describing, similar to the search bar.  This text only appears in three situations:

-Replaces the URL of the user's home page (but reverts on hover)

-Replaces the URL about:blank (but reverts on hover)

-Appears after creating a new tab

==Problem 2: Unclear Relationship Between Search Text and Results==

What does "be" have to do with the first URL, is Firefox broken?  The second URL has "be" in "cube"...

This was too far away for the user to notice:

A related problem is the user enters the full text of a bookmark, but then can't easily spot the correct result because they only know the bookmark name, they can't remember the URL.

==Problem 3:  URLs are not Human Readable (and sometimes they are basically GUIDs)==

[mockup contains the hypothetical criticisms of an angry novice user meant purely for comedic value.]

==Proposed Solution:  Adapt the Display of Individual Results Based on Match==

Only the top 7 results are displayed.

Exact case insensitive tag matches are listed first, bookmark and history results are mixed.

The bookmark title or page title is favored over the URL for the top line of the result, but only if there is a match.  Otherwise, the URL gets the top line.

Bookmarks have a second column displaying the star and all tags for the page (not just matching tags).  History items extend all the way across horizontally.

The "see all X results" loads a dynamically generated page in the content area.

Selecting "Search Google for Scuba" displays direct links to the top three results.
Much better!

I have to ask again, why display the tag as the first result? In your mockup, the four tagged results are already there.

> Bookmarks have a second column displaying the star and all tags for the page
> (not just matching tags).

They'll have to be truncated then, if there are many tags / long tag names. But what is it good for anyway? In the spirit of being lightweight, I'd just leave that out.
(In reply to comment #27)
> ==Proposed Solution: Self Describing Field==
> 
> -Appears after creating a new tab

That's difficult ... If you open a new tab, the urlbar has focus.
(In reply to comment #27)
> 
> ==Problem 1: Discoverability== 
...
> ==Proposed Solution: Self Describing Field==
> 
> The location bar is now self describing, similar to the search bar.  This text
> only appears in three situations:
> 

The description seems mostly unnecessary with the suggested changes in presentation (especially given C#29). The change is now so obvious that people who use the location bar are bound to see the change. (and AFAIK research has shown that most people rely on the location bar for navigation.)

(In reply to comment #27)
>
> The bookmark title or page title is favored over the URL for the top line of
> the result, but only if there is a match.  Otherwise, the URL gets the top
> line.

This seems confusing. Mixing the lines in this way makes skimming the list harder as I can't know in advance which line should I check for particular info. If there's a need to emphasize the bit that resulted in a hit, couldn't this be done with a symbol? or underlining the part of the line that was found.

Echoing C#28 about tags. Aren't the tags at the ends of lines already clickable? A tag line could be argued for if it isn't visible elsewhere in the results.
small change to i2: removed the scheme from URLs in the results.
>I have to ask again, why display the tag as the first result? In your mockup,
>the four tagged results are already there.

Sorry, forgot to reply earlier.  We could put the individual tag result last, since it probably doesn't deserve such prominent placement, and it would fit in next to view all results.  Since the tag match isn't like any of the other results, I'm not sure I would want to mix it into the list, based on some ranking of how likely the user is to select it.

>They'll have to be truncated then, if there are many tags / long tag names. But
>what is it good for anyway? In the spirit of being lightweight, I'd just leave
>that out.

I included tags for a few reasons, which may or may not be accurate (but I think they are):

1) If the user tags a page they are also likely to rename it, and users don't usually create extremely long names for bookmarks, so this are would probably otherwise be white space.
2) The tags the user associated with a page should help them recognize the result, since they had to go to extra work to create those tags.  Even if we truncate somewhere around the third tag, the first two and a half will provide useful contextual information.
3) Noticing a tag that is unrelated to the current search will help to remind the user of their tag space, so they know what they can search for in the future.

Rational 3 is potentially a weak reason, since it doesn't relate to the search currently in progress.  Do you disagree with 1 and 2?
In comment #5 I gave one my old mockup made on this topic, but I wasn't quite sure how much space was left for changing proposed solution, and as it had significant differences from then actual proposal wasn't really ready to join the discussion.

But now as I see that lots of suggestions are accepted (and including some from my mockup), I would like to give some suggestions/ideas.

1) First of all, second iteration of mockups is definitely much better. I am all after putting bookmars and history in the same basket.

2) My initial expression is also that tags have nothing to do with location bar, as some people expressed. They should be taken under consideration when finding the match, but that's nearly it.

3) It would be very important if Firefox could search word by word when matching results, and not exact phrase - more or less like Google does

4) I think average users (e.g. my dad) would appreciate Google results directly available from location bar (without expanding). I don't think that I can easily explain to him when and how to use search and when and how to use bookmarks and history, but if everything comes to him in one drop down, I don't even have to explain that. Of course, this leads to controversy with possible need to include Sponsored results, and possible visual clutter. Thus initally I proposed 3 column layout, though good solution might be 2 column layout - one for Bookmarks and history and other for Google search and sponsored search.

5) I think that my idea with tooltip with previous searches and Google suggestions is good one - pressing cursor left would move pointer to that tooltip and one would have to type less when searching.
>2) My initial expression is also that tags have nothing to do with location
>bar, as some people expressed. They should be taken under consideration when
>finding the match, but that's nearly it.

I personally really like the idea of tags themselves being locations. When you navigate to one you get thumbnail images of all of the pages with that tag loaded in the content area.  It is certainly a departure from both traditional URIs, and content only coming down from other servers.

>4) I think average users (e.g. my dad) would appreciate Google results directly
>available from location bar (without expanding).

Yeah, I'm pretty sure average users don't care as much about privacy with distant third parties like Google, as much as they care about privacy from other people they may share their computer with.  However, I've found that in general people who test nightly builds and comment on bugzilla/dev.apps.firefox happen to be extremely privacy conscious.  Another issue (completely unrelated to privacy) is the massive amounts of traffic this feature would cause if it triggered the search by default.

I really like how the three column view reduces key-presses, but as you pointed out earlier, it is very non-standard.  I'll give it some thought, thanks for the feedback.
(In reply to comment #32)
> I included tags for a few reasons, which may or may not be accurate (but I
> think they are):
> 
> 1) If the user tags a page they are also likely to rename it, and users don't
> usually create extremely long names for bookmarks, so this are would probably
> otherwise be white space.
> 2) The tags the user associated with a page should help them recognize the
> result, since they had to go to extra work to create those tags.  Even if we
> truncate somewhere around the third tag, the first two and a half will provide
> useful contextual information.
> [...]  Do you disagree with 1 and 2?

I disagree with 1, because even if that's the case, I wouldn't add tags just to fill some whitespace ;)
2 might be true, although I'm not sure if you're really faster this way, compared to just reading the page title and the site name. So it's still worth thinking about if the potential usefulness of the tags outweighs the additional visual complexity, or put another way: if they help more than they distract.
Maybe it's better if you put the star to the outmost right and the tags right next to the title so that one can continuously read through it? Just an idea.
What about placing the star bottom of the favicon or left of the name and tags right aligned? this way there is no need to truncate the names if the page is bookmarked and there is no empty space to the right if tags don't fill it
Attached image Image for comment #36
An example
I like the idea of having tags in the urlbar, but I think it would be better to make them right aligned so that they are less likely to crop the title so severely. That provides the same benefit while mitigating the cost.

Also, putting the star below the site icon looks like a good way to go.

note about restricting the results, and including a "show all" option.  In bug #388090 mconnor writes:

>The "Show All" and/or "Search for foo" options are secondary interactions if
>the search doesn't return the match you're looking for.  Limiting the results
>forces users to use them more often, which feels like backward thinking.  Show
>All is an interesting concept, but shouldn't come at the expense of making many
>interactions heavier than they need to be.

removed the joke from i2 since another places mockup hit the digg home page today (trying to avoid pulling a Shaver).
notes for i3:

-the location bar itself needs to auto complete to the first result (with the auto completion selected, like safari), hitting enter should navigate to the first result.

-move tags result to the bottom since it is considerably more likely that the user wants to navigate to a specific page.
(In reply to comment #41)
> notes for i3:
> 
> -the location bar itself needs to auto complete to the first result (with the
> auto completion selected, like safari), hitting enter should navigate to the
> first result.

There's browser.urlbar.autoFill. It doesn't work if your match isn't at the beginning of the address, for obvious reasons.
(In reply to comment #41)
> -the location bar itself needs to auto complete to the first result (with the
> auto completion selected, like safari), hitting enter should navigate to the
> first result.

This behavior has serious problems. IE used to have that feature, but it was dropped. Raymond Chen explains here:
  http://blogs.msdn.com/oldnewthing/archive/2005/11/02/488163.aspx

The comments are also an interesting read, as they show the opinions of other people. But my IMHO it should still be turned off by default. Dão's point just makes me more convinced that it would do more bad than good.
(In reply to comment #41)
> -move tags result to the bottom since it is considerably more likely that the
> user wants to navigate to a specific page.

Is a Keyword field already planned for the tagging/bookmarking UI?

It'd be good if keyword results were shown, too.
(In reply to comment #44)
> Is a Keyword field already planned for the tagging/bookmarking UI?
> 
> It'd be good if keyword results were shown, too.

What's the difference between a tag and a keyword ? 

>What's the difference between a tag and a keyword ? 

Keywords have been in previous releases of Firefox, and they allow you to access particular bookmarks with short phrases.  For instance, typing "f" and navigating to facebook.

Tags are new to Firefox 3, and they are an organization scheme that competes with folders.  For instance, all of the web sites for your various utilities could be tagged "bills" and "apartment."

Since the distinction between keywords and tags can be somewhat confusing, we are de-emphasizing keywords (but still keeping them around for people who use them).  The keyword field only appears on the properties of a bookmark, and it is now hidden behind a progressive disclosure control.
Depends on: 396816
Pardon my ignorance, but what is a progressive disclosure control? Has this already been implemented in the latest nightly?
>what is a progressive disclosure control?

A button with a down arrow that when pressed expands the dialog to display more controls.  For instance, the button in the properties pane that says "more" next to it: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_OrganizerWindowLayout_i5.png
Here are all the currently planned changes for i3:

-If the first result's URL starts with the URL the user entered, the location bar needs to inline auto complete to the TLD+1 of the first result (with the auto completion selected, like safari).  Hitting enter navigates to the that URL, hitting down fills out.
     -only filling out to TLD+1 takes away the problem stated on the IE blog, because anything less than that isn't likely to be a URL (except for on intranets, but that is a boundary case of a boundary case).
     -Only inline auto-completing if the text matches the start of the first result takes away the obvious problem of situations where you match the middle of the URL, or the title, etc.

-Title is always on the top line, URL is always on the second line

-move the command to show all tag results to the bottom since it is considerably more likely that the user wants to navigate to a specific page.

-No longer artificially limit the list of results

-Only tags that are direct matches to what the user entered should be shown
      --they should overlap the URL, not the title
      --they should be right aligned

-The star stays on the title line, and is right aligned to line up with the star in the location bar

I think that is everything, unfortunately I don't have time to get a mockup posted right now but hopefully those comments are clear enough.
Sounds quite good to me. I like the idea for the autocomplete. As for intranet cases, I guess it would autocomplete to the top result; hopefully, IF you get an internet result that conflicts with a desired intranet result (or any other case of conflict), the first result will be the one you want the most (since Firefox fortunately sorts URLs by factors like number of visits, rather than alphabetically like the great majority of browsers still do).
(In reply to comment #49)
> -If the first result's URL starts with the URL the user entered, the location
> bar needs to inline auto complete to the TLD+1 of the first result
What do you mean by "to the TLD+1"?

http://www.city.mikasa.hokkaido.jp/
TLD+1: hokkaido.jp
ETLD+1: city.mikasa.hokkaido.jp

If you type "ww" it won't autocomplete because it's not part of ETLD+1?

Or are you basically saying the autocomplete will fill out and auto select the full domain including the trailing slash?

And this is only for the first result matching? If I type 2 letters that happens to match in the title of a very frequently visited page, but I'm actually trying to match the beginning of a domain, it won't autocomplete even if what I want is the 2nd result?
Sorry, I mean it will auto-complete the full ETLD+1, so if the top result is 

http://www.city.mikasa.hokkaido.jp/folder/anotherFolder/page.html

and you type "www.city.m", this will inline auto-completed in the location bar:

www.city.mikasa.hokkaido.jp/

>And this is only for the first result matching? If I type 2 letters that
>happens to match in the title of a very frequently visited page, but I'm
>actually trying to match the beginning of a domain, it won't autocomplete even
>if what I want is the 2nd result?

Yes, but how are we supposed to know you don't actually mean the very frequently visited first result?

I am not quite sure about autocomplete (I guess I would need to test what it does in real life), but for all other changes, I think that they are intuitive, and inline with my personal thoughts.
(In reply to comment #49)
> -The star stays on the title line, and is right aligned to line up with the
> star in the location bar

The star is outside of the location bar. I don't think you want to change that, given your comment about combining it with the Go button. However, I don't think the stars need to line up perfectly.
Depends on: 397594
I'm still confused about what you mean about autocompleting ETLD+1 -- why do you say ETLD+1 vs the full domain?

http://bugzilla.mozilla.org/ -> ETLD+1 = mozilla.org
http://bugzilla.site.com/ -> ETLD+1 = site.org

If you type "bugz", it won't autocomplete because you /haven't/ started typing the ETLD+1? So only after "bugzilla.m" will it autocomplete to bugzilla.m|ozilla.org/| where ||s is highlighted?

Similarly, if the only bugzilla site you've ever visited is bugzilla.mozilla.org, it still wouldn't autocomplete until you type the "m" for mozilla for the same reason as above?

What I assumed first was that if you type in text that matches the beginning of the domain of the first result, it'll fill in the whole domain and highlight the rest that it autocompleted.
I mistook the diference between tld and etld we are just talking about the full domain name being inline auto completed
Seth: beltzner would like us to implement at least the transition to the richlistbox widget for M9.  I'll try to post a new mockup as soon as I can but I'm currently tied up with other visual refresh/icon design stuff.
Depends on: 399281
Spun off bug #399281 for the richlistview
sorry, richlistbox
idea for future iteration: Allow users to copy the URL of the selected item in the location bar auto-complete by hitting accel-c
idea for a future iteration (not sure if I've documented this one yet): let the user enter times into the location bar as well, like "today", "yesterday" and "october." Also maybe in addition to search terms?: "today icons", "yesterday youtube" "october flight"
(In reply to comment #61)
> Also maybe in addition to search terms?: "today icons", "yesterday
> youtube" "october flight"

In general, there should be support for multiple search terms. That's the autocomplete feature that I currently miss the most.
Shouldn't this bug depend on bug 314166? It doesn't seem very accurate to me to say "Search Bookmarks and History" if Firefox is not searching the names of bookmarks.
(In reply to comment #27)
> http://people.mozilla.com/~faaborg/files/granParadisoUI/places_UnifyingSearch_i2.png
(In reply to comment #49)
> -Title is always on the top line, URL is always on the second line

Where should the tags be placed and how should text be cropped?

I think the tags should go on the second line to cause the URL to crop instead of the title. I've noticed that with the current autocomplete, even if I type "bugzilla" to match the URL, I'm looking at the titles, so hiding the title is probably not as useful than hiding the URL -- especially so for those that don't understand URLs in the first place.

If the title does need to get cropped, crop right will probably work well.

However, URLs are interesting at both ends -- the domain on the left and query parameters on the right. So should we be cropping center instead of right?

E.g., when I type "bugzilla" on my small laptop display, all I see are rows and rows of:
https://bugzilla.mozilla.org/show_bug.cgi?id...
https://bugzilla.mozilla.org/show_bug.cgi?id...
https://bugzilla.mozilla.org/show_bug.cgi?id...
and "Bug ## - <maybe 2 words>..." for the title

This would probably be something more for advanced users, but often file at the end of the path can be useful:

http://www.cnn.com/2007/WORLD/weather/11/01/tropical.storm
crop right:  http://www.cnn.com/2007/WORLD/weather...
crop center: http://www.cnn.com/20...1/tropical.storm
Depends on: 403159
(In reply to comment #42)
> There's browser.urlbar.autoFill. It doesn't work if your match isn't at the
> beginning of the address, for obvious reasons.

Since we are on the topic of inline autocomplete, I assume you are aware that it has been somewhat broken since Firefox 2 (bug 357722). Namely, I think it doesn't complete the best match inline if the user has typed a string that does not contain the beginning 'www' of an address (e.g. 'cnn.com').

> Since we are on the topic of inline autocomplete, I assume you are aware that
> it has been somewhat broken since Firefox 2 (bug 357722). 

autocomplete is totally new in Firefox 3 since it is using places
(In reply to comment #66)
> > Since we are on the topic of inline autocomplete, I assume you are aware that
> > it has been somewhat broken since Firefox 2 (bug 357722). 
> 
> autocomplete is totally new in Firefox 3 since it is using places
> 

Yes, I know, however, last time I checked (M9), the problem was still there.

Depends on: 406215
Blocks: 406240
Depends on: 406241
No longer blocks: 406240
Blocks: 406254
Blocks: 406255
Blocks: 406257
No longer blocks: 395161
Depends on: 395161
No longer blocks: 406254
Depends on: 406254
No longer blocks: 406255
Depends on: 406255
No longer blocks: 406257
Depends on: 406257
Depends on: 406259
A minor improvement for autocomplete.css:
Replace:
  .autocomplete-richlistbox > richlistitem[selected="true"]
With:
  .autocomplete-richlistitem[selected="true"]
Faaborg suggested that other improvements be noted here.

In bug #408621, Martijn has a few suggestions (via code and screen shot).

They are:

1)  vertically center the favicon
2)  vertically center the star/tag
3)  In a result, the tag/star "eats into" the text, so the ellipsis for a title or url won't line up (between two rows, if one is starred/tagged and one is not).  this gives more room for the text when there is no star/tag image.

See https://bugzilla.mozilla.org/attachment.cgi?id=295120 for a screen shot.

faaborg seems ok with #1 and #2, but only if we remove the separator line.  see https://bugzilla.mozilla.org/show_bug.cgi?id=408621#c29 for his comments.
alfred wrote:

> A minor improvement for autocomplete.css...

This fix was made, see http://lxr.mozilla.org/seamonkey/search?string=autocomplete-richlistitem[sel
(In reply to comment #69)
> Faaborg suggested that other improvements be noted here.

See also attachment 294887 [details] in bug 407204 for same sized titles and URLs and system colors (bug 409974).
Here's another autocomplete layout:

http://extjs.com/deploy/dev/examples/form/forum-search.html

Pagination, for example, is an interesting idea to deal with a big number of results. It also has a throbber (bug 402968 comment 26).
Depends on: 407861
Adding myself to cc list as bug 40625 has been duped to this.
>faaborg seems ok with #1 and #2, but only if we remove the separator line

Quick clarification, I think we should kill the line and not do 1 and 2:

>>I would like us to consider dropping the lines, and using white space
>>to separate results to make the interface visually cleaner, in which case
>>vertically centered favicons makes it harder to differentiate rows because you
>>can't leverage the top edge of the favicon to detect a border.

I'll try to follow up with new mockups for discussion soon, still pretty busy with icon stuff at the moment though.
Like Alex I do not like #1 and #2 in https://bugzilla.mozilla.org/show_bug.cgi?id=393508#c69 the results looks ugly imo.
Well, I do, but then personal taste is different for everybody. That is why we have 'themes'. The current setup doesn't allow (with an overriding binding) to vertical align the icons, but with the patch for bug 408621, the themer can much easily define the vertical alignment (center, start, or even end). It also makes the richlist item XUL structure simpler.

Here we should distinguish between the 'backend' and the theme defined 'frontend'.
Whether a line is shown between items is frontend matter, but how the XUL is structured is backend matter but should not impose layout.
Blocks: 407204
I think I remember reading in one of the many Places bugs that it is intended to provide some sort of feedback that search is still going on (there is what looks like a throbber replacing the favicon in the latest mockup, i2). Is there a separate bug already filed for that? If not, there is already bug 413497.
Depends on: 409974
This was a tracking bug for Firefox 3 development, the awesome bar is now being used by 15 million people daily :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified
Status: RESOLVED → VERIFIED
No longer depends on: 406215
Summary: Mockup: Location Bar Autocomplete → Mockup: Location Bar Autocomplete for Firefox 3
Target Milestone: --- → Firefox 3
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.