Nathanael Boehm: Web interface and interaction designer and developer in Canberra, Australia

Posted by Nathanael (admin) on November 4th, 2005 in general

Introduction

As I draw near to the conclusion of an e-Commerce project I’m working on coupled with a post on Molly’s blog, An Open Letter to Disney Store UK, I decided I would put together some thoughts on the issues I see commonly with web developers producing web applications with Visual Studio that are’t web standards compliant.

I hope this article will shed some light on why these issues exist, and make web developers aware that there are issues, and that web standards compliance is important. I do’t seek to address another major issue of bad user interface (UI) design that we see all too often in both web and desktop applications, however some of the suggestions I put forward I believe will assist in this area.

Web Developers vs. Web Designers

Now, my opinions here are purely based on my personal experience and not on any research that I or anyone else may or may have not conducted. It is entirely possible that my experience is completely at odds with the overall global truth. However, in my experience, there are web designers and there are web developers. Web designers are your HTML, JavaScript, CSS and graphics people while web developers are your back-end database developers, using tools such as Visual Studio with languages such as ASP.NET, C# or PHP etc.

There are some people (of which group I consider myself a member) who’s skills and experience fall roughly in both camps, however by and large people who are your HTML, CSS and graphics web designs and implementers have little experience with databases and programming and people who are your database developers and programmers have little experience with HTML, CSS and graphics.

Is this a problem? Well not necessarily. It’s pretty hard to specialise in both areas unless you are very keen. So it’s quite ok to be either a web designer or a web developer.

The problem is that web standards are really only applicable to what is rendered to screen - which is primarily the realm of the web designers (which is why we refer to it as the “front-end”). So when web application developers are developing functionality for applications to render content to the screen or page they are generally going to be straying into an area that they have about as much knowledge and experience in as a junior web designer.

What are some of the mistakes Web Developers are making?

Depends on who’s working on the project team. If you’re lucky enough to have a web designer and web developer working closely together, then both can advise each other on areas that each is expert in, thereby reducing the risk of breach of web standards compliance, and ensuring good integration of back-end with front-end.

However, in my experience, I see these two groups of people often working separately with little knowledge sharing taking place. Sometimes a web developer might even be left to his own devices and has do both the role of a web designer and developer. This should be avoided - the web developer has enough to worry about with actually writing the application, let alone having to look after the front-end as well.

Some of the mistakes I’ve come across include:

• Non-semantic HTML
• Using transitional HTML instead of strict XHTML
• Inline and non-semantic CSS
• Hacks and workarounds carried across from the back-end
• Unreliable JavaScript
• Deprecated mark-up
• Cross-browser incompatibility
• - and not really a mistake, but not utilising the full capabilities of CSS and other new technologies for front-end

With the hacks and workarounds issue (and I can say this because I am a web developer); developing a web application is typically a very chaotic process. Nothing ever goes to plan, and what might have seemed like a straightforward functional specification at first ends up as a train wreck that is artfully sculptured and massaged into an as-reliable-as-possible system.

You think that CSS can be tough going sometimes - it’s nothing compared to web application development. Constantly running into brick walls and having to find ways of demolishing them, going over them and around them. It’s not shoddy programming - it’s just a fact of life with the technology and tools we have to work with, and I’m not complaining. However unfortunately often this process can cross the boundary into the front-end, resulting in hacks and workarounds being implemented in your HTML, CSS and JavaScript.

In the back-end, it’s ok because the server takes care of processing everything, and there are processes in place to catch and handle any issues. On the front-end it’s not acceptable because once you render content on your web page, the risk of something not working as desired goes up 1,000 times. The multitude of browsers, browser configurations, screen resolutions, operating systems, bandwidth - not to mention the users themselves!

Case Study: Several years ago I was involved in a project. I was one of three web developers building a knowledge testing application. There was a requirement to communicate with the server via an iframe - I guess in a way it was a precursor to AJAX. Unfortunately, if the server took too long to respond to requests submitted through that iframe, then it caused a JavaScript error because a function was being called on the front-end before the server had returned a response (an XML blob from memory). It was’t possible to queue up the threads so that thread B did’t start till thread A had been returned. We eventually found a workaround; but this sort of thing would’t happen on the back-end because of the functionality available to back-end development.

One of my most used ASP.NET controls is the Panel control. It’s essentially a container in which you place other controls, such as Labels, other Panels etc. The fact that Panel controls render as div elements, and Label controls as span elements is largely irrelevant to a web developer. This can lead to all sorts of abuse and non-semantic HTML when a web developer uses Panels and Labels for various purposes without consideration of the HTML code that’s being rendered.

JavaScript is almost unavoidable with Visual Studio. At the very least, if you need to allow a control besides a submit button to post back the page to the server, Visual Studio will put in a JavaScript function in order to enable that post back. It’s an essential part of the client-server model, so if you want a JavaScript free web application developed in Visual Studio then put some forethought into how to avoid this situation.

Another common thing I’ve seen is attempts to mimic behaviour of desktop applications. In fact just today I had to implement a table which allowed users to select rows in a table which meant having to set onclick events bound to a JavaScript function on td elements, and setting cursor to hand. It works, but I would rather actions like that be limited to hyperlinks and form buttons. While the user experience between web and desktop applications should be as familiar as possible, they are different mediums and require different approaches and treatment.

What web developers can do

Validate your HTML. At the very least validate your HTML templates - preferably to XHTML Strict if you’re bold enough.

But just validating your templates is really not enough. You need to validate what your web application is outputting. Open up your browser, look at your site, view the source, and run it through a validator such as CSE HTML Validator.

Know your limitations. Get the assistance of an experienced web designer to assist with the design of templates and dynamic regions. Web designers have a greater responsibility to be up to date on the latest on browsers, standards, front-end technology and user statistics.

Prepare complete templates. Do’t just do a shell and then throw dynamic content into it ad hoc. Do up complete page templates, ensure they are web standards compliant and then base your dynamic regions on those templates.

For example, if you have a Browse Products page - then do up a complete Browse Products page, complete with table, thumbnails, links, action buttons and as much CSS as necessary - and then move the dynamic components into your back-end.

Do not use the WYSIWYG view in Visual Studio. Just do’t do it. It’s not designed for designing web pages. Web pages do not have to look like desktop applications.

Understand what Visual Studio outputs and ensure that ASP.NET controls are used properly for their intended purpose.

Remember that the back-end only has to run on a single server in a single environment. The front-end may be pushed to tens of thousands of computers with myriads of configurations and environmental parameters.

Conclusion

Hopefully I’ve given web designers some insight into the world of web developers, and given web developers some idea of the issues common to web applications relating to web standards compliance as well as some tips of how to ensure web standards compliance.

If you have any questions relating to anything I’ve said here, please feel free to email me, and as always comments are welcome!

user interface, web application development, web applications, web standards, Visual Studio, HTML, CSS, Csharp, template, WYSIWYG, software, development