Build Google and Yahoo Maps Without Coding

I stumbled across MapBuilder as I was browsing the Google Code site today. MapBuilder was referenced as one of the sites featured projects. The application is pretty interesting, allowing you to visually create a map using either the Yahoo Maps or Google Maps API and then to export the source code for inclusion on your web site. There is also an option to host your maps directly on MapBuilder and reference them from your site with a button that links to a list of all of your available maps.

There are quite a few things that are really cool about the site:

  1. Supports both Yahoo! Maps and Google Maps.
  2. No need to learn the details of the mapping API’s – just create your maps and go.
  3. MapBuilder does geo-coding, using the Yahoo! Geocode API’sand geocoder.us while Google Map API’s require lattitude and longitude in order to do anything with them.
  4. MapBuilder does the “driving directions to / from here” for you. No need to create custom code for this functionality.
  5. MapBuilder will also do custom development for you if you want something different from what the basic services provide. I’m assuming there is a fee involved, but I couldn’t find reference to it.
  6. The site facilitates building communities around maps that people create on the site.
  7. Best of all, it allows the “common man” to include mapping capabilities on their web sites without having to know how to code in Javascript and HTML.

MapBuilder is a really good example of new, unintended possibilities that are exposed when web applications are designed as a set of API’s using the web as a development platform rather than the siloed approach that we have used historically. This application was written by a third party not affiliated at all with Google or Yahoo!, but because of the way their applications were written they have the possibility of an audience that they did not originally target by allowing someone to build applications around their base functionality.

One should note that creation of a user account is required in order to use the full functionality of the MapBuilder site. They basically ask you for a username, password, and your email address. Thats it. Registration for either a Google Maps API key or Yahoo! Maps API key is also required if you would like to host your map on your own web site rather than hosting it on MapBuilder directly.

Gillmor Gang – User Driven Innovation

The latest Gillmor Gang podcast talks about a concept called “User Driven Innovation” using Google and other vendors who have opened up their API’s as an example of this concept. The main subject of the podcast is disruption, of which this is just a part.

User Driven Innovation is the opening of service API’s to allow users to create applications based on a conglomeration of different service providers. You might remember reading something about this in articles on this site, including the ones here and here.

I have to say, I like the term “User Driven Innovation” much better than “Application Level Reuse”. Whatever you call it, it was validating for me to hear this on the way home last night.

Another Use For Google Maps – The Katrina Information Map

I found an article on Wired News called A Disaster Map ‘Wiki’ is Born. The article points to the Katrina Information Map at scipionus.com. The site is powered by Google Maps and allows people to add markers to the map to post information about the areas in which the hurricane has effected.

This is another good example of what I wrote about back in July about application level reuse and the ‘crowds’ ability to create software a company would never have envisioned by using published application programming interfaces.

Application Level Reuse and Google Maps

I found this, once again, on kottke.org. Someone has used Google Maps to map out the casualties of the Iraq War. Each click on the (+) on the left of the screen shows 30 more casualties.

I think the reason I find this so cool is not because of what this application is mapping out (which is cool — don’t get me wrong), but the fact that it was able to be written at all. Software written this way leverages the Wisdom of Crowds concept, allowing software to be written that the original authors had no idea would be an application of the technology they were creating at the time.

More than even that though, we are seeing a lot of what I call “application level reuse”. The distributed nature of Internet applications such as Google Maps allows the application to be used as a subset of a completely different application that serves a specific, specialized purpose. Applications can be written stringing together multiple applications like this, creating something brand new and extremely useful.

I think corporate IT shops, in most instances, aren’t getting the concept. They continue to write software in a very closed, monolithic fashion, that force their view of the world on their customers and do not allow that view to change — unless they agree and make the change themselves, increasing their development costs.

Amazon.com is another company that gets the concept. All patent issues aside, they were the first company that I remember that created a service oriented API to their application that allowed their customers to actually build their own store fronts if they wanted to. These APIs were used in ways Amazon wouldn’t even have thought of. The Amazon plugin for WordPress I use on the site is a really good example of this.

I think the world has already turned to this model of development and big corporations are missing it. Hell, even SAP, one of the most monolithic software applications in the world right now is getting it. The time has come where your customers want to use your software to make their own models of the world, that are specific to them. They want you to be transparent. They do not want your branding, they want the services you provide. Your branding has a place, but not everywhere.

I believe that customers are moving to the point where they just don’t want you to intrude on them. They want you to be invisible. Being able to integrate your software into theirs in a service-oriented fashion allows you to be invisible and to be integrated into the world they actually work in, rather than the world you think they live in (or worse, making them change worlds to work with you). The more you increase your transparency, the more you can be integrated. The more you are integrated, the more invisible you become. Pretty soon, you are used by default because you are part of your customers world , rather than a vendor that must be dealt with in an additional context shift.

Now, the problem with a paradigm shift like this is that it doesn’t come for free. Employees and business users have to be taught to think this way. Software has to be redesigned with this paradigm in mind. It’s not cheap — but I’m willing to bet its a lot more rewarding, from both a financial perspective, and a customer satisfaction perspective. Once the shift happens, you can stop worrying about “features and functionality” for the customer and start thinking about services the customers can use to make their own “features and functionality”. You can start focusing on the core services you provide.

The additional advantage is if you develop these services with customer use in mind, you can use them too. You can leverage the same services your customers use to constitute new functionality in your software. This also, can decrease your development costs.

This is how I see the world. But then again, who am I? I could be wrong. I doubt it, but I guess it’s possible.