13 April 2018 / 3 minute read

Simple Search Bar

Design a simple search bar using states and events. To make things less abstract, we'll add a simple prototype to visualize the different states of the UI.

To think about how our search bar will work, let’s start by brainstorming a few states:

  • To start, let’s make a top level state called Search Bar. Think of this as a named container for the statechart we’re about to build.
  • Next, we’ll add the starting state, where the search bar is visible to the user, but not currently in use. We’ll call this state Inactive.
  • The user will probably click or tap into the search bar to focus it, so let’s also make a state for that, called Active.
  • We’ll make another state for when the user entering a search string, called Text Entry.
  • Last, we’ll add a Results state for when the search results have been delivered.

Creating transitions

Next, we’ll need transitions to move between these states. Transitions are triggered by events, like user input (clicking on a button) or messages from other parts of the program (“no search results were found”).

  • We know that when the user clicks or taps on the search bar, we should transition from the inactive state to the active state. We’ll call that event focused.
  • The inverse should also be true, if the user cancels the search, or clicks/taps something else in the app, we should switch the search bar back to its inactive state. We’ll call that event canceled.
  • When the user starts entering a search string, we’ll want to transition the UI to the actively typing state. We’ll call that event typed.
  • Once the search is submitted, the interface will transition to the results state. We’ll call that event submitted.

The updated sketch with transitions added is below. Trying clicking on the underlined event names in the diagram to trigger the transitions and move the search bar model between its different states:

Refining the model

You may notice that we’re repeating a lot of events across different states. One way to fix this is by making the Text Entry and Results states children of the active state. This is more logical: the search bar is active when it’s in any of these states.

We’ll need to set one of the states inside of the active state as the starting one. It doesn’t make sense to start at Text Entry or Results, so we’ll make a new state called Empty.

Adding a prototype

We’ve got a basic model of our search interface, but it’s pretty abstract—it can be hard to see what states or edge cases might be missing. Roughly visualizing how the UI actually looks in each state can help, so let’s add a prototype to the Statepen.

Below you can see a 4-up view: the statechart spec and diagram on the left, with the prototype code and preview on the right. When you click on an underlined event in the diagram, the prototype UI will change to reflect the new state.

Taking things further

Now that we’ve got the prototype in place, it’s easy to see a few places where the model could continue to be refined.

It’s not possible for the user to submit a search if they haven’t typed anything into the search bar. This is because there’s no direct transition to the Results state from the Active state. This might be the intended behavior, but perhaps we want to introduce an error to the user that instructs them to enter a string. That could be another state.

Searches aren’t usually instantaneous, so we might also want to add a loading state. This state could accommodate an animation for visual feedback and prevent the user from initiating any more events.

Try making those changes by forking this search bar pen.

This is where Sketch.systems really shines. It’s cheap to make changes, so it’s easy to think through behavior, experiment, and refine.

You can also check out these other examples:

Or, if you want to dive deeper: