Ripping mobility from the clutches of telecom
Archive for March, 2006
SMS.ac – Come On! Just Die Already
Mar 29th
Just following through on what I started this morning and linking to Russ with SMS.ac prominently in the text. I also put it up in my del.icio.us links. Join in, spread the word, post a link or two or three. If there ever was a time for Googlebombing I think this is probably it. Help prove that you can’t rewrite history to try to salvage your reputation, you salvage your reputation by not being an asshole any more.
Participants:
April 2006 Mobile Monday – Flash and SVG
Mar 27th
I just posted the details for the April 2006 Mobile Monday meeting. I think it’s going to be an interesting one. I had a bunch of folks at MoMo meetings ask about Flash and SVG, and once I started passing the idea along found a lot of attendees were already involved with Flash and/or SVG. So we really got to pick and choose presenters this time, and got recommendations together, and I think really ended up with a well balanced (and small) set of presentations.
Like I said in the post however, I’m interested in finding what others in the audience think about using Flash or SVG for their application. Many handsets can run Flash and/or SVG now, but how many do it out of the box? If they don’t have the necessary bits pre-installed how easy is it to bundle everything up into a simple install for users? How does that affect the cost of your app? For the average consumer application I just don’t see folks going to pay for a runtime Flash environment so that they can run any app. There’s just no killer app out there that would drive that kind of effort.
So that’s the first question I’m going in with: what does the packaging and install process look like typically? My secondary question is as a developer of primarily open source stuff: how does Flash/SVG development fit into that world?
PayPal Mobile
Mar 23rd
I think Carlo really nails it in his writeup of PayPal mobile. I would just put some additional stress on the “force that onerous revenue share down to more acceptable levels” role that PayPal can play. I’m very very happy to see something like this happen outside the carriers just because I suspect it will make the carrier solution down the line much more palatable. Cellular carriers have one really solid competitive advantage over other kinds of networks we see springing up, and I think it’s their billing relationship with their customers. If carriers can find a way to make that a service they provide to content providers and other online services it gets interesting. Right now they’re trying to use that billing relationship to try to control everything that the cellular user touches. That’s not going to work long term, there’s only so much you can roll up under one roof, and carriers just don’t have any competency at all in the things they’re trying to roll up.
This was a lot of the focus at the Mobile Monday we had about digital identity. The carriers are in a great position to provide value added services instead of trying to strangle a higher and higher percentage out of the existing channels they control. I think it would mean a boost for mobility in general. For me the PayPal service means that the carriers can’t think they control that payment relationship, there’s a way around them. It’s not something that most people would do, but it’s still a crack in the wall around the garden. And I hope that forces carriers to think different about the way they prepare their offerings.
Google Transcoding Search Results for Mobile
Mar 22nd
I’m happy to hear that Dave managed to get Google to stop mangling the WINKsite pages after searches, but definitely somewhat troubled by the process he had to go through. I agree with what Scott had to say about the issue in general. I don’t really see it as censorship or predatory behavior necessarily. The problem is that Google doesn’t automatically pass through to the mobile site when one exists, so they can be seen as hijacking the browser to a degree. It’s just bad web etiquette to return your own stuff when you can link off to existing workable stuff. I personally view it very much the same as framing. It’s bad manners to frame someone elses site unless you have a reason to. And it should be bad manners to stick your transcoding engine in between the user and the end website if you could realistically just link off to an existing mobile version. That’s it. I’m not going to comment on the advertising or the censorship issues or the rights of publishers or anything else. It’s just bad manners in general, independent of any other issues. So I hope Google figures out how to fix it and does so.
Location Based Disservice
Mar 9th
I’m betting at least some of you out there look at the release from Garmin and think “Bah, I could do what I want of that with my Series60 phone, a GPS unit, and some Python scripts”. It’s what I thought. And it’s what I did actually. I took a look at the amazingly mobile friendly Map Image set of calls into the Yahoo service and built myself a little Python script that would download an image every once in a while to show me where I was. Cool, right? But then Martin and Diego pointed out this from the bottom of that Yahoo maps API page:
Sensor-Based Location Limit
You may use location data derived from GPS or other location sensing devices in connection with the Yahoo! Maps APIs, provided that such location data is not based on real-time (i.e., less than 6 hours) GPS or any other real-time location sensing device, the GPS or location sensing device that derives the location data cannot automatically (i.e. without human intervention) provide the end user’s location, and any such location data must be uploaded by an end-user (and not you) to the Yahoo! Maps APIs.
And most people respond to what with “God.. what is Yahoo thinking? Do they not want people to use their APIs?” It’s not Yahoo, I’m 99.9% sure I know where that comes from. It’s exactly because of the thing I said before: “I can do most of the useful stuff with a simple phone and GPS so why do I need Garmin.” And then people say: “But why would Yahoo do that to protect Garmin? Is Yahoo making a device with them or something?” No, it’s not Garmin either. Look one level further up in the chain, to the folks I complained about in my last posting about LBS.
So who is it that would cripple the Yahoo mapping API and has a vested interest in protecting the bottom line of folks like Garmin? TeleAtlas is the one that pops to my mind. Download a map from Yahoo and you’ll see their logo in the corner. They sell that same map info to device manufacturers and charge them per copy of the data. If the Yahoo API were able to provide info in realtime to GPS enabled devices it would start to eat into the license revenue TeleAtlas makes off navigation devices. So what’s the response? There’s no technical reason for that restriction in realtime usage. There’s no realization that “Wow, the market is changing amd maybe we should revise our model some.” No, the response is to cripple to new technology in favor of continuing to milk the old. Does no one read Christensen besides my friends? Cause all of them see this is a boneheaded move long term. And a horrid disservice to what should be an even more booming location based services market reconstituted around web services.
Someone, please, if you know better than me on this one let me know. But the resources I’ve tapped within Yahoo don’t seem to know about any alternative reason for the restriction. And generally respond with “Wow, yea, that makes sense” when I tell them what my theory is.
Video and Audio from Mobile Monday
Mar 8th
Shannon Perkins has started posting the video and audio from the March Mobile Monday. Thanks Shannon!
Web Components For Mobile Applications
Mar 6th
I should probably start with some kind of disclaimer that I am a Ning employee. However, this stuff that I’m about to talk about is work I’m doing in my free time. It does not represent the position of Ning or any of the other Ning employees, and whatever else disclaimers like this are supposed to say. This is all completely mine. Mine I tell you, MINE!!! There are a bunch of ways that Ning could kick ass, but in which it does not yet. I could try to convince everyone of my grand vision, which I’m not very good at. Or I could just make things and see what happens. Which I’m better at, and which keeps me from having to amuse myself in other ways. I don’t think any of us want to see that happen again.
I was fooling around this weekend with a Ning app that accepts posts from Lifeblog. Why was I doing that? Cause now that there’s a Ning app that accepts Lifeblog posts we’re going to take over the world? No, not quite. Even I’m not that naive. And you should hear some of the crackpot stuff I believe in.
The first reason was that I wanted to make sure that there weren’t any unforeseen technical problems with putting something of the sort together. Putting in support for an application that wasn’t meant to be used with Ning I think proves that the platform is pretty generic. Generating web pages usable from mobile devices isn’t there, but that’s true in lots of other places too so I’m not going to spend too much time moaning about it.
So why care? The client app isn’t new, posting the stuff to the web obviously isn’t new (it was a feature in Lifeblog to start with after all), the server side app isn’t inventive at all. The only real difference is the simplicity with which a “new app” can be setup. True that by default my sample app is pretty crappy. But take a step back and check out what we got:
- Download an app for free, like Lifeblog. Or even better start with some open source – say a simple photo upload midlet or a blog posting app for Palm devices (also free). Or if you’re that kind of person, pick from among the many network based examples for an open platform like Python for the Series60 (wow, that’s really free).
- Sign up for a Ning account and clone an application that works with the bit of software you’ve got on your phone (free). There’s the Lifeblog endpoint I threw together this weekend. But it wouldn’t take much effort to throw together others. Say something that exposes the Blogger API and accepts posts from any of the tools that upload in that format. Or a script that accepts samples from one of the Python GPS samples and generates a map based on that.
- And the environment is pretty malleable. Don’t like the way that the application on the server side works out? Hopefully by now I’ve driven home the point that you don’t have to live with it. Get in there and hack that shit up. And of course your changes are resharable too.
First of all it’s a relatively simple and easy to setup environment that closes the loop between mobile and web. Not an ending point mind you, but not too shabby of a starting point. We can move stuff from a handset out to the web, and with an extremely low amount of effort compared to most of the existing methods for fooling around with mobile to web interaction. A clone and choose an application name and you have a working service endpoint.
My plan is to fool around with a couple more samples, and work on the mobile client side some over the short term. Over the longer term I would love to figure out how to make the mobile client side more generic, get the mobile side interacting with more and more of the apps, figure out the user side (assume I have a great app with a mobile component to it, how do end users interact with it), inbound and outbound messaging, and of course the whole general web issue. I posted about it cause I’m betting there are a bunch of people out there who have app ideas that would only really work on mobile, and for which a service like Ning opens up the door.
Not Making things Mobile
Mar 4th
I’ve been thinking a bunch about the mobile web in general (it’s the topic of the Mobile Monday meeting next week) and what I said a while ago about trying to merge the two currently distinct webs in particular. It was something that came up during Mashup Camp too. I don’t want better tools for people to make their content mobile with, I want better ways to work with content which automatically make it mobile. I want to run down quick what goes into that from the website developer side, folks who normally aren’t too into mobile but would I’m assuming like to support it if the cost wasn’t too high.
Details of what device the page is going back to has to be something that the developer can ignore. The default should be “it just works”. Most website developers have neither the time nor the desire to learn the nuances of the hundreds of devices out on the market. Also, the magic to make the website work on mobile devices can’t be something additional to do. It needs to be baked right into whatever the easiest/most common method of developing websites is.
So of course the question comes up of what exactly that magic is. I was starting to question if there had to be a single markup that goes directly to both desktop browser and mobile device. That could either be proxies between the device and the website (such as done by Skweezer or Google) or a single source generated in both desktop and mobile markup. The second option raises hackles right away cause that’s how WAP was supposed to work out. However I don’t want to count it completely out, given a different target markup maybe it could work. The proxy option doesn’t look too appealing either, with more and more websites relying on client side scripting and a dynamic document model.
A related question is if the HTML layer is really the right layer to target for compatibility anyway. The current techniques of website design apply a few “hacks” to get the browser to act not as an HTML renderer but as a scriptable application who’s widget set happens to be HTML and CSS description. So could we make life easier for the web folks by baking that behavior right into the next version of the spec (no more having to probe browser types to figure out how to get an xmlHttpRequest object, no more JSON to fake the browser into loading data from a third party) and at the same time making a “web application” something that a mobile device would find as executable as a browser does? I don’t know, but I’ve started thinking about it.
There’s also a question of how much coverage you could get with support for a couple of web services style APIs. With more standard support for RSS, the Atom publishing protocol, and OPML could somewhat generic mobile applications be built to allow access to the corresponding web applications? This would probably require some extra definitions of how the generic mobile app should interact with the specific site, and we have to assume that most people wouldn’t create those. But if the standard tools for creating web sites were driven off something that would be able to generate that automatically that would be a completely different issue.
So that’s the stuff I’ve been thinking about (and hacking around, hopefully I’ll be able to post some of the toys this week coming up), how can we make it so that people don’t have to “mobilize their service”. Everything starts out mobile and it takes effort to make it NOT work on a device.
