Mike Rowehl: This is Mobility

Lets say you find yourself in possession of a nice new Treo 650. You’re no slouch. you’ve owned just about every form of PDA that’s come down the line. You know cellular well enough to sit up and pay attention when someone says EDGE, and to start drooling when informed that UMTS is available in your area. Your idea of bling is getting your device signed by Jeff Hawkins. So of course you can’t have just the standard list of applications on your Treo. You need the kind of application list and demo potential that will immediately establish your dominance as the alpha geek you are and send the lesser geeks scurrying off for their sync cables. Here’s my list of ultra geeky stuff I’ve thrown on my 650 in preparation for the countless showdowns that seem to happen whenever some hapless person asks “so what do you use that thing for anyway?” at the Mobile Monday meetings.

Before we start off at all, let it be known that you will need an expansion card. Hard to say if it’ll be for documents or audio or video or applications. But you will need one, and probably pretty soon after you start throwing stuff into memory on the device. Like many of the Palm devices before it (and completely unlike the Clie I currently have, grrr) the Treo takes both Secure Digital (SD) and Multi Media Card (MMC) formats. So what kind of card do you want to use with this thing? The first misperception is that the Secure Digital cards will somehow make your data more secure than Multi Media card. Not true. The “secure” part of Secure Digital applies to content put onto the cards when they’re used as a distribution media. It’s DRM, and therefor it sucks. It does absolutely nothing for you, and will actually keep you from doing what you want in some cases. I get MMC instead of SD when all other things are about equal specifically to voice my opposition to DRM.

There is another reason to go with MMC if you use lots of gadgets. Newer phones and some cameras have started using something called RSMMC (Reduced Size MMC, it’s described in the Wikipedia article). No one really needs another format, so that’s kind of a pain in the ass. But at least they threw us a bone in that RSMMC cards can be snapped into a little adapter and used in normal MMC devices. That’s decent enough. And if you do use a bunch of devices it might be worth it to get the more expensive RSMMC so that you don’t have to get another card when you do start using an RSMMC device. Got it? BUT WAIT! Of course, now that we’re getting close to an obvious answer for the alpha geek multigadget folks, it can’t be that simple. Nokia has thrown in another twist. For some reason they decided that the physical compatibility available with MMC/RSMMC was an evil that needed to be dealt with, so they went out and broke electrical compatibility. Yay! I was really afraid that I was going to be able to use the same media format in more than one device, so thank you Nokia for putting those fears to rest. Nokia have introduced the Dual Voltage Reduced Size Multi Media Card (DV-RSMMC). Groan. Eyeroll. As you might expect, the format is backward compatible, but not forward compatible. If you have a DV-RSMMC you can use it in a RSMMC device or with the adapter in a normal MMC device. However, your normal RSMMC card will not work in some of the newer Nokia phones (such as the 6630 or the 6680, two devices you’re pretty likely to run across if you run with the Nokia pack as well). So the answer would seem to be getting the DV-RSMMC, but there are two problems. One, the DV version can cost more than twice as much as the standard version. Two, up until just a few days ago the largest size DV was 256 meg, and it’s still only 512. I’ve seen RSMMC in sizes up to 1 gig, and there might be bigger for all I know. So take the two times multiplier in price, limited availability, and current limit in overall storage capacity and you’re back to making a real value judgment. I went with a large RSMMC, it was relatively cheap and I was able to walk in to Fry’s and get one off the shelf.

So what is one to put on this neat little device bristling with unfilled megs of storage space? One could purchase all kinds of software from one of the online stores, there are literally thousands of titles spread across the different commercial online Palm stores. Yawn. Not my style. I recommend one of the Palm open source sites, like the aptly named PalmOpenSource.com for all of your code and coding needs. Here’s a bunch of stuff that I either had on my Clie and have moved over, or picked up recently.

FileZ actually isn’t open source, it’s freeware. But we’ll forgive it that shortcoming because it’s such a useful application and really a base requirement. It allows you to view a list all the databases in the built in memory and the files on the expansion card, get information and attributes, sort and filter, move, copy, or delete. Basic filemanager functions, for some reason not built into the Treo but definitely essential. The document reader of choice is Plucker. Plucker uses an optimized compressed document format, which is another way of saying “no, you can’t just transfer documents over from your desktop.” For Plucker it’s worth it however. Lots of content meant for the PDA is already available in Plucker format (open source projects do make their docs and readme files available in Plucker format frequently). And there are a bunch of Linux friendly tools available to convert files to Plucker format and crawl web sites to generate snapshots for reading offline. They have a bunch of interesting stuff in the samples area of their site if you’re looking for something quick to try out. Sites like MemoWare provide fantastic catalogs of free documents if you’re looking for content instead of generating it.

The most recent addition to my list of programs is TCPMP, a multiformat media player. It handles a bunch of audio and video formats. A lot of the video content I pick up off the net ends up being AVI, and I’ve had fantastic luck with that so far. Video has a lot of wow! effect even with the nontechnical crowd, so it’s just good stuff to have around to show off. And it works well as a podcast player as well, with support for mp3 audio content. I’m listening to a lot of audio on my daily trips on Caltrain, but I haven’t used it for long enough to get a feel for how the audio player impacts battery life. It does support background playback however. Startup a file and press the power button, the screen goes off and the audio keeps playing. The LCD is really the big power drain in Palm devices, so playing back with the screen off should buy you a lot of battery time. And speaking of commuting, for those in the Bay Area you’ll probably want to grab Caltrain+ and Quickplanner. Caltrain+ is a Caltrain schedule, and Quickplanner is a BART trip planner. Simple, but extremely useful to have. And finally there’s pssh for the time when you absolutely positively MUST SSH into some system right away. For some of us that’s pretty much a daily ocurance, so this is an extremely valuable tool. My personal favorite experience was SSHing into my server using pssh so that I could compile the palm chat application I was looking for and then moving it out to my public server so I could install it over the air. An excellent reason to do the happy dance. I’m not sure why they haven’t added a related question into the geek code, major oversight in my opinion.

Okay, all those are great tools and applications, we had a little productivity, a little entertainment. Now it’s time for some pure and unrefined nerditry. Welcome to on-device development tools. We’ll start off with my personal favorite, LispMe. LispMe is a scheme interpreter with extensions for the Palm platform. You can actually script up GUI applications, although you have to generate the resource files outside of the scheme environment. It does have sockets support, so scripting up little network apps is a cinch. LispMe has been around almost since the beginning of Palm time, fantastic app, but I would still replace it with Pippy in a heartbeat if Pippy were just a bit more up to date. Pippy is Python for the Palm, but it’s based on a very old (1.5.2) version of the language. Compiling the system and getting it working requires very specific versions of the Palm compile tools and a host system version of Python 1.5.2. The project is old however, and seems to be stalled. With all the geeks picking up 650s I’m really surprised no one has thrown down yet and picked up the project. Nokia has Python for the Series 60, it would be dead sexy if Python could be a cross platform dev language for mobile devices.

Right about now some of the old school hackers are saying something like “You people are all spoiled. Running dynamic languages on systems with megs and megs of storage space and more processor cycles than I can shake my walking stick at!” I’ve always had a soft spot for those guys. I do a lot of embedded systems work, and I got involved with personal computers when they did have just a few kilobytes of RAM (two kilobytes if you want to be precise). So I understand the yearning for the good old days when you flipped on your system and you were presented with a usable interface running out of a few K of prom. Fortunately when that urge hits you can just fire up Frodo and hack away on everyone’s favorite 6502 based micro. Frodo is a Commodore-64 emulator with support for saving multiple sessions and loading up disk images. The keyboard support used to be a little lacking on my TG50, but on the Treo it works fantastic. Finally, there’s the project that should not be. The Frankenstein monster of the development options - the OnBoardC suite of tools. Yep, that’s right. OnBoardC provides a C compiler, assembler for m68k, and a text editor app. All running on the device, so you can hack on the code, compile it, test it out, and end up with a real honest-to-goodness 68K palm application needing no support libraries or runtime environment. Unfortunately most work requires a commercial resource editor, but most of the time you’re not starting an application from scratch if you’re playing with OnBoardC. The toolset includes some host side scripts so that you can package up GCC or Metroworks based projects and work on them on your device when you’re on the road. The SrcEdit editor is a pretty decent general tool on it’s own as well, reading from and writing to a common Palm format called simply Doc. Apparently the world was a much simpler place when they came up with that name.

This isn’t a complete list by any means, just the stuff I happen to have with me most of the time. There’s a ton of stuff out there still. The Palm environment used to be a thriving ecosystem of open innovation and sharing, and I thought it was destined to become as widespread and strong as the Unix culture. Lately it’s been pretty dead however, and the old freeware and open source sites feel more like abandoned strip malls than hotbeds of innovation. Palm has a chance to get back into the game with the Treo 650. PDAs are a small and saturated market, but phones are seeing fantastic growth. If Palm can recapture the minds of developers the way it did with the early models of the Palm Pilot and ample support for the open tools used to hack it I think they could start making waves again.

These are some notes and comments based on the “No Mobility Solution is an Island” talk given by Klaus Seibold from Nokia during Mobile Enterprise 2005. He used the acronym REAL to frame the components of mobile solutions - Roaming, Economical, Ad-hoc, Life improving.

Roaming means not just roaming to different networks and different countries, but different technologies. GPRS, Bluetooth, 802.11. I thought that was a great point. It’ll be hard to get the carriers here in the US to see the value in that, but I think the vision is sound with the stipulation that roaming must be completely transparent to end users. People won’t and shouldn’t have to understand the underlying infrastructure. It should all just work. There was some talking of tying into existing PBX infrastructure. Yawn. I almost tuned out a great point he had about the positioning of mobile applications in the enterprise because it was buried between talk of PBXs and Websphere. He said that mobility isn’t a layer that you spread over a bunch of existing services, you need to build services that reach down and touch all the different nuances of the environment they’re deployed into. Only by respecting and adapting to the existing infrastructure can the mobile solutions create value instead of driving efficiencies. W00t! Nice. Don’t drive efficiencies, create new value. If I had a single point to draw out of all the sessions for everyone doing mobile enterprise solutions, that would be it. I might make that my new mantra. After we disrupt the telcos in the US maybe. I can only fight three wars at a time, and my plate is already full.

A lot of his presentation was focused on the enterprise, that was the theme of the conference after all. He spoke in particular about becoming the standard solution for enterprise email. Saying that the key was offering choice, one size doesn’t fit all. Multiple technologies, multiple client styles, multiple device options. In particular he put up a slide with the series 40 full keyboard models (such as the 6822) and the series 80 communicators (like the 9300). Anyone somewhat familiar with the Nokia line, and listening to his pitch about choice being the key, would say “what about a choice for full keyboard from the series 60 line?” Series 60 devices are the most popular, but there’s no device available with a full keyboard. So of course I went to go pester Klaus after the presentation and find out. He didn’t think it was an important choice though, and pulled out his communicator to illustrate how it was a great form factor. That’s nice and all, but it’s not the device style people out here in the US are exactly snapping up in droves. You wanna be defacto standard for email? How about a device from the standard price range and functionality suited to the task? That’s my free tip for the day.

Russ and I sat down with Charlie Schick and Christian Lindholm while we were over in Helsinki. It was a great conversation, most of which I spent just trying to get a word in edgewise around the sparring that Christian and Russ were doing regarding some of the new Nokia handset designs. That’s a post for another time though. One of the topics we spent a while on was from a post Charlie has called Mobile was nowhere at Les Blogs - why? The question boils down to the use of mobility in cutting edge innovative applications. Mobility is obviously an area that can deliver a lot of benefit if merged into an application offering, why aren’t the folks in the innovative startup environments doing it more? I don’t think it’s because there are few people out there who can bridge mobile and web environments. I’ve done a ton of work in both, and I still run into people at every single MoMo meeting who follow the trends more closely and know the details better than I do. The folks are out there who can bridge, they’re just not doing it. For good reason.

The primary issue is that carriers are not innovators. They actually fear change. They’ve grown an immune system to defend their working system from outside forces. They have a profitable model as it is, providing mostly voice services. They might be able to expand out into other services - but that would mean ramping up support and sales for those new services, figuring out what the impact on the already overloaded networks would be, and risking an investment for an uncertain return. Normally the market system in the US takes care of that kinda crap. The technology company who sits still gets rolled over the the nimble startup who provides the users with a new valuable product or service. Unfortunately not just anyone can startup a cellular service provider. With all the spectrum owned by the existing players there’s no one to come in and compete to act as the disruptor. So even if the startup folks wanted to deploy a new service or set of features that could be making the carrier a ton of money it can still be hell dealing with the carriers.

“Screw that!” you might say, “just go around the carriers! Put a service out on the Internet and let the users find it. If you have something compelling enough you don’t have to go through the carriers to get to the users. Just like back in the early days of the Internet.” Great idea, but the carriers thought of that already, and unfortunately even that can be prevented. Leaving aside the issues of starting a viral marketing campaign for a new product using mobile devices, it can still be technically infeasible to attempt to deploy an application. Some kinds of systems, like BREW, will keep users from getting your content or application unless the carrier approves it (read: “unless the carrier profits from it”). In order to provide messaging from one world to the other (mobile to Internet or Internet to mobile) requires explicitly going through gateways, which is a pain in the ass for the service provider and frequently cripplingly complex for the end user. They remain different worlds because the carriers like to keep them that way.

If there was a way to hack on applications that bridged the worlds I’m sure there would be a ton of it going on. But right now the only way to get an application up is to prove to the carrier that it’ll make money and then cut them in on some of it. Or pay a ton of money so that you can use a gateway to message into and out of the mobile world. These are all disincentives to experimentation, hacking, and innovation. The advances aren’t going to spring full formed from the head of some Draper Fisher Jurvetson supplicant. They’re going to come from experts who understand the technology trying out new combinations and scratching their own itches. Not many are experimenting because of the onerous environment. Provide a more inviting ecosystem and the merger of web and mobile will kick right off.

Russ has been telling me to setup a mobile specific weblog for a while, and this is it. We’re actually on our way back from the first global Mobile Monday Summit. I wish I could tell you that I was writing this from the event, but that’s not the case. I’m writing this from an 802.11 connection in the Scandinavian Airlines flight on the way home. My cell phone didn’t work when I went over to Finland. I got a prepaid SIM card to use while I was there on the second day, but it had no data service available. And that’s what this weblog is about really, the failure to realize the fantastic potential that cellular mobility has. I would also like it to be about how to change that. What can be done to drag mobility out of its current state and into the next model? Mobility is tethered to the telecom system, and that environment is killing it with mediocre devices, crappy services, spotty networks, and convoluted billing models.

What is mobility? When I think about mobile applications I think about systems that allow you to keep more connected with the people you care about. I don’t think about efficiency. I don’t think about phrases like “global access to corporate data” or “workforce automation”. Those things are somewhat interesting, but not the real killer application. My mother is never really going to care about making her day 4% more efficient by managing her tasks using notifications and scheduling software. She does care about seeing her grandkids, knowing that she’s available should they need her, and feeling involved in their daily lives. She’s not going to start using data services for an application like streaming CNN to her phone. She might start using data services in order to get video of the kids.

Mobility has already worked its way out through the early adopters and technology enthusiasts. It’s possible to do a lot using mobile services, if you’re willing to pay the cost (both in frustration and whopping bills). That needs to change from ‘possible’ to ’simple’. A good test is how easy it is to recommend a particular usage to someone who isn’t at all familiar with mobile technologies. The example I use is trying to connect a laptop to the Internet using a cell phone. It’s how I connect when I’m commuting back and forth from work. But it’s not something I would recommend to anyone without a technical background. I would feel guilty for leading them into a mire of crappy documentation, needless complexity, nonstandard drivers, incompatibilities, and uneducated support. This is something that should be as easy as plugging a flash drive into a laptop and moving files around. Sometimes the carriers are to blame for intentionally crippling the user, sometimes group incompetence and overengineering are the culprits. The end result is that the services are a lot less useful than they should be. The mobile industry is overflowing with examples like that. That’s why the mobile world is still relatively small. Lots of people have cell phones, but what they’re doing with those phones is just a small sliver of what it should be.