Taking Your Talent to the Web- P24 docx

We’ll look at where the web designer fits in and how server-side applications help us manage immense content sites or change text and appearance in response to user actions.. Nat-urally,

chapter 12

Beyond Text/Pictures

O N FIRST DISCOVERING THAT THE W EB IS NOT PRINT, many designers see only the drawbacks: poor typographic resolution; a limited pool of installed user fonts; bandwidth bugaboos; the need to compensate for browser, platform, and hardware differences; and the awkwardness of trying to read a com-puter screen in the bathroom

As we start to become genuine web designers, though, most of us see more advantages than disadvantages in the Web’s distinctive differences from print For example, instant worldwide distribution looks pretty darned good after wrestling with print shops and mail houses

The longer we work at it, the more we marvel at the Web’s ability to provide universal access across seemingly unbridgeable gaps of technol-ogy, nationality, economic and political systems, and physical ability or disability

As these barriers are crossed, the human spirit becomes less isolated, sus-picion and intolerance begin to fade, and we learn to appreciate each other’s differences instead of fearing them These benefits will greatly increase if the whole world gets to come along for the ride They will greatly diminish if too many humans get left behind

This, the substance of the vision of the founders of the Web, should be enough But there is more In particular, there are the two profound differ-ences between the Web and print that we’ll discuss in this chapter:

1 The ability to develop not simply static pages, but full-fledged,

dynamic experiences

2 The visual, sonic, and interactive possibilities inherent in rich media, whether it is delivered through emerging web standards or popular plug-in technologies

These two unique strengths of the Web have tremendous implications for business and for art Each has played a huge part in popularizing the medium Each brims with powerful potential that designers and develop-ers have barely begun to tap Each also has the potential to be abused

328 HOW: Beyond Text/Pictures

Figure 12.1

Nicola Stumpo’s “Destroy

Everything” is a

noncom-mercial, nonnarrative

Flash site that eats

your screen alive

Stumpo’s emotions are

probably inexpressible

in any medium outside

Macromedia Flash

( http://www.

abnormalbehaviorchild.

com/ ).

P RELUDE TO THE A FTERNOON OF D YNAMIC

In Chapter 11, “The Joy of JavaScript,” we saw how JavaScript and its big brother, the Document Object Model (DOM), facilitate interactivity that printed media can only dream about In the pages that follow, we’ll look at additional and powerful ways of making the Web more interactive

Dynamic sites enable web users to locate information, store phone num-bers in a shared contact database, buy holiday gifts without braving crowded shopping centers, or view “adult” material without shame until the baby-sitter barges in

In this chapter, we will see how web agencies use server-side applications

to build sites that let users do things We’ll look at where the web designer

fits in and how server-side applications help us manage immense content sites or change text and appearance in response to user actions We’ll also discuss how small shops and freelancers can get in on the action even if they don’t have casts of thousands and budgets of millions at their dis-posal

We’ll also see how technologies like Java can compensate for “missing pieces” in our visitors’ browser setups or unleash full-fledged software pro-grams that run right in the browser And we’ll explore Java’s potential beyond the desktop

Figure 12.2

Here is a tranquil moment outside the Eiffel Tower, captured in all its panoramic, Sensurround glory courtesy of Apple’s QuickTime VR—part of the QuickTime plug-in Print cannot do this ( http:// www.apple.com/ )

You Can Never Be Too Rich Media

After all that, we’ll examine emerging “multimedia” web standards that are almost ready for prime time and take a peek and a poke at plug-in tech-nologies that can radically enhance your sites—if used with respect for the realities of average web users

These technologies are not for every site, but, when appropriate, they can enhance the web user’s experience tremendously Used poorly, of course, they lead to less satisfying experiences We will explore all these tech-nologies and consider what causes both kinds of experiences

Knowing you as we do, we’ll start with the drier, more technical stuff because if we saved it for later, you’d never read it

Think back to our earlier discussion of Perl versus JavaScript in Chapter 2,

“Designing for the Medium.” As far as the Web is concerned, Perl is most

often used in server-side transactions, such as the processing of a

visitor-submitted mail form You might remember that a server-side technology is

one in which the computing process takes place on the web server (hence

the name) rather than the end-user’s PC With Perl, number-crunching tasks fall to the web server, while the visitor’s computer sits idly, waiting

We contrasted Perl with JavaScript, whose actions take place in the browser With JavaScript, the end-user’s computer (the “client,” in geek

parlance) does the heavy lifting JavaScript is a client-side technology

Nat-urally, the dynamic technologies we’re about to consider do some work on the client side and some on the server side After all, the two sides are

con-tinually interacting If the two sides, client and server, were not

continu-ally interacting, you would not have web transactions; you would just have machines sitting around doing nothing, like Teamsters

But though they necessarily move from one realm to the other, most of the dynamic technologies we’re about to discuss do the bulk of their work

either on the server or on the user’s desktop Sometimes where they work

330 HOW: Beyond Text/Pictures: The Form of Function

is so important it becomes part of their name For instance, as you might guess, Server Side Includes (SSI) is a server-side technology Mostly, though, the names of web technologies give very little away For instance, would you guess, from its name alone, that PHP (originally called Personal Home Page tools) is a server-side technology? Probably not

Some versatile technologies work both sides of the street Java, for instance, is frequently used on the client side, as a downloadable applet

But it also performs many server-side jobs You’ll hear developers and

sys-tems administrators talk about Java servlets, which are miniature Java

applications that run the Apache server’s mod_jserv component Or you might host a site on Jigsaw, a W3C server that’s written entirely in the Java language

You don’t really have to know any of this, as long as you get the general idea Now let’s move on to some specifics

Server-Side Stuff

The days of slicing Photoshop comps and hand-coding every last HTML page are not dead—they just smell bad

One day soon, web designers will be fully liberated from these crude pro-duction methods It will happen when a core group of web standards is completely supported in browsers, enabling us to separate style from con-tent, presentation from structure, and design from data It hasn’t happened yet, as any working web designer can tell you It’s coming soon, we tell you now We’ll talk more about it in Chapter 13, “Never Can Say Goodbye,” so save your questions until then

Meanwhile, we have interim solutions that let us create web pages with-out, well, creating web pages Under the principles of dynamic site

con-struction, we can establish the conditions for web pages instead of building

each page individually

The process is simple: To begin with, web designers create visual templates, while writers, editors, and marketers create content (Hopefully the two teams are talking to each other so that design and content work together.) The content is stored and indexed in vast, humming “back-end” databases,

and the site is launched When visitors request data, server-side

middle-ware applications fetch the appropriate content and pour it into the

designer’s template The result: virtual pages that can be read, used, and bookmarked but that do not exist as conventional, self-contained HTML documents Oh, oh, oh, it’s magic Let’s descend to earth and see how it works

Where were you in ‘82?

Ever used a search engine such as Google (www.google.com)? You type in the name of your former high school sweetheart and hit the Google Search button Moments later, you’re presented with page after page of links From these pages you learn that your old flame is the two-term governor

of a large Midwestern state, honorary dean of a prestigious university, has had two charities, a hospital wing, and a Ben & Jerry’s flavor named after her, and relaxes by participating in amateur kick-boxing tournaments The question, of course, is why did you ever break up with her? But for our purposes, the question is, where do these Google results pages come from? The Google results pages are created on the fly by software that sucks query-related entries from a huge database, determines which links are probably most relevant, and pours the results into a preexisting HTML template

Who made the software? Programmers How does data get into the

data-base? More software: specifically, a search engine spider, so named

because it crawls around the Web indexing the content and location of individual web pages Where does the designer fit in? The designer creates the template that the software uses to display the results How does the designer do that? Let’s see

Indiana Jones and the template of doom

As a web designer, you might be called upon to design the front end of an application like Google, or you might work on vast content sites that rely

on similarly dynamic processing Or you could design a site that sells things, revealing new products in response to the visitor’s desires

332 HOW: Beyond Text/Pictures: The Form of Function

Paradoxically, your job will not change that much from what we’ve

described earlier in this book You are still creating the part of the site that the visitor sees You design it as you would any other web project In a way, it’s like designing a magazine’s table of contents page You create the mas-ter design; someone else designs the individual issues It’s also like design-ing corporate letterhead in that your responsibility ends when you deliver the approved letterhead design You don’t have to sit and type individual business letters Creating website templates is as normal as those more familiar design processes It’s after the image pieces and HTML templates leave your desk that the voodoo kicks in

Precisely what happens next is up to your team’s developers—those who write the scripts that make these dynamic transactions possible The

devel-opers take their lead from information architects, whose job is to figure out

“user flow” through the transactional portions of the site (Who will come here? What will they want to do? How can we best fulfill their needs? What can go wrong?) The very things we advised you to do when planning an entire site, information architects do as they envision and structure the site’s transactions

The data can be stored in an open source MySQL database, or in similar programs from Microsoft, Oracle, and other companies As each visitor hits the site and begins to take actions, the middleware that lies between the visitor and the back-end database begins to do its thing

It is the job of the middleware to process each request, fetch the appro-priate document (or document fragment), and pour it into your template

Common middleware applications include open source PHP, Allaire Cold Fusion, and Microsoft Active Server Pages (ASP) MySQL is often found on UNIX Apache servers, Microsoft SQL and ASP on Microsoft Windows NT servers, and PHP can run on UNIX Apache or Windows/IIS

Deciding on the appropriate database and middleware is not your concern

Technology officers and network administrators solve that problem You aren’t expected to write code that complies with these middleware pro-grams’ requirements either; developers do that, and we love them for it

You can learn to write code for PHP, ASP, or Cold Fusion if you wish, and

we’ll have something to say about that in the “Doing More,” section that follows

Ordinarily, the developers and project managers will provide you with

guidelines in a document that might be called the functional spec They will

also discuss requirements with you in one or more personal meetings— probably more “We can’t have frames,” they might tell you or, “we must have frames,” could be their direction Don’t skip these meetings and don’t rush to argue Talk, listen, and learn

The work process is but a variation on what you already do You might take the comp no further than Photoshop; the developers will try to emulate it

in, say, Cold Fusion, and show you the result You might ask them to revise their code to bring the design up to your spec; they might ask you to revisit the design to accommodate limitations in the software or particular site requirements

You will also write the Cascading Style Sheet (CSS) that determines colors, type sizes, margins, leading, and so on—same as always You might find that some of these middleware technologies are unfortunately ill-suited to CSS, and you might need to do some HTML table work or have it done by your friendly neighborhood web technician

It is sad but not surprising that some of these dynamic tools (Cold Fusion and the like) are more suited to old-style methods of web construction (<FONT>tags, table-based layouts, and so on) than to the newer, stan-dards-based methods (structural markup, design via CSS) After all, these server-side tools arose in a market driven by browser quirks and proprietary technologies, not by universally supported web standards As browsers improve their support for web standards and as web designers and devel-opers begin using these standards instead of whining about them or plead-ing ignorance, the dynamic tools will likely improve in this regard

Serving the project

As you might expect, database-driven sites, built with templates, are usu-ally not the place to show off your deep Photoshop layering skills, your abil-ity to bring complex layouts to life via frames, or your newly acquired

mastery of DHTML Low bandwidth, large areas of flat, web-safe color,

rea-sonably sized web fonts: This is the terrain you must plow; these are the fields you must harvest

334 HOW: Beyond Text/Pictures: The Form of Function

Some web designers understand this as part of the discipline of the craft and strive to bring beauty, elegance, and utility to their simple designs

Others rebel and might be temperamentally unsuited to this type of work

The Web needs both kinds of designers, and there is plenty of work for both

The need for simplicity is another reason that it’s best to do as much of the design work as possible in CSS (as long as the middleware doesn’t choke

on it) There is little sense in asking the server to generate deeply nested table cells when you can achieve the same result with light, clean, struc-tural markup and a single declaration in a global style sheet By doing the work in CSS, you save processor cycles and bandwidth; and when it comes time to update the design, you can do it yourself in the style sheet instead

of pestering the programmers to change their scripts

Naturally, you will have to test to make sure that the middleware your com-pany has chosen can handle the CSS you’ve written You’ll also have to test the site in multiple browsers, as described in Chapter 7, “Riding the Project Life Cycle.” During testing, you also will want to turn off CSS in your browsers to make sure that the resulting pages work in non-CSS browsers (or in CSS browsers whose users have turned off CSS in their preferences)

What do we mean by “make sure the pages work with CSS turned off?" We mean that the pages work We don’t mean that the pages look the same with CSS and without it Bad clients and stupid companies expect sites to look exactly the same in AOL 1.0 and Netscape 6 That’s impossible with-out quadrupling the budget, and it’s also pointless Those who turn off CSS

or use older browsers aren’t hoping for a rich visual experience If you stick with basic structural markup and the simple CSS techniques described in Chapter 10, “Style Sheets for Designers,” you should be fine

Coding in PHP or ASP rarely falls within the web designer’s job description, but after working in the field for a while, many web designers are pleased

to discover that they have a knack for these simple programming environ-ments If you are one of them, this knack will not go unappreciated or make you any less marketable