Showing basic performance details of page resources

The Performance Timeline is a spec that extends the Performance interface defined in the Navigation Timing spec and adds a new interface called PerformanceEntry. The new additions give to developers a quick overview of the performance of each resource that composes the page and the order in which each resource was loaded. For anyone that wants to quickly see the timing information of the page this is more than enough and very easy to use. Below you can see the most basic use of the API:

1
2
3
4
5
6
7
8

function simplePerf() {
 var pe = performance.getEntries();
 for (var i = 0; i < pe.length; i++) {
  if (window.console) console.log("Name: " + pe[i].name + 
   " Start Time: " + pe[i].startTime + 
   " Duration: " + pe[i].duration + "\n");
 }
}

Once you have a list of the resources that the browser has loaded you can further explore the details of each HTTP request. Similarly to the Navigation Timing API developers have access to the timings of any redirects, DNS lookups, network connections and of course the time to make the actual request and receive the response. For each resource is also available the initiatorType, i.e. how the resource is referenced in the HTML page; the types available are ”css”, “embed”, “img”, “link”, “object”, “script”, “subdocument”, “svg”, “xmlhttprequest”, “other”. If you have IE10 on your Windows PC or a Windows Phone 8 device you can visit this page and try yourself.

Start time and duration of each resource

Breakdown of the time it took to load each resource in the page. Values are grouped by Network, Request and Response.

How does it work?

The example is made of 4 parts, the HTML itself, a tiny CSS file to give a minimal styling to the tables, a JavaScript that does most of the work and a couple of images. The code is available on Projects.

onload, featureDetect() is fired. featureDetect() checks the browser support for the Performance Timeline and Resource Timings specs and shows a message in the page. If supported, it also enables the two buttons. This is the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function featureDetect() {
 var rt = "Oh rats! Your browser does not support the Resource Timing spec :(";
 var pt = "Oh rats! Your browser does not support the Performance Timeline spec :(";
 
 if (!!window.performance.getEntries) {
  pt = "Excellent! Your browser supports the Performance Timing spec";
  var e = window.performance.getEntries();
  for (var i in e) {
   rt = "Excellent! Your browser supports the Resource Timing spec";
   document.getElementById('myButton2').disabled=false;
   document.getElementById('myButton3').disabled=false;
  }
 }
 document.getElementById('perf_support').innerHTML = 
  document.getElementById('perf_support').innerHTML +
  rt + "<br>" + pt + "<br>" + "<br>";
}

If the user clicks on “Load another image” the function loadResources() is fired. All this function does is create a new image() and append it after the existing image, this is useful to display more timing data, more on this later. loadResources() on its own is not very interesting and you should not spend time on this. What is interesting to see is that the browser continues keeping track of all the events and the information is available via JavaScript. Notice that I use a PHP script to delay the delivery of the image; the only reason is to make sure that the response time is a big enough number.

Clicking on “Display basic performance data” a table is shown. The table is printed by the function displayPerfData() which takes window.performance.getEntries() and loops through the elements to show when the browser started loading each element and how long it took to load it. The script uses the duration property to access the final timing. For basic measurements this is probably all you need to know, easy, hu?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

function displayPerfData() {
 if (!!window.performance.getEntries) {
  var perf_data = loadPerfTimeData();
  document.getElementById('perf_data').innerHTML = "" + perf_data + "<br>" + "<br>";
 }
}
 
function loadPerfTimeData() {
 var e = window.performance.getEntries();
 var perf_data = "<table id='table_perf_data'>
  <thead><tr><td>Resource</td><td>Start time (ms)</td>
  <td>Duration (ms)</td></tr></thead>\n<tbody>\n";
 for (var i in e) {
  if (e[i].name == "document") {
   perf_data = perf_data+"<tr><td>HTML document</td>";
  } else {
   perf_data = perf_data+"<tr><td>"+e[i].name.replace(/^.*\/|\.$/g, '')+"</td>";
  }
  perf_data = perf_data+"<td>"+e[i].startTime+"</td><td>"+e[i].duration+"</td></tr>\n";
 }
 perf_data = perf_data+"</tbody>\n</table>\n";
 return perf_data;
}

The browser provides the values for the start time and the duration in accordance to the High Resolution Time spec. The start time is particularly interesting because it shows exactly when the browser initiated the request for the object. This also means that the browser keeps track of when the user clicked on “Load another image”.

Similarly, “Display detailed performance data” loops through getEntries() to get a list of the resources the browser loaded, but instead goes into more details and breaks down the data into network-related operations (DNS lookup, open the connection, SSL, etc), request time and response time. For my example I bundled up the timings into three buckets, network, request, response, refer to the Processing model for a detail of all available properties. In my tests the request time was often close to zero when using a Wifi. For the sake of readability I have rounded the timings. This is how it works:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

function displayDetailedPerfData() {
 if (!!window.performance.getEntries) {
  var d = loadResTimData();
  document.getElementById('detailed_perf_data').innerHTML = "" + d + "<br>" + "<br>";
 }
}
 
function loadResTimData() {
 var e = window.performance.getEntries();
 var perf_data = "<table id='table_perf_data'><thead><tr>
  <td>Resource</td><td>Network (ms)</td><td>Request (ms)</td>
  <td>Response (ms)</td></tr></thead>\n<tbody>\n";
 var t = [];
 for (var i in e) {
  if (e[i].name == "document") {
   // for the document refer to window.performance.timing instead,
   // we skip it for this example
   continue;
  }
  perf_data = perf_data+"<tr><td>"+e[i].name.replace(/^.*\/|\.$/g, '')+"</td>";
  if (e[i].requestStart==0) {
   // resource is cached, some entries are zero, 
   // we default to fetchStart instead
   perf_data = perf_data+"<td>"+Math.round(e[i].fetchStart-e[i].startTime)+"</td>";
  } else {
   perf_data = perf_data+"<td>"+Math.round(e[i].requestStart-e[i].startTime)+"</td>";
  }
  perf_data = perf_data+"<td>"+Math.round(e[i].responseStart-e[i].requestStart)+"</td>";
  perf_data = perf_data+"<td>"+Math.round(e[i].responseEnd-e[i].responseStart)+"</td>";
  perf_data = perf_data + "</tr>\n";
 }
 perf_data = perf_data + "</tbody>\n</table>\n";
 return perf_data;
}

While I was writing the script I also thought of another example, but eventually decided to take it out as I did not find a suitable use in my specific use case. What I wanted to show was how you can also query for specific entries and filter by type looking at the initiatorType. What I initially thought was to fire an event once the extra image is loaded and show data about it specifically. I thought it was interesting to attach an onload event to a resource that I am loading at a later stage and measure its performance, but the example is so small that it did not fit. If you are curious look at resourceTiming(). First of all I get a list of objects filtering by type “resource”, this means I will get a list of objects such as images and stylesheets, then I loop through them and filter out everything but images. Calculating the time it took to load it is a matter of making a subtraction.

The source code is available on GitHub.

When to check the performance object?

In my example I decided to use a button for two reasons, I wanted to make sure it happens once all the parts of the page are loaded and I wanted to allow visitors to load the extra image and then refresh the timings.

Truth is, there isn’t a right time to access the performance object, it depends on your application. If your script makes an XHR request, loads images dynamically or anything else you can always check both when the operation started and how long it took. The “Load another image” button is an example, more complex Web apps might have much more meaningful reasons to monitor the performance tied to specific events other than onload.

Browser support

The specs described here are really new, infact they are just candidate or proposed recommendations, so we cannot expect full support across all browsers. IE10 both on Windows 8 and Windows Phone 8 is the first browser to support them. Yes, you read that right, IE10 is ahead of the pack on this one. Chrome is expected to implement it soon and Mozilla is a member of the Web Perf WG, so we can expect it there too.

Create HAR

While researching on performance I started looking into a packaging format called HAR. Both Firebug on Chrome’s developer tools can generate a HAR (basically a JSON file) of your session. The good thing about HAR is that you can store it and analyse it later and see the performance of one or more pages. For your production Web site you probably want to build something scalable, that will read a lot of data and aggregate it, you might want to do it in-house or you might want to use a third-party service. On the other hand, while you are creating a new Web app you might want to monitor specific pages or specific parts of your app and you want to do it with high level of detail. For this use case I thought that creating a HAR and posting it to a remote server could be a nice feature. What you do with the HAR posted is up to you, in my case I simply view it with an online tool called HAR online Viewer.

So let’s start from the basics: HAR 1.2 spec. What we want to do is build a JSON with all the information about the current page and store it somewhere. In my example I do this for a single page, you might want to use a session or store it somewhere (localStorage?) and then make a single POST with all the information you need.

My example is composed of two parts, the HTML and JavaScript that runs in the client and a very simple PHP script on the server that stores the file locally.

The markup

For this sort of example the markup you need is very limited, but to make it more similar to a regular Web page I added a stylesheet, an image, some text and a couple of third-party scripts (Twitter and Facebook buttons and Google analytics). Three links are available, “Generate HAR” which will fire the script to generate a HAR file and POST it to the server. The script will also check that your browser implements the Performance Timeline and Resource Timing specs, if not it will do nothing. Assuming your browser can provide the needed information, clicking on “See the dynamically generated HAR on HAR viewer” will show you the HAR of your current session. Please note that although the page works on modern mobile browsers it is designed for a big screen. If you are using a browser that does not implement the needed API’s you can click on “See a HAR file generated from a previous session with a Lumia 920 running IE10 Mobile on HAR viewer” and see a session I recorded previously.

The scripts

For this example I use two scripts, I use PPK’s browser detect and a script I created.
My script is very simple in concept, there are a number of values that I must provide for a valid HAR 1.2 JSON and I read them from either the performance object or from the window and document objects.

generateHAR() is where it all starts, I collect some basic details about the browser, the page title and initial timings.
fillEntries() is where most of the work happens. Although simple in concept there are few things to be noted. The fields that HAR supports and those provided by the Resource Timing API don’t match exactly so I had to make some adjustments. For example HAR has a field called “blocked” that represents the time the browser waited for an available slot, but this information is not available in the Resource Timing API. Similarly the Resource Timing API exposes information about redirects that are not part of HAR. I tried to bundle together what made sense.
HAR requires integer numbers, so I round all values. Because of this the generated HAR occasionally failed to validate as the numbers did not add up exactly to the total time. From my tests the rounding occasionally generated an error of 1 or 2ms, so I decided to use the “wait” field for which I had no data anyway. When the rounding makes the sum of the intervals smaller than the total I set the “wait” field to the difference in time, when it’s smaller I actually decrease the total time (I know, dirty). Here is the code:

1
2
3
4
5
6

twait = Math.round(rl[i].duration) - tdns - tconnect - tsend - treceive ;
ttime = Math.round(rl[i].duration);
if (twait<0) {
 ttime = ttime-twait;
 twait=0;
}

Probably the most interesting thing I learnt while writing the script is that some of the timings will be empty (this is actually by spec!). Imagine the previous example where I was displaying data about a page; the second image is loaded dynamically, fired by a user event (clicking the button), if you try to calculate the time it took to load, fields like responseEnd will be empty until the image has finished loading. Similarly, if there were no redirects, redirectStart and redirectEnd will be empty, so if you try to make operations with those you will get unexpected results. What is ALWAYS set is startTime, so I added a few extra checks to make sure the starting time in all my subtractions is set:

1
2
3
4
5
6
7
8

nextFrame = rl[i].startTime;
tdns = (rl[i].domainLookupEnd) ? Math.round(rl[i].domainLookupEnd-rl[i].startTime) : 0;
if (tdns) nextFrame = rl[i].connectStart;
tconnect = (rl[i].connectEnd) ? Math.round(rl[i].connectEnd-nextFrame) : 0;
if (tconnect) nextFrame = rl[i].requestStart;
tsend = (rl[i].responseStart) ? Math.round(rl[i].responseStart-nextFrame) : 0;
if (tsend) nextFrame = rl[i].responseStart;
treceive = (rl[i].responseEnd) ? Math.round(rl[i].responseEnd-nextFrame) : 0;

Notice how the response time is a negative number, this is because the image hasn’t finished loading and so responseEnd is still 0

Internet Explorer also supports the property fileSize for documents and images. I implemented the support for it and kept the default value of -1 for the other browsers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

fileSize = -1;
httpStatus = "200";
httpText = "OK";
if (rl[i].name == "document") {
 fileSize = document.fileSize
}
// a dumb check to see if fileSize is supported, of course you 
// MUST have at least 1 image in your page
if (!!imgs[0].fileSize && rl[i].initiatorType == "img") {
 for (ii=0;ii<imgs.length;ii++) {
  if (imgs[ii].src == rl[i].name) {
   // it looks like fileSize is -1 when image is loaded from cache.
   // Not documented
   if (imgs[ii].fileSize == -1) {
    fileSize = 0;
    httpStatus = "304";
    httpText = "Not Modified";
   } else {
    fileSize = imgs[ii].fileSize;
   }
  }
 }
}

Once all is ready I generate a JSON and POST it to the server. All sessions are stored on the server, but there is a cronjob that removes them after 7 days.

If you have a computer or a device with IE10 you can try this at http://logme.mobi/jsnt/har.html or you can look at a previous session that I created with a Lumia 920. The source code is available on GitHub.

TODO

I noticed that the HTML page has a total duration that is equal to loading the entire page and all its resources. I am investigating how to get the actual data for the HTML alone. If I can, I will fix it later.

Performance and RUM tools

There are a number of tools out there that already take care of measuring the page performance on the client. Google Analytics probably gives the simplest overview and for free. If you are looking for something more advanced you should check out a couple of open source projects: Boomerang and Web Episodes are both framework for timing web pages. They offer different degrees and techniques to measure page performance, but they are both a lot more advanced than my examples and they cater for all the browsers in the market today. If you like the idea, but want to rely on a professional to take care of this, I suggest you check out lognormal (developers of Boomerang) and Torbit (who use Steve Souders’ Web Episodes).

Resources

• W3C’s Web performance WG publications (see all the specs the group is working on and their status)
  • Navigation Timing (PR as of 26 Jul 2012)
  • High Resolution Time (PR as of 23 Oct 2012)
  • Resource Timing (CR as of May 2012)
• Navigation Timing documentation on MSDN
• Performance Timeline and Resource Timing example source code
• Boomerang library
• Web Episodes library
• HAR online Viewer and other HAR adopters
• HAR generator source code

This article is a cross-post from Measuring the speed of resource loading with JavaScript and HTML5.

The Navigation Timing API

Up until recently browsers have taken care of everything around resource prioritization, memory management and resource loading. With the rise of JavaScript, Web developers feel the need to be more in control and at the same time have more responsibility. If a Web app requires a lot of resources you might want to tweak what you load when based on the actual performance loading a page. The W3C has a number of specs in the works, some of which already implemented by browsers, that allow Web developers to measure how quickly Web contents are loaded. The Navigation Timing API is already implemented by IE (9 and later), Chrome and Firefox on the desktop (also see can I use) and on mobile by IE9 and later, Android 4.1 and Chrome on Android.
You are probably all familiar with WebKit inspector’s resources panel; look at this screenshot from an early implementation of the page resources, here you can see how long each resource took to load and you have details about when the request started, how long the browser waited and how long it took to transfer.

WebKit inspector’s resources panel, taken from https://www.webkit.org/blog/197/web-inspector-redesign/

The Navigation Timing API is a first step in this direction. In the past you would have used Date.now() to measure the interval of time between two events, but with the Navigation Timing API you get access to the full timing information related to the page, from when the browser opened the connection to when it resolved the DNS name to when it finished loading the page. All in milliseconds. I should clarify that the Navigation Timing API gives you information about the entire page, not each resource that composes it.

How to measure the page speed?

I found a lot of great articles about the Navigation Timing API and a couple of examples that really caught my eye, but I did not find an example that I could really copy and paste, so I thought I’d create one. Check it out at http://logme.mobi/jsnt/index.php

My example is quite simple, load a basic HTML page with some text and an image and record how long it takes to load. There are few things to note. First of all my code is VERY simple, I wanted it to be this simple, this way it’s a lot easier for you to read it and copy what you need. It’s all in one file, making it dead easy to see all the piece.

The Navigation Timing API introduces a new attribute, window.performance, which hosts 2 more attributes called timing and navigation. timing holds timing information about the loading of the page and navigation holds information about the actual HTTP request performed, i.e. if it navigated there (clicked on a link or the user entered the URL), if it’s a reload or a history traversal, going either back or forward. Simple.

Let’s start with the good news, all three major desktop browsers support the unprefixed attribute, window.performance. If you wanted to support older versions of Chrome or IE9 beta you must use respectively webkitPerformance and msPerformance (I did not find any references of mozPerformance on MDN, so I assume Mozilla went straight to the unprefixed version). On mobile the API is supported, unprefixed, on IE9 and higher, Android 4 and Chrome on Android. It is not supported on any version of iOS up to 6. Unless you have a very good reason for this, it is safe to stick to the standard, but just in case you wanted, I have written a simple check in my script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

featureDetect.supported = (window.msPerformance 
   || window.webkitPerformance || window.performance
   ) ? true : false;
 
[...]
 
featureDetect.unprefixed = (self.performance) ? true : false;
 
[...]
 
if (featureDetect.unprefixed) {
  var t = window.performance.timing;
} else if (featureDetect.prefixed == "ms") {
  var t = window.msPerformance.timing;
} else if (featureDetect.prefixed == "webkit") {
  var t = window.webkitPerformance.timing;
} else {
  alert("Unexpected error while fetching navigation timing data.");
}

The main action happens in printIt(), there I look at the window.performance.timing array and loop through each value to calculate the time each step took. I use the order array to order the different steps. Depending on what you are measuring you might want to look at different parts of the load process. For example you might have heard Steve Souders recommending that you avoid redirects, but then we all see how Twitter, Facebook and Google send us through one if not more redirects to follow a link. How much do those cost? If there was in fact a redirect the timing attribute will contain the redirectStart and redirectEnd values. The URL I provided earlier is a tiny PHP script that redirects the browser to a static page, for me, the redirect takes about 340ms, i.e. a third of the total load time, that’s 1/3 of the time wasted.

You now have an idea of the information that you can collect with the Navigation Timing API. Microsoft has a more complete example that also gives you a sense of how a page gets slower as you add resources, Navigation timing (although it is designed to be cross-browser, when I tried with Chrome 22 and 23 it did not run correctly, works fine with Firefox and IE).

Can I debug from my PC?

The short answer is “nearly”. You can enable the remote debugger on Chrome for Android or use Visual Studio for Windows Phone and dump data from the window.performance.timing array. For the standard Android browser, you still have to rely on something weinre.
If you wanted to collect information on a server for statistical purposes you could build your own format or you could use HAR; either way you will need a server to collect the information.

What else?

There are two other specs that are very much complementary to the Navigation API, the Performance Timeline and Resource timing. In short, the first one lets you see in which order each resource has been loaded by the browser and the second one lets you access detailed loading information of each resource. While the Navigation timing API gives you an overview of the whole page load, you might want to know how long each image or each external script took to load. These specs are already in very good shape, so far IE10 is the only one to implement them with Chrome coming soon. I will cover these in another article very soon.
If you have followed recent trends in Web design you will understand why these API’s will be very helpful. Think of responsive Web design where some resources are loaded selectively, it can be hard understanding exactly why your page is slow unless you can see exactly what happens and when. If you are relying on external resources (like Google analytics or a facebook button) you might want to avoid loading them if there is too much network latency. IE9 and later already implement a property called msFirstPaint that tells you when the document began to be displayed. Chrome already implements the memory property that gives access to JavaScript memory usage data and the Web performance WG is working on a spec.

Wait! Where’s the code?

I could have setup a repository for my example, but honestly, it’s so small that you can just go ahead, right-click and save it.

Read more

I did a lot of reading before I wrote this article, these are some of the useful resources that I collected:

• W3C’s Web performance WG publications (see all the specs the group is working on and their status)
  • Navigation Timing (PR as of 26 Jul 2012)
  • High Resolution Time (PR as of 23 Oct 2012)
  • Resource Timing (CR as of May 2012)
• Microsoft has some excellent documentation on Performance and Timing API’s for IE9 and IE10
• Yottaa’s site Website assessment, link on homepage
• Mobitest by Akamai, formerly Blaze.io
• Measuring page load speed with Navigation timing @ html5 rocks, look at the nice breakdown of each event and the order in which they happen
• Kasia wrote a bookmarklet that shows the page speed in a waterfall style similar to WebKit Web inspector, code available on GitHub: Breaking down onLoad
• HAR online Viewer and other HAR adopters
• More about feature detection and Modernizr, the feature detection library

This article is cross-posted on Nokia Developer’s site at Measuring site performance with JavaScript on mobile.

What’s new in IE10

IE10 and IE10 mobile are substantially the same browser. In I will try to highlight some different behaviors often determined by the different hardware configurations and environments. To give you an idea consider the input element, it now supports a new state for the type attribute: “number”; if you are using a PC with a full keyboard you will not see any difference, but if you are using a device like the Lumia 920 with a virtual keyboard, that keyboard will only show you numbers. Try using the “tel” state and the keyboard will show numbers, the plus sign, the dash and the space. These simple enhancements will make the life of your users a lot easier. This different behavior in different environments is true for pretty much all browsers and all OS’s.

As of today, IE10 implements most of the HTML5 spec related to forms and in fairness none of the current browsers covers 100% of the spec. The good news is that all modern browsers have wide coverage and they all degrade gracefully when something is not yet supported.

What doesn’t work

As mentioned there are a few things that are not yet implemented and I suggest you check can I use for more details on cross-browser support and look at the official Microsoft documentation for the specifics of IE10.
Although IE10 supports most of the improvements to forms it does not support the output element, Microsoft doesn’t clearly state if it supports it or not, so I thought I would clarify. Custom validation error messages are supported in Windows 8, but not on mobile. Custom validation error messages are not supported in iOS 6 or Safari 6. Similarly, the datalist element works in Windows 8, but not on Windows Phone 8.
HTML5 defines a number of new properties for the input element such as valueAsNumber, stepUp and stepDown, Microsoft’s documentation says they are supported, but I could not get any of these to work on either Windows 8 or WP8.
Either way, there is no reason for you not to use it as it degrades gracefully and we can expect that it will be implemented at some point.

Update: The stepUp and stepDown methods actually work when the input type state is “range”.

How does it compare to other mobile OS’s?

Here is a quick summary table of the features that are not consistent across different OS’s. I recommend that you look on can I use for more details and of course always test on real devices.

A real world example

I built a simple form covering some of the new features of HTML5 forms. First of all I wanted to show how the new elements and attributes behave in IE10 mobile and how some gracefully degrade. This is how it looks like in Chome 22 (probably the most complete implementation today) and how it looks like on a Lumia 920.

Chrome 22

Windows Phone 8 on Lumia 920 (2 screenshots merged to show the entire page)

You can try it yourself at http://logme.mobi/html5/form.html. Look at the code and feel free to take what you need, but don’t expect accurate error checking and validation unless it’s specifically useful for this article.

As you can see the placeholder texts are there, some fields are surrounded with a red glow and some with a green one, these are defined in CSS using pseudo classes for required and optional fields. You might have noticed that Chrome shows a placeholder for the birthday field, that’s because the browser correctly interprets the “date” state for the type attribute of the input element, but on IE10 mobile this field is treated like a normal text field (the expected graceful degradation).
This is how I defined the input field for the name:

1

<input type="text" id="name" name="name" placeholder="John Doe" required>

And this is how I defined the input field for the birthday:

1

<input type="date" id="bday" name="bday">

And my pseudo-class for the required fields, notice that I still defined the prefixed versions, mostly for mobile (read more about box-shadow support on can I use):

1
2
3
4
5
6
7
8

:required {
 border-color: #88a;
 -webkit-box-shadow: 0 0 5px rgba(0, 0, 255, .5);
 -moz-box-shadow: 0 0 5px rgba(0, 0, 255, .5);
 -o-box-shadow: 0 0 5px rgba(0, 0, 255, .5);
 -ms-box-shadow: 0 0 5px rgba(0, 0, 255, .5);
 box-shadow: 0 0 15px rgba(0, 0, 255, .5);
}

If you use a lot Chrome or Safari you might be familiar with the little widget on the far right of the “Donation” field. As I was writing my example and testing I quite liked the functionality of it. When testing on IE10 and later checking the spec I realized that this is an extra that Chrome adds. HTML5 adds instead two new methods of the “input” element named stepUp and stepDown and the developer is left with the burden to implement it, but also the freedom of designing it as he wishes. Either way all browsers evaluate the value correctly. Since I define a “min” and a “step”, the value will be considered invalid until the user enters a multiple of 10. If you test on your Windows Phone 8 device you will see that the surrounding color will change from red to green if you enter for example the number 20. Look at the source code to see the CSS pseudo-classes. This is the markup I used to define the input field:

1
2
3

<input type="number" id="donation" name="donation" required 
  min="10" step="10" title="Type the amount, only multiples of 10"
  oninput="test_output.value=donation.valueAsNumber+10">

Chrome 22 on Mac:

See the little arrows on the right of the input field that automatically increment or decrement the value based on the value of the step attribute

IE10 mobile on a Lumia 920:

Value correctly evaluated according to the input attributes and no extra widget added

Creating a widget to handle the stepping is very simple. Below is an example I wrote using two buttons and a JavaScript function that invokes the .stepUp(n) and .stepDown(n) methods where “n” is the number of steps you want to increment or decrement the value of the field:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[...]
<input type="number" id="donation" name="donation" required min="0" 
  step="2" title="Enter an even number between 0 and 10">
<button type="button" id="stepUp" name="stepUp" 
onclick="step('up')">Add 10</button>
<button type="button" id="stepDown" name="stepDown" 
onclick="step('down')">Subtract 10</button>
[...]
 
<script>
function step(action) {
  var donation = document.getElementById('donation'),
    min = donation.getAttribute('min');
 
  if(isNaN(donation.valueAsNumber)) {
    donation.value = min;    return;
  }
 
  // the actual stepping up or down, 1 is the number of steps
  (action=='up') ? donation.stepUp(1) : donation.stepDown(1);
}
</script>

As you can see I used valueAsNumber in both example. This is another handy addition of HTML5, unfortunately I could not get it to work in IE10, of course you can always use .value.

Next I want to show the “progress” element, in this example I used a very simple JavaScript function to change the value attribute of the progress element and hence change the look of the bar based on how many fields the user has filled.

I did not go into the detail of verifying if the values are valid, it’s really just to show how the browser animates the bar. You can use the CSS3 property “animation-name” to switch between the default (a bar) and a ring. This is the HTML:

<progress id="progBar" value="0" max="100">0%</progress>

Input type states like email, number and tel affect the virtual keyboard layout. As you would expect the keyboard for email is the standard virtual keyboard with the “@” symbol immediately available, on the other hand, using the “number” type a keypad is displayed and using the “tel” type a keypad with digits, the plus sign, space and dash are displayed. Very handy, see the screenshots here:

WP8 shows a keyboard to enter phone numbers

You might also have noticed the little JavaScript that is executed in the “donation” input field, if the browser supports it it will update the value of the output element. In IE10 it degrades gracefully and always shows the default value.

Continue reading

This article covers most of the new implementations in IE10, but not everything. I have collected more resources that I think are very valuable, if you haven’t read them yet, I strongly suggest you do it now.

• Making forms fabulous with HTML5 by Jan Kleinert
• A form of madness by Mark Pilgrim as part of Dive into HTML5
  • HTML5 form validation
• PPK’s “HTML5 tests – inputs“, i.e. support table
• For cross-browser support information, check out the always great can I use
• The current state of HTML5 forms @ wufoo

Microsoft has a lot of documentation specific for IE10, I found these articles particularly useful:

• HTML5 forms
  • Progress element
• A very complete example of what is supported in IE10
• Download the full source code of a forms controls sample
• CSS3 animations in IE10

 This article is cross-posted on Nokia Developer.

Organizing the event

It was still cold and snowy in New England, but some of the original participants of Mobilewood thought it would be great to meet in this area in Spring. Although only ten people participated in the first edition of Mobilewood they wanted to open the discussion to more people, get more thinking and more ideas and build on the concepts that were defined the first time. Since I moved to Boston in February it was very easy for me to immediately say YES to the invitation to Mobilewood 2.

Josh Clark did an amazing job scouting rental properties and found the perfect place in Truro, MA, at the top of Cape Cod, surrounded by the Cape Cod National seashore park.

Indoor pool in the Mobilewood 2 mansion

This time around nine of us made it to the work retreat. The plan was to arrive on Thursday afternoon and leave on Sunday. While Scott Jehl and I are local, most of the others were traveling from all over the US. We all knew each other either from previous conferences or because of previous work, yet we thought it would help to introduce ourselves he first evening. We talked about what keeps us up at night both in work and in real life, that would be the starting point for our work. We gave ourselves a night to think and the day after the real work started.

Moving the Future Friendly thinking ahead

Friday morning we got all our ideas on the wall, sorted them, grouped them and decided what we wanted to achieve during the weekend. When you have so many brilliant people in one place you want to reach for the moon, but time is incredibly precious and you have a clear deadline of about 48 hours. We had to be laser focused.

We split in three groups and started thinking about how can get more people to embrace the Future Friendly values, how we can help them and how they can help others.
We agreed that responsive Web design has evolved to a stage where you can create a good Web site or app applying the main principles, but that it’s still very hard, so we wanted to dedicate some time to think about what can be done better and more easily. Trying to look further ahead, we tried to imagine what is coming for the Internet and the Web in the next few years and what we can do, as the creators of Web contents to influence that future.

Come aboard

It was nearly impossible to cover all the topics we set for ourselves and that is OK with this type of meeting. You want to set some goals, but you also want leave space for improv and see what happens. We all agreed that the main goal of Future Friendly is to spread the word, in a way educate on how we can all create better content for the Web that works well on all sorts of devices. The more people read, learn and practice the principles the better it will get. We defined many steps that will help this happen, but we also tried to distill the most important elements. The result is a new page on the Future Friendly site titled “Come aboard“. If you don’t already know the site I recommend that you go and check it out now, if you already know it, see the new section.

The biggest take-away for me regarding the community engagement is that techniques evolve and then become deprecated quickly, but the thinking lasts long and that is what we want to do with the Future Friendly thinking.

Future of the Web

As geeks that carry all sorts of devices with us it was easy to agree that Internet and the Web are becoming pervasive. The technologies that were created to deliver Web pages are now used for much more such as audio, video and raw data (think about REST APIs that use HTTP as a transport, but show data such as your tweet or your open graph). We think that these are the foundations for a new set of devices, some of which will consume this data, some will display it, some will produce it and some will do both. Think about the Nest thermostat that controls the temperature in your house, but can be controlled via a Web site or an app on your phone. Think about the upcoming Leap motion that will let you control your computer waving your hands and pointing. Then imagine a future where multiple devices will cooperate, for example imagine having a Web browser on your TV, you will say “TV, open the Boston Globe site” and the TV will show the site, but then… How will you tell the TV which article to open? How will the browser know which link you mean? Now think about building the Web of the future, it is already complicated with click and touch events, think of adding “voice” events and you get the idea. Now think about the Kinect it’s an additional device that allows me to use my body and my hands to control what is basically a computer. What if many devices could interact with each other, each could offer certain inputs and outputs depending on what it is. A mobile phone with a touch screen can be used as a trackpad, the screen can be used to display the temperature of the fridge or the time until your cake is baked. Before this can happen and be useable some innovation needs to happen in the browser and of course in Web apps. We think we can and should influence some of the upcoming technologies.

We are geeks

As you would expect we all had our computers and various devices at hand. You might need some testing right?

Mobilewood 2 devices

The Mobilewood 2 gang

This is us trying to be serious… or not.

Group photo of Mobilewood 2

Just give me the solution

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!