Site Design Versus Application Design

part of Perl for the Web

A full-page magazine advertisement can be the perfect venue of expression for corporate graphic artists. The only inherent restrictions are the size of the page (which is huge) and the resolution of the color imagery (which is so tiny as to be infinite.) The challenge is to reach a reader who spends less than a second looking at the ad, draw the reader in, and deliver the advertising message. The tools are varied, and the creative process is individual to each artist.

A Web site can have just as wide an impact as a magazine advertisement. HTML and modern Web browsers enable pages to be laid out with the same creativity, detail, and control as print–albeit in a smaller space. A Web site also offers interactivity and multimedia, both of which open up the artistic possibilities of the medium and enable more compelling expressions of information to be portrayed.

On the other hand, a commercial application can be the best form of expression for a computer programmer. An application has one main metric of success: if it doesn't do the job, it's worthless. Programs usually have other restrictions and optimizations, as well; performance, memory footprint, and efficient use of resources all have to be taken into consideration. Human factors are important, but they usually come second to a clean, efficient program that operates without errors. Creative impulses are less of an ally than a solid set of solutions upon which the programmer can draw to solve problems quickly and reliably.

Web sites have become applications in their own right. Some of the most popular Web sites are applications at their core. For instance, an e-commerce site is really a shipping and ordering database front-end that incorporates business logic and data mining capabilities with a graphic user interface, and a news site is really a real-time publishing and syndication engine with data collection and distribution interfaces. In addition, a business-to-business (B2B) portal is really an integration infrastructure with quality assurance, security, and administrative interfaces. These sites require the same scalability, performance, and reliability as any other enterprise-level application.

The line between Web sites as venues of artistic expression and Web sites as applications is a thin one that is blurring more with each new technology. Convergence–a buzzword usually thrown around in reference to Web sites and multimedia outlets such as television or radio–is a reality for these artistic applications, and the opportunities it opens up are only surpassed by the problems it creates. A Web application is judged not only by the way it works, but also by the way it looks and feels. A site that provides accurate information or useful services 100 percent of the time is valuable, but one that does so while presenting the information or service in a pleasing, easy-to-access fashion gains much more support.

Because Web applications are being created jointly by graphic artists, programmers, and other types of developers, it's important to meet the needs of all groups. Graphic artists need the flexibility to create aesthetically pleasing interfaces, programmers need a stable environment in which to develop clean code, and other groups need clear interfaces to the work that is available.

What Graphic Designers Want

Web site design is a lengthy process, even when programming is not involved. Content production, editing, layout, and graphic design all have their respective processes and problems. Content takes time to gather, and it is sometimes not available until the site is live. Editing Web copy takes time, and the process it uses is sometimes a duplicate of content production. Layout has to walk the fine line between consistency and suitability to specific content. HTML itself is not an easy language in which to provide content; it's less complicated than page layout programs, but it's less sophisticated as well.

Graphic artists would prefer to have a definite goal to which they can work; the more uncertainty there is in the design environment, the more likely it is that an assumption made during the design process will not be accepted. Consistency across the site is an additional hedge against potential changes to the design; consistency enables the graphic artist to make design decisions once and carry them through the rest of the site.

Consistent Look and Feel

Site design is made considerably easier for a graphic artist when page elements are repeated consistently from page to page. For a commercial site, this makes it easier to create a brand identifying the content. Branding is more important on the Web because a site can be accessed in an indefinite order by viewers referred from an unknown source. Consistency also provides improved navigability to sites by allowing viewers to discover a site without having to relearn basic navigation elements.

In the early days of the World Wide Web, HTML pages had very little resemblance to each other, even when they were performing similar functions on the same site. The nature of Web servers was to provide a different page for each request without any knowledge of pages that were accessed previously; thus, each page was treated as a complete document with its own formatting and structure. Unfortunately, this presented a navigational nightmare as users were forced to choose between wading through monolithic pages with the site's content laid out linearly or following links from one page to the next without an overall picture of each page's ownership or relation to other pages. Site designers quickly learned to use consistent design elements on related pages to provide continuity and navigability within larger sites.

Originally, consistency was addressed by designing one page with the desired look, and then copying the page and modifying it for each subsequent page of the site. This worked fine for the initial development of small sites, but modifications to any design elements had to be copied manually to every page each time they were made. Developers of larger sites with hundreds of similar pages learned this lesson the hard way, as changes to the look became cumbersome and time-consuming to implement one page at a time. Sometimes, new changes became necessary while earlier changes were still being implemented, thus creating a site with as many navigational variations as before.

Frames–introduced by Netscape for the 2.0 version of Navigator–seemed to be a good solution to the problem of consistency. The common elements of a page would be broken out into separate frames, and only the information that changed from page to page would be reloaded. Unfortunately, the implementation of frames was a disaster; site design had to become much more complex because a frame set was made up of a group of HTML pages, each of which could be accessed directly by the browser. Rather than providing a consistent look across an entire site, frames created disparate pages that contained navigation structures without content, content pages without navigation, or branding elements with neither content nor navigation.

Template-based design is a more recent way to provide a consistent look to many pages without the need to break the design elements into pieces or make hundreds of unchangeable copies of them in each page or application. Tools such as Macromedia Dreamweaver and Adobe GoLive enable templates to be created during the design process. The templates are then applied across a site. However, they don't make the job of transferring the updated site to the Web server any less complex or time-consuming. They also aren't likely to support the Web applications that are present on the site; this is the reason why many sites have a less interesting look for dynamic pages than they do for static ones. A better solution would enable graphic artists to use the templates for both static and dynamic content.

Round-Trip HTML Design

Of course, the tools used by a programmer to write and test code are not the same tools a graphic artist uses to compose HTML pages or other Web-ready content. For instance, a Web Perl programmer is likely to use a basic text editor to write Web application code, and then he or she would test the code by running it in a Web environment. Simulating the final runtime environment is usually very difficult. Thus, intermediate steps between creation and implementation are few. As a result, the code produced by programmers is likely to be inaccessible to the designer's tools and processes.

For instance, a CGI application such as the one in 3.1 has HTML elements along with the Perl code, but it would be very difficult to extract the HTML in a form usable to an HTML editing application. Within the Perl application, the HTML could be in blocks of text, quoted strings, or even composed on the fly. The only way to extract it in the final form is to execute the program.

Listing 16.1 CGI Program with HTML Output

01 #!/usr/bin/perl
02 
03 print "Content-type: text/html\n\n";
04 
05 print <<EOF;
06 <html>
07 <head>
08 <title>Problems with CGI</title>
09 </head>
10 <body>
11 EOF
12 
13 foreach my $number (1..3)
14 {
15 print "<p>$number. Embedded HTML.</p>\n";
16 }
17 
18 print <<EOF;
19 </body>
20 </html>
21 EOF

A one-directional solution involves the site designer providing application developers with a template page to use when writing the HTML output sections of the Web application. Unfortunately, this approach assumes that the applications are updated to match new templates as they are made available, which can cause delays to implementation. It also assumes that programmers are comfortable with taking the time to replace possibly hundreds of lines of HTML embedded in their code with nearly-identical HTML supplied by the site designer, and that graphic artists are comfortable entrusting the timely update of their HTML designs to programmers.

This situation also makes it difficult for graphic artists to incorporate changes to the template made by programmers when adapting it to Web applications. If Web addresses in an image map are changed to point to different parts of an application, for example, the changes won't be reflected in the original template. This gets more complicated with the inclusion of JavaScript or other client-side scripting; the lines between HTML text to print and programmatic code to develop become blurred.

The best solution would be to base the look and feel of both static pages and Web applications on a single template file (or set of files) in a single location that is accessible to both graphic artists and programmers. The applications and pages would derive their look from the template, and modifications made to the template by either application changes or site redesigns would be available to all groups.

What Programmers Want

Images of start-up companies with Nerf armories and all-night coding sessions might make the programming world seem as chaotic as any creative endeavor, but that chaos masks the underlying rules and structure programmers rely on when producing code for Web applications. A programmer works best when given a clear goal to meet (for example, to display a given query in a given format or to deliver a provided piece of information to a given database) and a clear set of guidelines to use in reaching it.

Programmers are looking for any shortcut that gets them to the goal faster; conversely, they resist any process that might pose a threat to their progress. Readable code helps a programmer understand code faster, modularity keeps the programmer from reinventing the wheel, and future-resistant code keeps programmers from having to modify it as often.

Clean Code

If there's one axiom that is constant throughout all program development, it's that all code needs to be changed sooner or later. Whether it's due to new bugs, incompatibilities with new software or hardware, or the addition of new features, any application is likely to be modified at least once–and more likely, many times–over its lifetime.

Code rewrites aren't automatic, though. They are performed by programmers, no matter how much automation is put into the process. Programmers are also human, which means they have priorities, style preferences, and idiomatic ways of creating code. For instance, it's possible to write code that is impossible to decipher. The practice is called obfuscation, and it can be the result of deliberate effort–usually for a competition or for artistic value. It also can happen inadvertently when programmers write unreadable code due to inexperience or the conditions under which the code was written.

Obfuscated code also can be written by code generators, such as applications that create code based on templates or other high-level languages, as discussed in Chapter 12, "Environments for Reducing Development Time." Although this code can be perfectly usable after created, it can wreak havoc on a development cycle by requiring programmers to completely decipher the obfuscated code before they modify it, rather than simply finding the part that needs changing and making the modification. The answer in a development environment seems simple: Write clean, understandable code.

Producing clean code isn't such a simple matter, though; there isn't one "good style" that is learned by programmers everywhere. Clean code is also the product of good business practices. The readability of code that is written by a team of programmers can be greatly improved by having a clear road map of functions, naming conventions, and a high-level structure. For instance, the code in Listing 3.3–a segment of the forum code written for VeloMeter.com, as detailed in Chapter 14, "Database-Backed Web Sites"–is written to conform to a style guide agreed upon by VeloMeter.com developers. Listing 3.2 is a work-alike segment, which follows a different style.

Listing 16.2 Code in a Default Style

01 squeal($q,'Please try again.');
02 
03 sub squeal {
04 $_[0] or return; $_[1] =~ tr/ /+/;
05 print $_[0]->redirect("/forum/confirm.psp?error=$_[1]&".$_[0]->query_string);
06 exit;
07 }

Listing 16.3 Cleaner Code in the Author's Style

01 show_error($q,'Please try again.');
02 
03 # redirect the user to the input page with an error if needed
04 sub show_error ($$)
05 {
06   my $q = shift || return;
07   my $error = shift;
08   $error =~ tr/ /+/;
09 
10   my $query = $q->query_string;
11 
12   print $q->redirect("/forum/confirm.psp?error=$error&$query");
13   
14   exit;
15 }

The subroutines in Listings 3.2 and 3.3 perform the same function, are called with the same arguments, and work nearly identically. The difference is striking, though, and Perl's indifference to variations such as these is usually seen as a drawback to programming in the language. However, the idea that a language should force programmers to create clean code makes little sense; it's much easier to develop and enforce a style at the project or team level than at the language-design level.

Some improvements in the readability of Listing 3.3 come from basic Perl style rules; it's much easier to tell that the error message is being printed when it's named $error, instead of the more Perlish $_[0], in line 12. In addition, the $q object is easier to recognize when it's named the same in line 6 as it is in line 1. Also, basic whitespace and indenting rules help group functions in a logical way throughout the program.

Further enhancements come from style rules developed by the project's authors. Program blocks begin with a curly brace on their own lines, as in line 5. The ending brace in line 15 is at the same indent level to enable easier matching. Cute function and variable names such as squeal are eschewed in favor of functional descriptions such as show_error, which use whole words separated by underscores for easier reading. The $q object is an exception to this rule because the object it references is common in Web programming and likely to be used frequently; a shorter identifier, as in line 10, is less obtrusive when calling methods. The $dbh database handle object–used frequently in the examples throughout this book–is another example of this idea.

For Web applications, clean code can make the difference between a quick site modification and a major rework. If a five-minute modification to the content on a Web page requires a six-day trek through the inner workings of a complex application that consists of code in a style such as Listing 3.2, more important modifications might never have the chance to be made.

Modularity

Components, beans, modules, objects, layers, and plug-ins–they're all ways of providing program modularity. Program modularity enables each part of a program to be developed and modified separately, without impacting the overall usability of the program. The plug-in interface to Netscape Navigator, for instance, enables third-party programmers such as Macromedia to produce extensions, such as the Shockwave, to the Navigator program player without having to change them every time a new version of Navigator is developed. Similarly, a new version of the plug-in can be developed without requiring modifications to Netscape itself.

Modularity goes hand in hand with abstraction, which is the capability to address part of a program in a standardized way, regardless of the underlying implementation. For instance, the Shockwave plug-in makes calls to the Netscape plug-in API, which is a defined set of methods that Navigator responds to in a consistent way even when the underlying functions being executed change. Abstraction can be codified in a standard such as HTML, which provides a common language that is used regardless of what the Web browser or Web server actually does to create or interpret it.

Subroutines, modules, and object interfaces are the main structures used to provide modularity and abstraction in Perl. Objects are found also in Java, C++, C#, and Python, and modules are similar to headers or includes in procedural languages such as C. Subroutines are common in most languages and are generally used as the first examples taught to computer science and other programming students. Each layer enables a program to be developed in parts that interconnect in formalized ways.

Modularity doesn't just work at the language level, though. Programs are rarely self-sufficient, and they frequently combine features with other programs to make more complex applications. In fact, this idea of small programs that "do one thing and do it well" is a founding principle of UNIX-like operating systems. For instance, an e-mail retrieved through an mail program could be searched with grep and the resultant lines could be counted with wc to produce a tally of the occurrences of a particular word. Because each program both takes in and emits text, neither program needs to know how the other is implemented.

Web sites enforce their own modularity by implementing the Hypertext Transfer Protocol (HTTP) and the standard uniform resource locator (URL) notation. These two standards break a site into a hierarchy of directories with discrete files, any of which can be accessed at any time from any network-accessible locale without the need for previous exposure to any other file. Because of this simple structure, a Web server can provide thousands of files per second by applying a simple translation between the URL requested and the location of the file on the disk. The server also can cache files or compose them on the fly as long as the basic needs of HTTP are met.

Web applications have to merge the document-based statelessness of Web sites with the reusable persistence of application objects. Unfortunately, this usually means that parts of a Web application that should be shared–such as the look of a navigation bar or previously-selected user preferences–are likely to be expressed in a multitude of file locations, as seen by the Web browser. This can cause problems when neither the browser nor the server is saving program information; recreating state information with each request can create additional load for the server and discontinuity for the browser.

Modularity is a must also when extending a Web application to provide new features and functionality. It's easier to develop and test a small, independent piece of a large Web application than it is to test a piece on which the entire application is dependent. Abstraction also restricts the possible ways that the larger Web application interacts with the piece being modified.

Future Resistance

Of course, the best way to avoid rewriting a piece of code is to write it with the future in mind. The future comes all too quickly for Web applications, and the pace of change requires that old programs do work they were never designed to do because there's no time to write a new program for each new function. Unfortunately, it's usually difficult to predict all the possible uses of a Web application when it's first designed, and it's practically impossible to design an application that is compatible with every future technology.

Code that is written to a standard is more likely to be flexible when the demands on it change. The Web server is a perfect example of this principle; even though Web browsers have changed significantly since the Web was first implemented and Web sites have grown to incorporate countless new applications, Web servers themselves have been able to focus on their primary goal of serving more files in less time with more flexibility. This is possible because the Web server is written to standards such as HTTP, multipurpose Internet mail extensions (MIME), and the common gateway interface (CGI). To a Web server, a Java applet is just another MIME document, a data mining application is just a set of CGI scripts, and a load testing application is just another HTTP client.

The standards themselves are usually repurposed for use with new technologies. MIME was originally proposed as a standard way to identify file attachments embedded within an Internet e-mail, but Web servers started using MIME descriptors to identify files as they were returned through HTTP. CGI was originally designed as a way to pass arguments and environment variables to external programs called by a Web server, but the conventions of CGI are used also by technologies such as FastCGI and mod_perl to make them more understandable to the programmers using them.

What Everyone Wants

Of course, the Web application landscape isn't a battleground. Programmers, designers, and other staff members do agree on some aspects of the process. Everyone involved would like to see shorter development cycles, consistent results, and help from other teams. After all, everyone wants the end result to be a site of which they can be proud.

Shorter Development Cycles

Nothing can possibly happen quickly enough on the Web. If any information relevant to a Web site changes, the Web site needs to reflect that change as soon as it happens, no matter when it happens. If there is any delay, the possibility exists that someone will access the site, get the incorrect information, and lose confidence in the accuracy of the site's information.

As a result, content producers need the ability to change site information at any time with little or no notice. This applies to all types of content, whether it's advertising copy prepared by the marketing department or a home listing entered by a user of a real estate site. Self-determination allows content producers to work to their own schedules, applying changes and updates whenever needed without adding more work for programmers and site administrators.

This idea has worked well for news and comment sites that integrate content production into the basic framework of the site. By allowing any site visitor to post news stories or add comments, these sites provide a richer experience to future visitors without additional effort. If this type of content required intervention by programming staff or site administrators, it would cause much more work than it was worth.

Application programming and graphic design have their own tight schedules. In both cases, changes and new development have to be acted on as soon as possible to allow time to implement them, and the finished product has to allow for changes that come to light after it is available for review. If either graphic designers or programmers have to wait for the other group to implement a change before it can be reviewed, the result is a site that doesn't fit the requirements or a deadline that is missed.

With a Web year lasting only six calendar months, schedules are tighter than usual and advance notice of design changes is in short supply. If a site requires a quick change and it relies on someone who is out of the office for a week, any process that relies on that person loses that week as well, and site visitors spend an entire week either looking for a change that hasn't been posted or using out-of-date information.

Clear Division of Labor

Nothing brings site design to a grinding halt sooner than making everyone wait for a manager to decide who needs to implement each new change. When there is no acknowledged ownership of a file, project or process, it becomes difficult to determine where even the smallest change should be made, and by whom.

Programmers want to program; they don't necessarily want to learn the intricacies of graphic design every time an application needs to provide a new visual interface. If programmers are left to their own devices without a clear route to the work of graphic artists and other site designers, they either ignore needed changes entirely or implement them in a way that seems reasonable to them. This can result in a Web application that is unappealing at best and unusable at worst. With clear guidelines to follow when drawing the line between site look and feel and application function, programmers are more likely to fit application structure into the site design seamlessly.

Graphic designers want to design; they don't necessarily want to learn the intricacies of a program listing every time the look of an application changes. They might become frustrated if the changes they make to the look of a site create errors in the site's Web applications. If forced to choose leaving applications in an outdated state, asking for programmer assistance in updating the look and feel, or breaking functionality, graphic designers are likely to update the accessible parts of the site at the expense of Web applications. If graphic artists have a clear path to updating the site's look and feel and they can do so safely, easily, and with instant results, they are more likely to make each change across the board to keep the site consistent.

Usability testers want to churn; they don't necessarily want to learn the intricacies of graphic design or programming when an interface change is dictated by usage patterns. They certainly don't want to wait a week to test a slight variation to a widget when there are a dozen other variations to test before the application goes live. If given the choice between hacking together code and graphics that fit the usability criteria or waiting for graphic artists to match the site look and feel and programmers to optimize the code, usability testers will make the change first and attempt to sort out the conflicts later. If usability testers are given an intermediate level of code generation that is clearly separated from site look and feel and underlying implementation programming, they can make broad changes to the operation of a Web application and test the results immediately with confidence that the changes will carry intact through to the final site.

Content providers want to write and edit; they don't necessarily want to dive into the sea of usability, design, and code whenever there's a new piece of information to present or an old bit of copy to change. Unfortunately, administrative interfaces to application data are as difficult to write as the Web applications themselves. If a site is designed with modularity and abstraction in mind, however, administrative interfaces can be added to a site just as easily as other application components can be added.

Every team wants to know what its domain is, what its limitations are, and where to go for help in other areas. With the right approach, this idea can be extended to the design of Web sites and Web applications as well. Each group can have its own area of expertise, and each area can be abstracted for use by other groups.

The Cool Factor

Everyone involved in producing a Web application wants a site that looks great and that provides the latest and greatest features. Programmers want to show off their skills in producing the fastest, most capable applications, graphic artists want to win design awards for their avant-garde work, user interface designers would love to see repeat traffic from satisfied users, and they all want to impress the boss, the viewer, and the folks back home. The chance to elicit the "Wow!" response is difficult to pass up.

Unfortunately, the coolest programming tricks aren't necessarily the most stable or extensible. When Java was developed, for example, the urge was to add Java functions to all parts of the site without regard to their real utility. The result was a lot of sites with "nervous text" or mouse-over animation that either slowed site responsiveness or crashed Web browser software. These useless features were quickly dropped from sites after the problem of updating potentially unstable Java applet code for simple site changes was revealed. Of course, after Java technology matured, it became possible to find areas where applets were truly needed.

Likewise, the coolest graphic designs aren't always the most usable or conducive to performance. A site with the fastest Web applications imaginable can still be brought to its knees serving 15-megabyte Macromedia Shockwave files or Quicktime background music. If system resources are nearly all being devoted to supporting style, it's difficult to provide Web application substance with the remaining resources. At the other extreme, sites can be made unusable by relying on all the latest features from Cascading Style Sheets, JavaScript, and the Document Object Model (DOM), even if they would enable simple underlying code and a rich graphic interface. Browsers that support only a subset of the features used might cause navigation to behave strangely, increasing the need for server-side assistance in checking user input and determining browser compatibility.

Web applications might eventually benefit from cool new features and exciting graphic design, but a more sustainable approach might require waiting for some technologies to achieve wider adoption and greater stability.

Summary

Programmers, graphic artists and other site personnel have different needs and priorities when designing Web applications. Graphic designers want artistic freedom with the look and feel of a site, but programmers are looking for stable, extensible architectures that can be modularized and optimized as the site grows. Everyone involved would like a clear division of labor and a result of which they can be proud.