http://xent.w3.org/FoRK-archive/winter96/0613.html
http://xent.w3.org/FoRK-archive/winter96/0619.html
...and it occurs to me that I'd better be careful when I say that I'd
like to see a book on Design Rules for Emerging Web Technologies,
because, as the following Stating the Obvious pieces indicate, this
name/phrase means different things to different people. [Yes, Rohit,
the naming problem comes to roost in everyday life yet again.]
Stating the Obvious knows exactly what I mean when I say "Design Rules
for Emerging Web Technologies", and shares my lament that no archival
book on constructing information spaces (with careful attention to the
specifics of the Web) exists:
> I'm not against well-designed pages. But what the web needs is fewer
> experts in page design and more experts in true site design. What
> seems to be lost on Siegel (and all the other authors of HTML how-to
> tomes) is the notion of architecting information. Where are all the
> books on how site designers can break out of the magazine metaphor?
> Where are all the books on how to manage large content archives
> efficiently? Where are all the books on how we can help users deal
> with thousands of channels of push media?
Where indeed! It's like a moral imperative for such a Web design book
to get written! Preferably by a W3C employee who's considered to be
somewhat of an authority on the issue.........
Along those lines, for those interested, I've included below 3 more
excerpts from Stating the Obvious about the subject, all of which are on
target. My comments are interspersed in between...
1. http://www.theobvious.com/archives/022497.html
> Yesterday, Sunday, I spent a few hours sitting in on a breakout session
> at Web97. Delivered by Mark Rettig and Dick Costolo, two folks from
> Digital Knowledge Assets, it was a two-day seminar on "Design for
> Emerging Web Technologies." The scale was a little unusual for me -- in
> my previous job I used to present at conferences to 50 people at a time
> stuffed in subdivided ballrooms, not to 300 people in an airplane hanger
> nearly 75 yards long. Yet Mark and Dick were able to hold the crowd,
> keep them involved, and wander through some, well, obvious territory.
>
> The topic, ostensibly, was how to design for technology like Pointcast,
> VRML, Java and JavaScript, and how to build community with chat or
> threaded discussion tools. But as I sat in the back of the room (near
> the power outlet), a few familiar phrases kept popping up...
>
> "...there needs to be a bare essentials list of features..."
> "...management wants to get their products out into the world..."
> "...don't have the lead designer or engineer involved in user testing..."
> "...issues related to cross-platform development..."
>
> Then it hit me. This session wasn't about design at all. It was about
> development. Software development. Somehow I'd been transformed from a
> severely hyped Internet conference to a mundane client/server software
> development conference. Requirements definition? Management
> expectations? Usability testing? Could it be that basic software
> development and product management tools are finally making their way
> to the web?
>
> If so, thank God. Because I know a web designer or two out there who
> could use a lesson in basic development management.
>
> The true technology content of the session was fairly close to nil.
> The topic was broad enough to cover basically very little of substance,
> and we were regaled with development anecdotes and stories about how
> they had trouble with a particular bug in JavaScript or the pitfalls of
> dealing with the Netscape color palette. The folks that were looking for
> a bit more meat were probably disappointed; I don't spend my time
> ironing out the differences between JavaScript and JScript, and I was
> even disappointed by the technology content.
>
> But the subtext they were delivering was right on the money. They
> discussed basic things like the "tradeoff triangle" of features, time
> and resources. They talked about how requirements need to be well
> defined up front in order to avoid "scope creep." And they talked about
> getting users involved at every step of the process, and aligning the
> project with the business objectives of the organization.
"software design" -- and not even interesting software design at that
(though the "tradeoff triangle" does sound vaguely familiar...).
page design"... argh! How tough *is* it to make people understand that
when I say "web design" I mean "design of webs" as in "designing
information spaces using WWW technologies"???
Note how Michael Sippey, author of Stating the Obvious, is right on
track in the assessment that what he really wants is insight into
website design, not web page design... also, though Dave Siegel is a
brilliant writer and designer, his design rules of thumb (among them,
color cube, anti-aliasing, gif compression, animation, jpeg compression,
eyeballing the palette, single-pixel gif trick, browser offsets, reduce
colors, and hand retouching) neither come close to providing insightful
design tips to improve performance (such as the one Rohit mentioned,
that compression techniques cause pages with lowercase markup to load
40% faster than pages with uppercase markup), nor to providing helpful
rules of thumb for taking a chunk of stuff and making best possible use
of {URL, HTML / Interactive Hypermedia / CSS, HTTP / CGI / Embeddable
Content} to provide a useful web presence to the public.
Clearly, a "Design Rules for Emerging Web Technologies" as I can
conceive it is not only useful, but presently nonexistent!
http://www.theobvious.com/archives/012797.html
> The latest in Siegel's little dominion of design is the hard copy
> "Creating Killer Websites: The Art of Third Generation Site Design,"
> published by Hayden Books. Siegel must have realized that the chance of
> actually making any money from a website hawking website design tips was
> somewhere between slim to none. Thus, the ironic turn to pulp to ply his
> HTML and image wrangling wares.
>
> The book is pretty, I'll give him that much. It's printed on heavy
> stock, and is chock full of helpful color wheels, clever HTML, and
> those jaw dropping "before and after" screen shots of Siegel
> makeovers. But as I paged through the book, I started getting that
> "all sugar, no substance" feeling that I usually associate with
> Hostess Twinkies. Here's a list of topics covered under the category
> "design tips:"
>
> color cube
> anti-aliasing
> gif compression
> animation
> jpeg compression
> eyeballing the palette
> single-pixel gif trick
> browser offsets
> reduce colors
> hand retouching
>
> It should be clear from the above list that Siegel's book is not about
> website design at all. Instead, it's about web page design - a
> completely different topic. Sure, the single-pixel gif trick may do
> wonders for indenting the first word of a paragraph, but it does
> nothing to help a web designer give users easy access to the
> information contained in their site.
>
> One of the fundamental tenets of database design is to keep your stores
> of information separate from any related processing or presentation of
> the information. That way, if the processing or presentation has to
> change, you don't risk having to redesign your information structure in
> order to accommodate the change.
>
> Something this simple would be lost on the aesthetics-happy Siegel. In
> "The Balkanization of the Web," a mammoth "essay" from Siegel on the
> past, present and future of information, exchange and entertainment,
> Siegel uses a 3 x 3 grid of colors as a map to the nine sections of
> his essay. The map muddles his (already muddled) message: we're more
> concerned with getting on to the next square of the tic-tac-toe board
> than grasping what Siegel has to say. It's almost as if Siegel
> designed the grid first, and fit the essay to it as an afterthought.
>
> One of the wonderful things about HTML is that it offers the
> opportunity for "structured" content. Structural tags like <head> and
> <body> and perhaps even <blockquote> help machines (like browsers and
> search engines) make sense of pages. But for Siegel, for whom
> white-space reigns supreme, structural tags are to be avoided like the
> plague. Forget the advantages of a browser-independent markup
> language like HTML, for everything Siegel does on the web "is a
> workaround to get back to the kind of typographic and visual control
> we have in more 'primitive' media. ... To say that all Web pages
> should be viewable by all browsers, including non-graphical ones, is
> to say there should be a pedestrian lane in the freeway."
>
> I'm not against well-designed pages. But what the web needs is fewer
> experts in page design and more experts in true site design. What
> seems to be lost on Siegel (and all the other authors of HTML how-to
> tomes) is the notion of architecting information. Where are all the
> books on how site designers can break out of the magazine metaphor?
> Where are all the books on how to manage large content archives
> efficiently? Where are all the books on how we can help users deal
> with thousands of channels of push media?
>
> "Site" designers will buy Siegel's book, and we'll see more
> single-pixel gifs, and more entry and exit tunnels, and more tables.
> Great. But I hope that someone is out there somewhere, writing
> "Creating Useful Websites: The Art of Fourth Generation Site Design."
http://www.theobvious.com/archives/020397.html
> Steve Champeon, who spends most of his time designing and implementing
> large-scale sites, wrote from North Carolina...
>
> I've been thinking about this very issue for some
> time now. I've had a few ideas on how to build good
> *sites*. You can find some core ideas in the
> article:
>
> http://www.bsginc.com/default/oopaper.htm
>
> I just got done reading "Information Architects", by
> Richard Saul Wurman (ed. Peter Bradford) and
> recommend it, but it doesn't do much for me re. site
> design. Example: the USAToday weather page. Cool,
> clean, crisp, informative, etc. But to do that on a
> web page they'd have to either use a graphic or a
> java applet.
>
> I'm more interested in the mechanics of large,
> scalable, manageable site architectures for
> document-centric systems - rather than data-driven
> systems. The only thing is, for the most part, I end
> up coming up with these clever solutions to
> problems, but when I try to explain *why* I'm doing
> it *this* way I get nothing but confused looks.
>
> Steve's article (linked above) is well worth the time. In it, he
> sanely argues that "rather that leaping headlong into the freedom that
> hypertext allows us, we should carefully consider the ways in which
> our documents and trees will need to be maintained, used, and reused."
Amen brother Steve!
> Jonathan Peterson, from IBM Interactive Media, chimed in with a desire
> for site-based tags...
>
> I like Siegel a lot actually as a designer. I have
> bookmarked his site as one of my favorite
> designhouses. That said though, the world of the web
> is full of print designers who are bright enough to
> make the transition to the web (and get paid much,
> much more in doing so).
>
> Unfortunately as you have pointed out all those
> beautiful web sites are not maintainable, and the
> designers have no knowledge of 3 tiered client
> server design to design something truely _useful_,
> not just pretty.
>
> The idea of actually _using_ structural tags is way
> past dead, unfortunately. People have come to expect
> print-quality design on websites and there is no way
> that the W3 can create new structural tags as
> quickly as designers will find needs. Netscape and
> Microsoft haven't helped with their competing
> non-standard tags. And you know that clever
> designers will always find a cool hack which
> accomplishes what they want. WSYWIG page editors
> only hide the problem by attempting to solve it at
> the ass-end.
>
> What the web NEEDS is a web SITE language. This
> language can maintain links, navigation, content and
> design as separate pieces. A designer can then
> completely change the look of a site as needed. A
> simple "re-compilation" of the site will roll the
> new look out without breaking any funcionality. Use
> of server side includes, SHTM, WebObjects and other
> tools attempt this, but none have done it
> completely. I can't imagine that there aren't some
> smart guys out there building such a thing. I just
> hope that the W3 gets its hands on it early so it
> is clean, open and extensible.
>
> David Siegel himself actually may have a role to play in creating a
> site language, since he's on the W3C committee. It was his feedback on
> the piece that prompted me to turn this into "front page" news. His
> first missive went like this...
>
> As you can imagine, I've read your piece. Nice of
> you to mention me. I'm just wondering why you forgot
> to mention my chapters on site structure, make sites
> not pages, PDF, and style sheets? Was it because
> Push Media was only a press release at the time I
> submitted the manuscript that you criticize me for
> not saying how to design for it?
>
> You made your point, though not constructively. You
> didn't mention that my book was Amazon.com's number
> one best-seller for 96 and what you thought of that,
> or that I have designed Hewlett Packard's annual
> report on line, and you didn't bother to explain the
> concept of third-generation sites and what you think
> of the idea, which makes me wonder if you really
> read the book. Next time, perhaps read the whole
> thing before writing your review would make your
> material more useful to your readers.
>
> This is basically how I responded to Siegel, with the pronouns edited
> for readability...
>
> As I wrote last week, my issue with the book is that it's primary
> focus is on page design, not site design. The particular examples I
> used from the book, the site http://www.killersites.com/, and his
> other sites, illustrate this point. For example -- structural tags may
> offend Siegel as a typographer and graphic designer, but as an
> efficient way to classify and organize information, they're crucial.
> As for push media, I don't blame Siegel for not having it in his book,
> but I don't see him dealing with it on his sites, either.
>
> Finally, the fact that the book was an Amazon best seller is somewhat
> beside the point. Not only is the Amazon audience self-selecting, but
> readers may have actually been looking for a tome on site design, not
> single-pixel gifs.
>
> Siegel responded briefly...
>
> Thanks for being considerate. I thought it was
> unfair of you not to mention that my book was the
> first to mention style sheets. Did you know I've
> been on the W3C HTML and STYLE committees for over a
> year? We are committed to style sheets and
> structured documents as long as design of the user
> experience comes first. For now, that means we're
> spitting browser-detected HTML out of databases, but
> when we have XML we'll be able to add structure
> without destroying the look-and-feel that we think
> is so important.
>
> Style sheets may help designers deal with large sites...but will they
> help users? Sure, it may be true that when a site designer has a
> better grip on their site structure, they'll be better prepared to
> present information to their users. But the key to successful site
> design will be taking into account the needs of the user, and the way
> they want to use the information contained in your site. And remember
> -- users may not be looking at sites with 800 x 600 displays with
> millions of colors.
The utility to the end users has to be clear from the get-go.
I believe it, I do I do I do.
----
adam@cs.caltech.edu
In honor of FoRK passing 2500 posts, you win a .sig bonus: the quintuple-play!
Anything that is designed to do more than one thing can't do any of them well.
-- Rohit Khare
Like Unix, C++ was never designed, it MUTATED as one goofy mistake after
another became obvious. It's just one big mess of afterthoughts....
Face it: it takes thinking and real effort to redesign and build
something over from scratch.
-- Unix-Haters Handbook
NCSA's httpd is the leader in problems because it was developed under
heavy pressure by somebody who didn't expect it to get as big as it did,
and because that somebody made some really poor design decisions.
-- Rob McCool
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies.
-- C.A.R. Hoare
You must be the sort of person who can see the glamor in any project if
it has an elegant design. You must be the sort of person who finds bad
design physically nauseating.
-- William Shipley, Omni Group