–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<mode>[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.
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.
vs 
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?
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.