Improving the search bar UX

[MaggieAppleton]

Our current search experience has a number of UX issues that make it difficult for learners to find content relevant to their needs and interests. We receive fairly regular feedback from learners that they struggle to browse through content on the site and find what they're looking for.

Below I've identified a set of problems and potential design solutions for us to consider.

1. Learners may not know we have filtering features; menu is initially hidden and disappears after each use

We have a very useful and powerful filter menu that learners can use to find relevant content on the site. Sadly, many learners don't use it to find relevant content. This is partially due to the fact we hide the filter menu by default.

Standard view with a search term (filters closed):

If we look at our mixpanel data, we can see out of all searches only 10% of learners make use of search filters:

It's possible learners simply don't need filtering to find what they're looking for.
However, we've gotten feedback from learners that indicate they don't know the filtering functions exist.
Relevant feedback from learners:

• "it'd be lovely if there was a way to filter courses that are free"
• "It's hard the experience to look for courses, ie free courses or "hot" courses"
• "The complete lack of sorting/filtering ability on almost every page makes it feel impossible to find anything."
• "I went looking for something to help me do fast complex webgl in react. But searching is a nightmare"

The simple solution here is to have the filter menu open by default when a learner uses the search bar. The learner can choose to close the filter menu if they feel it's getting in the way, but they at least know that it exists.

A related issue is that the filter menu open/close state doesn't persist. Every time a learner selects a tag in the menu, the menu disappears. This makes it difficult to quickly select multiple filters since the controls are removed the instant you try to select them.
The learner should be in control of the open/close state of the menu. It shouldn't automatically close without them choosing to close it.

Current behaviour:

There's a larger issue at play here

Our topic tags are used as the main navigational tool for users to find curated topic pages. Selecting the "react" tag takes you to the curated React page. There's no way learners would know this, but if we're going to continue using topic tags in this manner it's essential we make them clearly visible and accessible whenever a learner performs a search. This will train learners to use topic tags as a navigational feature when they're browsing the site. I expand on this issue in the next section...

---

2. Learners don't see curated topic and instructor pages in search results due to topic tag + search term confusion

We are putting a significant amount of effort into gardening pages for our most popular topics and instructors. Unfortunately, users are unlikely to find these pages because they don't appear in our search results.

If I search for "react", I'm taken to https://egghead.io/q?q=react and I see this:

While this shows me a list of react-related courses, it fails to take me to the curated React topic page (https://egghead.io/q/react) which would be far more helpful and relevant.

This is because to get to that page I need to set react as a topic tag in our (hidden) filters section and make sure I don't have any text entered in the search bar:

Users have no way of knowing this. The interplay between search terms and topic tags is confusing. The fact you need to select a tag while removing any search terms is a strange combination of states.

The fact we have both https://egghead.io/q?q=react (search for the term "react") and https://egghead.io/q/react (empty search with the react filter on) as possible pages on the site feels like a significant IA issue.
It is also possible to go to https://egghead.io/q/react?q=react (a search for the term "react" with the react filter on), which shows the same list of results as the search term "react".

Redirecting https://egghead.io/q?q=react to https://egghead.io/q/react might be a possible solution.
Anytime a user types a search term that exactly matches an existing tag (react, CSS, etc.), we could apply that tag in the search filters which should automatically redirect them to the relevant curated page
IANA URL expert though so open to more experienced perspectives on how to handle this.

What I want to see when I type "react" into the search bar:

⭐️ However, it would be even better if I saw this:

Typing "react", landing on the most relevant page, and having the search filters open is a triple win:

1. I got where I wanted to go
2. I understand I am here because the "react" topic in the filter menu is selected
3. I now know I can use this filter menu to select other topic tags, in turn taking me to a whole bunch of curated landing pages

---

3. No explicit search button

We used to have a visible "search" button to execute a search, but I lobbied for its removal in a previous round of design work (#637). I was wrong 🙇‍♀️

The previous rationale for removing the search button was that we had numerous bright blue buttons in our navbar that all looked equally important: "browse', "search," and our main CTA.

Previous navbar:

In order to make the main CTA stand out more, we made "browse" into a secondary style button and removed the explicit "search" button. Users would then execute a search by pressing return on the keyboard.

A learner wrote in pointing out that they were unable to search while using egghead on a television display that only allowed mouse controls. We then added the ability to perform a search by clicking the microscope icon to the left of the search query.

This is still slightly out of line with industry conventions. Many other websites use the search icon as a "search" button but place it on the right hand side of the search box:

Twitch:

YouTube:

To make our search bar more accessible and standardised, we should turn the search icon into a square button and align it to the right of the bar:

[joelhooks]

[*the only time this thread will notify the org is when it’s posted or a reply occurs so editing won’t announce when the disclaimer is removed. i’d probably recommend keeping it stashed someplace if no input/background is desired versus restricting discussions here.*] the “react” (or any term that exactly matches a tag) thing worked at one point so this is actually a regression/bug imo as it’s not working as intended/designed. probably a separate concern? doesn’t really need a pitch. somebody should just fix it! i think the filters should be with the results (under the curated stuff) and exposed. similar to app.egghead.io/search would also be great to see a “sort” option that included date. both of these are changes i’ve almost done a few times but never squeezed them in.

[MaggieAppleton]

Was planning on posting to slack + roam once the WIP label was removed. Github notifications are so numerous I don't presume anyone sees them. Github's lack of drafts/autosave makes it hard to work on longer posts without losing work in the middle of writing. Can write it up outside this context, but adding in images, GIFs, links to relevant discussions/PRs is easier in native context.

Have sort by date + show search result count on a list of future/possible improvements once we get these fixed up.

Re: "doesn’t really need a pitch. somebody should just fix it!"
I certainly didn't understand the problem before I wrote this up, and given how long it's been working incorrectly, I doubt many other folks on the team are aware of it. Can't fix problems if you don't know they exist. I think any major fixes or design changes to the site are worth documenting and explaining clearly so we're all on the same page. Which is what a pitch is IMHO. Also will help us coordinate and assign someone to fix it.

[joelhooks]

Sounds good. Loading topics based on search term is fixed here: #764 This doesn't explicitly apply a search facet (filter) because imo that's heavy handed and not what the user has asked for by typing a term in a search bar, but it does see if a single typed query matches an existing tag and displays that tag's page accordingly. Search facets could be specifically applied, but it would add more complexity to both the implementation and the final required user behavior by filtering results to a more specific set and require understanding of the system to undo if it wasn't what the user was trying to achieve. They would need to take action in the UI to get the unconstrained results.

…

--- _This is a meta conversation, but I want to add some additional thoughts because a collaborative environment is important to me._ I monitor Github notifications and use email to respond and act on them accordingly. That isn't to say we should presume that github notifications are excellent and serve as an effective singular notification stream (they are bad and don't). Important stuff should definitely be broadcast across channels and often with specific @ mentions for interested parties where appropriate. That said, I'm not a fan of suppressing discussion/input in this (or any) venue and would prefer an environment where we can all feel free and safe to interact and collaborate on this work. This specifically feels like this is an example of where original implementor and subject matter expert has relevant details that are useful and will save time/effort. It's hard for me to understand why that input would specifically and explicitly be undesirable in a collaborative space, not just because the implementor and SME is me (I put a lot of research and effort into this functionality), but if it was any of the other folks we collaborate with (or even the public at large since this venue is widely accessible.) For me, the ease of use of the author is less a factor than an inclusive and collaborative work environment where possible. Hope that makes sense, more than happy to continue the discussion elsewhere and not derail this any more than I already have

[MaggieAppleton]

Good point that auto-applying the filter is not the best solution and would cause confusion.
Sounds right to say if a "search term" === "topic name" we show them the topic page, but we don't apply the filter.

This might be related to the overall tag/query issues; there's some strange behaviour happening where the search bar applies any term you type in as a tag. Eg. here if I search for "banana", it applies a "banana" tag to whatever I search for next 🍌

---

Also found a related issue where filtered search results are invisible on curated pages.

If I we search for a term (eg. "css"), the CSS tag is auto-applied and we're taken to the curated page.
If I then try to search for "javascript" instead, it seems like nothing happens.
The search results have updated to show javascript + css related content, but they're out of sight on the page, so we get no feedback that our search has happened. We also might not be aware the css filter is on at this point.

Nixing auto-applied filters should solve this. We should also only show the curated pages on a pure search for a topic (eg. either the css filter is on, or the exact term "css" has been entered into the bar, or both of those states are true).
If someone has the CSS filter on, then types javascript, the curated material should disappear and the search results should show up directly below the search bar.

The whole UX here is making me think separating the search bar from the results is overall problematic.
I know I lobbied for it to be higher on the page earlier on, but I'm now thinking putting it back below the curated content would make more sense. If we leave the search bar in the navbar on every page, and also move the main search bar lower on curtaed pages to be directly above the search results, that would improve the situation. Easy access in multiple places, and keeps search results in close proximity to the search bar.

[MaggieAppleton]

I'm going to peel off issue 1 (filter menu is hidden) and issue 2 (no explicit search button) into separate scoped issues since those feel like well-understood things we know how to fix.

Issue 2 on tags/search queries and the layout of curated content is meaty. I'll do a bit more research and written thinking in Roam to make sure we're catching all the issues at play here.

[joelhooks]

related: quickly moved the filters to sidebar since it was "quick and easy" and the preview is a better starting point imo

#779