Bunch of Random Updates

A few things I want to get down as much so that I know where to find them next time I’m looking them as anything else.

Installing Ubuntu using the version of Parallels I have a license for is a pain. My installs kept hanging and erroring out. Then I found a post that pointed out a few things, I needed to use 7.04 instead of the latest, and I had to tell Parallels that I was installing Solaris. Also very useful: how to change the resolution once you have it installed. I have it set to native resolution of my MacBook so that when I run fullscreen it looks like I’m running Ubuntu all on its own. Not fantastic, but cheaper than getting a laptop that actually works with Linux. I’ll have to pick up a new Thinkpad some time soon.

There’s a funky startup problem with Tomcat running under IDEA on Linux. It’s easy enough to solve, just add an extra environment variable when running the catalina.sh. Bit of a pain if you don’t know about the problem and are trying to figure out why a newly configured project isn’t running.

Even if you have the right repositories installed under OS2008, the GNU native toolchain doesn’t appear in the application manager. It does show up if you apt-cache search gcc however, and you can install it from the command line no problem. Don’t forget the libc dev headers don’t come down by default either, you’ll have to install them as well for just about anything.

Posted in ThisIsMobility | Leave a comment

OS2008 Homescreen Hackery

Inspired by some screenshots that came through my feed reader the other day, I updated the firmware on my N810 and installed a few new bits of hackery:

Almost perfect

Those are transparent homescreen apps, and more important than looking slick (if that’s possible) they’re written in python! Homescreen hackery here I come!

Getting the packages installed is a bit of a pain. They don’t one click install unless you install two packages by hand. I had to download python-hildondesktop and hildon-desktop-python loader from this site in order to be able to install and use them. And yes, download and install manually, the app installer doesn’t like them. Download them to your tablet somewhere, become root (I do that with an ssh to localhost myself), and run dpkg -i for both of them. Then you’ll be able to install the actual applets and enable them. w00t!

Posted in Maemo, Open Source, ThisIsMobility | 8 Comments

Mobile Web from the Perspective of a Javascript Developer

There’s a talk from Alex Russell about mobile web development up on IT Conversations. The title of the talk is “AJAX and Mobility”, which is actually misleading (as is my own title, since Alex isn’t really a Javascript developer only, he’s got experience all up and down the stack). He’s actually cautioning against going toward AJAX on mobile devices, having solid base primitives that really support the unique capabilities of a mobile device are way more important than trying to replicate AJAX.

His commentary is right on, and refreshing to hear it coming from someone who does a lot of Javascript online right now. Sometimes I think I’m insane for saying the mobile web isn’t ready for AJAX if the base functions don’t work yet. Maybe I’m being too conservative and I’ve somehow missed the boat on a new iteration of engineering on the Wild Wild Web. Maybe I’ve gotten too old. But then you see a few great new efforts flame out under the weight of their own development process and user base, and reality start to creep back in. Seeing an experienced developer or two express the same sentiments helps ease my nerves as well.

If you think I’m full of hot air for saying some of the things I saw, try out Alex’s take instead. His points about not having a reusable endpoint for application service on a phone is interesting. You have a phone number for voice and SMS, and you have a URL for web services, but there’s nothing really the same for installable applications (not yet at least, this is one of the reasons GetJar is interesting). I also thought his list of features the browser needs to grow directly were very interesting:

  • Access to location information
  • Access to the voice channel
  • Access to the camera
  • Access to contacts/address book

I keep hearing that list over and over again. Frequently the reason stated for not including the stuff is “security issues”, which is hard to argue against because so many folks currently would gladly give up tons of freedom in exchange for a little safety. But there’s no real reason for that. If I as a user want to send my location information to a service the system should allow that, and claiming security as the reason not to provide it is just a cop-out.

The point I disagree with Alex on is open source in mobile making a difference. I do see potential for folks like OpenMoko and the Firefox Mobile effort to really shift the playing field. If for no other reason than they can provide platforms that fix those four deficiencies in current mobile browsers. And once the mobile web is really setup to be able to win, things will tip in that direction. Users will bother to download and app and keep using it if that app is a genuinely advanced browser that gives them access to a whole bunch of other applications out on the web. Users will get a handset so that they can share their data online the way they want if the applications are out there to do so. I see open source as the only way to bootstrap that process. The carriers aren’t going to do it, existing manufacturers aren’t going to do it, and web app owners can’t do it on their own.

Listen to the first question from the audience too, it’s a gem. Some guy asking vaguely “On Windows Mobile with a GPS you can already use .NET to expose an interface to Javascript you can use from IE, why does location need to be built into the browser?” Ah, the world of mobile. Some people are just so beat down they’re completely incapable of thinking through anything new.

Posted in ThisIsMobility | 1 Comment

N810 Interface Critique

There’s a great post at TabletBlog critiquing the user interface of OS2008, the most recent revision of the operating system that runs on the Nokia internet tablets. To anyone who’s used both devices the points really ring true. Great writeup!

I’m a diehard Linux fan, and a mobile Linux fan in particular. My N810 is with me practically all the time. And people frequently ask me “Hey, what is that thing?” when I’m wandering around with it. Pretty frequently followed by “You think I should get one?” when I start gushing about the web browser, Python and Ruby packages, SSH, and how useful of a device it is for me. But my response is still “Well, are you a developer?” when they ask if they should get one. It’s just not a consumer device, not yet at least.

In theory us developers should be able to mold this open source platform and help make it something capable of appealing to the mass market. It takes time mind you, desktop Linux systems are only starting to make some real headway (thanks mostly to Ubuntu) after years of us geeks hacking around on the stuff. But once you have enough people pointed at an open platform interesting things do start to happen.

Part of the problem in OS2008 however is that the base environment and the bundled firmware applications are still closed source. If I end up disappointed in something like the RSS reader applet functionality I have options. The system is fully programmable so I could make my own RSS reader and create an applet for that which does what I want. It’s possible for me to do that. However if I had the source code to the bundled app the barrier to me trying out the configuration I want for my homescreen would be a lot lower.

I love the platform, and right now the N810 is a killer geek device for me. A real handheld Linux device that I can hack on, fantastic! However in the face of the platforms coming out I think they’re just going to get bowled over unless they do something to leverage the community they have to help them address a wider audience.

Posted in ThisIsMobility | 1 Comment

Maemo Browser Friendly Apps

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.

Posted in Browser, Maemo, Mowser, Software | 4 Comments

Sync vs. Always On vs. Modular Core

While I was upgrading to WordPress 2.5 this morning I happened across this post I noted but never finished. So it’s a bit less timely, but the overall issues are still interesting.

Looks like modular handset manufacturer Modu is raising a bunch of money. It’s an interesting concept, but certainly not new. Back at the start of 2004 I was taking a look at a company called Antelope who had a product called a Modular Computing Core that promised much the same thing.

The normal argument around getting your data and service where you want them when you want them goes something like this in mobile:

  1. Person 1 says that the problem is best solved by a set of services that run on each device/computer/gadget and allow you to synchronize your data and preferences information so that you don’t have to keep entering stuff over and over again.
  2. Person 2 says that increasing network coverage and speed coupled with decreasing access costs and competition between access mechanisms for share of user traffic will result in an “always on” infrastructure that makes syncing unnecessary. Just put the data and preferences up in the cloud and always access them realtime online. Surely the network will be acceptable for any use like this before a realistic set of services and clients to sync become available.
  3. Person 1 says something like “Bah, SyncML clients come installed on all kinds of handsets already.” And then they start bashing the networks as still being unreliable and unable to move large amounts of data for an effective cost and at the necessary speed.
  4. Person 2 says “Ha! SyncML has been around forever and has yet to yield a workable direct consumer application.” Then something about it doing even less than Bluetooth to foster cross-service information semantics, which make it unworkable as a base for large scale cross-application syncing let alone cross-domain syncing.

The discussion always goes on from there, is always circular, and never reaches any conclusion. Normally I wander away by the second round if I haven’t already slipped out by the first round. Which isn’t to say that interesting work isn’t being done on both sides of the equation. Funambol writes some kick ass open source software that makes it more and more realistic to use SyncML every day. However, I still don’t. The Nokia implementation is broken in some way or something of the sort. I would have to setup my own server to get it working, and many of the services I would be interested in using are marked as very beta. And on the other side efforts like OpenID and OAuth are making it more likely that I can just store stuff in the cloud and use it where I like. But even basic interoperability for things like preferences and personalization don’t seem to have made it into general use. And while some of the efforts used to have a focus on mobile, very little seems to have even a consideration for mobile any more.

So in that context a modular computing core is interesting. It’s kinda like flipping both camps the bird and saying “I don’t think either of you are going to get your shit together in any reasonable timeframe, so I’m going to create a way to solve this problem completely in hardware.” Not sure I agree with it, software systems enjoy economies of scale and flexibility that hardware based solutions don’t. But in the meantime, it’s a novel way to endrun both issues and get your stuff where you want it when you want it.

Posted in Technology, ThisIsMobility | 1 Comment

World Wide Web vs. Carrier Networks

There are a few interesting things going on with “carrier networks” on the whole that have had me wondering about how folks at the carriers/operators can be so painfully dense. There’s the problem with Sprint deploying a proxy transcoder and expecting folks to get whitelisted to not be adapted instead of using standards, stunningly similar to the Vodafone issue which has already been replicated with TeliaSonera. And I have an issue that hits more close to home, my startup company Mowser is apparently subject to some access restrictions on the 3 network in the UK which apparently do not apply to Google or Yahoo.

The common response to issues on these network is that standards be written up to specify the behavior so that carriers stop doing it. I’m going to have to cry bullshit on that one. While listening to a talk by Tim Bray from Rubycon I learned there’s a document up describing the overall architecture of the world wide web. How convenient.

A quick look through the document shows where carrier networks already diverge from published recommendations. For instance take a look at the very first section after the introduction:

In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. One goal of the Web, since its inception, has been to build a global community in which any party can share information with any other party. To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web. The global scope of URIs promotes large-scale “network effects”: the value of an identifier increases the more it is used consistently.

Well when you whitelist and blacklist sites at the network level guess what you’re doing? You’re segmenting the URI namespace based on your access network. Depending on where you are and how you’re accessing the network you might or might not be able to access a resource. And when a transcoding layer is introduced for all requests through a network independent of source link structure, you’re having the network make a decision to change the semantics of a URI, selectively mapping a whole chunk of URIs to other resources. Leaving aside the whole other issue of the general Internet principle of the intelligence for any given set of protocols being at the edge of the network instead of the core, this also conflicts with the overall principle of consistent global identification.

We’ve already had decades to understand and refine the proper functioning of the Internet, and there’s already a tremendous body of work laying down and describing how to replicate and interact with it. But carrier networks continue to break the most basic and fundamental principles when there seem to be obvious and simple alternatives to get to the same goals. I strongly doubt that yet another standard will do anything to help.

Almost all of the Mobile Web docs out of the W3C that I see reference the base W3C architecture description base document like the one I was just looking at. Yet still they go ahead and define something like “in network adaption” when talking about best practices. Best practices on the Internet say that no application decisions should be applied between the two communicating endpoints. Full stop. It’s just incorrect behavior.

Unfortunately nothing really seems to be affecting these folk’s decisions to do things that are disruptive, limiting, and destructive to the long term environment. You can always vote with your feet though. If I were on Sprint I would switch off their service, same thing definitely for 3. It normally only takes a few people switching off and giving the reason of “I can’t access the web sites I want the way I want” for their customer relationship systems to form the correlation and realize it’s an actual problem. I’ll help maintain a list of carriers not to use if you care about the mobile web also, cause people might be more likely to form their decision going into a purchase rather than after they already have things up and running. So here’s my list of carrier not to get service from if you care about the mobile web:

  • Vodafone UK and Portugal
  • 3 UK
  • Sprint

If there are others let me know in the comments.

Posted in Community, Mowser, ThisIsMobility | 3 Comments

Social Sites and Supporting Technology

You know how there’s the general rule of some technology being mainstream when your mother uses it? Well my mom is listening to a podcast, the twist is that it’s a knitting related podcast that my sisters produce. I kinda knew this whole social media thing was headed in an interesting direction when I heard that they all participated in a knitting and crochet related social network. Of course when I asked them if it was a social network they looked askance at me, and said “No, it’s a site where people share the stuff they’re working on and post tips and questions”.

Looks like this whole section of social stuff is catching on in the way folks expected it to. Explains the explosive growth that Ning is experiencing, and why so many folks are scrambling over each other to make something of the sort in mobile. But what’s taking off isn’t “social networking” exactly, it’s people forming communities. Give people a set of pages they can use to create a profile and message to each other, you get a decent user community (frequently focused on flirting with each other, but that’s a different issue). Give people tools to create pages they can use to communicate with each other, and communities start to form. The long term value seems to be tilted more in the Winksite direction than the Mig33 direction in that respect.

Actually, I’m not sure were I’m going with this. It could go anywhere from talking about mobile social building blocks like the stuff MPulse has been working on, or Zygo’s and 3Jam’s take on group messaging, all the way through OpenSocial vs. the mobile web and how we get to start using DiSo ideas like XFN, OpenID, and oAuth, and other microformats in the mobile environment. But then I would have to dig up info about what Johannes Ernst has been up to and how LID has progressed within mobile in particular. But unfortunately I need to get running yet again. Hopefully that’ll stop happening now that I’m not going to be running up and down the peninsula on a daily basis. In the meantime I leave you with this cross-disciplinary thread to pull on if you want: including SMS messaging in the OpenID authentication mechanism to avoid having to enter a password.

Posted in ThisIsMobility | Leave a comment

Missing Reporting/Metrics in the MMA Guidelines

Thanks to Russell for pointing out that a new set of MMA guidelines is up for review. Apparently I’m supposed to post feedback in their public forums, but I’m getting a bit tired of having to follow discussions in other places. So I’m posting my feedback in my public forum, just like they posted their recommendation on their site. Just seems proper.

As soon as I read Russell’s post I thought “Yay! Finally some structure around an accepted practice for audience measurement on the mobile web!” Cause any effort to democratize serving ads in a medium and put everyone on equal footing just needs to set down conditions of input (media styles and formats, standardize terms and minimum specification of a buy) and expected output (what should be reported and how should it be measured?) The guidelines as they stand make a point of dealing with the media formats and sizes, not bad, I have no real comments there. However, the mobile web part says nothing at all about audience measurement. Which is kind of conspicuous cause the messaging and downloaded app sections do talk about metrics and reporting.

It’s almost like it was intentionally left out, hoping no one would notice the smoking crater? I’m looking for something along the lines of the IAB Campaign Measurement guidelines. Look at the detail in there: delivery mechanisms and which inclusion tags count as which style and dealing with caching. And most important, it doesn’t matter if it’s right or wrong in every case, just that it’s consistent. Why is there information about handset screen sizes in China, and no mention of how to measure reach on the mobile web? Bad form.

Okay, I know I said the report included sections on application download and messaging audience measurement. Technically that’s true, in that their presence in the report calls into attention their absence for the mobile web section. But these are the counting and reporting “guidelines” for mobile messaging:

Operators could use counting tools that use digital fingerprinting or similar technologies to track message
distribution among users in the network. This could enable the service provider to track the dissemination
routes, to identify social leaders, and to reward users for forwarding messages. However, all these
capabilities must comply with existing national level regulatory and legal frameworks covering privacy and
the use of personal data. In addition end users concerns and expectations will always need to be
carefully managed. Taking all steps necessary to ensure end customers fully understand any proposal to
user their data, together with providing a clear choice to opt in or out of this type of service is essential for
its long term success.

Umm. I’m not sure “The carriers might do something to help count users. And oh yea, be sure not to break the law” really counts as a guideline. That’s not helpful at all, to anyone.

Then there’s the section on mobile video, which says pretty much “we’ve got no guidelines, but here’s some info about mobile video.” What the hell? Are these guidelines for usage? Or marketing material? If you don’t have guidelines for mobile video don’t include a section on mobile video in your guidelines. It’s reminiscent of padding out a book report. Was there a minimum word count for this assignment? I actually scrolled back to the top of the document and checked the title of the report again, thinking that maybe this was really just an informational release. The mobile marketing strategic overview and not a set of guidelines. But that’s what the report says, “MMA Global Mobile Advertising Guidelines”.

So lets create a specification for them so we don’t have to go through the process again. Audience numbers must be counted using the MSISDN if available and fall back on cookie based counting in all other cases. MSISDN presence is dictated by the presence of one of the following headers in a request from a mobile terminal:

  • X-MSISDN
  • X-NOKIA-MSISDN
  • X-UP-SUBNO
  • X-WAP-MSISDN
  • X-UP-CALLING-LINE-ID
  • USER-IDENTITY-FORWARD-MSISDN
  • X-WAP-CLIENTID

It’s relatively easy to pick out which headers to use if folks publish some info about the traffic they’re getting. Cookies must be delivered with the domain of the central advertising network if appropriate, which means image based recording even for text adverts. 1×1 gif, which admittedly carriers could block.

That’s it, that’s a spec, it’s the kind of thing I would expect the MMA to put in their “guidelines”. Furthermore, given their position as the premier global organization pulling membership from carriers, software providers, and manufacturers I would expect them to:

  • quantify in what percentage of cases the guidelines are expected to yield valid numbers given global averages
  • work to improve the guidelines to decrease the error rate over time
  • provide recommendations and guidelines to carriers, software providers, and device manufacturers to decrease the error rate going forward

If something like that happened we might have something that could “stimulate the growth of mobile marketing and its associated technologies.” As it stands now however, I don’t really see the point. It clarifies a few points if you already have an advertising business up and running. But say you’re an independent site owner looking to sell your own inventory directly, or an open source advertising platform looking to add mobile adverting to the mix of features your package provides. Read through the guidelines with that perspective in mind and it’s obvious it doesn’t provide any of the necessary clarity at all.

Posted in Browser, Community, ThisIsMobility | 2 Comments

Sprint Hiding User Agent

I did a search this morning to see if there was anything related to the cookie issue with Openwave software. Instead I found a post from Dennis saying that it appears that Sprint has now followed Vodafone in disrupting the mobile web. Ouch. And their partner in crime? Openwave. I was hoping to find some positive reaction, instead I find a new mention of negative behavior. Damn.

Posted in Browser, Community, ThisIsMobility | 5 Comments