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.

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.

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!

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.

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.

I don’t know if it was this one that was particularly good, but there are so many positive things that I’ve experienced at this event, that I strongly recommend you to go as soon as you can. You have gone already? Then go again!

If you don’t know what happens in a WordCamp, then here’s a quick list of things you can expect. To start off, it’s not a conference for geeks only, it’s about blogging and writing good content to publish on Internet. I admit you will likely meet a bunch of geeks, but you will also meet a lot of “normal people” that are passionate about Internet and want to get their ideas online. The general attire is very relaxed and equally the socialization is very easy going.

I have been to a number of conferences and this was easily one of the best and I’m saying so because I have a long list of things I have learnt and things I’ve heard and that now I was to learn better. This is probably the best outcome that you can get from a conference.

Small disclaimer: I was one of the speaker and not surprisingly I was talking about mobile, but for once, not to mobile nerds. Presentation coming to the Internet very soon.

I download the tiny zip from the official site, opened the readme.txt file. The file itself did not tell much if not that it would make my blog mobile. Fair enough, I took the php file and copied it in wp-content/plugins. That is all that was apparently required to install and in fact in the admin interface I had a new plugin available, I selected it and enabled on my Mac. The site URL was a local one, of course, wordpress.local (and added to my hosts file to access it).

Looking for some further information I went back to the official site (that I won’t link) and notice that in homepage there’s a nice link mentioning that my wordpress.local is the latest site which installed the plugin! A bit surprised I opened the small PHP file and noticed that there are two calls, one on plugin activation and one on deactivation. Being PHP it was not so hard to find what it does and I was very disappointed with the discovery. On both events the plugin calls a remote API AND send an e-mail to Andy Moore mentioning the site name, URL, and the admin’t email, YES, YOUR E-MAIL address.
In my case, the SMTP server was down, so the e-mail did not get delivered, but to my great disappointment the API was reached and that is why my local install was mentioned on the website.

Nothing wrong has happened, in fact I’m pretty sure if Andy wanted to contact me he would definitely find a way, but it was very disturbing to discover that this happens without letting the user know. If I had been a bit smarter I would have looked at the code and I would have discovered it, the problem is that the average wordpress user will not bother to look at the code and will probably not even be capable of understanding what’s going on. We are not all developers and my impression is that Andy is relying exactly on the inability of his users to disable the feature. The software is GPL and everyone is welcome to look at and change it and that is exactly why I did not even bother to look at it, I took it granted that nothing bad would happen.

In case you wanted to disable this functionality (but it’s probably too late now, I admit), what you should do is open wordpress-mobile.php, find the function wordpress_mobile_plugin_activate (it’s at line 1664 in version 1.3), go to the first line of the function and just add the following line:
return true;

Do the same for the function wordpress_mobile_plugin_deactivate (line 1673 in version 1.3).

Andy has definitely spent time to get this plugin working and maintaing it and I think it’s perfectly fair for him to ask for money and ask his users to provide usage details, but asking and taking are different operations, I my opinion.