Philip Haine's articles on Product Vision, Innovation and Design

Teaching PIMs about ZIPs

Zip codes were invented to help the post office, but now they are helping us humans.

Maybe I’m just vexed by living in a hard-to-type city. But when searching Google Maps or Yahoo’s maps beta for a certain nice restaurant, I find it more pleasant to type “Fringale 94115″ than “Fringale, san francisco, ca”.

Postal codes are efficient and precise. The machine knows what you mean when you tell it a zip code, often better than if you try and enter the city or state name correctly.

Some enlightened e-commerce web sites know this, and ask for your zip code first, using it to pre-populate the city and state field. This saves you time and reduces errors.

So here is a modest design to steal for Personal Information Managers like Mac OS X’s Address Book or Microsoft Outlook: how about letting the user tab over to the zip field, enter 94107, and have it fill in “San Francisco” and “California” for you?

Fringale is wonderful, by the way. Check it out, but make a reservation.

[Readers, do any desktop PIMs look up city & state by zip code yet?]

Posted by Philip Haine on Thursday, February 9th, 2006 at 11:55 am.
See similar articles in: Commentary, Quick Ideas.

4 Responses to “Teaching PIMs about ZIPs”

  1. Wayne wrote on February 15th, 2006 at 10:13 pm :

    Your friend David over at MerchantCircle (www.merchantcircle.com) has been spending a bit of time working on this local search problem. Indeed, you can type “Fringale 94115″ or “Fringale San Francisco” and get the results you are looking for. (Okay, small nit: MC uses a two box search instead of one box for its queries — a hotly debated topic). We’ve also been working on some interesting phonetic matching stuff so even if you can’t spell San Francisco (seems like at least 35% of all queries have spelling errors), it still works. Try “Fringale” and “San Farncisco” and check out your results.

    BTW, what *do* you think about one box vs. two box search for local queries?

  2. Philip Haine wrote on February 23rd, 2006 at 7:07 pm :

    I think it’s great that you are forgiving common typos like “san farncisco”. A polite human agent would know what you mean and just give you what you need, without even calling the infinitesimal error to your attention.

    I did a quick survey to see who might be equally polite:
    Yahoo! Maps beta takes the same give-me-what-I-need, not-what-I-asked-for approach.
    Google takes you literally, but asks if you really meant san francisco. That’s okay. It works really well for web search, but c’mon, now many san farncisco’s are there?
    – Both of these accept common shortcuts like “sf” or “nyc”.
    – If I ask Yahoo! Weather to tell me whether the air in Montreal is bloody cold, as opposed to frikkin cold, it makes me choose whether I mean Montreal Canada, Montreal Missouri or Montreal Wisconsin. With all due respect to Missourians and Wisconsinites, it’s a bit of a pedantic question. It would’ve been smarter to go ahead and assume the most probable result, but put off to the side clear links to the other possibilities.

    As for the old one versus two search box question…

    One search box may SEEM easier and more minimal and more direct. But it is not necessarily easier, because first, the user has to know what type of input we expect. (Google Maps hints at acceptable inputs: ‘e.g., “hotels near lax” or “10 market st, san francisco” ‘ ). Secondly, we have to worry about the machine teasing the input apart correctly. If either the human or machine makes a mistake, the solution fails.

    By providing two fields, we are guiding the user into giving us not just the information we need, but also a useful tidbit of meta-information about what is what. The machine doesn’t have to guess at the partitioning.

    To put the debate to rest, why don’t you take bets and do a live test? For an hour or two, give odd-numbered IP addresses a single field with a dab of explanatory text. Give even-numbered IP addresses two fields. Collect a few thousand queries. What was the error rate for user input? What was the machine’s effectiveness at making use of the input? Hey, it’s a bit of work but it will be a fun case study for us all and you’ll never have to wonder about it again.

    As for me, put me down for $10 in favor of two fields. The way MerchantCircle is now is big and clear, leaves the user no doubt as to what is expected, and leaves the machine no doubt as to how to interpret the input.

  3. David Creemer wrote on March 20th, 2006 at 3:39 pm :

    Hey, FWIW, it was Jason ( http://www.mischievous.org/blog ) who implemented most of the searching code…

  4. Help Everyone wrote on August 19th, 2009 at 8:08 am :

    I have an idea.

    When are the tons of missing-links going to be fixed?

    http://productvision.com/bios.html
    http://stealthisidea.com/wp-comments-post.php

    Links that have *NEVER* even existed.

Leave a Reply