Imagine if YOU controlled YOUR data.

If you could update it in one single place and Government Departments/Agencies could just collect it from there.

Imagine if this central data store gave you MORE privacy.  You could control which fields different Departments/Agencies were able to access and you could control if they could personally identify you or just use generic information like your age or postcode.

Imagine if it automatically created a log of each time a Department/Agency accessed your data and you could set the option to allow you to control that data – imagine it sent you an email or SMS and you could allow or deny them using important parts of your private data.

Imagine if you could start by just putting in simple information that you currently have to re-enter a million times like your home address, your phone number and email addres, your age, gender and marital status.  Then if you chose to you could add other information like medicare number and TFN – but it was YOUR choice – and YOU could turn on and off a Department’s access to those specific fields.

Imagine if every government web form you went to gave you the option to auto-populate your details – IF YOU WANTED TO – but it was completely your choice.

From the Department/Agency perspective.

Imagine if you could rely on easily getting people’s up-to-date contact details in a simple and secure way.

Imagine if you could integrate it into your existing websites/web forms without changing any of your pages or back-end systems – unless you wanted to.

Imagine if you could improve the auditability of your use of personal information while improving the quality and freshness of your data too.

Imagine if you put your users in control of their own data…but it also made your life simpler and better!

Imagine if you had a long term strategic vision of user data management that you could deliver today but that would help you evolve and adapt over the next decade and further.

But do people really want this?

According to Interacting with Government – Australians’ use and satisfaction with e-government services review from 2008 I believe they do.

two-thirds (68%) would still prefer the convenience of updating information (such as change of address) for government only once

http://www.finance.gov.au/publications/interacting-with-government/08-security-and-privacy-issues.html

Sure over half (57%) claim they would prefer complete anonymity and are happy to re-enter their data – but I believe that’s because they’re NOT AWARE of any options that can deliver both improved privacy/security AND convenience. Surely an secure system that was optional and also provided an audit log of when Government Departments/Agencies accessed your information would be something a civil libertarian would embrace.

What magical solution would achieve this flight of fantasy?
There are many ways this cat could be skinned – here I’d like to propose one of them at a very high level. If enough interest is shown in this idea then I’d be happy to map out the architecture and key sequence diagrams and user journeys to take this discussion to the next level.

Here’s one way it could be achieved.
I believe that a simple OAuth data store could be setup that would enable much of this functionality. It could be wrapped in a simple Mobile and PC web application that allowed users to control and manage the OAuth tokens they authorise.

I also believe it would be possible to create a simple jQuery plugin that could simple be integrated into existing Gov. Department/Agency webpages by just adding a single line of HTML code. This is very similar to the simple User Voice feedback buttons that are spreading across sites like wildfire – exactly because they are so simple to integrate. This plugin would add a visible button or element to the page (much like the User Voice feedback tab) that would offer the user the chance to pre-populate the form on the page they are currently on. The plugin would then manage all of the OAuth data store’s signup and token creation/authentication processes using Ajax and DHTML for overlays. It would then map the common fields from the users OAuth data store into the fields on the page (e.g. using something like JSONT rules that could be quickly customised for each form). In this way the underlying form and server-side scripts would not need to be changed at all.

If this model then did gain traction, over time Government Departments/Agencies could upgrade and integrate their back-end systems more closely with the central OAuth data store.

There is a lot of technical and user experience detail that needs to be discussed, however I’m confident that a simple proof-of-concept or prototype system could be created in a very short time. I also believe that all of this could be completed as an Open Data and Open Source project that would allow for peer-review for security enhancement and API based integration for developers to extend and enhance.

Personally, this is something that I would use, however I’m very concerned that the output of the Gershon Review and the existing Government Architecture is very “big vendor” and “internally” focused. Opening up control and externalising this core data seems to be currently sitting in the “too hard” basket.

Sure, not everyone would use it and they wouldn’t have to. And sure, not everyone has a javascript enabled browser. But if you don’t then you’re not likely to want to even think about a central data store and audit logs either.

Now, feel free to tell me I’m a dreamer – but please be prepared to back that up with detailed descriptions of WHY this wouldn’t work!

I would recommend changes to 2 sections within the AGIMO Web Publishing Guide.

First, I’d remove RSS from the Technical Development section and create a separate section entitled Open Data and Application Programmer Interfaces or just Open Data and APIs.

This would then be the logical home for the RSS link and should be fleshed out to include Open Data expectations or policies and discussion around common Web Service Interface topics such as SOA, REST, XML-RPC, JSON-RPC, etc. and even SOAP for legacy systems and from my perspective SOAPjr for modern Ajax driven applications

I will not propose here the exact structure I think this should be as that’s really a call for AGIMO, however there is a wealth of existing information in this area and I along with a wide range of other developers would happily engage in an Open Data discussion to help this process along.

The second recommendation I would make would be to bind the content of the Accessibility and Equity section to this new Open Data and APIs section in a deep and intimate way.  Both at a guideline content level and also at a policy level.

Open Data and APIs are the un-recognised foundation of true accessibility and equitible access.  If you simply encourage developers to create WCAG compliant sites then you are fixing your accessibility benefits in cement – at a certain cultural point in time.  However if you encourage or require developers to first deliver Open Data and APIs then you have enabled any other group or developer to then create new and targeted services that meet the needs of the group they are interested in or are a part of.

This cliched old proverb seems relevant and insightful again in this particular context:

Give a [person] a fish and you feed them for a day
Teach them how to fish and you feed them for a lifetime

This is also increasingly relevant as the “browsing device” landscape fractures even further.  Plain Old Mobiles (POMs), iPhones and the flood of new devices will be enabled by this and our burgeoning new market will be supported instead of constrained.

There two follow up points to this discussion.

1. I am NOT recommending that focus be removed from WCAG compliance.  I am merely suggesting that it should come AFTER Open Data and API requirements and I believe that overall Accessibility in all forms will be improved by this.

2. Some people may argue that this is shifting the onus from Government developers out into the community.  I would argue that this can be viewed differently.  It’s not “onus” but “power and freedom”.  Only allowing me to access the Public Data we have all paid for through applications and user interfaces developed by Government agencies is limiting my world to “what they think I want” and “how fast they can develop”.  By starting with opening up APIs you are letting me run alongside these agencies or even run ahead of them and letting me decide how, when and where I mash up this data.  For me this provides more freedom and also may free up some of the internal Government resources so they can focus on implementing these new Open Data policies instead of just trying to second guess what the increasingly diverse web user audiences really want.

As someone who runs an Innovation Lab I am aware how hard it is to predict what technologies and applications will actually be adopted and achieve wide diffusion.  For large Government Departments to also try to do this seems challenging at best.

Mobile advertising is defined as: all expressions offered on the mobile phone and paid for by
advertisers, of which the purpose is to influence the attitude, intention and behaviour of the
receiver, advertising mediums for mobile include, but are not limited to:
  * Mobile Websites
  * Mobile Applications
  * Mobile Messaging
  * Mobile Video

Overall this is a constructive and useful document that will add more clarity for advertisers, creatives and developers. However there are a few points that could be worded more clearly and a few that just seem incorrect. Since we’ve been too busy to attend the AIMIA Mobile Interest Group meetings over the last 6 months and there isn’t another one for a month I thought I’d provide the feedback in an open post so anyone else can join in the discussion and provide their own feedback. So feel free to post a comment here or send a twitter message to @nambor.

Related links

MMA Mobile Advertising Guidelines (2008)

MMA Mobile Application Guidelines (2008)

ADMA M-Marketing Code of Practice (2003!)

ADMA Code of Practice (2006!)

ACMA SPAM Act Case Studies

Feedback

A) Text guidelines (pg 4)

i) Maximum 25 characters in length (including spaces)

Surely this is dependent upon or should refer to the assumed text size.

iii) Include an Ad identifier. We recommend that the ad is clearly identified as such,
however that is up to each publisher to determine. If an ad indicator is used, it
should be provided as part of the creative.

How does this relate to i). e.g. Should the Ad identifier be included within the 25 characters? Also, especially if this is the case, shouldn’t these guidelines recommend a standard Ad identifier?

D) Creative guidelines (pg 8 )

D) Clear border and white space Include a 1-2 pixel white border surrounding the
image so it is clear when the banner/web link is highlighted

This is very very broad and doesn’t take into account that the colour of the link can often be controlled by CSS (e.g. on a dark background the host site may have set the link colour to white). This is also very prescriptive in terms of creative.

iii) Screen resolutions vary between handsets so you may need to prepare two
versions of the creative - lighter and darker versions.

Not quite sure how “screen resolutions” directly relate to contrast or “lighter and darker”? Perhaps this was meant to be “colour depths” instead of “screen resolutions”? Even then this statement is a little confusing.

iv) Test, test and test. It is important to test the creative and particularly any
associated interactions/campaigns on all phones

Now I’m a big fan of testing and in fact we even run our own Mobile Testing Lab (contact @alexmyoung on twitter if you want more info), but the statement “on all phones” seems waaaay too broad! I think it’s really important that advertisers match their target device profiles to their target audience profiles or at least the usage context. All our data shows that people who use the Mobile Web and even more so people who response to Mobile Advertising are more likely to have selected a higher end device. Forcing the creative and the campaign site to support all phones can be a massive and unnecessary budget drain for advertisers and can scare people away from Mobile Advertising in general. Also, you can often choose to only serve a campaign to specific device profiles ensuring that the creative is only delivered if the device is relevant.

Technical guidelines (pg 9)

vi) Enable easy direction from website to mobile site - with regard to browsers
this information comes from the userAgent string in the http headers

I “think” this is talking about site “switchers”, as in making it easy to change mode from the PC website to the Mobile website. However this sentence is quite confusing. The description of the User Agent HTTP Header should be clarified and the caveats should also be listed. For example, many devices have poorly configured or even blank User Agents. In fact Mobile User Agents are highly un-reliable (see my post on the alternative “Not-Device Detection” strategy). Mobile transcoding sites like Google’s and proxies can also play havoc with User Agents. As far as the “switchers” go – we are currently working on a Creative Commons and Open Source set of resources for a common switcher strategy to promote the “oneWEBaddress” concept – more on that soon.

ix) Handset detection capacity is highly desirable. It is advisable to test on
actual phones or use other companies which have an extended handset library
rather than using an emulator.

mmm…testing of handset detection should not be based upon an “emulator” but instead should be based upon an automated script or agent that is able to send arbitrary User Agent Headers based upon a library of known devices. The resulting pages or creative served should then be matched against the expected result for that device’s User Agent Header. No devices at all are required for this type of testing. Again, this is something we commonly do in our Mobile Testing Lab.

x) Advertiser/merchant infrastructure. Advertisers will keep up with traffic
demands and are responsible for all costs, communications, hosting, hardware
and software associated with the advertising campaign.

This sentence is just a little confusing and surely it is heavily impacted by the agreement the advertiser has, especially in the case of “zero rated” campaigns or sites that are hosted by a Telco who is running the campaign on the portal for example.

Downloadable and on-device applications (pg 9)

mmm – not quite sure what the difference between those two thing are?!

xi) Offline/not connected/unaware or sometimes referred to as off portal.

This seems like a very confusing statement. “Off portal” is a very different concept to “on-device” or “downloaded”.

xii) Online/connected/aware/ or on portal – These applications are normally
intermittently aware and can be refreshed through synchronisation with the ad
server.

Again, the concept of “portal” and “on-device” or “downloaded” seem to have been related in a way that just doesn’t make sense to me. This is taking the traditional Telco terminology and extending it beyond it’s applicable context. Also, “online” or “connected” applications may not be “refreshed through synchronisation with the ad server” – they may just be dynamically calling the ads in realtime just like a Mobile Website. The advantage here is that they may be supplying other targeting information such as location.

(4) ...or clicking through to a banner.

I think this is meant to be “clicking through FROM a banner”. Also, with the iPhone now reportedly accounting for 43% of Mobile Web traffic according to AdMob the term “tapping” may be more accurate than the term “clicking”.

These statistics show that it is now the dominant Mobile paradigm and with the Palm Pre’s sell-out release it seems that this touch screen User Experience model will become even more common.

BlackBerry guidelines (pg 10)

As the AdMob Mobile Web usage statistics show the BlackBerry represents only 17% of Mobile Web traffic. I am surprised that BlackBerry were singled out yet Nokia and perhaps even Windows Mobile were not mentioned at all.

iPhone guidelines (pg 10)

1) There are two different orientations - landscape and portrait. iPhone specific
websites will use the one size creative for landscape and portrait mode.

The statement that iPhone specific websites ” will use the one size creative for landscape and portrait mode” is not necessarily true. It is completely technically feasible to switch graphics, css and therefore complete layouts when the user rotates their iPhone. In fact this type of creative approach should be encouraged.

2) White space around banner for landscape, justified left

Based on the point above this guideline is a possibly redundant. And the prescription of “justified left” (which I think should be “left aligned” is highly subjective. Centered or right aligned layouts are just as valid and may even work more effectively with some site designs. I just don’t think guidelines need to be specified at this level.

3) Enable automatic redirection to WAP site

You’ll have to forgive me here…but the term WAP really rubs a nerve with me. The iPhone has a fully standards compliant Web Browser. WAP is a dead technology and should not be used to refer to the modern Mobile Web. In fact in our company meetings people get fined if they use that term!

4) As Flash is not supported there are no special effects the ads will have.

While it’s correct that the iPhone doesn’t currently support Flash, this does not mean that “no special effects” that can be supported. In fact the iPhone supports rich Javascript and CSS functionality including SVG canvas support so DHTML ads on the iPhone can be very dynamic and richly interactive. This highlights that this whole category of embedded DHTML Mobile Ads is not mentioned in the guidelines.

This also highlights another key point. The iPhone has driven the most downloaded apps of any mobile device with the Apple App Store now having served over 1 Billion (yes that’s with a B). However the guidelines for the “Downloadable and on-device applications” and “iPhone guidelines” don’t seem to be related in any way. This is something that will obviously need to be addressed in the next version of the guidelines.

Measurement (pg 11)

I think either 4 should be extended or a new 5 should be added that recommends that the type of device and browser or application the ad was served to should also be reported. This is essential and is highly related to all the points above. This should be a standard and expected part of any Mobile Advertising Post Analysis Measurement and we have taught all our clients to expect that.

Reporting (pg 11)

I’m not really clear how this differs from the Measurement section above, and based on the content it seems almost identical but just using a slightly different wording.

Consumer guidelines (pg 12)

Advertisers should look at designing an intermediary landing page, and advising of
data charges.

This is commercially and technically impractical. First of all you simply don’t know what data pack or plan the user has and therefore cannot calculate the cost – if any at all. Second, and perhaps most important, this will absolutely drive down the effectiveness of any campaign. If you interrupt the flow from offer to acceptance you drive down the response rate. If you interrupt it with a warning about cost then you will drive it down to almost zero! The goal should not be to encourage advertisers to advise consumers about the cost of using their Mobile Campaigns…it should be for the Telco’s and the industry in general to help the consumers become informed about their own plan or data pack costs.

Summary

Overall this is a useful document and another good step forward by AIMIA. I hope this feedback is taken in the positive and constructive way it is supplied. More debate and discussion about this document can only help.

There were some great speakers and I think this is a really important initiative.

I also think a few of the un-stated assumptions and where the current focus is was really interesting. The point that raised the most discussion from the audience was questions about why such complex data charges are still being applied and why “flat rate” models weren’t being used to drive user adoption of the Mobile Web in general.

While people on the panel claimed this still didn’t make “business sense”, I think the Flat rate is the new phat – MetroPCS case study posted recently by Vic Gundotra, “Vice President of Engineering for Google’s mobile and developer products” is a classic example of a strong business case.

I am also still a bit confused by the whole economics of the overall Mobile Advertising endeavour based on where this nascent market is up to.

For example, Claudia Sagripanti from GroupM quoted a recent Telsyte research report claiming the overall Mobile Advertising spend in Australia for 2008 was $7 Million. If this is the case then the Telco’s are probably only keeping just over half of that, and if you split it up between the 4 major networks then on average they’re getting less than $1 Million each!

When you compare this with the $44 Million spent by Optus alone over only 2-3 quarters to acquire iPhone users this highlights that Mobile Advertising Revenue cannot be impacting their balance sheet or bottom line at all…at the moment.

The underlying point is that the real revenue for the Telco’s doesn’t lie with Mobile Ad Revenue right now – it lies in the subscription services and data revenue generated when users click on the ads and browse the sites these ads point to.

The real revenue comes from encouraging users to get addicted to the Mobile Web and high-end smartphones like the iPhone and Palm Pre.

The real revenue comes from getting users to stop being afraid of data charges and use the Mobile Web like all of us early adopters do – 24 x 7.

So my question is…”wouldn’t this $1 million for each Telco be better allocated on encouraging users to adopt data heavy mobile habits instead?“.

If this doesn’t happen then the rivers of gold that people believe Mobile Advertising could become will not be realised.

Personally, we’ve gained a lot of data and insights into the real on-the-ground mobile user behaviour over the last couple of years and we are still constantly amazed by how “data charge” phobic the average Australian mobile user is. A lot of people simply don’t know their phones are even capable of using the web. And when we show them that they are they’re horrified and worried that simply clicking on a URL will cost them a fortune. Another large slice of users have even actively disabled data services on their phone so they don’t inadvertently rack up mobile data charges.

It’s going to take quite a bit of mainstream market edumacation to remove these fears and I’m not sure that focusing on such a small amount of Mobile Advertising Revenue right now is really the solution.

As I said, I think the AIMIA Mobile Measurement initiative is important and should be supported. I just think we really need to raise our sights a little higher when we’re considering the underlying goals.

The answers to the first question showed that this audience is obviously very bullish about the overall mobile market – hard not to be really! The most popular prediction was that “Clients will increase their spending on mobile campaigns” followed closely by “iPhone will grow rapidly to 2% global market share” then “‘Unlimited’ data plans will emerge in Australia”. I think these three points together show clearly what people in the mobile industry have thought for a long time. Mobile has come of age and the growth of rich devices like the iPhone and removal of the users “fear of data costs” will only drive the mobile revolution further.

The antithesis of this is that hardly anyone predicted that the “Telcos will embrace off-deck & supply services like billing”. The term “kicking and screaming” comes to mind.

The answers to the second question gave us some insights into this group’s predictions about their own personal mobile behaviour in 2009. The clear winner here was “I will do more googling from my phone”. I think this shows the power of search for the Mobile Web.

The second most popular prediction was “I will track facebook/linkedin from my mobile” showing how important social media and networks are for the Mobile Web.

The other 3 I found interesting were people’s predictions about their communication behaviour – “I will send more email than SMS from my phone” was highest followed by “I will twitter from my mobile”. This has interesting implications for SMS revenue for the Telcos. And “I will still call more than SMS/email” shows the immediacy and power of voice is still alive…just.

Interestingly mobile share trading/banking and ticker purchases rated higher than moblogging (if you exclude microblogging using twitter).

The third set of answers shows us what people’s business plans for 2009 are. By far the majority was “Create an iPhone app” which fits perfectly with the first set of answers covered in this post and the AppStore stats from Tim’s presentation.

Interestingly for us “Run a mobile poll” was quite a close second. We first launched this innovation at <a href=”http://smartmobtoolkit.wordpress.com/2007/09/29/hello-world-2/”Web Directions in 2007 and now a US company and an Australian company have even attempted to copy our innovations. We’re really excited about how we’ve seen people’s devices and usage patterns adapt to this over all the polls we’ve run and there’s a wide range of new features and innovations we have planned for 2009.

We also have been able to identify some really interesting patterns in the underlying data around which devices have worked for which Telcos and how that has clearly changed their customers usage behaviour. While this data is not statistically significant it does provide some clear clues that can inform your mobile strategy and product development plans. We’ll be putting out a presentation based on this detailed analysis soon and also running some further research to validate these insights.

It was also good to see that a reasonable number of people plan to “Sponsor mobile monday”. We really encourage you all to do this as it’s a great event that benefits the whole industry.

As always we offered SMS, URL and QR Code entry points and by far the majority of people joined in using SMS (57%).

Telstra (38%), closely followed by Optus (36%) were the dominant network providers, with Three (15%) and Voda (11%) trailing behind.

Nokia is still the dominant manufacturer (51%) with the iPhone quickly catching up behind (34%). Interestingly, Blackberry was only a very small share (9%).

And on the browser front Safari completely dominates (66%) due to the popularity of both iPhones and Symbian devices.

Compare this against last years results to see that Apple and Nokia have squeezed out almost all the other device manufacturers and the flow on effects that has had.

When asked what they’d like to see more of, the audience clearly responded with “more experts” (Industry leader interviews: 15%, Panels: 21% and International speakers: 15% – total 51%).

This was closely followed by more “new products” (Product launches: 15% and Product demos: 24% – total 39%).

The topics the MoMo Sydney audience are most interested in are primarily Mobile Advertising (24%) and Mobile User Experience (24%) followed by LBS/GPS (14%) and Mobile Payments (11%). This makes good sense considering the current state of the market and how everyone seems to be striving to find ways to generate revenue and keep users happy.

Compare this with last year to see the biggest change in interest is the decline of “Mobile Social Software” from 20% to 5%. In contrast “Mobile Advertising” has gone the other direction moving from 8% to 24%.

The analysis of who this audience represents shows that it’s quite a broad distribution across all the key categories. The largest segment is Mobile Application Developers (17%) followed by Mobile Services Agencies (14%), Telco/Carriers (14%) and Mobile Content Producers (11%). However Other (11%) is still quite a large slice that could be refined further.

Comparing this with last year shows there has actually been a bit of an evolution of the overall audience.

Overall, this poll has highlighted some really interesting patterns and when compared to last years results some key trends are starting to emerge. We’ll post the bar graphs from the “predictions” section of the poll soon, along with a more detailed assessment of some of the key usability trends hinted at in the underlying data.

I’d like to thank Tim, Oli, Gia and Shane for organising such a great event. The presentation that Tim and Oli did just before the poll was excellent and highlighted some really useful and interesting points.

BTW: If you’d like to organise a Live Mobile Poll for your event, company or group then give us a call.

http://iDidntDoThat.com

It’s a simple prank tool along the lines of iFart – however it let’s you turn your iPhone into a remote control for your friend’s and family’s computers. You just load a webpage on their PC when they’re not looking and then you can use your iPhone to make it sound like they’re burping, farting or even watching porn. And you don’t have to leave your precious and expensive iPhone lying around on someone else’s desk to play this prank!

We’ll be upgrading the site to support other mobile devices soon…however we decided to quickly release the first version just for iPhone users as it’s so much easier to deliver a better user experience. We’ve also developed it as an iPhone application that will be released as soon as the AppStore team approve it.

But underlying this “low brow” toy is the deeper “high brow” concept of Divergence. I think a lot of people find this concept a little academic, however http://iDidntDoThat.com is a fun way of showing exactly what it means and feels like.

We use this same framework to connect all sorts of devices and applications across the network. We can make your phone or PC chirp whenever someone visits your site or just play a “cha ching” when it processes a sale. The same framework can even let call centre staff shift their focus from “filling in forms” and “reading out disclaimers” to a much friendlier and more brand-building “co-browsing” with your customers, helping guide them through your site to find the best matched product or solution for them.

Once you detach user interfaces from specific devices or applications and really start to absorb what Divergence means I think you’ll agree it opens up a whole new range of business models and opportunities.

I hope you find this code useful. If you find any bugs or logical errors please let me know.

NOTE: This code is designed to support 3 key classes of device – PC, iPhone and POM (Plain Old Mobile). See the comments by the winmo detection that shows where you may like to extend this for other high-end devices (e.g. Windows Mobile or Symbian).

Javascript Example:

/**
 *  Copyright © 2009
 *  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
 *
 *  This program is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see .
 *
 *  Javascript Not-Device Detection Function
 *  Find out what type of device this is
 *  returns string - either pc, pom or iphone
 */
function _not_device_detection() {
    var ua = navigator.userAgent;
    var qs = window.location.search.substring(1);
    var agent = "error";
    var re = {
        "pcswitch" : new RegExp("pc", "i"),
        "pomswitch" : new RegExp("pom", "i"),
        "iphoneswitch" : new RegExp("iphone", "i"),
        "iphone" : new RegExp("iP(hone|od)(;|\s)", "i"),
        "winmo" : new RegExp("Windows\s+CE", "i"),
        "linux" : new RegExp("Linux", "i"),
        "windows" : new RegExp("Windows", "i"),
        "mac" : new RegExp("OS\s+(X|9)", "i"),
        "solaris" : new RegExp("Solaris", "i"),
        "bsd" : new RegExp("BSD", "i")
    };
    if (qs.match(re.pcswitch)) {
        /* This assumes you have a single query string value of "pc" */
        agent = "pc";
    } else if (qs.match(re.pomswitch)) {
        /* This assumes you have a single query string value of "pom" */
        agent = "pom";
    } else if (qs.match(re.iphoneswitch)) {
        /* This assumes you have a single query string value of "iphone" */
        agent = "iphone";
    } else if (ua.match(re.iphone)) {
        /* This user agent should be an iPhone/iPod */
        agent = "iphone";
    } else if (ua.match(re.winmo)) {
        /* This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too */
        agent = "pom";
    } else if (
        (!ua.match(re.linux)) &&
        (!ua.match(re.windows)) &&
        (!ua.match(re.mac)) &&
        (!ua.match(re.solaris)) &&
        (!ua.match(re.bsd))
    ) {
        /* This user agent is not Linux, Windows, a Mac, Solaris or BSD */
        agent = "pom";
    } else {
        /* Otherwise assume it's a PC */
        agent = "pc";
    }
    return agent;
}

Perl Example:

######################################################################################################
##  Copyright © 2009
##  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
##
##  This program is free software: you can redistribute it and/or modify
##  it under the terms of the GNU General Public License as published by
##  the Free Software Foundation, either version 3 of the License, or
##  (at your option) any later version.
##
##  This program is distributed in the hope that it will be useful,
##  but WITHOUT ANY WARRANTY; without even the implied warranty of
##  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
##  GNU General Public License for more details.
##
##  You should have received a copy of the GNU General Public License
##  along with this program.  If not, see .

##
## Perl Not-Device Detection method
## Find out what type of device this is
## returns string - either pc, pom or iphone
######################################################################################################
sub _not_device_detection() {
    # either pass in \%ENV or pack the UA and QUERY into a hashref and pass that in
    my $env = shift;
    my $ua = $env->{HTTP_USER_AGENT};
    my $qs = $env->{QUERY_STRING};
    my $agent = "error";
    if ($qs =~ /^pc$/i) {
        # This assumes you have a single query string value of "pc"
        $agent = "pc";
    } elsif ($qs =~ /^pom$/i) {
        # This assumes you have a single query string value of "pom"
        $agent = "pom";
    } elsif ($qs =~ /^iphone$/i) {
        # This assumes you have a single query string value of "iphone"
        $agent = "iphone";
    } elsif ($ua =~ /iP(hone|od)(;|\s)/i) {
        # This user agent should be an iPhone/iPod
        $agent = "iphone";
    } elsif ($ua =~ /Windows\s+CE/i) {
        # This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too
        $agent = "pom";
    } elsif (
        (!$ua =~ /Linux/i) &&
        (!$ua =~ /Win/i) &&
        (!$ua =~ /OS\s+(X|9)/i) &&
        (!$ua =~ /Solaris/i) &&
        (!$ua =~ /BSD/i)
    ) {
        # This user agent is not Linux, Windows, a Mac, Solaris or BSD
        $agent = "pom";
    } else {
        # Otherwise assume it's a PC
        $agent = "pc";
    }
    return $agent;
}

PHP Example:

/**
 *  Copyright © 2009
 *  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
 *
 *  This program is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see .
 *
 * PHP Not-Device Detection Function
 * Find out what type of device this is
 * returns string - either pc, pom or iphone
 */
function _not_device_detection() {
    $ua = $_SERVER['HTTP_USER_AGENT'];
    $qs = $_SERVER['QUERY_STRING'];
    $agent = "error";
    if (preg_match('/^pc$/i', $qs)) {
        /* This assumes you have a single query string value of "pc" */
        $agent = "pc";
    } else if (preg_match('/^pom$/i', $qs)) {
        /* This assumes you have a single query string value of "pom" */
        $agent = "pom";
    } else if (preg_match('/^iphone$/i', $qs)) {
        /* This assumes you have a single query string value of "iphone" */
        $agent = "iphone";
    } else if (preg_match('/.*iP(hone|od)(;|\s).*$/i', $ua)) {
        /* This user agent should be an iPhone/iPod */
        $agent = "iphone";
    } else if (preg_match('/Windows\s+CE/i', $ua)) {
        /* This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too */
        $agent = "pom";
    } else if (
        (!preg_match('/Linux/i', $ua)) and
        (!preg_match('/Win/i', $ua)) and
        (!preg_match('/OS\s+(X|9)/i', $ua)) and
        (!preg_match('/Solaris/i', $ua)) and
        (!preg_match('/BSD/i', $ua))
    ) {
        /* This user agent is not Linux, Windows, a Mac, Solaris or BSD */
        $agent = "pom";
    } else {
        /* Otherwise assume it's a PC */
        $agent = "pc";
    }
    return $agent;
}

We’ve had a lot of interest in the “Not-Device Detection” solution and lots of requests for example code so here it is.

Below is an example snippet from an httpd.conf (e.g. configuration for Apache) using mod_rewrite.  This assumes you have 3 main version of your homepage.

1. An iPhone/iPod Touch version using /iphone/index.html
2. A Plain Old Mobile (POM) version using /pom/index.html
3. A standard PC version using /index.html

Of course you can apply this model to more sophisticated solutions that also single out other specific devices or more complex collections of sub-pages. Other examples of this could also be implemented using perl or php scripts, but the performance is much better at the web server configuration level.

So, for this example let’s step through the code.

First make sure you have the RewriteEngine switched “on”.
RewriteEngine   on
Then detect the iPhone/iPod Touch first since they’re so easy to identify.
# iPhone/iPod redirected to iPhone index
RewriteCond %{HTTP_USER_AGENT}  ^.*iP(hone|od)(;|\s).*$
RewriteRule     ^/$         /iphone/index.html [PT]
The line below allows a user to choose to view the PC version by adding ?pc to the URL (e.g. from a specific switcher icon)
RewriteCond %{QUERY_STRING}     !^pc$ [NC]
You may want to exclude a number of standard bots here using generic strings.
You may also want to add exclusions for specific monitoring tools etc.  here too
RewriteCond %{HTTP_USER_AGENT} !(spider|crawl|slurp|bot) [NC]
Then here’s the meat of the “Not-Device Detection” solution.  You’ll notice that it mostly consists of !^ statements that say if this browser is NOT Linux, NOT Windows (excluding Win CE), NOT OS X or OS 9, NOT Solaris and NOT BSD then we’ll assume it’s a Mobile Phone and redirect it to /pom/index.html.
# Plain Old Mobile (POM) redirection (by exclusion)
RewriteCond %{HTTP_USER_AGENT}  !^.*Linux.*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*Win.*$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT}  ^.*Windows\s+CE.*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*OS\s+(X|9).*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*Solaris.*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*BSD.*$
RewriteRule     ^/$         /pom/index.html [PT]
Otherwise it should just receive /index.html as normal.

While this may look a little complex if you’re not comfortable reading regular expressions…I think you’ll agree it’s extremely simple when you compare it to this spaghetti diagram over on the .mobi forum.

I’d like to thank James for creating this work of art…now whenever I want to explain to a client why having a .mobi domain is a wrong headed and silly idea that makes your web strategy more complicated I just point them to this single diagram.

Anyway, I hope you find the example configuration described above useful. If you have any questions or would like any help implementing this please post a comment here.

While WURFL, Device Atlas, etc. are all great resources for very specific capability profiling…we’ve found that turning the problem upside down made much more sense and delivered faster, better results.

The key thing that most developers seem to be trying to do is to identify if a user IS using a specific Mobile Device.

The problem with this is that the User Agent strings on Mobile Devices are inconsistent at best…and completely useless or even non-existent at worst.

Once you accept this the inverse answer becomes clear.

PC browsers are much more reliable and consistent in identifying the Operating System they belong to. Also, there is only a small handful off Operating Systems you need to detect. So this is how our solution works.

We call this !device-detection (“Not Device” Detection).

If your User Agent isn’t one of the following Operating Systems:

- Windows
- Macintosh/Mac OSX
- Linux
- FreeBSD
- Solaris
- (Add niche OSes here)

And your User Agent doesn’t contain one of the following strings:

- bot
- slurp
- spider
- crawl

Then you are almost guaranteed to be on a Mobile Device.

Within this group you can then also clearly identify the important groups that are consistent:

- iPhone/iPod Touch
- Windows Mobile

We have implemented this method for two major Telco’s a major Insurance company, our leading edge Mobile Payment service and our own web projects. This is a strategy that has proven to be very effective and only requires a simple set of regular expressions in the form of Apache mod_rewrite directives that can work in either Apache or IIS.

We also couple this with a simple design pattern that provides a link from the Mobile site back to the PC site just in case we accidentally mis-classify a user. After all they should be able to ask for the full PC version if they really want it.

We’ve also recently put together a case-study that looks at some well known large corporations in Australia to see how they are or are NOT handling automatic device detection. The results are very surprising.

A full copy of the presentation is online on slideshare

Now we thought it’s time we shared this strategy in order to broaden the on-going device detection discussion.

When asked “What would you like to see more of?” 27 people answered.  Product launches, Panels and International Speakers were the most popular options.  Vox pop was the least popular with only 1%.

When asked “What topic do you want MoMo to cover most this year?” 20 people answered.  Mobile User Experience was the clear leader with Mobile Social Software, LBS/GPS and Mobile Payments following.  Mobile Games and Bluetooth were the least popular with 4% each.

When asked “Who’s here?” 16 people responded.  Of this small group Technology Vendor, Marketing Services Executive and Publisher/Media Owner were the most popular.  This was followed by Brand Advertiser and then Mobile Application Developer, Mobile Services Agency, Mobile Content Producer and Other.  Interestingly Carrier and Government were completely absent.

When asked if they thought the iPhone was “The Next Big Thing or the Next Big Hype?” 17 people responded.  Of this group 65% selected “Big Thing”.

The overall audience size when the poll was run was about 75 people. 71 people tried to participate with 59 of them successfully joining in. The 12 that couldn’t join in all sent an SMS but either decided not to follow the link in the reply message or simply couldn’t because their mobile doesn’t support data or open internet access.

It was interesting to see that over 58% of users chose to join the Live Poll using SMS. This means they sent an SMS to our inbound number and we then sent them back an SMS with a link to join the Poll. A third of the users simply typed the TinyURL directly into their phone and 8% scanned the QR Code provided. All three of these Access Methods were listed on the postcard that was handed out to the audience.

Again we were quite surprised at how evenly the 3 major MNO’s in Australia were represented. This is similar to the results we saw at Web Directions last year and we believe this suggests that amongst Data Heavy Mobile Consumers the market share is much more evenly split. However these results are only meant to be indicative and are not statistically significant. I’ll make some analysis of the “Other” segment soon.

In terms of Device Manufacturers Nokia and SonyEricsson dominated as usual. However there were 7 iPhone’s (11%) which just highlights what a bunch of Early Adopters the MoMo crowd really is. We think this suggests that this audience is more representative of how the mainstream market will be in 12 to 18 months.

When it comes to Mobile Browsers the audience was fairly evenly split between Safari (iPhone and Symbian), NetFront, Pocket IE and Unknown. We captured the x_wap_profile headers for all of these users so I’ll provide some more info on the “Unknown” break down soon. Again it was very interesting to see how small the Opera slice was. And the IE/Firefox slices were from the PC’s we used on the stage.

Last Monday we ran another MOB Live Mobile Poll…this time it was at MoMo Sydney.  The audience could join in by SMS, URL or QR Code.  The results of the audience profile and their answers where presented on screen in realtime.

It’s really interesting to see how diverse and varied the types of devices that participated on the day. Nokia clearly has the most significant market share, and if you combine “Sony”, “Sony Ericsson” and “Ericsson” (which you probably shouldn’t do) then they are a close second.

I think most significant is how small the Blackberry share is. In this audience all the combinations of Windows Mobile devices (dopod, i-mate, O2 and possibly HP or even Samsung) are 3-4 times the the number of Blackberry’s.

While a smallish 20% still “Didn’t know you could”, roughly 12% had tried it with half converting to regular “Monthly” use.

Nearly half the people “Didn’t know you could” accept Credit Cards on your Mobile and the remainder had “Never” tried it.

This shows there is an enormous awareness shortfall to be addressed.

Again the roughly 75/25 pattern is present.

Paypal seems to have less of an awareness issue than just the broad “Pay Friends” category does.

However only a small group of 3% do it on a regular basis and that is “Monthly”.

The fact that PayPal Mobile hasn’t been released in Australia yet should have something to do with these numbers

This area has a massive awareness problem with over 40% of people listing “Didn’t know you could”.

Another 50% said they “Never” had.

This left a very small number that was split evenly between “Once” and “Weekly”.

This could suggest a 50/50 conversion rate with the base frequency be “Weekly”, however the numbers in this sample are too small to really draw conclusions.

It’s interesting to note that this was the first mcommerce product to still have an awareness problem.

And again the 75/25 pattern seems to be present.

This time it converts to a roughly 9% regular “Monthly” usage rate.

This same pattern is even more pronounced here.

Over 85% said “Never”.

However of the small 12% that had tried it half had converted to doing so on a regular “Monthly” basis.