Naver Search Bar UX: Analysis and Implementation Guide

Intro

Today, we will analyze the UX of search bar components from a developer's perspective. With the knowledge from this post, anyone should be able to create a search bar component.

I tried typing directly into the search bar on Naver.

 

As you can see, when you search, it displays matching search results below. The list that appears at the bottom is limited to 10 items. It's also characteristic that the matching letters in the search are highlighted in blue.

The search bar has the following UX:

  1. 1

    Typing shows a list of search results at the bottom.

  1. 2

    The matching part of the search word is highlighted.

  1. 3

    The search result window has no scroll and is limited in number.

Let's analyze in more detail.

The UX of the search bar can be divided into 5 actions:

  1. 1

    Displaying the search results window

  1. 2

    Turning off the search results window

  1. 3

    Selecting a search result

  1. 4

    Searching

  1. 5

    Refreshing the search result list

Understanding when these 5 actions occur will give us a detailed insight into the UX of the search bar.

When does the search results window appear? It seems obvious that it would appear when you click on the search bar or start typing. Are there any other triggers?

1. When Typing Begins

The search results are provided as soon as the user starts inputting.

If there's a search term and the search results are turned off, clicking on the search bar with the mouse will turn it back on.

3. When Pressing the Down Arrow Key on the Keyboard

If there's a search term and the search results are turned off, pressing the down arrow key on the keyboard will turn it back on.

Surprisingly, the search results do not turn on when the search bar gains focus.

Then, when does the search results window turn off? There are several moments when this can happen:

As you can see, when all content of the search term disappears, the search results window turns off.

If the search results are on, clicking on the search bar will turn it off.

3. When Clicking Outside with the Mouse

Clicking on anything outside of the search results and the search bar will turn it off.

4. When Pressing the Enter Key

Performing a search will also turn off the search window (though technically, it closes as the page navigates).

Similar to pressing Enter, clicking on a search result item will perform the search and close the search window.

6. When Pressing the Up Arrow Key

Under two conditions: if the search results are on and no search result is selected or the first search result is selected, pressing the up arrow key will turn it off.

7. When Pressing the Esc Key

Pressing Esc deletes the search term and for the same reason as number 1, turns off the search results.

8. When Pressing Shift + Tab

If the first search result item is selected and Shift + Tab is pressed, the search results turn off (but if no item is selected, the focus simply moves without turning off the results).

Interestingly, simply losing focus does not turn off the search results.

Users can select search results using keyboard actions.


Although not clearly visible on the screen, the selected search result is highlighted with a light grey background.

Selecting a search result changes the content of the search bar as well. Now, let's see how users can select a search result.

1. When Pressing the Down Arrow Key

  • If no item is selected, the first item will be selected.

  • If a previous item was selected, the next item will be selected.

  • If the last item is reached, it will cycle back to the first item.

2. When Pressing the Up Arrow Key

  • If a previous item was selected and it's not the first item, the item above it will be selected.

  • If no previous item was selected or the first item was selected, the search results window will turn off.

3. When Pressing the Tab Key

  • If no item is selected, the first item will be selected.

  • If a previous item was selected, the next item will be selected.

  • Once the last item is reached, the search icon gains focus.

4. When Pressing Shift + Tab

  • If a previous item was selected and it's not the first item, the item above it will be selected.

  • Otherwise, the search results turn off or focus moves elsewhere.

There's a subtle difference between using the Tab key and the down arrow key. When navigating with the Tab key, it feels as though the focus moves to the search result items, but in reality, the focus does not move. The fact that the caret remains visible in the search bar is a giveaway. The moment when the focus truly moves is observable when the search icon gains focus after pressing Tab.

5. Other Actions

  • Each time a search item is selected, the caret in the search bar moves to the end of the word.

  • If the search results window is turned off and then back on, the previously selected search item is reset.

Searching

Searching involves using the search term to fetch data on the page. In Naver's case, the search results window closes and the focus is lost as the page navigates.

1. When Pressing Enter

Pressing Enter executes the search.

Clicking with the mouse executes the search.

Clicking on the search icon executes the search.

When does the search results list refresh? It seems it's not just when the search term changes because the list doesn't refresh when a search item is selected, which also changes the search term.

1. When the User Starts Inputting

The search results refresh as soon as the user begins inputting.

If the user changes the search term with the keyboard, turns off the search results, and then clicks on the search bar to turn it back on, the list refreshes with the updated search term.

Let's Implement It Ourselves

Following the analysis of the functionalities, I attempted to implement the code. As seen, pressing the up arrow key resulted in different outcomes depending on the condition. I thought it might be more readable to write the code focused on functionalities rather than trigger events.

Event-Triggered Approach

Html
<script> const handleKeyDown = (e: KeyboardEvent) => { if(no selected item and up arrow key pressed) { turnOffSearchBar() return } if(selected item exists and up arrow key pressed) { selectPreviousItem() return } ... } const handleClickInput = () => { if(search bar is on) { turn it off return } if(search bar is off) { refreshSearchResults() turn it on return } } </script> <input on:keydown={handleKeyDown} on:click={handleClickInput} />

Improved: Functionality-Centric Code

Typescript
const openMenuHandlers = { handleInputChange() { turn it on }, handlePressArrowDown(e) { if(off and down arrow key pressed) { turn it on } } ... } const closeMenuHandlers = { handlePressArrowup(e) { if(on and no selected item) { turn it off } } ... } const handleKeyDown = (e) => { const listeners = [ openMenuHandlers.handlePressArrowDown, closeMenuHandlers.handlePressArrowUp, ... ] listenres.forEach(callback => callback(e)) } ... <input on:keydown={handleKeyDown} ... />

In handleKeyDown, what was previously handled with branching is now managed through listeners. This approach allows for writing code that's centered around functionalities, making it easier to address problems or add UX flows later on.

Using listeners.forEach instead of listeners.some and having the handler return a boolean could provide even more flexibility.

Concluding Thoughts

In this post, we explored the UX of search bars. As observed, Naver's search bar contains a multitude of triggers. The search bar component implemented based on our functional analysis concludes this discussion.