Mike Rowehl: This is Mobility

I kept seeing commercials on TV saying Vehix has a mobile version. I went and poked at it however and had some issues. First off was that my N95 brought up the full web version. I’ve seen a bunch of discussions online saying things like “if the user is on a device with a full browser or using Opera Mini of course they want the full version.” From expert users sometimes even. That’s just stupid. I’m pretty sure the problem was just that the platform Vehix used just didn’t recognize the N95 But in case someone made the explicit decision to return the full version to Webkit on the N series, you were wrong. Definitely in the state it’s in now.

One of the major problems is that there’s no actual link over to the mobile version if you end up on the desktop version by mistake. I searched around on the web and didn’t find any mention of it. So I pulled on Firefox on my desktop where I have a bunch of mobile user agents saved in modify headers. The first two user agents I tried resulted in an “unsupported browser” error page. Well, that also is just dumb when you’re dealing with mobile. Seriously, if you’re going to do things all half-assed, at least allow your users to pick the right version manually if they should happen to understand what’s going on. Throwing up an error page and suggesting a bunch of desktop browsers to be using instead, that’s just poor form.

Turns out the mobile version is at http://mobile.usablenet.com/mt/www.vehix.com/ if you want to check it out. Once you can get there it really is a pretty nice mobile site. The layout is clean, selection options were a bit funky at times but workable, and it seemed like a perfectly practical site. My car is holding its resale value very nicely, that’s always great to see. Can’t really thank Vehix for that, but it put me in a good mood at least.

I had heard about Everyblock.com in the context of it being the continuation of the chicagocrime.org by Adrian Holovaty. I had never really poked at it though, mostly because it didn’t yet have info for my area yet. But then yesterday I was listening to the Udell interview with Holovaty and picked up some interesting threads.

The first is the applicability of the project to something like augmenting reality. As it is right now Everyblock is sucking in info from all over the place, scraping information out of it and unifying where it can, and presenting all the data together for a location. There’s definitely usefulness for finding out what’s going on in your neighborhood as a direct consumer. And for journalists it helps with trend spotting and information correlation. However if you reorganize the info around rates of change or concentration instead of events you could make some great mobile apps. Like an overlay for a Google maps style app that would alert you if you’re headed into a high crime area. The plan it to emit structured data back out of Everyblock in addition to offering the site directly on top of the data. When that happens it might allow some interesting apps that would otherwise be impractical or impossible right now.

The other bit that I found interesting was Jon’s comment that the evolving role of librarians in local libraries could include organizing and cataloging sources of local information such as the crime data or building permit info that Everyblock is currently doing. That’s an interesting angle on the role of the librarian and the library in our current information rich environment.

There’s an event called BarCamp Bank coming up in Berkeley in a few weeks. I saw that a few people signed up for the event were already listed as interested in digital cash or mobile payment systems. I figure it’ll be a good chance to gather some folks and discuss what options we have available, and I want to kick the conversation off so that we can get to the real meat of the discussion while we’re there.

The first thing I want to say is that existing mobile payments do not work. I’ve heard it said a number of times that mobile “comes with a built in payment system”, but that’s really a load of shit. Allow me to elaborate.

First of all theres the structure and revenue share of the existing payment infrastructure. In the cases where it’s possible to bill back to the customer bill the functionality is backdoored in frequently through premium SMS messaging. The carrier generally takes a large share of the transaction (I hear numbers like 50 percent here in the US, and I’ve been told it’s even worse in India). And of course the transaction isn’t directly from merchant to carrier to customer. Oh no, of course not. Theres the premium SMS provider in the middle as well also wanting their cut. It’s a hostile environment for merchants with way too much lockin for existing players. The base costs to use these systems are so high, and the overhead so steep, that it really discourages lots of potentially interesting usages.

Second is the off-deck payment systems. Stuff like Google Checkout for mobile, PayPal Mobile, and Obopay. First is of course that there are some user interface or user perception issues around the services. They also assume a credit based economy. No problem in the US and Europe, but a horrible problem in Africa, India, and China. “Who cares about people in China” you say? (particularly if you live in the Bay Area, people around here just love to dismiss the rest of the world) Well, ask anyone who watches construction and commodity markets where they think interesting stuff is happening. I bet those folks are interested in China at the very least. For all the nastiness of carrier billing, at least it handles the cash based economy and prepaid cell plans relatively well.

And finally, say we had a magic system that everyone could use with minimal setup and a great experience, every user had access to it, and every online merchant accepted it. Now you start having to worry about some pretty heavy regulation. There are banking and financial regulations meant to insure the basic level of trust. But recently there are also more regulations meant to curb money laundering and nefarious activities. How many people are familiar with those regulations on a global level? Even if we crack the technical problems and solve the user interface issues and gain user trust there’s still some potential issues with the G-men, whoever those shadowy puppetmasters might be.

So thats what we’re looking at. Tough, but things worth tackling normally are. Next post on this topic is a bit of background on whats been tried in the past and what technologies exist. The hat will be tipped to David Chaum I’m sure, but I need to read up a bit before I’m ready for that.

It looks like the world at large is starting to take up the challenge of understanding what it means to base an effort around the economics of abundance instead of scarcity. It’s already a pretty common thread with folks who geek out about things like nanotech, but didn’t really seem to be getting wide attention till just the last few days. It’s something I’ve struggled with explaining for a long time. I’ve been working on and with Linux for more than a decade, been running a free event for mobile enthusiasts for almost 4 years, helped out with barcamps and other community events, and most recently started working on a free service aimed at making every web page mobile.

Over the years, every step of the way, there’s always been someone saying “you know, people value something based on how much they pay for it, not how much it’s worth.” Which really sounds like it gets at a core truth, if for no other reason than because everyone seems to say it. But Linux has succeeded despite all the insistence by all the experts that it would never be able to compete “in the real world”, open source in general continues to roll along and gain more and more steam all the time, open community events are becoming more popular and more accepted (especially within tech). I’m hoping that this thread works itself out and that Chris can do for the economics of abundance what he did for the long tail - turn it into such an accepted and obvious model that folks start to laugh about how often it’s mentioned. It would really save me a lot of time in explaining the things I do. So please, read the Wired article, and some of the follow on conversations and earlier posts:

• http://ventureblog.com/articles/2006/10/chris_anderson_1.php
• http://www.techdirt.com/articles/20061026/102329.shtml
• http://www.techdirt.com/articles/20070503/012939.shtml
• http://www.longtail.com/the_long_tail/2006/10/the_economics_o.html
• http://avc.blogs.com/a_vc/2006/03/the_freemium_bu.html
• http://redeye.firstround.com/2007/03/the_first_penny.html

Hopefully they’ll do a better job of explaining why you can’t dismiss free stuff than I’ve been able to.

Following up on some of the mobile applications pondering I was doing the other day, I’ve been pointed at and run across some new info about SMS usage. I figured I would post it to share, seeing as how that post pondering if it can be done is currently the number one search result for “sms alternate port”.

First of all, yes you can send to alternate ports through many of the aggregators, though the feature seems to be used so infrequently that it isn’t included in the standard docs and might be a bit obtuse and hard to use. Comments to my last post pointed me at these:

• Mobivity, a US based mobile marketing company, makes it easy to do
• Sending SMS on other ports with Clickatell is possible, just poorly documented and not very user friendly

That’s all well and good, but SMS is relatively nasty and expensive and very regionally segmented, hard to use for most folks. But then Dan pointed me at the Betavine APIs. Part of what they do is allow sending SMS, for free. Including application trigger SMS messages, which are SMS messages on alternate ports. Interesting, but I was skeptical to say the least. I’ve been working through some issues trying to use them from the US, but I’ve been told that yes, the API should allow you to send a message anywhere. Yep, anywhere in the world.

They even allow you to register a web mashup and give it it’s own id so that you can send SMS from it. The default bucket of messages is only 100 for a user, and I need to dig a bit more into how that gets refilled and if this would be workable for a real service running at volume. But hell, if nothing else it lowers the barrier to entry for mobile developers. If you’re looking to try out some SMS stuff and want to be able to send arbitrary messages anywhere in the world, check out Betavine.

I was walking by a shop the other night right downtown San Mateo, and what do I see? Jolt cola. So I had to go back today and actually get some to make sure it was the real stuff, and that I wasn’t just suffering from sleep deprivation based psychotic hallucination:

Yep, it’s the good stuff. Right downtown San Mateo too, it just doesn’t get much cooler than that. The place is called Candie Land, check out the reviews on Yelp, starring expert testimony such as that produced by yours truly. Most important, go get a Jolt or two and try them out. Tell them Miker sent you, maybe I’ll get comped a bottle or two.

I’ve been thinking a decent amount recently about using SMS or other forms of messaging to drive mobile web usage. My overall question being can you drive mobile web usage with SMS and monetize your site with advertising? My gut feeling was no. And I think that’s what the number say. I figured I would share a bit of what I’ve been playing around with so that maybe we can work toward a shared understanding of SMS and mobile web interplay. My “model” of SMS/WAP usage has a few different variables:

• number of users
• number of SMS messages per user per day
• message response rate, what percentage of the time do users click on some message you send them
• average session length (number of pageviews) once a user does click through
• what’s your effective CPM on your site, how much do you make per thousand pageviews on average
• what do you pay to send a message

Relatively simple. Your daily cost is the (number of users) x (the number of messages per day) x (the cost per message). And your number of SMS driven pageviews is your (number of users) x (number of messages) x (response rate) x (pages per session). Divide that by 1000 and multiply by ECPM and you have your revenue.

Lets plug in some numbers and check it out, assume we have 1000 users. Lets assume that we’ve been ultra effective at figuring out what a user will really be interested in, so we send just one message per day and the user ends up clicking on that message and visiting the site 40% of the time. Take a session length of 6 pages, an ECPM of $5, and a cost per message of .02.

With a thousand users and one message per day that means we pay $20 to send out SMS messages every day. With a 40% click rate that means 400 responses at 6 pageviews per session, or 2400 pages. At $5 ECPM that means $12 in income from those pages. $20 spent and $12 made, not great.

Of course my numbers could just be completely off base. The one I’m really not sure about at all is the 6 pageviews per session number. I have a gut feeling that’s about right for mobile usage, especially in response to an asynchronous message. As far as the others, 40% click rate I think is extremely high, and 1 message per day is low. $5 ECPM for mobile pages is fantastic, I think most sites are way lower. And 2 cents for international SMS delivery is pretty cheap. I think if anything most people would see a bigger loss if they took a look at their site and plugged numbers in there.

Which isn’t to say that SMS is unusable for all services, just that if you’re looking at SMS and mobile web from the straight up media angle it’s not a great way to drive distribution. Lots of times I’ve said and heard people say “well if you had folks sign up and give you their phone number you could notify them of changes and drive users back to the site.” Technically true, but I don’t think the financials work out for the common case I’m seeing out there.

I’m going to pick up the handheld of the year thread from TabletBlog and encourage all you N810 fans to go vote N810 at the Engadget awards.

Michael Mace posted a great wrapup of a few threads that have been going around with respect to native vs browser based mobile development. He does a great job of laying down a nice linear story about the evolving development environment. And of course everyone who had an interest in seeing native mobile application development continue is all up in arms about his statements. I agree, kinda, but not really completely.

Of course this isn’t a black and white question. It’s not that mobile web apps have suddenly magically hit some threshold and now native apps will never be used for anything. It’s an analog value of course. Mobile web apps are getting better, the browsers more robust, the devices more capable. What’s happening is that while you HAD to write a native or Java app in the past in order to get a passable product to market, you can do more and more just using the browser.

Same exact thing as the desktop market. Pause, take a deep breath. Yes, same exact thing as the desktop market. Sure there are differences down in the details, and that doesn’t mean that mobile apps are going to be exactly like desktop apps. The market forces in play are the same. Web apps mean easier distribution, faster release cycle, higher leverage on improving the base platform, decreased barrier to entry, etc. And a third time, same exact thing as the desktop market.

Does that mean that native application development is dead on mobiles? Well, do you use any native applications on your desktop? Most people still do, but you use them when it makes sense to have a native app instead of a web based one. The same thing should shake out in mobile. That just means that native apps should be used where having a native app delivers actual increased value. Which I’m sure is what the folks defending native apps are most afraid of, needing to actually defend their position in the face of competition. That’s going to be rough, they’re so used to having a captive audience.

The overall statement from Michael I agree with however:

If you’re a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website.

Yes, that you should do. Step back and honestly ask yourself “can I do this on the mobile web instead more easily?” The answer might be no still, but for an increasing group of people it’s going to be yes. Take into account the off-deck monetization models available with advertising (and I do hope direct monetization will enter the mix soon on a global scale) and distribution through either advertising or searches (Google is sucking up as many partners as it can get to make its service the default) and the overall environment available for direct to consumer mobile web apps is starting to look like a viable alternative even when compared to native app development coupled with carrier partnerships. Because the off-deck ecosystem benefits from more network effects than the carrier model we should see it keep rolling right along now that it’s started to tip.

Update: The conversation going on around this thread has been great, plenty of bright people with excellent points to contribute. If you’re following it make sure to also read these posts:

• Sounding The Death Knell For Native Mobile Apps
• On Mobile Applications, RIP
• Standalone Mobile Apps vs Web Apps on Mobile

Great Jon Udell interview with Dr. Joel Selanikio, lots of interesting mobile commentary in there. First two bits that really grabbed my attention:

Think about what you could do if you could give access to all the information on the Internet to anyone with a cellphone.

Amen to that. They’re talking mostly about SMS and base cell phone apps, but on the details I actually disagree. I think it is going to be the mobile web that becomes the defacto development platform on mobile devices. The web in a different form than we have now, but the high capability browsers we see on high end phones are going to end up on every phone soon enough. And this one, fantastic:

It’s kind of comical how Twitter is the hottest thing on the block right now and all these people with their 2 gigahertz computers and huge displays are sending each other basically text messages over the web.

Yea, “funny”, that’s really funny stuff. I love the way all the pundits switch direction without acknowledging at all just how totally and horribly wrong they were. Always gives me a chuckle.

There’s a bunch of great stuff in there from document formats that scale from traditional web use to use over an SMS channel to use of SMS as a general packet transport for richer applications. I want to take just one thread and pull on it a bit however, using SMS as a generic communications mechanism for higher level applications. They’re talking about it as using SMS to transport and stitching together the content transparently.

So first off, I assume the reason for this is that the networks in the regions they’re operating in aren’t at least GPRS capable, or the potential users of the systems are on prepaid plans where all they have is voice and text messaging. Took me a little while to remember that constraint might exist in Africa. Bad me, I should have been thinking more expansively to begin with.

Okay, so problem established. We want to make this work on the existing networks with the existing handsets. I believe that means that the programs that do this would have to be written in Java, otherwise it wouldn’t really be usable by those folks. What’s the Java support like in those handsets? I believe they would need a Java implementation that support JSR 120 for access to messaging APIs. And even if they have JSR 120 the only way to get access to the SMS stream is to listen to “SMS messages sent to a certain port”.

This part of the systems has always been very fuzzy for me, even though at one point I implemented a system that did send SMSes on different ports (we had the server that did it at a test site at Telecom Italia Mobile). I believe that most external hookups to telecom networks don’t allow for sending SMS messages from outside a carrier in to an alternate port. I assume that normal text messages sent to the end user have some reserved port for SMS, like port 80 on tcp is the standard port for HTTP. Can the SMS aggregators most of us go through send SMS to alternate ports? I checked the XML API for Clickatell and I don’t see anything. Is there an SMS aggregator that would allow for sending on an alternate port?

Or would we have to do this peer to peer somehow? Sending from a handset with an alternate port? In the JSR I don’t see client side sending exposing a port number either, it seems to be a server side function. And what if these messages would have to cross carrier boundaries? Would they retain their port number in the interchange?

The examples that I’m digging up seem to be distinctly non-end-user focused, I’m not sure the technique would really work out without carrier backing. Does anyone know what the details are around this stuff? Any good references out there?