Mike Rowehl: This is Mobility

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.

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

I have a problem with wifi routers. I don’t know why it is, maybe I abuse them too much. But I’ve gone through a few routers over the last year. At AdMob we had the same kinds of problems, wifi routers would just do odd things. They would just stop routing, or slow down to a crawl after a while. This one that I had at home last started “stuttering” when I connected to IM. It would stop routing packets for about 70 seconds when I connected to IM. I verified that I wasn’t crazy by running a ping to an external site from another machine while I connected to IM from this one. Sure enough there were a bunch of dropped packets right when I connected. Why? No idea.

Russ jokes that I have inverse technical ability - the more complex something is the more likely it is that I’ll get it working. And for some reason, the less complex it is, the more likely it is to cause problems for me. So naturally it would seem the right way to solve this simple technical issue of getting a base networking component to just route packets for me would be to make it more complex. So I was going to dig out one of my old Linux systems, put two network cards in it, and configure it as my router.

However, I also noticed that Linksys WRT54GL routers are on sale. The Linksys WRT54G was the router that folks hacked to run Linux, but then Linksys changed the design so that they could run VxWorks instead. The WRT54GL version is the old version, brought back by Linksys cause there was a lot of vocal support for the design from the hackers.

What’s this? A way to run Linux on my router using a platform and distribution system I’ve never even touched before? Well that’s sure to work! I just tried it out today, and it did:

Actually took less time to get this router working than it did to get the last commercial router swap working last time I decided to try a new bit of kit. Looks like Russ’s theory might have some legs.

I just signed up for the BarCamp Bank event in Berkeley next month. Not my normal venue, but I would really like to get a conversation going around mobile payments. In short, they don’t work. There’s point solutions here and there that allow a limited number of merchants to interact with a geographically segmented group of users, but nothing that works at the scale of the web. If 2008 is going to be the year of the mobile web we need a way for people doing stuff on it to be able to pay other people providing stuff. And it can’t be based on what carrier you’re on, and which handset you have, or if you happen to be in the United States. We need a global infrastructure for payments on mobile that works for everyone everywhere.

I’m hoping that with folks there looking at issues like social money, risk management and fraud prevention, and online operations maybe they can help us figure out how to crack the nut and get at something better than what we have.

Apparently the technology now exists to tell good espresso from bad, so I have some subjective measure to go on when I complain about these kinds of things. I don’t want it built into the coffee machine though, I want it built into my phone. So that when I got a horrid cup I can take the reading right then. “See, the bitterness is right off the scale here, you’re going to have to find me a new barista.”

While putting together the YouTube linking support on Mowser I noticed something odd. If I bring up a video from m.youtube.com while using the cellular connection in my N95 the flash player errors out before the video starts up, but if I connect over wifi the video plays through no problem. I don’t want this to turn into yet another carrier behavior rant, so I’m just going to ask if anyone knows why that would be and what I need to do to get that fixed.

For the last few weeks I’ve been helping out the folks at Skyfire with some bits and pieces of projects they needed some backup on. They have a new browser for mobile devices, initial release is for Windows Mobile devices, but they plan to add additional platforms before too long. See their blog for the official story. As Rafe reports the browser is proxy based with most of the logic living on the server side. The result is that the browser is as standards compliant as the base it’s built on (which is Mozilla), so all the normal settling time about corner cases of CSS support and Javascript pretty much go away. Hopefully folks won’t have to deal with the “how will my page render on this additional platform” question as web property owners.

However there are some questions from the mobile side they would like to answer but haven’t sufficiently worked through yet. For instance what information do you send up to the server to make sure you get back “the right page” for a user. We’ve gone through these kinds of discussions before around belligerent or hostile proxy activity.

But say you have the ability to render a desktop page on a mobile device in a way that was never possible before, and to do it across platforms. Do you identify yourself as a desktop browser and display the full version? Or do you mix in some info about the device and possibly get the mobile version instead? Sometimes content or downloads meant for your device are based on reading out the user agent associated with your device. If we send that along the original phone user agent (using something like the unfortunately named X-OperaMini-Phone-UA header) then site owners have to pick up an additional header to act on. And at times it’s hard to pick up the original user agent unless you can sniff it out during an over the air download.

In the proxy world the accepted proper behavior is to pick up the handheld version header and redirect directly to that. One possibility is to provide some UI elements that indicate there’s a handheld version available and give the user the option to switch to that.

It would be great if there was a way to pull together some of this different stuff (pickup up additional headers from proxies and browsers and proxy based browsers) so that developers don’t have to add new logic every time a new browser or service comes out. Until the overall questions are settled it’s hard to standardize, but then again code speaks pretty loud. I wonder if just making a set of rules and an implementation would be the best way to handle the proliferation of techniques. The specs and standards don’t really seem to address the root issue here. For instance the content transformation landscape doc from the W3C is aimed at a much different level - once you have some content how do you handle it. Where this is more of an identification issue, how do you properly represent what you are so that you can get the “right” content?

Looks like Eric Rice is experiencing some frustrations dealing with Nokia. Not the same frustrations that I had when trying to get my N95, but the theme is familiar. Nice to know I’m not the only one.

Good luck figuring out the answer to your question Eric, but also keep in mind:

• You’ll have to hack the config that the online Nokia configurator gives you for ATT if you don’t want screwed up images when using the built in browser. Screwed up images are, for some reason, the default.
• Firmware updates are a crapshoot, make sure you backup to something besides the memory card.
• Using the N95 as a Bluetooth modem under OS X works unreliably, it connects for a few minutes and then randomly disconnects. None of the solutions I’ve found online seem to work for me.

I was looking for a description of the PointingResolution attribute in the UAProf vocabulary, and I hit this:

Yea, yea, I know, it’s in the drafts section. Still, how funny is it that a document called Ontology Data hosted at the W3C would be unparsable? It would be slightly more amusing if it were called “Welcome to RDF, bitch.” But only slightly. It’s nearly perfect as is. I might have to take back all the bad things I’ve said about the W3C.