Mike Rowehl: This is Mobility

One of my favorite technology blunders has added another bullet point to their list of screwups. Apparently the Bluetooth folks have forced the BlueZ (Linux Bluetooth stack) folks to take down a list of hardware that works with BlueZ. I’m sure the Bluetooth folks would claim that they need to control the brand and ensure that “Bluetooth” and the Bluetooth logo are only associated with products that pass a rigorous certification process. You know, so that the consumer knows that they’re getting a high quality implementation and gauranteed compatability across manufacturers. It’s best for the community and the standard as a whole. God, it’s hard to say that with a straight face, isn’t it?

Nice thought, except that I have two devices sitting on my desk right now that both have “approved” Bluetooth implementations in their vendor supplied configurations that refuse to speak to each other. I’ve had numerous problems of quirks in connections with devices, connections that drop or degrade, devices that refuse to disassociate even though one side of the pair is gone, etc. So Bluetooth folks, your technology sucks anyway. Why not take the little bit of help you can get in terms of making a list of compatible devices and shut the fuck up?

OSNews has a great writeup of the open source browser for the Series60 platform that Nokia has been working on. I stand by my assertion that I would like to see more code to go along with the talk, but there are some interesting points in there. Such as the team choosing the KHTML codebase over Mozilla because of readability of the code in addition to the size requirements.

The minimap interface sounds interesting, although I’m curious to see how it works out in practice. It’s one of those things that I can see benefits and disadvantages for, and I’ll have to play with it for a while to see which factors lend the most weight. The availability of a plugin architecture is promising as well. I think the mobile web definitely has a lot of growing to do, and allowing for incremental updates to browser functionality could provide a step in the right direction.

Google released Gmail Mobile a little while ago, and I’ve spent a little time playing with it. Nothing really interesting there, but there are few quirks and points of interest. Yahoo also has a mobile interface to their email service, so there’s a nice point for comparison. To check out the Yahoo mobile version go to wap.oa.yahoo.com.

The first thing I noticed was that I couldn’t find a view that shows me my new messages, in either Yahoo or Google actually. Each gives an unread message count next to the inbox link, but neither has any visual cues for which messages are read and which are unread. Odd to say the least.

One of the things I like about Gmail Mobile is that they’re apparently using a permanent cookie for login. I logged in once and now I’m just always connected. Bad security practice for most general online services. But this is an interface that’s supposed to be used primarily from a personal device. It just makes sense that as soon as I select the Gmail bookmark on my phone it’ll go straight to my mail. Yahoo’s mobile portal requires me to login every time I visit the site. I could leave my browser logged in, but the 6680 I have just doesn’t handle that. With the browser running pretty much nothing else will.

The Gmail Mobile version also handles attachments well. It resizes images and will display them, that’s pretty neat. It’ll also render attached docs, I tried with a Word doc for example, into an HTML view you can access on the device. It seems to be a pretty decent rendering given the target too, ends up with a readable doc at least. Yahoo mobile mail unfortunately doesn’t handle the attachments at all.

We went over to the San Francisco edition of the Nokia 770 party. It was a very small event, so I had a lot of time to talk to the Nokia folks who were there. I’ve been doing Linux embedded systems programming for a long time so I was really jazzed when I heard about the device. I’ve been impressed by what I’ve seen so far in playing with the 770, and I was hoping that this is just the start of a major forray into more open platforms for mobile and special purpose devices. Everything I heard at the event indicates that Nokia very much views this as the start of a learning experience about this new device category and platform ecosystem. Creating a device based on an open source operating system with a thriving developer community is certainly going to be different than creating devices based on Symbian. There are lots of benefits and pitfalls on both sides, and going forward successfully is going to require carying learnings from the different environments back and forth without making too many assumptions. My biased opinion is that Linux will start appearing on normal handsets as soon as Nokia and the community fully grok how to work together. And it’ll appear in a real natively user extensible form rather than the “host for a Java sandbox” versions that are out in the market now. Please, oh God please let it start appearing on handsets!

Of course, there was a lot of talk about the multimedia functions of the device. The Nokia folks there very much had the vision of the device as the control unit for a cloud of digital entertainment systems pulling content from the Internet. Lots of talk about new models for media, how to respond to the decoupling of content from broadcast channels, support for different standards, and digital rights management. Also a lot of talk about the browser, probably because I brought it up. There’s always a degree of push and pull in mobile solutions between “always on” connected devices and syncronization. Should information live on the server and be accessed on the device as needed? Or should it be pulled down to all the different locations in which it’s used and consolidated using discreet actions? I’m not going to try to lay out all the arguments on different sides, it’s definitely a complex issue. But if we’re going to see “always on” style services I think that evolving the mobile browser is going to be one of the keys. It makes sense to let the information live online in some contexts, but only if access to it is ubiquitous and fluid. Kludgey interfaces from the mobile make having the information online almost as much of a hinderance as not having it at all. The mobile browser has to provide an interface that can be as functional as a native app, as friendly from a UI perspective and as responsive. Custom applications to access the data just really don’t qualify in my book. The browser for the mobile has to mold itself to the same web as exists for the PC, or vice versa. With way way more users on the mobile side… why isn’t the mobile web driving the wired web instead of vice-versa?

Texas Instruments is shipping a DSP System On a Chip with Linux support for abstracted DSP interface. The article, and TI and MontaVista apparently, are talking about the video applications. I would think this would go a huge way toward getting Linux on mobile phones. The core of a cell phone is a DSP, and the way to deal with this in the past is normally separation between the generic processor core and the network interface. That really put Linux on an unequal footing with the operating systems which were meant to drive mobile devices however. This seems like it could provide a great way for Linux to penetrate further into the marketplace without extreme constraints.