Taking Your Talent to the Web: A Guide for the Transitioning Designer- P17 ppt

Just as with style sheets Chapter 10, it is possible and often desirable to save time, hassles, and bandwidth by creating one or more global JavaScript documents, which can then be used

Recognize that developers bash their brains out writing code like this because browsers behave so inconsistently from version to version and platform to platform Be glad you’re going into web design and not web development Be kind to your programmers

On the off-chance that you find this stuff enthralling or decide to switch from design to development, you’ll find an abundance of good browser detection information at http://webreference.com/tools/browser/

javascript.html and http://developer.netscape.com/viewsource/

krock_v5.html Unfortunately, there is always the chance that by the time you read this book, these pages will have moved or disappeared If so, check the Resources Department at http://www.webstandards.org/for the latest

on browser detection

Just as with style sheets (Chapter 10), it is possible and often desirable to save time, hassles, and bandwidth by creating one or more global JavaScript documents, which can then be used to control whole sections

of your site—or even the entire site

For instance, the “My Glamorous Life” section at zeldman.com (http://

www.zeldman.com/glamorous/) is controlled by a single JavaScript docu-ment (http://www.zeldman.com/glamorous/glam.js)

The document, in its entirety, reads as follows:

// Menubar preload Pretty standard stuff.

function newImage(arg) {

if (document.images) { rslt = new Image();

rslt.src = arg;

return rslt;

} } function changeImages() {

if (document.images && (preloadFlag == true)) { for (var i=0; i<changeImages.arguments.length; i+=2) { document[changeImages.arguments[i]].src = changeImages.arguments[i+1];

}

321 Taking Your Talent to the Web

} } var preloadFlag = false;

function preloadImages() {

if (document.images) { tocover = newImage(“ /omen2/coreover.gif”);

funover = newImage(“ /omen2/funover.gif”);

alaover = newImage(“ /omen2/alaover.gif”);

15over = newImage(“ /omen2/15over.gif”);

stealover = newImage(“ /omen2/stealover.gif”);

webover = newImage(“ /omen2/webover.gif”);

miscover = newImage(“ /omen2/miscover.gif”);

comingover = newImage(“ /glareon.gif”);

preloadFlag = true;

} } // Get out of some idiot’s frame.

if (top != self) { top.location = self.location; } // Popup window, 640 x 480

function open_window6(url) { mywin = window.open(url,”win”,’toolbar=0,location=0,directories=0,status=0,menubar=0,

➥scrollbars=0,resizable=0,width=640,height=480’);

} // Popup window, 500 x 500 function open_window(url) { mywin = window.open(url,”win”,’toolbar=0,location=0,directories=0,status=0,menubar=0,

➥scrollbars=0,resizable=0,width=500,height=500’);

}

Pretty “light” after all that stuff from Juxt Interactive, eh? By now it should

be obvious what this stuff means, but we’ll spell it out anyway because we really, truly love you

The double slashes //precede comments The comments help the author remember what each function is for The double slashes tell the browser to ignore these comments and proceed to the next function

The menu bar preload and subsequent changeImagesfunction are just another way of preloading images and creating image rollovers The images

in this case are referenced via relative URLs ( /glareon.gif), as explained in Chapter 8 It would have been smarter to use absolute URLs, but we never claimed to be all that bright

322 HOW: The Joy of JavaScript: Going Global with JavaScript

Get out of some idiot’s frameis a simple framebuster script, consisting of

just one line

if (top != self) { top.location = self.location; }

A third-party site might link to yours Sometimes that third-party site uses frames Sometimes those frames are poorly constructed Your site might load inside their frames instead of in its own window This line of JavaScript prevents that from happening In English, what it is saying is, “The HTML document referenced by this script should fill the browser window If it does, swell If it doesn’t, get rid of any extraneous frames and fill the browser window with our page, not some other jerk’s.” Of course JavaScript syntax is a bit more formal than that

The subsequent two functions are pop-up windows of varying dimensions

They are identical except for their dimensions and their names (The 640 x

480 window is named window6;the other is simply named window.) The parenthetical URL (url) is a variable If a pop-up window is needed on any HTML page that refers to this global JavaScript document, the address of the pop-up window will be inserted between the parentheses (popupwin-dow.html)

How do the HTML pages make use of this global JavaScript document? Just

as with global style sheets, they do it by referring to the jsfile with a link:

<script “”type=”text/javascript” src=”glam.js”></script>

The link appears inside the <HEAD>of each HTML document that requires these scripts

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

“http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd”>

<html>

<head>

<link rel=”StyleSheet” href=”glam.css” type=”text/css” media=”screen”>

<script “”type=”text/javascript” src=”glam.js”></script>

<title>Jeffrey Zeldman Presents: My Glamorous Life</title>

</head>

<body onLoad=”preloadImages(); window.defaultStatus=’Jeffrey Zeldman Presents.

➥Entertainment, free graphics, and web design tips since 1995.’”>

323 Taking Your Talent to the Web

Notice that the <BODY> tag includes these two onLoad functions:

preloadImagesand window.defaultStatus The first preloads the images as referenced in glam.js The second is our old friend, the default status bar message—the first snippet of JavaScript we learned in this chapter The two are combined in one onLoad declaration and separated by a semicolon Simple

There is so much that JavaScript can do This chapter barely hints at the possibilities, and some methods used in this chapter could be out of date

by the time you read this book

With the arrival of full support for ECMAScript and the DOM, the dynamic possibilities for websites will expand exponentially If you find, as some do, that you take naturally to JavaScript and want to learn more about the standardized version of JavaScript (ECMAScript) and the DOM:

■ The W3C offers the DOM at http://www.w3.org/DOM/ in all its baffling glory

■ WebReference’s “Doc JavaScript” (http://www.webreference.com/ js/) offers many fine articles covering ECMAScript, JavaScript, and the DOM

■ Peter-Paul Koch maintains a DOM mailing list (http://www.xs4all.nl/

~ppk/js/list.html)

■ The Web Standards Project maintains links to the latest ECMAScript and DOM resources, beginning at http://www.webstandards.org/ resources.html

And A List Apart (http://www.alistapart.com/) offers the Eisenberg DOM series, an ongoing tutorial that includes:

■ Meet the DOM: http://www.alistapart.com/stories/dom/

■ DOM Design Tricks: http://www.alistapart.com/stories/dom2/

■ DOM Design Tricks 2: http://www.alistapart.com/stories/domtricks2/

■ DOM Design Tricks 3: http://www.alistapart.com/stories/domtricks3/

324 HOW: The Joy of JavaScript: Learning More

Whether you tackle this advanced stuff now or crawl off to recover from reading this chapter, be proud of yourself You have faced your fears and

at least looked at the part of web design that most designers find

confus-ing and unintuitive This is mainly because, compared to Photoshop and

<p>paragraph tags, JavaScript is confusing and unintuitive

But with practice and experience, it will get easier And when browsers do

a better job of complying with ECMAScript and the W3C DOM, it will get

easier still The programming will not be easy, but you or your development

team will take comfort in the fact that you only have to code your site one way to work in all browsers

There is just a little more to learn before you can consider yourself a full-fledged (or at least a fledgling) web designer And by a strange coincidence, what you still don’t know is covered in the very next chapter Let’s go for

it, shall we?

325 Taking Your Talent to the Web

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

329 Taking Your Talent to the Web

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,

331 Taking Your Talent to the Web