[Archive copy mirrored from: http://xent.w3.org/FoRK-archive/spring97/0381.html]

The Web is Ruined and I Ruined It.

I Find Karma (adam@cs.caltech.edu)
Thu, 24 Apr 97 03:16:15 PDT


http://webreview.com/97/04/11/feature/index.html
is a cool little number by your friend and mine, Dave Siegel.

I love the paragraph:
> Separate all your content from its descriptive data (metadata, or
> markup), and the world suddenly gets interesting. You can see right
> through newspapers to the stock pages. You can compare movie reviews
> among 372 newspapers at once. You can search for Marx and find Karl, not
> Groucho, simply by filtering for the <PROMINENTSOCIALIST
> CLASS=MANIFESTOWRITER> tag.

Also:
> When Tim Berners-Lee talks about "inventing" the Web, he means that he
> came up with a few tags for writing physics papers and linking them
> together.

And yet it's 1997, and we still don't have math equation and formula tags!

> Companies like Organic grow quickly, taking advantage of the market
> for database-driven sites. The search engines, which can't see inside
> databases, break even more.

Plus, search engines are almost always a few months behind...

> Most of the content on the Web is garbage, and most of my content turns
> to garbage after some reasonably short period of time. Trying to find
> quality on the Web is like trying to find arable land in Antarctica.

Very eloquent.

> coming bookstore wars. Amazon.com will have a lot of competition. All of
> them will have great selection, service, and advice on what to buy. The
> battle will be fought on design and editorial content, plus extra
> services that make people feel special. This has nothing to do with
> "information," but everything to do with attracting and keeping
> customers. How much information does Nike give out about its products?

I disagree. I think ultimately, whoever has the most customized
information will win. The point that Nike gives out no information
about its products makes me never want to visit the site.

> We are waiting for something in between SGML and HTML. SGML is too
> general and too complicated for the Web. Instead, we need a junior
> version, and that's called XML. Just formulated in the fall of 1996, the
> ideas behind XML are good: To create a generalized markup language
> independent of presentation that works for most of the document types
> found on the Web. I'll talk about XML another time, but the early news
> is that Microsoft is interested and excited about taking HTML in this
> direction. In a few years, Microsoft Words' underlying data could be
> marked up in XML, but it's a bit far off to be making predictions like
> that (I just can't resist trying to tilt the playing field).

Wouldn't it be so precious if Microsoft co-opted XML?

> XML promises to be the Alexandria (I won't say Xanadu) of our digital
> desert dreams. It will let us build great libraries simply by building
> our own sites. It will let the average person put together very
> sophisticated and powerful applications, simply by tagging everything
> properly so it fits into the larger schema of the Web. Style sheets and
> the OBJECT model will provide the layout capabilities to make it look
> good. Then, in that future, we will have databases only to do what
> databases do best: Search for and compare 283 possible ways to get from
> San Francisco to Denver on July 3 for the lowest fare, find the best
> combination of 40,000 products for a particular visitor, or to do
> banking transactions. In this future scenario, Web sites will be big,
> flat, and tagged full of standard-compliant meta-data descriptions. Then
> the webmaster will tend, or farm, this flat Web site, using automated
> content-management tools to help keep it all up to date. Meanwhile, the
> search engines will grow more powerful every day and the average site
> builder will be able to participate. Radical, yes. You decide who is
> extreme.

Oh mannnn... this is so cool.

-----------------------8< ----------------------------------------

The Web is ruined and I ruined it. It's kaput. Over.

There's been a lot of talk in the newsgroups over the last 18 months
about a guy named David Siegel, the Web's foremost HTML terrorist. Why
do I get death threats in e-mail? Why do the so-called HTML "purists"
hate my guts? And why did the W3C invite me to sit on the committees
that shape HTML and style sheets? What kind of a snake pit is this? Have
I really ruined the Web, and if so, what is my punishment?

This article takes several thoughts from my upcoming book, the sequel to
Creating Killer Web Sites. It covers HTML and its evolution into a form
of nerd Nirvana, and just possibly a desirable distraction for
designers.

For the full story, simply go to www.dejanews.com and type in my name.
Or go to the comp.infosystems.www.authoring.html newsgroup and watch the
action first hand. Here's a bit of a response to the activity and a
challenge to you, the reader, at the end...

Part I: The Roots of HTML Terrorism

Some people say I've ruined the Web, and to them it's true. Web pages
can't be seen as easily by search engines and those with low-end
machines have a hard time getting much out of my site. On my personal
site, I don't even put ALT tags just to send a message to those surfing
without images. My life is visual. I love museums. How would you like
to visit the Louvre with images turned off?

I ruined the Web by mixing chocolate and peanut butter so they could
never become unmixed. I committed the hangable offense of mixing
structure with presentation, and in HTML and SGML circles, that's a big
no-no. The reason the HTML purists never carried out their threats is
not that they're against violence, it's that they know that if they kill
me, someone else will rise to take my place. It seems that structure and
presentation have been mixed forever, and the Web is in the fast lane of
the road to Hell. Fortunately, nothing on the Web is what it seems, and
"forever" lasts only about six months.

Structure vs Layout

First things first: Structure is markup. Markup is structure. To markup
a document is to describe its structure using metadata, also known as
tags. Tags were never meant to denote images or frames. Tags are meant
to describe contents, not presentation. For example, the <P> tag denotes
a paragraph (originally, HTML required a closing p-tag, </P>, but most
browsers ignored it, so it fell out of use). A tag would denote
something as a recipe, a movie review, a book title, a product
description, a grade, a headline, a bowling score, etc. Imagine all the
things that go into a newspaper. Properly tagged, you could apply a
layout engine, using a set of layout rules, to layout an entire
newspaper automatically. Not surprisingly, this kind of application is
exactly where SGML, the grandfather of HTML, came from.

Layout is presentation. Presentation is layout. Apply one set of layout
rules and get The New York Times. Apply another set and get The Village
Voice. Notice I am not talking about content! I'm talking about layout.
I'm writing this document in Microsoft Word. To tell you that The New
York Times is a newspaper title, I've used the italic feature, as any
good editor would. Now that you're reading it in HTML, someone has put
it between <I> and </I> tags, so now you're seeing the title in italics,
too. Blasphemy! How dare we use italics, when we mean
<newspapertitle>The New York Times</newspapertitle>, don't we? If we had
a <newspapertitle> tag, then people with 24x80 terminals in Zimbabwe
would see "The New York Times" rather than The New York Times, because
on a 24x80 terminal, you can't display italics. The browser itself adds
the quote marks -- they would not be part of the document. In this case,
the tag indicates meta-information, which the User Agent (also known as
a browser) interprets, however, it can on the target display. Similarly,
if this text were being spoken by a speaking browser for the blind (yes,
there are some -- and no, they're not very good), the <newspapertitle>
tag would be a signal to the program to pause and then emphasize the
name of the paper. Gripping, isn't it?

Let's take another example. A few sentences earlier, I wrote "they would
not be part of the document" in italics. Remember that? Did I mean
italics? Or did I really mean emphasis![italics mine] Oh, yeah, that's
what I meant, but I'm used to hitting the I key, not the <EM> key. Wow.
Are they that extreme, those HTML extremists er, I mean, purists? Yes,
they are that extreme. They can't believe everyone is using <I> for
italics when they really mean <EM>, for emphasis.

When Tim Berners-Lee talks about "inventing" the Web, he means that he
came up with a few tags for writing physics papers and linking them
together.

The Roots of HTML

Let's look at the sheer beauty of this argument for a second. Separate
all your content from its descriptive data (metadata, or markup), and
the world suddenly gets interesting. You can see right through
newspapers to the stock pages. You can compare movie reviews among 372
newspapers at once. You can search for Marx and find Karl, not Groucho,
simply by filtering for the <PROMINENTSOCIALIST CLASS=MANIFESTOWRITER>
tag.

In a perfectly tagged world, no one needs a search engine at her own
site. In a perfectly tagged world, the big search engines do all the
work for us, by searching the Web and storing not only the data, but
also the metadata. In a perfectly tagged world, we would standardize our
tags, so that everyone would use the same exact tag to denote a
<MOVIEREVIEW CLASS=HORROR>, or <RECIPE CLASS=VEGAN>. If one person
decided to use a tag called <MOVIEREVIEW> and another used one called
<FILMREVIEW>, the search engines would have a hard time keeping up with
all the new tags (are you listening, Marc Andreessen?). Hence, the need
for standardized markup (there I go again -- don't look at my source,
okay?).

Go one step further and say what kind of a document you are reading -- a
play, a newspaper, a PhD thesis, a recipe book, a journal -- and you
soon need to generalize the language to include the document type,
followed by the appropriate markup for that document type. Cookbooks
contain recipes, report cards contain grades, plays contain dialogue,
scene and action descriptions, and so forth. Standard tags for time
sensitivity let visitors choose whether they want to see only the most
recent content or see the last ten days' worth of material with every
page they visit.

Voila! I've just performed a magic trick: Now we know what SGML is --
Standard Generalized Markup Language. It's a difficult concept, because
the generalized part adds a layer of abstraction by first saying what
species of document you have, then adds the markup appropriate for that
species. Now that you understand it, you see where HTML came from. HTML
is a fairly weak, underpowered set of markup tags for marking up
hypertext physics papers. When Tim Berners-Lee talks about "inventing"
the Web, he means that he came up with a few tags for writing physics
papers and linking them together.

The Roots of HTML Terrorism

Just after Tim did his thing, a kid named Marc Andreessen came up with
the idea of the <IMG> tag, and the Web was both born and destroyed at
that moment. You see, Marc is the founding father of the HTML Terrorist
Guild, which now numbers in the thousands. As inventor of the <BLINK>
tag, Marc has done as much damage as I have with less effort. All I did
was take Marc's <IMG> tag a step further, to use single-pixel GIFs to
help layout a Web page. Seen from the perspectives of the SGML crowd,
this is about as far away from the beauty of the original argument as
one can get.

But it didn't stop there. I kept wanting to align my backgrounds and
foregrounds, forcing readers to see pages my way, not the way they
thought they wanted to see them.

Now let's return to the real world of the Web (not an oxymoron at all,
in case the thought just crossed your mind). The Web got where it is in
six easy steps:

Step one. The Framers of the Web mark up their papers on their NeXT
machines and put them on the first Web servers, delighted to be avoiding
FedEx charges to their limited particle-physics budgets. The <IMG> tag
makes the Web visual, and products like PageMill reinforce the
ugly-factor of first-generation sites.

Step two. I come along and start laying out pages visually, using HTML
(admittedly, a markup language, not a page-description language) as it
was never intended to be used. I pour narrative text into tables,
completely hosing the idea that tables should be used for tabular
material. My sites become popular. People start doing what I'm doing. I
write a book explaining how to do it, and it becomes the Amazon.com
number one best-selling book of 1996 in five months. The Web falls apart
quickly. The search engines can't tell a picture of Dolly Parton from a
picture of Dolly the sheep.

Step three. HTML changes so rapidly, and site maintenance becomes so
difficult, that large sites start using databases to serve up their
pages, separating the content from the HTML. Dynamic Web sites that cost
$300,000 to build become the norm. Companies like Organic grow quickly,
taking advantage of the market for database-driven sites. The search
engines, which can't see inside databases, break even more.

Step four. Microsoft comes to the aid of the W3C and puts some muscle
behind Cascading Style Sheets (CSS), for the sole reason that they are
what Netscape is not doing. Also, as it turns out, the people in
Microsoft's browser division saw that it was good to separate style from
markup, and they made a good choice. Internet Explorer 3.0 ships with
style-sheet capability. Few people write style sheets, but they are a
good step forward.

Step five. NetObjects Fusion, a product based entirely on my principles
(you can see my filenames in their code and I didn't get any NetObjects
stock -- what is it they say about imitation and flattery?). The
product takes a baby step toward becoming the first PageMaker of the
Web. Databases detect which browser you're using and serve sites
adjusted for all the different display bugs. Structurists see Fusion
sites being paired with databases and prepare to eat the sleepy
applesauce and lay down with purple shrouds over their heads.

Step six. Style sheets don't solve all layout problems, but they improve
typography greatly. Netscape announces a whole bunch of new tags to keep
people smoking their layout crack. Because Microsoft has aligned with
the W3C, Netscape tries to reinvent Director by putting lots of "dynamic
HTML" tags into their 4.0 browser. The design community isn't sure what
to do.

Keep in mind that the purists are protecting some pretty fetid ground.
Most of the content on the Web is garbage, and most of my content turns
to garbage after some reasonably short period of time. Trying to find
quality on the Web is like trying to find arable land in Antarctica. The
Web is a visual medium -- not to design is to design. Personally, I'd
rather leave the design up to professional designers than programmers,
but hey -- that's me. It's easy to be proud of your Web site. It's
another thing to have people say it was visually appealing and easy to
find everything.

Does that mean we should suck up to the smarmy <LAYER> tag and leave the
standards body behind?

Back to Reality

Here in the spring of 1997, I still have to use what works. My clients
want to win on the Web, so we employ the method used by more political
strategists: Image. We use great-looking sites and compelling
experiences to create equity on the Web for our clients. Example: The
coming bookstore wars. Amazon.com will have a lot of competition. All of
them will have great selection, service, and advice on what to buy. The
battle will be fought on design and editorial content, plus extra
services that make people feel special. This has nothing to do with
"information," but everything to do with attracting and keeping
customers. How much information does Nike give out about its products?
Not a lot. On the commercial side of the Web, design can make millions
of dollars of difference.

Does that mean Amazon.com should use every new gizmo and tag Netscape
provides? Does that mean we should suck up to the smarmy <LAYER> tag and
leave the standards body behind? I hope not. I support the standards
process. Right now, there is an interesting debate in the W3C over
something called the OBJECT model. It promises to give us active,
dynamic Web sites and still separate content from presentation. For some
odd reason, Netscape is actually being quite helpful and conciliatory in
this debate, and though we can't figure out why, we certainly see it as
a good sign for designers.

I can't say that much about the OBJECT model yet, because there are a
bunch of details to work out. Suffice to say it won't involve any new
tags, because tags are for markup, not layout. It will involve the use
of a special tag, called <DIV>, which we already use today in our work
with style sheets. (View the source of www.highfive.com to see our
current use of style sheets.) We expect both fifth-generation browsers
to incorporate the still-unapproved OBJECT model within a year.

We are waiting for PNG, the Portable Network Graphics format, to replace
GIF. Let's hope that by the end of the year most images on the Web are
PNG, with several levels of transparency and a much richer set of
extensions. It's been a political battle, but PNG is promising and it
will come. Add PNG images to your sites -- visitors using Netscape
Communicator will automatically download the PNG plug-in the first time
they encounter one. Let's hope they encounter lots of them. Perhaps
professional-quality image standards like LivePicture and Olivr will
take us even further in our quest for low-bandwidth quality.

We are waiting for vector graphics like Flash. Flash images will be
tiny. They will look great. They will be as close as you can get to
PostScript without making a PDF.

We are waiting for something in between SGML and HTML. SGML is too
general and too complicated for the Web. Instead, we need a junior
version, and that's called XML. Just formulated in the fall of 1996, the
ideas behind XML are good: To create a generalized markup language
independent of presentation that works for most of the document types
found on the Web. I'll talk about XML another time, but the early news
is that Microsoft is interested and excited about taking HTML in this
direction. In a few years, Microsoft Words' underlying data could be
marked up in XML, but it's a bit far off to be making predictions like
that (I just can't resist trying to tilt the playing field).

We will have to wait before the tools catch up. About two years ago, I
said the first halfway decent tools would appear in late 1997. I may get
lucky and be on track with that prediction. Then again, we may have to
wait a while longer. HTML isn't PostScript. It's hard to build tools
that don't suck on top of a set of standards being used in a giant
tug-of-war between big companies with millions at stake. Until good
tools exist, web designers will continue to be used as human shields in
the browser wars, with our customers being the big losers as they pay us
to make two separate versions of everything and serve HTML out of custom
databases.

Part II: Style Sheets: The Light at the End of the Tunnel

Let's take one thing at a time. If we're going to learn anything, it's
that style sheets are the future and tag-based layout is the past. What
can style sheets do? They can do a lot of typographic things, like set
your margins, indents, drop caps, leading, and other niceties invented
in the time of the Romans. No longer should we pour our text into
tables, for I have led us through the desert for 40 years (seemed like
it, anyway), and we have emerged in the promised land, where style
sheets give us the margins we seek. Sure, we still have to use tables to
lay out our pages, but in a year or so, we hope to give that up, too.
Say goodbye to the single-pixel GIF! Use it only when necessary! Ban
the kluges -- learn to use style sheets today!

Okay, maybe tomorrow.

Turns out that the Internet Explorer 3.0 version of style sheets is
pretty different from the 4.0 version, and the Netscape Communicator
version will likely have its differences. We will find the common
presentational behavior of both 4.0 browsers and use that. Stay tuned.
One thing you don't want to do is to commit style-sheet terrorism.
Style-sheet terrorism is where you use style-sheet capabilities by brute
force, mixing the style primitives right into your content, rather than
separating the content from the description of the presentation. Look at
Microsoft's Style Gallery. It's shameful. Look at both the code and with
Netscape Navigator 3.0. What's going on? To get a drop-shadowed "3,"
they've used the actual number two times -- once dark and once light --
positioned on top of each other. Not only that, but the number itself
is part of an ordered list -- the program should take care of the
numbering automatically! The style sheet should describe the behavior of
an ordered list in the absence of the list data. I repeat: There should
be no use of style sheets to effect typography that is bound to the
content. Style sheets must describe content that isn't there, then be
applied to content that is. If the style sheet doesn't give the intended
result, debug the style sheet, not the data.

Editors note: One can also set up Style Sheets to create a layout that
looks good in Navigator and Explorer, as shown here. [Netscape slide]
[MSIE slide]

When good ideas go bad: Style-sheet terrorism.

To be fair, the gallery was created last summer in a rush. The people
hired to make it were just playing around. But they didn't understand
the basic concept, and Microsoft let everyone see it as an example of
how to use style sheets, mostly because it looks awful in Netscape. If
you did it correctly, your pages would just look gray and dull in
Netscape, rather than all screwed up, and that would reflect badly on
Microsoft, hence the style-sheet terrorism.

The Big-Brother Issue

One of the central questions surrounding the use of style sheets is: Who
gets the final say over the look of a document? A small percentage of
the readership is colorblind, another group prefers larger type, and
others have special viewing requirements. Then there are alternative
surfing environments like Web phones, WebTV, and Web dishwashers. Each
has its own special browser and its own limitations. Aside from that,
issues of available typefaces, available colors, monitor size, and other
parameters affect the average surfer every day. Should there only be one
way to view a Web page?

My answer is simple: The designer should be able to specify how the page
looks under most conditions and give more (but perhaps not total)
control to the viewer as a last resort. In other words, designers should
be authoritarian, not dictatorial. Fortunately, that is roughly how
style sheets work. Style sheets can cascade, and that has two meanings,
so let me take them one at a time.

Style sheets can refer by name. A style sheet can include another style
sheet simply by naming it, specifying its absolute or relative location
on the Web. This lets us build a hierarchy of simple, middle, and more
complex style sheets without reinventing the wheel every time we write
one. As with Java, the lower-level libraries are just now being built
(by no one, actually, but we hope someone starts working on them soon).
Then we can write more complicated style sheets based on those and place
them on public servers. All you'll have to do to use a Dave Siegel style
sheet is include its name and location at the top of your file, and its
full functionality will apply to your document. Is that going to make
using style sheets easy? Yes. You won't have to write anything. You'll
just find the style sheets you like and specify them by name.

Style sheets have the capability to degrade gracefully. Today, you can
specify which fonts to use for which sections of a site, and if those
fonts aren't available, you can specify a second and third choice, and
so on. Style sheets go further. If a style sheet is well written, it
will contain instructions for what happens when you see a Web page under
optimal conditions (big screen, fast modem, lots of colors, etc.), then
how it should look under suboptimal conditions (256 colors, 14-inch
screen, slow modem), and also how it should look under lousy conditions
(WebTV, Microsoft CE, black-and-white screen, etc.). There aren't three
levels of cascade, there are as many as the designer can specify.

One of the most vexing things about this approach is that we still don't
have standard ways of learning how big or colorful people's systems are,
and this is a huge impediment to site designers. The W3C could have long
ago specified ways for people to fill out a little profile in their
browser, specifying, among other things, how many colors they have, how
large their screen is, whether they have sound capability, etc. There
are a lot of other Big-Brother issues surrounding profiles, but I'm a
strong believer that people will benefit by giving sites a bit of
information about themselves (demographics), their lifestyles
(psychographics), and their viewing systems (technographics). If the Web
is going to be free, it's a small price to pay for getting better
service. And anyway, if you don't specify a profile, you don't get the
benefit of it. No one would be forced to fill out a profile, but if most
people did, it would help sites degrade properly.

Finally, style sheets take the correct stance that the viewer should, in
the end, be able to specify her own style sheet for her own viewing. She
should be able to set up her browser (User Agent) so it always overrides
the designer's style sheets and substitutes her own. There should
actually be levels of override. It should be fairly hard to completely
throw out a designer's intended style sheet, but if she checks the box
marked "Hey, I really really really want to use my own damn style sheet,
okay?", then she should be able to get her way.

Unlike Marc Andreessen, I am in the process of turning in my black hat.

Turning in My Black Hat

Because both Marc Andreessen and I are HTML terrorists, we are jointly
responsible for the mess. Yet here our roads diverge. While Marc and his
pals have been slaving away deep in the Netscape laboratory to bring us
such visions of beauty as the <SPACER> tag and the <MULTICOL> tag -- and
now a new set of <LAYER> tags -- I am in the process of turning in my
black hat.

I am leaning toward structure. The hacks I've espoused, especially the
single-pixel GIF, and using frames and tables to do layout, are the duct
tape of the web. They are the designer's finger in the dam, trying to
keep the ugly gray sites where they belong -- at Yahoo, not in our
portfolios. Several of the things I've mentioned here are part of doing
it better.

Some day, the purists and I will see eye-to-eye, while Marc and company
keep on tagging, with lame excuses like: "Our customers demand interim,
tag-based solutions." Hogwash. When the browser manufacturers let us
separate content from presentation, we will gladly comply, for the
benefit of surfers everywhere. My personal priorities are that design
drives the train, because to hold an audience, you need good content
presented well. The best content poorly presented will lose to a better
idea hidden by dull presentation (presidential elections aside).

XML promises to be the Alexandria (I won't say Xanadu) of our digital
desert dreams. It will let us build great libraries simply by building
our own sites. It will let the average person put together very
sophisticated and powerful applications, simply by tagging everything
properly so it fits into the larger schema of the Web. Style sheets and
the OBJECT model will provide the layout capabilities to make it look
good. Then, in that future, we will have databases only to do what
databases do best: Search for and compare 283 possible ways to get from
San Francisco to Denver on July 3 for the lowest fare, find the best
combination of 40,000 products for a particular visitor, or to do
banking transactions. In this future scenario, Web sites will be big,
flat, and tagged full of standard-compliant meta-data descriptions. Then
the webmaster will tend, or farm, this flat Web site, using automated
content-management tools to help keep it all up to date. Meanwhile, the
search engines will grow more powerful every day and the average site
builder will be able to participate. Radical, yes. You decide who is
extreme.

Light at the end of the tunnel

You're not on the commercial side of the Web, you say? Then why
complain? Stick with your human-genome site and put helical horizontal
rules all over the place. Wait for the rest of us to catch up. When XML
hits, you'll be able to say, "I told you so." Until then, don't expect
many visitors. When we have better tools, we will use them. When HTML
evolves to the point that we no longer need to do browser detection or
dynamic page serving, we will do things simpler, and better. Until then,
we're going to go through another round of hacks where we put everything
into databases and serve pages from there. It won't help the search
engines at all. It will cost millions of dollars. It will all be totally
unnecessary. Don't look at me. Look at Netscape. They break the rules; I
just do what needs to be done. If I have ruined the Web, I apologize. It
was my intention all along. Many people like me have put design and
content ahead of structure, and now we can see a light at the end of the
tunnel. Netscape has blocked the way, but they may be coming around.
Site designers unite. Fight for presentation and structure. If we win,
our future will be so bright, we'll have to wear shades.

Don't look at me. Look at Netscape. They break the rules; I just do what
needs to be done.

The Challenge

We are working on a new book that we think will benefit developers
around the world. It is about the process of Web design and the
client/contractor relationship. If you are a client or a developer, we
have an online survey you can fill out. It covers salaries, estimating,
sales, pricing, hours, and client and contractor issues of interest. I
hope you'll come get our form and email it in, you'll help us provide
the community with this important information. If you fill it out, we'll
mail you the results ahead of publication in our book.

About the author:
David Siegel is a regular contributor to the High Five
(www.highfive.com). He is a member of the W3C's Font, Style, and HTML
committees. He is a founding member of Studio Verso, which designs and
produces high-end web sites for demanding clients around the globe.
Studio Verso most recently designed the W3C's "Made with Cascading Style
Sheets" logo, soon to be seen on web pages everywhere. Several dog-eared
copies of his book, "Creating Killer Web Sites," were found at the scene
of the Heaven's Gate cult suicide. He consults with many companies and
gives regular talks and workshops. His forthcoming book, on project
management, is due out in July. For more information, visit his sites at
www.verso.com and www.dsiegel.com.

----
adam@cs.caltech.edu

Leadership is not magnetic personality--
that can just as well be a glib tongue.
It is not 'making friends and influencing people'--
that is flattery.
Leadership is lifting a person's vision to higher sights,
the raising of a person's performance to a higher standard,
the building of a personality beyond its normal limitations.
-- Peter Drucker