theThought's thoughts

Today @Rem taught me that "Browsers have Wings"

Today was day one of WebDirections in London (tomorrow is a rest day, the conference starts properly on Thursday).

It was workshops day today and I attended “Browsers have Wings” a workshop by Remy Sharp (@Rem).  The topic of conversation was HTML 5 APIs.

Remy started with some context indicating that HTML5 is rapidly becoming a brand name accumulating many elements that are not actually HTML 5.  For example often associated with HTML5 are technologies like GeoLocation, WebWorkers, WebSockets and WebStorage.  These API’s however are not part of the HTML5 specification they are simply being developed alongside and used in association with HTML5.  I believe this is rather like the OS/2 PS/2 confusion way back when where people would associate OS/2 with the PS/2 even though they were completely different.

So what is included in HTML5?

• Canvas
• Video
• WebForms
• Offline applications

With the exception of WebForms these were the topics for the day, although we did do work on the other associated API’s as well.

This was not a workshop for the Novice, almost everyone in the room was an experience developer with HTML/JavaScript/jQuery experience.  They were from a range of organisations including Sunday Times and the World Health Organisation as well as numerous small companies.  There was no time wasted on basics such as the simple DOCTYPE declaration or how well formed (or not) the markup should be.  Instead it was straight into the first topic.

Video

In this section we learnt how to embed video natively and how to degrade this for browsers that do not support HTML5.  We learnt how to replace the native controls with custom controls, which events are available and how we can control the volume, play position etc.  We were running locally so there was no real discussion regarding buffering but we did learn how to know when the video was loaded and ready to play.

Canvas

Having settled in to the topic and done our first exercise (the whole session was hands on – with people typing like mad) we moved on to the Canvas element.  First up was understanding the difference between SVG and the Canvas and when to use which.  For example:

• SVG is excellent for vector graphics where as canvas is very pixel based.  
• SVG has an object tree and so there are layers, canvas is flat no layers at all

Once we had got this under our belts we learnt how to draw basic shapes (rectangles, circles) this is very similar to the process used in Flash so was easy to get used to, however, the lack of layers made it sound like it was really restrictive.

Next we learnt that we could move beyond basic flat shapes to gradients and from gradients to patterns and from patterns to images and/or video.  This concluded with an exercise where we created a link to an image and drew that image into the canvas.  Why do this you might ask?  Well we were then able to manipulate the image drawn to the canvas (for example make it greyscale).  This was done by manipulating the individual pixels of the image.  In my case, trying to be adventurous I combined the canvas and image with a slider to allow the user to change the transparency of the image.

GeoLocation, Storage and Offline

After lunch (a brief affair of very English sandwiches) we moved on to a trio of topics.  Starting with GeoLocation we learnt how to capture the current location of the user, demonstrating how the user has to give permission for this to happen.  We learnt how to understand if something went wrong (for example the user said no) and how to know whether something went wrong even when it seemed to go alright (understanding the accuracy of the location data).  The exercise related to this seemed to revolve around trying to prove that Brighton is not the centre of the universe.

In the Storage section we learnt about how useless cookies are and how useful local and session storage are.  We learnt how to store data and retrieve it and how to inspect the current data using our browser.  During the day we working primarily in Chrome with Remy giving clear indications (when he remembered) of the support in other browsers.  Lastly we looked at how to make an webpage work offline, this is principally around the building of a manifest file that indicates what should be cached to the browser, what should not and what to do if a file was is not available when offline.

WebWorkers and WebSockets

We were now getting to the end of the day, however the examples were getting more and more complex and the time spent on each getting less and less.  We were coming to the end of the rollercoaster ride and we were definitely going downhill. 

WebWorkers are a way of introducing threads into the browser.  The Browser rendering service is single threaded so routines that consume the thread for a long period can cause instability warnings to appear.  Web Workers get round this by building new threads and allowing javascript to run inside those threads.  The WebWorkers are sandboxed so they cannot manipulate the DOM or file I/O but they can do heavy weight algorithms without tying up the interface.

WebSockets are a way of creating transactions with a server.  Better than AJAX or Comet.  They are very thin threads of push notifications that do not include headers (only the data being passed).  This allows them to be much faster and to allow realtime conversations with server based web services.

Looking to finish on a high Remy boldly suggested that we work collaboratively on an exercise to end the session.  This would combine a number of the technologies we had been looking at including:

• Canvas
• WebSockets

The idea was that users would be able to draw an image in a canvas, take a snapshot of that picture place it on the left side of their screen and then either create a new image for refine the existing one.  The snapshots captured would be pushed to a web service so that other people could see them.  The right side of the browser was used to show the images that other people had created.  Clicking on those images would make them appear in your own drawing canvas so that you could enhance them and take a snapshot for others to play with.

In Summary

Many people criticise conferences and workshops because they are perceived to give little value.  I have to say that this event was a perfect example of how wrong these people can be.  Remy was Sharp (sorry I could not resist) he obviously knows his stuff, can create code on the fly in an instant and certainly massively increase my basic knowledge of the API’s.  I have to be honest and say my mind was spinning a little towards the end but I am sure that my upcoming flight to KL will give me the perfect opportunity to review what we did and understand it fully.  Thanks Remy, Thanks WebDirections.  I look forward to the main conference, which starts on Thursday.

An Update (Next Morning)

I was almost right.  The following morning @Rem posted the "finished" application on his site (http://rem.im/collab-drawing.html) a number of people have been having fun on it.  Feel free to have a go.  Send the link to a friend so that you can adapt each others pictures.

Future of Web Design (Day 1) - HTML 5/CSS 3 workshop

This week (17th to 19th May).  I am attending the Future of Web Design conference in London. Today was Day 1 (workshops) and consequently I attended a HTML 5/CSS 3 introductory workshop run by Molly Holzschlag a web standards advocate for Opera (www.Molly.com).

Having said that is became clear as the morning progressed that as far as HTML 5 is concerned commercial implementation of the standard is not something that should be considered right now.  Very few of these browsers have implemented some of the new capabilities and consequently there is little advantage in implementing the features let alone a lot of effort in terms of handling those browsers that do not give any support.

The morning of the workshop focused on HTML 5, the afternoon on CSS3.

HTML 5

The session started with a little scene setting.  Effectively a “Why should we be interested, what is HTML 5?” introduction.    The key justification being that today all the major browser manufacturers (Google, Microsoft, Opera, Firefox, Mozilla) have agreed to adopt HTML 5 and are currently working on their implementations.  This is the first time in the history of the Internet that all of them have made a concerted effort to agree on one standard (although their implementations of that standard are less likely to be consistent).

There seem to be five design principles behind the implementation of HTML 5:

• Backward compatibility
• Interoperability
• Clearly Defineable UserAgent Behaviour
• Improved Error Handling
• Evolve Don’t Recreate

Each of these is a challenging objective, for example backward compatability has always been a key driver for many software developments however every iteration makes this more and more difficult.  At some point the Internet is going to have to forget the past or be bogged down by it.  In terms of HTML 5 backward compatability is about equally supporting those who write in HTML 4 and those who write in xHTML 1.0 formats.  The new DOCTYPE declaration was discussed especially in terms of its simplicity.  HTML 5 has no equivalent DTD definition (due, at least partly, to the fact that the concept of DTD’s is dead) consequently the declaration is much simplified.  HTML 5.0 does not have to be a precisely formed as xHTML it was generally thought by the audience that this was not a good idea as it would lead to sloppiness (someone not closing <p> tags can get away with it).   This is no different to coding where someone can use Goto if they want (just don’t expect to get a programming job if someone notices).

The next section focused, briefly on the new elements being introduced in HTML 5 including:

• Section
• Article
• Aside
• Header
• Footer

The key objective here seems to be the removal of DIV tags that are simply sectioning out key parts of the document structure.  It was not made clear whether any of these would have any real advantage over the current use of DIV tags except clearer markup and more obvious CSS 3 synchronisation (as CSS 3 supports these element types as well).

There was also a brief mention of the other elements being looked at such as Mark, Meter, Progress, Time, Command, Datagrid and Details but as these are not yet fully defined no details were really provided.

The next section focused on the improvements to Forms.  Many of the concepts of Web 2.0 will be supported.  The autofocus and required attributes for example significantly reduce the amount of JavaScript that has to be written to deliver client side verification.  New Input types such as Range (for sliders) and search provide new ways of capturing data from the user.

The link tag has also been enhanced with new types such as icon, prefetch, archives, external and license.  The session closed around a discussion on the three most talked about new elements, those that provide embedded media without the need for a plugin.  Canvas provides a drawing palette which can be based on a combination of SVG and javascript to create a fully interactive visual experience.  Video and Audio provide broadcast components reducing the need for Flash (maybe).  The  key argument with the latter two is codec’s.  Which ones will be royalty free and therefore available in browsers?

There was also a brief mention of ARIA (accessibility for Rich Interactive Applications).  This extended only to a definition of the term and the fact it is an offshoot of WIA (Web Accessibility Initiative).

CSS 3

It would be a mistake to think that the whole of the afternoon session was dedicated to the new features of CSS 3.  In fact nearly 90 minutes was a discussion around the basic concepts of CSS including a definition of the term cascading, several discussions regarding specificity (including how to say it in German) and other general rules regarding the use of CSS.  Probably the most stressed point made during this 90 minutes is to not use the !Important facility.  It was identified that this is a hack and a poor one at that that designers should avoid using.

Once discussion did get around to CSS 3 most of the new features were very briefly discussed such as:

• The new Selectors
• Border changes including the use of images and rounded corners
• Multiple columns
• Real Font Support
• Colour control through Hue Saturation and Luminence (HSL)
• Animations
• Transparency
•  Shadows

Each point was glossed over with simple examples of most of them.

Probably the most poignant aspect of the afternoon was the constant switching between Safari, Chrome and Opera as Molly attempted to demonstrate the effects.  This really brought home the fact that no one browser has fully implemented CSS 3 as it currently stands and that the implementations are not consistent.

The session ended with a discussion regarding some of the newer concepts of CSS 3 (those that have not been implemented properly by anyone yet) these included concepts such as FlexBox (a flexible way of creating boxes of content within boxes) and some ways of creating grid structures without using tables.

Some of these latter examples showed how truly complex CSS 3 might yet become.  In its attempt to increase the presentation and dynamics of the internet it is becoming more like a programming language, unfortunately it is unwilling to be verbose so some of the codes are getting shorter and shorter (many are just two letters long).

In Summary

I have to say I was a little disappointed with today.  As a workshop I had hoped that we would go indepth regarding the attribute and reasons for using HTML 5 elements with some good examples of how they might be used.

I had hoped to be told more about how we could implement them today even though most browsers can fully support the features, how graceful degradation  and progressive enhancement could be applied to bring these new features to today’s customers.

This, sadly, was not the case.  Too much time was spent explaining principles I had hoped those in the room already new.  Yes we all learnt something but I think we could have all learnt more.  As a HTML 5/CSS 3 primer it was okay but I could have and have already got 90% of that just “Googling” on the internet.  Lets hope that the next two days brings more realism and less theory.

"one for all" is definitely possible - the Test Centre

In my previous post (read it here) I classified browsers into three types:

• Basic
• Simple
• Rich

This was done so that I could organise the way that I build templates for IBM SPSS Data Collection.  This is part of my project to build a single template that works for all browsers both desktop and mobile.

I defined these three classifications by building some simple web pages and testing a number of different browsers on them.  The web pages has a range of capabilities from basic HTML with CSS styling to complex HTML 5/CSS 3 and JavaScript.

The Environment
A first I tried building a test, test environment on my new Dell 1645, a 64bit laptop running Windows 7 64bit.   Installation of the main desktop browsers was not an issue, however almost all the emulators failed to work properly.  Consequently I stopped and reverted to a Windows XP operating system running in a vmWare image.  I built this using vmWare Workstation and started by taking a blank Windows XP SP 2 install and then performing a series of upgrades to ensure that I had all the latest patches applied and .net 3.5.

The Emulators
Once that was done I started installing desktop browsers:

Then I moved on to emulators for mobile phones.  There were a number of emulators that I wanted to try including the OpenWave emulator that I simply could not download.  It seems that the OpenWave browser and many of the older emulators are no longer available.

I installed a Sony Ericsson emulator which was written in Flash.  This was, consequently a simple installation from Sony Ericsson’s Developer Site (PhoneGap Simulator).  This was by far the easiest of the installers to get working.

The other two emulators that I wanted to install were the Blackberry, because I believe that this is a fairly limited browser that being built by RIM cannot be described as standard and the Android emulator.  I would have liked an iPhone emulator but alas my machine is a PC not a mac so I have to make do with testing on my iPod Touch.

Both of these emulators require the Java Runtime emulator (JRE) so that was the first element to install (JRE is available here).  Additionally the RIM emulator requires the Java Development Kit (download JDK here).

Next it was off to the Blackberry site to download an emulator.  I chose one for the Blackberry Storm (9500), however it is my understanding that you can download a number of them (get a blackberry emulator here).  Downloading the emulator, however is not enough if you want to browse the Internet.  It is also necessary to install MDS which is a Mobile Delivery Service created by BlackBerry.  Not only does this need to be installed but it also needs to be run at the same time as the emulator.  Testing with the RIM was concerning.  There are two modes the first is Page View this is a smartphone mode that I had expected to be as good as Sony Ericsson, Android and iPhone.  What I found was that although it supported HTML 5 and a fair amount of CSS it did not really support JavaScript (even though JavaScript support is switched on).  The other mode is called Column view and is a more basic view that is similar to that provided by very basic mobile browsers.  As can be seen by the following example neither gives a very good experience.  It is really troubling that these phones are the phones of choice for Businesses.

The last emulator was the Android emulator (get the android emulator here).  Like RIM there is an opportunity to download a number of different emulators, unlike RIM downloading them all is much easier and therefore I did just that.  Also like RIM the Android needs more than just JRE and the emulator.  There is also a need for eclipse (get eclipse here).  Careful with this download.  It is a zip which needs to be extracted in the location where you want to run it.  The setup is not an installation routine just a way of quickly setting up the environment and getting to the emulators once they have been installed.  Once these items are installed you are presented with an array of different device types.  Each takes quite a while to load but there is no doubt that the wait is worth it.

So that just left aDesigner.  This too needs Eclipse but as that was already installed this final installation was easy.  I may extend my list of browsers and emulators over time (a proper Nokia S60 is very likely).  I would really like a proper iPhone emulator rather than just Safari as Safari does not give an indication of how screen real-estate is working nor does it allow me to tilt the device.

If you have any emulators that you think I have missed feel free to drop me a line.

"one for all" is definitely possible - the Browsers

A couple of weeks ago I wrote an article questioning whether it would be possible to create a single template that handles the vast majority of browsers and allows Data Collection to deliver the best experience each browser can deliver (read Is “one for all” even possible).

I am pleased to announce, after a number of weeks of hard work that the answer is “YES”.

So what has happened over the last few weeks that allowed me to come to this answer?

The steps so far
I have not yet reached the end of my journey, however, I thought it might be a good idea to allow you to catch up.  I have started/completed a number of tasks including:

• A review of different browsers on the market (or previously on the market) identifying the capabilities they provide
• Locate and install a number of browsers and emulators into a Test environment
• Build a small Data collection survey to allow testing
• Start building a solution

Browsers

I started with the currently installable browsers (Internet Explorer, Firefox, Opera, Safari, Chrome)  Then I tried older versions of IE.  Lastly I obtained some emulators (Blackberry, Sony Ericsson, Nokia), finally I installed a copy of aDesigner for testing JAWS screen reader compatibility.

aDesigner an aSide
If you have not encountered aDesigner before and you are seriously interested in web accessibility you need to look at it now (aDesigner is available here).  aDesigner was built by IBM but it has been donated to the Accessibility Tools Framework (ACTF).  Not only does aDesigner provide clear information about the general level of accessibility of a website (based on its markup) it will also render the website from the perspective of “low vision“ showing how those with poor eyesight will see the site.  Furthermore, if that was not enough, in addition to testing websites it can also test ODF (Open Document Format) files, Flash content and general GUI accessibility of any application.

3 Classifications of Browsers
Having reviewed a multitude of browser capabilities I ended up with three simple classficiations.  These are based on the capabilities of the browser and will affect the way in which the template will be designed.  The basis of the categorisation is the fact that there are, currently, primarily, two platforms that have to be handled:

• Desktop Browsers (PC, Mac and others)
• Mobile Browsers (smartphone, basic phone, portable devices)

Against these two basic platforms there are a number of capabilities that may or may not be used:

• HTML
• CSS
• HTML 5
• CSS 3
• JavaScript

All of the browsers support HTML although some only have limited support of CSS.  Only a few have support for HTML 5 and CSS 3 (as I wrote this Microsoft announced that this list will expand to include IE 9 – review by the Register.com).  Lastly there is JavaScript.  This is more complex as browsers that naturally support JavaScript can be “crippled” by corporations that disable its use.  The following graphic shows how these different elements interplay with each other.

From this I defined three classifications of Browser as follows:

Basic Browsers           OpenWare browser, Basic (old) Mobile browsers, very early versions of IE and Netscape (Full HTML coverage, limited CSS coverage, little or no JavaScript coverage)

Simple Browsers         IE, Netscape, RIM, Nokia browser (Full HTML/CSS coverage, no HTML 5/CSS 3 coverage, some JavaScript Coverage)

Rich Browsers            Chrome, Firefox, Safari, Sony Ericsson (Full HTML/CSS and HTML 5/CSS 3 coverage, Full JavaScript Coverage)

Is "one for all" even possible

I have seen a number of different approaches to the creation of templates for IBM SPSS Data Collection that aim to handle multiple languages, multiple browsers and multiple question types.  The one approach I have not seen is a single master template with supporting sub-templates and transparently handle all desktop (Mac/PC) browsers and also provide an experience for basic mobile browsers.

If you look into the Internet you can find many companies who have achieved this for some or all of their websites.

So the question is, is this possible? Does it provide any benefits? Is it an approach that all customers can take to extend the reach of their surveys?

At the heart of the issue is the plethora of browsers available today and the range of capabilities of each of those browsers.  This can be seen in wikipedia’s firstly their comparison of web browsers and secondly their comparison of mobile browsers.  If there were a clear dominiant force in either or both of these markets they the majority of website designers would build for that format.  This was the case through the 90’s with the dominance of Internet Explorer (IE).  However that dominance is effectively at an end as shown by the following infographic:

The above graphic shows the long term evolution of desktop browsers but it ends in August 2009 and quite a lot has changed since then.  Furthermore it does not cover mobile browsers.  The next three charts are from the same web service and provide a more up to date picture (for more detail and other charts go to StatCounter).

Figure 1: Desktop Browsers by Version

This chart really highlights the rapid decline in Microsoft’s dominance.  Okay there are three versions out there and the still amount to a very high percentage of market share, but it has fallen by 20% over the last few years and with issues such as the provision of choice for Europe (where Europeans are presented with a choice of browser rather than automatic installation of IE) market share can only continue to decline.

Figure 2: Desktop vs Mobile Browsers

This graphic surprised me because there is a lot of noise about mobile internet but this indicates that that noise is largely irrelevant at this time.  This probably reflects the fact that a large portion of users are concerned about data costs and that combined with the percentage of users who do not have good internet access (no smartphone) means that mobiles have a way to go before they will challenge desktops.  Further exploration at a country level shows that emerging territories such as India are showing more movement towards mobile browsing than Europe or the US.

Figure 3: Mobile Browsers

This graphic shows that there is no clear dominant factor in terms of Browser when looking at mobile devices.  Many in Europe and the US may be surprised by the fact that Opera is top but in territories such as Japan this browser has real dominance.  Opera Mini is seen as a very good browser and other non mobile products (such as the WII) use this browser.  It is not clear whether the WII would be seen in the desktop or the mobile category.

With the advent, but not wholesale adoption of, HTML 5/CSS 3 and the fact that this standard is not due to be ratified until 2022.  There are new ways to engage browsers users with more visual richness.  One of the most talked about features of HTML 5 being its ability to embed video without the need for a plug-in such as Flash or Silverlight and its consequential high profile adoption by YouTube (amongst others).  The approach by IBM/SPSS Data Collection has always been to be browser agnostic.  This means delivering solutions without JavaScript and therefore without any richness.  As much as this may have been a sensible policy 5 or 10 years ago, it now runs against the mainstream perception of the Internet and so Data Collection consumers need to add their own solution. 

A small number of customers have explored User Agents to discover details regarding the device being used and to then send the person to the relevant template.  This requires constant support as User Agents are not delivered in a standard way by providers and they only provide a relatively small amount of information.  Also the building of multiple templates significantly increases the cost of support should customers come along requiring their own branded versions.

Its seems to me, therefore that a new approach is required.  This would be a three stage approach utilising a combination of Graceful degradation and Progressive Enhancement (a short explanation).  It starts with a basic HTML solution that is a fits all solution.  It is then built upon using CSS capabilities to improve presentation and overall layout.  Finally JavaScript is used to add richness where richness can be added.  But is this solution possible?

Because I like a challenge I have set myself an objective of delivering such a solution over the next few weeks.  I am interested in your opinion.  Will I manage it? what should I be looking out for?

As usual I will keep you informed of my progress and show the end results so watch this space.