1340663 - Figure out requirements to release top websites completion in the awesomebar

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Bug 1211726 implemented a feature that suggests top websites to new profiles for 14 days. The list of pages is currently hardcoded here:
http://searchfox.org/mozilla-central/rev/59cd73fbfa14384a81a4e3eb17d3881b372702c4/toolkit/components/places/UnifiedComplete.js#574

The sites are suggested as autoFill and/or as normal history entries.
These results can be replaced by normal browsing history, and the feature automatically disabled when the profile is 14 days old.

This bug is about figuring out what we need to let this reach Release users:
1. Which questions do we need to answer for approving it?
2. which bugs are blocking a release-quality state of the feature?

Ni? javaun to figure the first part, we can handle the engineering part.

Comment 1

[:Gijs (he/him)]

Dolske, I assume that given legal OK'd 858829, we don't need a separate legal review. Do you know if that's right?

Comment 2

[Javaun Moradi [:javaun]]

Gijs: assuming that we use the same mechanism articulated in bug 858829 it's likely still valid. In general we should always run older approvals through legal to make sure they're still valid (sometimes external factors like changes to Terms of Services, laws, etc. can change our status). If we deviate from that approach we may need a new review.

Comment 3

[Javaun Moradi [:javaun]]

Didn't mean to clear the NI from Mak...

Comment 4

[Javaun Moradi [:javaun]]

I added a user story. This is not exhaustive criteria, but I've had policy/legal and some UR/UX conversations. We do need to think about some aspect of either localization or constraining this to the point where it's less useful but also more neutral to country. I'm looking at Alexa top 50 for 3 markets now and see decent variation. 

I agree with Bill Selman, we should do some user testing to see how this is received, both for positives and for adverse side effects. 

Barring that, I think this is one to put on the trains. If we're not doing harm, we'll do more learning as we ride the trains.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Javaun Moradi [:javaun] from comment #4)
> or constraining this to the point where it's
> less useful but also more neutral to country.

I think it's not easily feasible, unless we reduce this to the few domains doing automatic redirects. As an example I previously made, it's true that I can go to amazon.com and it will suggest me to go to amazon.it through a big "you're in the wrong place" banner, but that's far from a nice experience.

> Barring that, I think this is one to put on the trains. If we're not doing
> harm, we'll do more learning as we ride the trains.

It's likely we want to first add some telemetry to track usage, as a requirement before riding the trains? Currently these entries appear in telemetry as any other autofill/history entry.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

As previously said, we should also filter out ads network, I doubt we can find an alexa service that provides us the proper filter for both ads and adult. The official Alexa API doesn't provide any kind of filtering by a quick look at their documentation.

If we'd ever decide to do our own filtering, how do we define acceptable content? On the italian list in one of the top30 position I see a russian social network, that by itself is pretty much legit, but it is also largely used in Italy for adult and copyrighted videos sharing (3 years ago its dns record was blocked in Italy by law).

Finally, note that, we also have a disabled feature that allows us to autofill to the search engines we ship. bug 958188. That is less problematic to filter since it's made of engines we already ship and we could start measuring impact of it. It could be worth to add to the legal/privacy discussion since it falls down into a similar bucket.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I was evaluating with Drew an alternative to this feature in Search Suggestions.
Basically, the search engines can often suggest top sites among other suggestions. Currently we remove anything that looks like a host/url from suggestions, because one side we are concerned about users guessing where those urls come from (but styling of these entries is now nicer in the urlbar) and because we'd open a page to the search engine pointing to the url, that is not great.

Now, if we'd allow pure hosts to be suggested by Search Suggestions, and we'd directly visit that host instead of going through the search engine, we'd pretty much have a top hosts feature. We should probably show a magnifier glass and a "-- Visit" suffix for these entries.
Chrome does something similar, if you type "www.f" it will suggest hosts like "www.facebook.com" (with a magnifier icon) and directly visit those.

Clearly this doesn't take into account eventual PM plans for the original feature that I'm not aware of.

Comment 8

[Mike de Boer [:mikedeboer]]

(In reply to Marco Bonardo [::mak] from comment #7)
> Now, if we'd allow pure hosts to be suggested by Search Suggestions, and
> we'd directly visit that host instead of going through the search engine,
> we'd pretty much have a top hosts feature. We should probably show a
> magnifier glass and a "-- Visit" suffix for these entries.
> Chrome does something similar, if you type "www.f" it will suggest hosts
> like "www.facebook.com" (with a magnifier icon) and directly visit those.

I, for one, really like that idea, since it seems relatively cheap to implement. If we can additionally increase the weight if URLs that were clicked this way, we can have it appear at the top of the users' list each time, right?
We could move this to a separate bug to implement and leave this 'local' autocompletion feature.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I think the 2 implementations are exclusive, I'd not want 2 "top sites" code bases around.
At this point the decision is likely up to product management, and Gijs, who drove the initial implementation.

Comment 10

[:Gijs (he/him)]

(In reply to Marco Bonardo [::mak] from comment #9)
> I think the 2 implementations are exclusive, I'd not want 2 "top sites" code
> bases around.
> At this point the decision is likely up to product management, and Gijs, who
> drove the initial implementation.

I don't think it's really my decision any more than yours, if that helps. Some feedback inline:

(In reply to Marco Bonardo [::mak] from comment #7)
> Basically, the search engines can often suggest top sites among other
> suggestions.

Which search engines do this?

> Currently we remove anything that looks like a host/url from
> suggestions, because one side we are concerned about users guessing where
> those urls come from (but styling of these entries is now nicer in the
> urlbar) and because we'd open a page to the search engine pointing to the
> url, that is not great.
> 
> Now, if we'd allow pure hosts to be suggested by Search Suggestions, and
> we'd directly visit that host instead of going through the search engine,

Who determines what is a 'pure host', and how? (Cf. bug 1080682 and friends)

> we'd pretty much have a top hosts feature. We should probably show a
> magnifier glass and a "-- Visit" suffix for these entries.

I mean, this would solve the same issue (how to distinguish these sites) for the implementation that this bug covered, right?

> Chrome does something similar, if you type "www.f" it will suggest hosts
> like "www.facebook.com" (with a magnifier icon) and directly visit those.

Some downsides:
- AFAICT, Chrome does this for "www.<something>" but not for "something". So typing "twitter" or "facebook" doesn't suggest the URL, just search terms, which still show the search page. If this also applies to the suggestions we get (which I assume is the case though I could obviously be wrong - can't easily tell from the UI) then this leaves out a significant part of where we could be helpful to the user.
- is dependent on the search engines doing / continuing to do this
- requires the network request to the search engine to be fast in order to give a good UX. This is probably the case for all of us, but definitely isn't for all of our users.
- won't necessarily use the canonical URL (with/without www, toplevel domain redirect (e.g. com to org or vice versa), etc.), which a fixed list would help with, which helps performance
- can't have any descriptions / favicons for the results
- won't work for people who disable search suggestions (or even disable search in the awesomebar entirely)

Some upsides:
- sounds somewhat easier to implement
- won't need to update a fixed list or worry about l10n

> Clearly this doesn't take into account eventual PM plans for the original
> feature that I'm not aware of.

I wouldn't expect there to be plans but I also haven't asked.

So I don't know, there's pros and cons for both solutions. I lean a bit towards the local solution because it offers us more control and has some performance advantages, but I also see the appeal of having something that is hopefully simpler to implement and will potentially/hopefully require less maintenance in future. If anything, I think you (ie Marco) 'own' autocomplete / the urlbar, so I think ultimately it's up to you and product. I definitely agree that the implementations are exclusive and if we decide to go the search engine route we should remove the local implementation. We might then also want to remove the one we do ship on Android in favour of a search-engine-based one.

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I'll try to answer some of those.

(In reply to :Gijs from comment #10)
> Which search engines do this?

Good question, Google, Yahoo, Bing and DDG all seem to suggest domains if I type "www.word" or "word."

> Who determines what is a 'pure host', and how? (Cf. bug 1080682 and friends)

if the user types "www." it's trivial, otherwise we could potentially ask for suggestions of "www.whatusertyped" and pick the first couple ones.

> > we'd pretty much have a top hosts feature. We should probably show a
> > magnifier glass and a "-- Visit" suffix for these entries.
> 
> I mean, this would solve the same issue (how to distinguish these sites) for
> the implementation that this bug covered, right?

Yes, presentation problems are similar, even if the magnifier lens may solve part of that.

> - AFAICT, Chrome does this for "www.<something>" but not for "something". So
> typing "twitter" or "facebook" doesn't suggest the URL, just search terms,
> which still show the search page.

Right, but nobody prevents us to send a "www.usertyped" request and get results for it.

> - is dependent on the search engines doing / continuing to do this

I doubt they'll stop, Chrome and Edge use that feature.

> - requires the network request to the search engine to be fast in order to
> give a good UX. This is probably the case for all of us, but definitely
> isn't for all of our users.

Speed has never been a strict requirement for the feature we are discussing.
But yes, we may not be able to provide autofill in a timely manner, it would just be search suggestion entries. Autofill was a nice-to-have afair, maybe I'm wrong.

> - won't necessarily use the canonical URL (with/without www, toplevel domain
> redirect (e.g. com to org or vice versa), etc.), which a fixed list would
> help with, which helps performance

I doubt this, it's unlikely engines will suggest wrong domains

> - can't have any descriptions / favicons for the results

I don't think the description is critical, autofill doesn't have one and users have no problem with that.
Sure, favicons would be replaced by the magnifier icon.

> - won't work for people who disable search suggestions (or even disable
> search in the awesomebar entirely)

But people who disable search suggestions filed bugs asking why we suggested these domains even if search suggestions were disabled.