Move search filters above input so not hidden behind autocomplete.

[iandunn]

Fixes #57
Intersects with #75

1. On trunk, type action into the search on /reference, notice that it covers the filter checkboxes
2. Switch to this branch, build CSS
3. Repeat first step to see it's no longer covered

This can wait until #75 is merged, and then be rebased.

[iandunn]

This has been rebased now that #75 has merged.

[StevenDufresne]

Nice. This works really well on the search results page. 👍

On the /reference page, I find it a bit distracting, almost as if I am supposed to interact with it even though ideally, users don't have to.

I wonder if we should consider hiding it there (/reference)? I would expect the filters only to be used when the search fails to surface the more applicable results which would become apparent after making the first search and then landing on the search results page. I don't have any data to support that suggestion though. Users may use the filters immediately... #109 may help with this flow since result types are more visible now.

Note: find my own idea painful since I spent time styling it in #75. :)

Thoughts?

[iandunn]

On the /reference page, I find it a bit distracting

Yeah, I can see that. I think it could be designed to look more like a secondary thing than a primary one. One way could be to move the filters back down below, but have them positioned absolutely so they're not covered by the autocomplete results. Or maybe have them on the left/right instead of top/bottom?

I would expect the filters only to be used when the search fails

Personally, I just assume that an unfiltered query is going to return too many results, even with more powerful engines like Google. it feels like more work to me to have to sift through them, and then to search a 2nd time w/ filtered results. I usually know upfront what type I'm looking for.

That's probably personal preference, though, and I also don't have any data about how common either approach is

[StevenDufresne]

I looked through some GA data to inform this chat and unfortunately, we don't have event logging on the filters. The only relevant piece is that few users enter a keyword, select a filter, and press enter (keyword/filter order not important). Most users do end up on a specific page after the \reference, suggesting they do find what they are looking for. I would expect them to end up on the search result page if the autocomplete functionality fails because they would be forced to press enter. Additionally, the bounce rate is proportionally low for /reference meaning that they are not failing outright.

Note: We don't know how many attempts the user takes to find the specific page though or whether they eventually add a filter.

Another interesting piece is that a large proportion of users click on the [filters] navigation link (which was removed in #75), get to the filter list, then return back to the reference home page (presumably to search from there). This does suggest that users are intending to find a specific page, which is more often than not a function (2. hook) and they recognize that working through the numerous pages is not the best approach.

If we were trying hard to remove these filters, we could probably argue that functions/hooks could be given more weight and/or clearer types in the autocomplete (you mention that in #120) and that may be all that is needed.