Closed Bug 847625 Opened 12 years ago Closed 11 years ago

Port search suggestions to Fireplace

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cvan, Unassigned)

References

Details

(Keywords: productwanted, uiwanted, Whiteboard: [fireplace] p=2)

Priority: -- → P3
Whiteboard: [fireplace] → [fireplace] p=1
Blocks: 859511
Keywords: uiwanted
Summary: Port search suggestions JS to Fireplace → Port search suggestions to Fireplace
Whiteboard: [fireplace] p=1 → [fireplace] p=2
Maria/David, what should be do here? Should we move forward with search suggestions? Port the existing ones or work on generating some search terms?
Keywords: productwanted
Flags: needinfo?(msandberg)
Not sure I am understanding the question.  Are you asking if we should work on generating new search terms (ie. tweaking the suggestions returned) vs use the existing ones? 

I would suggest that the priorities are 1) port existing 2) generate new (depending on how difficult this is).  Can #2 be continously tweaked and or improved while not affecting Fireplace?
I agree with David's prioritization.
Flags: needinfo?(msandberg)
If we are going to have search suggestions, I think we should consider a separate API for this. The current search API returns *a lot* of data that we don't need and if this is going to be queried every key press we can avoid excessive network traffic by using an API specific to search suggestions.
(In reply to Rob Hudson [:robhudson] from comment #4)
> If we are going to have search suggestions, I think we should consider a
> separate API for this. The current search API returns *a lot* of data that
> we don't need and if this is going to be queried every key press we can
> avoid excessive network traffic by using an API specific to search
> suggestions.

Yeah, I don't think anyone wanted to repurpose the search API for suggestions - that would defeat the whole point of quick search suggestions. But either way it sounds like UX (or probably just Basta) don't want name-based search results anymore. So I'm not sure an API endpoint will be necessary. I'm sure we'll have a conclusion in the next few weeks here.
Thanks to bug 898020 we now have a simple suggestions API. (The implementation details is still subject to change though)

Did we ever reach a conclusion regarding what we want to do ? I could easily hook up that suggestion API to our consumer pages if we want that.
I'm going to close this bug. Nobody has asked for search suggestions or complained that we don't have them anymore. Personally, I think the performance penalty of having them really wasn't worth it (loading the results, app icons, rendering, etc.).

If UX/product provides a spec and mocks, we can revisit this.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
I have received several comments "what happened to search suggestions".  I think we should investigate whether we need it.  I personally like it (except that I wasn't finding the suggestions particularly useful at that time), but I am a data point of 1.  I will go through all our Marketplace Feedback forms to see if we have any feedback or requests for this.
I think part of the usefulness of search suggestions is to be able to skip directly to a search result that you know exists, or in the case of Maria's intended behavior, skip to a search term that you want to arrive at. Each of these behaviors isn't something I think we can target right now:

- The majority of users searching for exact app names are searching for apps that we don't carry, so search suggestions won't help. If you type "whatsapp" and we show "Loqui", that's not a helpful suggestion.
- We get a relatively small number of searches (compared to other sites and app stores), meaning we don't have sufficient amounts of data to provide good search term suggestions. There's also a level of security here, as well: one troll user searching for "butts" a few dozen times a day could bias search term suggestions to show "butts" any time someone types "b" in the search box.
- Only a third of our visitors use search. Of those that do, half get an empty results list (one sixth of our visitors). That means that half of the time search suggestions would provide absolutely no benefit whatsoever, since we don't have what the user wanted anyway.

I think until we have more apps and more searches, this isn't going to be a really useful feature for users.

Consider the perf reasons, as well:

- Each "round" of search suggestions might fire off one or two dozen HTTP requests (icons, searches, etc.).
- 1.1 fixes many of the performance issues surrounding layout in FXOS (especially position:fixed-related issues), but many of the more awful problems won't be fixed until 1.2 or 1.3 because they got fixed sometime around Firefox 23.
- To keep app suggestions fast, we wouldn't send down the full app object in the server response. That means that using a search suggestion would virtually always result in a model cache miss, meaning the page would take upwards of five to ten seconds to perform the necessary requests to load the app's details instead of instantly as a normal search result would.
All good points.   I looked at search terms, and for most of the search terms that people are searching for, we do not have good suggestions if their intent is to find a specific app (which largely it is).

I think we should keep this feature on the back burner - like for the future when it may be more useful and provide the shortcut to an app that people are looking for.

(In reply to Matt Basta [:basta] from comment #10)
> I think part of the usefulness of search suggestions is to be able to skip
> directly to a search result that you know exists, or in the case of Maria's
> intended behavior, skip to a search term that you want to arrive at. Each of
> these behaviors isn't something I think we can target right now:
> 
> - The majority of users searching for exact app names are searching for apps
> that we don't carry, so search suggestions won't help. If you type
> "whatsapp" and we show "Loqui", that's not a helpful suggestion.
> - We get a relatively small number of searches (compared to other sites and
> app stores), meaning we don't have sufficient amounts of data to provide
> good search term suggestions. There's also a level of security here, as
> well: one troll user searching for "butts" a few dozen times a day could
> bias search term suggestions to show "butts" any time someone types "b" in
> the search box.
> - Only a third of our visitors use search. Of those that do, half get an
> empty results list (one sixth of our visitors). That means that half of the
> time search suggestions would provide absolutely no benefit whatsoever,
> since we don't have what the user wanted anyway.
> 
> I think until we have more apps and more searches, this isn't going to be a
> really useful feature for users.
I think you are right.
> 
> Consider the perf reasons, as well:
> 
> - Each "round" of search suggestions might fire off one or two dozen HTTP
> requests (icons, searches, etc.).
> - 1.1 fixes many of the performance issues surrounding layout in FXOS
> (especially position:fixed-related issues), but many of the more awful
> problems won't be fixed until 1.2 or 1.3 because they got fixed sometime
> around Firefox 23.
> - To keep app suggestions fast, we wouldn't send down the full app object in
> the server response. That means that using a search suggestion would
> virtually always result in a model cache miss, meaning the page would take
> upwards of five to ten seconds to perform the necessary requests to load the
> app's details instead of instantly as a normal search result would.
My two cents: It seems totally fine to keep this feature on the back burner for now. When you do decide to implement it, please consider not using the search suggestions as a list of search results (shortcut to an app). 

The suggestions should be to reduce typing, not to remove the search results page. If we start putting results in the suggestions list we will end up bypassing a bunch of apps that would have shown up on the search results page. No need to have this discussion right now, just wanted to put in a reminder. Happy to chat about this more when we bring the feature back if that would be helpful :)
See Also: → 1010369
You need to log in before you can comment on or make changes to this bug.