Reading/Web/Desktop Improvements/Features/Search/en

We want for all editors on our projects to have the ability to find the articles they are looking for quickly and efficiently. Our search capabilities are vital to this, yet our current search experience has a few issues and areas for improvement. First, the search is in a non-standard place on the page, making it difficult to find to a user with no previous experience with our sites and easily forgotten for users that do already know it's location. Second, while searching, it can take a significant amount of time to find the correct results as we currently do not offer any context on the search results displayed.

Our goal is to improve our search experience in ways that make it easier to find and quicker to use. In particular we want to


 * Make our search easier to find by moving it to a more prominent location
 * Make our search easier to use by including images and other contextual information for improved scannability of the search results

Release plan
We began deploying the first iteration of these changes, moving the search bar to its new location, September 2020 to Office Wiki and Test Wiki, followed by our early adopter wikis. We will deploy the second iteration of the new search experience (built in vue.js) in November 2020. This iteration will add images and content descriptions where applicable to the search results. See our main Features page for more details.

Feature description and requirements

 * The search bar will be moved to a new location in the header of the page.
 * The search bar will include an image for the page (if available) as well as a description for the page (if available). Page descriptions will be either local descriptions or wikidata descriptions, depending on the policy of the individual wiki.

Goals
A user test was performed using usertesting.com which focused on the following:


 * Indentifying any major usability issues that we may have overlooked
 * Learning more about search behavior by identifying the breakdown in terms of how people submit their search:
 * (a) click on a suggested result
 * (b) press `enter` on their keyboard
 * (c) click the `Search` button
 * To see what people think the “Search” button will do
 * To see what people think the “Search pages containing X” will do

Study
On usertesting.com we had people do various tasks, some of which required them to search for various articles (without explicitly telling them to use the search box). There were two groups:

Group 1


 * 17 people
 * People in group 1 searched for //Egypt//, //Cave art//, //Banana//, and //Purple//

Group 2


 * 15 people
 * People in group 2 searched for //Electricity//, //Banana//, //Willow trees//, //Romeo and Juliet//, and //Purple//

There was a mix of ages and geographies in both groups:

Findings

 * 0 people had issues using search
 * There were a total of 117 searches submitted:
 * 86 were submitted via a suggested result
 * 19 were submitted via the `enter` key
 * 12 were submitted via the `Search` button
 * Regarding what people thought clicking the `Search` button would do:
 * 16 of 23 people who answered thought it would take them to the first result
 * 7 of 23 people who answered thought it would take them to a list of results
 * note: all people assumed that `enter` and the `Search` button do the same thing
 * Regarding what people thought clicking the `Search for pages containing Purple` would do:
 * 25 of the 25 people who answered thought it would take them to a list of pages that have the word "purple" in them

Notes:


 * in the first study people started on the Pancake article and were then asked to go to the article about Egypt. It was ambiguous how they were supposed to get there. 7 out of 10 people tried to find an "Egypt" link within the Pancake article
 * one person wondered why the Cave art search result didn't have an image — made me wonder if the articles that don't have images look lower quality next to the ones that do?
 * in two cases the search results loaded quite slowly and the people used the `Search` button
 * few people used their keyboard to navigate down to suggested search results (maybe 2 or 3)

Quantitative testing
Two A/B tests will be performed on the early adopter wikis:


 * A comparison of the old location of the search bar vs the new location of the search bar
 * A comparison of the old search widget vs the new search widget

We will be tracking the following metrics:


 * Search Sessions initiated
 * Search Sessions completed

Our target is a 2.5% increase for each change for an overall 5% increase in search sessions initiated

Limitations
There is a current bug with the new implementation of search. If you start a search then resize your browser, the search results stay open but do not move with the search. It is only when you run another search that the results reposition. We will be fixing this upon the introduction of the new search widget.