Summary: (1) GoogleMaps API illustrates a business strategy accepted by Web 2.0 companies; fumbled by Web 1.0 companies; and rejected by old-world companies. (2) Google Maps succeeds because its complex, polished UI brings a smile and a muttered “how do they do that?” reaction from even jaded Internet users. (3) we’re shifting many of our favorite apps to mobile platforms, which will create some new UI paradigms and also some disappointment in current UI experiments (will people really watch video on their mobile phones?)

These observations and conclusions came from a visit to Google yesterday, where I spent an interesting hour in the world-famous Googleplex cafeteria discussing various aspects of Google Maps with Googler Paul Rademacher. Yes, the food is fantastic; yes, the place is buzzing with energy, just like Netscape in the mid-to-late 90s; and no, the Googleplex is not a spaceship inhabited by aliens.

Of course, one could spend days at a place like this, discussing a variety of different technical and business-related topics with a wide variety of Googlers. I’m tangentially interested in Google’s policy about censoring searches in China, and its difficulties coping with instances of spam and click-fraud; but lots of other people are covering those stories, and it’s not why I came here. I’d like to come back at some point and find a Googler who could explain the company’s strategy with shareable, Web-based word processors (i.e., Writely) and spreadsheets, as well as its vision for future generations of searching (will it take into account “interestingness,” as articulated by Flickr, and will it have some appreciation for “truthiness,” as articulated by Comedy Central’s Stephen Colbert?). But for this visit, I concentrated only on Google’s interesting adventures with maps.

Paul Rademacher is credited for having been the first to create a GoogleMaps mashup, which enabled him to display some real estate listings on a map; and he did this on his own, using his own private, noncommercial web site, while working as a programmer for another company. As a broader metaphor for what’s going on in the Web 2.0 world, I think there are several important observations to be made here. First, Rademacher’s success at creating such a mashup is one of many examples that today’s innovative Web 2.0 products and services can indeed be created and launched by one hard-working, talented person — or, in some cases, a small team of two or three people. To some extent, that has always been true of the software field, and it was true in the early days of Web 1.0 as well; but then we began to see larger and more expensive startup efforts, with an army of developers, and an associated multi-million dollar budget that required massive VC funding, and/or the resources of a large company. I wouldn’t be surprised if we eventually see the same thing for Web 2.0; but for now, we’re still in the early phases of the technology cycle, where a couple of talented, hard-working engineers can do dazzling things.

The second point to remember is that Rademacher was not a Googler when he did his work, and he did not have an official GoogleMaps API to work with — for indeed, there was no API. He looked at the Javascript code that gets downloaded onto the client (e.g., onto your Web browser) when GoogleMaps is invoked, and he figured out how to reverse-engineer it and tweak the code to accomplish what he wanted. To the extent that many of today’s Web 2.0 products are based on downloaded, client-based Javascript and other similar technologies, it means that we may see lots of situations in the future where clever engineers (I hesitate to say “hacker” in this context, but I’m thinking of hackers in the original, positive context) can reverse-engineer it, and figure out how to incorporate it into their own work. Companies intent on protecting and hiding every aspect of their software-based intellectual property are probably going to have to find some other technological means of accomplishing what the Web 2.0 world is doing these days; and companies that don’t want to assist these independent developers, and encourage them to do innovative things with their IP, are probably going to deliver a hodge-podge of undocumented Javascript and pay no attention to whatever happens after that.

But — and this is the third observation I want to make about Rademacher’s initial efforts — the really ambitious technology vendors are spotting these independent efforts at a very early stage, and taking proactive steps to help. Rademacher says that within a couple of weeks after his first Maps-based mashup (which had no advertising, generated no revenues, and did not run as a commercial enterprise) two or three other independent developers had seen what he did, mimicked his efforts, and built their own mashups. And shortly after that, Google itself noticed what was going on — and ultimately offered Rademacher a job, at which point he became a Googler, and began working on more formalized mashup developments. A few months later, Google released a public set of documentation and examples for a formal API that allows virtually anyone to create a mashup to combine various types of data with a spatial map layout — and the rest is history.

There have been several other examples of Google hiring individual developers, and acquiring small companies where a group of developers are doing something interesting with their technology. The same thing is happening with Yahoo and other high-tech companies, and one could argue that high-tech companies like Microsoft, Apple, and IBM have been doing this for decades. But in my experience, the acquiring companies have typically waited much longer, until the innovative startup has created a track record, generated enough revenues to make a profit, and actually created a competitive threat that the larger company feels can be handled most effectively by a straightforward acquisition. A good example of this is today’s announcement of IBM’s $1.3B acquisition of Internet Security Systems, Inc. (ISS). At that size, ISS is obviously no startup!

Back to Google Maps: since the publication of the API showing developers how to create such mashups, an amazing number and variety of mashups have appeared. One of the best known is the “housing maps” mashup that uses data from craigslist.com; but there’s also a mashup that displays the location of convicted sex offenders in your neighborhood; as well as the amazing “earth sandwich.” In fact, there’s a Web site, ProgrammableWeb, devoted to providing an up-to-date list of mashups. Rademacher said that he was intrigued by the variety of such mashups, and also by the fact that the idea for such things often came from non-computer geeks; he mentioned a mashup suggested by someone at last year’s Where 2.0 conference who wanted to see a map of the poisonous fungi in California playgrounds, as well as a mashup called Gmaps Pedometer, that helps runners determine the distance between two points on a map where they’ll be following a jogging route.

Beyond the novelty provided by all these mashups, Rademacher suggests that the reason GoogleMaps has succeeded is at least partially due to the enormous effort invested by Google in developing a complex, polished user interface (UI) that includes anti-aliasing of streets and roads that appear on the map (something that graphics programmers might spot right away, but that most amateurs might not); the ability to “drag” the map north and south, east and west, by just clicking and dragging the cursor; and the ability to type a “free-form” address into text-entry box, rather than laboriously entering fields into a data-entry form. (I mentioned a variation on this point in my discussion of 30 Boxes yesterday.) More fundamental was the epiphany — and I have no idea of where and when the “Eureka!” discovery was shouted — that maps are not just a mechanism for displaying the latitude and longitude of a single point, and not just a mechanism for showing the path from point A to point B. More generally, GoogleMaps provides a mechanism for showing the “spatial” organization of a large set of data, whose interrelationships might not otherwise be immediately obvious to the end-user — e.g., a GoogleMaps display of all the available rental apartments in downtown San Francisco.

Parenthetically, Rademacher pointed out to me that Google’s fundamental search engine technology is an important part of Google Maps. For example, he said, how should the phrase “coffee Brazil” be interpreted when typed into the Google Maps search box? Should the end-user be shown a display of local coffeeshops that sell Brazilian coffee, or a display of coffee plantations in Brazil, or something else? I have no idea what the Google search engine actually does do, but when I navigated over to maps.google.com and typed “coffee Brazil”, I found 8,490 hits, of which the top two were Brazilian coffee companies located in the metropolitan New York area relatively close to where I live. Curiously, when I typed “Brazil coffee”, I got 8,720 hits, of which the first two were the same as for “coffee Brazil.”

Since GoogleMaps is (a) very popular, and (b) has to organize and manipulate subsets of a vast amount of geographical data, I asked Rademacher if there are any useful collections of “best practices” that could help other Web 2.0 developers anticipate problems, solutions, and strategies for “scaling up” their applications to deal with large volumes of users, and large volumes of data. He recommend Christian Gross’ Ajax Patterns and Best Practices book, but said he wasn’t aware of anything else of a significant nature. He agreed that it would be enormously helpful for the rest of the computer industry if we had a collection of case studies titled, loosely, “How did Amazon do what they did with their web site?” and “How did Google do their thing, architecturally?” and “How does the eBay site work?”, and so forth. For all kinds of competitive and proprietary reasons, I think the chances of this happening are about as good as the chances for peace in the Middle East by next Tuesday.

As we wrapped up lunch, I asked Rademacher what sort of things he saw for the future. It’s important to emphasize that he was offering his own, off-the-top-of-the-head opinions here, and it shouldn’t be construed as an “official” Google vision, strategy, or hint of some future product. In any case, Rademacher sees the same transition of functionality and data from PC/desktops to the Web that many of us are seeing these days; and I agree with him that it still has a long way to go. Among other things, I think this is one of the areas where there’s a generational difference: as Narendra Rocherolle mentioned during my discussions with him yesterday, younger (e.g., college-age) Internet users are typically less concerned about uploading personal data onto the Internet than older-generation users, especially those who have worked in security-conscious/privacy-conscious corporate environments for years. I have to admit that I still have a knee-jerk reaction about the risks and dangers of uploading the confidential data that resides on my laptop and desktop computers, even though one could argue that the risk is greater that my laptop will be stolen from my hotel room (or airport) than the risk of a hacker breaking into a reasonably secure/protected/encrypted storehouse of data on some Internet site.

Rademacher also sees, as do many others, a steady movement of Internet applications onto mobile platforms, typified by the high-speed, Internet-enabled cellphones that more and more of us are carrying. Whether that means the next generation of consumer/users will abandon the notion of a traditional “personal” computer is a matter of conjecture; but as I noted in a blog entry a couple of weeks ago, Sun Microsystems CEO Jonathan Schwartz recently reminded us (in a blog entry of his own) that if you ask a teenager whether he/she would like to have a new top-of-the-line PC, or a new top-of-the-line cell phone, it’s highly likely that he or she will choose the cell-phone.

The most “blue sky” vision of the future that Rademacher offered was this: in the future, we’ll expect computers to solve more of our problems directly, rather than simply providing us with efficient tools that nevertheless continue to put the burden on the human to do the problem-solving. The example he used was a familiar one to me: balancing the various constraints and tradeoffs required to make the best choice of a flight itinerary for a business trip. In the “old days,” I would call my travel agent (or, in the twilight era of my interaction with human travel agents, I’d send an email) and explain the basic parameters: when and where I had to travel, and any specific constraints associated with this particular trip (e.g., I can’t leave any earlier than X time on Y date, and my client will pay the plane fare, but only if I fly on airline Z). Aside from that, my travel agent knew my “general” likes and dislikes, and she had her own database and personal knowledge to help choose the best flight for my circumstances.

As we all know, travel agents were disintermediated by the first wave of Internet technology; in their place, we business travelers were given Expedia, Orbitz, and Travelocity — along with websites provided by the individual airlines themselves. All of this saved the airlines a lot of money, and presumably created some profits for the Expedia-style businesses, but it’s not clear that it saved me any money at all. In any case, all it did was provide me with tools, so that I could do the same job that my travel agent used to do for me. That’s fine if I’m doing something simple and straightforward, like buying an e-ticket, online, for the Delta shuttle from New York to Boston. But if I’m planning anything other than a trivial itinerary, I can easily spend an hour or two researching the alternatives and going through the mental exercise of trade-offs and constraints, before I reach the point of typing my name and credit-card into some automated ticketing system. Rademacher’s point is that we should have an “intelligent” automated system that would do all of that — or at least 90% of it — for us. And if we can do it for the travel-agent application, perhaps we can do it for a lot of other problems as well.

All of which made for a very interesting conversation, and some interesting perspectives on what we might expect in the future world of Web 2.5, Web 3.0, and beyond. I look forward to seeing what role Google plays in all of this.