Mike Rowehl: This is Mobility

Inspired by some screenshots that came through my feed reader the other day, I updated the firmware on my N810 and installed a few new bits of hackery:

Those are transparent homescreen apps, and more important than looking slick (if that’s possible) they’re written in python! Homescreen hackery here I come!

Getting the packages installed is a bit of a pain. They don’t one click install unless you install two packages by hand. I had to download python-hildondesktop and hildon-desktop-python loader from this site in order to be able to install and use them. And yes, download and install manually, the app installer doesn’t like them. Download them to your tablet somewhere, become root (I do that with an ssh to localhost myself), and run dpkg -i for both of them. Then you’ll be able to install the actual applets and enable them. w00t!

There’s a talk from Alex Russell about mobile web development up on IT Conversations. The title of the talk is “AJAX and Mobility”, which is actually misleading (as is my own title, since Alex isn’t really a Javascript developer only, he’s got experience all up and down the stack). He’s actually cautioning against going toward AJAX on mobile devices, having solid base primitives that really support the unique capabilities of a mobile device are way more important than trying to replicate AJAX.

His commentary is right on, and refreshing to hear it coming from someone who does a lot of Javascript online right now. Sometimes I think I’m insane for saying the mobile web isn’t ready for AJAX if the base functions don’t work yet. Maybe I’m being too conservative and I’ve somehow missed the boat on a new iteration of engineering on the Wild Wild Web. Maybe I’ve gotten too old. But then you see a few great new efforts flame out under the weight of their own development process and user base, and reality start to creep back in. Seeing an experienced developer or two express the same sentiments helps ease my nerves as well.

If you think I’m full of hot air for saying some of the things I saw, try out Alex’s take instead. His points about not having a reusable endpoint for application service on a phone is interesting. You have a phone number for voice and SMS, and you have a URL for web services, but there’s nothing really the same for installable applications (not yet at least, this is one of the reasons GetJar is interesting). I also thought his list of features the browser needs to grow directly were very interesting:

• Access to location information
• Access to the voice channel
• Access to the camera
• Access to contacts/address book

I keep hearing that list over and over again. Frequently the reason stated for not including the stuff is “security issues”, which is hard to argue against because so many folks currently would gladly give up tons of freedom in exchange for a little safety. But there’s no real reason for that. If I as a user want to send my location information to a service the system should allow that, and claiming security as the reason not to provide it is just a cop-out.

The point I disagree with Alex on is open source in mobile making a difference. I do see potential for folks like OpenMoko and the Firefox Mobile effort to really shift the playing field. If for no other reason than they can provide platforms that fix those four deficiencies in current mobile browsers. And once the mobile web is really setup to be able to win, things will tip in that direction. Users will bother to download and app and keep using it if that app is a genuinely advanced browser that gives them access to a whole bunch of other applications out on the web. Users will get a handset so that they can share their data online the way they want if the applications are out there to do so. I see open source as the only way to bootstrap that process. The carriers aren’t going to do it, existing manufacturers aren’t going to do it, and web app owners can’t do it on their own.

Listen to the first question from the audience too, it’s a gem. Some guy asking vaguely “On Windows Mobile with a GPS you can already use .NET to expose an interface to Javascript you can use from IE, why does location need to be built into the browser?” Ah, the world of mobile. Some people are just so beat down they’re completely incapable of thinking through anything new.

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.

I was somewhat curious how the new Wordpress 2.5 admin interface would play with the browser on the N810 so I spent a little time poking around. Even though the new interface seems to be a lot more squishy than the previous version, it actually seems to work a bit smoother on the device. I like Maemo Wordpy as well, but it’s nice to be able to go in and do stuff like make sure a sudden spam surge hasn’t completely overrun my comments when I’m on the go.

While I was in a testing mood I poked around with some of the Google apps as well. The search, calendar, maps, and mail apps (as well as a few others) have bookmarks loaded into the browser by default. But I wanted to play around with the reader and the iGoogle homepage. The reader worked pretty much as I expected it to. The fact that it worked at all was great, but it was a bit slow and some screen elements overlapped each other. The kind of thing that might benefit from a bit of Greasemonkey hackery.

What I was relatively surprised by however was the iGoogle version of the homepage. All the controls worked well, even dragging around modules to change the layout. The layout is dense and efficient, I can add calendar and gmail apps in there. I added a weather app in there and then was about to pull it back out cause I already have OMWeather on the desktop of the device. But then I realized iGoogle is actually a better homescreen for the N810 than the device native applet based homescreen is.

When using the RSS reader applet on the N810 the only option is to put a blended list of every item from all feeds I’m subscribed to. No way to pick and choose and select just individual feeds or a single feed to display. The font is ridiculously large and the only options for reading are punching out to either web or RSS app, no expand in place. The same goes for the email app built into the device, just overly simplistic and at the same time fragile when compared to the other apps like Claws mail (but AFAIK Claws doesn’t have an applet to go along with it). Compare that to iGoogle configured similarly. The information density is much higher, configuration options a lot richer and more flexible, and there are just more options there for existing widgets. It’s an excellent example of rising browser capability allowing online applications to displace native apps, even when those native apps have direct operating system level support on a mobile device.

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.