gcomanici@:

It would be helpful to have a motivating example: a screenshot of where the current behavior is bad.

See attached a screenshot coming from a session running under the experiment decribed in crbug.com/682420. 

"See Gary Danko on Google Maps", "Make a resevation", and "More information on Gary Danko" are all describing what we are suggesting a lot better than "https://google.com/...." and "www.opentable.com/...."

Deleted: sJAKDvn92LY.png 645 KB

	sJAKDvn92LY.png 645 KB View Download

It looks like in this case none the titles are being elided (truncated).

Re-reading your comment, I guess I misunderstood your request.  Revising bug summary.

It sounds like you want the title be more prominent, e.g., swapped in position with the URL.  Is that right?

(If so, this sounds a bit like bug 338066, just specialized for the zero suggest case.)

cc bruno, UX for thoughts

Indeed, bug 338066 is what I was going for. IMO, the main problem is not the screen real estate. Rather I would argue that the value of the information we display is low. It makes more sense to display in light green secondary information, which in the case of zero suggest suggestions is the URL. The purpose of zero suggest suggestions is to "provide useful/novel content to the user" (as opposed to "matching a sequence of typed characters against the user's history of visited URLs").

Also, I am attaching the scenario on a screen that is much smaller than my 24inch screen. :-) 

Deleted: UiP6KcHyWSU.png 613 KB

	UiP6KcHyWSU.png 613 KB View Download

I completely agree. ainslie@ explored a few possible alternatives for this (https://docs.google.com/presentation/d/1PyxiCQ1O1bvLHTvMOY8IT-SSe6sr7M6aZ3Y1EgXsuzQ), not sure where they landed.

In any case, in the short term, I think we should include titles along with URLs, irrespective of how they're displayed. URLs by themselves are cryptic, technical and often don't convey any meaning.

I think you're generalizing too broadly (and I don't think our research supports your generalizations).  Titles are sometimes very helpful and sometimes worthlessly vague or stuffed with keywords.  URLs are sometimes extremely useful, even to laymen, and sometimes full of meaningless hashes.  Salient examples of each are easy to find and don't prove generalizations about which is better overall.  It's not clear to me what the right default answer is.

The omnibox has experimental code to reverse the ordering when titles match (or when they exclusively match) the input string.  But in this case, even if we enabled that experiment, it wouldn't really be effective, because ZeroSuggest looks to be providing results based more on the phrase "Gary Danko" than on the input garydanko.com.  One possibility is that ZeroSuggest data could report whether it matched this due to the URL or title, or cuold return a relevant query string the omnibox should consider the "original query" when looking for substring matches to decide how to display URL and title.

ainslie@ has told us omnibox folks that he's delegated maxwalker@ and bettes@ to be our omnibox UI contacts on desktop (at least for as-you-type suggestions).  Adding them here and removing ainslie@.  (Please add yourself back if you care to.)

Looking at this screenshot, I'd find domain + title to be the most useful thing.  I dislike how some titles hide the important bit, e.g., "See Gary Danko on Google Maps".  I'd rather see Google Maps or maps.google.com first, then the title, and no need for the rest of the URL.

Maybe this is an eliding problem, as I originally supposed.  Can we simply elide zero suggest suggestions at the end of the domain name?  Maybe that'll do what we want.

Sounds like some of the ideas in the deck linked in comment 8.

My question would be how specific to ZeroSuggest this is.  For example, if it's more problematic there because I'm being suggested URLs I'm less likely to recognize, or if it's more solvable there because the server knows something about how to best format these results for usability.

If this devolves to the general case of "sometimes URLs aren't the best", then the slide deck explores that more.

In the case of zero-suggest suggestions only, indeed, my intuition is based exactly on the points you raised:

1. Users are suggested URLs which they might not recognize.

2. The server has information that can be used to format these titles. The screenshot I attached is one example where the server built the title from a relevant query string (i.e. "Gary Danko"). I will mention though that the server does not have this for all suggestions. If necessary, we could provide numerical coverage for this.

I would also add that, in the case of zero-suggest suggestions, the input is not "www.garydanko.com" but "I am leaving www.garydanko.com". Hence the suggestions are not based on "www.garydanko.com", but based on pages which are known to provide additional info on topics detected on the page the user is leaving.

Right.  A case where we've constructed a title, which isn't the actual page title, seems much more likely to be a high-quality string to display.  I can well believe that in those cases we could have confidence in saying that the "title" is more informative.

In cases where we don't have such "titles" (and we're e.g. using the real page title), I wonder whether the server can provide hints as to how the client would know which of (url, title) would be more relevant to the user.  

Titles coming from Cusco use the exact same mechanism as Web Search. Sometimes they are significantly different from <title>...</title> contents, often completely replacing it.

Example:

Query: pandu nayak
Title shown: Pandu Nayak
URL shown: www.pandunayak.com/
Actual title: www

https://screenshot.googleplex.com/HeRzHGP7XST
https://screenshot.googleplex.com/VPMQiMRN9T6



Another data point: On mobile we're already showing titles first and then the URL:

Zero Suggest (top sites): https://screenshot.googleplex.com/Ka12OjvEGEa
Query completion: https://screenshot.googleplex.com/DnNU1M0C7qt

I have added a new feature that allows to experiment swapping title and description for zero suggest suggestions only (find attached a screenshot).

@mpearson notes that it looks a little odd to have the current page's URL on the left here next to the other pages' titles. He suggests that we display the current page's URL with the title on zero suggest to address this.

I personally find it odd that the current page's URL is present in the list, but I understand that there might be some historical reason (of which I am not aware) why this happens. The best solution would be to remove the current page's URL, but I like Mark's alternative.

Deleted: GuXWmY3NfC6.png 376 KB

	GuXWmY3NfC6.png 376 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba64a6af8eb5ce7ff17219925fa9c0de5a324554

commit ba64a6af8eb5ce7ff17219925fa9c0de5a324554
Author: gcomanici <gcomanici@chromium.org>
Date: Wed Mar 01 23:06:06 2017

Invert description and URL for experimental zero suggest suggestions.

BUG=682420,  693649 

Review-Url: https://codereview.chromium.org/2716273004
Cr-Commit-Position: refs/heads/master@{#454084}

[modify] https://crrev.com/ba64a6af8eb5ce7ff17219925fa9c0de5a324554/components/omnibox/browser/autocomplete_result.cc
[modify] https://crrev.com/ba64a6af8eb5ce7ff17219925fa9c0de5a324554/components/omnibox/browser/features.cc
[modify] https://crrev.com/ba64a6af8eb5ce7ff17219925fa9c0de5a324554/components/omnibox/browser/features.h
[modify] https://crrev.com/ba64a6af8eb5ce7ff17219925fa9c0de5a324554/components/omnibox/browser/omnibox_field_trial.cc
[modify] https://crrev.com/ba64a6af8eb5ce7ff17219925fa9c0de5a324554/components/omnibox/browser/omnibox_field_trial.h

Filed my suggestion as bug 697624:
"ZeroSuggest: The Current URL Suggestion Should Show Its Title"

Once we have that, gcomanici@'s current experimental code would allow us to flip the title and URL just like regular zero suggest suggestions.


As for the comment about why we display the the current page's URL in the list.  There is a long history here.  The short summary is that we tried removing it and it didn't work well for users.  Users apparently sometimes want/need a click target.

This bug has effectively been fixed.  We've turned on the title-first behavior for zero suggest on desktop for most users.  There are some other UI ideas that could be explored, but none are (in my opinion) important enough to be worth keeping this bug open for.