I often find myself talking to people who I should know (in theory), but for some reason, in practice, my neurons refuse to make the right connections to remember these connections. Wouldn’t it be great if someone designed a heads-up display based on your social network?

This is how it would work: when I activate it, and it notices I’m talking to someone, it would do a quick scan and tell me his/her name. That would be a life-saver, and would avoid the first five minutes of the 20-Questions game I have to play every time this happens (while making sure that the other guy (or girl!) doesn’t notice I’m playing the game in my mind.)

It could also tell me how I know that person, because sometimes I remember the name, but nothing else. Wouldn’t it be helpful to know that I’m talking to John Doe, who went to the same high school as I did, and who is now President and CEO of a Fortune 100 company (note to self: graduate soon.)

Not just names, it could even tell me more about the person I didn’t already know (or, in the more likely case, I’ve forgotten.) I’d love to know that my friend John Doe is no longer with his (now ex-) girlfriend Jane, so that would cut out a lot of awkward conversation. Knowing that he just went on a cruise to Alaska would instantly give us a topic to chat about. Knowing that the lady on his arm is not his wife would probably also help. I could ask him about our common friends and if he were in touch with any of them. And then he could use his heads-up display to pull their details up and tell me what I’d already looked up, but that’s another story.

So why isn’t something like this on the market yet? I’m sure there would be throngs of people lined up outside the offices of the company that makes the first such thing. And if they try to patent it, you can cite my blog post as prior art. You’re welcome.

Public transit seems to share many of the characteristics of the third place, as Ray Oldenburg calls them in The Great, Good Place. They’re full of people from all walks of life, having random conversations, and brings several of the same people together with amazing regularity.

Sitting at a café as I write this, and having used public transit for the three months of my internship at Google, I’ve wanted to pen these thoughts down for a long time. Every morning and every evening, I used to hang out with the same set of people. Sometimes a few fresh faces would make their way onto the bus; sometimes one of the regulars would sleep in late and miss their bus.

Whenever I happened to take a later bus than usual, some time around noon, the commuter crowd would have shrunk down to a trickle, and most passengers would be headed to finish off errands, or simply out and about the Bay Area. These passengers had an even greater rapport with the bus driver: I’ve been part of thoroughly engaging conversations with these people, who I do not know the names of, and probably never will. For them, it was a natural group that had formed because of their respective travel habits.

Public transit is markedly absent in America, but it is alive and kicking in most other countries: I’ve seen it in Dublin, I’ve seen it in Montréal, I’ve seen it in Bombay. The local trains of Bombay are the lifeline of the working population. The frequency and timeliness of the trains is something to be proud of (regrettably, the same cannot be said of the rest of the population.) Thus, groups of commuters who travel by the same trains day in and day out form their own cliques. There’s even a name in the local lingo for it: “train friends.” Just as you have family friends and work colleagues, this is a part of your social life that stays with you for a significant part of your life. You don’t visit the homes of your train friends; you hardly talk shop with them; and you hardly meet them outside of the commuter context. But the place is a third place, after all.

As in all the other instances of the third place having a strong existence in Europe and all over the world, but lacking in America, the “place” of public transit exhibits similar properties. In USA, commuters are holed up in their oil-fueled cars and vans and SUVs, all the while blaming the other guy for causing all the traffic jams on the 8-lane highways. It is obvious that this causes at least a small amount of increase in stress levels of the driver (though I can’t be bothered to look up a citation for that right now.) Compare that to urban populations elsewhere that share conversations on a bus or a train.

Ray Oldenburg could probably add “keeping stress levels low” to the ways in which third places affect the daily lives of those who inhabit them.

It’s not often that one gets to be in a meeting with Vinton Cerf — who’s credited as the “Father of the Internet”, and holds the official job title of “Chief Internet Evangelist” at Google. (No, I’m not kidding.)

So when I was invited to a research meeting with him, my mentor Bill Schilit, and others at Google, I was totally in awe. Of course I can’t discuss what we talked, but the little kid in me was awe-struck enough to want to write a blog post simply mentioning it! ;)

I remember having seen him first about 9 years ago. I was a sophomore at Bombay, and I heard from the ACM community that Vint Cerf was to give a talk at SNDT, Churchgate. It was examination time, and as hard as I tried, I couldn’t get anyone else enthused enough to make the hour-long journey to listen to Vint Cerf’s talk. In an engineering school with over 800 students, I had expected to find at least a few takers. None. Nada. Zilch. Everyone was too concerned about their examinations to find time to listen to the Father of the Internet. I gave up, took the train, and went to the talk, all alone. It was totally worth it, I recollect his ambitious Interplanetary Internet project back when he was at MCI.

I had never imagined that 9 years later, I would be attending a meeting with him. It’s not a dream come true, because I had never even dreamt it would be possible to share a table with Vinton Cerf.

Why do I have to search for the search box on any site I visit, before I can type my query into it? Given that almost every well-designed site has a search field, and it has been recommended as a good usability practice since 2001, why is it sometimes hidden deep inside the layout? Here is a suggestion for a change in the browser UI that will enable users to find the search box faster. Even faster than other suggestions so far. It only involves a little semantic markup on part of page authors and some redesign on part of browser makers.

The search box within the browser is underused.

The search box is one of the few basic design patterns omnipresent on the Web. It is also a de facto usability practice to place this search box towards the top right corner of the page. Yet, every site has it at a slightly different location (and some, even towards the bottom.) The user needs to search visually for the search box, or at least glance around until she finds it.

During this entire time, the search box within the browser chrome typically lies unused. It has a default search engine defined where it directs all queries typed into it. Why can’t the currently loaded website take advantage of this in-built search field for its own site-restricted search?

How it would work:

When a user is browsing a site that supports this feature, any searches conducted using the browser search box will send the queries to the site in question, and be able to display search results directly. When no site is loaded, the queries are directed to the user’s default search engine, just as it is now.

This proposal does not require any significant changes to any markup language — all that is needed is to enhance the markup with semantic knowledge, and microformats are just the answer! Simply marking up a <form> element with the CSS class "search" should be enough to tell the browser that this is a search form that should be promoted to the browser’s search box chrome.

Prior work on similar problems

HTML 3.2 (yes, 3.2) defines a link relationship type for search pages. Adding <a href="/search" rel="search"> indicates that the outgoing link is to a search page. Browsers currently don’t do much with this information (please correct me if you are aware of a browser that does something intelligent with this information). OpenSearch is (in their words) a simple format for the sharing of search results. Useful as it is, OpenSearch is more geared towards large-scale general search engines, and browser makers are adopting it as a standard for letting their users pick and install search plugins in browsers.

However, being able to customize the search field on a per-site basis with zero configuration on part of the user is not addressed by any of these proposals.

Addressing Potential Criticism

A few critics might argue that such usage dilutes the purpose of the search field (“It’s meant for searching via a search engine, not on a per-site basis”) or be concerned about possible user confusion (“Is my query being sent to a search engine or to the site I’m now visiting?”).

Considering an intentionality-driven approach to design, this UI is perfectly aligned with the user’s intentions. If a page has been rendered in a browser window, the user’s intention is likely to search within that site. If the user wanted to perform a search using a search engine, there is always the possibility of loading a new tab and then searching via the same field.

Issues of Mode

This also brings up the question of whether such a UI is inherently mode-based. (Modes in a User Interface are said to exist when a single input can result in two or more possible outcomes, depending upon the state of the UI at that point. It is generally considered bad design to employ modes in a UI because it invariably leads to user confusion.) In this case, it is arguable whether or not this UI employs modes.

The user task is “to search”, and the current site can be considered a specialized search engine (the specialization is that they only search within their own site). Given that a lot of sites employ site-limited versions of generalized search engines (e.g. Google’s Custom Search Engines), this notion is not very hard to think of. Hence, I argue that these are not two different modes, but two different search providers for the same box, just as current implementations offer users a choice among Google, Yahoo, Altavista and others.

It is also easy to indicate the destination of the search queries in a visually accessible format. Safari (for example) displays the word “Google” in the search field. When a site-search box is displayed in its place, it is trivial to display the name of the site instead of the word “Google”. It is also trivial to reuse the favicon for the same purpose.

Why not?

What do you think about this idea? Comments, suggestions, enhancements appreciated!

Google just announced a new feature in Google Maps: Click to Call. When you find a business on Google Maps, you can ask to be connected directly. Google then calls you on the number you provide, and places a call to the business at the other end.

This is yet another example of seamless task migration. The user’s ultimate goal in locating a business is to get in touch with them. The most common way to do this today is to call using a phone (at least as long as Voice-over-IP is not as ubiquitous as cellphones and land-lines). Lo, Google bridged the gap. End-to-end support for a user’s tasks using multiple devices is a challenge that’s getting its due attention only recently.

Hopefully, we will soon be able to do the same with phone numbers all over the Web. Imagine a button on my website that says, “click to call me”. Or, a button on my photo albums page that says, “view as a slideshow on the living room TV”. Or being able to press a button on your car radio to “read more about the currently-advertised product once I’m back home”.