http://www.ft.com/cms/s/0/28744c96-176a-11df-87f6-00144feab49a,dwp_uuid=4dce8136-4a24-11da-b8b1-0000779e2340.html?nclick_check=1

So, lets be clear once again. Installed apps are OK but they’re expensive, tied to a particular OS, distributed through crowded and controlled channels, hard to spread virally and, well, so 2009.

Web Apps for mobile are cheap to develop, OS agnostic, browser independent (if you build them using Wapple technology), free to distribute and easy to spread. Oh, and this really IS the year of the mobile web so if you want to live in the now then mobile Web Apps are the only place to be!

http://www.useit.com/alertbox/mobile-usability.html

We’ve been saying this for years and I wonder what took Jakob so long to discover the mobile web anyway? Maybe he was on a really long phone contract and only just got an upgrade. Or maybe his handset was so cluttered he only just found the browser.

Either way, he’s on board now and whether you subscribe to his somewhat draconian dismissal of everything pretty over everything useable you will certainly recognise the importance of such an influential character entering the affray.

Now, I’m a little dubious about the research itself, but mainly that’s because I already knew that getting a test subject to access a full website on a mobile browser is UI suicide. I’m not disregarding the findings at all, because I agree with the conclusions. I just feel that the approach could have been to  look at sites already designed with mobile in mind might have helped us advance the cause rather than assist the stragglers.

To summarize the problems in his research findings: ‘Websites don’t work on mobile because they are designed for a big screen and mouse controlled GUI.’

The solution, of course, is to actually make dynamic and optimizing services for mobile.

As a developer or designer, once you begin on this path, usability common sense kicks in, mainly because you have to work and test on mobile devices during development.

If your buttons are too small, you’ll know when you first try to click on them, if you put too much on a page you’ll spend most of your time scrolling. If your pages contain too much data you’ll spend forever waiting for them to load, and so on.

So now you’ve learnt from the UI master himself, the real trick is to use technology like WAPL to ensure that your wonderfully designed and interactive service works well and looks perfect on every mobile device.

Without WAPL, developing for ALL devices is incredibly difficult if you take a ground up approach. Identifying devices and adapting content will take up valuable time and resources that would be well spend elsewhere.

You can concentrate on the UI, the design (as pretty things are important too, Jakob – they help us bond with the interface) and most importantly the application.

A great idea, WAPL and the UI considerations of such an expert will set you firmly on your way to creating a marvellous mobile web experience.

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

If you’ve ever had to develop a website that does anything imaginative with it’s width then you will have encountered the inclusive / exclusive discrepancy amongst browsers. For example, should your page length exceed the vertical size of a browser window, a vertical scrollbar appears – trouble is some browsers feel the need to subtract the width of the scrollbar from the width of the page – causing horizontal scroll on the page.Of course, on a mobile phone you can’t change the size of your viewport but because every phone can be different problems arise when trying to create a mobile website that works across all devices. Because mobile devices tend to lack the JavaScript support that we all enjoy in big web browsers and therefore it is not simply a case of denying the bars so that everything works.

Wapple Canvas allows you to build mobile websites in a ‘build-once / publish-many’ manner. The Exhibit engine takes care of making the site work across all devices.

Until Wapple solved the problem scrollbars had been a problem – in fact they remain a problem for those not using Wapple. In the past, to get a consistent look across all devices (as in no horizontal scroll), we suggested to customers that they never size graphics to 100% width. We advised that they change the graphic width to 97% (a feature within Canvas that allows complete control of all graphic sizes on a site) so that devices never experience horizontal scroll. The trouble was that on the ‘better devices’ sites ended up with some blank space on the right.

We decided that this was simply not good enough. So we put a stack of effort into sorting this out once and for all.

Over the course of a week we implemented a new Browser singleton. Previously we had been using our Device object to perform a lot of screen related functionality. Separating it into a Browser class means that we can separate the logic for browser screen decisions from the values that need to be based on the actual device sizes.

Upon instantiation, the Browser class deconstructs the screen into viewport and scrollbar values. These are stored in both pixels and percentages. Everything stems from here.

From then on, all screen calculations are handled by this class. Older phones usually have quite large scrollbar widths. Newer devices often overlay the scrollbar onto the screen when necessary. These phone have a determined scrollbar size of zero, creating 100% viewport, 0% scrollbars in the process.

From then on it’s the same calculations working on every device to handle the screen every time it is required.

We have also put on a few min-height things. This keeps things tidy on certain devices.

Obviously, this new system is optional to our users. A site built with 97% width graphics should not have it turned on until sizes have been adjusted accordingly. Otherwise, graphics will be 97% of a viewport width, which might be 95% of the screen. Easily adjusted, though so no worries.

I think that this week we’ll probably roll this out as an option to Architect users.

Of course in order to do any of the clever stuff above you’d need a dyanamic and intelligent mobile browser and device handling system like Exhibit there in the first place. The conversations we had on this topic have lead us to discuss some very interesting community-based tools. More of that to come in the future…

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.

Most developers look at the above and conclude that developing for mobile is beyond their capabilities, as would I if I wasn’t in my unique position. Settling for the lowest common denominator approach gives the end user a poor experience and does real damage to the service and the brand.

As well as that, you’ve also got the additional issues of having SEO in multiple places for mobile and web and having to have separate promotions for both!

But those days are gone!

Now you can build your site in one universal mobile markup language (WAPL) and use a set of web services from Wapple to take care of all of those barriers to mobile development. You won’t have to worry at all about device detection and you don’t need to write different markup languages for different handsets, you build once and let Wapple handle the rest.

Samsung SGH X210

Samsung SGH-X210

• WML
• Supports GIF and JPG
• 128×160 pixels display
• TFT screen with 65k colours
• Multiple operators and firmware

NEC n343i

NEC n343i

• CHTML
• 128×160 pixels display
• CSTN display, 65K colors
• Downloadable pictures

Apple iPhone

Apple iPhone

• HTML
• 320×480 pixels display
• JavaScript and CSS support
• Touchscreen, 16M colors
• MP3 ringtones

As you can see from the handsets above, they all have totally different sets of capabilities that before the days of Architect and Wapple you’d have had to profile and optimize yourself.

Using one domain for web and mobile is also now possible, giving you the ability to promote the same URLs across all of your platforms and centralize SEO – you can even use your own database to build complex applications.

Here’s how it works

The key technology you’ll need to get your head around is Wapple Architect including WAPL – the language you use to interface with it. WAPL stands for Wapple Application Programming Language and allows you to describe your site in XML to look the way you want it to. Architect then provides you with services to take your WAPL and along with information about the device, turn it into perfect markup with dynamically resized images built with the capabilities of the handset in mind.

Dropping bits of functionality onto a site is a doddle and as Wapple knows each and every capability about your handset, you can be safe in the knowledge that a smartphone such as a G1 will output a really good looking site with great support for features such as click to call.

It’s all done through a number of SOAP web services so i’ll assume that you’ve got that installed. If not, have a read all about SOAP, and check out how to use it with a high level language like PHP. You’ll also need a valid dev key which you can get by signing up to the Wapple developer program. Once you’ve got those ready, I’ll delve into how to use the SOAP calls in PHP.

Early on in your script, make an isMobileDevice() or getMobileDevice() SOAP call to test whether a visitor is on a mobile device or not and make a decision on what to do based on the result.

<?php
try
{
	$sClient = @new SoapClient('http://webservices.wapple.net/wapl.wsdl', array('connection_timeout' => 5));
	$isMobile = false;

	if($sClient)
	{
		$headers = array();
		foreach($_SERVER as $key => $val)
		{
			$headers[] = array('name' => $key, 'value' => $val);
		}
		// check if we are a mobile device
		$params = array(
			'devKey' => "YOUR-DEV-KEY",
			'deviceHeaders' => $headers
		);

		if($sClient->isMobileDevice($params))
		{
			// A mobile device !!
			$isMobile = true;
		}
	}

} catch (Exception $e){
	// Add your own exception handling here
}

Line 4 sets up a SOAP client and if we can do this successfully, lines 9-13 setup the device headers ready to pass through SOAP. Lines 15-18 take care of special parameters such as your dev key and line 20 does the SOAP call to test for mobile. On line 23 I’ve set a variable called $isMobile to true and I’d probably set a session cookie as well to remember that I’m on mobile rather than do the call every time. This variable would also be the basis of whether to write XHTML or WAPL.

If the visitor is not on a mobile device, generate your XHTML as normal and output to the browser. If the visitor is mobile, write your pages in WAPL and instead of outputting to the handset, send the WAPL through the getMarkupFromWapl() web service to get perfect markup back for that particular device. Once you have something back, output the headers and markup to the device.

<?php
// XML headers and open
$string = '<' . '?xml version="1.0" encoding="utf-8" ?'.'><wapl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://wapl.wapple.net/wapl.xsd">';

// Page title and external CSS
$string .= 'Your Page Title';
$string .= 'http://your-domain/css/mobile.css';
$string .= '';

// Add your WAPL below
$string .= 'Hello World';

// Close layout
$string .= '';

// Setup parameters for communicating
$headers = array();
foreach($_SERVER as $key => $val)
{
	$headers[] = array('name' => $key, 'value' => $val);
}

$params = array('devKey'=>"YOUR-DEV-KEY", 'wapl'=>$string, 'deviceHeaders'=>$headers);

// Send markup to API and parse through simplexml
$sClient = @new SoapClient('http://webservices.wapple.net/wapl.wsdl', array('connection_timeout' => 5));
$xml = simplexml_load_string($sClient->getMarkupFromWapl($params));

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

Lines 3-14 are all about generating a string containing some WAPL that will display “Hello World” and once this is done, device headers and a SOAP client are generated again (I’d refactor this in a real world example to centralize code with the earlier example). Line 27 actually does the SOAP call to get the markup from WAPL and turns it into simple XML. Lines 29-32 take care of device specific headers and finally line 33 outputs the markup to the mobile browser.

The hardest job once you’ve got to this point is deciding which WAPL element goes where and how to configure them. Luckily everything is documented for you at wapl.info – you can also check out the schema, run your WAPL through a validator or find some useful tools to help you along. As you’re a developer (or you know one), you’ll see that WAPL is XML based so hopefully it’s a skill you’ve already got in your arsenal.

It’s as easy as that!

So all the headaches that previously existed whilst developing for mobile have now disappeared and you can see how Architect will revolutionize the way you deliver an amazing mobile experience.

We’ve gone through the process of mobilizing wapple.net as an exercise in showing how easy it is to mobilize an existing website, check out my article on it to see how we got on. Why not sign up for a dev key and try it out for yourself? All you need is a little knowledge of coding, a computer to do it on and an idea of what to mobilize.