There are no intentions to change the API and the way in which the tinySrc runs, so you can continue to use it with confidence.

You’ll see lots of new cool features coming in the future though: the service has some exciting times ahead of it!

The current vogue seems to be to do as much of it as possible on the client-side: media queries, progressive enhancement, adding CSS body classes, and so on.

These are all cool, and hit a resonance with those who deal entirely with the front-end of a web site, and who prefer CSS (and a little Javascript) to Python, Ruby, PHP and the like.

In my opinion, this approach won’t always cut it. I’ve already pointed out that the users of radically different devices might want downright different things. Sometimes the differences between browsers are just too great to be able to deal with once the page has reached the client. And dealing with structural changes to a site’s information architecture based on browser capabilities gets messy, fast.

(Imagine if my site had a conditional a ‘photo upload’ feature that I wanted to place in the site’s menu for mobile devices that supported it. Do I have to feature test <input type=’file’> on every page, simply so I can add or remove nodes from the menu’s DOM? Ugh.)

So anyway, sometimes it’s far better to have had the server emit the best content in the first place – or at least as close as possible.

With this in mind, I’ve a new project called modernizr-server.

Modernizr itself is a great way to find out about your user’s browser capabilities. However, you can only access its API on the browser itself, which means you can’t easily benefit from knowing about browser capabilities in your server logic.

To address this, the modernizr-server library is a way to bring Modernizr browser data to your server scripting environment. For example, in PHP:

<?php

    include('modernizr-server.php');

    print 'The server knows:';
    foreach($modernizr as $feature=>$value) {
        print "<br/> $feature: "; print_r($value);
    }

?>

The server knows:
canvas: 1
canvastext: 1
geolocation: 1
crosswindowmessaging: 1
websqldatabase: 1
indexeddb: 0
hashchange: 1
...

Exactly the same feature detection is available through this (PHP) API on the server as is available through the (Javascript) API on the client.

Currently, there is only a PHP implementation of the server-side API, but other languages would be easy enough. Stay tuned to the project for more (and let me know what might be a priority, or fork!).

For instructions on how to use, and information about how it works, you’re encouraged to consult the readme. Also this is a young project, so please use in high-traffic production environments with due caution.

Your feedback is welcome! Hope it’s helpful.

Currently, monomi analyzes incoming HTTP requests to detect which type of browser they come from. Default values are ‘desktop’, ‘tablet’, ‘touch’, and ‘mobile’ (meaning non-touch), and the type is put into the request.monomi.browserType property.

The order of preference for the detection, as well as the algorithms used, can all be optionally overridden when the middleware is instantiated.

It’s early days for the project… I have plans to allow the middleware to adapt the outgoing content to be appropriate for the detected device – although this needs to be sensitive to the asynchronous philosophy of node.js

Try it, fork it, experiment, have fun.

I’m focussing on native client apps that are free to download. These wouldn’t have suffered commercially had they been written this way in the first place. Obviously, I’ll also focus on feasible genres of apps. No 3D games or background apps, for example. To start with, informational media apps (such as newspapers and broadcasters) will be in the spotlight.

But otherwise, I may not need to pull too many punches. Offline access? Through the wonders of HTML5, that should be OK. Native device API access? Well, BONDI and proprietary libraries permitting, I’ll have a go – and there’s always PhoneGap too.

Each post on the site will be a walkthrough (or part of a walkhrough) of the process. As I get my hands dirty, from the protocol-sniffing to the pixel-jiggling, you can follow the steps I took.

Stay tuned and wish me luck!

We just launched v1.1, compatible with the latest version of WordPress. Download it, read the changelog, read about the features in full, or even join the team.

The plugin includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.

Features include:

• Mobile switcher to detect mobile visitors and provide an appropriate experience
• Base mobile theme for quick-and-easy XHTML-MP compliance
• Extended mobile themes so you can unleash your mobile creativity
• Transcoding and device adaptation to optimise the mobile experience
• DeviceAtlas integration for world-class adaptation
• Mobile admin panel for when posts can’t wait
• Mobile ad widget to make you some money
• Barcode widget to help users bookmark your blog

I have a lot of fun writing this plugin and there’s a bunch of cool ideas we have for the future. Check out the Assembla project to see the work as it happens – and maybe toss us some new ideas too.

It’s always a work in progress, but thousands of users seem happy enough so far. See what you think…

I had to generate some new resumé-style posts and they probably all showed up in your feeds. Sorry.

If you’re on the new site, I hope you like it.

If you’re reading this on RSS, maybe it appeared above.

Well, now we’re back on track.

The site now serves as much as a business card as it does a blog… but I will try to put the occasional post up to remind you that I’m still alive. Well, outside of Twitter and JaJaJeEv anyway.

By the way, I’m quite please with the favicon.

I run metajam.mobi. With 14m page-views per month, it’s a surprisingly popular mobile web site.

Also launching sometime this year: vumi.mobi…

I led the ready.mobi team, and have a mobile WordPress plugin ready for release soon. I just launched an image resizing service.

You may vaguely remember WAPtastic from 1999. Then AnywhereYouGo.com. Then Argogroup’s DevZone.

But the mighty mobiForge (neé dev.mobi) was also one of my babies, and is still going strong.

For Argogroup, I built BoxOffice, a reporting and analysis platform for large-scale monitoring systems.

The dotMobi KPI platform uses registry data to track domain trends. And I think I have another one in me.