Mike Rowehl: This is Mobility

It was a good week at work. And as everyone knows, there’s no better way to relax and unwind after a nice full work week than to get Linux running on some bit of consumer hardware it was never meant to run on using a technique most people will tell you doesn’t work:

I hear it will also play games. BRILLIANT!

I got a flash cartridge for it called the DS-XTREME. Horrible website, silly name, great toy. There’s actually a set of instructions for using the cartridge to boot DSLinux, they’re just hard to dig up unless someone links to them. Tada!

I’ve been playing around with RubyfulSoup for a few different projects. It’s a library for accessing HTML pages from within Ruby as if the format was actually sane for web pages (based on Beautiful Soup

download American Gangster

for Python). Sure XHTML is supposed to be XML and parsing is supposed to predictable and possible with a normal XML parser. But no one who has actually worked with a set of web pages from the real world would actually expect that to be the case. It’s just so nice to be able to say:

@soup.find_all( 'a' ).each { |t|
    u = uri.merge( t['href'] )
    ...
}

and ignore the details. Ahhh. Now only if it also worked with WML, that would be stellar!

Hat tip to Enrique for pointing out Twitlet, a Java ME Twitter client. Was just trying it out on my E61, looks pretty cool. I’m actually more in the Twitter by IM crowd normally than the Twitter by SMS crowd (just my programmer lifestyle, if I’m not in front of a large screen for more than a few minutes at a time recently I start to panic). But being able to switch around between the different modes is great. Like for example keeping track of what people are up to while at CTIA. Usually I use Agile Messenger and get the IM stream that way, plus I have access to my own bot then. But Twitlet provides a nice, and free, alternative. I’m assuming they’ve built most of the app based on top of plain old RSS and just integrated it well. Would be fantastic to try to abstract some common interfaces out of this and be able to use it as a generic client. Say getting both Twitter and Jaiku together in the same client would be pretty cool.

Last night was the April SV Mobile Monday over at Berkeley. Tony ended up not being able to make it, but that’s what happens when you schedule rockstars, sometimes they get pulled away by forces beyond your control. It ended up working out alright however, cause even with just Ajit and Russ presenting and a start time of 6pm, I had to shoo people out of the room at 9:30 so that Berkeley could close up. Fantastic!

Ajit (blog) spoke about using GPS for user generated content. Not location for user generated content, but GPS either as an external add-on for a handset or hopefully directly built into more and more of them (N95 for instance). Location as a network service is starting to get deployed on more and more carriers, so it’s technically possible to deploy a location enabled application. However the cost structure for the location delivery and sometimes access to the mechanism used to retrieve samples is geared for a completely different style of app than most of us are looking for. Using GPS instead of network provided location information puts control of the application infrastructure back in the hands of the developer and user and allows more room for interesting usages.

Good point. However, using an external bluetooth GPS is a pain in the ass. Believe me, I do my best to play until I can figure out a way for the stuff I like to work, but I just can’t get using an external GPS receiver with a handset to be practical. So of course, I need to try an N95. You hear that Nokia folks? Sure would be nice if an N95 just fell out of the sky and into my hands. Wink wink.

And Russ came out to launch Mowser, a new mobile enabler site he’s been working on. The blog post he put up today has a bunch of info, including a link to the presentation he gave last night. His overall goal is adding some transparency to the transcoding process that’s commonly used to mobile enable traditional web content as well as putting control back in the hands of the content owners where possible. That covers stuff from leaving markers in the HTML generated as output and intelligently handling handheld stylesheets to try to respect the authors original intent all the way up through some custom hinting that a content publisher can embed specifically for the transcoder to pick up and use in generating the mobile version.

Mowser has a bunch of content links, and a search box on the front page, but the guts of the system are really the content adaptation. Russ is aiming to come up with something that’s less effort than making a mobile specific version, but also provides more control and is more pleasant to use than a lot of the other transcoders out there. I completely agree with the effort, I was working on the same kind of problems before I joined up with AdMob for a lot of the same motivations. There really hadn’t been too much advance on that front for the last year, very nice to see the stuff he’s put together getting picked up and propagated. Go Russ!!

The big names in search are coming together around a common agreement on sitemap handling, including a method of autodiscovery linking to the sitemap from within the robots.txt file. Nice! I see nothing about a common understanding of how to deal with mobile content however. Not nearly as nice! Poor poor mobile web, never getting invited to the party. This must be some kind of mobile web psychological torture. Diabolical! The whole being tortured bit just drives me nuts.

We’ve been running an AdMob.mobi site for a while, it’s been up for a few months now. It’s basically just brochureware, info about how to contact us if the only way you can get to info is from a mobile. This is the case in some areas of the world, and particularly true in some of the places we get a lot of traffic from.

While I was fooling around with Google mobile search, I realized that AdMob.mobi actually doesn’t appear at all if you do a “Mobile Web” search from Google. I thought maybe somehow the Googlebot had missed it. Not the case. There are plenty of Googlebot hits against that website. So then I did a web search via the mobile interface. Our normal website is right up at top, everything okay. It turns out the AdMob.mobi version does appear in the web search, as result number 156. Wow that’s really far down the list. And when you click through from a phone you go to a Google transcoded version.

When I hopped online and started talking to some folks there were a lot of reports of the same kind of thing. Google doesn’t rank .mobi sites very high cause it takes domain registration length into account when figuring out how to weight sites. It also doesn’t really pay much attention to the variant of markup that a site uses, and has been just shoving everything through the transcoder.

That’s really kinda disappointing. With all the current push in mobile - from mobile browsers finally starting to support sane markup languages and palatable variants of CSS up through tools like the Mobi Ready Report and the machine readable mobileOK effort going on at the W3C - it feels like we’re generally getting to a state where site owners can put up a mobile version without too much effort and in a format they find appealing and consistent. But one of the main avenues through which people should be able to find this mobile stuff has actually turned out to be something of a blocker.

Everyone on 3rd edition (especially those of us with full keyboards) miss WirelessIRC, the fantastic symbian based IRC client. It just doesn’t work on the new phones. Fortunately someone has hacked together a new project: mIRGGI. It’s not open source, but it is free. And now it support server passwords, which I needed to be able to connect to the private server a friend has setup (my most common destination). Give it a try, it’s a great app.

I was just fooling around with some mobile Wordpress stuff, and noticed that a few sites I was playing around with rendered slightly different on Opera Mini vs the Services browser or Nokia OS browser. Not a tremendous deal, but it happened to catch my attention.

Opera Mini:

Services Browser:

Looks like Opera Mini isn’t doing the border-bottom. Fair enough, a quick look at the CSS Mobile Profile 2.0 shows that I should be using border-bottom-width and border-bottom-color. However, once I swap those in, Opera Mini still doesn’t look like the Nokia built in browser (which by the way renders the page like Firefox does, which is my gold standard, cause I’m a n00b).

And as always, I think well after the fact, “hey, wonder if there’s a checker out there that would tell me when I’m using CSS I’m not supposed to”. Cause when I put pages up I do it like people on the good old interweb do it, I bash at the stuff till it looks the way I want, and then maybe check it afterward when someone tells me it’s broken.

Surprisingly enough, I’m not sure there is. The stuff I’ve read says to use WCSS from the OMA (the WCSS PDF linked to from here), but I don’t think I’ve found a checker that actually checks a set of CSS against that document. And I think the document I have actually matches to that.. I think. The W3C mobile checker has some issues with my background colors… are background colors only allowed to be some predefined set in CSS Mobile 2.0?

Doesn’t matter, base question is: online document checkers - which one to use for XHTML mobile content that uses CSS? Is there an all-singing all-dancing one that lets me know if stuff is out of spec, or in spec but not supported by current implementations?