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.

The options

Symbian

Symbian is an old operating system that was developed for pocket devices, what we once called PIM‘s or PDA‘s. It was designed for devices that had a keyboard or a keypad, that were low on CPU and battery.
For these reasons Symbian is VERY efficient on battery and CPU. Most of the UI was crafted to work well with a keyboard and a joystick. You might not know it, but in your Nokia N8, designed to be entirely touch and with no hardware keyboard, you still have a lot of keyboard shortcuts that you will likely never use. The Nokia E7 that is finally reaching the shelves now has a lot of shortcuts that you can use with your qwerty keyboard.
The N8, with a 680Mhz CPU, performs almost as well as most Android devices that use a 1Ghz or better CPU, because it’s highly optimised, but you will never know it, because the UI is too clunky (more on this later).

Unfortunately what users expect at the high-end, is not what Symbian can offer today. Many of us are used to recharging their mobile every evening, something that most Nokia customers don’t do. Modern high-end mobile devices are expected to be snappy, to have a great browser with device APIs and graphics hardware acceleration, support applications developed with a relatively high-level programming language that lets you create a decent application or game in a week or so.
Symbian was not designed for this.
Symbian^3 has a much better UI than before, mostly designed to support touch, but still with a lot of legacy menus and interfaces. The programming language is C++, with a lot of quirks and strange libraries. This is the result of 10+ years of evolution in a direction that is not what was planned back then. If you know Symbian and C++ very well, your application will have a raw performance that most other OSs can dream of, but unfortunately it will take you 3 months to develop, and not 3 weeks.
This is true for developers out there, but it is also true for Nokia. Despite how hard Nokia has tried to blow new life in Symbian, it failed because the development environment is just too complex.

Unfortunately for Symbian, its highly optimised environment has determined its demise.

MeeGo

MeeGo was developed from the positive experience of Maemo. Maemo was an experiment, but it showed a lot of strong points and a surprisingly vibrant community. MeeGo was built on the best intentions to bring a great new OS built for mobile devices of all types (netbooks, tablets, in-car entertainment, smart phones).
Unfortunately it has not delivered in the time frame that was needed to Nokia not to lose too much market share. iOS and Android devices are selling well, too well to keep waiting. Apple has iPods, iPhones, iPads and appleTVs. Android has loads of mobile phones, is coming to the tablet world and has the Google TV.
Nokia announced in 2010 that it would deliver at least one MeeGo device. Then very late in 2010 announced that it would arrive in 2011.
So far, we haven’t seen anything.

MeeGo is still a great promise, but unfortunately Nokia needs to sell devices today in order to develop a better OS, apps and platform for tomorrow.

WebOS

WebOS, is in my opinion a great OS with a very interesting approach with Web technologies as its development platform. It’s a great idea, that hasn’t really delivered for Palm. HP seems to be betting really big on it with the recent announcement of some very interesting devices in all ranges. That is fantastic for WebOS and HP might be able to work around the operators selling directly to the thousands of medium and large enterprises that rely on them for their servers, networks, printers and computers. It will be a great synergy I’m sure.

What does that offer to Nokia? Well, Nokia might have embraced it, but was HP interested? Probably too busy developing its own devices and integration with all the other services. HP certainly has a grand plan and Nokia might have been a distraction more than a valuable partner.

RIM with QNX

Similarly to HP, RIM has a foot in the enterprise business and something also in the consumer business. It has completed some very interesting acquisitions such as Torch mobile (which resulted in a much better browser in their blackberry OS 6) and TAT. They announced the Playbook tablet (a little too early IMHO) and are busy trying to get QNX to work on their devices starting with the Playbook tablet and later on mobile devices.

Similarly to HP, RIM is probably too busy completing its plans, to be bothered with Nokia. Let’s not forget that Nokia can be a great partner, but will also come with some strong requirements and big personality. At the end of the day Nokia has the infrastructure and experience to sell millions of devices per day, it cannot settle with a partner that will not have time for it.

Microsoft and Windows Phone 7

Of all the mobile OS’s installed on devices that are on the market today Windows Phone 7 is the youngest and likely the one that still has to prove the most. It has a nice new UI, very consumer oriented and it has the Microsoft hat, so you can expect good integration with their enterprise products such as Office and Exchange.
Yet, the browser is not great and while the development environment is the very well known .NET, it does not have a number of developers dedicated to this platform that can make their store very interesting.
Microsoft has been able to convince LG and Samsung to produce mobile phones and that’s great, but the sales so far haven’t been amazing.

Android

Assuming that Apple was not keen on letting Nokia use iOS, Android would have been the most obvious choice. Android is the most mature “modern” mobile OS after iOS, has a good UI, the second best marketplace and a vibrant, growing community of developers. I imagine that the conversation between Google and Nokia went like this:
Andy R.: “Hello Stephen, nice to see you. So you are interested in Android? Well, we think it’s great, we have a great OS, we have a fantastic UI and we have some of the best UI and UX expert in the world working to make it even better. Our developers love our open source attitude and love the Google cloud services. We have by far the best search engine, the biggest ad network and the best maps. You are welcome to take the source and run with it. What can you do for us?”
Stephen E.: “Wait a second, WE have the best maps, ours are vector based and much faster to download, plus we can preload them”.
Andy R.: “Stephen, we have vector maps as well, already deployed on Android 2.3 and even better in 3.0″.
Stephen E. stands up and walks out with a little teardrop.

What Nokia has on the table

So what could Nokia offer, as a partner, to these players that would make the cooperation more interesting for both? Nokia is by far the number one player in the low-end market and in most if not all developing countries. In India, China and South Africa Nokia is basically a monopolist. This is very cool and very good for Nokia’s cashflow, but not of great value for these high-end operating systems. Android is going down the chain of value, covering more and more segments, but it’s still not in the 50-70 USD price range where Nokia rules. All the others have requirements not even close to that price point.

Nokia has Symbian and a large portion of users that today have a Symbian device and will likely buy another smart phone in the next months. Providing a smooth transition is a key selling point (anyone wants to manually enter all their 1200 contacts in the next phone?).

With both the low-end and the high-end device segments come a lot of developers. It is true that Nokia is not the number one platform to develop today but being the number one vendor for more than 10 years means having contact with thousands of mobile experts. That is worth something.
Forum Nokia is of course the heart of the Nokia developer community and that means millions of pageviews per month.

Nokia has acquired NAVTEQ and maps have been an integral part of its strategy for the last couple of years. This is actually a GREAT asset as there are basically only two providers of raw cartography, Nokia and TomTom. With those come points of interest (shops, hotels, petrol stations, etc) and years of experience in navigation, of course.

Last but not least there is the Qt development framework. Android and RIM use Java, Microsoft uses .NET and WebOS is, well, Web. Apparently not very interesting, but don’t forget that Qt developers are normally highly skilled developers breathing Linux and open source software, writing cool hacks and advanced C and C++ in their sleep. That has a GREAT value for anyone that dreams of creating a healthy ecosystem with cool applications that will sell well and will attract customers to their platform.
Along with Qt comes QtWebKit, a port of the great WebKit engine to wrap in native applications. Anyone not taking that into account would be underestimating the power of Web technologies and the desire of Web developers to monetise their content.

Nokia also has a number of services, more or less successful such as Music, Share, contacts and social. I will not go into the details of each, but of course consolidating the users in any existing online service would be great for anyone. Think about Blackberry messenger on 200 million Nokia devices, or Microsoft Live messenger, or finally having someone to talk to on Google Talk. Although none of these is a critical element, they all add to the overall value. A value that Nokia does not want to throw away.

Conclusions

The Microsoft deal

So the answer to Nokia’s hunt for a partner is not necessarily who is the best operating system or platform, but rather which one is the best partner. Which one of those companies will get the greatest benefit from Nokia’s assets and which one will bring the greatest value to Nokia?
Nokia has survived more than 150 years going through multiple mutations, jumping from a market to another, building tires, televisions, PC monitors and boots and eventually mobile phones. While the main focus for the past 15-20 years have been mobile phones, Nokia has diversified its business, it owns NAVTEQ, has a foot in the music distribution business, a foot in advertisement and can provide a great platform to expand pretty much every possible business.

In conclusion Microsoft is the best partner for Nokia because not only it provides many pieces of the puzzle, but it also needs many other pieces.
The partnership with Microsoft will bring great integration in the Maps, IM, advertisement, search, location and more. Both Nokia AND Microsoft will give something to the relationship and both will get something out that they did not have before.
It is going to be tough because these are both very large enterprises that have been working on their own for many years and working together will be hard, but they probably both want to make this work.

The backup plan

Let’s not forget that although Nokia is now going to spend a lot of R&D resources to get as many WP7 devices on the market as soon as possible, it will also keep alive MeeGo and Symbian. If the partnership does not work, both parties can walk away and still might retain what has worked well.
This is what today looks like the most likely scenario for a win-win for both companies (yes, I am being cautious).

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.

E-mail communications became longer and longer, sometimes replaced meetings.

This is all great, in many cases we can participate or just follow discussions from our desk, using only one finger to scroll up and down and read entire threads in a few minutes.

Now e-mail is bloated, it is not as slow as standard mail as delivery is almost immediate, but replies often arrive a few days later, simply because our inboxes are cluttered, e-mails are long to read and often involve complex tasks that will result in longer e-mail replies.

Maybe it’s just me, maybe my e-mails are too long and intricate, but I noticed that often a quick DM or @ in Twitter gives me a reply more quickly than a nicely written e-mail.

Why is that?
It’s the constraint. Twitter limits you to 140 characters, your messages have to be short, straight to the point, no introduction, no examples, no half-company CC’s. “John can you give me X?”

Is there something to learn from this?