PNS/ashford/image-maps/: Image maps (example)
  -[Open the demo in a separate window]-

Here's an example of taking the CONTENT and making it
work as a set of web pages. In reality, the real 
problem IS the content. That is all of the information
is accurate, understandable, and useful. If the user
has problems, then some sort of HELP or SEARCH 
facility should be provided. As we all know, those
things are *rarely* well thought out - mainly because
they're difficult to write, and most companies opt to
use an automatic cross-reference or index program to
do the work. This is fine, as long as you give to
a trial audience and take their feedback and use it
to improve the product. What an idea, right ;)

The sample pages are at the following url:

A few things in the use of this kind of technology:

1) It is relatively simple (albeit a *bit* time 
   consuming) to take the image to be "hot-keyed"
   and convert it to an html page that can then
   be linked to "sub-pages" of that image.

2) As regards the aesthetics:

   If something looks like button, 
   then it should BE a button. Otherwise,
   it's just totally frustrating for the
   user to figure out what to do.

   Ideally, there would be buttons to go back 
   to a previous level or immediately to the
   TOP of any branch in the tree. These would
   have to be programmed in, of course.

   Most web pages have more than just a blank
   screen as backgrounds. They can of course
   have ANY look and the text can be placed
   over them. Of course, for visually impared
   users, this may create quite a problem.

   Of course, it's the CONTENT on each page that
   is the goal -- the html and other fancy graphics
   are just the "Presentation Manager" for the 
   web page; ie, "look and feel". 

   Fancier things ARE possible, but then they 
   take longer to load, and of course are almost
   always more complicated and therefore harder
   to maintain or EXTEND. 
3) Web pages can have "programs" loaded in the
   background (using Visual Basic or JavaScript)
and these can do all sorts of things such as 
loading and playing a slide-show, music, other
windows (those nasty pop-up!!!), etc. More details
on the "innards" down below. 

Techie Points

The basic "magic" here is the programming language
known as "HTML" (Hyper-text Mark-up Language) which
controls the layouts of EVERY web page; there are
extensions, called CSS, XML, cold-fusion, etc.

Once the main graphic for the page is ready (here,
i just scanned the textbook). It has to NOT change.
Otherwise, it's impossible to "map" areas of the
image to the action. 

Basically, for every area, you just use PC Paint
(or other graphics program) to measure the locations
of each button. Then there are two corners (upper
left, and lower right). Then the MAP function in
HTML detects the mouse, and if you move it to within
one of the "hot" areas in the file and clidk the
mouse, then HTML opens that page as directed.

NOTE:  For almost ANY web page, you can see the
       html code, by choosing, VIEW (at the top
of the browser, and then SOUOCE). There are of
course, ways that the programmer/owner of the page
can block this action; protecting the intellectual
property rights, don't you know!

Of course, there are tools (Publisher, Front Page, etc)
that can automatically do this sort of thing.

File Names, etc

In setting up such a (potentially) complicated interface,
you HAVE to have a SYSTEM. Thus, the referenced pages
and the images and files associated with them have to
sort of "hang together".

Thus, the first level "software" (which is really a sort
                                  of summary page),
has it's webpaged named:  software-general.html
and it's thumb-nail image:   ldd-image-key-software-general.GIF

And then the next button: " "Authoring Systems" 
is stored as:              authoring-systems.html

The "tag" "ld-image-key" is completely arbitrary,
and "LDD" is short for "Lever-Duffy/McDonald"
If this systematic naming were carried thoroughly 
through, the files would all be something like:



then if there was a file such as:


it would be pretty apparent where it fitted into the

Also, these systems can get out of hand easily, 
since "in theory" we could keep adding more and
more pages and sub-pages, and of course new
classifications; eg, "special needs: Prosthesis",
                     "special needs: Monkey helper",
                     "special needs: Interfaces",

In an actual system, it would probably be best to
use FOLDERS for each group of things, and then
sub-folders as required. 

Of course, there is no escaping the complexity of 
the system. The main thing is that it should have
a "sensible logic" to it, that once gleaned that
even the user's could make there own links into
the system.

-- share and enjoy, :)