February 26, 2018

Building front doors into search experiences

Search ingress

“If opportunity doesn’t knock, build a door.”

1. in·gress
   noun \ˈinˌgres\
   1  :  the action or fact of going in or entering.
   

After collaborating with a few teams of developers on QF and Header projects, we became more comfortable bouncing random ideas off one another. These hallway conversations and midday office bumrushes produced a few interesting side projects. Some shipped while others would help inform other workstreams. As everything in the studio needs a name, I ended up referring to these side hustles as “Search ingress.” Though the team’s primary focus was enabling and enhancing entry points, this category of work was a bit more focused on accessibility and keeping up the momentum of re-queries.

On this page, I’m sharing two projects that came out of this collaboration: Quick actions and the Sidekick app for Android.

1. Quick Actions

The first one was a mobile affordance to get back to the search box once you scroll down past the header (and the search box is out of the canvas). Material Design calls this thing the Floating Action Button (F.A.B.)—we called it “Quick actions.”

It’s worth noting that we could have solved this issue in a number of ways. For example, a sticky header would have worked but that model seemed a bit heavy-handed and took up a considerable more amount of vertical space.

We also had some other secondary issues lingering, like making it easier for people to log in, change their settings, click on Related searches, as well as having a plan for multi-modal input selection. So, I sketched out a few interaction models—from mild to wild, as they say.

A. Single-action model

1. Scroll to the top of the page, then open QF. Could be frustrating on accidental tap.
2. Open QF, maintain context.

This one was the quickest one to build, test, and deploy as well as the most incremental change with the simplest interaction.

B. Menu (Simple) model

1. Like most menus, there should be a semantic grouping: Inputs (camera, mic, keyboard), Account management (login, saves, and history).
2. Tension/confusion with the existing hamburger menu.
3. Confusion with 2 inputs, 1 account button, and 1 submit button in the same array.
4. With or without action labels? Spacing issues vs. understanding each button.
5. Awkward integration of Related searches card with Quick actions array of buttons.

This model was flawed due to the lack of a semantic organization, lending itself to a somewhat random collection of links that look and behave differently. It reminded me of a poorly architected hamburger menu…or that unruly kitchen drawer in everyone’s kitchen.

C. Menu (System) model

1. Semantic grouping (Input, Account, Related searches).

2. Flexible system: build Input card first, then Related searches, Account.

3. Possible to get rid of menu (hamburger) and use this exclusively.

I lobbied for this model. I was interested in taking some of the weight off the Header’s menu controls, making them more accessible both in terms of speed and proximity to your thumb while holding the phone. However, there was apprehension regarding the novelty as well as perceived complexity.

Mobile Quick Actions, in action

After prototyping these models and weighing the pros and cons, we ended up shipping the Single action model (A.), primarily due to the ease of implementation and minimal product owner disruption. After making this call and deploying for mobile browsers, I wondered why we couldn’t do the same thing for desktop browsers, so I mocked that up and shared it with the group. It was the same user problem, with a lesser degree due to the difference in canvas size and input modalities.

The group didn’t buy it, decided it wasn’t as pronounced a user problem to solve, so we let it ride.

2021 UPDATE

It looks like someone finally warmed up to the idea of executing this concept on desktop browsers as well. Nice!

↓

Quick Actions for Desktop browsers

2. Sidekick app for Android

The team—ahem, Rahul—had an idea for an always-on search experience for Android. The interaction was akin to the Facebook chat heads UI. I put together the interface with much of the learning from Query formulation and the Mobile header re-design projects. Rahul’s team built a functioning prototype and we all had a good time testing it out for a bit. 

It’s worth noting that I was insisting on calling it Bing Up for some reason. I’m really glad Rahul pulled rank and called it Sidekick, heh.

In the end, it didn’t ship but it was supercool how we came together as a small and scrappy team to built something clever in such a small amount of time. If you’re into this sort of thing, check out Microsoft Launcher, which has this functionality and a lot more (including a better name).

* * *

.... .- ...- . .- -. .. -.-. . -.. .- -.--