Status

defect
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: openjck, Assigned: groovecoder)

Tracking

Details

(Whiteboard: [specification][type:change])

(Reporter)

Description

6 years ago
What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
In-site search results should be changed. Some example results:
https://developer.mozilla.org/en-US/search?q=HTML

What problems would this solve?
===============================
This would allow users to find the content they are looking for more quickly and easily.

Who would use this?
===================
The same people who are using search now -- people who know roughly what kind of content (and sometimes exactly what content) they are looking for.

What would users see?
=====================
Aside from better results, the search result page should look the same.

What would users do? What would happen as a result?
===================================================
Same as now -- enter a search term, look at the results, click on a few results. The only real difference is that the results users choose should be closer to the top. If the search term was something very specific (like "JavaScript Guide") that result should be the very first choice.

Is there anything else we should know?
======================================
(Reporter)

Updated

6 years ago
Duplicate of this bug: 823723
(Assignee)

Updated

6 years ago
Depends on: ops-es-mdn
(Assignee)

Updated

6 years ago
Assignee: nobody → lcrouch
Not setting a blocker, but I suspect indexing for elasticsearch will also require the use of Celery/Rabbit (bug 766627)
(Assignee)

Comment 3

6 years ago
Yeah, it should block.
Depends on: 766627
(Reporter)

Comment 4

6 years ago
Added it as a blocker in Kanbanery too.

Comment 5

6 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/07eb55ae2bfb823ab61a0897af09cc9bbdd96ca6
bug 839214 - elasticutils and search mapping

add elasticsearch-head plugin

simple cron to reindex documents

update vendor submodule for elasticutils

https://github.com/mozilla/kuma/commit/9b1094703f094e432329edee0a4f1eea99e6279a
Merge pull request #881 from groovecoder/document-index-794525

bug 839214 - elasticutils and search mapping
(Reporter)

Updated

6 years ago
Whiteboard: [specification][type:change] → [specification][type:change][selected]
Front-end proposal:

*  Search box at top of the page with term, if present
*  Heading with "Search Results for {term}"
*  List of results
*  Paging, if required, will display at the bottom of the result set, looking as much like the rest of the site's paging

*  Attempt to get autocomplete working for search box in both header and search page.

Comment 8

6 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/49c5891246f536b0361772dc3dcc3ba69fab1443
bug 839214 - add celery tasks for es indexing

elasticutils tasks broken; add tasks in search app

test

https://github.com/mozilla/kuma/commit/d6f933a47c2b3e130b69d91bb81f4c2cd412627a
bug 839214 - live indexing into elastic search

Code borrowed in large part from mozilla/fjord

update elasticutils, using pyelasticsearch with updated requests library

update test-utils library to eagerly test celery tasks
(In reply to David Walsh :davidwalsh from comment #7)
> Front-end proposal:
> 
> *  Search box at top of the page with term, if present
> *  Heading with "Search Results for {term}"
> *  List of results
> *  Paging, if required, will display at the bottom of the result set,
> looking as much like the rest of the site's paging
> 
> *  Attempt to get autocomplete working for search box in both header and
> search page.

This looks like a good way to go. No point in getting too deep into a massive amount of front-end work given the entire thing gets redesigned pretty soon anyway.
(Reporter)

Comment 10

6 years ago
(In reply to David Walsh :davidwalsh from comment #7)
> Front-end proposal:
> 
> *  Search box at top of the page with term, if present
> *  Heading with "Search Results for {term}"
> *  List of results
> *  Paging, if required, will display at the bottom of the result set,
> looking as much like the rest of the site's paging
> 
> *  Attempt to get autocomplete working for search box in both header and
> search page.

This sounds just like our current search results page, except that it will have paging. Is that correct? Also, can you share a mockup for what autocomplete will look like?
(Reporter)

Comment 11

6 years ago
Just talked with Sheppy and David on IRC. In short...

* The search results should look exactly as they do now, except that they should also
  be paginated. Pagination should look and behave just like it does on the /all page.
  https://developer.mozilla.org/en-US/docs/all
* When a user is typing in the search box, suggestions based on site content (rather
  than history) should automatically be provided. This is similar to the autocomplete
  feature of Google, except that the complete set of search results should not appear
  until the user hits "Enter" to complete his search. We have decided that the widget
  should look just like the link suggestion widget used in the WYSIWYG.

Signing off on this comment for design.
(Reporter)

Updated

6 years ago
Whiteboard: [specification][type:change][selected] → [specification][type:change]

Updated

6 years ago
Blocks: 837294
(Assignee)

Updated

6 years ago
Duplicate of this bug: 794525
(Assignee)

Updated

6 years ago
Blocks: 672672, 768456, 844926
(Reporter)

Updated

6 years ago
Priority: -- → P1

Comment 13

6 years ago
I believe this solution would solve most of the requirements in Comment #11. Facetview - Pure Javascript Frontend for SOLR and ElasticSearch. 
It lets you easily embed a faceted browser and search front end into any web page. It also provides a micro-framework you can build on when creating user interfaces to SOLR and ElasticSearch.

Project Link:
https://github.com/okfn/facetview

Demo:
http://okfnlabs.org/facetview/
(Reporter)

Updated

6 years ago
Priority: P1 → P2
(Reporter)

Updated

6 years ago
Priority: P2 → P1
(Assignee)

Updated

6 years ago
Depends on: 872016
(Assignee)

Updated

6 years ago
Depends on: 872019
(Assignee)

Updated

6 years ago
Depends on: 873265
(Assignee)

Updated

6 years ago
Depends on: 874935
(Assignee)

Updated

6 years ago
No longer depends on: 873265
(Reporter)

Updated

6 years ago
Depends on: 877239
(Reporter)

Updated

6 years ago
Depends on: 870526
(Assignee)

Updated

6 years ago
No longer blocks: 844926
Depends on: 844926
(Assignee)

Updated

6 years ago
No longer depends on: 870526, 877239
(Assignee)

Updated

6 years ago
Depends on: 877514
Depends on: 880027
(Reporter)

Updated

6 years ago
Depends on: 879983
(Reporter)

Updated

6 years ago
Depends on: 879986
(Reporter)

Updated

6 years ago
Duplicate of this bug: 670815
(Reporter)

Updated

6 years ago
Depends on: 884642
(Reporter)

Updated

6 years ago
Depends on: 884876
(Assignee)

Updated

6 years ago
Depends on: 886577
(Reporter)

Updated

6 years ago
Depends on: 882005
(Reporter)

Updated

6 years ago
Depends on: 890110
(Reporter)

Comment 16

6 years ago
Changing the title to reflect that this is a tracker for all issues and improvements that should block Elastic Search launch.
Summary: Use Elastic Search to power in-site search → Launch Elastic Search
Depends on: 911374
(Reporter)

Comment 17

6 years ago
Updating this title further to reflect that this bug will track blockers for the Elastic Search /MVP/ launch. I will later create a bug for tracking further improvements to Elastic Search that can happen after launch.
Blocks: 914828
Summary: Launch Elastic Search → Launch Elastic Search MVP
(Reporter)

Updated

6 years ago
Summary: Launch Elastic Search MVP → Elastic Search MVP
(Reporter)

Updated

6 years ago
No longer blocks: 672672
Depends on: 672672
(Reporter)

Updated

6 years ago
Blocks: 917851
No longer blocks: 914828
(Assignee)

Updated

6 years ago
No longer depends on: 879986
(Assignee)

Updated

6 years ago
Depends on: 917992
(Assignee)

Updated

6 years ago
No longer depends on: 882005
(Assignee)

Updated

6 years ago
No longer depends on: 879983
(Assignee)

Updated

6 years ago
Depends on: 877239
(Assignee)

Updated

6 years ago
No longer depends on: 844926
(Assignee)

Updated

6 years ago
No longer depends on: 672672
(Reporter)

Comment 18

6 years ago
All dependencies are closed. As always, we can open additional bugs for further improvements.

Congratulations, everyone!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.