Back in 2005 we were two years deep into the Iraqi war, a year removed from Boston’s first World Series championship in 80+ years and smack dab in the middle of the search engine gold rush. Google had made it quite clear that data mining was not only a lucrative venture, but safe as well (no canaries have died to this day during database dredging operations).
The rush was on to either catch up with Google’s progress (see Microsoft’s Bing) or to get out of the innovation game altogether (see Yahoo!). Found between the turf battle of the open web search giants were hundreds of thousands of domains, of wide-ranging sizes and purpose that either developed their own search engines or licensed the best available in the market. From editorial to retail sites, search was quickly becoming the focus of product teams, as the browse culture had evolved into a find culture.
Data vs Proximity
That summer I had flown out to A9—Amazon’s search R&D team—to present ideas about “block view” proximity in the A9 Yellow Pages interface. Technically speaking, it was a UI Designer interview with Udi Manber and my old Billsville pal, DeWitt Clinton, but the more I prepared back in Jersey City for a proximity UI presentation, the more the needs of the users of the domain drew my focus elsewhere. By the time I had left for Palo Alto, I knew I wouldn’t be a serious candidate for the job; I had fashioned a presentation around the value of structured data for retailers in a Yellow Pages experience.
The more I skimmed through a paper Yellow Pages, taking notes on my own scanning and findability patterns, I realized that while proximity of the store or service from my home (and within the context of its own block) was important, it fell squarely in a secondary position when compared to the task of actually finding a store or service that met my specific needs. The notion became more profound when taking a spin with the existing A9 Yellow Pages interface, as the interface had a much greater opportunity for exposing detailed business information at the return level… yet couldn’t.
It became clear to me that while proximity and structured data both play a part in presenting optimal, relevant returns, structured data leads the dance in the vast majority of use cases. The modern day Google search experience expresses this concept in a number of ways, including:
- a query for – [city] movies – returns an elegant display of available movies and showtimes in particular city, presents multiple sources of aggregated reviews, a trailer, synopsis, cast list and online availability
- a query for – [ethnic type] restaurant – returns a display featuring local restaurants that meet the type criteria, presented within the context of proximity from my current location
- a query for – [ethnic] food menu [city] – returns a display featuring the most popular local establishment’s menu as structured data (if managed within the Google My Business environment)
Google understood as early as 2006 that supporting the needs of businesses and their customers through exposing data was a much more complex task than presenting the position of a brick and mortar store within a postal block.
As such, they launched Apps for Your Domain (now Apps for Work) in 2006 as a first attempt to harness the multitude of online needs for businesses. Then came the merger of their Local Business Center, which had allowed for the collection of business-related data, with Places in 2010, creating an even more fluid experience of claiming and enriching representations of business experiences online.
Pages launched in 2011 (recently becoming My Business), which allowed businesses to expose their structured data in particular, making it even more findable by potential customers, clients, partner businesses, etc. via a search query or when represented in the G+ environment. Über competitor in the social, advertising and search space, Facebook, established the gold standard business page (appropriately named, Pages) in a social network in 2007.
Recently, proximity has claimed its own important place in the search game, but outside of mobile use cases, the concept of block proximity hasn’t evolved much since those early days. As I imagined when prepping for that presentation of an explicit Yellow Pages product, finding the data match to a business need comes first, and by a long shot.
Back To The Future
A decade ago was a time before sophisticated social graphs, or the full-fledged plunge into smartphone-driven mobile search opportunities; we were in an age where the potential for interfaces to support multivariate needs in a humane fashion were just becoming understandable, let alone practical. The concept of shipping a UI that explicitly reflected the underlying technology or database rather than the mental model of the user was beginning to wear thin.
The UI takeaway section of the presentation was as such:
- Create value by simplifying familiar tasks
- Subtract, rather than add to the interface
- Tap the human desire for instant gratification
- Empower people by providing meaningful choices
- Craft environments that value human participation
- Only useful technology should be made transparent in the UI
- Move from hierarchical to relational constructs
- Context provides meaning
- Partner with users to adapt to their evolving needs
With an approach to UI design on the table, I walked through the primary tasks of the existing product. The most frustrating aspect of the customer query -> connect with business task centered around the most basic, yet complex element of search recall. A search for:
- “coffee” in “palo alto” – returned 77 results in an interface steeped in proximity elements, such as distance from current location and displayed on a small map
- “coffee” and “donut” in “palo alto” – returned only 2 results… so either 75 of the previous coffee shops don’t have donuts, or the data isn’t being made available at time of query
- “coffee” and “doughnut” in “palo alto” – returned only 1 result, and it wasn’t one of the previous two listings
There’s no kind way to tell a product team—one that has flown you clear across the country to present a vision for their interface—that no matter what we do in the interface, the product defined as such, is going to fail.
The toughest challenge for the Yellow Pages product wasn’t proximity, it was figuring out a way to garner rich collections of business specific metadata for their search to parse and return. My idea was to empower business owners to tag their services, leverage existing user reviews as metadata, essentially, without boiling the ocean, provide structured data for search to leverage. If the business object model is a restaurant, provide a menu interface; if the business object model is a hardware store, provide a connection to tie in the inventory database. Make it impossible for me, the customer who is searching for a specific type of wrench, to miss out on spending money at the Ma & Pa hardware store that I like to support, simply because the name of the store doesn’t have “wrench” in it.
A year later, block view and Yellow Pages were shut down by Amazon. Google and Facebook figured out the path for creating a decentralized, modern day “Yellow Pages” product centered around business data and customer needs, while Amazon has Prime and Echo.
Not a bad refocus.