![]() |
Chapter 5: Learn to Program HTML in 21 Minutes![]() |
I tell this story to my friends who ask me for help in building their static HTML Web sites: "The abused 10-year-old got his site to work; I think you can, too."
If they persist, I tell them to find a page that they like, choose Save As in Netscape, then edit the text with the editor of their choice. I've never known anyone who couldn't throw together a simple page in under 21 minutes.
This was my big moment; I was being introduced to the one man in the world with enough power to fix everything wrong with the Web standards. I was sure that Dertouzos would tell him what a computer science genius I was. He was going to talk about my old idea to add semantic tags to HTML documents, about the work I'd done to make medical record databases talk to each other to support Internet-wide epidemiology, about all the collaboration systems I'd built that hundreds of Web sites around the world were using.
"This is Philip Greenspun," the lab director began, "one of our local webmasters."
Yeah.
Anyway, part of a real webmaster's job is to assist new users in getting their pages together. So in that spirit, here is my five-minute HTML tutorial.
My Samoyed is really hairy.
That is a perfectly acceptable HTML document. Type it up in a text editor, save it as index.html, and put it on your Web server. A Web server can serve it. A user with Netscape Navigator can view it. A search engine can index it.
Suppose you want something more expressive. You want the word really to be in italic type:
My Samoyed is <I>really</I> hairy.
HTML stands for Hypertext Markup Language. The <I> is markup. It tells the browser to start rendering words in italics. The </I> closes the <I> element and stops the italics If you want to be more tasteful, you can tell the browser to emphasize the word really:
My Samoyed is <EM>really</EM> hairy.
Most browsers use italics to emphasize, but some use boldface and browsers for ancient ASCII terminals (e.g., Lynx) have to ignore this tag or come up with a clever rendering method. A picky user with the right browser program can even customize the rendering of particular tags.
There are a few dozen more tags in HTML. You can learn them by choosing View Source from Netscape Navigator when visiting sites whose formatting you admire. This is usually how I learn markup. You can learn them by visiting http://photo.net/wtr/ and clicking through to one of the comprehensive online HTML guides. Or you can buy HTML: The Definitive Guide (Musciano and Kennedy, O'Reilly, 1997).
Another structure issue is that you should try to make sure that you close every element that you open. So if your document has a <BODY> then it should have a </BODY> at the end. If you start an HTML table with a <TABLE> and don't have a </TABLE>, Netscape Navigator may display nothing. Tags can overlap, but you should close the most recently opened before the rest, e.g., for something both boldface and italic:
My Samoyed is <B><I>really</I></B> hairy.
Something that confuses a lot of new users is that the <P> element used to surround a paragraph has an optional closing tag </P>. Browsers by convention assume that an open <P> element is implicitly closed by the next <P> element. This leads a lot of publishers (including lazy old me) to use <P> elements as paragraph separators.
Here's the source HTML from which I will usually start out a Web document:
<html> <head> <title>New Doc</title> </head> <body bgcolor=white text=black> <h2>New Doc</h2> by <a href="http://photo.net/philg/">Philip Greenspun</a> <hr> introductory text <h3>First Subhead</h3> more text <p> yet more text <h3>Second subhead</h3> concluding text <hr> <a href="mailto:philg@mit.edu"> <address>philg@mit.edu</address> </a> </body> </html>
Let's go through this document piece by piece (see
for how it looks rendered by a browser).
The <HTML> element at the top says "I'm an HTML document". Note that this tag is closed at the end of the document. It turns out that this tag is unnecessary. We've saved the document in the file "basic.html". When a user requests this document, the Web server looks at the ".html" extension and adds a MIME header to tell the user's browser that this document is of type "text/html".
I put in a <HEAD> element mostly so that I can legally use the <TITLE> element to give this document a name. Whatever text I place between <TITLE> and </TITLE> will appear at the top of the user's Netscape window, on his Go menu, and in his bookmarks menu should he bookmark this page. After closing the head with a </HEAD>, I open the body of the document with a <BODY> element, to which I've added some parameters to manually set the background to white and the text to black. Some Web browsers default to a gray background, and the resulting lack of contrast between background and text offends me so much that I change the colors manually. This is a violation of most of my principles since it potentially introduces an inconsistency in the user's experience of the Web. However, I don't feel too guilty about it because (1) a lot of browsers use a white background by default, (2) enough other publishers set a white background that my pages won't seem inconsistent, and (3) it doesn't affect the core user interface the way that setting custom link colors would.
Just below the body, I have a headline, size 2, wrapped in an <H2> element. This will be displayed to the user at the top of the page. I probably should use <H1> but browsers typically render that in a font too huge even for my bloated ego. Underneath the headline, I'll often put "by Philip Greenspun" or something else indicating authorship, plus perhaps a link to the full work. The phrase "Philip Greenspun" is a hypertext anchor which is why it is wrapped in an A element. The <A HREF= says "this is a hyperlink." If the reader clicks anywhere from here up to the </A> the browser should send him to http://photo.net/philg/.
After the headline, author, and optional navigation, I put in a horizontal rule tag: <HR>. I wish I could say that the best thing I'd learned from Dave Siegel was how to reel in women via a popular Web site (see http://philip.greenspun.com). Unfortunately, the only thing of practical value that I learned was not to overuse horizontal rules: Real graphic designers use whitespace for separation. I use <H3> headlines in the text to separate sections and only put an <HR> at the very bottom of the document.
Underneath the last <HR>, I sign my document with "philg@mit.edu" (my email address, unchanged since 1976). The <ADDRESS> element usually results in an italics rendering. I think that all documents on the Web should have a signature like this. Readers expect that they can scroll to the bottom of a browser window and find out who is responsible for what they've just read. Note that this one is wrapped in an anchor tag. If the user clicks on the anchor text (my email address), the browser will pop up a "send mail to philg@mit.edu" window. I think it is almost always bad to publish an email address on a Web page and not wrap it in a "mailto" tag.
Each line of the style sheet gives formatting instructions for one HTML element and/or a subclass of an HTML element. My first directive is to tell browsers not to separate paragraphs with blank lines ("margin-top: 0 pt"), but rather simply to indent the first line of a new paragraph by 0.2 inches (I tried "3em" but it didn't look right). So now my paragraphs will be mushed together like those in a printed book or magazine. Books and magazines do sometimes use whitespace, however, mostly to show thematic breaks in the text. I therefore define three classes of thematic breaks and tell browsers how to render them. The first, "stb" (for "small thematic break") will insert 12 points of white space. A paragraph of class "stb" will inherit the 0.2 inch first-line indent of the regular P element. For medium and large thematic breaks, I specify more whitespace and override the first-line indent.P { margin-top: 0pt; text-indent : 0.2in } P.stb { margin-top: 12pt } P.mtb { margin-top: 24pt; text-indent : 0in} P.ltb { margin-top: 36pt; text-indent : 0in} p.marginnote { background-color: #E0E0E0 } p.paperonly { background-color: #E0E0E0 } li.separate { margin-top: 12pt }
How do I use this style sheet? I park it somewhere among my pages in a file with the extension ".css". This extension will tell the Web server program to MIME-type it "text/css". Personally, I chose to place this cascading style sheet right at the top level of my Web content directory because I think that I will eventually use it for all of my writing. Inside each document that uses the cascading style sheet, I put the following LINK element inside the document HEAD, just above the TITLE:
Note the leading "/" at the beginning of the HREF. This causes the user's browser to come back and request "http://www.arsdigita.com/books/philg.css" from my server before rendering any of the page. Note that this will slow down page viewing a bit, although if all of my pages refer to the same site-wide style sheet, users' browsers should be smart enough to cache it. If you read 17 chapters from this book on-line with Netscape Navigator 4.0, the browser would request the philg.css style sheet only once.<LINK REL=STYLESHEET HREF="/books/philg.css" TYPE="text/css">
Okay, now the browser knows where to get the style sheet and that a small thematic break should be rendered with an extra bit of whitespace. How do we tell the browser that a particular paragraph is "of class stb"? Instead of "<P>", we use
right before the text that starts a new theme.<P CLASS="stb">
Book designers have all kinds of clever ways of setting off margin
notes, body notes, and footnotes. But I'm not a book designer, so I
just defined a couple of styles that get rendered with a gray background
("p.marginnote { background-color: #E0E0E0 }"
). This
alerts readers that margine notes aren't part of the main text.
My final new subclass ("li.separate { margin-top: 12pt }
")
was directed at making lists with whitespace between each bullet item.
It worked nicely in Internet Explorer 4.0 but failed in Netscape
Navigator 4.0 so I don't use it (instead I use two line-break tags,
<BR><BR>
).
For a complete guide to all the Cascading Style Sheet directives, look in HTML: The Definitive Guide and/or check the on-line guides that I reference from http://photo.net/wtr/.
"Owing to the neglect of our defences and the mishandling of the German problem in the last five years, we seem to be very near the bleak choice between War and Shame. My feeling is that we shall choose Shame, and then have War thrown in a little later, on even more adverse terms than at present."HTML represents the worst of two worlds. We could have taken a formatting language and added hypertext anchors so that users had beautifully designed documents on their desktops. We could have developed a powerful document structure language so that browsers could automatically do intelligent things with Web documents. What we actually have with HTML is a hybrid: ugly documents without formatting or structural information.
-- Winston Churchill in a letter to Lord Moyne, 1938 (Churchill: A Life; Gilbert 1991)
Eventually the Web will work like a naïve user would expect it to. You ask your computer to find you the cheapest pair of blue jeans being hawked on the World Wide Web and ten seconds later you're staring at a photo of the product and being asked to confirm the purchase. You see an announcement for a concert and click a button on your Web browser to add the date to your calendar; the information gets transferred automatically. More powerful formatting isn't far off, either. Eventually there will be browser-independent ways to render the average novel readably.
None of this will happen without radical changes to HTML, however. We'll need semantic tags so that publishers can say, in a way that a computer can understand, "This page sells blue jeans," and "The price of these jeans is $25 U.S." Whether we need them or not, we are sure to get new formatting tags with every new generation of browser. (Personally I can't wait to be able to caption photographs and figures, a common feature of word processing programs in the 1960s.)
Back in 1994, so long ago that I still believed an academic conference was an effective way to distribute an idea, I wrote a paper titled "We have Chosen Shame and Will Get War" (http://photo.net/philg/research/shame-and-war.html) presenting a scheme for embedding semantic markup in HTML documents so that it wouldn't break old browsers (e.g., NCSA Mosaic!). More importantly, I suggested that we needed to develop a common set of document classes, e.g., "advertisement", "novel", "daily-newspaper-article", so that programmers could write software to make life easier for authors and readers.
My idea was too brilliant, radical, and forward-looking for its time. The idea of semantic markup in documents had barely been tested. Charles Goldfarb, Raymond Lorie, and Edward Mosher tried it out in 1969 with Generalized Markup Language (GML). They got their company to use it for about 90 percent of its document production. But this was only at one little company so not too many Web standards experts would have noticed. Oh yes, the company name was "International Business Machines."
The American National Standards Institute (ANSI) published its first draft of Standard Generalized Markup Language (SGML) in 1980. A few small organizations, such as the United States Department of Defense, the Internal Revenue Service, and the Securities and Exchange Commission, began using the semantic markup features of the new language.
The most bizarre thing about HTML is that it borrows the (uninteresting) syntax of SGML:
but it doesn't have the (interesting) semantic markup or document type definition capability of SGML.<element> ... stuff being marked up ... </element>
As a Web publisher and Web user, it seemed natural to me that the folks who set the Web standards would see the importance of semantic markup and machine processing of documents on behalf of users. A student of Max Weber, however, would not have been surprised that my paper was rejected and that the whole semantic markup issue was ignored for six years. People who write Web standards and go to Web conferences are not doing it because they have a passion for Web publishing or Web surfing. They have a passion for sitting on conference committees, sitting on standards committees, and escaping the boredom of their hometowns by going on company-paid trips to wherever these committee meetings happen to be taking place (note that nobody ever points out the absurdity of putative Internet experts physically flying their bodies around the globe rather than using some kind of db-backed Web site and video conferencing to support collaboration). The people who are passionate about publishing are busy building on-line magazines and services. The people who are passionate about surfing are at home with their cable modems.
It has been four years since I wrote my "Shame and War" paper. Has there been any progress since then? Yes and no. The Extensible Markup Language (XML) is being standardized by the World Wide Web Consortium (W3C). Described by Dan Lyke as "the subset of SGML that Microsoft's developers could understand", XML addresses the need for semantic markup but not the requirement that publishers agree on a common set of classes for semantic markup to be useful. With XML, each publisher or community of publishers can agree on some new document types and concomitant sets of tags. Microsoft and Netscape have agreed to make their browsers render XML. A variety of server-side tools are becoming available for parsing XML, generating XML from databases, converting XML to HTML, and authoring XML.
If you are publishing structured data, does it make sense to use HTML or XML files? Neither. XML will let you store and exchange structured data. But that doesn't mean it addresses the same problems as database management systems. With XML, you can certainly keep a catalog of products for sale in a file system directory and easily write a computer program to pull out the price of an item. But you can't easily build an index to facilitate rapid retrieval of all the blue items or all the items available in size 6. XML lets you store how many items are left in inventory but you won't get any support for writing a program that subtracts 1 when an order is placed (and, more importantly, making sure that 10 simultaneous subtractions from different users won't collide). An XML document is like one record in a database management system. XML is therefore useful if you want to ship a record from one database to another, but it doesn't really help you build the entire database.
If I were publishing structured information, I would keep the information in a database and write scripts to generate either HTML or XML pages. Then I wouldn't have to edit 1,000 XML or HTML files when either the language standards or my publishing requirements changed. A "database"? Does that mean a scary huge relational database management system as discussed later in this book? No. If you aren't updating your data in real-time, an ordinary text file is fine.
For example, suppose that you are putting a company phone directory on the Web. You can define a structured format like this:
first name|last name|department|office number|home number|location
There is one line for each person in the directory. Fields are separated by vertical bars. So a file at MIT might look like this:
Philip|Greenspun|eecs|253-8574|864-6832|ne43-414 Rajeev|Surati|athletics|253-8581|555-1212|dupont gym ...
When the XML wave hits and someone comes up with a document type for
phone listings, you can generate a set of private and public XML files
containing names and phone numbers. People downloading an XML file will
be able to tell their computer to dial the phone number automatically,
since the number will be encased in a VOICE_PHONE_NUMBER
element.
The high level message here is that you should think about the structure of the information you are publishing first. Then think about the best way to build an investment in that structure and preserve it. Finally, devote a bit of time to the formatting of the final HTML or XML that you generate and ship to users over the Web.
CD-ROMs are faster, cheaper, more reliable, and a more engaging audio/visual experience than the Web. Why then do they sit on the shelf while users greedily surf the slow, unreliable, expensive Web? Stability of user interface.
There are many things wrong with HTML. It is primitive as a formatting
language and it is almost worthless for defining document
structure. Nonetheless, the original Web/HTML model has one big
advantage: All Web pages look and work more or less the same. You see
something black, you read it. You see something gray, that's the
background. You see something blue (or underlined), you click on it.
When you use a set of traditional Web sites, you don't have to learn anything new. Every CD-ROM, on the other hand, has a sui generis user interface. Somebody thought it would be cute to put a little navigation cube at the bottom right of the screen. Somebody else thought it would be neat if you clicked on the righthand page of an open book to take you to the next page. Meanwhile, you sit there for 15 seconds feeling frustrated, with no clue that you are supposed to do anything with that book graphic on the screen. The CD-ROM goes back on the shelf.
The beauty of Netscape 2.0 and more recent browsers is that they allow the graphic designers behind Web sites to make their sites just as opaque and hard to use as CD-ROMs. Graphic designers are not user interface designers. If you read a book like the Macintosh Human Interface Guidelines (Apple Computer, Inc.; Addison-Wesley, 1993), you will appreciate what kind of thought goes into a well-designed user interface. Most of it has nothing to do with graphics and appearance. Pull-down menus are not better than pop-up menus because they look prettier; they are better because you always know exactly where to find the Print command.
Some of the bad things a graphic designer can do with a page were possible even way back in the days of Netscape 1.1. A graphic designer might note that most of the text on a page was hyperlinks and decide just to make all the text black (text=#000000, link=#000000, vlink=#000000). Alternatively, he or she might choose a funky color for a background and then three more funky colors for text, links, and visited links. Either way, users have no way of knowing what is a hyperlink and what isn't. Often designers get bored and change these colors even for different pages on the same site.
Here's a concrete example of how graphic design stupidity can cost the
site owner money. I ordered an Internet cable modem from MediaOne, the
cable TV monopoly in Cambridge, Massachusetts. It turned out to be only
$10 a month extra for cable TV so I asked for that also. The folks who
installed everything did not leave me a channel card so if a friend of
mine said "Let's watch Beavis and Butthead on MTV," we had no
way of knowing which channel to type into the TV remote. "No problem,"
I said confidently. "I'll just print one out from the MediaOne Web
site." MediaOne had just paid the huge bucks to a fancy New York Web
design firm for a complete site makeover so naturally it was slow and
painful to navigate to the channel line-up page. But we got there
eventually and printed the document to my home HP Laserjet. The page
was blank because the graphic artistes had chosen white text on a blue
background. Netscape Navigator prepared a file for the printer with
white text on a white background. So I called MediaOne (they paid for
the call to their toll-free number) and they paid someone to grab a
channel card (that they'd previously paid to have printed) and stick it
into an envelope (which they paid for) and stamp the envelope and mail
it to me.
Frames are probably the worst Netscape innovation yet. The graphic designer, who has no idea what size or shape screen you have, is blithely chopping it up. Screen space is any user's most precious resource and frames give the publisher the tools to waste most of it with ads, navigation "aids," and other items extraneous to the document that the user clicked on. What's worse, with Netscape Navigator 2.0, when the user clicked on the Back button to undo his last mouse click, Navigator would undo hundreds of mouse clicks and pop him out of the framed site altogether. Newer Web browsers handle frames a little more gracefully, but none of them handle scrolling as well as NCSA Mosaic did in 1993. In the old days, any Web site that brought up scroll bars could be scrolled down with a press of the space bar. With frames, even if there is only one scroll bar on screen, the space key does nothing until you click the mouse in the subwindow that owns the scroll bar.
I'm not saying that there isn't a place in this world for pretty Web
sites. Or even that frames cannot sometimes be useful. However, the
prettiness and utility of frames must be weighed against the cold shock
of unfamiliar user interface that greets the user. This comparison
is very seldom done and that's a shame.
"I'm glad to hear that your company is so profitable," I responded. "I guess since you're able to hire 50 tech support people for your Web site then you must be raking in the bucks."
"What do you mean 50 tech support people?!?!" he asked.
"If people can't get a plug-in to work on their Windows 3.1 machine or can't figure out how to record from a microphone on their Windows 95 then I'm sure you must have a plan for dealing with all the support emails that they'll be sending to your webmaster," I said.
"Uh... well, I guess we have to think about that...," he mumbled as he wandered off.
Before you spend money on animation, Java, or authoring content for a plug-in, think about whether you couldn't buy the on-line rights to an interesting book on your Web site's subject. Remember that AltaVista doesn't recognize images or Java applets or graphic design. It only indexes text. So that on-line book is going to pull a tremendous number of people into your site.
Maybe you have infinite money and can buy the book plus a raft of multimedia authors. It still might be worth remembering what brought users to the Web in the first place: control and depth. Software like Java and Shockwave enables you to lead users around by the nose. Flash them a graphic here, play them a sound there, roll the credits, and so on. But is that really why they came to your site? If they want to be passive, how come they aren't watching TV or going to a lecture?
This may seem like an obvious point, but I mention it because I've seen so many tools to convert PowerPoint presentations into Web sites. The whole point of a ViewGraph-based presentation is that you have a room full of people all of whose thoughts have to be herded in a common direction by the speaker. Ideas are condensed to the barest bones because there is such limited time and space available and because the speaker is going to embroider them. The whole point of the Web is that each reader finds his own path through a site. There is unlimited time and space for topics in which the reader has a burning interest.
A Java applet can make a good site great in the following situations:
Suppose I'm doing a mundane camera ownership survey. If the user owns a point-and-shoot camera, it doesn't make sense to ask which accessory lenses and flashes he owns. However, if he says, "I have a Nikon 8008," then I'd like to present a list of Nikon flash model numbers as options. I can do this now by essentially asking one question per HTML form. The user says, "I own an SLR (Single Lens Reflex)," then submits that form, "I own a Nikon" then submits that form, "I own an 8008" then submits that form, and my server finally generates the appropriate accessory flash form.
With a Java applet, the user's choice on the P&S/SLR menu will affect the choices available on the camera brand menu which in turn will affect the choices available on the camera model menu. Is this better? It will take longer to download. Not only do you have to send the user the Java byte codes but also all the text that you have in your database of camera models, only a small portion of which will ever be presented. On the plus side, the user can work in another window while the applet is downloading and, once loaded, the applet is much more responsive than a succession of forms.
Don't get too excited by the possibility of offering a rich custom user interface with Java. Adobe PhotoShop has a beautiful user interface but it took Adobe hundreds of person-years to perfect it. It takes Adobe hundreds of person-years to test each new version. It costs Adobe millions of dollars to write documentation and prepare tutorials. It takes users hours to learn how to use the program. You don't have a huge staff of programmers to concentrate on a single application. You don't have a full-time quality assurance staff. You don't have a budget for writing documentation and tutorials. Even if you did have all of those things, your users don't have extra hours to spend learning how to use the Web site that you build. Either they are experienced Web users and they want something that works like other sites or they are naïve users who want their effort in learning to use Netscape and your site to pay off when they visit other sites.
You would not want to use a drawing tool that needed to go out to the network to add a line. An HTML forms-based game might be fun for your brain but it probably won't have the visceral excitement of Doom. Any thing remotely like a video game requires code executing on the user's local processor.
Note: There actually is a Doom-like game implemented as a Java applet: Frag Island. You can play it at http://hem.passagen.se/carebear/fraggame.ht.
<META HTTP-EQUIV=REFRESH CONTENT="60; URL=update.cgi">
The user's browser will fetch "update.cgi" 60 seconds after grabbing the page with this element.
I've been working for a few years with some folks from Boston Children's Hospital. We started back in 1994 by writing a Web interface to the hospital's 60 GB Oracle database. As soon as browsers started to support Java applets, my collaborators got the idea to broadcast real-time waveforms from the intensive care unit out to physicians over the Internet. You can play with this at http://www.emrs.org/.
"Java on the client doesn't work, and we at Netscape have done an about-turn on client-side Java in recent months."Java is often promoted as a safe and reliable language. Unfortunately, since those safe and reliable Java applets run on top of the unreliable substrate of Java Virtual Machine + Java window system, it is inevitable that your Java applet will eventually crash the user's browser. Plug-ins have similar drawbacks. You should read the chapter on server-side programming and think about whether you can't do everything with programs that run on your server.
-- Marc Andreessen, VP Products at Netscape (Quoted in a trade journal, July 1998)
Siegel is making some implicit assumptions: that there are no users with text-only browsers; that users have a fast enough Net connection that they won't have to wait 45 seconds before getting to the content of a site; that there are no users who've turned off auto image loading; that there is some obvious place to put these tunnels on a site with thousands of pages. Even if all of those things are true, if the internal pages do indeed contain any content, AltaVista will roar through and wreck everything. People aren't going to enter the site by typing in "http://www.greedy.com" and then let themselves be led around by the nose by you. They will find the site by using a search engine and typing a query string that is of interest to them. The search engine will cough up a list of URLs that it thinks are of interest to them. AltaVista does not think a Dave Siegel "entry tunnel" is "killer". In fact, it might not even bother to index a page that is just one GIF.
AltaVista is going to send a user directly to the URL on your server that has the text closest to the user's query string. AltaVista doesn't care that your $125 an hour graphic designer thought this URL should be one-third of a frame. AltaVista doesn't care that the links to your home page and related articles are in another subwindow.
If you intend to get radical by putting actual content on your Web server, then it is probably a good idea to make each URL stand on its own. Making a URL stand on its own has implications for site navigation design. Each document will need a link to the page's author, the service home page, and the next page in a sequence if the document is part of a linear work. Remember, the Web is not there so that publishers can impose what they think is cool on readers. Each reader has his own view of the Web. Maybe that view is returned by a search engine in response to a query string. Maybe that view is links from a friend's home page. Maybe that view is a link from a personalization service that sweeps the Internet every night to find links and stories that fit the reader's interest profile.
Our task as Web publishers is to produce works that will fit seamlessly not into the Web as we see it, but into the many Webs that our readers see.
"Time how long it takes to download the home page."
63 seconds. "Now time how long it takes to get the first results back from a search."
90 seconds.
"What do you guys plan to do about this?" asked the president.
"Uh... Well.. we could get a faster server," responded the Web expert.
"Great. Thanks. You're all fired."
My friend was specifically asked by the president to do a site with no animation and no Java. The focus would be entirely on a fast search of a server-side database.
Are there general design principles that can be applied to different kinds of Web applications? I've found two.
One of the things that users love about the Web is the way in which computation is discretized. A desktop application is generally a complex miasma in which the state of the project is only partially visible. Despite software vendors having added multiple-level Undo commands to many popular desktop programs, the state of those programs remains opaque to users.
The first general principle is Don't break the browser's Go menu. Users should be able to go forward and back at any time in their session with a site. For example, consider the following flow of pages:
The second general principle is Have users pick the object first and then the verb. For example, consider the customer service area of an ecommerce site. Assume that Jane Consumer has already identified herself to the server. The merchant can show Jane a list of all the items that she has ever purchased. Jane clicks on an item (picking the object) and gets a page with a list of choices, e.g., "return for refund" or "exchange". Jane clicks on "exchange" (picking the verb) and gets a page with instructions on how to schedule a pickup of the unwanted item and pages offering replacement goods.
How original is this principle? It is lifted straight from the Apple Macintosh circa 1984 and is explicated clearly in Macintosh Human Interface Guidelines (Apple Computer, Inc.; Addison-Wesley, 1993). Originality is valorized in modern creative culture but it was not a value for medieval authors and it does not help users. The Macintosh was enormously popular to begin with and then Microsoft went on to monopolize the desktop with a copy of the Macintosh. Web publishers can be sure that the vast majority of their users will be intimately familiar with the "pick the object then the verb" style of interface. Sticking with a familiar user interface cuts down on user time and confusion at a site.
What happens when publishers ignore these guidelines?
Date: Wed, 5 Aug 1998 23:20:33 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: philg@MIT.EDU Subject: Another bad Web user interface example I thought it was a really great idea when BankBoston replaced their clunky modem-only terminal-based home banking system with one that works over the Internet. Not only is the user interface painfully slow (downloading images that are different for every page over a 33.6 modem and an encrypted connection), but it totally disregards the perfectly good user interface built into my browser. In particular, if you try to actually navigate anywhere and then do something, you get this: Error Description 2300004 - Screen Error You only need to click once on your selection. Please do not double-click, use the buttons on your browser, or open a second window while logged on to BankBoston. You can use the buttons on the screen or Short Cut to move around the system easily. Oops! What's worse, once you get it into this sort of a state, it is totally unable to unwedge itself, and going back to the login screen gives only the helpful message: Error Description 1501002 - Invalid Card Number This Card Number is currently logged on. Please make sure you have logged off the system and try again. Um, hello?! The only way to communicate with them is through the feedback function, which I can't use because their system won't talk to me. (Of course, the whole thing is run under NT, judging by the file names. I think I should probably be very concerned about that.) Eventually, I was able to ``log in'' again, and got to the `feedback' section to send them a message. I spent about ten minutes composing my diatribe, hit the ``images'' button to figure out which inline image was hiding the ``send'' function, and then hit it. It comes back with another error message -- the date I had given it did not fit its simple-minded notions of what a date should look like, so it gave me another error message. Of course, I didn't want to lose my carefully composed diatribe, so I hit Meta-Back to get back to the form. (I then added another paragraph about what kind of idiot would give users a blank text field to enter a date without any indication that the simple-minded program would only accept one form.) You can of course guess what happened: I changed the format of the date to the one it wanted, hit ``send'', and it gave me the original error message again. Oops... better find something to waste ten minutes doing until it times out again! All in all, it took me a good hour to finally send my message, and I never did manage to pay my bills.
According to the July 27, 1997 issue of PC Week, BankBoston's Web service was developed by Sapient, a consulting firm, using virtually the entire panoply of technologies panned in the later chapters of this book: WebObjects, Windows NT, and a C++ and CORBA middleware layer.
I can't figure out which guy is the hero. The president of the company who just said no to lame, slow sites that take forever to do a search on, or the web designer who fixed it. I would have to say the company president who actually looked at the site and realized that customers would be turned off and wouldn't actually return for a second visit.Some of the comments regarding how much it actually costs companies who do stupid stuff like use non standard colors for background and text, like MediaOne cable company that actually had the channel card on the web page but didn't have the brains to put it in standard colors so that it would print out correctly from printing from a browser (this can be solved by selecting the text and dropping it into a notepad/text editor) could be shifted to another chapter. This theme is actually prevalent throughout the whole book. It is not "how to make money" but rather "how to minimize customer support costs and maximize repeat hits to your site" by making information regarding the product available online so that customers don't waste valuable resources by calling a company's toll free service number and making a site useful enough for people to come back to.
The point about frames is well taken, Most newbie internet users have a 20 inch monitor that they can spread all the frames around and see everything, right? Sure. If you are the typical first time computer buyer, guess which size monitor you will get because it is inexpensive. Yep, 13 or 14 inches. How many times can that be subdivided until you can't see any CONTENT, just navigation toolbars? Guess how many times I will go back to a crappy site like that.
The warnings on Java and other notoriously unstable plug ins should be heeded. How many times will I go back to that whizzy site if it crashes my browser? And what if I have Java turned off because it usually slows everything down? What will your site do for me in that situation? Load the no frames, no java version?
After looking at the source code that the typical page editor/creators kindly inserted into my html pages, I decided to get rid of the junk and make my source code cleaner. I don't need people to know how much of an idiot I am for using Windows 95 and Netscape Composer instead of Emacs (yeah, right). Clean web interface and good, solid content should be focus, not on the html itself.
-- Matthew Endo, July 17, 1998
I noticed you do not discuss "dynamic HTML" (DHTML). From my limited experience with it, I have found DHTML to be an excellent alternative to Java for building rich web UI. Newer versions of IE and Navigator support it (IE4.0 and up, Nav4.5 and up), although unfortunately the versions of DHTML they support are not 100% compatible. DHTML lets you access the Document Object Model (DOM) for a web page, which lets you programatically manipulate the HTML elements on a web page. You can build quite sophisticated UI with it. Since DHTML scripts run on the client, it does take advantage of the client's processing power (like Java). In fact, I would venture to predict that DHTML, rather than Java, will become the primary way people build rich web UI, since it is a very natural extension to straight HTML. Thoughts?
-- Anthony Chavez, August 12, 1998
Another reference on Web usability: http://www.alertbox.com is Jakob Nielsen's site about usability on the Web.
-- Patrick Connors, September 8, 1998
It appears that Mr. Chavez (above) read through the entire chapter and missed the whole point that Mr. Greenspun was making. He talks about building a "rich ui" which sounds very much like he is a "painfully creative designer" as Phillip Greenspun put it. Perhaps there are good uses for DHTML. I don't know of any.
-- Mark Hershberger, December 1, 1998
Why can't most companies understand the concept of good web page design? Its so often that function follows form instead of the other way around. The ideas presented here seem like they should be common knowledge and heeded. Check out http://www.ibm.com for a glaring example of a company that needs to read this document. Its so tiring to wait on pages to download because of all the bells and whistles attached to them that are meaningless to most people. I'm telling everyone that I know (that would care) about this book. Hopefully by 2003 all information-oriented (opposed to entertainment-oriented) web pages will deliver the goods without inducing a migraine in the end-user. Right.
-- Spencer Hochstetler, February 7, 1999
I taught myself HTML several years back with The Bare Bones Guide to HTML and some other starting pages similar to the intro lession in this chapter. Learning HTML is easy. Learning how to design a site is hard.
Six months after writing my personal home page, I was called upon to write up our corperate R&D pages. I was quite fortunate, as I had a local mentor who told me about the diversity of browsers out there, and thus showed me the value of writing to the lowest common denominator possible, while still getting out the information. We thought of the user who a)Wanted highly technical information b)Wanted some general information c)Were browsing and wanted to look at something interesting.
Each user was satisfied, with the emphasis being placed on technical information and less on flash. Our site was not as slick as some, but I never heard one complaint that our site was ugly, or too plain. Critique came mostly on the data, which was the prime area of interest for most users.
Unfortunately, I can't show you my work anymore, as a design company was contracted to do a total revamp of the site, making the look consistant throughout, and giving it a 'slick' look. Even users just looking for something interesting become frustrated because of long download times, links that don't look like links, convoluted site layout, and a host of other design problems. To top it all off, I still can't access our department's portion of the site anymore because they are worried about losing control of the content.(I laugh at this, because the content is now so hard to get at)
Why the current problems? Simply put, persons in our company did not think enough about making a useful, usable site, rather they made it look cool. In the process, they lost track of usability to the point where the site did not work on the company standard browser (IE 3.0) upon release.
My plea is this: Stop think before you use the latest toy for web pages. Ask yourself 'does this make our pages easier to use?' 'Does it add information?' Most importantly, 'Is there a simpler, more commonly used tool that will do the same job?'
With the diversity of tools, there are many wasy to present information on a web page. The trick is to find the right one.
-- Ralph Fuhrmann, February 13, 1999
Frankly, this is probably the first time I've disagreed so strongly with something Philip had to say. The reason is because the perspective given in this chapter is grossly oversimplified.It's easy enough to follow the logic: This book is written for Harvard MBA's who want to learn about RDMBS-backed websites. Harvard MBA's usually end up becoming CEO's at multi-billion dollar companies. Multi-billion dollar companies typically have lots of customers. You (as the CEO) want to reach as many of those customers as possible. You demand a straightforward site that presents information to as many users as possible, with minimal cost to the company. You get fired by the board of directors for having the most boring site on the net. Your wife leaves you because you've stopped making payments on the time-share in Cabo San Lucas. Your former company's Board of Directors replaces you with an Executive VP who happens to be pals with David Siegal. The new site has a tunnel. Everybody on babble-digest rants about it for days. The Executive VP writes a book about the experience, and gets all his other friends in new media to write blurbs for him, and he makes enough money to buy out the company. He and your ex-wife start dating. You can finish this story if you want.
So then. It starts out sounding true, then it's funny, and then you realize it's a bit ridiculous. Hopefully.
Reason number 1: this book is being read by folks like you and me. We're not CEO's, nor do we run websites that garner 500,000+ hits/day. Of course this is a totally unsupportable statement, and I'm probably wrong, but Phil will have to do some of his magic tcl-scripted market demographics to find the answer.
Before he does that, let me run with this for a second. Let's say you really are a Web Expert that a multi-billion dollar company originally hired to create their website described in this chapter. What would *you* do? If it was me, I'd show the CEO Photo.net, ask him what he thought. If he liked it, I'd charge him $1,000,000 for software development, go to arsdigita and download everything I could point my ftp client at, hire a few sysadmins to do the hard stuff, and then go home happy. Yeah right.
What I'd probably have is a team of designers which would at some point include the company's own graphic design department. At the least, there would be a committee to determine the site's "look & feel." We'd have to respond to dozens of memos per day discussing the progress of the site, which pictures we'd like to use, whose department will be linked from the home page. . . blah blah blah. And then, a year later, I'd be called into the president's office to meet some a**hole from MIT (I'm guessing), and be fired by him. But the anecdote's still pretty funny.
Reason Number 2: People like animated gif's. Don't ask me why, but they do.
Reason Number 3: One of the reasons the web became so insanely popular is because of pictures. People like pictures. And in the analog real world, if people like a picture well enough, the'll take it down to FastFrame and have them slap some wood and a plate of glass on/around it. Then they hang it on a wall, and say "Gee, doesn't it look so much nicer in a FRAME?" Don't think too hard about this. Somehow, I just though it sounded amusing.
Reason Number 4: Like most things in the world, there is a happy medium. Right now, most of the web represents itself much the way Philip describes. For that reason, Philip's got every right to lambast graphic designers. I take this chapter as an effort to reset the balance a little.
But if everybody took Philip's advice strictly to heart, the rest of the web would look like Photo.net. And wouldn't that suck? Seriously.
Okay, I got bored coming up with legitimate reasons. As if any of the above qualifies as legitimate. But I'll close with this: Your site doesn't have to be like Phil's to be useful, easily accessible, easy to administer, and robust. On the other hand, your site doesn't have to look like David Siegel's either. But popular sites with interesting content that are wrapped in a graphically pleasing design *are* possible. And sometimes a site's raison d'etre is *about* graphics. Unix servers and scripted pages do not the web make.
Examples?
That's all I have to say for now. But after having re-read the above, I realized I don't disagree with Philip at all. I just don't happen to agree as much.As a final note Philip, thanks for making your *excellent* book available for free reading online. And, right as I was finishing that last sentence (writing this in Notepad on NT, thank god), the IDEO site I listed caused my IE4's Active Desktop to crash. Maybe I should re-think this a bit. . .
martin@ouimet.com
-- Martin Ouimet, February 26, 1999
I am rather disappointed with the shallow treatement given to XML. XML is not just a record in a database: on the contrary, it might be an excellent vehicle to integrate heterogeneous databases and build great category-4 sites. The main point of the chapter on this respect is, I think, correct: "real" information lies in databases, XML is just another syntax. However, syntax is more important than the text implies, and XML might be very effective in defining the very "semantical tags" the text has mentioned earlier in a favorable light; why weren't that connection and its implications ellaborated upon?
-- Julian Cardona, March 6, 1999
On Martin O.'s comment:If web pages, slick or not, behaved like IDEO's [which is slick, maybe even gooey] they become useless.
Am I the only one who discovered that, on clicking over to IDEO from Martin's comment, that the back button on netscape failed [probably because there is an IDEO idiot refresh page blocking retreat]?
Phil is right. Simplicity is content, understandable. Web pages should offer information, and blue url's should answer how and why, just in case the reader wants to know.
-- j r, April 11, 1999
Two of Martin Ouimet's examples spawned error alerts in my browser. Glassdog tries to do something in Microsoft's VBscript, which my browser "doesn't support." Terraserver's page doesn't come up at all, making some complaint about Microsoft's Active Server Pages technology.
The browser I'm using is Microsoft Internet Explorer (4.5 for Macintosh).
What loaded at Glassdog after the error was beautiful. Two beautiful things were floating around so I clicked on one of them. On the next page I saw some more beautiful things in a very nice frame layout. Then I left and I'll probably never go back there again. By next week I will have forgotten the name of it.
I've spent over 10 hrs at photo.net over the last 3 days, and I'll probably come back tomorrow.
-- Scott Shepherd, April 24, 1999
"Tags can overlap, but you should close the most recently opened before the rest, e.g., for something both boldface and italic:My Samoyed is <B><I>really</I></B> hairy."
You have this backward in the printed version, page 125. Of course you probably already knew that since it is correct here.
-- Paul Calvi, June 4, 1999
You forgot to mention (and use) named anchors. If you want someone else to be able to refer people to a specific section or phrase in a long-ish document, you can wrap some key part of it in <A NAME="usedinurl"> and </A>. There are many examples in the glossary. One example is the link to my favorite web server. The text within the HREF attribute is simply http://www.photo.net/wtr/thebook/glossary.html#Apache.
This is particularly useful for referring poor designers to relevant sections within a good design book. A few names would be very appropriate in this text.
As a caveat, some older browsers (very old ones) will mis-render named anchors as real anchors. Those browsers are mostly extinct.
-- Jason Riedy, July 2, 1999
I must take exception to the choice of white background. You say:"Some Web browsers default to a gray background, and the resulting lack of contrast between background and text offends me so much that I change the colors manually."
Not only some browsers, but also some users (like this one) set the whole *desktop* background to some kind of gray. But... lack of contrast? You're implying some assumptions (see below).
Then you go on:
"...I don't feel too guilty about it because (1) a lot of browsers use a white background by default, (2) enough other publishers set a white background that my pages won't seem inconsistent, and (3) it doesn't affect the core user interface the way that setting custom link colors would."
All three points seem largely irrelevant. On the other hand you miss an important point: you (and most other Web publishers) are forcing users to *reduce* the contrast or brightness of their monitors, in order to survive the glare.
In the following chapter you make a few good points about the contrast capability of photo printouts vs. slides vs. computer monitors. It is obviously important to exploit the full contrast range of monitors, but putting up a white background you force users to lower their monitor brightness, just to get through the day safe and sound.
As a result, most Unix and Windows users see your beautiful photos even darker than they are gotten by the gamma problem.
On each machine that I use I put the contrast knob to the maximum, then put up a black screen and set the brightness as high as possible, given that the black stays black. Finally I set a greenish grey desktop background, and get all applications to use it.
Then I sit back and look at how the white in icons and photos stands out.
I use Opera for browsing. When I get to a site with a white background, or unreadable color combinations, or too small type, I just hit Ctrl-G and lo! Instant Arial 11pt black on greenish gray...
But, maybe you like a white background because it reminds you of glossy paper? Then you should stop and think about *recycled* paper. :^)
P.S. about the gamma problem, of course you know about the PNG format, and its built-in gamma support. Unfortunately it only supports lossless compression (images bigger than JPEG), and browser support is still catching up. Good news is that many video cards these days support gamma correction. I am able to see your photo on my PC in all their splendor and dark details.
-- Nicola Larosa, July 4, 1999
I'm afraid I have to second the complaint about white backgrounds. I spend a lot of time staring at computer screens, and it just seems intuitive that you want to keep the amount of light coming out of them to a minimum. I've always thought that the trend toward using white backgrounds with black text on computer screens is some kind of bizarre imitation of the dead-trees world, where "white papers" are automatically credited with respect.Myself, I don't even care about having majorly contrasting colors, but then my vision is really good (I've noticed that a lot of people who wear glasses also seem to like to have the room lighting turned way up when they're working). But if you were a contrast addict, I would think you might go for a good old-fashioned terminal light-on-dark color scheme. But I noticed elsewhere that you were sneering at someone for using white on black, though it's not enitirely clear why.
Is it the "consistent user experience" principle? The point being that if you use a black background, you're going to also have to change the link color from the usual darkish blue? This can be minimized by just switching to a light blue (and definitely, always leave link text underlined!).
Related side issue: I find it majorly annoying that Netscape's Edit-Preferences-Color feature has been broken for years. If you try and impose your own color scheme, you're likely to get half of what you asked for and half of what the page designer specified... nothing like a black-on-black color scheme, eh?
Anyway, words can not express the visceral sense of relief I experience when I close my last Netscape window, and nothing is left on the screen but my emacs window with "thistle" (pale purple) text on a black background, against a nice dark green (#052500) desktop.
-- Joseph Brenner, July 13, 1999
I visited the glassdog site, and I clicked on the Web Design link, and the text was almost completely unreadable against their background. I do agree with Marvin though, it should be half and half. It would be great if everyone supported Flash and had unlimited bandwith and everything was like a damn CD-ROM, but we're a couple years off from that. But it doesn't mean we have stay a some sort of completely minimalist way of designing web pages. I think that to start, minimalist would be the way to go, at least you develop your content. After that, you can design your page to be frendlier, not necessarily easier to use but impressive to the user without being slow as hell or incompatible. It is possible, it just takes a lot of work to do so. Resolution for example, is always a big issue for graphic designers these days, but it can be circumvented if you know enough about HTML. Combine the single-pixel gif and a working knowledge of HTML and I think you'll find a thin line that is acceptable.
Bertrand Fan (www.bertrandom.com)
-- Bertrand Fan, July 31, 1999
The www.ideo.com site is an example of everything that's wrong in web design now. Sideways text?
-- christian stock, August 4, 1999
I do web app & site devel for a huge conglomerate. Recently corporate decided that all the companies they own had to use a 'styleguide' to provide a consistent look for the corp. A noble ideal. Christening themselves the Experts On All Things Web, a number of people chosen for this task developed the 'styleguide' and it is shortly to become law. This is a big thing... we are all supposed to be awed by this expert approach to web sites.Of course, it is ENTIRELY graphic in design... they don't think the download time or images-off potential is a big deal. It is made so that a very limited amount of categories or info can be presented. (As long as the site isn't more complicated than a slide show, no problem.) Exactly what graphics program to be used, and the exact RGB and point size are spelled out, as one of many examples. Every front 'splash' page must have a (graphic) monthly date on it which of course must be changed, even though the site may change once a day or once a year. This has no bearing on whether DATA has actually changed, you understand. If visitors want to know where they've been, they just have to memorize, as all links are graphical.
But the best part is this: every single page looks exactly the same. Every single company has to make every single website and every single page look exactly the same. So, whether you're at a financial firm's site or a jet manufacturer, a design firm or whatever, everything looks exactly the same. It's like the strip malls, where you really can't tell if you're in L.A., Phoenix, Houston, Atlanta, etc. because everything is identical. Any chance for any user to remember 'where they were' when they found a given thing is zero.
This entirely graphic, entirely the same standard being enforced on any number of totally different types of companies with different types of site and content is being hailed as a real high-tech advancement in web presentation. Big money paid for this.
I think I may go back to making databases while I wait for XML to finally become useable.
PJ
-- PJ Gaenir, September 4, 1999
>> Each document will need a link to the page's author, the service home page, and the next page in a sequence if the document is part of a linear work. <<Not to be pickey, but isn't this a "linear work"? How about some links to the TOC, next chapter, previous chapter, etc.? Still, I would crawl on my hands and needs to read this book! It is simply super. Bobby Sanders.
-- Bobby Sanders, September 5, 1999
I'm a self-professed "contrast junkie" when it comes to my B+W darkroom work, but after reading Nicola Larosa's comment on setting the background to white prompted me to experiment with setting the background on my browser to gray (about the same shade as the standard gray of a program's menu bar). I have to say that it made a big difference. Not only can I feel much less eyestrain, but I can actually appreciate the images on this site now due to the reduced glare of the white background. I think that's the reason why I wasn't really attracted to most of the photos here (except the bright ones). Just try it out for a minute and see if you like it.I guess I wouldn't recommend it for all the pages on a website since it gives out a kind of "blah" feeling to a site.
-- Arjun Sanyal, September 14, 1999
Further feedback on IDEO:
I visited this site, curious about it after all the other comments. It is breathtakingly beautiful, its changing graphics have an organic flow at a level I've never seen elsewhere. I was more than impressed by the speed and co-ordination and sheer artistry of its mouseover effects. I eventually navigated into about four or five layers of the site to explore further [and I too discovered that you can't back-button all the way out].
I still can't tell you exactly what it is these IDEO guys do, other than "they design stuff". I couldn't find any clear, simple, non-jargonous info anywhere.
-- John MacLeod, October 8, 1999
I like the way that references to books are linked to Amazon so I can easily go buy one. But I'm in the UK, so I'd like to be linked to Amazon's UK site, not the US one. I can have a book shipped from the US, but it is more expensive to do so. A user centred web site would take me to a local web book supplier.How can such richer personalisation be accomplished without compromising a user's privacy or requiring them to fill out lots of tedious forms?
-- Brian McBride, October 19, 1999
Apple's Human Interface Guidelines have been on the web for some time now (Philip's link just goes to Amazon). As of this writing, they're available here. If that link should break, I'd try starting at www.apple.com/developer and poking around from there.
nat
-- Nat Irons, November 14, 1999
I truly enjoyed the Learn to Program HTML in 21 Minutes article. My opinion differs from yours on only a couple of counts, which I will now bore you with:
1) Black on White Text
Text should not necessarily always be black on a white background, but it should always, always, always have a very high foreground/background contrast. A grey background, even one as light as #CCCCCC, does not offer enough contrast with black text at normal body-text sizes.
Not everyone has keen eyesight, and the amount of light received by older eyes can be two-thirds or less than that received by younger eyes. Bottom line: err on the side of greater contrast unless there is a compelling design need to do otherwise.
2) Link Underlines
Underlines are (for the most part) a kludge used to compensate for monospaced monocolor type. In the nascent era of pocket-sized web appliances it may be that underlining links will be a useful and user-friendly design decision, but in the current era, the overwhelming majority of sighted users have color monitors and an adequate selection of typefaces.
Underlines for nearly all current users are no more than screen clutter, and should be expunged along with those Star Trek Scanning Light and Dog Running Back And Forth horizontal rules. Hyperlinks should be indicated with color (see next note).
3) Link Colors
Red is the universal "look at me" color. Unvisited hyperlinks should be red (AND have adequate contrast with the background color) unless there is a compelling design reason to do otherwise. A cool "relax" color, like blue or green, should be used for visited hyperlinks.
This is true regardless of the bad design decisions other web designers make. Others' bad decisions are not a compelling reason for you to repeat their mistakes. Conformity for its own sake is a not a design goal.
-- Brandon Blackmoor, December 2, 1999
Brandon raises some valid points with regard to contrast, however some web developers are going to be legally required to provide "Equal Access" to web pages. Not only will light grey letters on grey backgrounds not make the cut, other visual problems will need to be addressed. This means the underlined cue as to what is a link will need to remain. Even if you are not authoring content displayable on new non-traditional web devices like a Palm Pilot, a [defunct] Apple Newton or a cell phone, you may have a client looking at your page who is color blind, and can not distingush colors. Color blindness effects about 10% of the US Male population.
Without the underline cue, which one is the link? Perhaps blue as the default color for links wasn't selected accidentially.
In a nutshell, if you are opting for a web page that can be used well by all, without regard to their browser or eyesight, good contrast must be maintained, as Brandon pointed out, but that also extends to good font size and selection, and colors. Multi-media issues are another issue for later discussion, since they are not part of "HTML" per se.
This leaves you with 3 choices.
- static content which plays to the least common denominator.
- dynamic content which is backed with a program, and can present appropriately to the user on selection.
- dynamic content, which though DB backed sites and cookies, can automatically present in the preferred fashion to a user, no matter if they want the simple version for ADA reasons or because they are on a Palm Pilot or Cell Phone. Instead of the worn-out use of cookies for ads, a server could be used to help direct presentation content, either of a site, or of the internet.
The simple, static content will be the easiest to develop.
-- Rich Emmings, December 3, 1999
From the perspective of a beginner and newcomer to all things HTML, I must say that being a web surfer for the past five years has alerted me to the things that drive me insane - slow opening pages and grueling sites that just don't get me what I need or where I need to get it. But it is the nature of nerdy business technology that drives webmasters to speak in highly technical terms and jargon. . Corporate presidents hire IT/Techie gear heads to throw together website add-ons, bells, and whistles. The CEO gears get stripped in the process, because what CEO is going to admit his ignorance?Instead of knowing what they are talking about, the techies nod (because they will never admit that there is something that they do not know or can out source)and sites are created that simply suck out the profit and bonuses from the employees that make the companies profitable. Ceo's just tell the employees to go to the comapny website to lodge a complaint at a dead letter office, and to hell with it. Our internet expert, hired to design, outsources our sites to vendors and then complains when they are done wrong - am i just a little upset when he doesn't have to answer to anyone because nobaody uses our company intranet and our bonuses go to an outsourced firm?
Thanks, Phil, for introducing me to the notion that HTML only takes 21 minutes to learn how to do. Coupled with the three months that it took me to learn about relational databases, i should be one of these greedy bastards in no time.
One need not be a genius to understand that gimmicks and slight of hand (while temporarily entertaining and amaizing to the untrained)should not extract the double toll of wasting customer time and company money.
When designers get past the greed factor so prevalent in american society and realize that their profitability is directly connected to shareholder value and employee effort instead of impressing CEO's with animation, plug-ins, annoying music, and pop-up menus, they will begin to walk the precious miles with those of us who are not elitely educated. When elite educators like Greenspun get off their ass and help people, they automatically seem to get exiled from the groups that pay them to teach - because if it doesn't make dollars, it doesn't make sense? Fine.
Consider music. Rock and roll is stripped down music. People like it because it delivers a quick rush, gets a message across, and does not take forever. I don't need to pull down a bunch of new crap to let me know that the computer my mother slaved to buy me isn't the top of the line. The world does not need meta tags that connect sites to every spoken word. You can always tell the Poisons from the AC/DC's - and people have bought a hell of a lot more AC/DC than Poison.
-- Jim Clay, December 14, 1999
Well, it is very interesting to come to this page with the teachings of David Ogilvy, advertising guru, fresh in my mind. (I just finished reading both "Ogilvy on Advertising" and "Confessions of an Advertising Man".)Ogilvy points out that many designs for ads are done by art directors who are more interested in beautiful designs than ads that truly sell product.
I wonder if this doesn't map directly to the web, where we see graphic designers taking pains to produce exceptional artwork without regard to "what information am I trying to get across" or "how much does a guy visiting the Toshiba notebook support site really care about visuals when he is trying to get his modem to work"?
A couple of random thoughts from Ogilvy:
1. The consumer isn't a moron; she is your wife. You insult her intelligence if you assume that a mere slogan and a few vapid adjectives will persuade her to buy anything. She wants all the information you can give her.
2. On the average, five times as many people read the headlines as read the body copy. (me: what does this mean for how info should be structured on a page?)
3. Ogilvy was a fan of long copy: his research showed that long copy could often sell -more- than short copy ads. A famous advertisement for Merrill Lynch run only once in the New York time, contained 6,450 words, and generated 10,000 responses. This "jives" with Phil's comments about content.
-- Patrick Giagnocavo, January 12, 2000
I'd like to see the navigation links at the bottom of the page, after the comments from the readers, rather than before. That way, after reading everything on the page, Joe User doesn't have to look around for the link to the next page, or remember to use the back button to go back to the table of contents.
-- Andy Quigley, January 24, 2000
Martin Ouimet wrote above:"Reason number 1: this book is being read by folks like you and me. We're not CEO's, nor do we run websites that garner 500,000+ hits/day."
Well, as it happens I'm involved with a site that is presently getting 700,000 page views/day (5M+ hits) and climbing. Luckily I'm on the networking and systems side of the house and the mega-headaches caused by the 'middleware' haven't been mine... our Oracle database is now just ticking over, our web servers are ticking over, our middleware is falling over, even though it is only involved with producing less than 40% of the pages on-demand. Maybe that AOL web-server & Tcl solution isn't such a bad idea afterall. [Then again, in 1995, the OpenMarket web-server and Tcl was a good solution, while it lasted.]
Of course, the customer wants their logo, two advertising banners, a graphic navigation bar, some buttons, and 5-layer nested full-page tables, but when all is said and done, it isn't the speed of the servers that were going to thrash their desired 4-second download time, but the bloated size of their pages (which started out at half-again to twice the size of thier best-in-class competitors), and deeply nested tables which show no evidence of downloading (on many browsers) until everything has arrived.
-- Bill Caloccia, January 26, 2000
My thoughts on some of the issues brought up thus far by readers:Background color/contrast: Some like black-on-white for maximum contrast, some prefer the less contrasted black-on-gray (like me--my eyes are sensitive and pure white on a monitor can be irritating). If you're trying to be completely user-centered, why not just use the defaults and let the user choose whatever colors he wants with the browser preferences? Trying to use the color scheme that appeals to the broadest audience seems pointless when there's already built-in browser functionality to deal with it.
That said, it's important to point out that not every site needs to be 100% compatible with 100% of the user-base. I think it's perfectly reasonable when companies or individuals choose to sacrifice a little compatibility to give their site a distinctive branding. Every piece of content does not have to appeal to every person, just the target audience. If one alienates a few users by using a certain branding scheme, but makes loyal, trusting visitors out of the rest, then that is, in my opinion, a justified tradeoff. The alienated users can always find what they're looking for elsewhere.
What it comes down to is deciding which is more important: branding or user-compatibility? E.g. for Phil's site, since it's all about content and no branding, I would prefer he used my browser's defaults (black on light gray) so I can read all his great content without straining my eyes. If I was going to an online bank, however, I would probably prefer a site that has a nice, distinctive design that happens to use a white background over a site that has plain, "un-designed" globs of content that just uses the default color scheme. Well-branded sites, to me, convey trustworthiness. Given, they must have good content to back it up, but an aesthetically-pleasing design still helps.
Link colors: Brandon suggested that red be used for links, because it grabs the viewer's attention. Personally, I think red is too loud to be used as a link color. Blue is a good color because it is distinct enough to let the user know that the element is a link, but does not hijack the viewer's attention. Also, it is now pretty much common knowledge to any computer user (casual or nerd) that blue, underlined text is a link. Even if one finds an alternative, "superior" method for denoting links, the user's potential confusion could outweigh the benefits of the new method.
-- Justin Kramer, February 14, 2000
Why such a disparity between proponents of informational sites and graphical sites? I hear lots of arguments against graphics and for text, and dailing in from home through AOL, I do place a premium on fast-loading pages. But I have yet to find a plug for a SHORT PAGE or for PAGE LAYOUT.
Someone said above that long downloads cause migraines. What about reading 50 screens of unformatted text? My eyes are still throbbing. I have no idea how I made it through 3/4 of this page. I never even finished. It was honestly the first (and only) time I have read such a long page. I hate to break it to you, but not everyone has a text-only browser, and people do still go to libraries to read novels. They want small packets of information that they can manage, not endless pages of text. An effective site (dare I say, "killer" site) uses excellent layout to break up the information in useable chunks, making the content easier to read and therefore easier to access.
People really do like pictures, especially when they are seamlessly included into the page and not conspicuously plopped in random locations. If modestly used, graphics can be very interesting without bogging down performance.
-- David Crowley, February 16, 2000
Agh! Sorry, but there is more to web _design_ than crica '93 layout:) Yes, there are a lot of "features" (bad java, slow tables, big graphics, shockwave) that can really slow down a site. But the flipside of that is that it might be _worth_ the wait, if you're site is for a focused market/audience. Shockwave and flash can be seriously powerful design tools, as can tables, even frames. Content is king, but it doesn't have to be BORING looking to be effective:)
-- Robert Landrigan, February 17, 2000
Responding to an earlier comment regarding the "unappealingness" of VERY LONG web pages, I have to agree. The chapters of this book (in web form) are far longer than any other web pages I've cared to read all the way through. Granted, the content is interesting enough to keep me reading, but people aren't always reading things they are raptly interested in. I wasn't always interested in my assigned reading when I was in school. In my opinion, there needs to be some kind of standard page length. If I told you I read a 300 page book, you would have a pretty good idea how long it was, and could probably guess how long it would take you to read that same book. I can't guess how long a web page is going to be by the size of the scroll bar button. Can you?
I wouldn't mind if entire books were published as single web pages. I do think, however, that the pages should be numbered at some standard interval, possibly measured in lines of text. More importantly, the numbers should be expressed as page X of Y. That Y will help readers with a time limit decide if they want to delve into your page further or just move on. Knowing the number of pages to be read helps with personal time management, the decision of whether or not I should find a comfy chair or go to the bathroom before starting a chapter, etc. It would be great if page numbers could be bookmarked, too. I can never remember where I left off when I come back to this site.
Finally, Phil spoke of the need for pages to stand alone with their own navigation features to preceding and subsequent pages in a series. I found the "Next Chapter" button, but I still haven't found the "Previous Chapter" button on this page.
-- Dan Mascenik, February 24, 2000
Lately I have taken to turning off java/javascript. But I left style sheets turned on. Once I realized you were using them, I wondered why I was not seeing the indents, etc. Well, I suppose css are driven by javascript, since I had to turn JS back on for the css to have effect. I had considered trying out css, but if it relies on javascript, I think I'll pass.On another note, I have started writing a paper (book eventually?) entitled "Fire the Webmaster." It is my attempt at educating the corporate types about how to present what people want, rather than getting awards for graphic design. I suppose I don't need to finish it now, since I have discovered your book online. You have said pretty much what I was going to say, so I'll just point everyone I know to your site. Thanks!
-- John Meyer, February 24, 2000
I visited the IDEO site. It is poorly designed. However, the problem of not being able to use the BACK button to return to the "21 minute" page is not actually a problem at all. Simply click faster. If you click again before the re-director loads you can bypass it. It may take several tries before you get the timing just right. The same holds true when you enter a porn site and it spawns multiple copies of your browser. Just keep clicking faster than your computer can get the data off the 'net. It makes for a fast paced game similar to the arcade game of whacking the pop-up characters with the mallet. Of course, folks with DSL lines will have to be a tad faster but it's good exercise for all because it builds hand - eye coordination.
-- Bill C, March 11, 2000
I also visited the IDEO site, and I still can't figure out what exactly it is they do. Also, in a company, "about [us]" and "what we do" should be one in the same, but here you have to wait for two extremely long downloads full of graphical links just to read two little paragraphs. Also, the site is completely geared toward prospective clients, with little or no regard for employees or current clients, which only goes to show that whatever "consulting" they do, they:1. Do not use internet technologies as a part of a working program (a crucial aspect of today's businesses)
2. If they do consult on #1, they do not practice what they preach
3. They do not care for existing customers
4. They do not care for current employees
Any veteran employee, employee in training, or potential employee would be hard-pressed to find any information of substance at ideo.com. Any potential customer would be scratching his head trying to figure out what ideo could do for them. Any current customer would not hesitate to pick up the phone for the most simple question or transaction.
Also, it seems that content over pretty "design" is a good idea... when you are the top-level manager. However, if you are like me, looking to change careers, it would be a losing battle trying to convince middle management at a company that a shockwave presentation that lasts 5 minutes and provides no information isn't very useful, especially when some job descriptions require you to know shockwave, flash, etc.
On top of that, it is obvious that many sites have their planners, graphic designers, layout designers, and authors in completely separate departments, and they probably never mingle.
Also, regarding the white background.... it is too bright! Some monitors interlace, which worsens the situation. If you are sitting in front of a monitor for several hours, you want something different than black on white. I try to put a slight peachy color on the web site I am working on, http://www.traintomidnight.com/baleromag/ , just so that it does not hurt my own eyes. Also, I make active links on the initial page [which is actually a site map] in red, to go with the color theme, which communicates a mood of festivity. Blue would be too cold and plain.
-- N. David Guarneri, March 25, 2000
Something that came to mind in the graphical/content debate is the cover of books. Certainly someone decides on weather to decorate a book cover with lots of graphics or to use simple to-the-point text to entice readers to read. Right? I think every author/web-author should think about the mission of what it is they are doing in order to answer the pretty/functional question. If I'm not mistaken, a lot of sites that are nice on the outside lessen the heavy graphical interface as you descend deeper into their companies say technical information. (Showing a kind of inverse relationship of time spent to graphics.) The only site I can think of off hand is HP. I was there looking for drivers and the pages are decreasingly graphical the farther I got.I completely agree with the white background being much to bright for my 24-year-old eyes. I use a computer a lot as well. (I read somewhere that the most pleasing color to the eye is green. We used to call it Marine Corps Green. Maybe I'm bias.)
I also wanted to send a heart-filled thanks for this publication. I won't tell you how much time I've spent on this site (you can probably tell me with one dbase query.) Being a young family man I have a great desire to learn and not a lot of money to spend. I do think this site will change my life and I feel it will change that of many more. Bravo "philg"
-- Justin Dankel, March 30, 2000
Just a quick nit:Setting the text and background colors without setting the link colors has the potential of being bad. If someone has changed their colors, say to yellow on blue with black links, your links will be indistinguishable from your text (at least as far a color goes). Setting some of the page colors, but not others, is a little shame and a little war.
-- Jeremiah Blatz, April 3, 2000
You know, I can't help thinking that this is one of the best series of pages on HTML I've read in a while, and agreed with most everything here. But I found myself wishing that I could read it faster and couldn't understand why it was taking so long to read each page. Then I realized--the web today is pretty much a series of quick blurbs about whatever. We are unaccustomed to coming across any real content in here and have become comfortable with the shallowness of flashy graphics. When a page actually comes into our browser that is stuffed with decent content, we become impatient with how long it takes to get through it.My first experience with an electronic book was one I had to read for my architectural studies, City of Bits, also a publication with ties to MIT. I felt the same way while reading it. This is especially true when one can't see the top and bottom of the page together. In my experience, scroll bars on the sides of browsers are poor indicators of page size or current reading position within it. I feel that all pages should be designed to limit content to five paragraphs or about 500 words so that one can use mouse clicks, rather than scroll bars or mouse wheels, to navigate through it. Obviously then, with a large publication, real thought needs to go into providing additional navigation through sub-sections or chapters.
There is something about electronic feedback that doesn't satisfy us the way physical touch does. Surely this is true in realms beyond reading! It's the same when downloading something or installing software. Does that progress bar on my screen show me the real progress? Or is it just a tool based on incomplete data which is basically inaccurate for my personal situation that I usually treat skeptically? (How many times has your progress bar been stopped longer at 99 or 100 percent than it has taken the entire rest of the procedure to occur!)
I usually end up printing web pages of quality so that I can read them on paper. There is something temporal about the web that makes us want to click from one page to the next regardless of whether we've really read the entire thing. Perhaps some day the web will always be reduced to graphics and brochures for reality. In the end it might never become the substantive experience that we would like it to be. Maybe the only content still worth reading in a park on a Sunday afternoon comes out of a book.
-- Steve Hall, April 17, 2000
1. Defaults: How often is there really a reason to change the text color, background color, link colors, or link formatting? We should credit the user with having set those to work well for the user; why reach in and mess with them, ever?2. Contrast: Since eyes are not all alike and monitors aren't either, the user's settings (see #1 above) should be allowed to control the display. (By the way, for my 47-year-old eyes, black on white is very much easier than the reverse. I am looking at the screen for most of the day.) ("Day" defined as anything from 8 to 18 hours...)
-- Thomas W. S. Smith, April 21, 2000
I just can't buy the argument that a visually pleasing site can not also be a fast-loading site. Graphic design does not have to be complex and busy to look good, and there are great tools available for compressing images. With good planning and design, I firmly believe that a site can look good for the price of 8k or less; if the design is consistent throughout the site, the images will be cached, so it's a 1-time 8k. Furthermore, an amazing amount of attractive formatting can be done with stylesheets, which, if used properly, actually reduce the page size rather than increasing it.
Of course, there is no objective measure of what makes a site "look good," and, as many people have mentioned above, we all seem to keep coming back to photo.net. I just think that a site need not be overly spare to be fast.
Justin Dankel wrote that "a lot of sites that are nice on the outside lessen the heavy graphical interface as you descend deeper into their companies say technical information. (Showing a kind of inverse relationship of time spent to graphics.)." This is absolutely true, but it is also absolutely the wrong way of going about things. If a site has managed to keep me interested for a few minutes and a few pages, to the point where I'm deep within the site looking for specific information, I have already invested enough time and effort to make it unlikely that I'm going to leave just because the page that I've chosen to look at is a little slow (especially since I have chosen to look at the specific page, which suggests that it contains information that interests me). The front page of a site, however, probably contains very little that interests me, especially if I'm looking for specific information (likely the only thing that I care about is the link that will take me to that information). If I have to wait 60 seconds for all of the other irrelevant stuff on the front page to load before I've made any kind of time/effort investment in the site, I'm much more likely to get fed up and look for the information on a competitor's site.
In a strange (and unintended) sense, this sort of goes back to my first point - if you're providing information that people want, you can probably ask them to wait a couple of extra seconds in order to have that information presented in a visually appealing way. If the information is irrelevant (or non-existent), however, it doesn't matter how quickly your pages load, no one's going to stick around. So to sum up this rather long and directionless post, content is, indeed, king, but I'll bet people are willing to spend a couple of extra seconds in order to see the king dressed up in some nice royal attire rather than having to look at his wrinkly old naked body. Not too many seconds though, so graphic design should be simple and elegant.
Cheers.
-- Stephen Bollinger, May 22, 2000
Well I must say first that this page made me happy. It's so full of basic thruths.In fact I'd just like to rant about something.
I can't stand websites that are formatted for 800x600. Just think about, of course, the IDEO site, but also (alas), IBM.com and lots of others.
I happen to do a lot of programming and photoshop, so my PC has two 17" monitors (this works quite well with Win98), set to 1600x1200. Quite often, an arrogant website designer thinks in 800x600-compatible" fashion.
Quite often also, the same designer uses four levels of nested frames that clutter the screen. So, information is presented to me in this rididulously small 5"x3" window, in an illegibly small font, surrounded by an almost empty screen.
Of course, this pisses me off. Of course I wont change resolution. As I use Opera I just hit the "+" key to zoom the entire screen. But, as the IDEO team so cleverly replaced text by JPEG images, these look ugly and pixelated.
Let's focus on the IDEO site.
It's also full of java(script) that doesn't work on Opera. Looks like people think ugly menus are preferable to good old links that work. So will I use another clumsy unstable browser like IE or Netscrape ? No. I'll just close the window.
It is also slow to load on my school's LAN connection. This same connection does around 1 megabyte per second (not megabit) when downloading from a properly set web server, like photo.net.
How can people who claim to be consultants in ergonomy or whatever design this ?
We can compare this to newgrounds.com, which is entirely Flash (normal for a site about Flash animations), and loads very fast.
Or to Eric B. 's site (http://www.ebb.ns.ca/eb/index.htm), an art photo site, which is the proof that a site can be beautiful, fast and easy to navigate at the same time.
Or to www.ti.com ; did you notice the little menus hanging on the left of the first page, allowing you to get where you want in an instant ?
Well well. enough.
-- Pierre Caillaud, May 29, 2000
I only skimmed through the text. Phil, I appreciate your philosophy and perspective. I sense that one of the arguments for getting rid of graphics (and other media) is internet speed. But putting too much importance on speed of internet (or lack of it) can work only for short term. This reminds me of those days when we tried to squeeze every bit of performance out of the 8086 processor using assembly languages and clever techniques and ended up with 'less-than-maintainable' codes (Although I'm not sure the situation is any better now in terms of system maintainability)I think the focus should be on usefulness of the information (as Phil has already pointed out) and ease of access to that. We will inevitably handle contents that are not only text, but also graphics, sound and other forms of information. To make a site the most useful, we have to do whatever it takes.
-- R. A. A. Abdullah, August 23, 2000
Even worse than "printing" white text - I made the mistake of trying out Netscape 6 PR1. The first page I printed happended to have green text on a bgcolor=black background. There is no option for turning off "print background", and there is poor documentation (help). Ouch! It's a conspiracy with ink cartridge manufacturers!
I usually find high constrast (pure white background) offensive - it tends to... "glow over top of the text". I find setting a background to barely a shade off of pure white helps a lot. Of course, what's even worse is colors that don't contrast much at all...
Cutesy stuff has its place - like flash that's used at www.shockwave.com and in animated cartoons. But when it comes to when people want to KNOW something, just give them well-orgaized information. They want to know the answer to their question, that's all.
***Anyone know of any good links to places that do research on semantics and the context of words and phrases? I've been thinking about this for a while... it would be invaluable for all things that require searching...
...though maybe our search engines would work better if they didn't accept money from large sites who want their search ratings artifically tweaked...
-- Kat ., August 29, 2000
Let me first mention that I agree with your main thesis: web page should be simple and contain the information. Gifs, ads, tunnels etc make me angry. Unfortunately, from my day-to-day practice I found, that sometimes one need to add some of those stupid bells-and-whistles. For the simple reason: the person who pays for website project or web application requires the site to be 'sexy'. He will never use the site (people from internet or - in case of intranet app - poor organization workers will). But the man-with-a-pocket wants to show to their colleagues, how the site sexy is. That is not easy to fight against.
Different thing: I am amazed with the number of skilled people (fluent C/C++/SQL programmers) which are afraid of HTML. I worked with a project manager, who was previously technical guy with good SQL, C++ and middleware knowledge. I made him to learn perl to script some tasks! He accepted writing HTML docs after he found that FrontPage is very similar to MsWord - and strictly refused writing HTML by hand!
-- Marcin Kasperski, August 31, 2000
Your suggestion that only Java can solve the "richer user interface" problem of a succession of popups with the choices in the later popups contingent on the choices earlier on is not quite right; see commerce.motorola.com/consumer/QWhtml/manual.html where Javascript seems to do the job.
-- Owen Watson, September 29, 2000
Two years later, Terraserver still is a clear example of bad design. Using the Mozilla 6.0 engine, the menu links in the menu are half blue-over-green and half blue-over-darkorange. I couldn't read those over green at all. I would have let them know, but, guess what, there is no feedback link. It fits their site perfectly.This chapter in the book should be mandatory reading for everybody even remotely involved with web design and usability. Great job, Phil!
-- Didi Damian, May 16, 2001
This chapter lives up to its title, but I want to protest against one bit of bad advice. Phil says he won't use H1 style for his first heading, because browsers render H1 too big for his taste.Following Phil, I spent cumulatively more than 21 minutes deciding case-by-case which heading style looked nicest on my Netscape. Then I realized what style sheets were for. Now I use headings 1 through 4 in order, to show hierarchy, and cut H1 down to size with one stylesheet directive. Even Netscape 4 (which as Phil notes can't process directives relating to list elements) has no trouble following orders when it comes to heading style.
-- Karl Narveson, August 23, 2001
As someone already mentioned above Phil tends to under-rate XML.
I believe that one of the reasons of WWW's tremendows success was it's ability to deal with poorly structured information. HTML (and now XML) is a contrast and a good supplement to database technologies that are very strong in processing zillions of rather simple records but can hardly deal with close-to-real-life objects.
Probably it's not about complexity but about changeability. If an object is complex enough you can't determine it's structure once and forever (what DB expects of you).
- Adding a new column to the DB when adding a record that isn't exactly same as previous--no thanks.
- Adding a new tag into XML document--no problem! It wouldn't brake other documents nor codes that deal with them.
Phil, database are nice but you are pushing them to much. Sorry but sometimes it seems that despite all your criticisms towards Oracle's site they should pay you a bit.
XML as a storage and PHP as a processing tool is a good alternative to what you propose. We've launched the new version of our corporate website recently where we tried this approach and really enjoyed it. It gives an answer to many of challenges that you point out.
- design and content are separated nicely
- total and uniform version control on html, program (php) and content (xml) files
- and it's many, many times less expensive than DB like Oracle
PS. This is my second attempt to post the comment. Here is what I've got first time:
There was an error in inserting your comment into the database. Here is what the database returned:
ora8.c:4715:lob_dml_bind_cmd: error in `OCIStmtExecute ()': ORA-02291: integrity constraint (ADSTAGE.SYS_C0011923) violated - parent key not found
SQL: insert into comments (comment_id,page_id, user_id, comment_type, message, rating, originating_ip, posting_time, html_p) values (23631,1754, 0, 'alternative_perspective', empty_clob(), '0', '212.30.160.2', SYSDATE, 't') returning message into :1
Don't quit your browser. The database may just be busy. You might be able to resubmit your posting five or ten minutes from now.
So I'd better keep away of heavy-weight RDBMS until absolutely necessary.
-- Anatoly Belychook, August 31, 2001
A note to those who save HTML pages with formatting that they like and later modify them for their own use. It is hard to believe, but if you Save As... an HTML page in Internet Explorer, it is run through a parser that royally screws the original formatting of the page source and even adds extra tags before the page ends up on your disk.To preserve original page source, I recommend you to install Netscape 4.7 and save all pages in it. Netscape leaves the source intact. Netscape 6 may also fit, but I noticed that it sometimes replaces the line feed characters, so that the page will open as a single long line in Notepad.
It is also a good idea to check all your site designs in Netscape 4.7. You'd be surprised how many webmaster's mistakes are being hidden by IE, and how many webmasters will refuse to link to your site if it doesn't work in Netscape. As of October 2001, at least 10% users are using Netscape. You probably don't want to lose them. Don't expect them to convert to other browsers any time soon, either: this statistics now changes slowly, and as you see, Netscape has its own advantages.
-- Vadim Makarov, October 7, 2001
I would just like to point out some of the critism of the Boston Bank website was unjustified. If you are allowed to use back buttons on your browser when viewing private account details then the next user of the computer could simply press back and see all your account info. My bank (Barclays in the UK) had a system where this was possible and it made me very uneasy using it on public computers (a necesity when stuck in an internet cafe with little money on the other side of the world). They now have a sytem like Boston Bank which prevents people using the back button on the browser and thus seeing my private info and I am now much happier using the service.So my point is that things are not always clear cut, in this case security is of higher importance than ease of use. However I am sure the rest of the critisms of Boston Bank services are valid.
-- David Roberts, January 24, 2002