1100690 - Discussion: Updates and questions regarding new search UI

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Search, enhancement)

Description

[Holly Habstritt Gaal [:Habber]]

The following is a first pass at feedback and questions regarding the Command & Query search UI on MDN. It is currently behind a flag, but I'd like to show it to the community asap for feedback. First, let's resolve a few of the quick, high-level, design tweaks and answer a couple of questions regarding how search works when taking the new filter/query UI into account. 


Everything is working pretty well. Even the auto-suggest for the commands (http://cl.ly/image/3y1E452n052v). The styles are looking pretty good too. My feedback regarding the UI is mostly minor, but I want to be sure users understand how their search results are connected to the choices they make when altering their command(s) or query terms.


Below are a few points of style feedback and questions about search functionality. Once we can clean a couple things up, then we can release to some more people to test it out and offer feedback. I think Jannis can answer most of the questions I have about how search performs.



Search field + C&Q menu style:
- The field contents wrap too soon. For instance, there is plenty of room for another command/query, but it wraps. http://cl.ly/image/353W3U3r1y33

- Add a few pixels of padding above the titles 'TOPICS' and 'SKILL LEVEL' in the dd menu. That will help visually group the sections better. Right now the titles run into the items above them.

- I forgot to take a screenshot of the welcome message that displays below the search field. Now I dismissed it and can't remember what it looked like and said. I don't remember wanting to change anything... just could use another look if it's easy to grab.

- I'm trying to put myself in the shoes of somebody using this for the first time. Despite the dismissible welcome description about the new search UI, does the menu need a short message at the top of it as well? I prefer no message and to keep things minimal, but what do you think? I'd be open to possibly adding a persistent "Add one or more filters to your search for better results." message to the dd menu.

- I think we should have a hover state for the filter rectangle in the field http://cl.ly/image/0y1T2p2V1x03  What do you think? I was thinking either A) turn the whole rectangle darker grey on hover or B) Just change the 'x' to a different color, like the MDN light blue.


Search results:
- How do the the search results differ for a predefined '#fxos' command versus my free query 'fxos'... just curious if it's redundant if they are in the same search or if they reveal different results. http://cl.ly/image/2z3G1e0O3S0u ?

- The text in the box giving the user details about their search results could be more readable. http://cl.ly/image/0T0A3f2a1D3k How about this:
--- line 1: Regular font (not italics) "xxxx documents found for "xxxx" in English. Showing results 1 to x." [line break]
--- line 2: Italicized font "Search index: 2014-10-14-07-40-34 (created: 2014-10-14 07:40:34) "

Comment 1

[Holly Habstritt Gaal [:Habber]]

Here's an old blog post about the thinking behind this if anyone needs a refresh http://hollyhabstritt.com/blog/2013/11/5/command-query-a-better-filter-and-search-for-developers-on-mdn

Whenever this project is revived, I'm ready to help! I have the wireframes and can make any edits to .psds if necessary, but I think that from this point on, we can make any updates directly in code.

Comment 2

[Jannis Leidel [:jezdez]]

Rob and I have started to collect TODOs in https://etherpad.mozilla.org/search-suggestion-fixes as part of the MDN hack weekend in Berlin.

Comment 3

[Rob Hudson [:robhudson]]

(In reply to Holly Habstritt Gaal [:Habber] from comment #0)
> Search field + C&Q menu style:
> - The field contents wrap too soon. For instance, there is plenty of room
> for another command/query, but it wraps. http://cl.ly/image/353W3U3r1y33

FWIW, this doesn't happen on the current homepage, but does on the search page.

> - I forgot to take a screenshot of the welcome message that displays below
> the search field. Now I dismissed it and can't remember what it looked like
> and said. I don't remember wanting to change anything... just could use
> another look if it's easy to grab.

From the code:
"<h2>Welcome to the new way to search MDN!</h2><p>Search as usual, or filter your search by clicking in the arrow (<i class='icon-caret-down' aria-hidden='true'></i>) to show the filters menu.</p><p>Filtering also works by typing shortcuts into the search field (shortcut examples #int, #JS, #CSS).</p>"

> - I'm trying to put myself in the shoes of somebody using this for the first
> time. Despite the dismissible welcome description about the new search UI,
> does the menu need a short message at the top of it as well? I prefer no
> message and to keep things minimal, but what do you think? I'd be open to
> possibly adding a persistent "Add one or more filters to your search for
> better results." message to the dd menu.

What would this look like? I'm assuming the "dd menu" is the thing that drops down when you click the triangle, in which case I agree that a short helper message would be nice.

> Search results:
> - How do the the search results differ for a predefined '#fxos' command
> versus my free query 'fxos'... just curious if it's redundant if they are in
> the same search or if they reveal different results.
> http://cl.ly/image/2z3G1e0O3S0u ?

The "#fxos" will cause the backend search to select the "fxos" facet which filters the results by this topic.

> - The text in the box giving the user details about their search results
> could be more readable. http://cl.ly/image/0T0A3f2a1D3k How about this:
> --- line 1: Regular font (not italics) "xxxx documents found for "xxxx" in
> English. Showing results 1 to x." [line break]
> --- line 2: Italicized font "Search index: 2014-10-14-07-40-34 (created:
> 2014-10-14 07:40:34) "

I believe the 2nd line there is only there b/c your user has certain permissions to see more info about the search (which index it is coming from). Not all users see this. But all the same, I think this is useful for those who also have this. But if it changes your UI suggestion please share.

Comment 4

[MDN Team (:mdn-dev)]

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

https://github.com/mozilla/kuma/commit/9c11bd6a3212778fb5ea9d68398f963e8ef885b4
Bug 1100690: Improve the homepage search filter

This commit makes several improvements to the homepage search filter.
Most importantly, the front-end code is refactored so that the search
form will continue to work when JavaScript is disabled. Style
improvements are also made.

https://github.com/mozilla/kuma/commit/c15e0acc9852ea669e8f2c4fccb368cc00648761
Bug 1100690: Don't disable the homepage search box

https://github.com/mozilla/kuma/commit/be4f6667e76923c958f3849905c491f968a7ced3
Bug 1100690: Display bug fixes

- Increased minimum size for empty input to accommodate placeholders that are longer in other languages
- remove left and right filter arrow for when lots of filters are enabled
- added split to multiple lines for when lots of filters are enabled or the search query is long
- fixed RTL display bugs

https://github.com/mozilla/kuma/commit/4da2678c8ca311a344475bfe26f4bb8b6d6a8ec7
Bug 1100690: Fallback text for button

https://github.com/mozilla/kuma/commit/d209924d9c6d2ed54fb465866ddb62bfb337b895
Bug 1100690: Add l10n to filter serializer

Comment 5

[Stephanie Hobson [:shobson]]

Revisions to the filter have been pushed to production. What is the next step with this?

Comment 6

[Holly Habstritt Gaal [:Habber]]

(In reply to Stephanie Hobson [:shobson] from comment #5)
> Revisions to the filter have been pushed to production. What is the next
> step with this?

Hi Stephanie, 
Are these revisions currently behind a waffle flag?

IIRC we discussed being able to see the new search by accessing a specific URL. (developers.mozilla.org would still see standard search) Then I would run a usertesting.com test to watch a sample of users try it out. 

We would also like to get feedback on this search from current MDN users. We could do this in the following way, but I'm open to other options too: If the search is temporarily accessed with a specific URL, we can send out this URL to an MDN mailing list with a link to a survey that I would create to gather feedback.

Comment 7

[Rob Hudson [:robhudson]]

For URL testing what we have to do is the following:

1. Enable "testing mode" for this waffle flag. This can be done in the admin for this waffle, which I believe is named "search_suggestions".
2. Send users to any URL on the site with ?dwft_search_suggestions=1 in the query parameters. This will activate the waffle flag for this user and set a cookie for all subsequent requests.

Comment 8

[John Karahalis [:openjck]]

Homepage without search suggestion feature:
https://developer.mozilla.org/

Homepage *with* search suggestion feature:
https://developer.mozilla.org?dwft_search_suggestions=1

Bucketing doesn't appear to be working in our instance of django-waffle (I also noticed this in other tests), so as soon as the ?dwft... query string disappears the search suggestion feature will also disappear. In other words, the query string needs to present every time we want someone to see the search suggestion feature.

Comment 9

[Rob Hudson [:robhudson]]

(In reply to John Karahalis [:openjck] from comment #8)
> Bucketing doesn't appear to be working in our instance of django-waffle (I
> also noticed this in other tests), so as soon as the ?dwft... query string
> disappears the search suggestion feature will also disappear. In other
> words, the query string needs to present every time we want someone to see
> the search suggestion feature.

This can be fixed by adding 'waffle.middleware.WaffleMiddleware' to the `MIDDLEWARE_CLASSES` in settings, I believe. This is part of the install docs but it's not there in the kuma settings.

Comment 10

[John Karahalis [:openjck]]

I'll submit a pull request to fix that. As a result, it would be safest to use these URLs instead. Both URLs set the state of the flag explicitly, so that users can try both alternatives without Waffle silently bucketing them in one or the other.

Homepage without search suggestion feature:
https://developer.mozilla.org?dwft_search_suggestions=0

Homepage *with* search suggestion feature:
https://developer.mozilla.org?dwft_search_suggestions=1

Comment 11

[Holly Habstritt Gaal [:Habber]]

(In reply to John Karahalis [:openjck] from comment #10)
> I'll submit a pull request to fix that. As a result, it would be safest to
> use these URLs instead. Both URLs set the state of the flag explicitly, so
> that users can try both alternatives without Waffle silently bucketing them
> in one or the other.
> 
> Homepage without search suggestion feature:
> https://developer.mozilla.org?dwft_search_suggestions=0
> 
> Homepage *with* search suggestion feature:
> https://developer.mozilla.org?dwft_search_suggestions=1

Thanks, John, Stephanie, and Rob! 

So our next step is to do 2 things to gather feedback:
1) share the URLs via MDN mailing list with an accompanying survey to gather feedback
2) distribute to usertesting.com participants for further qualitative feedback

I'm at a work week in Toronto next week, but should get time to write up a quick survey and a script for usertesting.com. Only the user research leads (Bill and Gemma) have permissions to hit go on my usertesting.com tests, but are in Taiwan right now. I will need to wait for them to return before I can do the user testing. 

I'll write up the survey and script in Google docs so that you and Rob (and anyone else) can check it out before I start the tests and share the survey.

Which MDN mailing list would be best to invite people to try it out and give us feedback via the survey?

Comment 12

[John Karahalis [:openjck]]

Thanks, Holly! I think mdn@ would be the best list. It includes engineering contributors, writing contributors, product minds, and other users.

Comment 13

[MDN Team (:mdn-dev)]

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

https://github.com/mozilla/kuma/commit/933dea2dfe156f041242c270139fc29d4b696733
Bug 1100690: Let django-waffle bucket users

When using percent-activated flags, django-waffle is supposed to
permanently group a user into one variation or another. Before this
change, this was not happening. The probability of a flag being active
was re-determined on every page load.

This change adds the django-waffle middleware to our stack. This gives
django-waffle the opportunity to set a cookie and, in turn, use
percent-activated flags as intended.

https://github.com/mozilla/kuma/commit/240612d123fd9b145e6e4361fda326b3e60bec55
Merge pull request #3209 from openjck/bug-1100690-waffle-middleware

Bug 1100690: Let django-waffle bucket users

Comment 14

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.