Simplicity is the ultimate sophistication”
– Leonardo Da Vinci (disputed)
Important Note (April 2014): If you are interested in using WURFL from Javascript, you may want to check out WURFL.io (or this blog post).
Steve and I were at the awesome Breaking Development Conference last week in Dallas, Texas. What an amazing stand-up of great speakers (and what an amazing chance for networking!).
The presentations covered quite a lot of ground and a variety of topics. Some speakers gave their more high-level “long term” visions of where mobile is going and how every device (including your toaster) will be communicating with whatever else (but not through Bluetooth). I found those talks interesting, but also, I find those speakers very brave: how can they go out on a limb and say those things with no fear that someone will actually verify if their prophecies actually came true one day?
As a quick aside, about one month ago, all of Norway was laughing about a 1996 article that stated how the Internet was a complete flop and divined that it would never conquer a place in more than 1% of the households (English translation). For the record, Leif Osvold, the author, subsequently has admitted that he was wrong.
Jokes apart, I loved the other face of the BDConf even more. That’s the speakers who share real hands-on experience on how to build mobile sites and overcome the challenges of the kind that they encountered along the way. La creme de la creme of mobile web bloggers and professionals can be found at BDConf and the audience listen to them religiously. Not surprising. Content is king and those guys (and girls) are the high priests of total sense-ness.
It was the first time at BDConf for me. What I recalled from reports of previous editions was a lot of attention to Responsive Web Design. This was of course still the case, but Server-Side Detection has been added again into the diet of mobile web developers: I did not hear anyone disagree that RWD/Mobile-First (client-side) and Device Detection (server-side) are both useful tools in the arsenal of mobile developers. At the end of the day, it is a matter of choice and developers picking what cuts it for them.
More specifically about the RWD vs Server-side discussion, Ronan Cremin was one of the speakers. Ronan works for our commercial competition, but, credit where credit is due, he went on stage with a pretty decent set of slides that made a basic point clear: people access the web on desktops, tablets, phones, TVs and their wristwatches. Input methods vary wildly: touchscreen, clickwheel, keyboard&mouse, remote control, D-PAD and who knows what else. In this contest, a responsive approach can only bring you so far.
But Ronan was not the only one to put RWD in context. Brad Frost (who wrote an awesome RWD tutorial at some point), surprised the audience with a spectacular “Users don’t give a s**t if your site is responsive” slide all by itself (see slide 159) . I couldn’t agree more, so I had to clap my hands, albeit in solitude.
Coincidentally, an article by Ronan Cremin and me on exactly this topic was published by Smashing Magazine during the conference days, and that article contains the same points raised by the two speakers above.
The editor of Smashing Magazine had warned me that the discussions about the merits of client-side vs. server-side can quickly get religious and very heated. I did not come across any of that religiosity at BDConf, though. But Steve observed something else. Web/Front-end developers are not always as proficient with server-side languages (such as PHP or Java) as one might assume. They are more likely to be familiar with JavaScript (in addition to HTML and CSS, of course). In this context, isn’t the discussion between RWD and WURFL a direct corollary of the old “when all you have is a hammer, every problem looks like a nail”? and of course, doesn’t this apply also the other way around, with backend developers favoring a solution to device fragmentation that leverages the tools they know best? mmmm…food for thought…
On our way home, 20,000 feet above the earth, I was discussing with Steve about how we can do more to expose WURFL capabilities to JavaScript. Steve correctly objected that this is already possible today and has been possible since forever. After all, any developer worth their mettle knows how to use JSP, PHP, or whatever else to spit out JavaScript. This is correct. On the other hand, showing a different way to do it may be inspirational to those people who eat and breath JavaScript every day. Let us not underestimate the implicit power of <script src=”..”> to import external resources without implications on how the main HTML page is generated.
Bringing JavaScript Higher
Here is today’s problem. Let us assume that we want to know whether our page is running inside a smartphone phone (but not a tablet). Also, assuming it is a phone, we want to know what the device’s actual make, model and marketing name (if available) are. Finally, we want to capture that information inside a JavaScript object “wurfl” as properties:
is_smartphone
is_tablet
brand_name
model_name
marketing_name
These capabilities can be accessed like “wurfl.is_smartphone”.
Developers familiar with WURFL know what to do. Just embed that JavaScript generation directly into your PHP page. So we will raise the bar slightly. Let’s assume that the site is managed through some legacy CMS, and the PHP code that defines the templates cannot be modified by the front-end developer, while anything JavaScript can be.
Mmmm…things get more interesting now.
We can create a separate PHP page, on a different web server, that uses the WURFL API (either standalone or in its Cloud incarnation) that generates JavaScript (mime type text/javascript) and looks something like this:
<?php
require_once dirname(__FILE__).’/../Client/Client.php’;
header(‘Content-Type: text/javascript’);
header(‘Cache-Control: no-cache, must-revalidate’);
header(‘Expires: Sat, 26 Jul 1997 05:00:00 GMT’);
$config = new WurflCloud_Client_Config();
$config->api_key = ‘879060:XK8cG1Rq6NSDLdAIsCkuPeFhVfnnDlvE’;
$client = new WurflCloud_Client_Client($config, new WurflCloud_Cache_Null());
$client->detectDevice();
$capabilities = array(
‘is_smartphone’,
‘is_tablet’,
‘brand_name’,
‘model_name’,
‘marketing_name’,
);
$out_data = array();
foreach ($capabilities as $cap_name) {
$out_data[$cap_name] = $client->capabilities[$cap_name];
}
$json_data = json_encode($out_data);
echo “wurfl = $json_data;n”;
exit;
?>
When it comes to importing those JavaScript values in the page, this is as simple as:
<script src=”//server.mysite.com/talkToCloud.php”></script>
EXAMPLE HTML:
<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″>
<title>WURFL from JS Example</title>
<script src=”/WurflCloudClient-PHP/temp/wurfl-js.php”></script>
</head>
<body>
<h1>WURFL Capabilities:</h1>
<ul id=”capability-list”></ul>
<script>
var list = ”;
for (var cap in wurfl) {
list += “<li>” + cap + “: ” + wurfl[cap] + “</li>”;
}
document.getElementById(‘capability-list’).innerHTML = list;
</script>
</body>
</html>
At this point, the front-end engineer is able to use WURFL capabilities just as easily as he would use any other JavaScript variable.
A Note about the Example
The code above assumes the use of the Cloud Client and the use of the PHP programming language, but it goes without saying that the example can easily be ported to any of the standalone APIs as well as any of the other Cloud APIs (Java, .NET, Ruby, Python, Node.js and soon Perl). And of course, any WURFL capability can be exposed, not just the ones we mentioned in the example (if you have a patch file, you can expose the capabilities from your own patch file).
Cloud users should further observe that the capability they pick must be enabled in the WURFL Cloud control panel.
Conclusions
We had fun at BDconf and you can use WURFL where you may not have expected it. In case you are curious, the next BDConf will take place in Orlando, Florida, in April 2013.
Enjoy
Luca Passani, CTO @ScientiaMobile, with contributions from Steve Kamerman, COO @ScientiaMobile
