Mike Rowehl: This is Mobility

You know how there’s the general rule of some technology being mainstream when your mother uses it? Well my mom is listening to a podcast, the twist is that it’s a knitting related podcast that my sisters produce. I kinda knew this whole social media thing was headed in an interesting direction when I heard that they all participated in a knitting and crochet related social network. Of course when I asked them if it was a social network they looked askance at me, and said “No, it’s a site where people share the stuff they’re working on and post tips and questions”.

Looks like this whole section of social stuff is catching on in the way folks expected it to. Explains the explosive growth that Ning is experiencing, and why so many folks are scrambling over each other to make something of the sort in mobile. But what’s taking off isn’t “social networking” exactly, it’s people forming communities. Give people a set of pages they can use to create a profile and message to each other, you get a decent user community (frequently focused on flirting with each other, but that’s a different issue). Give people tools to create pages they can use to communicate with each other, and communities start to form. The long term value seems to be tilted more in the Winksite direction than the Mig33 direction in that respect.

Actually, I’m not sure were I’m going with this. It could go anywhere from talking about mobile social building blocks like the stuff MPulse has been working on, or Zygo’s and 3Jam’s take on group messaging, all the way through OpenSocial vs. the mobile web and how we get to start using DiSo ideas like XFN, OpenID, and oAuth, and other microformats in the mobile environment. But then I would have to dig up info about what Johannes Ernst has been up to and how LID has progressed within mobile in particular. But unfortunately I need to get running yet again. Hopefully that’ll stop happening now that I’m not going to be running up and down the peninsula on a daily basis. In the meantime I leave you with this cross-disciplinary thread to pull on if you want: including SMS messaging in the OpenID authentication mechanism to avoid having to enter a password.

Thanks to Russell for pointing out that a new set of MMA guidelines is up for review. Apparently I’m supposed to post feedback in their public forums, but I’m getting a bit tired of having to follow discussions in other places. So I’m posting my feedback in my public forum, just like they posted their recommendation on their site. Just seems proper.

As soon as I read Russell’s post I thought “Yay! Finally some structure around an accepted practice for audience measurement on the mobile web!” Cause any effort to democratize serving ads in a medium and put everyone on equal footing just needs to set down conditions of input (media styles and formats, standardize terms and minimum specification of a buy) and expected output (what should be reported and how should it be measured?) The guidelines as they stand make a point of dealing with the media formats and sizes, not bad, I have no real comments there. However, the mobile web part says nothing at all about audience measurement. Which is kind of conspicuous cause the messaging and downloaded app sections do talk about metrics and reporting.

It’s almost like it was intentionally left out, hoping no one would notice the smoking crater? I’m looking for something along the lines of the IAB Campaign Measurement guidelines. Look at the detail in there: delivery mechanisms and which inclusion tags count as which style and dealing with caching. And most important, it doesn’t matter if it’s right or wrong in every case, just that it’s consistent. Why is there information about handset screen sizes in China, and no mention of how to measure reach on the mobile web? Bad form.

Okay, I know I said the report included sections on application download and messaging audience measurement. Technically that’s true, in that their presence in the report calls into attention their absence for the mobile web section. But these are the counting and reporting “guidelines” for mobile messaging:

Operators could use counting tools that use digital fingerprinting or similar technologies to track message
distribution among users in the network. This could enable the service provider to track the dissemination
routes, to identify social leaders, and to reward users for forwarding messages. However, all these
capabilities must comply with existing national level regulatory and legal frameworks covering privacy and
the use of personal data. In addition end users concerns and expectations will always need to be
carefully managed. Taking all steps necessary to ensure end customers fully understand any proposal to
user their data, together with providing a clear choice to opt in or out of this type of service is essential for
its long term success.

Umm. I’m not sure “The carriers might do something to help count users. And oh yea, be sure not to break the law” really counts as a guideline. That’s not helpful at all, to anyone.

Then there’s the section on mobile video, which says pretty much “we’ve got no guidelines, but here’s some info about mobile video.” What the hell? Are these guidelines for usage? Or marketing material? If you don’t have guidelines for mobile video don’t include a section on mobile video in your guidelines. It’s reminiscent of padding out a book report. Was there a minimum word count for this assignment? I actually scrolled back to the top of the document and checked the title of the report again, thinking that maybe this was really just an informational release. The mobile marketing strategic overview and not a set of guidelines. But that’s what the report says, “MMA Global Mobile Advertising Guidelines”.

So lets create a specification for them so we don’t have to go through the process again. Audience numbers must be counted using the MSISDN if available and fall back on cookie based counting in all other cases. MSISDN presence is dictated by the presence of one of the following headers in a request from a mobile terminal:

• X-MSISDN
• X-NOKIA-MSISDN
• X-UP-SUBNO
• X-WAP-MSISDN
• X-UP-CALLING-LINE-ID
• USER-IDENTITY-FORWARD-MSISDN
• X-WAP-CLIENTID

It’s relatively easy to pick out which headers to use if folks publish some info about the traffic they’re getting. Cookies must be delivered with the domain of the central advertising network if appropriate, which means image based recording even for text adverts. 1×1 gif, which admittedly carriers could block.

That’s it, that’s a spec, it’s the kind of thing I would expect the MMA to put in their “guidelines”. Furthermore, given their position as the premier global organization pulling membership from carriers, software providers, and manufacturers I would expect them to:

• quantify in what percentage of cases the guidelines are expected to yield valid numbers given global averages
• work to improve the guidelines to decrease the error rate over time
• provide recommendations and guidelines to carriers, software providers, and device manufacturers to decrease the error rate going forward

If something like that happened we might have something that could “stimulate the growth of mobile marketing and its associated technologies.” As it stands now however, I don’t really see the point. It clarifies a few points if you already have an advertising business up and running. But say you’re an independent site owner looking to sell your own inventory directly, or an open source advertising platform looking to add mobile adverting to the mix of features your package provides. Read through the guidelines with that perspective in mind and it’s obvious it doesn’t provide any of the necessary clarity at all.

I did a search this morning to see if there was anything related to the cookie issue with Openwave software. Instead I found a post from Dennis saying that it appears that Sprint has now followed Vodafone in disrupting the mobile web. Ouch. And their partner in crime? Openwave. I was hoping to find some positive reaction, instead I find a new mention of negative behavior. Damn.

Great post from the Mippin folks explaining a problem with cookies on mobile devices, in the US in particular. I’ve heard support numbers all over the place from folks. Some say cookies fail 50% of the time, others say they work in all but 5% of the cases. Apparently there’s some major issues with using a bare TLD with Openwave (either browsers, gateways, or browsers and gateways - see this Openwave FAQ for some info about how they’ve mucked up identifiers). Good info to know.

If this is a browser plus gateway issue it would be nice to see it get fixed. If this is a browser issue that can’t be fixed I think we all need to make sure to continue giving Openwave folks the evil eye when you see them (I’m assuming you all do already, just keep it up). Come on Openwave! This is your chance to prove to us all you’re not completely useless. I’ll be keeping an eye out for major network changes.

I find this news about Google deploying a system that lets site owners sell their own inventory on top of AdSense very interesting. I was fooling around with a system for mobile publishers to represent their own inventory for mobile on top of existing networks. Looks like others were thinking in the same direction. I wonder how well their service works out for selling mobile inventory. I’ll see if I can get in on the action. Meanwhile, if anyone is using it for mobile please share your experience.

The second part of a series of mobile payments posts I’m making to get ready for BarCampBankSF later on this month. The first part was a problem overview for the issues. This part is about the Fear Uncertainty and Doubt (FUD) that stand in the way of trying to get a global system going for moving money around.

I was going to hold off on this topic for a while, but then I ran across this gem of a report from our beloved US government explaining why mobile payments could destroy the world. The whole topic area right here just strikes me as backward, small minded, and at it’s base just really stupid. Here we have the potential for a fantastic system, uncoupling the concept of money from bits of paper and metal. Making it easy for people to do what they want with their money when they want. Being able to reach out and help friends and relatives in far away places instantly.

But instead of seeing the potential upside (not, potential upside, most of us don’t have the ability to do the things discussed in that report under the current set of services), instead what’s called out is the potential for abuse by a very small percentage of the population. I just don’t get that mentality at all. It’s like not allowing cars because people could get drunk and drive around in them. Or declaring that everyone has to walk around naked cause someone could hide weapons under their clothes. It’s just absurd. Why cripple everyone because you’re concerned about the behavior of a few? Apparently all you have to do is include the word “terrorism” and you can propose just about anything you want.

I personally don’t buy it at all. If you want to cut off the potential use of a system by terrorism, sure, by all means! I’m not going to stand in your way. But if you want to cripple a system that dictates what I can do with my money, how I can do it, and when I can do it, well then we have a bit of an issue. If you want to cut off terrorism do things that affect terrorists and money launderers. Inconveniencing everyone in order to do so is just lazy thinking. Unfortunately people have strong and irrational feelings about things like this cause they feel their safety is threatened (Surprise! You never really had safety, you’ve just become more aware of not having it), and any bit of absolutist thinking they can hold on to in order to make them feel better. Well darnit, that’s just going to have to do. Cutting off terrorism by cutting off their funding is one of those areas (Surprise! That’s not going to work either, probably won’t even slow it down).

Unfortunately what we’re working at here, at heart, is a fundamental change in the way people think about money. And like any major change, that really makes people nervous. Especially people who have a vested interest in the particular limitations, controls, and structures brought about by the incidental effects of the current system. People like governments and banks, who unfortunately are holding most of the cards in this game. In order to figure out a workable system we either need to work around the folks who would normally stand in our way, or convert them to our side. Most of the efforts that have come before are based around a third option of giving incentive to the existing folks and caving in to their restrictions. I don’t consider that option to be on the table, limiting a new system to make the players in the old system happy isn’t a path to progress in my opinion.

Converting the existing folks to our side seems like it could be pretty difficult. Hard to say though with the setup the way it is in mobile payments. With the carrier sitting in the middle of every significant transaction we might be able to play the banks against the carriers to come up with a system that works at scale to break open that market for the banks. But the banks have their own sets of issues. Working completely around the existing system might be the real option we have. Direct user to user payments with something only vaguely resembling a bank in the middle. Using alternative “payment” methods like trading prepaid minutes or prepaid messages. That gives us a bit of a foothold, but how does the regulation and legal arena look for schemes like that? For instance can I take $25 from someone in CA and at their request provide it to someone in NY for withdrawl? What needs to be reported and recorded in that case, and what base restrictions are there? If someone has good pointers please share them.

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.

A few of the things I’ve been playing around with on the side lately have the common theme of inversion of control. Making one side of an interaction consume something that it normally emits or emits something that it normally consumes. Take the PAMP stack post at dev.mobi for example, a handset running Apache, PHP, and Mysql. On my own I’ve been working on HTTP controlling the Mac mini hooked up to my TV. I want a generalize HTTP interface to the stuff I normally do on my television so that I can control it with my N810 or iPhone.

The whole theme of “your mobile as your remote control of the world” has been floating around for a long time. And I’m kinda curious how easy it would be to get there at this point. For instance if I sit in front of my TV I normally do so with at least one of my devices in my hand. Admit it, you do the same. We’re all ADD now, so better to just embrace it and figure out how to feed the demons rather than spending naval gazing time figuring out if we should be doing it or not. What I would actually like to be able to do is to “switch channels” to something from my device. I’m watching Scrubs for instance, but I run across a video that someone linked to while I’m dicking around reading feeds on my N810. I want to be able to use the N810 to send that video to my TV, switch channels to youTube so to speak.

There’s MythTV stuff out there for controlling your DVR from the N810 (there’s a dedicated package actually). But they’re all point solutions. I want raw exposed APIs for this stuff. Today I want to send videos to my television, but who knows what I might want to display there next. Maybe a dynamic web page that I want to toss up on the big screen while I dig through the details about something else on my device. Although videocasting and the like have really increased the unbundling of media, and DVRs and related technologies given people much more control over reintegrating their own channels, the viewport itself still remains somewhat under external control.

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?