Sunday, April 23, 2006

Google SMS and search as a dialogue

Rudy Schusteritsch and Kerry Rodden at Google wrote an interesting CHI 2005 short paper, "Mobile Search with Text Messages: Designing the User Experience for Google SMS", that discusses some of the constraints and challenges in building Google SMS.

Most interesting to me were the tidbits on how many users seemed to expect Google SMS not to work like a one-shot search, but more as a dialogue. Some excerpts:
At present, SMS is primarily used for 1-to-1 communication; Google SMS repurposes it to enable mobile search. We expected that this might be confusing to users, requiring them to adjust their conceptual model of the technology ....

Most [users] had some initial problems understanding how it could be used for search. For example, one experienced SMS user wondered at first whether a Google employee would receive their query and reply with an answer ....

Several users started a product search task by sending a message like "shopping", expecting to enter a mode that would cause their subsequent messages to be interpreted as product searches. They were confused to receive an error message in return, telling them that their query had no results.
People at first expected Google SMS to work like normal SMS, like a conversation. They appeared to expect a back-and-forth of text messages, narrowing in on the information desired.

This does suggest an alternative model for mobile search using SMS. Perhaps the search should be iterative. For example, I could imagine this chain of SMS messages between me and a search engine:
Me: sushi

Google SMS: A sushi restaurant in Seattle? Blue C Sushi in Fremont is popular. Directions? A recommendation for sushi somewhere else?

Me: downtown

Google SMS: Saito's at 2nd and Lenoa? Red Fin at 6th and Stewart? Both highly rated.

Me: saito

Google SMS: Saito's Japanese Cafe & Bar, 2120 2nd Ave, Seattle (206) 728-1333
Or this conversation:
Me: price ipod

Google SMS: Average price, 60G iPod, $383. Lowest price, $344, at PCMall.

Me: 30g

Google SMS: Average price, 30G iPod, $322. Lowest price, $282, at Amazon.

Me: at apple

Google SMS: Apple.com, 30G iPod, $299 + tax with free shipping.
I am glossing over some hard issues here. How would the system determine that a thread has ended and a new one begun? How would we reliably disambiguate and intelligently respond to iterative queries? What can we do to avoid searcher frustration if we guess wrong about user intent? How do we respond clearly in less than 160 characters in the general case?

But, the user study seemed to suggest that Google SMS users do expect more of a dialogue model. While we can train users out of that expectation, I think the dialogue model has advantages for helping people discover and narrow down on what they want.

I believe this is also true for regular web search. Current search engines treat each search as independent, but that is not how people use search engines.

When I need to find something, I start with one search. If I am not satisfied with those results, I refine my query, changing it to something slightly different. If that doesn't get me what I want, I change it again.

I am repeatedly refining my search query, trying to find the information I need. But current search engines ignore this stream of related queries, this dialogue, instead treating each search as independent.

In both mobile search and web search, I think there is an opportunity for techniques that focus explicitly on this kind of refinement process, bringing all the information from the past and present to bear.

I think search should be a dialogue, going on for as long as it takes to help people find what they need.

4 comments:

or said...

Interesting. I just learned that events can be added to Google calendar with SMS.(unfortunately I could not test this because I use Verizon which Google Calendar does not support yet) The following url has all the details: http://telegramsam.googlepages.com/googlecalendarsmstricks

Apparently the quick add feature can be used via SMS. This would seem like a basic dialogue. You send "dinner at Zupas tomorrow 7pm" and receive a message back - "Created event: Dinner at Zupas @ Sat, Apr 22 8pm" I would imagine that it can't be too difficult to extend that to allow futher dialogue.

jeremy said...

Greg writes: "In both mobile search and web search, I think there is an opportunity for techniques that focus explicitly on this kind of refinement process, bringing all the information from the past and present to bear."

Woah, hold on a minute, here. Have you just gone 180 on us? I thought you implied a few weeks ago that you were dead set against tools, that people would not use them, that the way forward was through personalization. Now, from the text above, it appears you've completely embraced the tools approach. What are tools, if not manifestations of what the system thinks you might want? Are not query refinement tools the system's attempt at engaging you in a dialogue?

System-state information is revealed by the range of choices they present you with (query refinement options). Greg-state information is saved through the additional information that gets sent when you select a query refinement option.

It is crude right now, yes. And the system only saves the previous two states (your original query and your refinement) and not more. It will get better. But through tools, on sites like Vivisimo and Ask, you are already carrying on the dialogue you seek.

Again, what I like about tools, rather than personalization, is that with tools I can actually carry on this dialogue. With personalization, the system makes all its decisions for me, and does not offer me a way of changing its opinion of me.

Greg Linden said...

Hi, Jeremy. No, no 180 here. But I think we have a misunderstanding about terms and definitions.

When I talk about "more powerful tools", I am arguing against more complicated interfaces, like trying to train everyone to use advanced search.

That example may sound extreme, but some do argue for something not far from this. For example, Udi Manber (former CEO of A9, now at Google) said, "People will learn to use search better but have to invest the thinking," at PC Forum in 2005 as part of advocating for providing complicated tools to users.

I, Marissa Mayer at Google, and many others have argued that you generally can't try to get people to do work. You need to make things simple and easy.

There are many ways to make things easy. Personalization -- showing different things to different people depending on their history and the context -- is just one approach.

I am obviously not opposed to providing better tools. But, I do think most people prefer simple tools over complicated tools. And, I think that most people will not invest in thinking if they don't have to or if there is no immediate and obvious benefit from doing so.

jeremy said...

Of course we both agree that people will not and should not use tools if there is no immediate and obvious benefit in doing so. Of course the tool has to do something useful.

But now I ask myself.. which search interface is more "complicated"? You have Google's interface in which you can type 2-3 words, but if you want any more specificity or clarity in expressing your information need (i.e. phrase operators, negation operators, domain restriction operators, etc) you have to learn dozens of arcane command line operators, or Ask´s interface, in which you also can just type 2-3 words, but it will expose to you in the right column a bunch of context-appropriate query refinement tools, which you then just look at and click?

Given that the results page is no less busy in Ask than in Google.. as Ask fills the right column with tools rather than ads, I would argue that Google´s interface is actually more complicated. If you want to search on a phrase, for example, with Google you really are forced to learn the advanced search syntax. With Ask, on the other hand, it will suggest to you a phrase version of your query (when appropriate) as well as other related phrases. Ask suggests these things, not because of personalization, but because it exposes internal mechanisms in an easy, simple to use manner.. without forcing the users to learn complicated query syntax or invest in extra thinking.

The more I read from you, the more I think we agree on fundamentals. I think we just dont agree on which things are actually expressions of those fundamentals, and which things run counter to those fundamentals.

Anyway, maybe I will chat you up at SIGIR if you are going this year.