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.

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

Now, if you are done reading it, I wonder if you agree with him or not. When I started reading and probably up to one third, I was not understanding where he was going to end up, but then I had a A-HA moment and all of sudden I realised what he means and I completely agree. It is something that has been in my mind for a while, but I was never able to put it down in words as well as Tim O’Reilly did. One of the reasons recently I’ve been paying particular attention to where I sign in, which cookies are in browser and where I go is that I can see where Google are going and how they are expanding their APIs and how developers are using them more and more. Google are amazing at how they are identifying growing trends, developing new technologies or acquiring companies and integrating their existing products. Add to this their release speed and you have an amazing juggernaut heading to the conquest of the Internet Operating System. They are obviously dominating the Web and you don’t need me to tell you that they are doing very well with APIs. Come in mobile devices and more in general mobile computing. Google have not left any base uncovered and they have the already successful Android and the upcoming Chrome OS. Then at the latest Google I/O the Google TV is announced in partnership with Sony, a company that has always tried to develop its own technologies and keep them as closed as possible. If they have given up to Google it means Google is giving them something that is worth a lot.

I read Tim O’Reilly’s post a little later from the original publication and just the day before the Google I/O. Since the initial read of the article the little gears in my brain have been running like mad thinking about the Internet OS and Google TV only added more steam to the engine.

Today I was catching up on Fabrio Capobianco’s blog and found The Google Chrome OS and Android conundrum. Of course he’s on the topic as well.

Android
Android has been very successful, I am not sure if Google expected it to be picked up so well and definitely HTC have done an amazing job. Yet, from a mobile device perspective, many still think it’s not as good as the iPhone. Of course, it’s a hard comparison as the iPhone is really a combination of MANY parts that go from the OS to the hardware to the iTunes store for apps and music.
Google are probably not there yet, they probably don’t have all the tiles in the right place, but they are improving and they have a train that is running fast with releases that come quickly and keep adding new features that put pressure on Apple. The hardware is not exactly Google’s responsibility, but there are so many devices coming from HTC, Motorola, Samsung, Sony Ericsson, etc that at some point a winner MUST come, it’s just a matter of numbers.

Chrome OS
It is still unclear if Chrome OS will be a success or not and vendors have obviously decided to invest in Android for now as it’s a more mature platform. Chrome OS is an easy bet for Google and it plugs perfectly into their existing business model helping us, the users, to get more connected and more on the Web. As they did with Android, they are giving away something for free, in order to speed up the adoption of their existing services. It’s an investment to make sure that the extra money they can make tomorrow actually comes sooner (and they are in control).

Apple and the iPhone
As Tim O’Reilly points out in the second part of his article, it looks like Apple is not getting this thing of the Internet OS. I would add something, either they don’t get it, or more likely they think they are a consumer products company and all they want is build products. They develop or acquire technologies that will make their products better, but only key technologies and they either buy or partner with other companies for things that are less crucial. Think of Exchange, they finally (and rightly so) gave up on developing internally and just licenced it from Microsoft, they get better support and customers are happier. Other things that are more important like Maps, they acquire a company and you can expect the new iPhone OS to have them integrated in some way.
In my view, if Apple decide that they are happy to be a consumer products company, they will let Google go their way, compete where they have to, but not invest in other fields. They will not win the battle for the mobile world and I don’t think there will be a dominant player like Microsoft anyway and they will still be happy with their 5-10% of market share of wealthy customers. It’s not a bad market, Italian fashion’s fame is built around a few expensive brands and yet makes Italy famous in the world even if very few people will buy an Armani suit in their entire life.

Google wins anyway
Fabrizio Capobianco, in his post, says that Google would like Chrome OS to win, but Android is going too well and so they have to keep it going and improving and pretend they are happy about it. However these are only ways to accelerate something that is already happening, i.e. Google becoming the heart of Internet services or at the very least a major part of them. Either way, they are making sure they are a vital part of our lives for the next 10 years or more.

The future of computers
The end of my post would have been the previous paragraph, yet, I would like to add some thoughts on  why I think Android will win the race against Chrome OS.
Chrome OS is just a limited GUI with the browser and easy access to the Web. It is a way to help us understand that on the Web we can do everything we need.
On the other hand some are saying that the iPhone has proven that a new interface that comes from a completely different angle can be a winning UI compared to the old Windows PCs. Many pointed out that the iPad is a big iPhone and in a way it is and if you have used it, you will know that it’s very good to use, you can hold it easily, you can read well and it lives very well on your coffee table. This is a new way of using a computer at home and it is perfectly in line with the original plan of Apple 30 years ago of bringing a computer in our homes and let us enjoy personal life using it. It’s easier and more intuitive than a PC and it does almost everything that we need.
Android has the same approach. Google TV proves that it is climbing up the chain of home services.

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.

In the meantime, do not despair, you CAN get W3 Total Cache to work with the WordPress Mobile Pack and with other mobile plugins. If you know about mobile user-agents, the solution is to add keywords to the list of rejected user-agent strings. This will stop the cache to work completely on mobile, but at least it will produce content that is mobile friendly and all your PC visitors will still get the cached content. If you need a step-by-step manual, here is a very good one with images and examples, Blog Building: How to Configure W3 Total Cache to Work with WPtouch for WordPress.

For now, this is the best you can do. Stay tuned for more updates.