839214 - Elastic Search MVP

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Search, defect, P1)

Description

[John Karahalis [:openjck]]

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?
======================================

Comment 2

[Les Orchard [:lorchard]]

Not setting a blocker, but I suspect indexing for elasticsearch will also require the use of Celery/Rabbit (bug 766627)

Comment 3

[Luke Crouch [:groovecoder]]

Yeah, it should block.

Comment 4

[John Karahalis [:openjck]]

Added it as a blocker in Kanbanery too.

Comment 5

[[github robot]]

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

Comment 6

[Luke Crouch [:groovecoder]]

https://github.com/mozilla/kuma/pull/923

Comment 7

[David Walsh :davidwalsh]

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

[[github robot]]

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

Comment 9

[Eric Shepherd [:sheppy]]

(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.

Comment 10

[John Karahalis [:openjck]]

(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?

Comment 11

[John Karahalis [:openjck]]

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.

Comment 13

[karabajic]

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/

Comment 14

[[github robot]]

Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/3cabfa8814c36fdbedf91316edd55ab0fd28bbac
bug 839214 - add highlight matches to results

Comment 16

[John Karahalis [:openjck]]

Changing the title to reflect that this is a tracker for all issues and improvements that should block Elastic Search launch.

Comment 17

[John Karahalis [:openjck]]

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.

Comment 18

[John Karahalis [:openjck]]

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

Congratulations, everyone!