Importance of correct goals

Jan 25, 2004 by Aleksandar Vacić 3 minute read

I have recently been asked to review particular ASP.NET application, written using Visual Studio.NET 2003 (what else…). Each page is one huge form with dozens of various elements - drop-down lists, textboxes and checkboxes. And their labels.

When you build the page in VS’s HTML Designer, default is that all controls are absolutely positioned. When you place a control - whether that is label or form field - it gets positioned.

When I opened the source code for first page, I encountered 138 levels of z-index. I looked sadly at multitude of font tags, right next to style attributes. I was greeted with the web of HTML code like this:

    <span id="Label5" style="Z-INDEX: 108; LEFT: 3px; POSITION: absolute; TOP:
    
    113px"><font face="Microsoft Sans Serif" size="2">Label</font></span>

This is how terrible - for web purpose - one of Microsoft’s flagship product is, and it will be for unknown time in the future. It is basically the absolute evil of Front Page-like HTML output combined with very good (most likely excellent) server-side programming.

Now, where does project goals fit into this?

Microsoft’s project goals were obviously very clear: build mostly usable product that will showcase the strong points of their new framework. And they did - dealing with XML, databases and other various server-side stuff is very easy and almost without significant bugs. They left web part for future version. OK. when you know the rules, you can’t feel cheated (although I still do, since that kind of output is simply ridiculous in year 2003).

However, for this particular web project, goal was simple: build a web app which was supposed to work in IE/Win. IE/Win holds overwhelming majority of users and it seemed like a good choice. Right until the moment when app was offered to the client that uses Mac. Then project goals suddenly seems very bad.

Signing

Address

Back

Address

This example is mock-up of the problematic code. Problems:

When you use any other font-size but IE’s default (medium) labels and fields overlap.
In various browsers, form fields have slightly different sizes so they sometime overlap.
On various platforms, things almost always overlap, especially on Mac OSX Alpha interface.

As you can imagine, a client that uses Mac would not buy something like that. I was asked to propose an affordable solution. On another project done with ASP.NET, where I was in charge of HTML output, I went for XHTML compliance. The only solution was to:

ignore VS.NET HTML designer and code by hand in text editor
use VS only to work on server-side files
never, ever open .aspx files in VS, since it will deliberately rewrite your code, even when all options related to that are off

In this case, that is not acceptable, since it would cost like half the original project. Rewriting the pages to use tables would also take a lot of time (almost similar to the previous one). Also, there is matter of training and learning the stuff to hand-code stuff. Or to buy Dreamweaver. But nothing simple and cheap.

The only solution I could come up to get somewhat acceptable layout was to fix the width and height of field elements, and to fix the text-size (although that is not entirely feasible). Accessibility and usability..? Oh, well…next time. (standing in the corner, ashamed)

I wonder if something else could be done…