It’s not just a web page anymore

I’m increasingly asked to build more sophisticated web interfaces which begin to approach the interactive capabilities of a thick client. Satisfying these requests is getting much more difficult. Most of my clients "just" want a web page that works like their green screen, with field-level validation and replacement of page sections as the user progresses from one task to another – but without refreshing the web page or making too many round-trips to the server. For more complex pages, the old Submit button which requests processing of an entire page is giving way to requests for auto-completion from server-side tables, multipart forms that refresh as data is changed elsewhere, dynamic page updates that notify clients of activity on the server or on the internet, and even custom form layouts where the user can re-arrange their own screens to suit their preference.

The revolution in web development now fueled by Ajax is as significant as the transition from the old IBM 3270 terminals to our green screens. The moniker "Web 2.0" has been widely adoped to categorize the new paradigm. The mechanisms that make this sort of thing possible are not simple, standard, or consistent across browsers. The popularity and hype around Ajax gives the misleading impression that this is now mainstream, and that the functionality can be rolled into development without affecting project scope in terms of time or cost. This is making it very difficult for me to recommend and provide solutions which respond to the requests while keeping projects within the same scope that people are used to in web development.

The notion that we are working on the web no longer implies simple tools and rapid development. Coding for the web is now more complex than coding thick client apps because of the need to work with a non-persistent data, and completely unknown technologies on the client PC. Choice of technologies is also very difficult because of site-specific requirements and preferences for Apache or IIS, or Windows or Linux on the client and/or server. The promise of the universal client and simple deployment has only made development and deployment much more complex and in some cases much more expensive. This is further complicated when existing applications have their UI and rules mixed in traditional procedural style, and record locks asserted for significant application blocks which include user interaction.

I’ll present some solutions that I’ve found in another post, but the real answer is that there are no solutions that won’t cost time or money to implement.