Vote N810 for “Handheld of the Year” at Engadget

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.

Native Mobile Apps vs Mobile Web Apps

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:

Mobile Applications Commentary

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?

IUI Dev on OS2008

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:

IUI sample page on N810

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

IUI sample in minefield

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

Editing the test page

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

Microb Spellcheck Extension

Some of the comments to my previous posts about Firefox mobile pointed me toward the packaged extensions to the Microb browser, which is the default browser on the N810. One of the extensions is a spellcheck extension that underlines misspelled words right in a text area. Fantastic! Now I can blog from my device without fear of looking like a complete eediot cause I spell worse than a 4th grader. Now if I can just find extensions to correct grammar, poor sentence structure, and boneheaded predictions and market analysis.

Random Mobile Web Stuff

Riding Caltrain home earlier I had a hankering for some new fiction, so I thought “this would be a perfect chance to poke at the Amazon mobile site and get Singularity Sky.” Geeky huh? I have to say I don’t like it. There’s just one item staring me at the face when I visit, not something I’m interested in. So I think maybe it’s some quirk of mobile user behavior, that they’re getting way better conversion rates with just one item on that page. SO I sign in with my account and nothing really changes. There’s no real exposure of all the magic that makes Amazon interesting on the mobile web side. Too bad. And then to top it off, after I just searched out the book I wanted:

Amazon Mobile

Aww man!

On the other hand, I was fooling around with the sharing features that Taptu just released. You can suck in your contacts from Gmail or setup your Twitter account, and when you find a page of Taptu results you like you can send it to someone. Yay! Now that I do like! The UI is slightly funky though. To actually post the twit you click on myTwitter, which is probably something that was defaulted somewhere but I missed it. Would be nice to have a “post” or “send” button that looks more like an action on that form. I like it though, great job!

The Effects of Unbundling Mobile Distribution

Sounds like there’s some interesting discussion going on at GDC. I liked the summary from MocoNews about the end of carrier control in gaming. It’s an excellent example of one of the positive benefits that comes out of having the mobile web look more like a web than a bunch of standalone content silos. I wanted to call attention to this bit in particular:

Who says you have to support 1,000 handsets from the start? How about 10 and see what the uptake is? Suddenly, you have all the options that weren’t available previously.

First of all cause the idea itself is worth pointing out – that distribution through the carrier often came with a required list of porting targets and you had to hit all of them. It was a pretty cumbersome requirement to go along with distribution. The ability of the developer to pick and choose targets as they go along is great news. But it also means that niche use spread across large areas also becomes possible. An application that appeals to 5% of mobile users was something that any single carrier would never go for unless the return per user was astronomical. Even if the worldwide number of users was large (5% of the worldwide mobile using public is a lot), there was no way for the app developer to reach that user base through carrier deals. Unbundling access to mobile users by hitting them via other distribution and discovery mechanisms makes those kinds of applications realistic again. I like it!

However, the flip side to this is thinking about why the carriers put those porting requirements in there in the first place. They didn’t do it to be jerks, they did it cause they wanted to deliver a consistent experience to as many of their users as they could while not bearing high support overhead. I don’t agree that was a great way to handle that problem, but it does point out an interesting area. What’s going to happen to customer support and consistent user experience in a post-carrier-dominated world? Who do I call or what do I do when an application I downloaded yesterday starts behaving badly or I can’t figure out how to configure it?

I think long term the answers to those questions should mimic the way these things are handled for PCs. The attempt to try to control the whole system of mobility from network to handset to user application resulted in the system we have now, and the whole thing needs to be supplanted with something more expansive. There’s a few things that probably go into that. There’s probably some degree of communal mobile user knowledge that needs to evolve. It exists for desktop systems, though for lots of us it’s so ingrained by now that we don’t see it. Users know what an email address is, they understand that when they install an application they should look for it in the start menu if they want to use it, that when they want to save a web page to use it later they add it to favorites, etc. Common user experience, frequency of tasks, shared understanding, and common sense all combine to make the stuff that people do frequently seem simple. And I don’t just mean “user education” here. I mean application provider and handset manufacturer education as well, cause it’s a two way street.

For an example take a look at the way that iPhone usage has pushed mobile to a different level. What happened with the iPhone was that the market potential for the device wasn’t set by how well the carrier could push services out to the end users. Instead, Apple decided what they wanted the phone to do, designed it the way they wanted it to work, and then marketed those functions directly to end users. Compare the iPhone commercials to the kind of stuff that Nokia makes to describe their products. Very different stances. But it’s not just the marketing, it delivers on what it says. Using the web on an iPhone is simple and intuitive, using the maps app is the same. It wasn’t designed by a committee, which is how a lot of the current phones on the market feel. It was designed with a strong and consistent hand guided by the practicality of the end user, not a reduction in support call costs. And the difference is obvious top to bottom.

I’m curious what else is going to come around and what else changes in this version of mobile. Are the rest of the device manufacturers going to follow suit and rethink their devices now that Apple has shown that it can be done different? I think so, which leaves the door wide open to get more open platforms into the mix. When I bring up OpenMoko frequently I hear responses from people that are tied to the “accepted knowledge” from that old environment. But I think it’s been proven that a single vendor with a strong vision, consistent implementation, and messaging to the end user can make a difference. So really all the arguments against a major disruption in the mobile devices market are pretty well voided at this point. And we have so many efforts lowering the bar for getting a new device out in the market. That could get really interesting really soon.

Linux Router

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:

OpenWRT login

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.

Poking Around in the Minefield

After getting an initial version of mobile Firefox (currently called minefield) compiled and running on the Maemo SDK, I compiled a version for ARM and put it on my n810:

Minefield on the N810

It’s definitely a very early effort, like all of the pages say. It’s not even a release yet, just a hint of things to come and an attempt to start the effort rolling along. I’m actually impressed that it worked out so well. I was able to build the code for both targets, get it installed, and poke around some. It loads pages, settings work, extensions work, tabs, session saving, etc. All told, fantastic for what is effectively a rough port of the desktop version with few tweaks made.

I installed Greasemonkey to poke around some. I’m just really interested in there being a user contributed set of hacks to get existing web content to work on mobile devices. This seems to provide an excellent way to fool around with that concept. I tried out a few user scripts and they do work, although I had a few crashes here and there while fooling around. It’s still an early effort, so no surprise there.

This whole thing has me really excited. I wasn’t sure what to make of the announcement that there was going to be a mobile Firefox somewhere down the line. With so much momentum behind the Webkit based browsers I wasn’t sure if Firefox was going to be able to make a dent. I’m happy to see working code and an early demo, nothing gets interest for an open source more than a working set of code. Fantastic, this just might work out yet.

One of the aspects that I think is a huge deal is that Firefox is actually open source. When you look at the Nokia open source browser (like that included in the N95) and the Safari browser in the iPhone they’re both based on the open source WebKit project. However, they are not themselves open source. WebKit includes the guts of the web browser (HTML parsing, CSS, rendering engine, JavaScript, DOM interface, etc) but that’s not all that goes into a browser. So there are proprietary bits of code that go in with WebKit in order to make up the browser on my N95. The result being, I can’t decide I don’t like the way my N95 works and get in there and hack up a new version of the browser that suits my taste. With the mobile Firefox browser that will be the case. And I’m hoping that a genuine open source browser on the mobile end will catalyze innovation in the client the same way that having an open source desktop browser has kept things interesting in that arena.

Now if only I could get the browser compiled for a device with a cellular interface in it, or get a Maemo device with a cellular interface.

Walk Through Minefields

I got networking going in my scratchbox install and was able to build my own minefield 1.9 Mozilla and get it talking to the intarwebs:

Mozilla Minefield OS2008

Pimp, I know, you’re jealous. Turns out Brad is way more pimp, and actually had debs packaged that I could play with and all.

I actually found his stuff before I did this, but I wanted to figure out how to build my own so that I could hack on it a bit. Unfortunately the extension developers extension didn’t install cause it doesn’t “provide secure updates”.. whatever that means. But Greasemonkey did:

minefield_greasemonkey

I know, it’s hard to comprehend. I’ll give you a bit of time to catch your breath, I’m getting all excited myself.