Mike Rowehl: This is Mobility

Looking at the recent updates on maemo.org I noticed a utility for putting the USB controller into host mode. I had seen Kate’s post about modifying a standard cable or getting a USB On the Go cable to take advantage of host mode. So I didn’t expect it to work when I just hooked up my USB flash drive with the shipped cable and an adapter, but it did:

Here’s a shot of the df output:

Sexy huh? So of course the next thing I was wondering was if my 250 gig travel USB hard drive would work. No dice though. Even with a powered hub. With the native compiler, thats a great little standalone system.

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.

After my IUI Maemo Microb hackery the other day I started pondering making the browser lie to say it was an iPhone. More cause I wanted to hack around some with extensions and Microb than because I really find myself using iPhone sites all that often (though I will say that ShifD on the iPhone is way way more pleasing than it is on any other device).

I expected it to be no problem, there’s a Modify Headers extension for Firefox, there’s documentation about how to package an extension, there’s a working set of extensions to start from. Yet still I have failed.

Microb doesn’t support XUL, so I knew I couldn’t rely on the stuff for preferences and additional windows, etc. I just created a version of the plugin that held a static Modify user-agent rule to make the browser emit the same UA as an iPhone example I pulled from my logs. I loaded the xpi into my desktop browser, and sure enough when I restarted it was telling everyone it was as iPhone. W3wt! Used the instructions from the Microb site to package the extension, but there the browser behavior didn’t change. The extension wasn’t listed. I must be doing something wrong says me, how can I test this out?

Fast forward to some time hours later and way way into the wee hours of the morning. I’ve stripped out all the chrome, rewritten the install script, repackaged the browser extra packages to make sure things weren’t funky with my build system, pored over the adblock source, merged modify headers /components directory into adblock to get it to load that way, compared the installed files to my starting files, and attempted installing the extension by hand.

I know a hell of a lot more about Mozilla extensions than I did before, but I can’t help but feel much of it was in vain. Why do all these extensions work no problem on my desktop browser but fail to load on Microb? Is there a way I can get some kind of console or debugging info out of Microb? Should I be running Microb on my desktop when debugging these things? I would love to be able to just hack out Microb extensions on a whim. The way this worked out in my head was actually that I could have a few bits of pieces of stuff I liked to use and I could hack the extensions right on the device. Totally p1mp, I might even have to get a new velvet coat to wear while I do it if I can get it working. But my experience is running very counter to my expectation so far.

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?

I’ve been fooling around a bit with doing IUI dev on and for the N810. IUI is the javascript library behind those cool iPhone web apps. It does a menu style rendering and slides and all that. It actually works quite well on the Microb browser that ships with OS2008. Here’s one of my test pages for instance:

It renders well on the minefield browser at well, but navigation doesn’t currently work:

And kick ass, with VIM installed on the N810 hacking on the pages when disconnected even is possible:

That colorscheme is delek by the way, and I think it works great on the device.