Mike Rowehl: This is Mobility

Gregory and Matt invited me to participate in a developer focused pre-event session on Thursday right before MobileBeat 2008 kicks off. The session is going to focus on the evolution of mobile operating systems and services platforms.

It should be interesting, cause in general I think the services platforms are a load of junk, and mobile operating systems are generally moving in the right direction. The services platforms are fundamentally mismanaged and misaligned efforts to try to replicate the success of user generated content from the web and apply it to application development for mobile platforms. Generally they seem to be shiny trinkets to dangle in front of business folks to make them salivate over addressable audiences, but I know of very few successes running on top of any of these platforms.

Compared to say something like GetJar, on which I’ve heard good feedback from both existing businesses and entrepreneurs looking to bootstrap distribution. The iTunes App Store could be the counter example, but I think it’s too early to know for sure. Too bad the iPhone as an overall platform isn’t one that I would pick out as a real boon for developers, generally closed off as it is. Still, everyone seems to fail their saving throw vs. shiny when an iPhone shows up, so they could have at least a sustainable success going there.

Should be a great discussion. If you want to attend make sure to contact Jacob as described in the post. Even if you have a ticket for MobileBeat, this is a different deal. The folks at MobileBeat need to know how many folks are going to drag themselves out of bed for a 9:30am session. This is a developer focused session after all, that’s like 6:30 in the morning in real-people time. Hope to see you there!

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.

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:

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.

There’s a whole bunch of noise about the LiMo Foundation and comparisons to the Google Android project and the Open Handset Alliance. That’s cool, I’m happy there are people taking a look at both and poking around and trying to figure out how to make things better. But right now I don’t really care.

I don’t care because LiMo doesn’t seem to be an open source project at all. It’s a consortium meant to steward communal intellectual property and license rights. Just a quick glance over the open source definition and then the LiMo website should spark thoughts like “Hey, where’s the source code?” and “What’s with all this talk about membership?”

I’m not saying that LiMo isn’t a great effort. It might drive down the cost of manufacturing handsets and drive significant innovation back into Linux. But the project is really aimed at device manufacturers. They’re trying to bill it as a savior for consumer application developers as well because it supposedly standardizes Linux, but until the devices are out in market and I see some numbers that’s going to be a really hard case to make to me. Show me the code or show me the install base. Don’t claim open source without any public code and claim an end to device fragmentation without significant units in the market. I’m going to assume you’re just bullshitting.

I tried out JoikuSpot yesterday for a while. It’s a bit of software that turns your Nokia phone into a Wifi access point using the cellular connection as the backhaul. It worked perfectly!! I have a 3G N95, so the connection is very fast. No setup at all, I just installed it and started running it, told it to connect to cellular for the backhaul, and it started broadcasting an ad-hoc access point SSID I was able to connect to from my Mac. Sweet!!

The first page I brought up was actually redirected to the JoikuSpot homepage, but that’s just a flash screen. Connections after that go through as they should. Pretty sweet if you’re out somewhere with a bunch of geeks and everyone wants to check their email or scan their blog comments right in the middle of some other outing. That never happens though, right? Especially not in the Bay Area, where everyone is well adjusted and normally socialized.

Another cool thing, my MacBook stayed connected and constantly using the connection for 45 minutes using the wifi bridge. I’ve yet to get the Bluetooth modem scripts for my Mac to stay connected consistently for more than 15 minutes at a time. W00t!! So this might become my new defacto access method. Or does anyone out there know the magic settings to keep pppd from barfing every once in a while when connected to the N95?

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?

I’ve been using VLC to convert videos for my iPod for a while, but recently had started having issues. Like one video stops playing after 45 minutes of an hour and a half long movie (something I discovered while on the road trying to watch it, very frusterating), others fall out of sync between audio and video even though they play fine when played on my computer, and others get into a loop some ways into playback with either the audio or video stuttering until I turn the playback off.

VLC still seems to be one of the recommended ways to consistently convert videos for iPod usage though, why is no one else having issues? I made sure I had the most recent version of VLC installed and tried to convert the videos again, and had either similar or at least equally frustrating issues. Then I figured maybe it was an odd quirk or the OS X versions, so I took the videos over to my nice fresh Ubuntu system and did the conversion there. Still no dice. I even went and installed the Medibuntu repositories and let it upgrade anything that could be even vaguely related. Still ended up with files that didn’t run through all the way.

Finally I ended up giving iSquint a try. It runs ffmpeg underneath it looks like. And sure, it’s pretty naggy about trying to get me to upgrade to some paid version of the software, but at least the videos it’s created so far play all the way through.

What are other folks using? Say you have a bunch of vidoes downloaded from the internet that you would like to be able to watch on the go, how do you do it. I used to go for downloading them from video.google.com if there was a download for PSP/iPod option, but that feature seems to be screwed up pretty frequently recently. iSquint is nice, but I want a command line converter. Should I just dig out the right options to use for ffmpeg and run it myself? Last time I checked ffmpeg supported a lot fewer formats as input than VLC does, which was why I switched in the first place. Or is there an “iPod happy” version of VLC floating around that I just haven’t run across yet?

Luca recently announced the availability of a public WURFL database site that contributors can use to propose new devices or modifications to WURFL. Managing the large dataset that makes up WURFL has been a problem, so Luca is trying to open it up to the community and allow folks to submit proposed changes directly on the site. There’s information on the site about how to become a WURFL contributor and what’s expected.

I’ve seen a lot of folks complaining about the WURFL submission processes in the past, saying they wished it was more of a community direct participation effort. Hopefully they’ll follow up with some submissions now that it’s heading that way. There are a few things that would go a long way toward helping with the process I think:

Overall I’m just really happy to see the process opening up, great job Luca and crew!

Version 1.1 of the LightSabre application for N95s is out. You need to also install the accelerometer plugin on your phone otherwise the LightSabre application just does nothing at all when you try to start it. Now I can be a Jedi knight. If I had known that my initial review of the phone would certainly have been more favorable. The council must have been testing my patience, I always fail that test.

One of the things I’ve started doing for “send to my mobile” is using del.icio.us to do the bookmarking from my desktop browser and subscribing to the RSS feed from my mobile. I bookmark stuff and tag it “mobile” when it’s something I might be interested in coming back to and reading from my phone. Both the Nokia browser built into the N95 and Opera Mini support subscribing to RSS feeds, so it’s a great way to move stuff back and forth. I was going to say “Would be great if there was a way to optionally wrap stuff in Mowser on display”, but then I realized I should just add a modified version of the bookmarklet to Firefox so that I can opt for transcoding then instead:

javascript:location.href=
  'http://del.icio.us/post?v=4;url='+
  encodeURIComponent('http://www.mowser.com/web/'+
  encodeURIComponent(location.href))+';title='+
  encodeURIComponent(document.title)

Not as clean, but that’s pretty workable.