Mike Rowehl: This is Mobility

We had the automotive focused Mobile Monday in Silicon Valley last night. It worked out quite well, there were quite a few new faces in the audience. Two main presentations for the evening were Dash and BMW.

The folks from Dash were showing off the base functions of their system, but also talking quite a bit about how the Dash acts as a base platform that users and service providers can build off of. One of the things that I liked was the “send to car” function they demoed. You can select an address in a desktop browser and send the info over to your device using their web site and it gets pushed out to the device. The kind of base function I can really see being included in just about any connected device down the line somewhere, but they have it working in their system now.

They also went into some detail about how their traffic monitoring system works. Most traffic monitoring systems use sensors embedded in the road and companies can subscribe to the feed of traffic info and republish it. However it only gives you info about the major roads, highways where the sensors are deployed. The Dash uses the units out in the field as a mobile sensor network to time travel between points and track estimated travel time. That means they can provide traffic on sidestreets and smaller roads (if there are other Dash systems driving around and generating the necessary data). That’s awesome.

Chris from Dash (their brand spankin’ new platform evangelist) went over some of the functions of the APIs. Using the website you can feed in info from KML or GeoRSS and use it alongside the information that the device uses by default. Right now that consists of updating the feed each time you select the entry on your device, so that fresh info is pulled each time. But they’re working on a “dynamic API” that gives the developer more control over the results returned, and can do things like select geographically bounded sets of results based on the current location of the driver if you have a huge data set behind the service.

The Dash isn’t out yet, but it’ll be shipping end of this month. The base platform that it’s built on is actually OpenMoko, so I’m finding it lustworthy on a number of different levels.

We also had Jeff Zabel from BMW come and present an overview of what BMW is working on and some vision for the future. There’s a BMW Technology Office right downtown Palo Alto (BMW Technology office in Palo Alto, maps isn’t recording the zoom level, but the location is correct), I had no idea and I used to walk right around that corner at Cowper and Hamilton on a daily basis for months. Sneaky!

Jeff showed off the set of services that BMW has been working with. Many of them are flavored by the demographics of a typical BMW driver, which doesn’t necessarily overlap with the engineering techy crowd in Silicon Valley. For instance their base service is a voice connection back to a support center so that you can get voice turn by turn directions from a person or help in case of an emergency. As a techy that just sounds horribly wasteful, but that’s what the people who end up in BMWs typically want. I had flashes of the stories people used to tell in Rochester about the execs at Xerox and Kodak who would have an assistant that would filter and then print out their email so they could get it as paper, and then hand write their responses to be transcribed as responses. Shudder. To each their own I suppose. He was also talking about improving those base level systems, providing stuff like seat occupancy info to emergency response in case of a crash. Or sending ahead emergency contact info of medical alerts for the folks expected to be in the vehicle.

They did have some cool features that resonated with my geek side. Jeff was into a shared route feature they have, and I very much agreed with where he was going with it. It’s a feature that allows you to download a preset route and information about it. His example was that lots of folks who come out from Germany want to drive the legendary highway 1 when they’re in town, so they could download a route that takes them along the interesting parts of 1 and gives them info about the road. Personally, I would do Woodside instead. Highway 1 is beautiful, but boring. Waste of a perfectly good BMW. If I found myself in a Z4 M with some time to kill, hell yea, I would do Woodside between Skyline and the coast. And I would love it it said things like “there’s a set of switchbacks in half a mile that will give you goosebumps, let the car in front of you get ahead some so you can gun it.” It should also have a lap timer, but I’m sure that would require a whole other set of warnings on the startup screen.

Jeff said a lot of the purpose of the facility in Palo Alto is to search out interesting new ideas in the valley, wrap them up and work them through, prototype every once in a while, and attempt to ship stuff back to Germany that can make it into future generations of the cars. Great news, I didn’t know something of the sort existed. A whole other fantastic resource in a new direction for folks working on mobile services.

I was surprised to see another SMS service that I hadn’t heard of, and apparently Russ was as well. But what I was paying more attention to was the original Radar post that got me to the service, which references a “How to Build an SMS Service” paper at O’Reilly Safari. I haven’t read the whole paper, just the preview snippets, but I noticed that they reference 411sync as an example way to send SMS (in the chapter “Using a Mashup”). 411sync has since shut down, not being able to find a workable model for sending out SMS messages on behalf of internet services.

I totally agree, SMS services are killer. People have their phones in their pocket all the time, they already text, it’s a real genuine asynchronous response mechanism and possibly the ultimate thin client. But the fact that SMS services pop up, get used by people outside of the normal geekery that take advantage of hacks of the sort, and then unfortunately have to get shut down cause the payment model for SMS doesn’t line up with any apps. That’s just not good. It’s going to lead to the general public getting frustrated with services and walking away from them like they did WAP the first time around.

I’ve been looking at using SMS for services, and Russ has been pulling on some threads as well. We all see the value of adding SMS messaging from the application and user experience side. But how do we make the thing work as a whole, cost to the service provider included? Everyone keeps ignoring this cost of actually sending SMS messages, running a service for a while, and then eventually getting plowed under and forced to quit.

Monetizing batches of messages with advertising I just don’t see working at all, it’s been tried a number of times before and the technical problems and user interest issues really get in the way. Across all mediums chat is one of the hardest things to monetize, it’s hard in a dedicated desktop client, damn right it’s going to be hard to do jammed onto the tail part of a 160 character message. Put that together with not knowing if the user is going to be able to click a link out of the messaging app on their phone, or even have a data plan, and it’s a hard sell to fill SMS inventory. Even when you have segmented and channeled content like sports notifications. If what you’ve got is random messages being sent between teenagers, your potential advertiser group is even smaller.

Some of the more interesting SMS “applications” are the ones that go viral. The community action or political messages that see users forwarding info to other users in order to get the word out about something. The effect of a message is multiplied there, and it’s using the social network of users not just for finding where to send the message, but also to bear the cost of transmission and spread that load around. The same thing isn’t possible if your technical hack needs to be the hub for these connections.

What if you could send virally though? What if someone using your service said “I’ll commit 100 messages every month of my 300 free messages and donate them to your SMS service.” We could either implement that as the carriers opening up their billing systems to outside marketplaces for prepaid messages and minutes…. Wahahahaha! Just kidding, they’ll never do that any time soon. Though it would be FANTASTIC for worldwide payment and mobile web billing solutions. Even I can’t dream that big yet.

How about a peer-to-peer system though? Say you were able to get a java application out on handsets that was able to multiply the leverage of a single inbound message on a command port and forward it to a number of other devices on your behalf. There’s all sorts of potential issues with response paths and making sure your app doesn’t play host to SMS botnets. But it just popped to mind and I figured I would share it. Has anyone fooled around with this out there? I can’t even get Betavine to send messages to the US yet, so I haven’t been able to test any of this out on my own.

As part of investigating SMS applications and non-standard usage I’ve been playing around with the Vodafone Betavine APIs. However I can’t get them to deliver messages to my handset. I had a thread going in the discussion forums, but haven’t seen a response in almost a week. Anyone out there using the Betavine APIs in the US? I have the full command I’m using the send my request in there, is there something I’m doing incorrectly?