This post started as a rant about people learning ASP.Net as their first web development platform and consequently not really knowing what is going on under the hood.  I've interviewed quite a number of programmers over the last year and it's very rare to find anyone who would survive if you suddenly took the training wheels off.  Tertiary education is focusing more on turning out graduates that have useful skill sets in the short term than building a strong understanding of computer science fundamentals and the technologies everything is layered upon.

As I was writing I realised that the most usable web forms I have written have involved setting some of the ASP.Net magic aside and getting my hands dirty with the details.  Rather than rant at you I instead decided to discuss developing an example web form and show how a deeper knowledge of the layers underneath ASP.Net can allow us to provide a better end user experience and improve performance at the same time.

This information is particularly applicable to anyone interested in the upcoming ASP.Net MVC framework in which developers are much more intimate with the way the web works.

A Simple Form

For an example scenario I've chosen a simple online order form.  Imagine a user with a mail order catalogue in front of them who wants to quickly type in the code for each product and the quantity they want to order.  There are a lot of simple ways that the usability of this form can be improved such as adding interactive feedback on whether the codes entered are correct.

It just so happens that I've had to build this sort of form on a couple of occasions now.  Here is an example mock up:

View Source

A form like this can be thrown together pretty quickly using Visual Studio.  A repeater, a couple of text boxes in the item template, a button and so on.  Unfortunately the easy doesn't go much further.

ASP.Net tries to sweep a lot of details under the rug with varying degrees of success.  The trouble is that sometimes those details are important and sometimes those details can have a big impact on the success of a project.  Joel Spolsky calls this The Law of Leaky Abstractions.  As an example I borrowed a few lines from the HTML of the MSDN NZ site:

Ah, view state, I've only included the first few lines of it too.  ASP.Net is trying to present an abstraction where you can store state between page requests but this falls apart when that state becomes a major performance problem.  It is not all that uncommon to see pages where the developer has been careless with a data grid and built up 300k of view state which gets sent to the client and back every request.

There are a lot of tricks for keeping your view state down to a manageable level but doesn't it make you wonder how we got on before view state existed?

Here is another snippet from the same page:

Most concerning is the value of the anchors ID tag, ctl00_mainContentContainer_ctl38.  This phrase is repeated 3 times for each item in the list which can add significantly to the size of the page if the list is long.  The length of the IDs can be shortened by giving the mainContentContainer control a shorter name however we should not have to sacrifice code readability for such fundamental performance issues.

This is another case where ASP.Net is trying to help by ensuring that the ID tags are unique for every control on the page.  This can cause similar performance problems to view state however it also makes it more difficult for us to use JavaScript to develop client side functionality as we do not know what the controls final ID will be when we write it.  For more information on how these IDs get generated look up naming container in your favourite Google.

Bare Bones Markup

The HTML output for the example form is presented below.  I've used HTML controls directly rather than ASP.Net server controls and extras like ID attributes have not been included unless necessary.  The form isn't very functional yet but it's already pretty close to the final markup I will be using.  It's surprising how little HTML we can get away with and still have a very powerful user interface.

I'm still figuring out what works well in the blog format and this is a big topic so I'm going to experiment with more episodic posts.  To give you a preview here are some of the topics I plan to touch on in upc0ming posts:

• Getting your data back to the server without using server controls.
• jQuery for client side interaction and feedback.
• AJAX for interactive feedback from the server.
• HTML as templates for modifying the form on the fly.

Keep an eye out for part 2 in the next few days.

Labels: ASP.Net, HTML, jQuery, Style

Bookmark this on Delicious