RANT: The state of web-design practice
Jorn Barger
RANT: The state of web-design practice
.
RANT: The state of web-design practice
or
My kingdom for a theory!
I've been working on a Hamlet page, from a Joycean perspective:
http://www.robotwisdom.com/jaj/ulysses/hamlet.html
and I wanted to offer some mirrors of the basic etext of the play,
so I started a Google search, doing view-source on each one to see
(especially) if there were name-anchors (handy for scholars).
The HTML I saw was so horrifying I decided to document my quest--
below are the top 50 Google hits, with comments, followed by some
basic design-recommendations.
Probably this specific challenge is a bit unfair, because many of
these sites were created when the Web was young, and so don't
accurately reflect the current state of the art for html-design.
But my greater purpose is to draw attention to how little that
design-theory has evolved, hoping this might someday reduce these
errors.
There are many dozens of sites that just mention or quote from the
play, so to eliminate false-hits I picked a couple of rare words--
'liegemen' and 'uphoarded'-- from the start and end of the first
scene: http://www.google.com/search?q=liegemen+uphoarded
The top hit is a very nice fulltext edition, at a site with the
offputting name 'Chemicool.com':
http://chemicool.com/Shakespeare/hamlet/full.html
An identical page that strangely doesn't show up at all for this
query: http://tech-two.mit.edu/Shakespeare/Tragedy/hamlet/full.html
Doing 'view source' reveals that these have named anchors for every
line, which is useful-- if a bit excessive. The html-formatting is
limited to the workmanlike BLOCKQUOTE and B.
The 2nd-place winner is: http://www.clicknotes.com/hamlet/H11.html
which annoyingly magnifies (for me, anyway) everything with
<FONT SIZE=4>. Navigation is minimal, and design-errors abound.
Site #3 is: http://www.uoregon.edu/~rbear/shake/hamlet.html
which uses the charming and talented <PRE> tag to wrap the full raw
'txt' text. Not very readable-- apparently its high rating is
inherited from better-formatted etexts on the same site.
Site 4 is Bartleby, which I avoid because it's overformatted and has
obnoxious popups: http://www.bartleby.com/70/4211.html
(This site is perhaps more tragic than IMDb, since Bartleby started
out as a free academic project but has sucked many important etexts
into its commercial black hole.)
Site 5 is broken up act-by-act, and uses the lovely but untalented
<tr> and <td> tags (no name-anchors):
www.gh.cs.usyd.edu.au/~matty/Shakespeare/texts/tragedies/hamlet_1.html
Site 6 is PDF: http://www.pinkmonkey.com/dl/library1/hamlet.pdf
Site7 is classic W3C goofiness, which claims to be simplified XML:
http://www.w3.org/People/maxf/XSLideMaker/hamlet.html
Every line is a paragraph, no anchors, no navigation outside the page
(!?).
Site8 is RTF, part of a tutorial on DSSSL:
http://csgrs6k1.uwaterloo.ca/~dmg/dsssl/tutorial/tutorial.html
(Someday Google will probably recognise that this pagerank is not
really applicable to this query! A surprising proportion of the top 50
are tutorial demos.)
Site9 is embarrassingly amateurish 1995-era hand-coded HTML:
www.engl.uvic.ca/Faculty/MBHomePage/ISShakespeare/Ham/Ham1.1.html
Site10 uses a stylesheet whose only relevant CLASS is 'verse':
http://www.bragi.com/classics/s/ws1564/h01.shtml
There's no anchors, but it's a decent act-by-act edition. (A website
to watch.)
Site11 is About.com, which I avoid like the plague for its overdesign
and noxious sticky-frames:
http://shakespeare.about.com/library/blhamlet_1_1.htm
With my default settings, I see a 15-character-wide column of text,
and view-source reveals absurd quantities of formatting-junk.
Site12 is extremely-minimally formatted (EM, STRONG, BR, no P!?):
http://www.compusmart.ab.ca/hamlet/act1sc1.htm
They _do_ link a onepage summary, which is linked back to the
individual acts. (I think they're the only one of the top 50 to think
of this!?)
Site13 is an MSWord abortion, with each line a centered paragraph:
http://www.kidslink.co.uk/shakespeare/hamlet.htm
We're spared the background image because Word linked it only from the
local C: drive.
Site 14 has made it easy to enjoy the background image by adding an
extra nbsp-paragraph between each speech:
http://www.entrenet.com/~groedmed/Honei.html
Site15 is bland, unanchored HTML (and, alas, inept commentary):
http://www.netcomuk.co.uk/~iandel/text11.html
Site16 has 404ed, but Google's cache reveals unwarranted silliness:
http://information-resources.com/Library/library83.html
Site17 is in .doc format:
http://www.shakespearehelp.com/textfiles/hamlet.doc
Site18 is badly-formatted txt:
http://www.ugcs.caltech.edu/~cs2/cs2/shakespeare/tragedy/hamlet1.txt
Site19 is an adventurous historical approach, but looks like crap from
my platform:
www.humnet.unipi.it/anglistica/dente/lavori/kemble/1807/a1s1.html
Site20's source bears quoting (every single speech is this bad!):
http://pd.sparknotes.com/shakespeare/hamlet/section2.html:
<!-- begin par 2 -->
<tr><td colspan=2>
<table border=0 cellpadding=0 cellspacing=0 width=100%>
<tr><td><span class='pdtext_text'>
<span class='pdtext_person'>Ber.</span>:
Who's there?</span></td><td align=right valign=top width=30>
</td></tr>
<tr><td><img src='http://img.sparknotes.com/graphics/shim.gif'
width=50 height=8></td></tr></table>
</td></tr>
<!-- end par 2 -->
For all that, there's no anchors... and there's no excuse for leaving
the character-names abbreviated! (Talk about penny-wise and pound-
foolish...) All that javascript quickly crashed my browser, to boot.
Site21 commits the egregious stairmaster-fallacy (no 'next scene'
link): http://www.shakespeare.com/FirstFolio/HAMLET/1.1.html
It also wastes a TABLE on each speech:
<p><table cellspacing='5'><tr><td class='speaker' width='200'>
BERNARDO</td><td></td>
<td width='500'>Who's there?</td><td></td></tr>
</table></p>
(I think those empty "<td></td>"s are for occasional line-numbers.)
It also claims to be 'first folio' but the spelling and punctuation
are certainly modernised.
Site22 is clumsily autogenerated from XML:
http://qmir.dcs.qmw.ac.uk/Focus/FocusRetrieval/hamlet_fc.xml.html
There are name-anchors for every damn thing but the html isn't even
stylesheeted, just BR, B, and I (no P again!?!?).
Site23 is another pdf:
http://www.hn.psu.edu/faculty/jmanis/shakesp/hamlet.pdf
Site24 is in Romania (?) and sets off a Netscape bug that displays
everything in 'Chicago' font (though every speech is a P with the font
individually reset to Arial!):
http://www.x3m.ro/ScoalaOnline/biblioteca/shakehamlet.html
Site24 squeezes the text into another narrow column, and also uses the
scant BR-B-I-only formatting:
http://absoluteshakespeare.com/plays/hamlet/a1s1.htm
Site25 sets fontsize to +1, and relies heavily on nbsp for formatting:
http://www.english.uga.edu/hc/xml/exercises/Hamlet/nhamlettest.html
Site26 is a popup-poisoned Angelfire site, but looks quite nice...
until you view source:
http://www.angelfire.com/nb/classillus0/hamlet/hamlet.html
Site27 is a sad, misguided academic effort ('ENG570' is surely
engineering, not English!):
http://cs.engr.uky.edu/~raphael/courses/ENG570/hamlet.html
<div class=line><strong>Line 7</strong>
'Tis now struck <span class=time>twelve</span>;
get thee to bed, <span class=person>Francisco</span>. </div>
Site28 is apparently the 'all-P' edition:
http://www.uea.ac.uk/~p200/LiteraryWeb/Shakespeare%20Texts/Hamlet.html
Site29 looks like Chemicool without the name-anchors:
http://www.lapaf.org/site/building1/library/shakespeare/tragedy/hamlet/hamlet.1.1.html
(Lots of meaningless layers in the url, too.)
Site30 invokes the Chicago-font bug, but has very silly source:
http://www.literatureark.myetang.com/books/hamlet/act1.htm
<p><font size="4">Ber. Who's there.?</font></p>
Site31 is even sillier (and spams its keywords-header):
http://www.authorweb.com.au/plays/hamlet.html
<H4>FRANCISCO For this relief much thanks: 'tis bitter cold,<BR>
And I am sick at heart.</H4>
Site32 is quite mystifying but appears to be a demo of using XML to
print individually-color-coded versions of the play for each actor:
http://www.pitt.edu/~ejshaw/hamlet4.html
<p>sp3: BERNARDO<br>
<font color="red">L.1 -- </font>Long live the king!</p>
Site33 achieves a new level of bizarrohood:
http://www.stud.uni-hamburg.de/users/peter/c/theatre/script.txt
(text "Elsinore. A platform before the castle.")
(domove light0 "blendin")
(walk bernado "3pos" "3w")
(say bernado "Who's there?")
(start francisco "lookRight" 1)
(start francisco "faceAnger" 1)
(say francisco "Nay, answer me: stand, and unfold yourself.")
(say bernado "Long live the king!")
If you have their Java library, I guess this runs an animated 3D movie
of the play:
http://www.stud.uni-hamburg.de/users/peter/java/movie/hamlet.htm
Site34 restores normalcy with the indispensable Richard-Chamberlain-
tribute edition (all centered, with lines individually bolded and
redded): http://www.richardchamberlaintribute.com/Hamlet1.html
<center><b><font color="#660000">Bernardo: Who's there.?</font></b>
Site35 is freeyellow.com. DON'T GO THERE. (You have been warned.)
http://shakesp.freeyellow.com/34.htm
Site36 seems to be for teaching English to Italians, so I'll be kind:
www.middlesmoor.com/teachers%202001/12.2%20Hamlet%20opening%20scene.htm
<p style="word-spacing: 0; margin-top: 0; margin-bottom: 0">
<font size="3"><b>Bernardo. </b> Who's there?</font></p>
Site37 offers both English and Klingon texts:
http://www.psiphi.org/cgi/upc-db/excerpt/0671035789.html
The stylesheeting is underwhelming:
<P CLASS="descr"><I>Bernardo:</I> Who's there?</P>
Site38 has whimsical/irrelevant 'annotations':
http://www.undergrounde.com/0002HM/ActOne.htm
Site39 does the Chicago-font thing (apparently side-by-side Japanese):
http://www.hi-ho.ne.jp/karonv/Hamlet.htm
Site40 is pdf:
members.ams.chello.nl/cjjacobs/program/William_Shakespeare.Tragedies.pdf
Site41 is trueblue xml:
http://melusine.eu.org/syracuse/xml/xml20000306/hamlet/hamlet.xml
<PLAYSUBT>HAMLET</PLAYSUBT>
<ACT>
<TITLE>ACT I</TITLE>
<SCENE>
<TITLE>
SCENE I. Elsinore. A platform before the castle.
</TITLE>
<STAGEDIR>
FRANCISCO at his post. Enter to him BERNARDO
</STAGEDIR>
<SPEECH>
<SPEAKER>
BERNARDO
</SPEAKER>
<LINE>
Who's there?
</LINE>
</SPEECH> etc
Site42 uses the rarely-seen all-BR-and-CENTER combo:
http://www.geniereader.com/Literature/Plays/Hamlet/ACT_I_SCENE_I.htm
Site43 is an email-archive trying to identify the Gutenberg edition:
http://www.shaksper.net/archives/1991/0291.html
Site44 is boring, though view-source has trouble with its
one-line-per- scene:
http://www.rutgersprep.k12.nj.us/upperschool/english/hamletfolder/1actHamlet.html
Site45 is just word-frequencies:
http://www.lost.co.nz/files/lang/hamlet.txt
32,457 words, 4,700 unique words
the, and, to, of, you, a, I, my, Hamlet, in, It, that, is, Not,
lord,
his, this, But, with, for, your, me, be, As, he, what, king, so,
him,
have, will, Horatio, do, no, We, are, on, Cladius, Polonius, queen,
all, our, by, shall, or, if, O, Good, Come, Laertes, thou, They
[etc]
Site46, oddly, is the same:
http://www.mta.link75.org/shake/hamfreq.html
Site47 is Polish, with the Chicago-glitch:
http://raster.art.pl/forum/komentarze.php?watek=36
Site48 is unremarkable, except for some mostly-empty name-anchors:
http://www.endoxa.it/bramante/amleto/009.htm
Site49 is txt, but appears to have been cut-and-pasted from an html
file with some linenumbers:
http://www.ime.usp.br/~yoshi/mac338/exx/quick_string/Hamlet.txt
Site50 is the ALL-CAPS FOR THE HEARING-IMPAIRED (as read by Garret
Morris) version: http://www.cs.colorado.edu/~ralphh/2270/8/hamlet
So out of 50, almost every one was different, but there were only
maybe two that seemed worth my linking.
For comparison here's how I did the 'theatrical' chapter of Ulysses:
http://www.robotwisdom.com/jaj/ulysses/circe1.html
- basic formatting with blockquote, center, CAPS, and i
- numbered anchors every 25 lines (using standard Gabler-linenumbers)
- unobtrusive links to annotations every 100 lines, with links back to
the text that create a splitscreen window
- a full summary keyed back to the name-anchors:
http://www.robotwisdom.com/jaj/ulysses/summary.html
- a minimal up-link at the top (Joyce insisted on uncluttered
page-designs), a next-link at the bottom, plus a (recently-added)
random-access menu at the bottom for all 18 chapters
- black text on light-colored plain background... no effing fonts!
- read your own pages, repeatedly (ie, eat your own dogfood)
--
Robot Wisdom Weblog: http://www.robotwisdom.com/ "If you worry that
reading the news online will rob you of the serendipity factor you get
with the newspaper, Jorn Barger solves the problem." --Dan Gillmor
Daniel R. Tobias
> below are the top 50 Google hits, with comments, followed by some
> basic design-recommendations.
I'm not sure what your point is supposed to be... what you've
documented here is a wide variety of approaches to the structure and
presentation of that Shakespearean piece, ranging from
presentationalist sites trying for visual effects to structuralist
sites attempting logical markup of some sort or other; the coding
techniques ranged from plain ASCII to bare-bones HTML paragraph tags
to tables to frames to stylesheets... lots of different approaches.
Your comments aren't really clear enough to let me see why you think
they all suck, or indicate exactly what you think all of those site
developers should have done instead.
--
Dan
Dan's Web Tips: http://webtips.dantobias.com/
Jorn Barger
> I'm not sure what your point is supposed to be...
Don't assume I limited myself to _one_.
> what you've
> documented here is a wide variety of approaches to the structure and
> presentation of that Shakespearean piece, ranging from
> presentationalist sites trying for visual effects to structuralist
> sites attempting logical markup of some sort or other; the coding
> techniques ranged from plain ASCII to bare-bones HTML paragraph tags
> to tables to frames to stylesheets... lots of different approaches.
> Your comments aren't really clear enough to let me see why you think
> they all suck, or indicate exactly what you think all of those site
> developers should have done instead.
At a minimum, they ought to be optimised for readability, with enough
name-anchors for scholars, and links to auxiliary texts (summaries, etc).
(Did you read all the way to the end?)
> http://webtips.dantobias.com/
Comments:
- making your name a link is ambiguous-- is it just a mailto? (one
shouldn't have to mouseover to know, any more than one should have
to visit a page to find out its (general) content)
- columns: I hate 'em. I have to scroll right to read your text
- toc: I also hate reading blue underlined text. reading your blurbs
I have no idea what the pages will say-- blurbs should condense the
content, not abstract it. (make the toc-page a long condensation of
all your tips, with links to the _explanations_.)
- intro http://webtips.dantobias.com/intro.html
- embedding an 'up' link in the title is confusing
- next links belong at the bottom, not the top
- I think the TimBL quote should be at the top, not in a side-column
- tip#1 is way abstract, and so belongs at the end
- tip#2 (heh, i think i _started_ that war)
- ww3: as contentist i detest your travesty of my views
- links: same-old unreadable abstractions, not even mentioned in the
linkblurb!
- forcing: http://webtips.dantobias.com/force.html
a long list of questions you don't plan to answer is a pretty cheap shot
- folders: http://webtips.dantobias.com/subdir.html
- the comment about weenies is pointlessly neurotic
- tip#1 is tautological
- the most important thing about directory-structure is that you be
able to _remember_ where you put stuff-- this is tricky
- directories based on corporate structural hierarchies is a big no-no
(see Jakob N)
- they should be shallow and wide, not deep-- urls must be under 80 chars
- tip#2: changing directory structures is unavoidable-- what's important
is to leave redirect-pages behind when you do.
- a clever idea suggested by a visitor was to make _all_ new pages the
index page of a new subdirectory, just in case. (I haven't, yet.)
- '.htm' is more universal, and the only reason not to use it is anti-MS
prejudice (which is a plenty good reason, for me)
- best policy is all lowercase in urls-- uppercase is just asking for
trouble
- an index page should condense and link all the subpages in the
directory
- 'home.html' is another common default name
- a lot of that 'slash' business is pretty low priority
- physiological: http://webtips.dantobias.com/logical.html
GRRRR. Not that I want to re-open ww3 here, but just to restate my views:
- page-design is primarily about specifying relative degrees of emphasis
- 'em' and 'strong' are _less_ precise, not more (there are thousands
of ways to subtly vary emphasis)
- literature has never used 'bold', because it disrupts the reading eye
- the way to approach varying window-sizes and default fonts is to aim
for pages that scale gracefully
- TimBL didn't grasp this, so H1-6 are really worthless
- the structuralists scorn for presentationists also misunderstands the
necessity of giving the designer control over these relative emphases
[bailing out]
I notice several of your side-quotes seem to be filler-- is this a
consequence of a template that demands something go in that slot???
(If so, it's a fine argument against the structuralist mindset--
the reader/document should come first, not the effing database.)
Without having read everything, here's what I missed (vis-a-vis Hamlet):
- readability, readability, readability: you want to make pages that
are easy to read, and all else follows from that
- anchors: a tricky subject-- did you deal with it? (I did a search for
it and got dropped into an irrelevant new-windows page)
- do you mention skip-a-line beween paragraphs? many hamlet-etexts fail
to.
- navigation: do you cover 'next' links? my current policy is to put
a huge toc at the bottom of most pages-- it really proves convenient.
- google-research: do you cover the importance of including links to
resources? your own style is to segregate them at the end, this is
very bad because people have to re-orient to the full range of topics--
they should be non-obtrusively embedded at the appropriate point in
the text.
- linktext: don't make people read a lot of underlined blue. make sure
you describe what they'll get when they follow a link.
- pagelength: long pages are good.
Michael Stutz
> The HTML I saw was so horrifying I decided to document my quest--
First of all, thanks for the good laugh ...
> below are the top 50 Google hits, with comments, followed by some
> basic design-recommendations.
I would have assumed that the Project Gutenberg etext would've been
listed first, but it didn't even make the *top 50*? Hmm.
So I did a search myself, and found it -- but it took some while even
Googling on ``Hamlet "Project Guteberg"'':
ftp://ibiblio.org/pub/docs/books/gutenberg/etext97/1ws2610.txt
And _then_ I saw with horror that the text is proprietary! I don't
know the whole story yet, but I can't believe that PG would do that if
a public domain text were available ... but it appears that The
Complete Works of William Shakespeare in its entirety as distributed
by PG is a proprietary work whose copyright is held by an organzation
that calls itself "The World Library." I haven't looked to see if this
"library" holds copyrights on other works, or what the deal is. But
this text is unusable.
If you were to make your own Hamlet page now, even a minimal one just
throwing up some anchor names on an etext, where would get the source
from? (Clicking thru some of the specimens you list below I didn't
recall seeing too many of them citing the source for the text they
used.)
> Probably this specific challenge is a bit unfair, because many of
> these sites were created when the Web was young, and so don't
> accurately reflect the current state of the art for html-design.
Yep. But how many old sites can you list whose design has _improved_
with age? I know plenty that have gotten worse. Classic examples:
http://imdb.com/
http://amazon.com/
http://yahoo.com/
http://photo.net/
(Yeah, I like Philip too, but I think that "relaunch" lost the grace
of the site he originally designed.)
So who's had it and _kept_ it? Drudge hasn't changed at all in years,
and
he's still got one of my all-time favorite designs ...
Any relatively _new_ sites whose design is very good? Google's the
classic example here, I suppose, but I do have quibbles with their new
nav-gifs. The old ones were so much more pleasing than the
off-the-shelf stuff they replaced them with -- it hit me the same way
the "Builder's Square" effect does on contemporary home-improvement
projects.
> But my greater purpose is to draw attention to how little that
> design-theory has evolved, hoping this might someday reduce these
> errors.
Key with that, I think, is that we need better software for rendering
& displaying HTML. If we only design according to how our current
browser programs work, we're going to have a 'reactionary'
effect. Of course working on both is much more difficult. The great
genius Henry Ford only designed one half of his invention -- he got
the production-line auto out there, but he left it for the politicians
and local bureaucrats to come through with the roads ...
I'll tell you what, though. lynx has really come a long way. It's a
real pleasure to use nowadays.
> Site 4 is Bartleby, which I avoid because it's overformatted and has
> obnoxious popups: http://www.bartleby.com/70/4211.html
> (This site is perhaps more tragic than IMDb, since Bartleby started
> out as a free academic project but has sucked many important etexts
> into its commercial black hole.)
Ah, great. Is this like The World Library situation then? Proprietary
etexts?
IMDb will always be greatly tragic -- we the people of the net
_contributed_ to their database! (Though that property can also work
to our advantage...)
I've been thinking that copyleft might actually be the thing that
ends up _saving_ Amazon. Not just the IMDb but their whole catalog.
But if they don't, no matter -- we will replace the IMDb with a free
one that is even better.
http://linart.net/archive/msg01017.html
> Site9 is embarrassingly amateurish 1995-era hand-coded HTML:
Even as automated conversion tools improve, I think that a work whose
HTML design aspires to Art will always necessitate at least minor
hand-coding.
> Site11 is About.com, which I avoid like the plague for its overdesign
> and noxious sticky-frames:
> http://shakespeare.about.com/library/blhamlet_1_1.htm
> With my default settings, I see a 15-character-wide column of text,
> and view-source reveals absurd quantities of formatting-junk.
Never read Shakespeare on a page that has a link called "Privacy
Policy."
> Site13 is an MSWord abortion, with each line a centered paragraph:
> http://www.kidslink.co.uk/shakespeare/hamlet.htm
> We're spared the background image because Word linked it only from the
> local C: drive.
Hmm ... kinda looks to me like they were clearly inspired by your
weblog,
no? But they forgot to link the last few words of each line! (...to an
anchor NAME on the next line, of course -- to enable easy
click-to-read because everybody knows surfers don't scroll)
> Site27 is a sad, misguided academic effort ('ENG570' is surely
> engineering, not English!):
> http://cs.engr.uky.edu/~raphael/courses/ENG570/hamlet.html
I don't know COBOL.
> - black text on light-colored plain background... no effing fonts!
Your black-on-lights are nice -- I like the 'minty' Joyce backgrounds
especially -- but black-on-white is massively irritating to me, bad on
my eyes.
Have you ever tried light text on plain black background? My old
(~2000) pages are like that:
My writing environment is all light-on-black now too -- I've gone all
the way with it, couldn't have it any other way. I cringe at giant
white windows with black text. (I wonder if the contrast is just
different on the Mac.)
And it seems to work. I've noticed a dramatic improvement in my vision
since making the switch. I wear contact lenses, and this year the doc
actually lowered the strength of my prescription thanks to it (well,
plus experiments with Bates method & orgone pad).
Michael Stutz
> - tip#2: changing directory structures is unavoidable-- what's important
> is to leave redirect-pages behind when you do.
I'm beginning to doubt this wisdom, since no urls are probably
effectively-permanent, anyway ... and 'cause people don't change their
old links! So what I've tried is automatically sending 404s to a ToC
page ...
> - a clever idea suggested by a visitor was to make _all_ new pages the
> index page of a new subdirectory, just in case. (I haven't, yet.)
Yeah, and I never went all the way with it (yet) but it's really
awesome for a book-in-progress, for when you're researching topics and
getting pages out there in chunks over time.
> - '.htm' is more universal, and the only reason not to use it is anti-MS
> prejudice (which is a plenty good reason, for me)
Do you really think so? With all the superior *bsd - linux - gnu -
unix - etc systems that dominate the net (as far as servers)?
I just woke up AltaVista to get some figures:
.htm 237,121,217
.html 333,609,618
That's oddly close. Though I wouldn't trust 'em (the hitrate for
"windows" mysteriously jumped by like 1000% after I published an
article ~1995, with screenshots, showing how a search for "linux"
brought thousands of more hits than the behemoth. The ratio's now back
to 1:2 in freedom's favor).
Daniel R. Tobias
You mean like your home page? I found your color scheme rather
difficult to read, myself...
> > http://webtips.dantobias.com/
>
> Comments:
Thanks for your comments. I always like to hear others' reviews of my
work, even if I don't always agree with what they say.
> - making your name a link is ambiguous-- is it just a mailto? (one
> shouldn't have to mouseover to know, any more than one should have
> to visit a page to find out its (general) content)
That's a point... though at least I didn't use annoying JavaScripts to
suppress the normal mouseover clues as to where a link goes.
> - columns: I hate 'em. I have to scroll right to read your text
Sorry about that. Until a few weeks ago my site was in the standard
"purist mode" with no layout tables or anything like that, but I got
enough of an evil burst of presentationalism that I "spiffied up" the
presentation in the latest redesign of my sites, including adding a
left column for navigation menus, search fields, cutesy quotes and
pictures, tools, ads, and other stuff both utilitarian and decorative.
I refrained from forcing hardcoded pixel widths for the main content
area, so it should resize gracefully to a wide range of window widths,
but the title graphic on the main page does push the page out on
smaller screens.
> - toc: I also hate reading blue underlined text. reading your blurbs
> I have no idea what the pages will say-- blurbs should condense the
> content, not abstract it. (make the toc-page a long condensation of
> all your tips, with links to the _explanations_.)
That's your opinion... it doesn't match mine. I believe in keeping
tables of contents brief and abstract, with the actual content in the
linked pages... to me, the link text and blurbs are there to give a
general idea of what can be found on the linked pages, not to
substitute for them.
> - intro http://webtips.dantobias.com/intro.html
>
> - embedding an 'up' link in the title is confusing
> - next links belong at the bottom, not the top
I follow the "more than one way to skin a cat" theory of site
navigation links; I don't limit myself to a single "up", "next", or
"previous" link, but put them in everywhere it makes sense. To me,
it's logical for the name of the site (or its logo, if it has one) to
link back to the home page. So does the "Home" button on the left
edge, and the leftmost item on the "breadcrumb bar" structural
navigation section at the top of each page, and the "Up" links on
pages that are just one level beneath the home page. Thus, no matter
which of these things the user is more familiar with, it will work.
The Next/Prev row is both at the top and the bottom. There are also a
full set of <LINK> tags giving such structural links; if browser
support for these were better, I might be able to forego the
"Next/Up/Prev" bars in the page body, but at the moment, other than
Lynx and Mozilla, the <LINK> tags are ignored in most browsers.
> - I think the TimBL quote should be at the top, not in a side-column
It used to be, but in my redesign I decided to "slot" a quote in the
left column of each page -- some of them are serious, some humorous.
It's one of the things I did to put relatively extraneous things out
of the way of the main content.
> - tip#1 is way abstract, and so belongs at the end
I wanted to open with the abstract concept and proceed from there to
more concrete explanation of it.
> - tip#2 (heh, i think i _started_ that war)
> - ww3: as contentist i detest your travesty of my views
I've never really been able to pigeonhole you in my categories... I
see a true contentist as, for instance, somebody who just types in
their content into some convenient program like MS Word or FrontPage
and puts up the HTML code excreted by that program onto the Web
without thought for structure or aesthetics... that doesn't describe
you very well.
> - directories based on corporate structural hierarchies is a big no-no
> (see Jakob N)
I thought you didn't like that guy! Myself, I mostly agree with him,
but reserve the right to ignore him on a case by case basis as I wish.
Probably, in many cases, a corporate structure hierarcy won't be
appropriate for the Web site, but it might be sometimes... certainly,
it's likely to be easier to maintain that way because it follows the
division of responsibility between the different people involved.
> - they should be shallow and wide, not deep-- urls must be under 80 chars
Whose rule is that?
> - tip#2: changing directory structures is unavoidable-- what's important
> is to leave redirect-pages behind when you do.
Or server redirects... I used .htaccess files to set up redirects from
obsolete URLs at the time of my recent redesign.
> - a clever idea suggested by a visitor was to make _all_ new pages the
> index page of a new subdirectory, just in case. (I haven't, yet.)
That's a little too extreme, probably, but it's a good idea to make
new directories any time you think a page is likely to become the
parent of many sub-pages.
> - '.htm' is more universal, and the only reason not to use it is anti-MS
> prejudice (which is a plenty good reason, for me)
Only if you really expect that the pages will need to be stored or
served on a system with an old-fashioned limited operating system...
surfing the Web, even from such an archaic system, causes no problem
even if site URLs have longer extensions in them.
> - best policy is all lowercase in urls-- uppercase is just asking for
> trouble
I agree with that in general.
> - an index page should condense and link all the subpages in the
> directory
Well, as I said, I prefer to abstract rather than condense, but I do
agree that each subdirectory's index ought to link its subpages, at
least in most cases.
> - page-design is primarily about specifying relative degrees of emphasis
> - 'em' and 'strong' are _less_ precise, not more (there are thousands
> of ways to subtly vary emphasis)
Well, <B> and <I> don't give any greater degree of precision in this
area. Stylesheet classes, however, can express many variations.
> - the way to approach varying window-sizes and default fonts is to aim
> for pages that scale gracefully
That's always what I aim for.
> - TimBL didn't grasp this, so H1-6 are really worthless
With stylesheets, you can make lots of suggestions regarding the
presentation of headers, like all other elements. I do this myself on
my pages.
> - the structuralists scorn for presentationists also misunderstands the
> necessity of giving the designer control over these relative emphases
The designer doesn't "control" anything; he/she/they can only suggest.
This is true whether presentationalist tags/attributes or stylesheets
are used.
> I notice several of your side-quotes seem to be filler-- is this a
> consequence of a template that demands something go in that slot???
> (If so, it's a fine argument against the structuralist mindset--
> the reader/document should come first, not the effing database.)
Yeah, I did have to stretch sometimes to come up with a quote for each
page, but it was a conscious decision on my part to make this a part
of my standard page format.
> - anchors: a tricky subject-- did you deal with it? (I did a search for
> it and got dropped into an irrelevant new-windows page)
I'm trying my best to set up search keywords to go to all reasonable
pages in the site, but I can't always anticipate everything everybody
might want to search for, and some topics don't have a page
specifically about them.
> - do you mention skip-a-line beween paragraphs? many hamlet-etexts fail
> to.
The normal default HTML presentation does this, if the site author
didn't override it or use illogical markup like <BR> instead of <P>.
> - google-research: do you cover the importance of including links to
> resources? your own style is to segregate them at the end, this is
> very bad because people have to re-orient to the full range of topics--
> they should be non-obtrusively embedded at the appropriate point in
> the text.
I do have most of my external links at the end of pages where they
don't get in the way of my content, but I do on occasion link to
things within the main body of the text where it makes logical sense;
when my discussion is directly about something external, I'll
generally link there at the point of discussion.
> - pagelength: long pages are good.
I believe in moderation... if pages get really, really long I
sometimes break them up, but I don't feel like some site authors do
that everything needs to be chopped up into bite-size chunks. Mostly,
my page divisions are along logical lines, not arbitrary just because
pages are "supposed" to be some particular size, but sometimes I will
divide them if they've grown excessively.
--
Dan
Jorn Barger
> > I have no idea what the pages will say-- blurbs should condense the
> > content, not abstract it. (make the toc-page a long condensation of
> > all your tips, with links to the _explanations_.)
>
> That's your opinion... it doesn't match mine. I believe in keeping
> tables of contents brief and abstract, with the actual content in the
> linked pages... to me, the link text and blurbs are there to give a
> general idea of what can be found on the linked pages, not to
> substitute for them.
there's no law that says you have to choose one way-- try, as an
experiment, adding a page that extracts each tip, with links to each
explanation. you'll find people prefer it, i bet.
> > (see Jakob N)
> I thought you didn't like that guy!
i've always said i agree with almost all his points, but think when he's
wrong (esp pagelength) he's horribly destructive due to his arrogance
and pretense of 'science'.
> > - they should be shallow and wide, not deep-- urls must be under 80 chars
> Whose rule is that?
anybody who uses email or netnews.
> > - '.htm' is more universal, and the only reason not to use it is anti-MS
> > prejudice (which is a plenty good reason, for me)
> Only if you really expect that the pages will need to be stored or
> served on a system with an old-fashioned limited operating system...
my point is that if everyone used the same one, it would make things
simpler, but the one would have to be 'htm'. (today i tried to go
up a level by trimming away a filename, and got a 404, so i had to try
six variants: home/index/default.htm/html )
> > - page-design is primarily about specifying relative degrees of emphasis
> > - 'em' and 'strong' are _less_ precise, not more (there are thousands
> > of ways to subtly vary emphasis)
> Well, <B> and <I> don't give any greater degree of precision in this
> area. Stylesheet classes, however, can express many variations.
B and I are absolutely precise: they say what they mean and you know
what you'll get.
> > - TimBL didn't grasp this, so H1-6 are really worthless
> With stylesheets, you can make lots of suggestions regarding the
> presentation of headers, like all other elements. I do this myself on
> my pages.
what percentage of people surf with stylesheets on, these days? i'm
sure the quantity who _don't_ is big enough to make it important to
have nice-looking pages even for them-- which appears to be tricky,
since stylesheeted pages often appear to me like unformatted database
dumps.
> > - the structuralists scorn for presentationists also misunderstands the
> > necessity of giving the designer control over these relative emphases
> The designer doesn't "control" anything; he/she/they can only suggest.
If you're driving a car, and your steering wheel comes loose, your
degree of control drops. It's true that before you didn't 'really'
have control, because a giant commie robot could have pulled alongside
and lifted your vehicle off the highway with its magnetic claw... but
that's a dumb way to argue.
> > - do you mention skip-a-line beween paragraphs? many hamlet-etexts fail
> > to.
> The normal default HTML presentation does this, if the site author
> didn't override it or use illogical markup like <BR> instead of <P>.
however they did the markup, it's important for online readability that
those lines be skipped.
Someone asked what my point was, and I wasn't ready to limit it to one...
but I think I do have a main point, which is that none of those 50
Hamlets' html gave a sense of well-informed choices being made... and
I blame the html community for failing to agree on a coherent set of
basic principles (readability, readability, readability).
.
Jorn Barger
> I would have assumed that the Project Gutenberg etext would've been
> listed first, but it didn't even make the *top 50*? Hmm.
Probably all their fineprint at the top of every text pushes the keywords
too far down!
> If you were to make your own Hamlet page now, even a minimal one just
> throwing up some anchor names on an etext, where would get the source
> from?
I'm thinking of doing it, but I'll tweak stuff enough (based on
scholarly editions) that the original will be unenforceable.
> Yep. But how many old sites can you list whose design has _improved_
> with age?
Very scary, yes.
> Drudge hasn't changed at all in years, and
> he's still got one of my all-time favorite designs ...
Eck-- columns, and achronological order. I've wasted hours and hours
(cumulatively) trying to find newly-added headlines there.
> > But my greater purpose is to draw attention to how little that
> > design-theory has evolved, hoping this might someday reduce these
> > errors.
> Key with that, I think, is that we need better software for rendering
> & displaying HTML.
How so? Like simulated previews for multiple platforms?
> > Site 4 is Bartleby, which I avoid because it's overformatted and has
> > obnoxious popups: http://www.bartleby.com/70/4211.html
> > (This site is perhaps more tragic than IMDb, since Bartleby started
> > out as a free academic project but has sucked many important etexts
> > into its commercial black hole.)
> Ah, great. Is this like The World Library situation then? Proprietary
> etexts?
Not that bad, I don't think. Someone needs to boldly rip them, I guess.
> I've been thinking that copyleft might actually be the thing that
> ends up _saving_ Amazon. Not just the IMDb but their whole catalog.
How so?
> > Site9 is embarrassingly amateurish 1995-era hand-coded HTML:
> Even as automated conversion tools improve, I think that a work whose
> HTML design aspires to Art will always necessitate at least minor
> hand-coding.
Yes, I always handcode when I want fine control (like the whole Ulysses
edition).
> Have you ever tried light text on plain black background? My old
> (~2000) pages are like that: http://dsl.org/comp/screen/
I think you'll find the readability is a lot more plaform-variable
with light-on-dark. Thin fonts can crumble to dust...
> My writing environment is all light-on-black now too -- I've gone all
> the way with it, couldn't have it any other way. I cringe at giant
> white windows with black text. (I wonder if the contrast is just
> different on the Mac.)
Possibly. For me, they just look dull-witted (ie boring).
.
Michael Stutz
> jo...@enteract.com (Jorn Barger) wrote in message news:<16e613ec.02041...@posting.google.com>...
> >
> > At a minimum, they ought to be optimised for readability,
>
> You mean like your home page? I found your color scheme rather
> difficult to read, myself...
Do very many browsers today have the ability to override author's
color schemes completely? Because while I like to see the author's
preferred choice(s), especially for books or texts I like, for general
'browsing' I would like the whole Web to be drawn in the color schemes
of my choosing.
It's an unexpected joy for me to get pages with black-on-grey text in
an older CSS-less browser, reason being (I suspect) they'd specified
all their colors in stylesheets and left the <body> tag blank!
> I follow the "more than one way to skin a cat" theory of site
> navigation links; I don't limit myself to a single "up", "next", or
> "previous" link, but put them in everywhere it makes sense. To me,
> it's logical for the name of the site (or its logo, if it has one) to
> link back to the home page.
Yeah ... or the name of the book or work or whatever it is you're
reading will bring you back to its cover page. I put variations of
next/prev/cover/index links at the top and bottom of every chapter
(page) in the ebook edition of my computer how-to book, _The Linux
Cookbook_, for example:
http://dsl.org/cookbook/cookbook_19.html
For articles and single-page works, I've most often put a single line
of nav links at the top of the page which more or less correspond with
the site's directory structure.
But on the whole I'm actually not in favor of _any_ navigation text
that is extra to the document, certainly not icons or huge sidebars or
tables or tabs that must be put on every page. As for that thin bar of
text that I use, I'd like to find a way to take them all off, but it's
still quicker for visitors to click than it is for them to hack the
URLs.
Philip Greenspun said that designers could learn all they really
needed to know about site design from pages 146-9 of _Visual
Explanations: Images and Quantities, Evidence and Narrative_ by Edward
Tufte (1997; Graphics Press). I went to the library and checked those
pages out. He's right.
``The screen should contain information, not navigation or
administration icons. The information should become the interface,
i.e., clicking on a word that was itself informational should take
you to a screen with more detailed information.''
(From Greensun's article, ``What can we learn from Jakob Nielsen?'':
<http://www.arsdigita.com/asj/nielsen/>)
This is how I approach navigation. Sometimes it seems to be necessary
(like that line of text I can't get away from), but the ideal that I
aspire toward is for any page to contain the work that is published
there itself and nothing else -- so a text-dump of that page will
output a nice plaintext version of your article or chapter or whatever
it is you got at that URL.
> > - they should be shallow and wide, not deep-- urls must be under 80 chars
>
> Whose rule is that?
http://giving.this.url.com/directory/long/long/long/on-usenet/will-wrap-and-the-
url-will-break/dot.dot.dot
Alan J. Flavell
> Do very many browsers today have the ability to override author's
> color schemes completely?
It's a normal and relatively widespread feature to find in a browser,
certainly: maybe independently or maybe coupled with other
accessibility features such as font size. Some of them (Opera) offer
a button to switch between author mode and user mode in a single
click, whereas others hide the option(s) away deep in some
configuration preferences accessibility menu.[1]
NN4.* versions have a nasty bug that turning off author-specified
colours is effective for everything _except_ <font color="...">:
this can result in text becoming unreadable or disappearing entirely.
cheers
[1] It's kind-of curious how, in some browsers, the options for
achieving accessibility are some of the hardest options to find and
use. It's yet another reminder (at least, this is how I interpret
what I'm seeing) that typically, browsers are not made to sell to the
end user, but to appeal to web-page deezyners.
Jorn Barger
> st...@dsl.org (Michael Stutz) wrote:
> > If you were to make your own Hamlet page now, even a minimal one just
> > throwing up some anchor names on an etext, where would get the source
> > from?
> I'm thinking of doing it, but I'll tweak stuff enough (based on
> scholarly editions) that the original will be unenforceable.
I used Chemicool's, but massively reformatted and added value:
http://www.robotwisdom.com/web/hamlet/hamlet1.html
(still a work in progress)
Michael Stutz
> st...@dsl.org (Michael Stutz) wrote:
> > I would have assumed that the Project Gutenberg etext would've been
> > listed first, but it didn't even make the *top 50*? Hmm.
>
> Probably all their fineprint at the top of every text pushes the keywords
> too far down!
I figure that in 1971 it was necessary to distribute the texts with
all that stuff at the top of the file but now I'd like to see them
offer an alternate distribution, where you get an archive file
containing the pure etext plus another COPYING file with their
licensing and other information (perhaps a VOLUNTEER file with their
current tasklist, too)...
The only other gripe I have with PG, and I preface this by saying that
I think it's been a huge success & Michael Hart is a definite
warrior's warrior, but it seems to me that distributing texts minus
their accented characters & other high-bit marks without indicating
that their distribution differs from the original is a disservice to
the author (and readers). I think there ought to be several versions
distributed: the current unmarked 7-bit, 7-bit with indicators (like
e' for é), and a standard 8-bit character set like ISO 8859-1 with all
the proper accents.
> > Drudge hasn't changed at all in years, and
> > he's still got one of my all-time favorite designs ...
>
> Eck-- columns, and achronological order. I've wasted hours and hours
> (cumulatively) trying to find newly-added headlines there.
Think of it as like a front page of a newspaper, so that with every
update he makes it's a printing of the very latest edition -- as a
designer of such a page you don't want to stick with pure
chronological but you want to look at the message of the page as a
whole (the 'news' or state-of-the-world that you're presenting), and
balance the position of all the links ...
But what would solve your problem just _instantly_ is if he changed
the VLINK in the BODY tag so that visited links go grey. Then your
eyes scan the page without having to read the headlines to know if
you've been there ... that'd be an excellent improvement.
His links to columnists plus AP etc searches are pretty great, too.
> > Key with that, I think, is that we need better software for rendering
> > & displaying HTML.
>
> How so? Like simulated previews for multiple platforms?
No ... basically I think all browsers, antique to modern, pretty much
stink. We can go so much farther. I used to think that for serious
reading, you'd just have to print it out. I no longer think that is
so, but the software to really make this a go just isn't there yet.
Nobody has made a web _reader_ yet. I read in full-screen Emacs all
day long, and it might not be my dream system but the experience is
very pleasurable. I want the Web to feel the same. Want to see it get
optimized for reading, and for that to happen we need improvements in
both web design _and_ the software we use to read these pages. Why
can't Web pages display with the same typographic quality as TeX
output? Crisper fonts, better presentation. Clean fast pages that load
with incredible speed. I want speed -- not faster pipelines or better
modems but more efficient xfer of data _over_ those lines. 1200 bps is
just about reading speed; 2400 bps is nearly instantaneous. So what's
the holdup?
To get there, I think that pages are going to have _less_ of all this
markup and backend stuff, and _not_ more. Put all that on the reader
software and not the author. The more 'content' data and less markup
that goes over the line (and that authors have to stick into their
manuscripts), the better.
And for reading, when you want speed, and want to keep your own
colors, lynx is still pretty swell -- especially if you're running it
in X in a full-screen window with huge, crisp fonts (and the big
secret is that you can use lynx to browse & view _graphics_, if you've
got it configured to run "display" or some other image viewer).
> > I've been thinking that copyleft might actually be the thing that
> > ends up _saving_ Amazon. Not just the IMDb but their whole catalog.
>
> How so?
Well as for the IMDb, it seems inevitable that a free replacement will
come and once that happens theirs will lose all its value. If they
free theirs and it replicates, with a thousand new interfaces and
designs, it should benefit them.
They seem to have a profitability problem. For what, like nearly a
year now, they've been selling tons of books at 30% off cover price.
You can get a copy of my book for twenty dollars [1], which is cheaper
than _I_ can sell it myself. All of their trade books are discounted
like this. It sucks for authors, since we get less on the deal, but it
also sucks for them. Their margins are pretty low. They just reached
profitability now for like the first time (a penny a share), but their
CFO quit. How long can this go on? How long?
I'm very unhappy with the book publishing industry & think massive
upheaval has to happen (and predict that it will); publishers are
still 100% clueless about the net, about ebooks, etc. Right now Amazon
is a "bookstore." But its more than that, really -- a recent "feature"
mimicked Web email, showing a returning customer new "messages" they
had waiting for them (which were just advertisements for books in the
form of fake email messages).
What if Amazon were to stop trying to be a bookstore and instead
become a brokerage for publishers, as Jason Epstein suggests in _Book
Business_? If their catalog were copylefted it could easily happen.
What if some other company succeeds in doing this first? Not many
people would shop at Amazon, I would imagine.
> > Have you ever tried light text on plain black background? My old
> > (~2000) pages are like that: http://dsl.org/comp/screen/
>
> I think you'll find the readability is a lot more plaform-variable
> with light-on-dark. Thin fonts can crumble to dust...
Ah, great. The variability of display across platforms is why I've
found myself almost becoming more and more ambivalent about
presentation, beyond the basic readability -- I adore light-on-black,
but should I force this preference on all my visitors, even if I know
it'll annoy them? This is why I think colors and all these other
matters like it have to be controllable by the visitor's software.
What I'd been doing around 2000 is, when updating older pages,
changing the color specified in the BODY tag to be that of my
most-current-favorite. That way when you'd revisit a page you'd know
instantly whether or not it'd been changed since your last visit, and
visitors familiar with the site as a whole would get an instant
approximate gauge of _when_ that most recent update occurred (as would
I, when returning to a page). (I think it's also a law of good Web
design that a work should include its original publication date plus
date of most recent update.)
But I found that not all colorschemes looked equally well on all
pages, so I abandoned that approach. My page on Stafford Beer [2]
shows another color scheme I'd experimented with.
1. http://www.amazon.com/exec/obidos/ASIN/1886411484/ref%3Dnosim/michaelstutz/
2. http://dsl.org/faq/beer/
Michael Stutz
> Yep. But how many old sites can you list whose design has _improved_
> with age? I know plenty that have gotten worse. Classic examples:
>
> http://imdb.com/
> http://amazon.com/
> http://yahoo.com/
> http://photo.net/
You can't forget http://www.ebay.com/
In 1998 it approached beauty. It's barely usable now (and then only if
you click-to-agree to give up your privacy & freedom ... in exchange
for the safety of their brand-name experience).
Daniel R. Tobias
> > > - they should be shallow and wide, not deep-- urls must be under 80 chars
> > Whose rule is that?
>
> anybody who uses email or netnews.
That's a point... if you think a URL is going to need to be emailed or
posted to a newsgroup, you should keep it short. That doesn't
necessarily mean that every page in your site needs to be that
short... you don't necessarily expect every page to be deep-linked to
in email and newsgroup messages, and don't necessarily want to
sacrifice structure to make this easier in all cases.
> > > - '.htm' is more universal, and the only reason not to use it is anti-MS
> > > prejudice (which is a plenty good reason, for me)
> > Only if you really expect that the pages will need to be stored or
> > served on a system with an old-fashioned limited operating system...
>
> my point is that if everyone used the same one, it would make things
> simpler, but the one would have to be 'htm'. (today i tried to go
> up a level by trimming away a filename, and got a 404, so i had to try
> six variants: home/index/default.htm/html )
I believe .html came first, as the logical abbreviation of HyperText
Markup Language... .htm was a Microsoft bastardization.
> > > - page-design is primarily about specifying relative degrees of emphasis
> > > - 'em' and 'strong' are _less_ precise, not more (there are thousands
> > > of ways to subtly vary emphasis)
> > Well, <B> and <I> don't give any greater degree of precision in this
> > area. Stylesheet classes, however, can express many variations.
>
> B and I are absolutely precise: they say what they mean and you know
> what you'll get.
Except on a text-mode or speech browser that is incapable of doing
bold and/or italic text, where you don't know what you'll get -- maybe
the browser will just ignore the tags, or maybe they'll presume you
really meant to emphasize the text and do something of its own
devising to signify that. <BOLD> and <EM> have the advantage in such
contexts of clearly signifying that you intend emphasis. Stylesheet
classes can be used to fine-tune the desired presentation of emphasis
with great versatility; you can specify many different levels of
boldness, color changes, font changes, or other things you think
should be used.
> > > - TimBL didn't grasp this, so H1-6 are really worthless
> > With stylesheets, you can make lots of suggestions regarding the
> > presentation of headers, like all other elements. I do this myself on
> > my pages.
>
> what percentage of people surf with stylesheets on, these days? i'm
> sure the quantity who _don't_ is big enough to make it important to
> have nice-looking pages even for them-- which appears to be tricky,
> since stylesheeted pages often appear to me like unformatted database
> dumps.
I'd estimate that a very high percentage of people surf with
stylesheets on, though some of them are using browsers with fairly
buggy support, like Netscape 4.x. The newest browsers, such as
Mozilla, have quite good support for stylesheets, and even the
Microsoft abomination does stylesheets decently well.
A well-done page, however, will still be readable with stylesheets
off. Mine, for instance; I'm making lots of use of stylesheets now,
but the site still functions (though isn't as pretty) without them.
Try turning on stylesheets; you'll find my site looks better. I "kept
it simple [stupid]" so that my stylesheet code works passably even in
Netscape 4, and there's no microscopic text; in fact, I refrained from
even suggesting the main body text font face or size so that your
browser settings are respected. But some colors, margins, and font
face/size of auxiliary things like headers and sidebars are "tweaked"
in the stylesheet to improve the aesthetics of the site.
--
Dan
Dan's Web Tips: http://webtips.dantobias.com/
Dan's Domain Site: http://domains.dantobias.com/
Jorn Barger
> in email and newsgroup messages, and don't necessarily want to
> sacrifice structure to make this easier in all cases.
Long urls are just poorly-thought-out. You never have to use that
many layers of long directory-names. (And you can't possibly guess
which pages people will decide to email to their pals.)
> I believe .html came first, as the logical abbreviation of HyperText
> Markup Language... .htm was a Microsoft bastardization.
Yes, but if you believe in standardising, you have to aim low.
> > B and I are absolutely precise: they say what they mean and you know
> > what you'll get.
>
> Except on a text-mode or speech browser that is incapable of doing
> bold and/or italic text, where you don't know what you'll get -- maybe
> the browser will just ignore the tags, or maybe they'll presume you
> really meant to emphasize the text and do something of its own
> devising to signify that. <BOLD> and <EM> have the advantage in such
> contexts of clearly signifying that you intend emphasis.
Bullshit, bullshit, bullshit. That's the giant commie robot defense.
> I'd estimate that a very high percentage of people surf with
> stylesheets on
I don't care if it's 95% (and I don't think it's anywhere close to that),
I want my pages to look decent for them-- not just 'readable'.
'BLOCKQUOTE' is especially useful for this.
> A well-done page, however, will still be readable with stylesheets
> off. Mine, for instance; I'm making lots of use of stylesheets now,
> but the site still functions (though isn't as pretty) without them.
> Try turning on stylesheets; you'll find my site looks better.
With MacNetscape 4.6.1, the new patches of background color are ragged
and ugly.
Michael Stutz
> I believe .html came first, as the logical abbreviation of HyperText
> Markup Language... .htm was a Microsoft bastardization.
Yeah, I remember first time I saw ".htm" I gagged ... am pretty sure
that it didn't come out until much, much later -- someone in here's
gotta have the exact figure, but I seem to think it was around '95
when it hit. Anyone?
Isofarro
> Yes, but if you believe in standardising, you have to aim low.
Not necessarily, on two points:
* the obvious straw-man argument:
http://ppewww.ph.gla.ac.uk/~flavell/www/html-smac.html
* ISO9001 standardisation is not something you stoop down to.
>> <BOLD> and <EM> have the advantage in such
>> contexts of clearly signifying that you intend emphasis.
<strong> not <bold>?
>
> Bullshit, bullshit, bullshit. That's the giant commie robot defense.
What kind of reasoning is this? It certainly looks peculiar.
--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
AnyBrowser Campaign: http://www.anybrowser.org/campaign/
Michael Stutz
> Yes, but if you believe in standardising, you have to aim low.
Don't understand. I believe in standardizing, but that doesn't mean
dumbing down -- to the contrary, I say you've got to aim for the
opposite, and not settle for less. If it isn't good design, it isn't
worth standardizing.
Daniel R. Tobias
> >> <BOLD> and <EM> have the advantage in such
> >> contexts of clearly signifying that you intend emphasis.
>
> <strong> not <bold>?
Yes, of course... obviously, I screwed up... I do that occasionally... :)
--
Dan
Jorn Barger
> > Yes, but if you believe in standardising, you have to aim low.
> Don't understand. I believe in standardizing, but that doesn't mean
> dumbing down -- to the contrary, I say you've got to aim for the
> opposite, and not settle for less. If it isn't good design, it isn't
> worth standardizing.
If N% of users have some limitation (like MS's 3-char file-extensions)
then even if you don't like it, it makes more sense to go with 3 as
the standard. That's all I meant.
(And I've always used '.html' exclusively.)
Joel Shepherd
>
> If N% of users have some limitation (like MS's 3-char
> file-extensions) then even if you don't like it, it makes more sense
> to go with 3 as the standard.
I wasn't aware that MS's old filesystem limitation extended to their
handling of HTTP. In fact, I'm pretty sure it doesn't.
Moreover, if some users have some limitation, it makes sense to ensure
your content degrades gracefully enough to be accessible within that
limitation. That doesn't imply the highest standard you can operate
within is defined by that limitation.
> (And I've always used '.html' exclusively.)
It really doesn't matter.
-- Joel.
Jorn Barger
> > If N% of users have some limitation (like MS's 3-char
> > file-extensions) then even if you don't like it, it makes more sense
> > to go with 3 as the standard.
>
> I wasn't aware that MS's old filesystem limitation extended to their
> handling of HTTP. In fact, I'm pretty sure it doesn't.
Duh-- the 'limitation' just forced MS-users to use 'htm' instead of
'html'.
> Moreover, if some users have some limitation, it makes sense to ensure
> your content degrades gracefully enough to be accessible within that
> limitation. That doesn't imply the highest standard you can operate
> within is defined by that limitation.
*If* there's going to be an agreed standard, it can't be 'html', so
it needs to be 'htm'.
> > (And I've always used '.html' exclusively.)
> It really doesn't matter.
That you state this as a fact (rather than asking _why_ I think it matters)
indicates to me that (like the ciwah-cult in general) you're in this for
your ego, and not for the betterment of the Web.
.
Jerry Muelver
Barger) wrote:
>Joel Shepherd <joel...@ix.netcom.com> wrote:
. . .
(Jorn Barger wrote)..
>> > (And I've always used '.html' exclusively.)
>> It really doesn't matter.
>
>That you state this as a fact (rather than asking _why_ I think it matters)
>indicates to me that (like the ciwah-cult in general) you're in this for
>your ego, and not for the betterment of the Web.
>
And you, on the other hand, are in this purely for the
betterment of the Web? But, your "explanation" [1] is --
"I use Netscape 4.6.1. Anything more recent seems like a
step down for my purposes. Other Mac browsers don't work
with my elaborate macros.
"I set my default font to Geneva 18, for readability. I
override all author font-settings.
"I can't turn on stylesheets on my browser because a bug
causes many pages to display unreadably small fontsize. So
many pages that use stylesheets look like crap for me. (If I
could use them myself, I might find some reasonable uses,
but for now I stick with the tried and true.)
"Why should I specify a doctype if I'm using plain vanilla
html? They look like geeky linenoise and offend my esthetic
sense.
"I detest validation because it reeks of anal, neurotic,
schoolmarmism. If you don't want to read pages that ignore
validation, good riddance to ya."
I can assure you that your suggestions for the betterment of
the Web will receive all the attention they deserve.
[1]From: jo...@enteract.com (Jorn Barger)
Newsgroups:
comp.infosystems.www.authoring.misc,alt.hypertext
Subject: Re: The state of web-design practice
Date: 19 Apr 2002 02:29:58 -0700
Organization: http://groups.google.com/
Lines: 73
Message-ID:
<16e613ec.02041...@posting.google.com>
---- jerry
--
Michael Stutz
> If N% of users have some limitation (like MS's 3-char file-extensions)
> then even if you don't like it, it makes more sense to go with 3 as
> the standard. That's all I meant.
>
> (And I've always used '.html' exclusively.)
I getcha. I thought you were suggesting that longer extensions be
banned!
In the past I've had to use '.shtml' for pages which used server-side
includes and because of that I consciously tried to make new pages as
directories, so that as inevitable changes happened over time to the
backend server, this would be invisible to the outer url ...
Alan J. Flavell
> I wasn't aware that MS's old filesystem limitation extended to their
> handling of HTTP.
Why would _their_ handling of HTTP be relevant? I was using
longfilename.html format URLs with a web server on Windows 3.1 in
1994, but it wasn't a web server _from_ MS.
> In fact, I'm pretty sure it doesn't.
It would't particularly surprise me, in relation to an HTTPD from MS,
but then, I'd rather not run an HTTPD from them, having seem the
consequences when other folks do.
Sure: nowadays I wouldn't run SerWeb as I was doing then; I'd run
Win32 Apache, but the same holds true as far as mapping HTTP URLs to
the actual filesystem resources.
Anyway, I lost interest several years back in trying to convince
people of these obvious facts. Those who believe that URLs are
constrained by 8.3 filesystem naming limitations are quite convinced
in their belief, and no amount of logical argument seems able to move
them. I just thought it might make you feel happier to have some
confirmation of what you evidently alreadyhad grasped yourself.
Joel Shepherd
> > their handling of HTTP. In fact, I'm pretty sure it doesn't.
>
> Duh-- the 'limitation' just forced MS-users to use 'htm' instead of
> 'html'.
And the relevance of this to the World Wide Web is what, exactly?
> *If* there's going to be an agreed standard, it can't be 'html', so
> it needs to be 'htm'.
Huh? Standard for what? There are standards -- or recommendations
anyway -- and one implication is that for a text/html document, it
doesn't matter if the file name (assuming there _is_ a file) ends in
.htm, .html or .snot for that matter.
So what, exactly, are we aiming to standardize?
> > > (And I've always used '.html' exclusively.)
> >
> > It really doesn't matter.
>
> That you state this as a fact (rather than asking _why_ I think it
> matters)
I don't really care why you think it does. As far as the Web is
concerned, it doesn't matter.
> indicates to me that (like the ciwah-cult in general) you're in this
> for your ego, and not for the betterment of the Web.
Time to fix your indicator.
-- Joel.
Isofarro
> *If* there's going to be an agreed standard, it can't be 'html', so
> it needs to be 'htm'.
Doesn't need to be .htm either. Think about it a little. A file
extension doesn't have to be exactly the same as the URL. Also there is
no need for an extension at all, since content should be rendered
depending on its mime-type. File extensions are meaningless, so no
agreed standard is required.
Michael Stutz
Nice colors.
What I found read better for me was setting the names of the speakers
flush left, with (via <br>) no extra space between that and their
lines:
------------------------
<a name="1.1.1">BERNARDO</a><br>
Who's there?<p>
<a name="1.1.2">FRANCISCO</a><br>
Nay, answer me: stand, and unfold yourself.<p>
-----------------------
My eyes don't have to move as much. I tried lightening their names
with <FONT COLOR> but that didn't look nice.
I should read thru this more and see how it compares with hardcopy.
Recently read "The Tempest" in my ancient hardcopy edition and was
distracted by the typography. Names were set in italics and
abbreviated, set just left of their text:
<i>Boats.</i> Do you not hear him? You mar our labour: keep your
cabins: you do assist the storm.<br>
<i>Gonz.</i> Nay, good, be patient.<br>
<i>Boats.</i> When the sea is. Hence! What cares these roarers
for the name of king? To cabin: silence! trouble us not.