Browser support

This is an issue which crops up in one form or another on almost every project I have ever worked on. Its normally the project manager who will approach me and say in a sometimes off-handed way something like "I assume we will support this list of browsers (which someone gave me back in 2001)."

My usual answer is "No. We will support this standard support matrix."

I then proceed to hand the project manager something which at the time of writing includes the following:

• Internet Explorer 6+
• Firefox 1.5+ (all platforms)
• Safari 2+ (all platforms)
• Opera 9+ (all platforms)

This is all well and good, but the real purpose of this kind of browser support matrix is actually to fulfill some sort of contractual requirements with a client and to appease the project manager.

I also consider this matrix to be a testing guide for the testers of the website. Most testers are not completely familiar with ID concepts, and they need some help. I have seen testers using up to 20 different browsers and raising bugs if they are not all perfect. This is obviously very costly on the project - testing takes a long time and fixing the bugs is extremely tedious and often not really possible.

To get around this issues (and to help with dealing with the client who still happens to be using Ie5 on Windows 98) I normally talk in terms of graded support. At the time of writing, I use 2 level of support:

Level 1
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.

Level 2
All features of the website are functional if only in a fall back manner. All content is available. The web pages will largely match provided designs. The web pages may look slightly different between browsers at this level and those at other levels.

This provides a sensible testing structure as well as fulfilling all other requirements. If an awkward browser (such as IE 5.5) absolutely must be supported, we have the option of only offering level 2 support - the key here is that all content will be available.

In reality, browser support only matters for the visual and enhanced behavior of the website. If the website is built using the principles of progressive enhancement, then all user agents, all browsers should be able to access the website in some form or another. It is the content of the website which is most important, and using well structured, semantic HTML should ensure that this content is available to all.

The message here is that agreeing a sensible browser support matrix is very important in both a business sense and for testing. It is also imperative to adhere to the agreed support levels, but the principles of progressive enhancement, particularly starting with well formed, semantic HTML will ensure the widest possible support even if that is with a degraded experience.

Its our job

I cant agree with absolutely everything in this article, but it certainly does make some very good points - accessibility should not be an inconvenience!

Progressive enhancement

In the world of interface development today there is one technique to which I fully subscribe without hesitation or regret - progressive enhancement. It is for me the guiding principle behind almost all of the work I do.

Progressive enhancement can mean a number of things but in a nutshell, it involves taking a base line for a web page and layering on enhancements which are not required in order to use the web page or to understand the content of the web page. If the browser being used can understand these additional layers, then they will be applied and will enhance the way the web page operates or looks.

The base line is the HTML code of the web page. The HTML code defines the content of the web page. The HTML of course should be semantic and where possible valid. In order to define the content of the page, the HTML code should be well structured, for example having a sensible header nesting order.

Given semantic and well written HTML, the content of a web page should be accessible to any user agent. The job of progressive enhancement is to layer on some additional "features".

There are two main forms of progressive enhancement used presently. It is in fact possible to argue that there are 3 or possibly 4 forms (and maybe even more), but the two main forms are CSS and JavaScript (I would perhaps also say that images are another main type of progressive enhancement - with well written alt attributes on image tags, the images are not necessary to understand the page).

So what do these forms of progressive enhancement do and how do they work?

CSS
The way the web page looks is defined by the CSS code used to style the page. The stylesheet uses a series of selectors to select elements defined in the HTML code and apply one or more of a wide variety of styling effects. These include applying borders, text colours, background colours and images, sizes and many many others.

JavaScript
Any behaviours not handled by the browser by default can be added through the use of JavaScript. JavaScript is a programming language with a C type syntax which is the language of choice for the web. The JavaScript code can perform a massively wide variety of different operations. These range from simple form validation scripts to whole applications such as Google Maps.

Progressive enhancement gives us a very powerful structure to building web pages. Using this technique, we create by default a separation between code for content, visual style and behavior. We are compelled to consider the implication of our enhancements and to make visual and behavioural aspects of the web page just that, enhancements and not requirements.

What will the page be like to use if the user agent does not support CSS? How will the core functions of the page operate without JavaScript enabled in the browser? By considering these questions, we are forced to write better HTML. In fact we are forced also to write better CSS and JavaScript. Everything needs to be considered carefully to ensure the separation of code remains and that the web page will be usable without the enhancements being available.

Not every web page can be progressively enhanced. In that instance, the appropriate alternative is a fallback version. Try browsing to Google Maps with JavaScript disabled in your browser and you will be taken to a page which will work without JavaScript. Not all fallbacks are this drastic, but a fallback allows the principle of progressive enhancement to be applied even in those few cases when the effort involved in using this approach is prohibitive.

The vast and overwhelming majority of the time, progressive enhancement makes writing a web page easier. The code will be better, cleaner and more maintainable. The web page more accessible and inclusive. The interface developer can be happy with a job well done!

What is Interface Development

This is a very very good question. I often get asked what Interface Development really is (other than the obvious answer). Many people will know it as front end development. But its easier to answer the question in the form of a skill set.

I consider the core skills for a Web Interface Developer (or ID) to be:
HTML
CSS
JavaScript
User Agents
Accessibility

So what do these terms mean?

HTML
Fairly self-explanatory really. But an ID should know about HTML and XHTML in all its different forms. That is every widely supported doctype around.

CSS
Also self-explanatory. Everything up to CSS 2.1 is useful at this time.

JavaScript
Another one of those obvious ones. This is not to say that all IDs should be expert in JavaScript, but all IDs should have a good working knowledge

User Agents
This is less obvious. But I think an ID should know all about the most common browsers in use in the market today. How we define common is perhaps not a subject for this post, but once you have decided what is common, an ID should be able to write code to be compatible for all of them and should be able to understand their foibles and quirks

Accessibility
Well here is something that is a bit more contentious! IDs should ultimately be versed in best practice. Accessibility is a large subject and deserves many posts all of its own, but suffice to say that knowing what the WCAG say is not enough. Understanding best practice and why some approaches are good and others bad is far more useful.


So this is what an ID is. Its what we preach and what we practice and these are the topics that this blog will discuss. Enjoy.