Mike Rowehl: This is Mobility

There’s a great post at TabletBlog critiquing the user interface of OS2008, the most recent revision of the operating system that runs on the Nokia internet tablets. To anyone who’s used both devices the points really ring true. Great writeup!

I’m a diehard Linux fan, and a mobile Linux fan in particular. My N810 is with me practically all the time. And people frequently ask me “Hey, what is that thing?” when I’m wandering around with it. Pretty frequently followed by “You think I should get one?” when I start gushing about the web browser, Python and Ruby packages, SSH, and how useful of a device it is for me. But my response is still “Well, are you a developer?” when they ask if they should get one. It’s just not a consumer device, not yet at least.

In theory us developers should be able to mold this open source platform and help make it something capable of appealing to the mass market. It takes time mind you, desktop Linux systems are only starting to make some real headway (thanks mostly to Ubuntu) after years of us geeks hacking around on the stuff. But once you have enough people pointed at an open platform interesting things do start to happen.

Part of the problem in OS2008 however is that the base environment and the bundled firmware applications are still closed source. If I end up disappointed in something like the RSS reader applet functionality I have options. The system is fully programmable so I could make my own RSS reader and create an applet for that which does what I want. It’s possible for me to do that. However if I had the source code to the bundled app the barrier to me trying out the configuration I want for my homescreen would be a lot lower.

I love the platform, and right now the N810 is a killer geek device for me. A real handheld Linux device that I can hack on, fantastic! However in the face of the platforms coming out I think they’re just going to get bowled over unless they do something to leverage the community they have to help them address a wider audience.

While I was upgrading to Wordpress 2.5 this morning I happened across this post I noted but never finished. So it’s a bit less timely, but the overall issues are still interesting.

Looks like modular handset manufacturer Modu is raising a bunch of money. It’s an interesting concept, but certainly not new. Back at the start of 2004 I was taking a look at a company called Antelope who had a product called a Modular Computing Core that promised much the same thing.

The normal argument around getting your data and service where you want them when you want them goes something like this in mobile:

1. Person 1 says that the problem is best solved by a set of services that run on each device/computer/gadget and allow you to synchronize your data and preferences information so that you don’t have to keep entering stuff over and over again.
2. Person 2 says that increasing network coverage and speed coupled with decreasing access costs and competition between access mechanisms for share of user traffic will result in an “always on” infrastructure that makes syncing unnecessary. Just put the data and preferences up in the cloud and always access them realtime online. Surely the network will be acceptable for any use like this before a realistic set of services and clients to sync become available.
3. Person 1 says something like “Bah, SyncML clients come installed on all kinds of handsets already.” And then they start bashing the networks as still being unreliable and unable to move large amounts of data for an effective cost and at the necessary speed.
4. Person 2 says “Ha! SyncML has been around forever and has yet to yield a workable direct consumer application.” Then something about it doing even less than Bluetooth to foster cross-service information semantics, which make it unworkable as a base for large scale cross-application syncing let alone cross-domain syncing.

The discussion always goes on from there, is always circular, and never reaches any conclusion. Normally I wander away by the second round if I haven’t already slipped out by the first round. Which isn’t to say that interesting work isn’t being done on both sides of the equation. Funambol writes some kick ass open source software that makes it more and more realistic to use SyncML every day. However, I still don’t. The Nokia implementation is broken in some way or something of the sort. I would have to setup my own server to get it working, and many of the services I would be interested in using are marked as very beta. And on the other side efforts like OpenID and OAuth are making it more likely that I can just store stuff in the cloud and use it where I like. But even basic interoperability for things like preferences and personalization don’t seem to have made it into general use. And while some of the efforts used to have a focus on mobile, very little seems to have even a consideration for mobile any more.

So in that context a modular computing core is interesting. It’s kinda like flipping both camps the bird and saying “I don’t think either of you are going to get your shit together in any reasonable timeframe, so I’m going to create a way to solve this problem completely in hardware.” Not sure I agree with it, software systems enjoy economies of scale and flexibility that hardware based solutions don’t. But in the meantime, it’s a novel way to endrun both issues and get your stuff where you want it when you want it.

There are a few interesting things going on with “carrier networks” on the whole that have had me wondering about how folks at the carriers/operators can be so painfully dense. There’s the problem with Sprint deploying a proxy transcoder and expecting folks to get whitelisted to not be adapted instead of using standards, stunningly similar to the Vodafone issue which has already been replicated with TeliaSonera. And I have an issue that hits more close to home, my startup company Mowser is apparently subject to some access restrictions on the 3 network in the UK which apparently do not apply to Google or Yahoo.

The common response to issues on these network is that standards be written up to specify the behavior so that carriers stop doing it. I’m going to have to cry bullshit on that one. While listening to a talk by Tim Bray from Rubycon I learned there’s a document up describing the overall architecture of the world wide web. How convenient.

A quick look through the document shows where carrier networks already diverge from published recommendations. For instance take a look at the very first section after the introduction:

In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. One goal of the Web, since its inception, has been to build a global community in which any party can share information with any other party. To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web. The global scope of URIs promotes large-scale “network effects”: the value of an identifier increases the more it is used consistently.

Well when you whitelist and blacklist sites at the network level guess what you’re doing? You’re segmenting the URI namespace based on your access network. Depending on where you are and how you’re accessing the network you might or might not be able to access a resource. And when a transcoding layer is introduced for all requests through a network independent of source link structure, you’re having the network make a decision to change the semantics of a URI, selectively mapping a whole chunk of URIs to other resources. Leaving aside the whole other issue of the general Internet principle of the intelligence for any given set of protocols being at the edge of the network instead of the core, this also conflicts with the overall principle of consistent global identification.

We’ve already had decades to understand and refine the proper functioning of the Internet, and there’s already a tremendous body of work laying down and describing how to replicate and interact with it. But carrier networks continue to break the most basic and fundamental principles when there seem to be obvious and simple alternatives to get to the same goals. I strongly doubt that yet another standard will do anything to help.

Almost all of the Mobile Web docs out of the W3C that I see reference the base W3C architecture description base document like the one I was just looking at. Yet still they go ahead and define something like “in network adaption” when talking about best practices. Best practices on the Internet say that no application decisions should be applied between the two communicating endpoints. Full stop. It’s just incorrect behavior.

Unfortunately nothing really seems to be affecting these folk’s decisions to do things that are disruptive, limiting, and destructive to the long term environment. You can always vote with your feet though. If I were on Sprint I would switch off their service, same thing definitely for 3. It normally only takes a few people switching off and giving the reason of “I can’t access the web sites I want the way I want” for their customer relationship systems to form the correlation and realize it’s an actual problem. I’ll help maintain a list of carriers not to use if you care about the mobile web also, cause people might be more likely to form their decision going into a purchase rather than after they already have things up and running. So here’s my list of carrier not to get service from if you care about the mobile web:

• Vodafone UK and Portugal
• 3 UK
• Sprint

If there are others let me know in the comments.

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.