If all you care is a super-simple solution that gets the job done, I recommend that you use tinySrc in its basic configuration. tinySrc does a lot of legwork for you and the resulting images are in 90% of the cases or more just great. Check out the tinySrc home and you already have all you need.

So why mix tinySrc with a JavaScript?

At mobilism I met Scott Jehl for the first time and he mentioned working on a JavaScript that would take care of providing the right images based on client-side detection. It sounded quite interesting to me because most of the times, in order to create a decent responsive design, you have to create all the media files in advance.

I started looking at his Responsive Images library and liked the idea. We exchanged a few messages and it seemed easy enough. What it does not do is what I know is very often the real issue: generate the images. So it taps into the power of the client-side detection to understand what the browser and device can do, but then relies on media files generated in advance. In Filament’s online demo you can see that Scott generated 2 images, small and big and that’s all you get. Of course you can extend the JavaScript to manage more sizes, but every time you add a format you will have to edit your JavaScript. This is a good start, but not exactly what I was looking for.

I also thought about WordPress Mobile Pack and users that are on simple hosting plans or maybe don’t have the time and skills to generate all the images in the right formats. tinySrc seemed a perfect match.

How it works

The changes I made to Scott’s JavaScript and Rewrite rules are very limited, but I think they open the door to some substantial benefits. The JavaScript now reads the available width and height of the screen and passes those values to tinySrc so that an image of the perfect size will be generated (I padded the image of 20px for safety). You still need to have a small image (for fallback purposes) and a full-size image so that tinySrc has a high resolution image to work from (of course the bigger the better).

See it in action.

Why use it?

If you want to apply responsive design you must create the correct media files for each target device or family. This little script allows you to do that with near-zero effort. If you want to support device families tinySrc supports that, but you will have to change the JavaScript. What’s not to love?

Why NOT use it?

The JavaScript works so that it parses your HTML and replaces all image URLs with a dummy URL on your Apache server (at the time of writing the script requires Apache, nginx in the works). When the client requests that URL your Apache server will redirect the client to tinySrc. This is at least 1 HTTP request for every image that we might avoid. tinySrc on its own already does a great job, so this really is a step further toward responsive design. The only one that knows which approach is best is probably you.

What next?

I am looking at a couple more improvements, one idea is to use tinySrc’s dataURI API call and use that to replace all image URLs. That should save all the requests to your Apache server that are then redirected to tinySrc. Depending on how many images you have this might or might not make a difference. The problem is browser support, I am looking for some data. If you have any, please contact me.

The source code

If you like what you saw you can get the code on github.

I am going to take four User-Agent strings for four platforms that are meaningful for mobile and analyse what is useful today, what they have currently and what they should have. I will also briefly jump into some other headers as they can help in a number of situations.

User-Agent string definition

A clarification here is probably needed. Let’s start from what the User-Agent string is, if you don’t know. When an HTTP client such as a Web browser makes a request to a server it sends a number of headers as part of that request. One of these headers is called User-Agent and it is meant to identify the client. This is how it is defined in the RFC-2616:

The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokensare listed in order of their significance for identifying the application.

User-Agent strings in mobile

In the mobile space specifically this string has historically been used to recognise devices. Since each device has very specific features and installing third party plug-ins has always been (and still is) nearly impossible, recognising a device easily is fundamental to the creation and provision of content that is not only optimised for a device, but often that it is simply supported. In the early 2000 the User-Agent string of a Nokia 7110 was  “Nokia7110/1.0 (04.84)“. At that time it gave all the information that was needed. Over the years a lot of information has been added and eventually, recently, a lot of mobile browsers have started emulating the strings that were usually provided by desktop browsers, unfortunately picking up a lot of useless information and removing what was useful.

The analysis

Here are my four sample User-Agent strings, an iOS 4.1, an HTC/Google Nexus One, a Nokia N8 and the latest Fennec on an Android device:

• Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-gb) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7
• Mozilla/5.0 (Linux; U; Android 2.2; en-gb; Nexus One Build/FRF83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
• Mozilla/5.0 (Symbian/3; Series60/5.2 NokiaN8-00/010.016; Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/525 (KHTML, like Gecko) Version/3.0 BrowserNG/7.2.5.2 3gpp-gba
• Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre Fennec/4.0b1

iPhone User-Agent string

Let me start with the first one, the iPhone. There are a number of things here of interest: that it’s an iPhone, the software version, the type of browser and possibly the browser version. I will get back to why the browser version may or may not be useful later. Do we care it’s “like Mac OS X“? Do we care that “KHTML (is), like Gecko“?
So what we could do is strip out everything that we don’t need and

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-gb) \
 AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 \
 Safari/6531.22.7

becomes

iPhone/4.1 AppleWebKit/532.9

If I was a VP at Apple and had any decision power I would also specify the iPhone model and it’s probably a good idea to also be explicit about the vendor (it happened that two vendors named two devices the same way). Here is a very short string that tells me everything I need:

AppleiPhone4/4.1 AppleWebKit/532.9

Google Nexus One User-Agent string

Second on my list is the Nexus One, again a lot of information we don’t need. Who needs to know it’s Linux when we can’t really hack the kernel or install X.org (at least from the browser!)? Who cares about the language when there is an appropriate header for that called Accept-Language? So what we have is

Mozilla/5.0 (Linux; U; Android 2.2; en-gb; Nexus One Build/FRF83) \
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

but what we should have is

GoogleNexusOne/2.2 AppleWebKit/533.1

Nokia N8

Nokia, with the N8 and a lot of other devices has taken the best of all worlds. On one side emulating a desktop browser and on the other side bringing all the extra information about J2ME, audio and video streaming and other details that have been meaningful in the mobile space at some point in time. The sad truth is that all these supported environments and protocols are so fragmented that the name alone is not useful and hence, just a burden. Let’s clean up the house, remove the information that the device supports MIDP-2.1, because anyone who has ever seen the build-chain of a J2ME application knows that you need to know a lot more about the specific JSRs that are available and of course the device-specific quirks. Also, don’t forget that this is just an example, Sony Ericsson, Samsung, LG and the other vendors are all more or less the same. So bring some fresh air, leave space for what is important and change this

Mozilla/5.0 (Symbian/3; Series60/5.2 NokiaN8-00/010.016; \
Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/525 (KHTML, \
like Gecko) Version/3.0 BrowserNG/7.2.5.2 3gpp-gba

to this

NokiaN8/010.016 BNG/7.2.5.2

In this case specifically, we probably need one little extra information. All the Symbian devices by Nokia in the last few years also have an environment called Web Runtime or WRT that lets you create Web applications that look like native applications, are installed on the device and can access device APIs. So we could use “B” or “BNG” for the browser and “W” or “WRT” for the Web Runtime, so if you developed a Web application and  request a remote page, the server will know if it can send extra Javascript to pull up the device location or contacts and so on. It’s a nice piece of information to know, right?

Fennec on Android

Now on with my last example and I am picking Fennec on Android simply because it’s probably the newest kid on the block, but the exact same comment would be valid for Opera browser and other third party browsers that you can install on your mobile device. For starter, there is no reference to the device, there are a already more than 100 of Android devices, how will I know which one? How will I know if it’s Android 2.2 with Flash or not? So this is what we have today

Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20101006 \
Firefox/4.0b7pre Fennec/4.0b1

This is what we should have (and for the sake of this example I am assuming the device is a Nexus One):

HTCNexusOne/2.2 Fennec/4.0b1

Now, you might comment that I will know if Flash is available looking at some other headers. Well this would be true, if the browser sent the appropriate information. If you have been into mobile detection for a little while you will know that since day one you could not trust the Accept header, mostly because browser vendors have been very bullish about their ability to support content, to then generally disappoint their users (and most of all the _customers_ of mobile sites and content providers). For example the Accept header of this Fennec for Android is “text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8” (see the full headers recorded on logme.mobi). As you can see, this browser supports ANYTHING (the little */* towards the end), isn’t that great? Now, will it play a real-video? Probably not. Will it play Flash? MAYBE! Will it play an H.264 video? I don’t know. Oh, yes, these are the same Accept headers that Firefox for PC sends, but it is also true that on my PC or Mac I can download the file and play it with VLC or I might want to download a Word document and read it later. On mobile devices it’s slightly different and most mobile devices do not let you download and store files and even after I have downloaded it, my context is normally such that if I cannot read the file now I don’t care. Hence the server needs more information in order to provide the right content; the server might have the file in the right format, if it knew what is supported.

PS: In fairness Opera Mini adds extra headers to tell you the device it is running on, when they know it and this depends on how you installed the client.

Conclusions

I am not advocating overloading the headers, we have examples of other headers sent to the servers that are nearly completely useless. Looking at the N8 again, it sends a header about the Music shop version (X-Nokia-Musicshop-Version: 13.1012.15), do I care? Unlikely. Would I care to know the version of Ovi Maps installed so that I can provide a link that will launch the Maps application? More likely!

As you might have noticed, I have stripped the “Mozilla/” at the start. There is a myth that servers will not provide the Web site or will provide a very limited version of the site if that string is not there. I have asked many times and although everyone seems scared of this, I do not know of a single site that really does it today. If you know one, please let me know and most of all WHY is this site doing this?

One final note, earlier I said that the browser version might not be required. As a rule of thumb I would say that if the server knows the browser version it’s better because the server will either not care, or if the site actually has different versions for different browsers it can provide that version. In the future I hope that what will matter is just the browser, i.e. is this a standards-compliant browser? If so, I can use Javascript to detect what works and what doesn’t or I can create my CSS in a way that degrades gracefully. Today, I think we are on the right track and things are quickly moving in the right direction, but we are not there yet, so for the next 1 or 2 years and until everyone gets a new shiny devices with a cool browser, we will have to be a little patient on this and try working together on what is still not solid enough.

So please, if you are browser vendor, take out what is not useful and keep what developers need.

You might or might not know that the service is hosted by wordpress.com and they use WPTouch as a mobile theme. WPTouch is normally known as the best WordPress plugin if you want to give an iPhone-like look to your mobile site and we all know how cool is the iPhone nowadays.

This is all good, too bad that while the site looks very good, it is not exactly optimised for performance. I was pleased to notice that WordPress serves the WPTouch theme to Symbian devices like the Nokia N8, less pleased to see the KB downloaded goes up to the stars. The iPhone does not show the data usage in real time, so most of us, including myself, have never noticed this. When I tested this morning the size of the homepage alone was about 1.5MB, yes, 1.5 megabytes!
I tested again this evening on my Mac, emulating the iPhone user-agent and this is what I got

As you can see there is a single image using 544KB and then a bunch of other images eating up a lot of memory and bandwidth. The most annoying part is that that image is not even visible! It is hidden in one of the posts and if you don’t click that post… Well, you will never see that big, fat image. If you look at the other files, the HTML is just 60KB and all you need is probably in the range of 200KB (CSS, JS, and some basic images). In short, we are wasting 1.3MB – every time we visit the homepage.

Since this theme is served only to high-end devices why not use a little javascript to load the images when needed? Of course, the way it is now is snappier to open each item on the homepage, but wow, I have to pay for those 1.5MB. Most iPhone users have a nice data flat rate, but a) not all have an iPhone with a contract, b) I still have to wait even if it’s free and c) this is why operators are getting tired of giving us flat rates.

If you are curious, this is how the TechCrunch homepage looked when I tested, the OneRiot image is a little over 10KB.

Glossary

Some of the terms in this blog post’s title are buzzwords these days, so let me first clarify what I mean here.

WML: YES, I really mean the WML that was part of WAP 1.
Widgets: by “widgets” I mean the self-contained mini-applications that you can download and install on your mobile device, created with Web technologies like HTML and Javascript. The most obvious examples are of course Nokia’s WRT and the W3C’s Widget Rec, now already implemented in various browsers and devices.
HTML5 Web app: Web applications developed as a single-HTML-page that is updated mostly using Javascript, i.e. with almost no page reloads.

Why WML, Widgets and HTML Web apps are the same thing

Forget for a moment the technical details or the SDK that you use to create one of these applications. Let’s start from this sentence:

My service is developed using the latest Web technologies, it contains mark-up and scripts, you can download it with a single request and while you use it you will see different content without actually making new requests to the network

It might sound crazy, but the above sentence applies to WML, Widgets and HTML web apps. Why? Let me explain.
WML is a highly underestimated mark-up that died a cruel and early death because the rest of the technology was not good enough yet (and possibly because it was a bit too strict). On the other hand it had some interesting ideas that have been disregarded for years or we have forgotten too soon. A WML page was called “a deck”, a deck was one file with a header and then one or more “cards”. Each card was rendered as a page on your mobile device and you could use anchors to jump from a page to another. The main reason for this was to save network requests, i.e. download everything you need in one go and then browse within that content until you need more.
A Widget, in the context I described above, is normally one HTML page, some CSS, some Javacript and an XML file that acts as a descriptor. You download and install it on your mobile device. When you run it, a sandboxed browser opens your starting HTML page and some Javascript and CSS magic loads the content and updates it according to your actions. Of course it is much more advanced than what WML (and WMLScript) did, but 10 years have also gone! What are the key selling points of a widget? That once installed on your mobile device it looks like a native application and that you have the markup pre-loaded in your device’s memory. IMHO, it sounds a lot like a pre-loaded WML page and in fact something that was also possible with WAPPush (you would send a compiled WML page via SMS and the device would parse it and display it).
An HTML5 Web app is not rocket science and in fact Web apps existed way before HTML5. Think about Gmail, it’s a Web page, but you never hit the “back” button or load a new page. In essence Gmail (like any single-page Web app) is one Web page with a lot of CSS and Javascript that load and update different parts of the page. VERY similar to a widget with regards to both technology and functionality, much more advanced than a deck in WML, but not so different in concept.

So what’s the story?

The two ideas might have started from different assumptions, for WML it was a matter of saving network requests, for Widgets was the idea of creating an application that looked native, but was as simple as a Web page and for HTML5 it was a bit of both, look like a native application and optimise network requests. The end result seems to be the same.

Of course, the road to success (if we can already declare Web apps a success) has been paved with many tiles that were missing at the time of WML and even when the first Widget implementations came. We now have much better connectivity and lower latency, we have better Javascript engines and a way of styling pages that allows to manipulate elements in the page easily.

If you are like me and thought that Widgets were not interesting, what is your thinking with HTML5? Why is an HTML5 Web app any better than a widget?
A Web app is downloaded from a URI and is always up-to-date, but updating a Widget is almost as easy. A widget can be installed in your device and appear as an icon like a native application, but you can also save a bookmark of a Web app and some devices let you add shortcuts to bookmarks in your mobile device’s menus.

So can we call Widgets useless and love Web apps? Can we call WML a complete failure?
Are these just names created by marketing and sales teams for the same thing?

While I was editing the code I also improved the code segmentation part that in some cases might have sent incomplete data.

I have written an update, should be much better.

Still to do is the AdSense integration and managing the manual placing of the javascript/img.

If you were testing the previous version of the script, please upgrade now!

Preamble

My normal browsing starts from four main sites: dabr (i.e. Twitter), Facebook, Google reader, search. From there I normally follow links and consume content that is on the larger Internet.
Also, getting used to the non-touch interface was hard initially because I got so accustomed to zooming and panning easily with my finger. Anyway, since touch is just not a feature of the E72, I will not be discussing here if touch is better than non-touch.

Native browser

The first few weeks I used exclusively the native browser, I wanted to have a clear idea of how the browser works and what is the performance. My hope was that it would simply be good enough.

There are two main cases to consider of course, the site designed for mobile and the site designed for a generic Web browser. In my daily roving on the Internet I end up on everything from good optimised sites, to Flash-only site.
The performance is obviously different and a mobile site always worked better, in any case it is fair to say that the browser overall works. To me that’s a fact, you can go on pretty much any site and it will work. Flash is not supported, but that is OK with me (Flash lite IS supported, but I cannot remember when I last saw any content).
When you visit Web sites that are not designed for mobile devices, the browser normally shows you a portion of the screen and then you can scroll in all directions. This is a feature that Nokia introduced many years ago (was it 2005? 2006?), when they first released the WebKit-based browser and it’s still there, working exactly the same way. Although it took me a bit to get used to navigating the page with that small map on the top right, it does the job. Average sites will work well and you will be able to browse around and read your content. The articles or body of the page is normally adapted in a thinner column that fits your screen and this makes it easy to read (yes, in rare occasions you have to scroll a tiny bit, but that is also true for Opera Mobile). The inability to zoom out makes it hard sometimes to get an idea of where are things on particularly complicated pages (think of mashable or techcrunch) and of course you will occasionally not be able to see a picture all in one screen (you will have to scroll to see it).
Page loading overall feels slow and while it would be OK on a 3G or even 2G network, it is never snappy, not even on Wifi. Of course, when I am at home or in the office I will most likely use my PC, but I still happen to quickly check on my phone once or twice a day and in those occasions it should be immediate. Speaking of mashable, the page is just too complicated for the browser (or maybe the CPU) and scrolling around and reading, is close to impossible and certainly not pleasant.
Another thing that drives me crazy is that the browser supports multiple tabs, but you are not able to actually open a new one. What you can do is go on a site, click on a link that opens a new tab and THEN and only then you can switch between the two (or more) tabs and have multiple pages open at the same time.

My conclusion is that it’s not a bad browser, but is not exactly up to my requirements as a power-user.

Opera mobile

Given the non-complete satisfaction of the native browser, I went on and started looking for Opera. While my first thought was for Opera Mini I soon realised that Opera Mobile is free as well. Of course, the idea of using a proper browser with all the bells and whistles seemed too good to be true.

Installation went smoothly and while to this day I am still not quite sure how to manage the quick links that you have when you open Opera, I immediately felt at the helm of A PROPER BROWSER. Tabs, quick links, google search always handy. It felt very good. Opera Mobile immediately became my favourite browser and I started using it every day instead of the native one.

Unfortunately it did not take long for me to go back to use the native browser occasionally, and eventually abandon Opera Mobile. Here is why.

Loading feels snappier than the native browser, although I have not done proper measurements I have for example switched between the two in the same network conditions. On top of that add the zooming in and out, it works and it’s a really nice feature. The very same interface to zoom out seems flawed in its design, though. While you are still loading a page the right soft-key has the dual functionality of stopping the page load AND zoom out, which means you cannot zoom out until the browser is done loading. I am a very impatient user and the idea of zooming out and starting to look at other details while the page finishes loading is something that I would love to do. A minor issue that ruins a feature the would otherwise be so good.

I have 3 major issues with Opera Mobile that are really blocking from further use.
The first one is that it often generated memory limit errors when browsing long enough and this eventually also generated a couple of crashes. Not good.
Secondly, many times I received a page timeout error, something that rarely happened with the native browser, which tells me that Opera has probably set the timeout limits too low. That seems very strange for a browser that is designed to be used on a mobile device that might have bumpy connection speeds and unstable networks.
Thirdly, a side effect of Opera’s bullish approach of “we know best, give us the best content you have” creates some issues on highly optimised sites like Google reader. The short version of the story is that it does not work, the long version is that the design for desktop browsers is just too complicated for a small screen and too slow to use and the mobile design does not work well with Opera Mobile.

These three things, unfortunately, made me kiss good bye to the power of tabs and search at your fingertip.

All this is great, but what about mobile devices?

Well, if your visitor is using a device with a good browser such as Mobile Safari (iOS devices), Android, WebOS and Nokia’s Symbian devices all should be good, but what about all the others? I am not talking about WML phones that are today a rarity more than anything, I am talking about all those low and mid-end devices that sell like hot-cakes. Think about all the Samsung, Sony Ericsson, LG and (reasonably-priced) Nokia that people get for free from their operator, or buy for about 50-100 Euro. It is true that heavy users will likely buy a high-end device with a big screen and a good browser, but that does not mean we should suddenly forget the long-tail.

With this in mind, and knowing the WordPress Mobile Pack (WPMP for short), I made a few small changes to Yoast’s script. The theory is very simple, based on the device groups defined by WPMP provide the standard JavaScript for the high-end and  use the Google’s official ga.php file for the rest. The changes are quite simple and are all applied to googleanalytics.php, plus you will need Google’s ga.php. Also, this system plays on the safe side as if the device is not correctly recognised, in the worst case the 1px image is server, which means that it should really work with anything, even the WML devices.

REQUIREMENTS

• WordPress Mobile Pack version 1.2.3 or higher
• Google Analytics for WordPress by Yoast
• Download the script adaptation based on Google Analytics for WordPress 4.0.8, a.k.a Google Analytics for WordPress for Mobile

INSTALLATION

1. Both WPMP and Google Analytics plugins should be enabled and correctly functioning (of course!)
2. Make sure in the “Mobile Theme” menu you have enabled the Nokia templates (this is needed to activate the device group recognition)
3. Save a backup copy of your existing googleanalytics.php
4. Upload the files ga.php and googleanalytics.php in your google-analytics-for-wordpress directory on your server (normally in wp-content/plugins/google-analytics-for-wordpress)

KNOWN LIMITATIONS

Although in theory the custom segmentation is implemented, it is a bit of a hack and needs review with Yoast.

UPDATE

Small bug fixed, see Google Analytics for WordPress for Mobile update.

Configuring WordPress Mobile Pack

Configuring the WordPress Mobile Pack with W3 Total Cache 0.9 and above is a breeze, in fact, you have to do nothing! Just to make sure things are enabled, go to the “User Agent Groups Settings” section of the W3 Total Cache settings, make sure there are two groups enabled (high and low) and leave the default settings. Save. Clear Cache. If you have “Preview mode” enabled, deploy. That’s it.

How fast will this be?

W3 Total Cache generates nice cache files for the mobile version and then uses Apache to serve the files, this means that it will be AS FAST AS IT CAN BE! Enjoy speed and low resources consumption with full mobile support.

To my great pleasure, it was something completely new!

Homepage

The homepage was immediately a pleasant surprise, colours, shades, animated icons moving around to attract my attention.
Immediately visible are a number of icons to access the most important parts of the site. Of course your eye will fall for the big icons, in perfect iPhone-style. You can’t see it in this image, but the icons can slide left and right and when you load the page they are moving to the left and that makes you immediately understand that you can interact. Something that was not equally obvious on the CNBC’s mobile site for the winter olympics, for example. Most important events are the ones most prominent with “Live Betting” always there and of course the World Cup in the very centre as this is that time of the year (or 4-years).

Below are the events that are happening now, depending on the event some times you can’t bet, but you can see what’s happening.

At the very top there is a navigation bar that is consistent across all the site and you can use it to quickly jump to different sections or search for specific events.

Event details

Something that unfortunately I cannot show you here is that when you click on one of the events you see a nice animation when the page loads, i.e. it resembles the action of opening an app. On my iPhone when you click you see the usual spinning image for a couple of seconds and then magically a new page pops up. Although loading feels a bit slow, the effect is really nice.

As you probably noticed there is a little arrow on the left. The first and most common bets are expanded by default, but you get many more that are collapsed and you can skim quickly to find what you want to bet on. This saves space and lets you read quickly. When you expand you get a nice BIG button that you can press and bet. The odds are clearly stated on the button. Very nice.

For each event they have a lot of things you can bet on and this collapsible system is an excellent compromise between speed and completeness.

Placing a bet

Here is a screenshot of what happens when you place a bet: the system registers the bet and a pseudo-cart appears at the top of the page with a number indicating how many bets you prepared so far. Later you will be able to easily finalise them all at once.

As you might have noticed you can do all this without ever logging in, that is required only at the very end of the process.

Easy bets

Some special pages collect major events and let you easily bet on a common element, for example for the world cup there is a collection of all the upcoming matches and you can easily tap on a button and place your bet.

Review your bets

Once you have collected all the bets you want to place you can click on the “cart” at the top and review your list. If you don’t remember or want to review the details of each a nice pop up gives you all the details.

A simple form allows you to tweak your bet and calculates your potential returns. VERY tempting.

Overall

I really like this site and I think it’s a step forward in the design for mobile. Obviously it was designed with the iPhone in mind, the size of images, text and buttons are optimised for the size of the iPhone. Testing on one device alone we all know is easier, but I do not see how porting this design to Android and possibly to the most recent Nokias that run webKit wouldn’t be possible. The efforts of this small company (compared to your usual Google or Facebook) are amazing. This site really stands out both for the quality of the design and the usability. The intent is very clear, make it easy to bet on your mobile and in my view they have completely succeeded.

If I have to complain about something, I think the site does not feel very fast. I don’t know if it’s a network issue, computation on the server side (I am sure they are very busy with the World Cup these days) or anything else. I tested on my Wifi, so we can’t blame the carriers for once. In any case, I think the experience is worth the short wait.

PS: Device detection
Paddy Power implemented a smart device detection system so that any address you hit you will be shown the right presentation, sometimes by redirecting you. This means that you can hit http://www.paddypower.com with your iPhone, PC and any other mobile and still see the correct site. Their default is to have mobile presentation on paddypower.mobi and even if you hit it with your PC, you will still be redirected to the correct desktop presentation. From the perspective of your average user I would say VERY well done, as a mobilist, I would like to be able to force a different presentation and see what happens, but I guess I am a minority

This was true until today. With the WordPress Mobile Pack version 1.2.1 you now can get the best of both worlds. Here is a quick guide on how to achieve it. I am assuming you have installed the latest version of WP Super Cache, already.

1. Activate WP Super Cache
2. Go to the WP Super Cache options
In your admin -> Settings -> WP Super Cache
3. Turn WP Super Cache ON and mobile support

4. Click on Update Status
5. Scroll down and click on Update Mod_Rewrite Rules

6. Make sure WPMP is active
Go to Plugins -> Installed and activate WPMP if not yet active
7. Enjoy speed and mobile content at the same time!


Notes for the geeks
Setting up WordPress this way will generate some extra cache files because you will have a cached version for your desktop versions and up to 3 versions of your mobile site depending on the devices that visit your site. Don’t worry about this too much as Super Cache will clean up old files anyway and if most of your visitors are in the same device class you will not get the other cache files generated.
The integration works in a way that WPMP gives to Super Cache a new key to cache files, so that desktop and mobile pages are separate. Super Cache will be only partial (i.e. like the HALF ON setting) for your mobile content, but and send static HTML files for desktop (i.e. the ON setting). This is currently the best we can get, but soon it might be different, so stay tuned.