1/10: Presented the PC website – site breaks/crashes the mobile browser so nothing displays

2 or 3/10: Presented the PC website – site takes too long to load and/or has key elements that are not supported by many devices. Mobile consumer compelled to leave

4: Presented the PC website – pages render on mobile device but the website does not present most relevant content for mobile users. Also zooming in for content and out for context is frustrating.

5/10: Redirected to a mobile site but the mobile experience is basic and the user experience poor which is not in line with digital branding of website. Lowest common denominator approach

6 or 7/10: Redirected to a great mobile site for smart phones but the experience is poor on older devices. And /or the content is not relevant for mobile users

8 or 9/10: Redirected to a great mobile site experience that accommodates consumers on the move no matter what device they have.

10/10: Served mobile relevant content from the website domain and underlying application with an experience catered for mobile users. The site is optimised for all mobile devices old and new. They included unique usability for the mobile customer eg instore experiences, scan QR codes or promotions, mobile campaigns.

Google Wallet, American Express Serve, Mastercard Paypass, Visa Wallet and Isis, a mobile payment based on the near-field communication platform, have all being launched to service this market, and while industry insiders expect near-field communication (NFC) to become the dominant platform over the next three years, it is brands that need to act now if they are to benefit from this huge revenue stream.

Potential customers of mobile payments have little interest in which platform they will use, only that it works whenever they want to make a purchase. Similarly they will insist on the same from the mobile websites of companies they would like to buy from.

Any integration of a mobile payments platform must be done in parallel with a mobile website that is optimised. With digital goods making up 40% of that huge $690 billion figure, brands need to choose their partners wisely, and to merge that decision with a well-thought mobile strategy… and a mobile website that is fast, secure and scalable.

There’s an ongoing debate on the subject of mobile web transcoding, so here’s our take.

Let’s be clear on our language here though. Transcoding videos for mobiles is essential and very good, but doing it to your web output is bad. Really bad.

A reliance on an automated process that takes HTML output and reformats it to mobile markup is a deluded one. Computers are really bad at recognising diverse visual patterns (that’s why we all use CAPTCHA to protect from bots) and you don’t get much more diverse than web design. If a transcoder has been taught your web layout, you’ll find yourself tied to that web design or face losing any learning invested in the system.

The core point however is that mobile users have different desires and demands to you normal web audience. They don’t want to search for information – they want it served to them. They want access to services that are typically mobile, not those that are more comfortably engaged in while sat in front of a 19inch monitor with time to spare.

The solution is to write mobile applications for mobile from the heart of your server outwards, sharing logic and data.

With this approach you can utilise all the logic, models and controllers (if you’re that way inclined) from your existing web services but present them using view layers that are ideally suited to mobile devices. You can omit features that are simply not made for mobile and include new ones that would mean nothing to a web audience but are essential to visitors on the move.

Wapple Architect allows you to output a single markup language for every mobile device. The process will automatically adapt your WAPL markup to each and every mobile device – but this isn’t transcoding – it’s taking the output, layout and data described in WAPL and returning the correct markup for any particular device.  Watch this video to understand more.

Wapple Architect beats automated transcoding

Don’t be fooled by the sirens singing the song of transcoding. They will bite you in the backside sooner or later. Transcoding is at best a quick fix but as an enterprise level approach to catching the mobile web wave it will ultimately disappoint your users, create an extra layer of work for you over and over and simply glosses over an issue rather than addressing it entirely.

Code, don’t transcode.

In June 09 IE6 accounted for 14.9% of web access.

Take a look for yourself here.

Access from mobile devices to web sites is on the increase. It is approximated at about 5% for the same month.

That’s an interesting figure because IE6 is on a downward slide, yet the world is scared of not supporting it.

Let’s get this straight.  Mobile access to popular websites exceeded IE8, Chrome, Safari and Opera. We’re clearly on our way to mobile browsers overtaking IE6.

This is a big deal for anyone who wonders if they should be properly serving mobile content to mobile browsers. The answer is a resounding “YES” and this is how you can do it.

In fact, if you’re not supporting mobile properly, I’d be worried. More worried than I’d be about iE6. The twitter crowd will be bringing that to its knees on your behalf.

How much you should care about IE6 and Mobile Browsers

Trouble is, developing for mobile browsers is hard if you don’t choose the right tools and technology to help you on the way.

If you’ve ever tried to code for the mobile web in the past (or have been lucky enough to have someone do it for you), you’ll know how hard it’s been to create a mobile site that looks great and provides a great user experience on all mobile devices.

Mobile web development is traditionally very difficult. You are not alone. In this article, I hope to explore some of the troubles encountered and then a really cool mobile publishing solution that will help you develop mobile web sites – your mobile web sites, the way you want them. I’ll also explain how you can do it quickly.

The results will optimize for EVERY mobile browser, perfectly.

Instead of having to worry about a couple of browsers as you would with a desktop browser, you’ve got different screen sizes, firmware, operators, carriers and multiple markup languages to look after – all of which meaning there’s a potential 50,000 devices to support.

That’s a staggering number. If you ever had the problem of making something work in IE6 then multiply that headache by the figure above. It’s brain-splitting to say the least.

There have been tools emerge in the past that have gone some way to helping, but now there is a new service available that has removed all of the problems and barriers to development. It’s called Wapple Architect and by the end of this article you’ll know all about it and how it’s revolutionized the entire web world.

Mobile Web, the Old Testament

In the beginning there was WML (ok, strictly speaking there was HDML and maybe something before that)  and coding for mobile web was fairly straight forward. But as browsers got more sophisticated and started to understand HTML, XHTML-MP and XHTML things got a bit more complicated – sites could be coded with new standards, but old devices would only handle old languages.

And that’s not all, you’ve got i-mode phones in Japan that use CHTML, Vodafone’s PML and a few online banking solutions in Japan that still use HDML. A quick head count of the languages I’ve just mentioned gives you 7 different mark-up languages to deal so you can see how hard it is to work out which version to deliver to a mobile device.

Screen sizes

When it comes to screen sizes you’ve got an even bigger problem with hundreds of different sized screens. There’s plenty of documentation that suggests only catering for the top 3 or 4 sizes such as this article by Brian Suda.  What about the rest of the handsets and browsers out there that add up to a sizeable slice of the mobile phone pie – Samsung Instinct M800 for example?

I’ve gathered some stats using Wapple’s own mobile device and browser detection technology.  This reflects millions of unique visits to Wapple-powered mobile sites across the world.  Look at the pie chart on the right which provides a true picture – the sizes recommended by Brian Suda only account for just 66% of handsets out there.

A few tools emerged a number of years ago that would do some device detection for you and supply you with information about a device, WURFL is one of them, Device Atlas is another. Both of these were a step in the right direction but what do you do with the information once you’ve got it? You might know that a device has a screensize of 320×480 but how do you make sure an image fits it perfectly? You can’t be expected to create versions to cater for every old and new screensize plus how would you be future proof for bigger or more obscure displays? I’ll enlighten you further down…

Then once you’ve got a mobile site built, where do you host it? On m.yourdomain.com, yourdomain.mobi, or have yourdomain.com intelligently serve out content to either a mobile or web browser. There’s plenty of advice out there suggesting that the latter is difficult (here’s an example)! It’s not by the way – and I’ll tell you why shortly!

If we use the Old Testament analogy then you are Job. The Mobile Web is a testing and trialling place with tons of nastiness to endure. At the end of it you’ll be broken, bruised, scarred and burnt. But don’t worry, redemption is just around the corner – so don’t get scared, just keep reading.

Mobile web, the New Testament

I feel your pain. But hallelujah, brothers and sisters, help is at hand.

Wapple Architect is a series of web services that you can use to perform various operations – you can test a device to see if a browser visiting your site mobile or not, grab some info about the handset, or turn some device independent code  into perfect and meaningful markup.

Because Wapple Architect is so new, it’ll come as no surprise that there isn’t much written on the subject and articles written prior to it’s release will obviously make no mention of it – but things have changed, and they’ve changed for the better.

With Wapple Architect you have everything you need to develop mobile websites and applications.

Device detection is done through Wapple’s awesome optimization and rendering engine called Exhibit that caters for all handsets on all networks with every screensize in the world. Instead of having to download a database it’s updated in real time and is always available, it’s self learning and knows about new devices before they’ve even left the lab!

Actually building your site once you’ve learned that the visitor is on a mobile device is simple, just describe your site in an XML based device independent language called WAPL and rely on Architect’s web services to turn it into appropriate markup for that particular device. To demonstrate the difference between Old Testament and New Testament with Architect, here’s a quick run through of the steps you’d go through to place a click-to-call link on one of your pages.

It’s much easier to successfully place a click-to-call link on a page with Architect. It not only works for phones that support the tel and wtai protocols, but outputs the phone number as text for devices that don’t.

Image resizing is a similar process, instead of working out a screensize of a phone and either placing CSS media queries or having loads of code in your application to deal with all the different sizes, you specify an image as a percentage width of the screen and Wapple takes care of the rest.

Having one domain for both web and mobile is also something that is easily attainable and by using Architect’s web services to do it you can have yourdomain.com serve out appropriate content to whichever device visits your site. Read of my article about the Importance of Single Domains for Web and Mobile.

Revelation: Mobile Web Development

So there you have it! Amazing mobile web development tools that overcome all the barriers that previously and continue to pain developers.

No more concerns about mark-up, screen size, or graphic formats and no more cutting corners by delivering to only 66% of phones. You have within your grasp a future-proof solution that delivers best end-user experiences every time. Plus you can promote one single domain for web and mobile.

If you want to find out more on Architect with some code examples of how the SOAP functions actually work, check out my Intro to Architect Mobile Web Development article and if you’ve been inspired to get cracking with these new tools, sign up for a dev key and check out the documentation at http://wapl.info.

If you want to get it for yourself, head over to http://wordpress.org/extend/plugins/wapple-architect/, have a read of the documentation and activate it on your own blog!

If you’re not interested in delving too deep into the manual (or you want to skip it like most people do), here’s a quick overview of the features and how to install it.

Features

• Compatible with WordPress 2.0 and higher
• Works perfectly on every mobile device
• Retain one single domain and SEO friendly URLs
• Total customization of the mobile blog experience

How to Install

• Download the architect.zip file from wordpress.org
• Upload the entire contents to the /wp-content/plugins directory
• Activate the plugin through the Plugins menu in the WordPress control panel
• Enter your Wapple Architect dev key in Settings > Wapple Architect

If you haven’t already got a Wapple Architect dev key, you can get one from the Developer Program Sign up page. If you make sure you enter your blog URL into the activation form you’ll get your dev key sent straight to your inbox.

Whilst you can use your newly acquired dev key in your WordPress blog, the developer program allows you to generate more dev keys for other mobile projects!

This is only the beginning of this plugin, it’s version 1.0 and there will be many more to come. Advanced features, improved handling of other plugins, admin options so you can write your posts from your phone are just a few of the ideas I’ve got to extend this plugin further.

If you’re using my plugin on your blog, please get in touch with some feedback or send me a link so I can check it out on my phone!

To help the community at large, I’ve created a WordPress mobile plugin and theme that provides a perfect WordPress experience to mobile web users and here’s how and why I did it.

Plugins … but not one that truly understands mobile web

If you want to do anything slightly out of the ordinary with WordPress you have to use a plugin. If you want to edit your content in a weird and wonderful way then there’s a plugin to do it. Want better search capabilities? Someone’s already written something to do it. Simply put, plugins are little chunks of code that you install on your site to add extra functionality to the basic set.

Yet I searched high and low for a plugin that would properly mobilize an existing WordPress site, and my definition of properly is:

• Being able to use the same one single domain for web and mobile
• Maintain URLs across platforms
• Retain SEO for mobile search
• Carry through the same look and feel of the website on every single mobile device and browser

I did find one that renders your site for iPhone only, but that’s no good if you’re one of the 90% of mobile users who don’t actually have one. There’s another for PDA’s and a third that renders XHTML only, there were also other plugins that forwarded you round to an alternative mobile URL.

Themes … even fewer mobile options

The other extendable aspect of WordPress are themes, allowing designers to create great looking sites by modifying a relatively small number of files containing chunks of PHP code and HTML. Whilst this is great for web, it’s bad news for mobile because phones that require anything other than XHTML will never be given it.

At the time of writing, there’s only one single, solitary mobile WordPress theme available out of a total of 797 so the cupboard looks a little bit bare when looking for something to mobilize your blog.

So as I couldn’t find a plugin or a theme to fulfill my criteria, I set myself the challenge of writing one that caters for every mobile device and creates an enjoyable user experience for every visitor. As Mobile Web Junkie is one of the many millions of sites using WordPress, it made sense to make it the guinea pig.

How I did it

At a very high level, the plugin works by dynamically switching themes dependant on what platform the user is visiting on. By using the add_action function in WordPress to trigger my own functions at certain points, I made sure that device detection took place early on in the script in order to control what happened, here’s a snippet of code from my plugin.

function deviceDetection()
{
	if(__testForMobile())
	{
		// Load the correct file depending on the URL (copied from template-loader.php)
		$template = __templateLoader();
		$file = WP_PLUGIN_DIR.'/architect/theme/'.$template;
		if(file_exists($file))
		{
			include($file);
			exit(0);
		}
	}
}
...
add_action('template_redirect', 'deviceDetection');

Template_redirect is an action that is triggered immediately before loading a theme – the posts have been created but nothing has been echoed out to the browser. By hooking the ‘deviceDetection’ function into it, I dynamically switched to my Architect theme depending on whether the visitor was on a mobile device or not. There’s a couple of functions missing in the above example, one to get the correct template file (from the ‘__templateLoader’ function) and one to actually do the test for mobile (__testForMobile()). If you get the code for yourself, you can take a look at what they do.

If at this point the visitor was detected as being on a desktop browser, none of the code to switch themes was executed and the code carried on as if nothing had happened.

However, if a mobile was detected, the plugin loaded in the correct template file – if the home page was being viewed, it’d be index.php but if it was an actual post, single.php was the file it tried to load. Here’s a few chunks of my index.php to see what it does:

include_once('functions.php');
$waplString = get_wapl_header();
$wapl = new WordPressWapl;
if(have_posts())
{
	while(have_posts())
	{
		the_post();

		$waplString .= $wapl->link(array('rowClass' => 'entry_row', 'display_as' => 'h2', 'label' => get_the_title(), 'url' => apply_filters('the_permalink', get_permalink())));
		$waplString .= $wapl->chunk('words', array('class' => 'post-date', 'quick_text' => apply_filters('the_time', get_the_time('F jS, Y'), 'F jS, Y')));

		if(get_option('architect_home_showexcerpt'))
		{
			...
			$content = $wapl->format_text(get_the_content(), $homepagescale, $homepagequality, 'entry_row');
			$waplString .= $wapl->chunk('words', array('class' => 'entry_row', 'quick_text' => $content));
			...
		}
	}
} else
{
	$waplString .= $wapl->chunk('words', array('display_as' => 'h2', 'quick_text' => 'Not Found'));
	$waplString .= $wapl->chunk('words', array('quick_text' => 'Sorry, but you are looking for something that isn\'t here.'));
}
...
$waplString .= get_wapl_footer();
process_wapl($waplString);
?>

Instead of having a get_header() function (which is the norm for most WordPress themes), I created a get_wapl_header() function that returned markup from header.php file instead of echoing the contents to screen. I then looped through the posts in the same way as other themes and built up a WAPL string along the way.
At the end of the example, the WAPL string is sent through the ‘process_wapl’ function, here’s what that function looks like in its simplest form:

function process_wapl($waplString)
{
	global $waplHeaders;
	global $waplSoapClient;

	$params = array('devKey' => get_option('architect_devkey'), 'wapl' => utf8_encode($waplString), 'deviceHeaders' => $waplHeaders);

	// Send markup to API and parse through simplexml
	$xml = simplexml_load_string($waplSoapClient->getMarkupFromWapl($params));

	foreach($xml->header->item as $val)
	{
	    header($val);
	}
	echo trim($xml->markup);
}
?>

This function is very similar to some I’ve used in other projects, it takes the WAPL string and sends it through the getMarkupFromWapl SOAP service. You can see how it’s used in my Intro to Architect Mobile Web Development and mobilize your cake app in minutes article on the Cake Bakery. Infact, the whole process of doing device detection in one area and the building of WAPL in another is a pattern that could be applied to any other CMS or framework – I’ve already started work on a Joomla plugin and you could also use the same logic for Drupal.

There are a whole load of builder classes and functions included in my theme that will turn WordPress markup (mostly HTML with other bits thrown in) into plain text and Wapple Text Formatting. The WordPressWapl class also allows you to build WAPL markup that will always be valid and conform to the schema.

Get the plugin

Now I’ve created a plugin and theme that not only makes sure that my blog works for every single device, but will do the same for anyone else with a WordPress blog who wants to mobilize it.

If you want to take a look at my plugin, head over to http://wordpress.org/extend/plugins/wapple-architect/ and check it out for yourself! There are extensive instructions on there with regards to installing as well as a few screenshots so you can see what you could accomplish.

Plugin Features

• Create mobile specific page header and page footer images
• Customize your blog for mobile by configuring options in the control panel
• Make sure long posts get split up into manageable pages
• Dynamically resize your uploaded images
• Pull through the look and feel of the website theme
• Fully customizable mobile CSS
• Extendable for other WordPress plugins
• Works for every single device
• Correct markup is delivered to the right handset
• Retain one single domain
• Maintain SEO friendly URLs

How to Install

The installation process is simple. Upload the contents of the architect.zip file into the /wp-content/plugins directory, activate the Wapple Architect plugin and enter a valid dev key. From start to finish, you should be able to mobilize your blog in under 2 minutes!

The Result

Here’s a screenshot of what my plugin has done for this blog, but if you want to see the results for yourself, visit Mobile Web Junkie on your mobile phone.

Mobile Web Junkie

The latest stats suggest that 5% of traffic to websites now get hit by mobile browsers, even if you promote a separate URL for mobile web.

What do you want them to see? The actual website that takes 20 minutes to load and scrolls to about 10 times the width and height of the mobile? Not likely. They’ll want to see a mobile specific version, running off that single domain, perfectly optimized to whichever handset they’re using, yes, even if they have an iPhone. Mobile users are getting a bad experience either because you don’t have a mobile website or you do but are promoting a separate URL for it! You don’t actually need a separate URL for mobile web and if you do have one currently you’re probably having the headache of getting people to use it.

Websites are designed for big screens with a mouse and pointer so mobile websites should reflect the smaller window, slower connection and alternative interface but both versions should be accessed through the same URL. Architect allows the development of mobile friendly websites and one single domain – something that everyone should be striving towards.

We’ve recently mobilized the wapple.net website so that’s it’s accessible on mobile with the same URL, why not have a read of it and see how we did it.

Built with Canvas

Built with Architect

Since its conception a number of months ago, we’ve been telling anyone who will listen how good Architect is, how you can use one domain, use the same URLs on mobile as on web, retain SEO from web to mobile and centralize all underlying business logic no matter which platform you are browsing on.

Now we’re practicing what we preach

The previous site was built with Wapple Canvas, a superb tool with full drag and drop functionality perfect for creating mobile marketing campaigns. There are some awesome mobile sites built with Canvas that look amazing and convey the exact message they’re designed for, here are just a couple of them:

Watchmen

Alfa Mito

The above sites work better in Canvas as they’re designed specifically for mobile advertising campaigns, there’s no corresponding website and they can be targetted at a mobile audience. You’ll find more detail on Wapple Canvas here.

One domain

For websites like Wapple’s, it’s essential that if you’re on a mobile device and hit the wesite url (http://wapple.net in this case), you get something that looks perfect on your handset no matter what screensize or capabilities your phone may or may not have. It is essential to use Architect to deliver the mobile site with pages written in WAPL if you want to provide a great user experience to everyone.

During the week I read a tweet from Brian Fling about a one-day mobile workshop, and in the spirit of “if you can do it so can we”, we thought we’d have a go at building wapple.net with Architect & WAPL in one day.

We already had a mobile site built in Canvas with all graphics already saved out and we’d used our experience on mobile to make intelligent decisions over what was to be displayed on mobile rather than the website. For example, the big slider the sprawls across the home page of the website could be turned into a smaller and simpler version for smartphones such as the iPhone but wouldn’t really be appropriate for a tiny phone with no javascript capability.

This is where the magic happens

Mobile Shopping Review

The Wapple website is built with CakePHP, an MVC framework that gives us flexibility and speed of development. We’d previously mobilized plenty of other cake apps such as mobileshoppingreview.com plus I’d already written a plugin and article for the cake community about how to mobilize a cake app which, incidentally, we used to mobilize wapl.info. Development was going to be easier with the plugin already available :-

Once the Cake plugin was in place, it was just a case of writing WAPL for every page we wanted to mobilize.

Within half an hour we had the component in place that did device detection and altered the view and layout path accordingly if the visitor is on mobile, a layout that would take the WAPL code inside the view files, wrap it in a bit of header and footer WAPL and send it through a SOAP web service, and placeholder view files for the pages we wanted to mobilize.

Another half an hour and all of the ready made graphics were in place, the header and footer of the mobile site looked smart, the main menu was sorted (which actually looked better than the Canvas version) and we’d implemented a new bit of functionality that displayed the latest wapldevs tweet. And because we’re using cake and all business logic is centralized, latest tweets from wapplemobileweb are also available on the website!

After a quick break for lunch, a game of pool and a much needed cup of tea, we pressed on with creating view files for the pages. The home page was sorted first, shortly followed by the rest of the top level menu, the other product pages and lastly the contact form and latest news. By mid afternoon we were ready to send the site to QA for testing.

We noticed at this point that the quality of the images generated through Architect didn’t match that in Canvas. A short investigation ensued which resulted in a quick fix going up to the live WAPL server which fixed all of the image quality issues. After another short round of testing, the code came back with zero bugs so we were ready to launch.

Or so we thought

When deploying the code to a test live box, a number of elements on the website were being displayed twice or in some cases, three times and seeing as some of these elements were only referenced once in the code, it was a little confusing (it worked fine on the local dev server). The problem was an issue with cakephp, rsync and windows / linux file formatting and after running a touch command over all .php and .ctp files it resolved itself, however, this little setback meant we were near to 5.30pm and no-one wants to deploy anywhere near going home time.

We did build the site in a day

We did build the site in a day and although it would have been nice to launch on the same day, common sense meant it was launched first thing the next morning, however, it does prove how quick and easy it is to mobilize a website. We now have URLs that work both on mobile and web, we’re using just 1 domain for every browsing platform and we’re retaining all of our website SEO giving us the ability to promote our sole domain and not resort to m. or /mobile or a .mobi.

We’d been seeking a solution for a long time that will mobilize existing web content so it was a really significant step for us to employ Architect as the technology behind our mobile wesite. Inventing WAPL was very much an epoch defining moment in Wapple’s history!

So in summary

Developing properly for mobile is now an easy process, especially if you’re using a framework that does all of the heavy lifting for you. Gone are all the barriers for web developers which I’ve written about in my intro to architect article – you should be able to mobilize an entire site in a single day with Architect.

To see how we got on and view the site on your mobile, visit wapple.net or scan the QR code to take you directly to the site.

If you want to make a truly mobile friendly version of your own website just like we did, sign up to our Developer program for free usage and a dev key.