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.