Archive for May, 2011

HTML5 gets very chatty

May 26, 2011

The web started birth with very much a “click and wait” experience. Any interaction with the server meant a round trip of data across a slow line and ended up with a page refresh. In the Web 2.0 era things changed dramatically with the exploitation of an API: XMLHttpRequest the foundation of a framework called Ajax. With Ajax web pages could now interact with the server without page refreshes. This was transformational, and especially as bandwidth speeds increased people got very inventive with Ajax and created applications that started to feel much more like desktop applications.

Whilst this created a massive step forward developers were still having to create proprietary approaches, sometimes using plugins, for other forms of communications with the server. Ajax allowed the client to call the server, what about the other way round? And further still how about a server sending a message to multiple clients – either on the same machine but in different windows or indeed to multiple physical clients?

Step forward HTML5 which brings a number of new capabilities for communication. There are plenty of resources that provide tutorials on how to use these new features, the focus of this blog is just to raise awareness of the features and the possibilities they present.

Cross Domain Messaging is one of my favourite features of HTML5 and worthy of it’s own separate article, which I will do in my next post. Essentially Cross Domain Messaging allows you to send messages between separate applications running in separate iFrames, Tabs or even browser windows. It is facilitated by the existing PostMessage api (see next post for more details).

XMLHttpRequest has also been upgraded to support Cross Document Messaging. This now means that an application can communicate with multiple servers. For example imajine a News page that contains an article about Japan, the page may have separate sections containing local weather and currency rate updates. Previously the page would have been built up with content from different sites at the server end, now it is possible to do this from the client. A further enhancement to XMLHttpRequest is the addition of Progress Events. Previously when a request was made to the server there was only the “readstatechange” event, which was limited and no implemented consistently across browsers. Now there are several more meaningful and useful events (loadstart, progress, abort, error, load, loadend) that can be processed

Another constraint the web has faced has been the ability for servers to send messages to clients. The most common example being stock markets feeds. Typically developers have created a polling mechanism to get updates from the server at regular intervals most likely using XMLHttpRequest. This creates unnecessary load and traffic to the server. HTML5 also introduces the concept of Server Sent messages using the EventSource interface.  This is basically a publish and subscribe approach: the client subscribes to a message event source, and the server code publishes messages to those subscribers.

XMLHttpRequest and Server Sent Messages are uni-directional messages, but what if you need bi-directional messages: the ability for either the client or server to send/recieve messages? Well HTML5 also has an answer for that with WebSockets (note it is possible to achieve bi-directional messaging without WebSockets, but it is much more difficult, unreliable and network inefficient)

WebSockets is a large topic, however the key point to be made here is that it is a more efficient and standard mechanism for enabling bi-directional messaging. The first step in the process is establishing a handshake between the client and server, this is done by upgrading from http protocol to the websocket protocol. Where websocket communication provides a significant advantage is that once the handshake is established, communication between client and server is free from the heavy load of http headers! Http headers can reach 2k in size, which is a massive overhead if the message is only 10 bytes.

When you compare this to applications that have implemented a polling approach you can see that WebSockets are not only more efficient in message size but can significantly reduce unnecessary traffic created by polling and reduce latency of updates (created by the polling time).

Using WebSockets today does require a server of which there are many available, and of course like all HTML5 features browser support varies and hence needs to be checked.

This post aimed to key you a flavour of some of the key new features that enable web applications to become more chatty and in doing so not only make applications faster, efficient but richer and more dynamic than we have been used to. I believe just these features alone could drive a new generation of web applications across many industries like gaming and financial services. Could this be Web 4.0 ?

 http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#comms

HTML5 Forms richer applications

May 19, 2011

In the early days of the internet data capture forms weren’t the most exciting area of web. Initially every click meant a pause for pages to refresh. Then as Java-script evolved some client side processing meant fewer click-wait-page-refresh cycles. However the real transformation came about with Ajax (enabled by XMLHttpRequest) and suddenly pages felt much more dynamic and responsive (although in the background our broadband speeds were also improving). This innovation certainly was one of the cornerstones of the web 2.0 era.

Developers have got used to using libraries or writing their own code for client side processing to validate data entry, create rich client behaviour like hiding/showing form sections and incorporating more than the basic set of input controls (such as sliders, accordions, google-suggest lists etc.).

However in the background the WHATWG were creating the next upgrade of forms processing capability into HTML5. The new specification continues to push for better user experiences with more client side processing without plug-ins and libraries, and instead facilitated by the browser following open standards.

A number of new input types have been introduced such: tel, url, email, number, color, datetime, search, range. These not only come within inbuilt validation, but also allow browsers to present additional functionality for example: tel would allow mobile browsers to present an onscreen keyboard specific to number entry, color would allow the browser to present a color picker and a range input could be displayed as a slider.

There are lots of new attributes and some of these will especially make developers lives easier when creating richer forms applications. For example:

  • The placeholder attribute allows sample/help text to be displayed in an edit field (typically text is greyed out) – thus assisting users with the kind of response required in the field without navigating to help.
  • The autofocus attribute can be used to set the field in focus.
  • autocomplete attribute aids security of the form data bu allowing you to control which form data elements may be cached by the browser, and which explicitly cannot be.
  • Masked input field can be created using the pattern attribute allowing rich formatting and validation of data into edit fields e.g. <input type=”text name = “Card number”  pattern =”[0-9]{16}]” for a credit card number field.
  • datalist attribute allows for data entry of specific values only, as specified in the list
  • min/max attributes set validation of values in numeric fields
  • For range fields, the step attribute
  • The required attribute tells the forms the field is mandatory for completion

The specification also introduces client side validation status’s. It is possible to check the forms entire status as to whether all fields are valid or not, or too check the validity of individual fields. The standard defines 8 types of validation status’s:

  • · valueMissing Validates “required” fields
  • · typeMismatch e.g. Entering char’s in number
  • · patternMismatch e.g. Email address format incorrect
  • · tooLong i.e. Value exceeds maxLength
  • · rangeUnderflow i.e. Value exceeds minimum set
  • · rangeOverflow i.e. Value exceeds maximum set
  • · stepMismatch value conforms to min/max/step
  • · customError For business logic validation errors

The standard also allows for developers to define which individual fields should be validated (willValidate), when to execute validation (checkValidity), query/set the local error message (validation Message) and switch off form validation (formNoValidate).

There are many other features in the specification that will also make forms more dynamic and performant whilst making developers tasks much simpler. For many business applications client side forms development just become easier, however to mitigate security issues there will still always be the need for server side checks also. I also wonder what over-zealous marketing departments that like to define customer experiences down to the last pixel will think of the browser taking responsibility for how it will display certain field types?

I believe the enhancements for forms with a drive to client side processing (including my soap box topic of client side session management) all make for a dynamic and richer user experience that will be welcomed by all.

http://www.w3.org/TR/2011/WD-html5-20110113/forms.html#forms

In the early days of the internet data capture forms weren’t the most exciting area of web. Initially every click meant a pause for pages to refresh. Then as Java-script evolved some client side processing meant fewer click-wait-page-refresh cycles. However the real transformation came about with Ajax (enabled by XMLHttpRequest) and suddenly pages felt much more dynamic and responsive (although in the background our broadband speeds were also improving). This innovation certainly was one of the cornerstones of the web 2.0 era.
Developers have got used to using libraries or writing their own code for client side processing to validate data entry, create rich client behaviour like hiding/showing form sections and incorporating more than the basic set of input controls (such as sliders, accordions, google-suggest lists etc.).
However in the background the WHATWG were creating the next upgrade of forms processing capability into HTML5. The new specification continues to push for better user experiences with more client side processing without plug-ins and libraries, and instead facilitated by the browser following open standards.
A number of new input types have been introduced such: tel, url, email, number, color, datetime, search, range. These not only come within inbuilt validation, but also allow browsers to present additional functionality for example: tel would allow mobile browsers to present an onscreen keyboard specific to number entry, color would allow the browser to present a color picker and a range input could be displayed as a slider.
There are lots of new attributes and some of these will especially make developers lives easier when creating richer forms applications. For example:
•    The placeholder attribute allows sample/help text to be displayed in an edit field (typically text is greyed out) – thus assisting users with the kind of response required in the field without navigating to help.
•    The autofocus attribute can be used to set the field in focus.
•    autocomplete attribute aids security of the form data bu allowing you to control which form data elements may be cached by the browser, and which explicitly cannot be.
•    Masked input field can be created using the pattern attribute allowing rich formatting and validation of data into edit fields e.g. <input type=”text name = “Card number”  pattern =”[0-9]{16}]” for a credit card number field.
•    datalist attribute allows for data entry of specific values only, as specified in the list
•    min/max attributes set validation of values in numeric fields
•    For range fields, the step attribute
•    The required attribute tells the forms the field is mandatory for completion
The specification also introduces client side validation status’s. It is possible to check the forms entire status as to whether all fields are valid or not, or too check the validity of individual fields. The standard defines 8 types of validation status’s:
•    valueMissing        Validates “required” fields
•    typeMismatch        e.g. Entering char’s in number
•    patternMismatch        e.g. Email address format incorrect
•    tooLong            i.e. Value exceeds maxLength
•    rangeUnderflow        i.e. Value exceeds minimum set
•    rangeOverflow        i.e. Value exceeds maximum set
•    stepMismatch        value conforms to min/max/step
•    customError        For business logic validation errors
The standard also allows for developers to define which individual fields should be validated (willValidate), when to execute validation (checkValidity), query/set the local error message (validation Message) and switch off form validation (formNoValidate).
There are many other features in the specification that will also make forms more dynamic and performant whilst making developers tasks much simpler. For many business applications client side forms development just become easier, however to mitigate security issues there will still always be the need for server side checks also. I also wonder what over-zealous marketing departments that like to define customer experiences down to the last pixel will think of the browser taking responsibility for how it will display certain field types?
I believe the enhancements for forms with a drive to client side processing (including my soap box topic of client side session management) all make for a dynamic and richer user experience that will be welcomed by all.
http://www.w3.org/TR/2011/WD-html5-20110113/forms.html#forms

HTML5 knows where you are!

May 12, 2011

A few years back I was deemed a heretic by many of my colleagues and friends  when I suggested that HTML5 will remove the need for writing many mobile applications. I was pummelled with questions like:

  • But how will they work offline?
  • Are you saying a browser user experience can rival a platform native one like Apples?
  • You do realise that most games require “threading” how you going to do that?
  • What about storing data locally, can you do that?

I was able to fend of most of these, but the one I couldn’t at the time was about accessing the device applications like Camera and GPS. Well things have moved on and whilst I am no longer deemed a heretic there are still some corridor’s whispering doubt.

One of the big features of mobile technology used by many apps is the phones location and location based services and application have already been through a huge hype cycle.

Under the catch-all banner of HTML5, although it is a separate subspec, the W3C Geo Location working group are making location based applications a reality for web developers. It has been around a while and hence is fairly mature and stable now.

A device (even a desktop) can provide location information in a number of ways:

  • IP Address (this is typically the location of the ISP rather than your machine, but ok if you simply want to check which country the user is in)
  • Cell Phone triangulation (only fairly accurate, very dependent on the phone signal so could be problematic in the countryside or inside buildings)
  • GPS (very accurate, takes longer to get location, dependant on hardware support and can be unreliable inside buildings)

Location data can also be simply user defined: however this is dependent on the user entering accurate information.

Of course one of the key concerns will be privacy but the spec covers this with an approach that the requires a user to give permission for location information to be passed to an application. Note the application can only access location information through the browser and not directly e.g. from the GPS device. Hence the browser enforces the user permissions for access.

The Geo Location API allow for both one off request to get the users current location or for repeated updates on the user’s position, developers write simple callback routines for both approaches. The key information provided includes: latitude, longitude and accuracy. Accuracy is a %value of how close the longitude and latitude values are to the user. Depending on the device you may also get additional information such and speed, heading (direction of travel) and altitude.

As per any quality application you process errors accordingly, especially responding to a failure to get hold of location data because of signal issues or other reasons. Hence retrieving location information is fairly simple, the real hardwork is in processing that information and that requires good old fashioned quality programming ;o)

This specification presents a huge opportunity for web developers to create applications once deemed only the domain of platform specific code, and I for one am very excited !

http://dev.w3.org/geo/api/spec-source.html