Preview of the AI assistant in Vercel's search

1. Animations

Let's start with the first thing a user would see. The modal expands and contracts in-place to provide a sense of persistence between the two UI states.

To make this look and feel just right, we're employing two counter-intuitive techniques: isolation and asymmetry.

We isolate the background layer from the foreground content. In other words, the background is really a sibling element to the foreground, instead of containing the foreground elements.

This allows us to animate the background's size and position with a GPU-accelerated transform without stretching the foreground elements. This is why content still looks crisp while smoothly animating from the small text input to the full modal, but it still leaves one problem…

Normally a close animation can just be the open animation played in reverse. if we did that here, the border would get stretched and malformed.

Instead, our close animation only transitions from the input at the top of the modal back down to the original trigger element, so it's a more similar shape and size.

2. Simplicity & ambiguity

The results are shown in the simplest way possible while disambiguating results that would look similar.

For instance, matching the "Deployments" page needs to clarify whether it's for the current team, current project, or a completely different scope.

3. Shift prevention

Because we show some results optimistically and others only after fetching more data, there's a risk that the results could shift as a user goes to select one.

Or rather, there would be, if we didn't implement a system to prevent it.

When we get new results after a delay, we don't just replace the old results directly. we minimize shifts by ensuring that:

• the result that's currently focused will never be removed or change position

• other results that still exist anywhere in the new results do not change position

Other results from the previous set are removed and replaced with the highest ranking new results. This ensures that the best result will always be included somewhere in the output, but a result will never change as a user makes a selection. It also makes it easier for users to parse what's changing as new results come in, because fewer things are changing on screen.

4. Focus

We allow focusing on results via arrow keys or hovering over them with a pointer. We also always focus the first result as the user types.

This seems easy enough until you try to change the focus while the pointer is still hovering over one of the results.

A simple implementation (such as listening for the pointerover event) will cause the focus to keep snapping back to the pointer focus as a user types.

We solve this by only acting upon the pointer event if the pointer moved since the last time the pointerover event was fired.

We still need to track what we would've focused on even if the pointer hasn't moved, though, because as soon as the pointer moves again, it should trigger focus even if it doesn't leave and re-enter the target element.

5. The navigation assistant

Dead ends are the enemy of search

If we can't find what a user is looking for using traditional algorithms, we want to ensure that they still have a way to find what they're looking for. This also allows users to ask more complete, complex questions and still be directed to pages with answers.

For instance, you can ask for pages like deployments, logs, and usage with filters (like date ranges, environments, routes, etc.) applied.

We didn't want this feature to feel like a traditional chat or prompting experience. Instead of responding with words, the navigation assistant responds with actions.

It silently thinks about your query and navigates for you.