This edition of CodeNotes includes:
-A global overview of a technology and explanation of what problems it can be used to solve
-"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.
About the Author
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 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.
-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.
-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 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?