Ripping mobility from the clutches of telecom
Archive for February, 2006
The Series 60 SDK vs. Linux
Feb 15th
I don’t have a Windows system, I don’t want a Windows system, I will not get a Windows system. I would however like to create software for my phone, a Nokia 6680. Java and now Python are options. But I would really like to hack around, which means writing native apps. I’ve tried using GnuPoc, but didn’t have too much success with it. However I recently happened across this sdk2unix package, which does work, has recent activity, and apparently is being used to compile some Python extensions. Ideal!
LBS – Not quite there yet
Feb 9th
We had a location based services focused Mobile Monday at the start of the week. There were some great presentations, people working on interesting stuff and some promising work going on. But I have to admit that my overall takeaway is that there’s a huge disjoin between user and developer expectation about LBS and what those inside the industry think.
The folks inside LBS claim that “location based services are here now!” in the US because of recent rollouts of technology. But the reality is that LBS is possible, not convenient yet. That’s not to say that useful applications can’t be built on top of LBS. I think Spencer from Bones in Motion did a fantastic job of explaining all the pitfalls and problems that they had to work around in putting together a well packaged and convenient application that integrates location as a core aspect (see Spencer’s blog for some more info, his slides are up online as well). In general that’s not going to cut it however.
I agree with what Charlie says about location based services, there needs to be more ground up activity. The current environment in terms of LBS doesn’t really allow for that though. In many instances the application developer has to get a special key so that their app can get location info out of the handset, many of the handsets out in the market still don’t support convenient access to that information, it’s costly to the user and follows an unpredictable cost model that varies from network to network, and maps and other geographic info are viewed as value bearing resources that “someone has to pay for”.
However when I talk to developers thinking about working on a mobile app that includes location they ask what API they have to call to get a map centered on the current location of the phone. The low barrier to experimentation with online services has generally lead to a proliferation of (sometimes) interesting applications, and the same thing can be expected for mobile. That’s where current developer expectation is, and I think rightly so. If I start talking about getting API keys from carriers and then purchasing map info from someone they generally wrinkle their nose, mutter “screw that”, and wander off to their next idea. For them location based services are most definitely not “here now”, they’re not even close. And I think the environment won’t really start to get interesting until we reach that point where the barrier to experimentation is much lower.
Linux Motorola Phones
Feb 7th
There’s an article at NewsForge about Linux on Motorola cell phones and the lack of native applications:
The big question is, what does Motorola gain by obstructing willing developers from bringing software to their platform?
Actually, it’s not that much of a question, the answer is just a bit higher up in the article: they gain carrier approval. Carriers view open platforms as a threat to their business model. This is one of the reasons for the newer versions of Symbian including a signing infrastructure as part of the OS. This actually represents a move away from the open platform approach they have. It does nothing for the user, and nothing for the device manufacturer. All it really does is increase the friction in terms of getting an application onto a handset, which benefits the carrier who wants to take a cut of any application install (because of course they want to drive folks to their deck instead of installing apps on their own).
Google Local Mobile on TMobile
Feb 1st
Up until a few days ago I wasn’t able to use Google Local for Mobile on TMobile (or the other Google Maps app Mobile GMaps. Which I found very very odd. I had Mobile GMaps installed for months before the Google offering came out, it was part of my standard “show off mobile apps” lineup so I pulled up the app relatively frequently. But then when the Google offering came out, and it didn’t work, I turned to someone and said “that’s dumb, I have this other app by a third party that does the same thing pretty much and it works”. But sure enough, starting right then the Mobile GMaps didn’t work either.
Suspicious, very suspicious. But earlier this week one of the guys at work who also has TMo said he tried out Google Local for Mobile and it worked. So I started up mine and sure enough, yep, it works now. And yes, Mobile GMaps is working also. Just thought there might be interested parties out there. Google will probably want to change the header on this page too, which says that Google Local for Mobile doesn’t work on T-Mobile. At least I hope they will, cause it would suck if this is a temporary glitch that’s allowing it to function.
Yet Still More Mobile Advertising
Feb 1st
I’ve posted about mobile advertising a few times recently already:
And now Oliver has posted a discussion between him and Omar that I want to comment on. First of all, the setup with mobile ad delivery is often positioned as something completely different between the online and mobile worlds. That just isn’t so. Sure, the method of insertion typically used online isn’t going to work for most current mobile browsers, but the overall environment problems often cited actually exist in both places. People say that on a mobile the user is paying for the bandwidth. People say that advertising reduces the usable screen realestate for a mobile application. The advertising itself consumes bandwidth, causing the user to load more screens or wait for longer for a single page.
All of those things are problems online as well. We still pay to get online, it’s just a flat fee for a very fat pipe. Advertising reduces the effective screen realestate for the desktop browser, you just normally have much more realestate to start with. And online advertising also consumes bandwidth, it’s just percentage-wise a much smaller impact. People say that they should have to see advertising cause they pay for the data transfer.
But you pay for cable TV and there are commercials in most of those channels, and you pay your ISP and there are advertisements on the web pages you surf. Sure, you don’t pay per minute watched or pay per KB downloaded normally. But I’m on a flat fee data service with my cell phone, so I don’t pay per KB either. Not true for the majority I admit, not yet at least. But I don’t see any reason for the overall environment not to evolve in that direction. No matter how hard the carriers try to stop it, that’s the way mediums evolve. They evolve to the transport being a comoditized service with the content supported by subscription on the high and and advertising on the mass end.
So the real difference comes down to degrees. Trying to jam traditional advertising into the mobile environment seems cumbersome and intrusive because of how much bandwidth it takes, how much screen realestate it takes, and how little information it pulls about targeting those ads. If it consumed less bandwidth, less screen, and delivered more relevant information into more valuable content I don’t think it would be as much of an issue.
And those tunables can be combined in a few different ways to make the environment more appealing. Drive the value of the content through the roof and it probably won’t matter if your ads are intrusive, if people get enough value out of the service they’ll keep coming back. If you’re delivering something of relatively low value structure your advertising program so that those links are as targeted as possible, they might even become indistinguishable from the rest of your app. Is that advertising? Or an affiliate program?
As I’ve mentioned before in relation to video advertising on mobiles, I don’t think that shoveling the traditional ad delivery system into the new medium is going to be a win. But I do think that the overall dynamics are as much going to apply in this medium as they do in others. The key is finding out how to take advantage of the unique benefits of the mobile as advertising platform (and all the information I’ve seen so far indicates that “advertising platform” is going to be a bad term for it because it’s going to need to be ultra-personal and much more of a conversation) and take advantage of that. But is advertising supported content on mobiles a natural and correct evolution on the whole? In my opinion, yes. It just might have to look significantly different enough from online advertising that we’ll have to stretch our definitions after the fact in order to include it.
