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
- The user will probably click or tap into the search bar to focus it, so let’s also make a state for that, called
- We’ll make another state for when the user entering a search string, called
- Last, we’ll add a
Resultsstate for when the search results have been delivered.
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
- 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
- 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
- Once the search is submitted, the interface will transition to the results state. We’ll call that event
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
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: