theThought's thoughts

"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)

Data Collection Populates form using custom controls (binding custom parts to form fields)

Having created the Survey, the Form and defined the custom part it is now time to create a working prototype.  This involves creating a custom part within the document and then linking the relevant data from the custom part to each of the forms.  Word does not provide a mechanism for doing this within its interface, however there is a tool available that does do this work for you even though it’s interface is relatively crude.  This tool is called the Word 2007 Content Control Toolkit and is available via the following link (Word 2007 Content Control Toolkit).  Although this is a relatively simple interface it does allow for the creation of custom parts and the binding of form fields to those parts.  It also provides all the source code for the application so it is possible to identify how the custom part was constructed and how binding is defined.

Building the Custom Part

Before using the Word 2007 Content Control Toolkit it is advisable to create an XML document containing a static version of the XML that is to be used in the document.  The reason for this is that although this tool does provide users with the ability to build XML it does not have all the full validation and UI capabilities of a true XML creation document.  My preference is to use Microsoft’s Web Developer Express 2008.  This software is available, free of charge from Microsoft (Microsoft Express Products).  Using this tool I created a static version of the XML defined in a previous post (the custom part) and saved the file to a local directory.

Binding the Custom Part to the Fields
Once an xml document has been created the toolkit can be used to load its structure into the Complaint Record document created in Word.  Once the toolkit has been installed and opened it is necessary to point it at the Word document that contains the form layout and will contain the custom part.  This is done by simply opening the File using File Open.  Once opened the toolkit examines the document for any form fields and lists them In the window on the left (as shown in the following diagram).

The second step is create a new Custom Part.  This is done by clicking on the Create a new Custom XML Part in the bottom right corner of the dialog. Once done it is possible to load the previously created XML document (this means that the elements and attributes do not have to be created manually).  This is done by clicking on the Open XML document button.  As a result of these actions your dialog should look similar to the following:

The last step is to bind the form fields listed on the left side with the XML content on the right side.  This is done by switching the left side from Edit view to Bind view.  Bind view provides a hierarchical representation of the XML loaded into the custom part clear depicting elements and attributes.  To perform a binding perform the following steps.

Click on an element or attribute from the binding view

Click and Drag the element to the relevant field on the left side

It is important that the click and the click and drag are two separate actions, if they are done as one the wrong element/attribute from the XML is assigned to the field.  When the item is dropped onto the form field the XPath of that element is updated.  Check this to make sure it is correct.  Once all the bindings have been created the dialog should look similar to the one below:

Once all the changes have been made it is possible to save the Word Document.  Once this has been done it is possible to open the file in Word.  If the XML part loaded has sample information within it then the document will show the fields populated.  In this case it should look similar to the image below: