DeepDarkSee

It’s funny how things cluster out there.  Yesterday I was all rev’d up at how Where is enabling location capable widgets on handsets, and at Moto’s new MOTOMAGX WebUI capability (ship a JavaME app that has an html canvas and JS capabilities) available late this year.  Today I find that Mike Rowehl has just written an article on mobile platform evolution that touches on this and references a related article by Tom Hume which calls out a mobile widget platform (very early still) called WidX.  Whew.

I like what WHERE is doing, and hey, it’s shipping on Sprint and Alltel.  The rub, however, is that the carriers have to approve the widgets that actually ship, and you’re one of many.  They’ll pay you $5 if you cause the sale of their app (a $2.99/mos subscription for access to ALL widgets), and will do revenue share in some cases.  It’s great that they have LBS capability in place, local scripting, and map resources.  Wish they were standards compliant rather than doing their own markup and scripting (very close to html and js, but with exceptions).  I think the economics are tough to build a business based on publishing widgets on Where, but it is a direct and easy path to a mobile presence for a web property.

WidX looks interesting.  Still very early in the process, but it is web standards based.  In my view it’s a (great, interesting) technology experiment until it is available on lots of phones (including the locked networks in North America).

There was a speech out of Google on Web 2.0 a couple months ago where Sergey described Web 2.0 as widgets that run wherever you are.  At the time I thought this was a rather constrained view of what Web 2.0 is (and I still to), but that concept makes loads of sense, and has lots of interesting implications when you think about the Google Phone.  I also think Apple did us a favor by making people think HTML/JS for developing apps for the iPhone.  Would I like to see third party native iPhone apps supported by Apple?  Sure.  But low barrier to deployment, and easily update-able “widgets” in mobile are worth more attention than they are getting.

I sent this to a contact at NAVTEQ today after a conversation on mobile and maps earlier in the week at the Moto Developer Summit in San Jose.  I think this is an opportunity waiting to be leveraged, by a map vendor, or mapping web service provider (ESRI, Autodesk, you there?).  I also think that in cases where carriers mandate map providers, this kind of thinking could win contracts.

As a developer, we want to do more with maps on handsets.  We want to pan and zoom, turn layers on and off, add custom layers, and have a responsive UI experience for the user.  I looked hard for some solutions for this 2.5 years ago as we got started, and have kept poking around since.  This solution means vector maps to me, but as Google as shown, it can also be done ‘marginally well’ with tiles on handsets.  We do it like most right right now with single static images or small groups of tiles.

The key issue is that as a single developer, we don’t have the resources to build a great map display engine in our Java and BREW apps.  We also don’t want to run our own map servers (we use ESRI). 

I was (and am) really surprised that no vendor has shown up at the table offering a map display/rendering module for BREW and for JavaME that developer can adopt and use in their apps. This would be VERY leveraging for developers.I think that a company that solves these problems would be very well received.  I could even see the license for the tool require a certain map vendor. 

I could see NAVTEQ doing this, and working with companies like ESRI or AutoDesk to serve  (and enable their leased servers) vector data to the handset display components you provide.  It just seems like a win-win situation all around.  You don’t step on the toes of your content resellers or server vendors, you enable customers, and you lock in NAVTEQ as the map source.

On a related topic, I think the JSR-293 Location API 2.0, the replacement of the JSR-179 JavaME standard for GPS, provides an interesting opportunity for NAVTEQ along these same lines.  The new standard includes a map display component.  NAVTEQ could write a reference implementation of the map component, but even more interestingly, NAVTEQ could build and make available a super charged version of the implementation – not as a reference but as a value add implementation.  It could be the kind of high end vector display capability that would turn peoples heads, and could be locked to NAVTEQ content (through your existing distribution channels).  This could be part of that same “super handset map display component” work effort.

I see these as opportunities to take a leadership position, as well as advantage NAVTEQ in the mobile space.

If you look long enough at this picture, you will see a giraffe. From the NIEHS Kids Page.