(EER's homepage, Astronomer's
Elizabeth Roettger's Homepage
Planning a WWW site
My limited surfing hasn't turned up practical notes on how to
start a web site from scratch, so here are my notes from
instigating both my own and Adler Planetarium's prototype
Note in conversion from previous site: page-design and
maintenance software now does a lot of the bookkeeping, so you
can focus on the design. That means a lot of what follows isn't
applicable unless you're encoding the html by hand. The first
part still applies, as does the last. (I hope to modernize this
page in the future...as soon as I gain more experience with the
- Do only a few mock-up pages at first.
- Get the basic design and graphics set.
- Determine what your standard layout and graphics
- Decide things like:
- will you have standard banners and
- what will you use for heading and
- will you use standard graphics (buttons,
- will you put text next to graphics, under
it, or over it?
- MEANWHILE, write your basic pages in plain text
- Figure out the basic structure of your linked
documents - I have a main page with several major
- Each section may have a number of
- That's why I initially chose to have my
standard opening graphic be
last/next/home/headpage, much like Yale's
- I've since determined that this isn't
working. The linear sequences are not the
dominant organizational structure. I've
removed them, and once the Notebook is a
bit more developed, I'll reorganize.
It'll be a pain in the neck, so I'm going
to try to do it just once.
- For the Adler homepage, it started out as a tree
- The main page had several major paths.
- Each path had several paths or choices.
- There's less sequencing, so it makes more
sense to have the standard opening
graphic be a series of topic buttons,
much like the Museum of Paleontology.
- In both cases, it helped to draw a diagram of the
- Naturally, this doesn't prevent me from
having many cross- references within the
structure, but I'm trying to keep the
overall structure clear and fairly
simple. Users want to know where they
are, and how to skim effectively.
- Collect your graphics, and convert them
- Do you want them to have standard sizes?
- Will they have standard colors?
- Some viewers use a gray
background, some white, some
colors. You can also now choose a
background for Netscape viewers,
although those with slow
connections may be unhappy with
this. (Make sure your text works
well on it...it's far too easy to
give people headaches.)
- You won't be able to make your
graphics blend in to all viewers
- so take your pick, or design
- Design your standard buttons, bullets,
and bars (horizontal rules or
separators), or use the defaults (done
for most of this page).
- If your graphics device has the
capability, jot down the length and width
in pixels - it's helpful to list these
for some viewers. (automated)
- Jot down the size of the larger files,
too - you'll want to list them when you
make links, so those with slow
connections don't get stuck downloading a
large file unintentionally.
- THEN make an html template.
- Test it as extensively as possible.
- Have a couple people try it out.
- You may wish to have several templates, if your
documents have several main sections.
- THEN start converting or writing your pages.
- Stop partway, and have a couple people try out
your structure. Watch them and see where they get
stuck or frustrated. I know it's tempting to put
it up and ask for comments, but there's NOTHING
as effective as actually watching someone use
- This kind of feedback is valuable, and you want
to make any changes *before* you set up all your
documents. (It's incredibly tedious to go back
through every single file to make a minor change
that could have been in your template.)
- Don't write "under construction" pages.
- They're a pain in the neck, and don't give you
- They're annoying to users, too.
- If you want to remind yourself that you want to
create a link, either add a comment or format the
word (<EM> perhaps).
- Decide on naming and folder/subdirectory conventions
early on. (somewhat automated now)
- I've been keeping all my html files in one
directory, and all my gifs in a single /gifs
subdirectory. That way, I can use relative links
pretty consistently. This helps, because the
machine I create files on is not the one where
they eventually reside.
- I use a 3-letter code (all caps) to distinguish
major sections (EER for my homepage, AEN for the
notebook) This makes it easy to tell where a file
belongs without having a complex directory
- Section-specific gifs start with the same letters
- General-use gifs start with other letters (BT for
buttons, GR for other graphic elements)
- If I were developing the files on the machine
where they "live", I think I'd keep
subdirectories for each of these groups. Also, if
there were a bunch of files with similar names,
I'd put them in a subdirectory.
- I find myself getting annoyed with lists of links that
don't tell me anything about where I'm going. I'm
therefore trying to make my links a little more
descriptive, so that you get a thumbnail sketch of the
external site before spending lots of time downloading.
Ditto for images, of course.
- (the rest is basically automated by software, as far as I
- I use html tags in all-caps whenever possible.
- When writing, I write the beginning and end tags
(<PRE> </PRE>, or HREF="") first,
and then fill in what's in between. It's a bit more
trouble, but it saves a *lot* of debugging time.
- When embedding one list in another, I like to indent (in
my html file) the second list. That makes it easier to
read, and doesn't affect the final formatting of a WWW
- I'm still training myself to save files as
text-only-with-linebreaks. At least now I recognize that
when I get garbage on the Browser screen, I should check
the file format.
Go (back) to Elizabeth Roettger's Homepage.
Created 24 September 1995, last revised 23 June 1997
by Elizabeth E. Roettger, firstname.lastname@example.org