Devising a new paradigm for usable, maintainable Web applications

In: Articles

By Ka Wai Cheung

Published on October 20, 2004

Note:

This article assumes the reader has a working knowledge of basic object-oriented paradigms.

In the Web community, usability engineering is often discussed but rarely implemented. It’s pretty clear that software works better when it is well-designed and user-centric. It’s also evident that too many of today’s Web applications are harder to use than they should be. Experts tend to focus on why usability is important and how to improve usability on the Web. However, they rarely address what makes usability on the Web difficult to implement and maintain.

Why does usability tend to lag behind as Web applications become increasingly complex? Much of this lag can be attributed to the fact that the languages we use to create Web pages are not optimized for usability engineering. It is often the goal of the developer to simply get an application to function—but not necessarily function well—because the tools at the developer’s disposal do not promote such a thought process.

In this article, we’ll look at how traditional programming has evolved, discuss the current state of presentation-tier code, and devise a paradigm that makes developing for the Web a more intuitive and maintainable practice. Hopefully, this will lead to a greater emphasis on developing for usability and long-lasting code to avoid the constant need for major redevelopment.

Learning the lessons of object-oriented programming

Consider the evolution of business logic and data-tier Web development from procedural (or top-down) languages like ASP to object-oriented languages like C# or Java. Encapsulation, reusable objects, inheritance, interfaces and other object-oriented principles made Web development a more robust and maintainable practice. Let’s take a look at what exactly evolved in this transition.

With object-oriented programming (OOP), we can now describe business processes in more business-like terms. For instance, we can build a corporate intranet application describing each employee of the organization in terms of an employee class. Accordingly, we can access information about every employee by creating an object (an instance of the employee class) for each employee. We can then programmatically access information and routines within an object (i.e. myEmployee.PhoneNumber).

Underneath the black box of the class structure, accessing someone’s phone number most likely involves the use of a data-reading object, a database connection, and a query against the database. By using OOP standards, all of this code can be hidden from the developer. Retrieving John Doe’s phone number could look something like:

Employee myEmployee = new Employee("John Doe");
return myEmployee.PhoneNumber

The essential point here is that the concept of an employee can be modeled in a very similar way to how we perceive an employee in real life. We can ask John Doe, “What is your phone number?” and he will tell us. In code, we can query John Doe’s programmatic equivalent (his employee object) and get his phone number as well.

This is a wonderful upgrade. In procedural code, we couldn’t inherently subscribe a phone number or name or email property to some employee object. Instead, we’d have written functions to access a first name, a phone number and an email address of some employee, passing in some parameter that represents John Doe. Or, we could write one large procedure to return all of these properties in some sort of generic data structure (like an array). Ultimately, the results are the same, but the way we get there does not describe the physical model like it does with OOP.

OOP describes the data model first, whereas procedural code describes processes without much consideration in defining the data that is processed. OOP allows the developer to think about a problem from the user’s perspective (in terms of entities that interact with the user and with each other), not from some obscure and muddled process-based perspective.

The successes of OOP should be a harbinger for the type of change the Web community needs to see in presentation-tier code. If we are to make usability engineering a more implemented discipline, we need a language that more tightly couples how users interact with software and how developers develop code. Only then can usability engineering assume its rightful place in the Web development process.

Progress on the presentation layer

With the enforcement of Web standards, today’s presentation-tier code does many things well. We have seen some very encouraging progress in XHTML and CSS that allows developers to separate structure (the organization of various elements of a Web page) from presentation (the visual appearance of these elements).

XHTML/CSS standards have been widely embraced by the Web community. There are two huge advantages to Web standardization. First, the separation of structure from presentation allows XHTML to be a true XML-compliant markup language. HTML no longer has to be bent out of shape to make things “look right” on Web browsers. Second, CSS can now presume full control over how data is displayed. Effective use of new XHTML/CSS standards already has an object-oriented flair to it. We can think of tag blocks as objects (especially under strict XHTML standards where all tags need end tags) and styles as object definitions. Many sites that strictly adhere to Web standards succeed in catering content to the user in a visually appealing way. Just as important, this separation makes the code drastically easier to maintain.

Similarly, we can and should apply standardization that allows us to separate structure from behavior (how elements of a Web page interact with the user). Let’s take a look at the current state of HTML forms, and see how we can harness OO thinking and the Web standards model to create a functional heuristic that is easy to implement and maintain for the developer.

Applying object-oriented techniques to presentation code

HTML forms are a classic usability engineering headache. Forms can be long, complicated, and unintuitive. Forms that validate user data, by and large, don’t do it well. Required fields sometimes aren’t displayed as required. We don’t know the status of their form submission until they click “Submit” and see all the things they’ve done “wrong.” Date fields will tell us to fill in their field in a particular syntax when they could easily be developed to recognize other ones. The list goes on and on.

Certainly, modifying the languages themselves won’t solve all the problems, but it will get developers thinking in a way that is more tightly integrated with the way users experience the product. And this will solve many problems.

In order to build a basis for a usability-oriented code, let’s first examine the constraints of current presentation-tier languages. Building forms or other interactive elements with HTML/JavaScript leaves lots of things to be desired:

• HTML does not allow developers to describe physical objects in the way that users view them. (An <INPUT> tag could refer to an email field, a zip code, or your favorite pie).
• JavaScript is not fully object-oriented. Therefore, we can’t take full advantage of building our own constructs and interfaces. (We’ll see how powerful an interface structure can be in presentation code later on).
• HTML and JavaScript still interact in the way that non-standards-based HTML/CSS interacts. JavaScript is still usually embedded into HTML tags, referenced by event handler attributes like onSubmit and onClick.

Let’s begin implementing a new structural/behavioral/presentation code paradigm utilizing OO techniques and influences from the improved HTML/CSS model.

Building a physical representation structural model

In an ideal world, we would retain the structural capabilities of HTML but name tags in a way that describe what they physically represent. Additionally, we should have the ability to group a series of tags that represent parts of a singular physical representation together. Consider a typical HTML form containing three input boxes that represent the month, day, and year of a date:

<form>
<span class="body">Enter Month:</span>
<input type="text" name="month" size="2" class="body" />
<span class="body">Enter Day:</span>
<input type="text" name="day" size="2" class="body" />
<span class="body">Enter Year:</span>
<input type="text" name="year" size="2" class="body" />
</form>

To the user, this mush of <span> and <input> tags simply represents a singular date entity. To the developer, each input box and span represents distinctly different objects that must be manipulated individually.

Suppose we could tie the user’s mental model in more closely with the developer’s programming model. In this new markup language, the code above might look something like this:

<form>
<date name="myDate">
<_month title="Enter Month:" class="body" />
<_day title="Enter Day:" class="body" />
<_year title="Enter Year:" class="body" />
</date>
</form>

Now, each tag correlates to exactly what the user sees. Also, we have encapsulated month, day, and title fields within a single <date> object. By doing so, we don’t have to implicitly name the _month, _day, and _year fields because they are properties of the date object myDate rather than some arbitrary set of three input fields. Instead of using free text for labeling the month, day and year, the titles now become properties of the month, day and year objects. We have also left the CSS class attribute intact to keep the separation of structure from presentation.

However, there are still a few missing pieces to the puzzle. How would the CSS file know that the _month, _day, and _year fields actually represent input boxes? And, where do we implement the behavior of these fields?

Scripting behavioral code through objects and interfaces

A progressive behavioral usability language should allow us to completely separate structure from behavior, rather than embed procedure calls in the structural language. At the same time, it should be able to fully interact with both structural code and presentation code. With this recipe, let’s start by scripting the behavior of a date entity, much as the user would view it, in an object-oriented style. Let’s not worry about syntax or where this code exists. The key here is grasping what the code might look like and how it could interact with other parts of the presentation layer.

// define the date object
Public class date {

// Date properties
Private month _month;
Private day _day;
Private year _year;
}

// define the month object
Public class month inherits iHTMLinput {

Private label title;

Private onFocus() { // Do some validation, if necessary }
Private onChange() { // Do some validation, if necessary }
Private onSubmit() { // Do some validation, if necessary }

}

// Public class label inherits iHTMLspan {

// A label simply inherits the properties of an HTML span tag. }

// Repeat the same heuristic as seen in month for day and year.

In this schematic, the names of the classes are the same as the names of the tags in our new markup language. Within the date class, the three parameters are _month, _day, and _year—the same tags used within the <date> tag of our structural markup code.

The month class inherits from an HTML input interface (iHTMLinput). For those unfamiliar with this concept in OO, interfaces establish a set of functions that must then be defined by the classes that inherit them. Thus, we can predefine that the HTML input interface has onFocus(), onChange(), and onSubmit() methods (much like JavaScript event handlers). Any class that inherits iHTMLinput must then define these methods. This is where we can relegate all of our behavioral code. When the form is submitted, for example, the month object’s onSubmit() method would be executed. If we needed to pass parameters into the onSubmit() method, we could simply define a new parameter as part of the object definition and add the value within the structural markup code.

Not only does this separate all behavior code from structural code, but, if we were to include five other date objects in our structural markup, we wouldn’t have to reassign the behavioral code anywhere. They would all reference their object definition—the month class.

Also, by specifying that the month class inherits from the HTML input interface, CSS theoretically will be able to deduce that any style definitions against a month class should be handled in the same way as a regular input tag. Also, the browser would know to render the <_month> tag as an <input> tag.

The month class also stores its title within the object definition. The title is the label, which simply inherits an interface called iHTMLspan, telling both CSS and the browser to render title as text within a <span> tag.

Classes for both day and year would be implemented in much the same way.

The higher-level benefits of separated objects-based presentation languages

In redefining both the structural layer and behavioral layer of presentation code, we have the makings of a prototype that separates structural, behavioral and presentational elements but keeps each one in contact with the other. This model can be applied to navigation menus, link behavior and practically any Web element (not just forms).

With this new paradigm, we begin to eliminate the transitional barriers between how we use applications and how we develop them. Programming at the interface level no longer has to be an interpretive process. Our code base instantly becomes more readable.

An improvement in the maintainability of code is another significant benefit. By orienting ourselves away from the muddled mess of traditional HTML/JavaScript and toward an objects-based infrastructure, we can continue to add on to, modify and remove parts of our existing code base with ease. We rid ourselves of the typical ripple effects that occur when major revisions are needed to the presentation layer, keeping the focus on making things usable and not just functional.

The movement has begun

Fortunately, this movement is already beginning to take place. Microsoft’s .NET platform allows developers to create custom controls that can then be referenced in the front-end tag structure. The compiled .NET project then replaces the tags with pure HTML. Though HTML and JavaScript are still integrated in many .NET applications, developers are beginning to model the structural components in a more object-oriented way.

What is even more exciting is the new architecture of Macromedia’s Flash MX 2004 platform. Flash ActionScript 2.0 (which runs on MX 2004) is object-oriented. Any visual object in Flash (be it movie clips, UI components, or graphics) can link to ActionScript classes. These scripts can be coded within the Flash file itself or as external .as text files. Flash also can parse pure XML and has CSS capabilities. With all these features available, it’s becoming possible to build entire Flash applications by using external object scripts, XML structural code, and CSS. The Flash file itself can simply act as a container for all the objects referenced externally. We’ll see how to implement a true working model in a future article.

Ka Wai Cheung is a corporate programmer at Hubbard One in Chicago, Illinois by day and freelance designer by night. His site, Project 99, is a portfolio of his web projects and articles on web design, development, and usability.

There have been 15 comments posted about this article.

Related Topics: Programming, Usability, Web Maintenence