Building Web sites has changed, and someone forgot to tell the architects.
Web browsers’ support for modern techniques has allowed a new degree of discipline and control in coding the front end of a Web site. These new best practices are those dictated in what is commonly referred to as “Web standards-based” design or development.
A Web standards-based approach has countless benefits. The larger or more complex a Web presence, the more critical Web standards become. This is particularly true for an enterprise with many different properties, channels, or brand considerations. Add to this the prospect of critical Web-based applications and content management, and it becomes a mandate to ensure a high level of quality at every tier of an online presence.
To embrace standards is only the start. Some planning must occur to create a standards strategy that will endure over time, be applied gracefully, and scale within an organization, team, or enterprise. A solid foundation should be created by getting back to the basics and building with deliberate choices instead of accidental decisions.
This book will help a Web team reexamine why they are creating standards-based Web sites and how best to do it. It will help evaluate what is in place now as well as the impact of Web standards on a team or a Web site as a whole. It will also assist with staying organized over time and in finding ways to improve stability and reduce risk in Web applications. It will help create techniques that leverage the unique strengths of Web standards in a CMS (Content Management System). Finally, this book will finish by examining some process and staffing considerations of Web standards.
Web standards is a term used to mean Web pages built using the open and compatible recommendations from the World Wide Web Consortium (W3C) and other standards bodies as opposed to closed, proprietary, corporate feature sets. These recommendations, combined with modern best practices, exploit the standardized power of the modern Web browsers that dominate the market today, as opposed to out-of-date browsers that were feature-rich but inconsistent and often incompatible. Placing a graphic that reads “This site designed for Netscape Navigator” on the main page of a Web site should be a thing of the past.
Web standards fail gracefully when encountered by out-of-date browsers. The standards are also intended to provide greater benefit for accessibility and for other types of media. These techniques are built with intentional side effects that can benefit users, the company, and the team responsible for creating the sites. Whole books have been written on the subject.
Sites built with Web standards have many benefits, right out of the box, virtually without robust technique or experience. These include
Style and script reuse and consistency
Reduced bandwidth use and caching of style and script files
Faster rendering of pages
Cleaner, easier-to-maintain code
Easier to make search engine-optimized
Increased compatibility between browser vendors
Improved chances of document legibility for the next generation of browsers
Increased readership for your site!
In simple software terms, the front end of a Web site can be referred to as its user interface (UI) layer. The UI layer of a Web site includes all the artwork, text, formatting commands, interaction instructions, and controls sent from a Web server over the Internet to be viewed by a user inside a Web browser. A user may interact or “interface” with the resulting Web page UI by clicking objects or typing, thus providing input for a new request, which is then sent back over the Internet to the Web server to start the cycle again (FIGURE IN.1).
Contrast this front end to server-side programming, which includes business logic and direct interactions with databases or other data stores. Oftentimes a server-side program must render a UI layer. By the same token, the UI layer can send directives or input to a server-side program and may contain some business logic. This demonstrates how pervasive a UI is and how it touches every aspect of Web sites, from the simplest static marketing page to intricate business logic.
When Web authors build a modern UI layer, they may include complex instructions or share code between pages and server-side programs to be more efficient. Therefore, a redesign, or modifications to the UI, can get complicated or far-reaching. Or both.
How can this code be managed in an effective manner, shared among large teams, and remain efficient from a productivity standpoint over time?
The 1990s dot-com boom introduced horrible UI practices that led to bloated, unstructured, risky, and inefficient construction of Web sites. The structure of a simple Web page became an ugly mess referred to as “tag soup”—a virtual train wreck of nested HTML tables and single-pixel transparent spacer GIFs that had to be designed before work could begin on the page’s content or an application (FIGURE IN.2).
Massive HTML documents were the norm, weighing down the user experience and making the slightest modifications difficult. To enable user interaction via JavaScript was also a hack, with embedded event handling and code forks based on proprietary browser techniques. Finally, to control any of the output on your Web site or application required intertwining your content, presentation, and application logic all together in layers, which introduced business risk and management hassles.
The vast majority of the effort and project planning on large-scale Web projects today trivializes the UI layer and treats it as an afterthought, when in fact it can deeply impact content management, Web applications, search engine optimization (SEO), bandwidth costs, site performance, and maintenance efforts. Plans typically start with the back-end software and only touch on the UI in terms of design.
Fortunately, there are ways to pare down the long-term risks and remove the constraints of traditional Web coding. Embracing modern techniques starts with the W3C and its recommendations, often called Web standards.
The issue should be considered not only in terms of your design, but also where the content management, applications, and other dynamic systems are concerned. If a Web site is to reap the benefits of a Web standards-based UI, it needs to be considered at all levels, and plans should be introduced that will allow the site to grow intelligently.
What, exactly, changes when you’re planning a site with a Web standards-based approach?
First, on the UI layer, conforming to Web standards means 100% separation of presentation from content and structure, as well as the scripting behavior of UI elements. Second, on the back end, this means limiting the mixing of UI code in the Web applications and CMS code that may need periodic updates, and applying the same strict separation as to any other static screen.
The distinct areas to concentrate on are
Content and structure—the markup layer, usually made up of HTML (HyperText Markup Language) or XHTML (eXtensible HyperText Markup Language)
The presentation layer—consisting of CSS (Cascading Style Sheets), which is referenced from the markup and the sites scripts
The behavior layer—the JavaScript elements that enable user events and interactions
The software and CMS layers—these have a UI of their own and often produce the above UI layers
The teams and processes that help to build all of the above
It is not difficult to attain UI layer separation in a static setting devoid of software or large teams. The key is that the Web software needs to respect these distinctions as well, and the project plans need to consider the UI layer as a first-class citizen that needs to interact with all systems in an intelligent and thoughtful way, not as a second-class citizen that is simply an afterthought.
Layers of code serving different purposes are not a new concept for the software industry. In fact, there are numerous examples of architectural design patterns that software students have been studying for years. A good list with links to examples of architectural design patterns can be found on Wikipedia at http://en.wikipedia.org/wiki/Architectural_pattern_%28computer_science%29.
An example of a popular pattern called “model-view-controller” is, in simple terms, something like the following:
Model: Logical meanings of raw data used for various business purposes. Think of the model layer as an application program interface (API) for other parts of a program to connect with it. This layer is responsible for the computational footwork we rely on computers to do for us, like adding up the cost of items in a shopping cart or determining if today is our wedding anniversary.
View: This is the eye candy one sees when the model is rendered into a UI layer or part of the UI layer. Think of an HTML+CSS web page from a Web application as the view.
Controller: Frequently event driven, it interprets and responds to user actions and may drive changes to the model. Think of this as the layer responsible for handling user actions which include, but are not limited to, mouse clicks or Web-based form submissions.
To extend this model to Web software and Web standards, some have labeled the UI layer separation of content, presentation, and behavior as a parallel to this pattern, using the model (content and structure), the view (presentation), and the controller (behavior). Experienced software architects are often quite eager to embrace a layered front end whether they are familiar with Web design or not.
A traditional plan starts with back-end requirements and then builds on a UI layer code as an afterthought. Today, using a modern Web standards-based approach, teams should ask themselves the following:
Is the UI layer built and structured for easy maintenance?
How does the UI layer impact SEO?
How does the UI layer interact with the site’s content management system (CMS)?
Is it possible to redesign or make simple design changes without deep CMS impact or the need for CMS staff?
What happens when it comes time to modify or enhance the UI?
How do you integrate a UI with a Web application?
What happens when the application logic changes?
How risky is a design change to an application?
Should mission-critical applications buckle under the pressure of needlessly risky design, simple content, or script changes?
A well-planned Web standards approach will mitigate these risks at two levels: first, the front-end code; and second, where the back end meets the front end.
Over time, for any site, these questions become big issues. Larger enterprises often have a Web presence in place, and mass change will not be possible or will be too difficult to achieve overnight. Incremental change may be required. Where the line is drawn will be different in almost every case.
When planning for change, first figure out what needs to be designed, whether it’s marketing content or an application, and how it needs to be rendered in the browser. Second, make reasoned decisions based on the pros and cons of each option. Finally, figure out how to get a site to its standards-compliance goals and how to keep it that way.