Search Provider Top Suggestion

NEW
Unassigned

Status

()

Firefox
Search
P4
normal
Rank:
45
4 years ago
2 months ago

People

(Reporter: MarcoM, Unassigned)

Tracking

(Depends on: 4 bugs, Blocks: 2 bugs)

unspecified
x86_64
All
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [recent][fxsearch], URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

4 years ago
1.  Goal:
* As a Firefox Desktop user I want the visual cue for my search engine domain to be the highest in the list so I can auto-complete directly to my search engine faster.
 
2.  Acceptance Criteria (AC): 
* When a user types the search engine domain in the URL bar the search engine auto-complete becomes the top suggestion
* This search engine auto-complete simply completes the domain of the search engine and doesn’t perform a search 

3.  Notes/Supporting Documentation: 
* Intention is to give the best visual cue for a search engine domain and auto-complete a user to that space faster than typing directly
(Reporter)

Updated

4 years ago
Depends on: 958534
Created attachment 8359661 [details]
recent search terms in url bar.jpg
Comment on attachment 8359661 [details]
recent search terms in url bar.jpg

my bad, this is the wrong bug. :(
Attachment #8359661 - Attachment is obsolete: true
Depends on: 959571

Updated

4 years ago
Depends on: 959572
Depends on: 959573
Depends on: 959576
Depends on: 959579

Updated

4 years ago
Depends on: 959580
Depends on: 959581

Updated

4 years ago
No longer depends on: 959580

Updated

4 years ago
No longer depends on: 959572
(Reporter)

Updated

3 years ago
Whiteboard: [story] → [story] [search]
(Reporter)

Updated

3 years ago
Blocks: 973272
(Reporter)

Updated

3 years ago
No longer depends on: 959571
Depends on: 951624

Updated

3 years ago
Depends on: 993372

Updated

3 years ago
Blocks: 995091
(Reporter)

Updated

3 years ago
No longer blocks: 950073
Flags: firefox-backlog+

Updated

3 years ago
No longer blocks: 995091
Depends on: 995091

Updated

3 years ago
Depends on: 990799

Updated

3 years ago
Depends on: 1065997

Updated

3 years ago
Blocks: 1071461
I think here we need some PM and UX guidance.
Now the feature is enabled in Nightly, but it causes some fancy results, for example "t" suggests "twitter.com", but selecting the entry we go to "https://twitter.com/search-home" that is the search form for twitter. We do this cause we don't know if the raw domain points to a useful page, so we use a page that surely exists, the declared search form. Plus in future we want to count uses of the feature and thus we need a special url to be built.

While this works fine for search engines, where the search form is always useful, for content providers like twitter or wikipedia it doesn't work very well cause more often the user wants to go to the main page, and not to the search form page.

bug 1073846 is going to make the behavior a little bit less painful, cause if the user previously typed twitter.com, we will suggest the domain rather than the search form. But it's not covering any existing case.

We can't even decide the behavior based on the engine, cause we don't know which engines we can meet in the wild.

Now this will be in Aurora in a couple weeks, so shat should we do?
1. disable the feature
2. complete to the resultDomain and hope it will work for most engines
3. other ideas?
Flags: needinfo?(philipp)
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(clarkbw)

Comment 4

3 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #3)
>
> 3. other ideas?

Here is a proposal for this feature with the aim to give the user more control whether the typed url (e.g. twitter.com/) will be visited or the search-url (twitter.com/search-home) of the typed url:

- let's assume the user types a URL for a page with a search provider (e.g. twitter.com/)
- in this case, the first entry in the awesomebar popup changes from (currently):

  Visit twitter.com

to the output:

  Visit twitter.com
  <small> Hit the Tab key to search on this page</small>

(Think about the <small>...</small> text to be displayed at the bottom of the awesomebar popup entry)

- if the user hits the <Tab> key, the output changes to:

  Search On twitter.com
  <small> Hit the Tab key to visit this page</small>

This might be a good tradeoff between discover-ability of search providers and putting the user still in control which site s/he wants to go to.
For this feature specifically, I think it's clear that we shouldn't conflate "top suggestion" with "inline autocompleted suggestion". We should suggest search engine "searchforms" (as "Search with" entries), but we shouldn't let that override typed entries, and we shouldn't inline complete them, at least not in all cases. We'll need a revised design for this, I think.

In general, I think we'll need to disable unified autocomplete for 35, given the outstanding regressions, so that will address these issues too.
Flags: needinfo?(gavin.sharp)
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #5)
> In general, I think we'll need to disable unified autocomplete for 35, given
> the outstanding regressions, so that will address these issues too.

We can also just disable this specific piece (the search provider top suggestions).

which outstanding regressions would be blocking us from releasing the feature?
I think all of the missing pieces are manageable, at least from what we have so far.
Btw, this is likely discussion for a mail thread or a different bug.

Updated

3 years ago
Depends on: 1081305
I have filed UX bug 1081305 to redesign the feature, I'll ask for it to be added to the backlog

Updated

3 years ago
Flags: needinfo?(philipp)
Flags: needinfo?(clarkbw)
I think this is a very local problem, since it is only needed for the search providers we ship with (and, really, just the general purpose search providers at that). So essentially we'd need this behavior for Google, Bing, Yahoo, DDG and possible some others that we ship in other locales.
Marco, Gavin: What do you think of that?

Julian, I like your idea of using tab (or a different key) to search any site, but that's really a different feature. Would you mind filing a separate bug for that?
(In reply to Philipp Sackl [:phlsa] from comment #8)
> I think this is a very local problem, since it is only needed for the search
> providers we ship with

we ship with twitter search, and that's one of the problematic entries already.

Comment 10

3 years ago
(In reply to Philipp Sackl [:phlsa] from comment #8)
> 
> Julian, I like your idea of using tab (or a different key) to search any
> site, but that's really a different feature. Would you mind filing a
> separate bug for that?

Sure, opened bug 1083200. Note that I haven't put in a blocks/depends on as I am not sure what a good bug to make it relate to is - should it be this bug?
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #9)
> (In reply to Philipp Sackl [:phlsa] from comment #8)
> > I think this is a very local problem, since it is only needed for the search
> > providers we ship with
> 
> we ship with twitter search, and that's one of the problematic entries
> already.

Yes :)
What I meant was that this makes the most sense for general purpose search engines (like Google). But even if we do the behavior for all pre-installed search engines, that's a very limited number of sites, so (I think) we can customize the autocomplete URL on a case-by-case basis.
In Twitters case, we should definitely send the user to twitter.com and not to the search page.


(In reply to Julian Viereck from comment #10)
> (In reply to Philipp Sackl [:phlsa] from comment #8)
> > 
> > Julian, I like your idea of using tab (or a different key) to search any
> > site, but that's really a different feature. Would you mind filing a
> > separate bug for that?
> 
> Sure, opened bug 1083200. Note that I haven't put in a blocks/depends on as
> I am not sure what a good bug to make it relate to is - should it be this
> bug?

Thanks for filing! I made it block our search tracking bug.
(In reply to Philipp Sackl [:phlsa] from comment #11)
> What I meant was that this makes the most sense for general purpose search
> engines (like Google). But even if we do the behavior for all pre-installed
> search engines, that's a very limited number of sites, so (I think) we can
> customize the autocomplete URL on a case-by-case basis.
> In Twitters case, we should definitely send the user to twitter.com and not
> to the search page.

are you suggesting a whitelist?
While that may work, I have a couple concerns:
1. it should be done per locale, that puts the burden on l10n team.
2. users or providers of other search plugins, might think we give some engines a preference, like they are sponsoring us or such.
though, we might make this work only on engines that define a resultDomain attribute, and stop making resultDomain fallback to the host. If no resultDomain is provided, we don't autoFill that engine.
So anyone making an engine could opt-in to make the provided resultDomain go to the search form url.
This would still add some work on l10n, but should be a smaller chunk (basically remove resultDomain where the search form url doesn't make "sense" for this feature)
At that point we might rename resultDomain to something more meaningful (suggestions welcome, should sound like searchFormAutoFillHost).

The alternative is complete rethinking of the whole interaction.
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #13)
> though, we might make this work only on engines that define a resultDomain
> attribute, and stop making resultDomain fallback to the host. If no
> resultDomain is provided, we don't autoFill that engine.
> So anyone making an engine could opt-in to make the provided resultDomain go
> to the search form url.
> This would still add some work on l10n, but should be a smaller chunk
> (basically remove resultDomain where the search form url doesn't make
> "sense" for this feature)
> At that point we might rename resultDomain to something more meaningful
> (suggestions welcome, should sound like searchFormAutoFillHost).
> 
> The alternative is complete rethinking of the whole interaction.

That sounds good to me (remember though, I'm no engineer ;)

When you say rethink the interaction, do you have something specific in mind?
First and foremost, this feature is designed so that new installs (that haven't navigated to their search provider yet) will have a quick way to get to the home page of their default search provider.
No, I don't have anything specific in mind at this point. I meant probably we should indeed go back to the original purpose and figure a different implementation to obtain that.
I think comment 13 is the closest thing to a solution I may think of atm.

Updated

3 years ago
Depends on: 1088218
I think comment 13 sounds like a reasonable approach. At the very least, it means we can ship this in a usable state in the near future. If need be, we can go back to the drawing board later, but it won't need to be in such a rush.

Updated

3 years ago
Depends on: 1096962
I moved the approach in comment 13 to bug 1096962 so we can track it in the backlog

Updated

3 years ago
Depends on: 1097106
Bug 1097106 is instead about disabling the feature for milestone 1.

Comment 19

2 years ago
move to search component
Flags: needinfo?(sescalante)
Priority: -- → P4
Whiteboard: [story] [search] → [recent][fxsearch]

Updated

2 years ago
Component: Firefox Operations → Search
Flags: needinfo?(sescalante)
Product: Tracking → Firefox
Version: --- → unspecified

Updated

2 years ago
Rank: 45
You need to log in before you can comment on or make changes to this bug.