James Pearce » Mobile Web

Mobile Analytics With Python, Django, ASP.NET, Java, and node.js

James — Mon, 30 Aug 2010 06:42:30 +0000

A few weeks ago, the PercentMobile team came to me to see if I could help write some new libraries for them. Contemporary web and mobile web sites are written on a vast array of different platforms… and obviously the more that PercentMobile supports, the better.

Something I love about programming is that there are so many languages to choose from – why restrict yourself to learning or becoming an expert at one when the same problems are also being solved in other, sometimes better, ways? Each language or platform has strengths and weaknesses of course. But I believe that understanding the differences – and more often, the similarities – makes one a better programmer.

So, generous polyglot that I am, I took the challenge, and plunged in.

(Sign up for the free PercentMobile service to get the libraries described in this post.)

Python & Django

I love Python – its readability, its libraries, and its overall philosophies. In a web server environment, Python can be used in a fairly raw way, behind a generic Web Service Gateway Interface (WSGI), but there are also a number of powerful web application frameworks using the language – most notably Django. PercentMobile want to provide painless Django support, but also to make sure that other Python server environments were not precluded.

percentmobile.py is the single file that provides everything you need.

If you are running code in a WSGI environment, you will have a handle to the WSGI environment. This is normally called environ by convention, and is passed in to your application via your top-level WSGI callable. To make the PercentMobile tracking code work, you need only make one call to the percentmobile.tracker_cookie_insert function. It returns two values: the cookie that you’ll need to set in the HTTP response headers, and the HTML that you should insert into your page.

Say, for example, you had a very simple WSGI app. This responds to requests with an HTTP 200 status code, a single header and some simple HTML:

def my_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/html')]
    start_response(status, response_headers)
    return ["Hello world"]

To add PercentMobile tracking to this code, you need to firstly import the tracker library of course, and then call the tracker_cookie_insert function:

import percentmobile
cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')

(Of course you should replace the final string with your own site ID!)

The cookie return value is actually a dictionary of the different parts needed to construct its string serialization. This will allow you to splice together multiple cookies, or alter the expiry time, path scope and so on. To convert the dictionary to a string, and to get the Set-Cookie header sent back in the request headers, the following code will suffice:

cookie = "%s=%s; expires=%s; path=%s" % (
    cookie['name'],
    cookie['value'],
    cookie['expires'],
    cookie['path']
)
response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]

Finally, you need to make sure the HTML fragment, in the insert variable, gets placed in the HTML response:

return ["Hello world %s" % insert]

And that’s a wrap. The whole, PercentMobile-tracked WSGI application looks like this:

def my_app(environ, start_response):
    cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')
    cookie = "%s=%s; expires=%s; path=%s" % (
        cookie['name'],
        cookie['value'],
        cookie['expires'],
        cookie['path']
    )
    status = '200 OK'
    response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]
    start_response(status, response_headers)
    return ["Hello world %s" % insert]

Pretty easy, huh? Well, not as easy as tracking an app if you’re using the amazing Django framework! Contained in the same percentmobile.py file is a class that can be used as Django middleware. It uses the same underlying function as the WSGI implementation, but also takes care of the headers and insertion for you.

Assuming you’ve placed the library file in your Python or Django path, you simply need to add two lines of code in the settings file. Firstly add the percentmobile.PercentMobileDjangoMiddleware class to your list of middleware:

MIDDLEWARE_CLASSES = (
    ...
    'percentmobile.PercentMobileDjangoMiddleware'
)

And secondly, add your PercentMobile site ID to the settings file too:

PERCENTMOBILE_SITE_ID = '1234555'

Um… that’s it. The middleware will intercept the request, figure out the cookie that will need to be sent in the response, create the insertion code, and place it just before in the response. You’re golden. I love Django.

ASP.NET: C# & VB.NET

Switching over to another world altogether, let’s take a quick look at the ASP.NET implementation of the tracking code. One of the great things about .NET is that you can choose between all sorts of different languages to write your applications and pages in. I decided to write the tracking library in C#, but you can use it declaratively in your page code, or programmatically from C#, VB.NET, or any other supported language.

The library is implemented as a User Control – that is, as a .ascx file. You need to download and add PercentMobile.ascx to your web application project.

To embed the tracking logic into a page (or probably preferably, a master page), you simply register the user control as residing in that file:

<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>

And then embed the control straight into the .aspx file contents, wherever you want it to be:

So a simple, tracked .aspx file might look something like this:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>


    Hello World
    
        
            Hello World

To be honest, this is so simple that I would expect most people to use the control declaratively. But if, for some reason, the control needs to be inserted programmatically, that’s pretty easy too. You need to use the Reference directive, instead of Register, at the top of the file, but otherwise it’s not much harder. Here, we’re using VB.NET to programmatically achieve exactly the same result as above:

<%@ Page Language="VB" AutoEventWireup="true" %><%@ Reference Control="~/PercentMobile.ascx" %>




    Hello World
    
        
            Hello World

(It should be fairly straightforward to see how to do this in other .NET languages – PercentMobile includes some examples in their install instructions.)

Java

Onwards. Let’s take a look at the tracking code for Java. There are numerous ways in which Java can be used for web or application server environments. To keep things simple, I decided that supporting JSP was more or less the most familiar and reusable approach.

JSP doesn’t enjoy the rich page event model that I was able to use in ASP.NET to intercept headers, write cookies, and insert HTML, all with one include. is OK for adding the HTML snippets, but wouldn’t let me access the HTTP headers. does, but would only work if you weren’t planning to emit any HTML of your own after the tracking code – something of a radical assumption.

So I settled for an approach where an include directive creates an instance of an inner PercentMobile class defined within the JSP class. To cut a long story short, this means you merely add a reference to the library file at the top of the JSP file:

<%@ include file="percentmobile.jsp" %>

And then call the track method on that instance, somewhere within the page:

<%percentMobile.track("1234555");%>

The included JSP file takes care of instantiating the percentMobile object and giving it references to the request and response stream. This means it can read and write cookies, and later emit HTML. Your tracked Hello World in Java then? It’s as simple as this:

<%@ include file="percentmobile.jsp" %>
 
  
    Hello World
    <%percentMobile.track("1234555");%>

node.js

OK, OK. Python, ASP.NET, Java. No big deal, right? That’s all so 2003 or so, right?

Well, there’s an alternative future for web server technologies. It’s one that’s blazingly fast, lightweight, event-driven, and… where you write your server logic in Javascript.

node.js is one of the most exciting things I’ve seen for a long time, and I know I’m not alone. Fresh, fashionable, and somewhat unproven, admittedly, it’s had a lot of gushing coverage. But since it turns the web server model (almost literally) inside out, I do believe there’s something important going on.

Would it be possible to write a web app with node.js and still have it tracked by PercentMobile? My challenge.

I decided to rely on Connect, a middleware framework for node.js, which, if you are writing web applications, provides a whole host of other helpful web logic. Using Connect to create a simple node.js app is extremely easy:

var Connect = require('connect');
Connect.createServer(
  function (req, res, next) {
    res.simpleBody(200,
      "Hello World" +
      "",
      {
        "Content-Type": "text/html"
      }
    );
  }
).listen(88);

To add PercentMobile tracking to this application firstly requires you to pull in the PercentMobile module:

var PercentMobile = require('./percentmobile');

(Where the percentmobile.js file has been placed in your node.js environment or in the common modules location.)

The module needs to be initialized as a piece of Connect middleware in the createServer function:

PercentMobile.init('1234555')

There are then two module functions, cookie and html, which both take a reference to the response object, and which return the cookie string and HTML to insert, respectively. These can be used in Connect’s simpleBody function, for example, meaning that our tracked application is as simple as this:

var Connect = require('connect');
var PercentMobile = require('./percentmobile');
Connect.createServer(
  PercentMobile.init('1234555'),
  function (req, res, next) {
    res.simpleBody(200,
      "Hello World" +
        PercentMobile.html(res) +
      "",
      {
        "Content-Type": "text/html",
        "Set-Cookie": PercentMobile.cookie(res)
      }
    );
  }
).listen(88);

That’s a wrap

So that’s it. A whistle-stop tour of the new languages and frameworks supported by PercentMobile. I’d love to hear your feedback on how easy (or hard!) these new APIs are to use.

And, oh… who will be the first to build a mobile web app on node.js?

WhitherApps

James — Sun, 08 Aug 2010 03:10:20 +0000

Why spend your life recompiling native client apps when you have HTML5 and the mighty mobile web at your disposal? WhitherApps sets out to debunk some contemporary mobile myths.

WhitherApps is a bandwagon-busting experiment. I believe there are far too many native client apps which could have been far better written as mobile web apps. What I’m trying to do with the project is take a few particularly obvious examples, apply a little reverse-engineering, and rewrite them, warts and all, with web technologies.

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!

Mobile Trends 2020 – a brief review

James — Sat, 09 Jan 2010 22:35:26 +0000

A curious affliction of the mobile blogosphere is its propensity for annual predictions about what will happen next in our industry. It’s a badly-kept secret that this frustrates me. Mostly because:

A year really isn’t a very long time, whatever the cliché tells you… very little surprising happens in 12 months an industry dominated mostly by large companies and continuous market dynamics.
It doesn’t take a lot of research into any topic to be able to make a handful of sensible predictions about it. (Flat rate tariffs more common? Really? I should think Antarctic will thaw quicker than last year too, and there will be progress in HIV research.)
They’re rarely actionable. I’m unlikely to buy shares on such vague tips, and I can’t wager against their accuracy at my local bookmakers. Do these lists exist to bolster the reader’s wealth or knowledge? Or perhaps demonstrate how perceptive the writers think they are?
Wouldn’t it be better to spend the same effort actually helping to make the future come true in the first place?

But this week saw the publication of a collection of 40 or so pundits’ predictions mobile trends for the coming decade. Should I dislike this 400 times more? Well, fortunately no! Ten years gives more room for the predictions to breathe, and the collective nature of the project should mean broader trends can be spotted.

The document is curated by Rudy De Waele, for whom I have lot of respect. He’s got the enthusiasm and boundless energy that fits well with the promise of mobile. It must have taken a fair bit of effort to pull this project together: a set of slides containing the predictions from a large number of contributors. The document has already been very successful and well circulated. And there are some very clever people involved.

In choosing the contributors, Rudy describes them as his personal ‘mobile heroes’. Fair enough – but how has that affected the overall roundedness of the project? This, to me, is potentially a worry.

For example, it might have been interesting to have heard from at least one handset manufacturer. This will be a decade of bitter rivalry in that market between the old telecoms guard and already-successful new entrants. Exciting times: and I would love to know what the contenders foresee? And only 3 network operators? However conservative their ambitions, the networks’ plans and predictions are quite likely to shape mobile’s decade somehow.

Facebook is a good scalp – although not as revealing as I’d hoped – and so are the financier contributions. Most of the remainder of the contributions are from small startups, bloggers, authors, entrepreneurs, ‘strategic thinkers’ and ‘keynote speakers’.

Now, I have nothing against such individuals (since I know many of them, they’re very smart, and that’s how I’d probably describe myself too!). But having so many casts a slight pallor over the project: the patina of the developed world’s well-trodden mobile conference circuit. Punditry that’s been trotted out for years: affluent, Western, urban- and professional-centric reflections of how we’d like the industry to fulfill our own personal use-cases.

This is a shame. I wanted this document to surprise me more. The entire world – economically, politically, climatically – will change a lot in ten years. I would expect the mobile medium will flex to adapt to those seminal changes far more interestingly than it does to some tactical contemporary challenges.

In the same vein, a missed opportunity may have been to look further abroad. True, there are valid mentions of mobile’s cultural impact in Africa, but try keyword-searching the document for ‘China’, ‘India’, ‘Brazil’, ‘Russia’ (or even ‘Japan’!) and you’ll be out of luck. Who thinks nothing of interest will happen in those places in the next decade? (Now that would be a surprise).

This all made the predictions, a little, erm, predictable. Yes, yes, I think we all know battery technology will improve, but who was brave enough to make predictions like this?:

most mobile web sites in 2020 will be in Chinese
at least one major European operator will have been bought by an Indian conglomerate
the Rio De Janeiro Olympics’ web site will have more mobile visitors than non-mobile
Google’s home page will default to being mobile in all countries except the US
roaming agreements will be used as collateral in carbon trading markets as the mobile-wielding populations of low-lying countries are resettled

Crazy? Sure. But these are just off the bat. I think the aims of such a project should be to inspire, question and provoke. Don’t give me some short-term platitudes about app stores and widgets. At least not when history is on the move like it will be in this decade.

OK, so perhaps I’m protesting too much. Despite these flaws, there are some real gems to be found in this document. “Digital syllogomania” is a brilliant piece of insight. A few touch on the very likely “always-on backlash”, and the promise of mobile-device-as-sensor is tantalizing. I also applaud those predictions that wonder whether mobile technology can change basic human behavior. I’m doubtful, but it’s a good question. As Tom Hume asks: “What happens to conversation when it’s all recorded, or any fact is a 5-second voice-search away from being checked?”

Anyway, it’s a few days old now, but do go read the document here. And more importantly, make up some of your own. Even more importantly, go and try make them happen. “It’s good to talk”, but the mobile world in the next decade probably belongs to those who make. And those who make the predictions come true.

The WordPress Mobile Pack is back! And here’s how.

James — Fri, 18 Dec 2009 19:13:09 +0000

Just a quick post to confirm that the WordPress Mobile Pack plugin is back online at wordpress.org.

Most WordPress plugins, if ‘GPL-compatible’, are hosted on wordpress.org – it provides an easy way for people to view and upgrade them. The increasingly popular Mobile Pack is no exception, and we’ve been happily listed there for over 6 months.

But what do you do when it suddenly disappears? About 3 days ago, that’s exactly what happened. I’m the administrator of the plugin and could see it when I logged in. But suddenly none of my collaborators – nor the general public! – could see or download the plugin.

Our sole channel for software distribution had mysteriously dropped into a black hole – without a word of notification from WordPress themselves.

Assuming it could only therefore be a bug with the wordpress.org web site, I filed a number of support tickets. No response.
Assuming it could only therefore be a permissions or licence issue, I raised a number of forum threads on the site (as, kindly, did Dennis Bournique, over at WAP Review). No response.
Assuming I was somehow falling between the cracks, I even emailed Matt Mullenweg. Less surprisingly, no response. UPDATE: I received an apology shortly after this post.

Hmm. All rather unsatisfactory.

Well, this morning, a breakthrough. My WPMP partner in crime, Andrea Trasatti thought of joining the WordPress IRC channel. (Obviously he’s a bit more old school than me). But finally found someone who would be prepared to answer the puzzle.

At this point, I need to point out there there are (true!) other mobile plugins out there. One particularly popular one has been Andy Moore‘s. He hadn’t hosted his on wordpress.org due, I guess, to his choice of license, and his – disclosed – use of automatic ads in the resulting pages, which WordPress does not permit.

For whatever reason, Andy recently closed down his plugin’s page, and had kindly redirected it to ours. This probably accounts for our nice increase in traffic in mid-November. Thanks Andy!

However, one of Andy’s previous plugin downloaders apparently complained about an error message they had received. The WordPress administrators investigated by visiting Andy’s site, and of course got redirected to our Mobile Pack page. Thinking our plugin was at fault, they then disabled our plugin for violating the no-ads rule.

Oh, and no-one thought to drop me an email to tell me.

But Andrea’s investigations and protestations prompted us to get re-approved, and we’re back!

(In the process of investigating this, it also turns out that when WordPress says ‘GPL-compatible’ and points you to a list of licenses, that doesn’t mean much at all. You also have to work out that they actually mean ‘GPL2-compatible’, and not ‘GPL3-compatible’, as our more permissive Apache license is. So I guess we’ll have to change our license too – which is a shame.)

I don’t think WordPress covered themselves with glory here. In the interests of constructive criticism, I would suggest the company should:

Inform a plugin owner whenever there is a complaint raised against it. I would have been able to point out the complaint was aimed at a different piece of software.
Inform a plugin owner when – or better, before – disabling a plugin from the listing. I could have had a grace period to have investigated any issues, rather than hear it first as complaints from users.
Respond to ‘site bug’ tickets raised on the site.
Make the licensing requirements for plugins more clear. The phrase ‘GPL-compatible’ here, (and its link), is certainly not precise enough.
Remember that plugin authors work hard to support your business of running the most popular blog platform in the world. Those individuals’ reputations, to a fair extent, rest on your responsible syndication of that code, and they get the grief when you pull the plug.

Anyway, thanks guys (and Mark in particular) for putting it back. And special thanks to Andrea, who now overtakes me in the chocolate-for-favours race.

Now… back to the roadmap of Mobile Pack coolness. Stay tuned.

WordPress Mobile Pack v1.1

James — Wed, 15 Jul 2009 10:14:09 +0000

The dotMobi WordPress Mobile Pack is a complete toolkit to help mobilize your WordPress site and blog.

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…

Simple ‘on-server’ mobile AJAX in Django

James — Wed, 17 Jun 2009 11:30:52 +0000

–or–

“How your mobile site may not be much more complicated than building one with a data API or AJAX”

I am working on a project called ‘IvyRoot’ that is predominantly mobile and which is going to make me fabulously rich and famous.

OK, OK. It’s predominantly mobile, at least. It’s all in Django.

There’s a ‘desktop’ web site to go with it, and this contains panels within pages. Some of these panels might take a few moments to process and so I use XHR to call back to get them once the main page has loaded, displaying a pretty spinning icon in the meantime.

I also use XHR to populate in-page tables which might have many rows – so that pagination and sorting are fast without having to load the whole page again.

I also want to expose a number of data APIs (providing XML, JSON, basic HTML and the like) so that people can build 3rd party clients, their own consuming sites, and widgets.

Finally, I want to provide a mobile web version of the site. I’ll probably do some sort of device detection to refine the behaviour, but I should assume that plenty of browsers will not be able to do the XHR bit, and should have the page (containing all the panels) in one go – admittedly after a slightly longer wait.

Well, it occurs to me that these requirements can all be solved at the same time. Switching templates based on URL (or other HttpRequest clues) is pretty easy, so one thing I could do is have a filename extension convention for all my URLs. Imagine a ‘things’ view that lists things.

http://ivyroot.com/things – this is the human-consumable page: the view surrounded by menus, logos, graphics and the like. Knows how to switch outer template, based on various things, between desktop and mobile.
http://ivyroot.com/things.html – this is the table at the heart of the page, perhaps using unstyled markup containing the list of things itself.
http://ivyroot.com/things.xml, http://ivyroot.com/things.json etc – data APIs that list things in various serializations.

So perhaps we can set up URL routes like this:

...
(r'^things$', things),
(r'^things.(?P[a-z0-9]+)$', things),
...

And have a view that looks something like this:

def things(request, mode=''):
    if not mode:
        mode = desktop_or_mobile()
    template = "things.%s" % mode
    ...

(Or, I suppose we could pass the mode into the template via the context and have some sort of a switch statement in the template itself. It might be good to pass it in, anyway, in case there is any further refinement required within each template.)

Anyway, let’s also assume that the things list is very long and takes a while to generate. For the desktop users, we might want to either load the table as HTML asynchronously using XHR, or paged into a jQuery grid control. For these two approaches, I can call back to /things.html or /things.json respectively (and do a little extra plumbing to make sure the JSON is in the right format for the grid control to consume).

But what of mobile? Well, for many devices, I can’t expect any XHR activity to be supported, so we need to insert the table HTML into the body of the things.mobile page before it departs for the client – and we may need to pre-page it too (if it’s long). But the good news is that, if I made it simple enough, the HTML generated by things.html might be good enough for either type of browser.

(And if not, I could easily do a little adaptation on that view too – perhaps turn my table into a list.)

So what I would like to have a is a way of embedding the output of one view (or even URL) into another, whilst the response is still being put together on the server. Try as I could, there didn’t seem to be anything in Django to do this.

Enter my first DjangoSnippet!

This basically allows me to put a template tag into the mobile template that pulls the output from one of the other views (identified by view name, with arguments; or a verbatim URL which would be the same as the one used in the desktop’s XHR request – nifty!)

It also makes sure that the context for that view is sandboxed with what it needs to render itself – so that I don’t have to worry about getting the context ready in the ‘outer’ view. That’s not necessary in our simple example above – but it might be useful later on if I am dynamically choosing which panels to place on a page, and I want them to gather together their own context prior to template rendering.

Now, I’ll need to be careful to make sure that any interaction elements within the table – say, some actions available on each item in the list, or a paginator – behave suitably for their location. But this may be as simple as toggling between further XHR requests (for desktop) and simple anchor links (for mobile). Forms-in-panels will be harder but similar.

So… there we are, a glimpse at the inner workings of a mystery application that’s many weeks away from seeing the light of day.

But hopefully I’ve raised a few thoughts about how you can treat the mobile version of your site as being a cousin of the data APIs that you might have written anyway. And also how you might be able to sneakily bring some of the funky XHR – that you wanted to impress your friends with on the desktop – up into the server to keep your mobile pals happy too.

Maps & mobile

James — Tue, 07 Apr 2009 17:29:44 +0000

I’m somehow dissatisfied with mobile cartography.

On the Hollywood Walk of Fame site, we’re currently using Google Maps. When I first saw Google Maps on the web, I was thrilled with the cartography. The craft of good map-making started to shine through after a decade of turgid MapQuest vectors.

(In a previous life, I lived for maps… so I take this very seriously!)

And on HWOF, sure, it does what it should. The now-familiar style has a comforting effect for users I suppose.

But, both with and without the ‘mobile’ option set in the API (shown on the right – worse I think!), and despite the huge watermark on the limited real-estate, I’m personally tiring of it.

Maybe it’s the burnish of familiarity. I’ve seen this style so much that it holds no allure or beauty any more. Maybe because it appeals more to drivers than pedestrians. Maybe because of the uninspiring Arial font. Or maybe just because I’d like to be more in control? All of the above.

Anyway, I’ve started to look at alternatives. On one hand we’re looking at some commercial possibilities with other map (and location data) providers.

But on the hand, I’ve been sucked into the thought of using CloudMade. Built on top of the excellent OpenStreetMap project, it allows everyone to become a cartographer – or at least, to apply new themes and styles to the map structures from OSM.

A great example? Check out Matt Jones’ lovely map:

Which, interestingly, immediately made me think of John Speed:

Nothing new in the world, eh?

Anyway… this is now interesting. I’m no graphic designer, but I’ve done my fair share of map-making. I do know how to make important features rise to the foreground. And make irrelevant aspects fade to the back. Serve specific purpose. A map is not just a dry record of geographic fact: it should be created entirely with the context of the user in mind.

Hey! Just like mobile web applications.

So I am on a crusade to in find the perfect mobile map. A cartographic style that jumps out of a handheld screen. A visual vocabulary that caress a mobile user’s spatial awareness. Maps that blend seamlessly into the device’s user interface, rather than merely rectangular crashups. A panache that brings vectors to life. That crosses the boundary into art.

And that can do so, effortlessly, in 176 pixels or less.

The world is full of brilliant maps of many kinds. But do any of them cut it in the mobile medium? Is that medium so different that we have to start again with some of our cartographic assumptions? Will I ever be satisfied?

Well, I don’t know yet. But I do know that I’m going to have a lot of fun fiddling with CloudMade.

What’s your favourite mobile map, cartographic style or service? And why?

New blog design & apologies

James — Sun, 29 Mar 2009 23:05:02 +0000

Welcome to my new blog theme. It includes a pseudo-portfolio for my various mobile activities in 2009.

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.

Python Google AdSense for Mobile code

James — Fri, 20 Mar 2009 20:27:21 +0000

I was amazed to discover that Google don’t currently support Python as a language for their mobile ads. AdMob doesn’t either (thinking it’s more likely that people might use perl or VBScript for a contemporary web site).

But it’s a particularly strange omission for Google, since it’s one of their three ‘official’ internal languages (together with Java and C++), and because their Google App Engine platform mandates it. Do they assume that no-one would create a mobile application in their cloud?

I don’t know – it’s probably just left-hand and right-hand out of sync.

Anyway, The Hollywood Walk of Fame mobile site has been a recent hobby for me, and I chose Django on Python for a bit of educational fun.

It was going well until I decided to throw some ads onto it.

So of course I needed to port the ad code. It’s very simple, although cuts a few corners (this does not support AdSense’s custom colour feature for example):

def google_ad(request, publisher_id, format='mobile_single'):
  scheme = 'https://' if request.is_secure() else 'http://'
  params = {
    'ad_type':'text_image',
    'channel':'',
    'client':'ca-mb-' + publisher_id,
    'dt':repr(floor(1000*time())),
    'format':format,
    'https':'on' if request.is_secure() else '',
    'host':scheme + request.META.get('HTTP_HOST', ''),
    'ip':request.META.get('REMOTE_ADDR', ''),
    'markup':'xhtml',
    'oe':'utf8',
    'output':'xhtml',
    'ref':request.META.get('HTTP_REFERER', ''),
    'url':scheme + request.META.get('HTTP_HOST', '') + \
          request.META.get('PATH_INFO', ''),
    'useragent':request.META.get('HTTP_USER_AGENT', '')
  }
  screen_res = request.META.get('HTTP_UA_PIXELS', '')
  delimiter = 'x'
  if screen_res == '':
    screen_res = request.META.get('HTTP_X_UP_DEVCAP_SCREENPIXELS', '')
    delimiter = ','
  res_array = screen_res.split(delimiter)
  if len(res_array) == 2:
    params['u_w'] = res_array[0]
    params['u_h'] = res_array[1]
  dcmguid = request.META.get('HTTP_X_DCMGUID', '')
  if dcmguid != '':
    params['dcmguid'] = dcmguid
  url = 'http://pagead2.googlesyndication.com/pagead/ads?' + urlencode(params)
  return urlopen(url).read()

I presume I’m allowed to do this, I know it’s only 15 minutes saved – but if it helps someone, great. No warranties – but it works for me!

Incidentally, in Django, I am placing this in a context_processor so that it gets put into a template variable that I know will turn up in every view when the site is in mobile ‘mode’. I use a switcher like this to toggle between http://hwof.com and http://hwof.mobi.

Hm. This post looks terrible in this theme. I think I need to change WordPress template soon.

A mail I couldn’t send

James — Mon, 09 Feb 2009 16:43:30 +0000

After someone I respect got banned from the WMLProgramming mailing list, I wrote to agree with one or two other members who were disappointed with the state of affairs.

I’ve been a member since, I guess, the first few weeks of the group’s existence – even if I haven’t been a day-to-day contributor. Sadly it’s gone downhill over the last year or so.

Why? It’s a long story. The mobile developer community has a desire to have a strong position on unprovoked content transformation. This is a good thing.

But the approach taken to get their message across involves some of the most inflammatory, derogatory, and unprofessional behaviour I’ve ever seen online. This is not a good thing.

I was disappointed that the reputation of the group was sinking so low. It also occured to me that, as a member, this behaviour was implicitly in my name.

But not for long! I was promptly banned from the group. Well, I suppose I was leaving anyway, so maybe it was no big deal.

But shortly after, a rather rude mail was written in response, making some outlandish claims about some corporate conspiracy I’m supposed to be part of. But could I respond? No! I’d been banned. I guess to make sure you get the last word, the best way is to limit the other party’s ability to respond.

So anyway, I don’t really want to labour the point. But here’s what I wrote as my last post to the group and couldn’t send – thanks to the membership button being grayed out.

After all that fruitless typing, and in the interests of free speech, I just feel it needs to see the light of day somehow

—————————————-

Luca,

You do indeed deserve huge thanks for the many years of hard work and success. The manifesto and it could have been a memorable agent for good on behalf of the industry as a whole. It may still become so.

I fully admire your goals, but with them comes an attitude that ruins the external reputation of the group – and the chances of those goals ever being met. Further, the reputation of the group is projected onto its members.

That is why I’m leaving. This brand of militarism does not represent my broader interests in the growth of the mobile web.

Let me also state clearly that my opinions about the situation have absolutely nothing to do with my recent employer or its investors: I’m sorry to disappoint you, but there really is no conspiracy.

I hope that one day this famous list will return to being positive and friendly again.

(Doubtless you’ve more positive and friendly things to say on the matter too. But since you banned me, do note I won’t be receiving further replies.)

James