Codenotes for Web-Based Ui

by Gregory Brill (Editor)

Overview

CodeNotes provides the most succinct, accurate, and speedy way for a developer to ramp up on a new technology or language. Unlike other programming books, CodeNotes drills down to the core aspects of a technology, focusing on the key elements needed in order to understand it quickly and implement it immediately. It is a unique resource for developers, filling the gap between comprehensive manuals and pocket references.

CodeNotes for Web-Based UI shows how to build sophisticated, high-performance UIs for web-based applications using technologies such as JavaScript, DHTML, and CSS as well as XML and XSLT. It also details how to leverage technology and solve common web-based presentation and manipulation problems. Web designers and programmers will both develop a better understanding of common web-based design challenges, and discover some common approaches to solving these problems.

This edition of CodeNotes includes:
-A global overview of a technology and explanation of what problems it can be used to solve
-Real-world examples
-"How and Why" and "Design Notes" sections that provide hints, tricks, workarounds, and tips on what should be taken advantage of or avoided
-Instructions and classroom-style tutorials throughout from expert trainers and software developers

Visit www.codenotes.com for updates, source code templates, access to message boards, and discussion of specific problems with CodeNotes authors and other developers.

Every CodeNotes title is written and reviewed by a team of commercial software developers and technology experts. See "About the Authors" at the beginning of the book for more information.

Product Details

ISBN-13:	9780679647416
Publisher:	Random House Publishing Group
Publication date:	01/23/2002
Series:	Codenotes Series
Sold by:	Random House
Format:	eBook
Pages:	256
File size:	2 MB

About the Author

Gregory Brill is the series editor of CodeNotes and the founder and president of Infusion Development Corporation, a technology training and consulting firm that specializes in architecting securities trading and analytic systems for several of the world’s largest investment banks. He has written for C++ Users Journal, and is the author of Applying COM+. He lives in New York.

Read an Excerpt

Chapter 1: Introduction
Orientation: The Purpose of this CodeNote

A chasm exists between software developers and website designers. This is unfortunate, because the skill sets of these two groups overlap in many ways: designers may need to understand programming to add interactivity to their sites, and developers need to understand how browsers and HTML operate to leverage the Web in their applications. This CodeNote is intended to create a bridge between these two skill sets; specifically, it provides a common methodology of user interface (UI) design for creating effective websites (or web-based UIs for applications). Chapter 3 distills the many contemporary theories of web design into some rules of thumb that can be employed to create good-looking and highly functional web design. The remaining chapters give the reader (software developer or website designer) a working understanding of the primary web technologies and languages; they include tutorials on the languages and technologies required to add a dynamic dimension and interactivity to web pages.

Web UI Design Theory

While one may be familiar with the technologies and development languages of web design, to use them effectively one needs to understand the rules of design by which an effective and aesthetically pleasing web UI is put together. We say “rules of design” because, contrary to the beliefs of many developers, making a good UI is not a purely creative act. By virtue of understanding certain rules of color, layout, and font (outlined in Chapter 3), one can actually take a somewhat algorithmic approach to web design.

The choice of colors is, for example, not just a matter of opinion: different colors at different saturations, graduations, and relationships to one another on the color wheel (see Chapter 3) create different feels. There are rules for what colors are complementary to one another and in what ratio they should be used together. Similarly, there are definitively good and bad placements for navigation and some absolute do’s and don’ts in terms of how data, navigation, and images are laid out.

After covering basic design theory, these CodeNotes will introduce the technologies of web development. The “Summary” and “Design Notes” sections of these chapters will relate the technologies being introduced to the UI chapter (Chapter 3); these will provide a UI context to which the technologies being introduced may be specifically applied.

The Web UI Technologies

While there may seem to be a myriad of technologies associated with client-side web UI, there are, in actuality, only a few we need to be concerned with. In this book we will explore DHTML/CSS, JavaScript, some advanced HTML (the reader is advised to have a basic understanding of HTML prior to reading this CodeNote), XML, and XSLT. Often these technologies work together, but it can be difficult to understand where one leaves off and another picks up, or where different technologies might be used to accomplish the same thing. To make matters more challenging, major browsers, while supporting the same technologies, may support them in slightly different ways with differing levels of compatibility. Even different versions of the same browser may render things differently.

While additional effort is required to make certain that your UI functions similarly in Internet Explorer, Netscape, and other browsers (many differences will be addressed in the appendix to this book), it is not an insurmountable problem. Fortunately, at the time of this writing, the industry has largely converged on a few standard web-UI technologies that major web browsers implement. They are:

-HTML. The HyperText Markup Language is the foundation technology of web UI. At its most basic level, HTML consists of an established (presently version 4.01, www.w3c.org) set of tags and attributes defining how a browser should display a document. The data itself takes the form of the text held between a given pair of formatting tags. HTML is the basis for all web UI, but has two significant drawbacks: (1) it mixes presentation and formatting information with data, making the two very tedious to separate when required, and (2) HTML, by itself, is an entirely fixed format by the time it arrives at a browser; it displays like the static page of a printed book. A displayed HTML page does not have any dynamic or changeable qualities that graphically react to the user’s interaction with the page.

-DHTML. You can think of Dynamic HTML as an enhancement to your browser that enables dynamic web behavior after your page has loaded (for example, changing color when the user moves a mouse over some part of the page). As we will see in Chapter 5, DHTML by itself is not capable of making a web page interactive; rather, it requires two additional elements with which it must work in concert. The first DHTML requirement is that the host browser must support a Document Object Model (DOM), which is a programmatically accessible (and changeable) representation of a web page. A browser that supports DHTML must necessarily support a DOM (though the DOMs may be slightly different with different browsers; see the appendix for details). The second DHTML requirement is that a scripting language (typically JavaScript) be present to respond to events (perhaps the user mouses-over DHTML-identified regions of HTML) and then manipulate the page in some way to affect these regions.

-Cascading Style Sheets (CSS). CSS is considered part of DHTML, but you can think of it as having a life of its own as well. CSS is predominately a mechanism for taking a group of HTML formats and styles that are frequently used together and grouping them into classes. When a particular grouping of formats is required (for example, in a hypothetical News website, there may be certain formatting and style tags that make up a news headline) for which a CSS class exists (i.e., the class NewsHeadline is 20 point, bold, italic, and red), the HTML page can succinctly reference the class to specify the format of some text. This is far easier and more efficient than restating the disparate formatting and style tags every time a news headline is needed.

-JavaScript. Despite its name, the JavaScript language itself is neither a derivative of nor is it related to Java. Originally drawn from a Netscape specification known as “LiveScript,” Sun and Netscape have rebranded their implementation as “JavaScript.” JavaScript in the form of the ECMAScript standard, has since become the established client-side scripting language; it is used to manipulate the browser’s DOM so as to create dynamic effects on otherwise static web pages for all browsers.

-XML. Extensible Markup Language represents any kind of textual data as a tree-like hierarchy in a text file. The data of an XML document is kept between start and end tags similar to HTML, but, unlike HTML, these tags can be named whatever the designer wishes; they have no predefined meaning. While an XML document looks similar to an HTML document (both have tags and attributes, and both keep their data between these tags), basic XML has nothing to do with presentation and makes no assumptions that it will ever be viewed by a browser. XML is becoming the standard for transporting information between different systems and, as we will see in Chapter 6, XML documents can easily be transformed into HTML pages via a technology known as XSLT.

-XSLT. XSLT is actually an XML grammar that specifies how an XML document that contains tags and data may be translated into some other textual form. While XSLT may specify any output format, it is often used to translate XML documents into HTML documents. This XML-to-XSLT transformation process provides for the long-sought-after split between data and presentation that the industry has been looking for.

If you are not familiar with some of the technologies listed here, don’t worry; this CodeNote will demonstrate where, when, and how they can be used.

Battle of the Browsers: Developing for the Lowest (or Highest) Common Denominator

There is a saying in this industry: “The nice thing about standards is that there are so many to choose from.” This wry comment is definitely applicable to web UI. Fortunately or unfortunately (depending on your point of view), web developers work in an exponentially growing market dominated by the browser duopoly of Netscape (more specifically, AOL/Time Warner) and Microsoft. The two companies have run a neck-to-neck race since 1995 and, at different times, have leapfrogged each other with new interactive/dynamic features and capabilities.

While new features are always welcome, it puts developers and designers in a difficult spot when one browser supports a feature that another does not. It is even more frustrating when both browsers support a similar feature, but have slightly different, subtly incompatible approaches. All in all, the use of any feature above the HTML 3.2 (we are at 4.1 at the time of this writing) specification inevitably gives rise to the possibility that there are some people using older browsers that will not be able to utilize the feature. Or, worse yet, the feature may actually be disruptive to browsers that do not know how to accommodate it. These sorts of issues are particularly noticeable with DHTML and the Document Object Model (DOM).

At the time of this writing, many developers would argue that Microsoft’s Internet Explorer (IE) has taken a strong lead over Netscape. IE supports a rich, fully featured (and backward-compatible) DOM, enhanced JavaScript features, and intrinsic support for basic XML and XSLT. For its part, Netscape has completely broken with its techno- logical strategies of the past. It has leaped out of its 4.x version series and into version 6.0 (there was no version 5.0), where, like IE 5.x, it (partially) implements a specification from The World Wide Web Consortium (W3C; www.w3c.org), DOM Level 1. But at a cost. Whereas IE remained backward-compatible with its non–DOM Level 1 methodologies, Netscape chose to completely break with its past and not support its previous proprietary approaches.

At any rate, it might seem that with both IE 6 and Netscape 6 supporting the W3C DOM Level 1 (and thereby, at long last, having similar dynamic capabilities) we finally have a common platform to write to. Unfortunately, at the time of this writing, Netscape 6.0 adoption has been slow. Furthermore, many major corporations with controlled, centralized releases of software (browsers included) are still standardized on Netscape 4.x. What’s more, they will be very likely to consider deploying IE in the future as opposed to Netscape 6, even if they have been traditional Netscape users; the two-year delay between Netscape releases 4 and 6 has, arguably, allowed Microsoft’s aggressive marketing and development tactics (and jump start on many new features) to eat into Netscape’s install-base. However, while a number of Netscape users have switched to IE, many others will remain loyal to Netscape—they may feel it is a superior technology, they may be philosophically opposed to Microsoft, or they may be familiar with it and simply prefer Netscape. It is important to point out, though, that many Netscape loyalists will stick with a version of Netscape 4.x as opposed to adopting 6.0. Here again, they may prefer the older versions because they are familiar with them, or it may be a corporate standard where they work. So, you have, in essence, Netscape 4.x versus IE 5.x (and soon IE 6). The difficulty here is that there are fundamental differences between these two browsers. Netscape 4.x leverages a proprietary technology for dynamically modifying web pages via a scripting interface known as Layers; IE has never supported Layers. However, not only have Layers been cast aside in Netscape 6.0 in favor of the DOM Level 1 specification, but Netscape 6.0 will not even recognize Layer syntax from older versions of itself.

So where does all this leave us? After reading this CodeNote and ramping up on web design theory and the primary web technologies, will you be able to apply what you learned? Or will you be forever forced to develop and design for the lowest common denominator?