What Is a Page?
In print, a page is a unit of size. On the web, a page is a unit of information.
Words in a book tumble and flow between pages, patted gently into shape by a designer, as a farmer might build an irrigation ditch, till they are brought up short by the dam of a chapter end. A designer may, indeed should, look at a page as a unit, but a reader is supposed to ignore it. By sensible convention, a typesetter avoids putting breaking a word at the end of a page, for the inconvenience of it to the reader, and makes sure that the first line is complete and the last does not start a new paragraph (unless it finishes it), mostly I think in order to avoid drawing attention to the page itself. For it is the sequence of pages that matters.
What do you do if you have an 1800-word poem that you want to post on the web? Clearly you can choose between splitting it into half a dozen (or more) different pages, or putting it all on one. On paper, unless you are Kerouac typing in a speed-fueled frenzy down one long roll of teletype paper, you don't even have a choice.
One might think that the cyberspace unit would be the screenful; but that's not the convention. Screens are variable, of course, but 640 x 480 is the norm and obviously the size to design for, which is presumably why Adobe's on-line magazine was set up for 504 x360, allowing for menu bars and the like. This meant that with any luck you got a page at a time and jumping to the next page was a single screen redraw. This sounds logical, and at first I tried to design for it, but it soon became clear to me that I felt constricted. You just don't get much on a page that size, which is OK if you are jumping to a Help point, where the information you need is specific and short, but it feels wrong for a longer, more flowing text.
It seems we have got used to scrolling down (and up). Scrolling across is another matter – it's really annoying. With a 17-inch monitor, I don't run into it much as long as I have a maximum window, but with a smaller one you find it all the time on the web, and it is aggravating.
Page size strikes me as the most interesting design question on the web. It is one that won't go away, unlike the questions that seem at first blush to be the most important.
The Issue of User-Control
What seems to be the unique challenge of web design is that the users have considerable control over the look of the pages they read; in fact this problem is essentially trivial. If designers want control, they can insist on it.
You don't even have to use Acrobat, of which more below. For an example, take a look at the demo of my HyperCard stack June 1990, discussed in the Essay on Writing Fiction to be Read on a Computer. This was a functional decision, rather than an aesthetic one, but each successive screen needed to be presented with precise accuracy and it was.
Presenting a text page as a series of graphics, which is what the last example was, may be cheating, but so what? It's a pretty good way of hanging on to copyrighted text, aside from the ease of maintaining the formatting – essentially they are a series of screen shots, cropped and converted to 2-color, one transparent and the other black, so they load pretty fast.
Even without using those tricks, and I chose not to in the basic presentation, the Great Font and Leading Question is surely going to go away in the next few years. You can already request fonts; soon you will probably be able to supply them; I neither know nor care about the technical details but from the point of view of both user and creator the problem will disappear.
What does QuarkXPress code look like? Who cares? As I built these pages, I occasionally had to go into PageMill's source code mode to fiddle with things that didn't work right, probably because of my own failings. But I look forward to the time when I never do that – when I don't even think of it as a possibility – because the authoring tools have grown up.
And then the power will be mine, all mine, hahaha. And I can stop thinking about form, once I have made some basic design decisions, and focus on content. Which is, after all, the point.
Loading Speed
The loading-speed question will also wither away. For practical purposes at present, it is extremely important; there is nothing worse than waiting in front of a blank screen – the one I spend most time in front of is the Sporting Life, which has lots of news on the British sporting scene that I want, but I sure feel I have to work for it. (I did not link it, since it requires registration, but you can find it at www.sporting-life.com.)
Conceptually, however, this is also trivial. I recently bought a machine five times faster than my old one (and cheaper too; cheaper even than my first, which was almost 100 times slower), which means I can now use some software that used to drive me crazy – that's going to happen to web design within a decade.
I don't mean to minimize the social issues involved, for it may take years before most people get any web access, let alone speedy connections. Most people, let us be explicit about it, live in technologically under-developed environments and have no easy access to telephones, let alone computers. The global instincts of the web are great, but we should never forget that it actually represents connections within the thin global layer of the privileged rich.
But we didn't let widespread illiteracy stop us from working on print design for several hundred years. And my main complaint about the Sporting Life site is not really that it is slow to load, but that it is busy and confusing.
The Print Mindset
Most texts available on the web are designed to fit the old model – download it and print it out. Even companies like Adobe, which supply extensive hypertext manuals, intend them to be skimmed on screen and the relevant portion printed locally for close perusal; it is to Adobe's credit that they are not only aware of this, but explicit about it.
Screens are not printers. Their resolutions are an order of magnitude too small for optimum presentation of text, and this is not about to change in the near future. Screens do, however, provide exciting and dramatic opportunities that will never be accessible to printed material; on-screen texts can be a different animal, as everyone who has ever used a hyperlink knows – and that is without even considering pictures and sounds.
Reading on screen has received an unnecessarily bad rap. Certainly, you can't take a 17-inch monitor into the tub (though I wonder if Bill Gates is putting wall-size, voice-activated screens into his bathrooms), but portability isn't the only issue. Ugliness is just as important. And that one we can do something about.
If it looks good, people will read it.
Acrobat
I've been round and round on this one. I like it a lot, but you have to balance its advantages in control against both a theoretical and a practical problem.
If it does nothing else, Acrobat explodes the myth that you cannot have cross-platform design. It's slick. Creating an Acrobat document is dead easy, once you have made the thing in some other program, and you can embed fonts and formatting, and post it for all to use. (They have to have the Reader, but it is free and available for all major platforms.)
The IRS convinced me. They have tax forms available in Acrobat format, and you can just download them, print them, fill them in and mail them. (Assuming you dont want to do electronic filing.) Late in the evening of April 14th, missing a single schedule, this is a godsend.
The simple fact is that most people don't want to use their Acrobat Reader while web browsing; and a lot of people are probably still using version 2.1 or earlier, which is a great shame. (The machine I bought in March came bundled with 2.1, though 3.0 has been out for a while.) Please go get 3.0 from Adobe! If nothing else, the files in 3.0 are much smaller, with obvious advantages in download time.
And the theoretical difficulty is that you are still stuck with the given page size. You can get around it, of course, by making a different document for each page, and varying the size accordingly, but then you are dealing with external links and multiple documents, and some of the slickness crumbles away, along with almost all of the speed.
I did a crude and somewhat exaggerated test. I took the Word version of Occasional Turbulence and saved it as an Acrobat document with embedded fonts; it took 165,203 bytes, which is nearly twice as big as the final web version. I then saved each poem, the title page, the contents, and the credits as 14 separate documents; they totaled 1,178,027 bytes, just over seven times the size. The largest single file was not the longest poem; it was one that used italics as well as roman text, which meant there was another font to include.
Ninety-odd K can still be a manageable document if it's combined with page-by-page downloading, so you have something to read quickly. A megabyte is definitely go get coffee time. And a whole series of 50K files to get 100-word poems ... I don't think readers would hang around too long.
The Yale Style Manual
When I started to plan this site, I had various self-imposed guidelines about the look of the thing – no big graphics, no sounds, absolutely no blinking text or other moving distractions – and one about content, which was that I would under no circumstances have a Cool Links page.
Here is a cool link:
http://info.med.yale.edu/caim/manual/index.html
It is the Yale Style Manual, aka the Yale C/AIM Web Style Guide; C/AIM is short for the Yale University School of Medicine's Center for Advanced Instructional Media, and the Style Guide is written by Patrick Lynch and Sarah Horton. Lynch is Director of C/AIM, and Horton is Multimedia Applications Specialist for Academic Information Resources at Dartmouth College.
What they have produced is a remarkable achievement. For one thing, it's huge! It is available for download in its entirety, if your computer has an hour or two to spare (the unstuffed folder is 13.1 MB on my hard disk, 10,056,157 bytes used, for 322 items) but fortunately you can browse it on line, and if you have any interest in web-page–design issues I do recommend it.
The Style Manual, as its name implies, is not about HOW to make web pages, it is about WHAT to make them. The tone is gentle; the authors tend to suggest rather than to command. It is the most constructive contribution to this discussion that I have found so far.
