Spaces.org


Design Criteria

"We have no reason to be grateful to those who juggle the thresholds in the name of haphazardous innovation." -- McLuhan

(Up 4 April 2000) (finally revised April 2002) The following are the parameters used in the design of the pages at Spaces.org. The aim is to provide web pages which are fast loading, downward compatible, and are easy to navigate by visually and physically impaired viewers.

Downward compatibility and navigational access are related. This page mainly deals with these. Speed is covered elsewhere. This page also does not offer definitive solutions, but only suggests common sense.

"Common sense" is entirely contary to what the giants of the browser industry are attempting to accomplish for impaired viewers. Their thinking is that whatever is needed should under no circumstances impede the progress the companies have made in increasing their control over the presentation the viewer experiences.

Thus whatever has to be done about accomodating blind and near blind viewers is expected to be accomplished by piling up more specifications, code, and browser version numbers. And these same industry folks might then write and sell the programs which will accomplish the interpretation of the CSS specs.

But the "programs" have been around since the 70's. We dont need anything more complicated, we need things less complicated. It is so easy to do if the webmasters will just let go of their Kompozers and learn to type.

So what we have here (at Spaces.org) is a minimal but workable immediate implimentation of direct methods of access. The viewer (any viewer) is in complete control over font sizes, link colors, and the display format of the pages. No text is dropped into unreadable gif files. The foreground and background colors are selected for contrast. Etc.

Topics below:


Downward Compatibility

Why would anyone want to use a text-only browser? Well, when I need information I want to be able to connect with speed and get what I want in a hurry. There is nothing like a text browser, such as Lynx or Bobcat, because it just skips all the graphics, and with very few exceptions, information is text, not graphics.

Text-only is one reason. Other reasons are that text browsers are fast, it is easier to feed to a text talker, and it makes an easier translation to a Braille screen. Lynx is available for Windows, too.

Speed

A Lynx connection is an order of magnitude faster than a graphical browser like Explorer or Netscape -- that is 10 or 50 times faster -- and probably two orders if the pages include anything gimmicky, like Java, CSS, or Flash. That's right: two orders of magnitude: 100 times faster. And the use of Pentium processors (in conjunction with bloated graphical browsers) have only accentuated this. If you don't know what "an order of magnitude" is, stop reading now.

Incompatibility

Incompatibility started when Netscape made a marketing push to have their tags accepted worldwide, causing an enormous amount of friction somewhere between the HTML2 and HTML3.2 standards. But that is history now.

Microsoft's Explorer started doing the same thing -- they came up with the <blink> tag, and uses JavaScript components incompatible with all other browsers, and "Active-X" which no other browser knows anything about.

Browser specific tags are no problem as long as the web pages are confined to internal corporate use where everyone has the same browser settings, and the same fonts, etc. But on the internet, this can cause no end of confusion when things do not at all look like how they are intended, or worse, screw up: like invisible text colors, missing fonts, overwriting of text with other text, etc.

Conservative Design

A reasonable course for page design then is to remain conservative, that is, to use tags which will be understood by as many browsers as possible. Forcing web pages to be easily readable by a text browser thus represents the dead level of downward compatibility.

Fortunately, one of the outstanding design features of html which has remained an accross the board standard is to have browsers simply ignore tags which are not understood. This solves a lot of problems, for different graphical browsers have invented their own tags often enough. It also solves the problem of any new stuff, like flash, for example. An older browser does not hang up with new tags, it simply skips them.

Access

Again, the other consideration for downward design web pages is to allow access by people who are visually impaired, who will set up bigger font sizes to read the text, who will disable background colors, who are color blind, and even completely blind and will be using a Braille screen or a sound-out reader. Blind readers have no problem with plain text, but find it nearly impossible to use text which shows as images. Visually impaired viewers have immense problems with texts controlled through external CSS.


Three Design Elements

I am not addressing "speed" here, for it would be a compilation of interelated elements, but see the specifics of loading speed and image file sizes, at this [http://jnocook.net/web/] location.

This is a media where you try to reach out to many people, all using different equipment, operating systems, and web browsers. At the present there are some 200 versions of the two popular browsers in active use - and they all act different. Worldwide there are in all probably 50 named browsers all with their own various versions. And people do not upgrade. So the question will be, how do you allow as many of these variables to play out successfully?

The answer is, by implementing the following three design tenets, which all point in the same direction: letting the viewer fit your page to their screen.

1: Use of defaults...

Use default colors for texts and backgrounds, default fonts (set by the user), default page width (set by the user), default link colors (set by the user), default type sizes (set by the user), default scroll bars. This generally means use of HTML-3.2 standard. (Which did not include frames!)

2: Use the most basic tags...

Not much else is required besides the H, P, and BR tags. Anything special which fancies up the text will increase the size of the files (slow things down), make the files more difficulty to edit (your problem), and is likely to be misrepresented by other browsers (which becomes the viewer's problem).

Some strongly held opinions: CSS should never be used on public sites; JavaScript is more cute that effective; Java is still a genuine security risk; Frames are difficult; Image Maps are death to a text browser; and Flash sucks.

3: Let the viewer's browser do the work...

That was the idea behind web browsers, and still is: Don't specify widths, fonts, font sizes and colors, or any of the details of layout. Let the user pick a readable font, and then let the user's browser fit the page locally to a screen.

There are additional advantages: knowing the basic tags, you can get a new webpage up in five minutes; you can find logical errors with ease; you can practice your typing. Knowing in addition the reductiveness of web page specifications since HTML 3.2, you will also realize that pages can be reduced to no tags at all.


Guidelines

  1. General site parameters

    1. The organization should be obvious.
    2. Website divisions kept to four or less.
    3. A 100 to 200 word abstract to open a page.
    4. No text presented as images.
    5. Large images at the start to be avoided.
    6. Time stamp at the opening or close.
    7. DOCTYPE (3.2, en), ISO-8859-1 (HTTP-EQUIV Meta)
    8. META Description, and Keywords TAGs.
    9. Titles should reflect the contents even out of context
      (I use path/filename for deeply imbedded files).

  2. General formatting elements

    1. Generic HTML 3.2 whenever possible.
    2. No background images.
    3. White (or very light) background colors (#FFFFFF or #eeeeee) throughout
    4. Black foreground colors (#000000) throughout
    5. (Default) Cyan blue (#0000FF) for links.
    6. (Older Default) Bright red (#FF0000) for visited links.
    7. (Default) Yellow (#FFFF00) for active links.
    8. Basic compositional tag set: H1 through H3, P, BR, HR
    9. List organization tags: UL, DL, OL
    10. Sparse use of TABLES: see below.

  3. Specific formatting elements

    1. Markup tags: use I and B exclusively (EM goes bad often).
    2. Set off single lines of code with BLOCKQUOTE tags.
    3. Set off more than a few lines with PRE HR ... HR PRE tags.
    4. PRE tagged text width well under 80 characters.
    5. FONT tags are not used
    6. FONT COLOR attributes are not used.
    7. FONT SIZE attributes are not generally used
      (Netscape and Explorer do not agree).
    8. FRAMES are to be avoided, but if, then:
      1. Don't set any absolute frame widths.
      2. Left frame as an index, at 30 percent
      3. Right frame for text, at remainder
      4. Don't provide an escape, it is easier to do by the user.
    9. TABLES are to be avoided, but, since TABLES are the most elegant means of formatting ...
      1. Don't set any absolute table widths.
      2. Keep character widths to under 79.
      3. Restart TABLES as soon as possible
        1. Because Lynx presents tables in column order
        2. Because screen writes are much faster
      4. A single TR tag per table (speed).
      5. Short left column menus.
      6. PRE tags for tabulations, or nbsp entities.

  • Navigation and presentation of links

    1. Navigation menues only on the index page, not everywhere
    2. Square brackets surround all anchored texts.
    3. Use URLs as anchored text for remote links, if possible.
    4. Use "jump" or "below" to indicate hash-links.
    5. All pages: list URL, host domain, and logical domain.
    6. Hosted public pages only linked from the index file.

  • General use of images

    1. No text will be presented as images.
    2. No clickable images, or image maps (even if everyone else is _so_ stupid about that).
    3. Large images at the start to be avoided.
    4. No image dimensions, ever (faster screen display).
    5. Use of JPEG/JFIF compliant *.jpg files, not pJPEG
    6. Use of GIF87a non-interlaced *.gif files only
    7. No PNG files (yet)
    8. Descriptive ALT text, and link-to indication.
    9. jpeg files at 300 dpi, 62 percent compression.
    10. gif files at reduced colors (jpeg too)
    11. Image files within the 600 pixel width limit.
    12. Page icons within 34x34 pixels
    13. Link icons within 54x54 pixels.
    14. Images contrasts to a gamma of near 3.0.
    15. Use #eeeeee background for photo images.
    16. No transparent white space images.
    17. No bullets, "new" indicators, arrows.

  • File organization

    1. Root directory for common pages only.
    2. Image intensive pages in separate sub-directories.
    3. All sub-directories have index files ("go away").
    4. Local links use relative paths.
    5. Images in separate subdirectories everywhere.
    6. All filenames 8.3 format and lc (my habit).


    The Uncomfortable Spaces Website, [www.spaces.org]
    Site Host: Outflux Net
    URL: http://spaces.org/design.htm