“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

Why separate contexts into distinct views?

[This is going to be a 2 part piece discussing first why designing for contexts of use is so important by analyzing kayak.com as a great example. Then part two is going to ask for a new metaphor to be be used to describe this type of design across a greater number of platforms.]

In 2005 and 2006 (you know, ancient times) we started to see that the metaphor of the page that existed till that point to describe the major context of focus in UI design for the web was starting to crumble. At the 2006 IA Summit Gene Smith quoted me as saying “The Page is Dead” as he stated afterward “Long Live the Page!”. I took his talk to heart. Later that year, I changed my own presentations to talk directly to the page and the importance of understanding that “the page is a metaphor of a moment of uninterrupted context.”

Dave on the Page

There are 3 core points to make in this slide (besides the fact that Neo kicked ass!):

1. Nothing on the internet really exists. It is only through metaphor that we can understand anything that happens on computers at all. It’s all 1’s and 0’s and we are at the mercy of those who present concepts to us so we can derive meaning to the whole.

2. The web has transitioned from a mode primarily of reading and writing to a mode of activities and tasks.

3. If we are to have a metaphor at all, like “page” then we need to reframe what it means so that the meaning we give it fits the analogy of its reality.

The example I gave back then was kayak.com. 4 years later (4 decades in internet terms) it is still as good as ever. There are 3 distinct contexts within Kayak:

  1. creating your search query
  2. browsing results with the ability to filter and sort along key criteria
  3. confirming your purchase destination

There are other distinct contexts, but you can look at these as the primary examples if the flow of Kayak as a service. What is unclear is why these contexts? What makes these moments of distinction worthy of separation, focus, and control? Let’s review each one.

Kayak Search Screen

When creating a search query there is one thing we know. We know what we are searching for. We know nothing else. By “what we are searching for” we know what type of travel item. We also know the criteria of that search. It makes no sense to have a bunch of blank areas taking up space and/or creating distraction for the end user.

But what Kayak knows that the end user may not, is the intensity of the process of running a search for travel. By maintaining a distinct context here it is easier for the designer/developer of Kayak to mitigate the awful feeling of waiting for results to emerge. That is to say that the next context, results, is completely reliant on the criteria of the search. Any change in most of the parameters of a travel search require a deep set of processing rules across many servers to acquire a result set.

Kayak Results (in progress)

What the user learns, only upon first use is the shere enormity of a results set for Kayak. If Kayak was to make room for both setting the search query and its result set, there would have to be a sacrifice of usability of both screens. Further, if the end-user changed specific criteria like dates or places in the search query while viewing results, existing results would have to disappear, or alternatively there would have to be a clear way to save pieces of the existing results or concatenate the results of multiple queries. This level of complication would be difficult for even the best designer to manage with probably only utility for a small subset of user real world scenarios.

The power of Kayak though is revealed on this screen more than any other. It is in the left side filters. I can change any of these parameters and without so much as a flick of the page, the data (which is already resident on my computer) is limited in view or changed in order as I requested. Being able to play with this data in real-time without having to run heavy queries back to Kayak’s server is a win for me (the end user) and for Kayak (as it reduces load on their servers).

Kayak Option Selection Overlay

Besides the filtering capabilities of the UI, it is also important for the UI to offer controls to progressively display if not give options for the next level of key actions, such as purchase. In the example above, when the user clicks “select” for any option, they are presented with a dialog overlay of the precise purchase options.  There are other overlays like this in the results list area. There is also progressive display of parameter options that are not as used as often in the filter area on the left side panel. Combined these allow the user to change the context permanently (the filter presentations) and then the overlays for progressive temporary information, or an access confirming for the end user goes to the right place when they want to.

Kayak Direction Overlay

A great feature in Kayak is the overlay to see a the details of a single direction on a flight combination. This overlay with accompanying options allows the user to get valuable information that is contextualized with useful options for making decisions without a large investment through the change of the interface.

Kayak: Details View

The details view of all directions and all stops is made available through a contextual progressive display. This has had various view types in the past. At one time for example it was a dialog overlay that was modal (didn’t allow the user to use the rest of the application unless the dialog was acted upon). What is also interesting is that depending on the type of travel object being searched for (flights, hotels, cars) this interaction changes. For example, for hotels the amount of information in a details view is so large with so many different types of views (hotel info, map, reviews) that it actually opens a completely new context, but does so without destroying the results view by opening a completely new window or tab (depending on the user’s settings).

Here on the flight page though, this progressive “opening” of the details of the flight selection could be seen as a “sub context” because as you can see, the amount of information that needs to be made available takes up so much of the screen real estate that almost all the rest of the results page is gone. What this does allow though is to take advantage of the 4th dimension in Interaction Design through scrolling. A user can easily compare 2 open details views by having them both open and scrolling between them. I do not think though this is how it is commonly used. So its other advantage is that it allows the user to dig deeper without feeling like there is a large investment in the system to present this information to them and thus not difficult to return back to where they were.

As you can see through this deconstruction of the contexts of Kayak, a lot of thought went into when to “change the page” and when not to. It is important to have focus, but it is also important to make the user feel comfortable in highly invested search operations, so they feel at ease in digging deeper.

I hope this deconstruction of Kayak.com will help any designer in the future make decisions about when and where to create new contexts and how to manage dominant and as described in the last example, sub-dominant contexts.

In the next part of this series, I’m going to discuss why the page metaphor needs to change to something more robust so that the idea of context management can be applied generally to all types of platforms.

Be Sociable, Share!


The archives run deep. Feel free to search older content using topic keywords.