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.
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.
–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.
