Browser User Interfaces: A State of the Union

Article ID: 63097

Posted December 1st, 2008

Check out these technologies that can improve the user experience

By:

HTML is now two-decades old, and in that time, things have changed quite a bit. HTML is still at the center of web page development, but now a host of other available technologies improve the user experience. Here, we look at some of those technologies and how they affect the browser user interface (BUI). But first, let's consider the evolution of browser user interfaces.

In the Beginning

When it debuted in 1990, HTML contained a mere 22 elements. A few years later, greater formatting capabilities and support for images and external format specifications (CSS) were added to HTML. In the mid-1990s, the ability to build HTML dynamically, on the web server, was enabled with the Common Gateway Interface (CGI). CGI allowed developers using popular languages such as RPG and Perl to construct business applications for the web.

Netscape introduced JavaScript in 1995, and Microsoft hastily made it available in Internet Explorer in 1996. JavaScript source is embedded within HTML and executes from the browser. JavaScript's initial use was to manipulate HTML within the browser to provide such features as animation, input validation, and dynamically constructed pop-up windows.

In 1997, three important server-side web platforms emerged: PHP, Microsoft Active Server Pages (ASP), and the Java Servlet API. PHP, ASP, and server-side Java provided web development and deployment capabilities that were substantial improvements over CGI. Many other web development platforms are available, but these three are the most dominant.

XML made its appearance in the late 1990s. XML and HTML are similar in that both are tag-based languages. But whereas HTML describes how to display data in a browser, XML describes the content of the data it contains. XML quickly became the ubiquitous data exchange format of the Internet. In early 2000, the XML-supporting technologies of Extensible Stylesheet Language (XSL) and XSL Transformations (XSLT) surfaced. XSLT converts XML into HTML (or other XML). In fact, it is a common service-oriented architecture (SOA) strategy in which business modules are developed to return entities as XML. Then, any client prepared to deal with XML, including XSLT, can consume that XML.

We can't talk about the web without mentioning web services, which became all the rage around 2004. Web services were not designed with BUIs in mind, but instead to provide application-to-application interaction over a network. However, a relatively unexpected side effect of web services was their use by interactive browser-based web applications. But note that as a direct response to the complexity of web services, Representational State Transfer (REST) is quickly gaining acceptance as a simple alternative to web services (more about REST in a moment).

The web was arguably transformed in 2005 when the use of Asynchronous JavaScript and XML (Ajax) became widespread. The features Ajax provides ramped up user expectations with the advent of sophisticated pages like Google Maps. Besides offering such features as auto-completion (see the From Airport input field in Figure 1) and dynamic validation, Ajax developers also began to create mashups—web applications that use other web applications and web services to provide application hybrids. The Kayak website in Figure 1 is fine example of a mashup. It uses web services and APIs from a variety of sources to seamlessly provide aggregate travel services.

Today the browser user interface is said to be at Web 2.0. Tim O'Reilly, founder of O'Reilly Media and a leader in the free-software and open-source movement, coined the phrase Web 2.0 saying, "Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as platform, and an attempt to understand the rules for success on that new platform." Now let's dive into the technologies you need to make your next web application take advantage of Web 2.0.

Putting the X in HTML

Web browsers are very lenient with HTML syntax. Like XML, HTML is a tag-based language. But unlike XML, HTML must follow the rules of XML—specifically, XML tags must have a matching close tag, and tags must begin and end in the same parent element. It's typical, for example, for HTML to have tables and forms with no closing tags. But browsers are very forgiving, and they guess where tags ought to be closed. The problem is that this tag speculation is different between browser implementations, resulting in inconsistent page rendering.

The solution is to force HTML to follow the rules of XML by using XHTML, which became a World Wide Web Consortium (W3C) recommendation in 2000. Because it's an XML language, XHTML must conform to XML standards as well as follow a prescribed set of HTML coding rules:

XML and XHTML declaration statements are required at the top of every XHTML page.
Head and body tags are mandatory.
Every tag must be closed.
Empty tags get a terminating slash.
All tags must be lower case.
Attribute quotes are mandatory.
You may not have forms inside forms.

For a simple example, let's see how the HTML in Figure 2 (which does render in a browser despite its sloppy syntax) is converted to XHTML. The first step is to add the two standard XHTML declarations to the top of the HTML (see lines 1–3 in Figure 3). Next, use one of the many XHTML tools available to assist in the conversion of the HTML. The three tools I want to mention are HTML Tidy, TagSoup, and IBM's WDSc 7.0. That's right—System i shops already have an XHTML utility available with WDSc.

You can invoke WDSc's XHTML tool from the HTML editor by right-clicking anywhere in the editor and selecting "Clean up document." When you run WDSc's XHTML utility over the HTML in Figure 2 (after manually adding the XML and XHTML declarations) and take the default options, the tool automatically inserts required attributes and missing tags, quotes attribute values, formats the source, and lists the remaining issues in the Problems view. To remove those issues, you will still have to manually code a few other changes, such as wrapping the input tags within a div tag and moving the paragraph and list block out of the form. Figure 3 shows the resulting XHTML.

Take a look at the XML declaration and the document type declarations at the top of the XHTML in Figure 3. The first line tells editors and browsers that the content is XML. The document type statement in the second and third lines provides the specification of XML syntax required by the document— in this case, xhtml1-transitional.dtd. The xhtml1-transitional.dtd file is a document type definition (DTD) that is basically a schema for the XHTML XML language. In other words, DTDs are essentially the DDS for XML.

There are hundreds of industry-standard DTDs, and three of them are specifically for XHMTL: Strict, Frameset, and Transitional. Most shops start with Transitional and then move to Strict after working with XHTML for a while. An XML file is considered well formed when it conforms to the standard XML syntax specifications and valid when it conforms to the specified DTD.

Why go to all this trouble when browsers are so lenient with HTML? Perhaps the most straightforward reason to use XHTML is that it ensures greater cross-browser compatibility. But ultimately, the biggest advantage is preparation for the latest and future technologies. XHTML is more easily generated and parsed by languages and XML utilities, including JavaScript and XSLT. And XHTML is often used as the XML language—even though the XHTML may not be intended for direct rendering by a browser. That's because XHTML cleanly defines display data and input forms so devices such as PDAs and cell phones can convert the XML to an optimal rendering format. In fact, because XHTML is XML, it can be in the payload response data of SOAP-based web services. REST, the lightweight alternative to web services, can return any data format, but XML is one of REST's most common payload formats.

Adding Style to Your Page

Legacy HTML pages were written completely with rudimentary HTML without the benefit of supporting technologies such as Cascading Style Sheets (CSS), XML, and JavaScript. Pages were stylized with tags for bold (<b>), italics (<i>), font (<font>), and nested tables. But putting look-and-feel code in your HTML creates two problems. First, redesigning the look and feel of your website becomes so difficult that it probably won't ever be done. Second, the HTML ends up with so much look-and-feel code that the true content is obfuscated, making maintenance unwieldy. A fundamental user-interface design principle is to separate presentation from content. HTML should contain content, and CSS should contain as much of the presentation as possible.

You can embed CSS specifications within HTML, but it is more appropriate to place the specs in external files and reference them from the HTML. CSS is referenced in HTML with a link tag:

<link rel="stylesheet" href="acmeords.css" 
      type="text/css" />

CSS contains curly braced code blocks with names (called selectors) that match an HTML tag, ID, or class name. For example, the CSS in Figure 4 is used by the HTML in Figure 5 to provide external styling for the page.

A huge benefit of external CSS is that developers can combine the style markup for an entire application and put that markup into several files—thus ensuring a consistent look and feel as well as drastically reducing page size. The smaller page size makes the HTML much easier to develop and maintain and reduces download times. For example, when ESPN switched to CSS, the company saved about two terabytes of download time a day. Another benefit of CSS is that you can identify CSS styles to use for alternative devices such as printers and PDAs. Furthermore, the CSS style of page authoring lets users set their own preferences for fonts and colors. That way, you aren't inadvertently cutting color-blind 85-year-olds out of your target audience.

Accessibility

And speaking of visual impairment, one big, often overlooked consideration when designing a corporate BUI is accessibility. Consider that some users may have some degree of vision and/or hearing impairment or be unable to use a keyboard and mouse. Also, even if your target audience consists of thirtysomethings, consider that someone with 20/20 vision may be attempting to listen to your page during his or her daily commute.

To spot accessibility issues, you can hire a person with a disability to test your site. It's also worthwhile to actually watch a blind person navigate through your web application. Alternatively, you can use the completely text-based Lynx browser to test your app. Because Lynx will not render images, you should see text descriptions of all graphical elements of a page that would be read out load-by-screen readers for the visually impaired. You can also turn off the keyboard and mouse and navigate solely with voice recognition. You might have users from various age groups test your site as well. And be sure to take advantage of the web accessibility evaluation tools listed at W3C's Web Accessibility site (see the links in Find Out More, below). Making your web pages accessible is not overly difficult. Here are some simple standards you can follow:

Specify label tags for all form input fields.
Use standard field names (as identified by ECML's RFC 3106 at faqs.org/rfcs/rfc3106.html) so auto-complete can fill in commonly occurring fields such as addresses, company names, phone numbers, and email addresses.
Add tab indexes to forms to simplify keyboard navigation.
Introduce skip navigation (place "invisible" links at the top of the page to jump straight to the main content) and add internal headings with judicious use of the h1–h9 headers. Assistive software enables both visually and physically impaired readers to jump through headlines.
In links and headlines, put the most descriptive words first in phrases. Screen readers allow users to jump from link to link without listening to the entire link text.
Use the table tag's summary attribute to provide descriptions. Visually impaired users will be unable to grasp the context of a table at a glance.
Wrap abbr and acronym tags around all abbreviations and acronyms so screen readers know when to pronounce words, or simply spell out the acronym or abbreviation.
Convert images that display text (e.g., buttons, corporate logos) to text. Then use CSS to specify the size, color, font, and optionally a background image. Screen readers can then pronounce the logos and buttons.
Use CSS to the furthest extent possible. CSS allows users to set personal preferences such as font size and colors that assist visual impairments.

Be sure to consider how search engine robots interpret your site as well. Keep in mind that robots will follow links and forms (with GET identified as the HTTP method) with impunity. Understand that HTML form tags have an attribute called METHOD that lets you specify that the form data is to be passed as an HTTP GET or POST. Use HTTP GET only for requests that have no side effects. That is, the request should not cause the server to add, update, or delete an item. It's all too easy to forget to specify forms with side effects to use the GET method. The problem is that a web robot can wreak havoc on your site if it starts chasing down destructive GET requests.

Web 2.0 and Ajax

JavaScript has been used in web development since the mid-1990s. But until Ajax invigorated interest in this powerful, browser-based, client-side language, JavaScript was coded to do basic tasks such as form validation and maybe the dynamic construction of menus. Ajax sounds grandiose, but technically it's nothing more than a simple API, called XMLHttpRequest, that allows a JavaScript function to make a request to the server. This simple API, however, lets developers build web pages that behave the same as desktop applications. Nearly everyone has heard of, and probably used, the heavily hyped Ajax application Google Maps. But I want to point out one of Google's latest tool that was built with the benefit of Ajax—Google Docs.

Google Docs uses Ajax so that it can look and behave much like Microsoft Word, complete with spell check and formatting. Furthermore, Google Docs uses Ajax so that multiple users can work on the same document at the same time. Figure 6 shows a document in Firefox, and Figure 7 displays that same document viewed in Internet Explorer. What's amazing is that the IE version of the document was dynamically updated with text that was typed in Firefox. I recently used Google Docs, with several other remote developers, to refine a proposal as we collaboratively worked on the same document. My point is, Ajax lets you add amazing and creative features to your web application and provide what have become standard Ajax use cases.

A common Ajax use case for business is to validate input data on the fly on a field-by-field basis, without requiring the user to pass the complete page to the server and be presented with a potentially large list of validation errors. Because Ajax can call any web application or web service, developers can take advantage of other web applications and web services to provide data such as weather information and driving directions. Although Ajax gives developers lots and lots of cool capabilities, it all boils down to a simple JavaScript call to a web application or web service.

But there's an ugly problem in JavaScript development: the extreme complexity of managing browser incompatibility issues. The solution? Use one of the many JavaScript and Ajax libraries. The most popular libraries are Prototype, Dojo Toolkit, Yahoo! UI Library (YUI), jQuery, and Google Web Toolkit (GWT).

Prototype—a fairly small, lightweight framework—is currently the most heavily used of these libraries. Essentially, Prototype extends the JavaScript language with some core Ajax utilities and features found in languages such as Ruby, Groovy, and Python. Some of the other JavaScript libraries use Prototype internally. Prototype also has a partner library, called Script.aculo.us, that provides fancy UI visual effects. Prototype is a good choice if you intend to do either some basic Ajax or some advanced JavaScript and want to use Prototype's language extensions.

The lightweight library jQuery is comparable to a combination of Prototype and Script.aculo.us. However, jQuery is easier to learn and use than Prototype and Script.aculo.us. Dojo Toolkit is a modular, open-source library that provides a comprehensive suite of JavaScript and Ajax tools. Dojo's Dijit library, for example, is useful when you're doing web development with languages (such as RPG and Cobol) that lack web tooling. The Dijit library includes JavaScript-based widgets comparable to those in sophisticated server-side technologies such as Grails, Ruby on Rails, and Java Server Faces. Dojo's Java-like modular approach lets you use only those components that your application requires. Recently, the Dojo Foundation acquired some strong corporate sponsorship from large companies like IBM.

Like the Dojo Toolkit, YUI is an extensive and well-regarded JavaScript library. It contains libraries that handle Document Object Model (DOM) extensions, event interactions, animations, a host of prebuilt widgets, and more.

JavaScript development environments are not as available or fully featured as those for most other modern languages. Editors are available for WDSc and Eclipse but, as yet, the debuggers are weak. For that reason, many JavaScript developers tend to test and debug from Firefox—taking advantage of the strong tooling available for Firefox with plug-ins such as Firebug and Web Developer—and then test in Internet Explorer after everything is working in Firefox.

Google Web Toolkit gets around the thorny problem of JavaScript testing and debugging by implementing the JavaScript code in Java. You code and test your Ajax routines in Java, but GWT generates the required JavaScript code at runtime. GWT is a good choice for shops with plenty of Java expertise.

One last point I want to make about Ajax: Don't use it just so you can paste a label on your app saying, "Now with Ajax!" Use Ajax to enhance the user experience, improve responsiveness, and decrease download times.

Web Services and REST

Which server-side process is your Ajax requesting a response from? It could be a simple service that returns a text string or a snippet of HTML. Or maybe that process returns information as XML, comma delimited data, or JavaScript Object Notation (JSON, which I cover in a moment). Or it could use today's hottest SOA strategy where business processes can be invoked across the network using SOAP-based web services. Because of the availability of existing web services, web developers have been taking advantage of those web services with Ajax requests (see "Simplifying Web Apps with Ajax, RPG, and XSL" in Find Out More). SOAP-based web services always return payload data in XML. That XML can be either manually parsed using JavaScript's DOM API or converted into HTML using XSLT. Not a bad strategy, especially if the web service is already available. But dealing with web services quickly gets complex. Fortunately, there's a far simpler approach—Representational State Transfer.

Web services use a complex protocol called SOAP to send and receive requests, but REST uses good old reliable HTTP. Web services return payload information as XML that is itself inside a more complex XML called the SOAP envelop; however, REST can return any data type, including XML, text, images, and PDFs. (Note that SOAP-based web services actually can contain any type format, but it has to be encoded as base64 and placed in XML.) And although web services require a Web Service Description Language (WSDL), REST APIs are, for the most part, self-defining. Let me explain.

Creating a REST-based web service is like forming a simple sentence. You need only a verb and a noun. In REST, nouns are resources pointed to by URLs. An example of a resource might be an order or a customer. The verbs are the HTTP methods to perform on a resource. The standard HTTP verbs are GET, PUT, POST, and DELETE. The following URL would be processed differently based on whether the HTTP method was GET, PUT, POST, or DELETE:

http://widgets.com/order/123

GET responds with information about order number 123. PUT and POST create or update order number 123 (with values passed as standard HTTP request parameters), and DELETE cancels order number 123.

Implementing REST APIs, especially GET requests, can be trivial. For that reason, REST has been heavily adopted for use in web applications. In practice, REST APIs return four types of payload data: text, HTML, XML, and JSON. The text and HTML response is typically put directly into the HTML of the existing page. The XML is either parsed with DOM or converted to HTML with XSLT, but DOM and XSLTs can become complex. An elegantly simple alternative is JSON.

JSON is a simple mechanism for retrieving complex objects from the server. A JSON response is essentially a string that contains name/value pairs. But what is interesting is that a JSON string is really a mini-program. Those name/value pairs are JavaScript syntax for defining objects. Consider the following JSON string:

{'no': 123, 'customer':'Big Lots', 
  'lineItems': [ 
   {'line':1, 'item': 'ABC', 'quantity':2}, 
   {'line':2, 'item': 'XYZ', 'quantity':1}
  ]
}

When the above string is returned as the result of an Ajax request, it can be parsed with one line:

var order = eval('('+xhr.responseText+')')

The order variable is then a complex JavaScript object containing information about a specific order. The simple HTML in Figure 8 illustrates how information from a hard-coded JSON string (which would normally come from an Ajax request) is turned into dynamic HTML. Figure 9 shows the resulting page.

External forces often determine the selection of REST or SOAP-based web services. Business partners may require you do business with them via SOAP-based web services. Or your industry may have standardized WSDL documents that simplify the development and consumption of SOAP-based web services. But, without those external forces, if you want – simple, fast, and easy-to-write and maintain web services, use REST—especially if your intended audience uses BUIs.

The Life Cycle of a Web Request

It is important to understand the difference between the behavior of a web application and that of a traditional midrange or PC-based application. When a user logs in to a green-screen or PC-based desktop application, that application maintains application context for that user. The app remembers things like items added to a queue or subfile that the user may or may not later confirm to be placed into an order. But with a BUI application, the server by default completely forgets about a user after processing a request. That's because the web's HTTP is a stateless protocol. HTTP is not like FTP or Telnet where, after you log on, user context is retained between requests. With HTTP, each browser request starts a new job on the server and, once the server delivers a response back to the browser, the job is terminated. To maintain application context for a user, web applications must do some extra work.

Typically, web applications use HTTP sessions to retain user context. An HTTP session is simply an indexed array whose entries contain yet another indexed array. The index to the first array is a unique key that distinctly identifies one user. The web server keeps the HTTP session in memory at all times. Each user's session key is passed back and forth in the HTTP requests and response packets sent to and from a browser via an HTTP cookie or encoded as a request parameter. When a user request comes into the server, the session key retrieves the user-specific second-level array. Web developers can store application objects in the user's session array using a key that represents the object; typically, coders use a string that contains the name of the object (such as "order" or "cust").

Most web application languages and technologies such as PHP, server-side Java, and Microsoft .Net provide standard mechanisms (e.g., HTTP session) for maintaining state. Yet those mechanisms still fail in a number of areas, such as the proper handling of users clicking the browser Back button, opening multiple browser sessions to the same application, and managing bookmarking. There certainly are workarounds for these issues, but it is important to look for potential side effects of using the stateless protocol of the web.

Enriching Web Applications

Some amazingly creative and unique applications are rapidly becoming available for the web. Some of these sites push the web to its extreme by using advanced graphics and interactive media. These upscale apps are referred to as Rich Internet Applications (RIA). If you want your application to push the Internet envelope, you can consider using some of the frameworks and development environments that provide RIA, such as Adobe Flex, Microsoft Silverlight, Mozilla XML User Interface Language (XUL), and Sun's JavaFX. But if you want to provide applications that make it easy for your users, customers, and clients to do business with your company, follow the standard practices for Web 2.0.

Don Denoncourt is a System iNEWS technical editor and a trainer, mentor, and consultant for Java, Ruby, and Grail.