I'm hearing the phrase User Experience thrown around quite a bit these days. It's become an overloaded term that means different things to different folks, yet we all seem to agree with the premise that a positive user experience is essential.

I just got home from another Getting Started with Grails presentation. After using the framework for about six months, I still can't get over how easy it makes developing web-based Java apps.

The idea of listening to your customer is one that should never be dismissed. But surprisingly, I often see it happening by other contractors. I refuse to buy the argument that customers aren’t equipped with the ability to know what they want. Some may need assistance with technical jargon, but a web application is not always just a web application.

Perhaps you’ve worked with this guy I know. He holds the record for World’s Fastest Programmer. Nothing is new to him. He’s seen it all. In fact, he doesn’t even have time to discuss it. He has code to write! Well obviously, a great coder alone is not a competent software engineer.  Coding is just one of the many areas in which we must excel in order to complete the job. Truly useful systems must be well-designed. High-quality systems must be thoroughly tested. Easily maintainable systems must be well-documented.

Users want control. They want content, but they also want to be able to view it in the way that best meets their needs. My Yahoo! is a great example, and one that I use everyday. I can select which modules I want, drag and drop to reorder them, provide my own RSS feeds and more. I can even pick the color scheme that fits my mood.

Color is an important and often overlooked aspect of Web Programming as well, Richard. I quickly searched and found a good article for web designers on the value of choosing the right color scheme. But what if we want to ensure that each user experiences colors that fit into his/her own predefined environment? There is a way that we can do this without prompting them to pick a “skin” or “theme.”

Over the last few weeks, I’ve been playing with two of the latest web framework offerings. Of course both advertise to dramatically increase the ease of web application development (while shouting the obligatory, "AJAX!"), yet they are quite different.

Adobe Spry framework for Ajax
Although I found the Adobe Spry demo applications to be compelling, they ran a bit slow for me (yes, running locally). I also didn’t see much new here; just a combination of things that had wowed me previously. For example, the transitions between images in the Photo Gallery were a bit rougher than LightBox. The RSS Reader was well put together, although I can’t see myself using (and maintaining) something like this when so may other (integrated) options exist. The Product Table seemed a lot like the Accordian example found on the Rico web site.

I was recently sent an article from the current issue of eWeek titled Gosling Outlines the Trouble With AJAX. Don’t get me wrong, I have tremendous respect for Dr. Gosling. He’s fantastic if you ever get the chance to see him speak live. I’m also a fan of the eWeek publication. But...

I have a couple of problems with this particular interview. I think it’s fair to say Dr. Gosling has an agenda, (Sun most certainly does).

I really enjoy keeping up with Ben Galbraith's Ajaxian web site. It’s a terrific resource for keeping up with the latest news from that world, and for getting introduced to many of the toolkits that are available. The site also offers plenty of stimulating discussion to follow and even regular feature-length interviews with the important players; all Podcasts of course.

Even if you don’t have the time to keep up with Ajaxian.com's frequent entries, you can quickly scan for widgets that interest you. A great deal of these widgets can easily be added to your application without much tweaking.

I recently had the opportunity to “webify” a legacy client-server application.  Once we began listing our favorite toolkits, I was reminded how much I adore OpenSymphony’s SiteMesh.  SiteMesh has been called “the best open source component you’ve never heard of” by its creators.  Well, if you haven’t heard of SiteMesh, then that may just be an accurate description.

Separating content from presentation in web applications is an issue that has certainly been addressed over the last several years.  Industry best practices have shown that proven design patterns and clearly defined roles for developers can yield predictable, manageable software.  With the introduction of so many new technologies - from CSS through the widespread adoption of server-side scripting, to the many available templating frameworks, and now with AJAX - we have nearly completely managed to extract our data from its presentation.

Still, no matter which combination of tools I’d assembled, I always felt like there was room for improvement.  

Anyone doing enterprise-level web development is working a great deal with HTML forms.  The promise of XForms not withstanding, the small amount of actual code that produces the form is often lost in all of the formatting that surrounds it.  Producing clean, elegant code that is easy to write, read, and maintain is pretty straightforward in the POJO Java world.  Why can’t it be so for the Web UI tier?  

Let’s take server-side includes (SSIs) for example.  

The idea of making calls to a common snippet of HTML with one line was revolutionary in 1996.  But what if you want to make a change to the calling pieces of code?  Hundreds of replacements may be necessary.  Moreover, the included code is often incomplete and malformed.  Tools may not handle snippets, particularly those that are not well-formed.

Now let’s assume you have a standard header with a page banner, and a standard footer with some copyright information.  It’s very common to open an HTML table in the header and close it in the footer.  Then you might place all of the “meat” in the main pages, using <tr> and <td> tags.  You might complicate things further with a left-hand navigation bar in yet another include file.  Tying all of these things together with say, <jsp:include> is extremely brittle.  This is commonly referred to as the “open table” problem.

Let’s keep going.  What if you have some pages that require unique JavaScript in head?  You might break your standard header into hearder1.jsp and header2.jsp in anticipation of this.  What about calling a custom JavaScript function with a <body> onLoad event?  How will you provide that if your <body> tag is contained in an include file?  Passing it in as a parameter?  You’re no doubt beginning to get the idea.  

SSIs are fragile, strongly coupled, and far too complex.

SiteMesh solves these types of problems by allowing for 100% complete, valid HTML files across the application; not merely the “content” portions.

SiteMesh is an open source J2EE page layout and decorator engine.  Because it is implemented as a Servlet request filter, installation is trivial to anyone familiar with J2EE web applications – simply copy the SiteMesh jar file into WEB-INF/lib and map the filter in web.xml.