Be sure to sign and date your Web pages. Solicit comments from your users. Feedback from
users is the best means of finding out problems with your site and is a good source of suggestions.
Dates are also important due to the rapidly changing nature of the Web. They allow a user to
quickly tell if a site is being maintained and whether the data you present is up to date. Dating
your pages is more effective than saying your data are "current" or "new." On a related note,
maintain your site. You should periodically check your links to make sure they are still active and
check any mapping tools (like query) that you offer to make sure they are working properly.
If you have a GIS-based site, be sure to include metadata if you want your data to be useful. Sol
Katz (1997) maintains a list of metadata related resources, including standards. The GRASSlinks
site demonstrates a nice way to unobtrusively include metadata on your site. Even if you do not
expect others to use your data directly, you should still list your sources. It is also wise to explain
the limitations of your data to help prevent any misuse. The TIGER site includes this sort of
information in a FAQ list. If you want to be helpful to other interactive mapping Web site
designers, you should also include some documentation on how you created your site. Some
sites, such as GRASSlinks and Andy Wick's Cool Java Map Page, even include the source code
on their pages. Currently there is quite a bit of documentation on how to use CGI to link a GIS
to the Web. Documentation on Java and VRML is more difficult to come by.
The biggest issue for interactive mapping sites is what type of GIS-WWW interface you want to
use. The basic choice is between a form-based page using CGI and using Java. [There are other
methods, such as using Active X, but I found very little information on them]. According to the
responses I received both have their pros and cons. Java is more interactive and versatile, while
forms are faster and more reliable. Java is also not yet supported by all Web browsers and
generally requires more programming experience to implement well. Despite its problems, Java
has more potential for truly interactive mapping. Most commercial browsers and GIS-WWW
interfaces will probably support Java in the future. Bandwidth problems will also hopefully be
overcome. The Mapquest site uses Castanet software to speed up their Java performance
(Strand, 1997). The best solution is to offer more than one version of your site, then your users
can choose whichever interface they prefer. Unfortunately, many sites do not have the time or
resources to do this. You should base which interface you choose on the purpose of your site and
your users. Some applications may be impossible without using Java. If you want to
accommodate users with slow connections and old browsers you should stick with forms and
basic HTML.
"Creating Killer Web Sites" (Siegal, 1996) offers many tips on formatting pages in HTML. One
useful trick is using blank GIF files to control the layout of your page. Tables can also be used
effectively to control your layout. Recently it has become popular to use frames to display more
than one window of information at a time. Frames limit how much space you can devote to your
map and will slow down a Web site considerably. Since most interactive mapping sites need all
the speed they can get I do not recommend using them.
Be careful of the size of your maps. Several sites I reviewed had maps that did not fit on a 15"
screen and could not be resized. You can use the HTML height and width tags to define the size
of an image. Users with 14 or 15" screens will usually have a default resolution of 640 x 480
pixels. To be sure your map appears correctly you should restrict its size to 535 x 320 pixels
(Lynch and Horton, 1997). [If your maps are better viewed at a different resolution, be sure to
state this in your opening page].
Maps should follow some basic map design guidelines. Like Web pages, maps should have an
informative title and be as independent as possible. It should be clear where in the world the map
is located. This is especially important for large scale (small area) maps. Not everyone knows
where the Murray Basin or Clinch River are located. Small scale maps can show location and
orientation by including latitude and longitude coordinates and grid lines. Large scale maps
should also include a locator map, making it easier for the user to orient themselves. Some
indication of scale should also be included on all maps. Scale can also be shown using
coordinates and grid lines on small scale maps. For larger scale maps I recommend using the
traditional bar scale, or simply including the scale as a fraction (e.g., 1:25000). [Bar scales have an
advantage of being independent of screen resolution and remaining accurate if the map is reduced
or enlarged]. The TIGER Map Service and the Berkeley GIS Viewer are examples of maps with
scales that change as the user zooms in and out. Finally, all maps need a legend. The query
ability can substitute for a legend to some degree, but I still recommend one for any map that
shows more than one feature. The Xerox Parc Map Viewer is an example of a site that can get
away without having a legend, anything more complex should have one. Once you have a legend,
make sure it is understandable. Having a legend with a bunch of codes on it is not much good if
you do not explain the codes. Generally labels on your map are also a good idea, although they
can clutter up your map. Many sites have labels as a layer which can be turned on and off, which
is a good solution. Robinson (1995) provides a good guide to label placement.
Other aspects of map design are the same as more general graphic design. Monmonier's, How to
Lie With Maps (1996) is a nice guide for basic map creation. Make sure that type on your map is
readable. Features should be distinguishable, variations in the visual hierarchy should be used to
make important features stand out. Try to avoid making the map too cluttered. The Cool Java
Map Page is an example of a map that is difficult to read because of clutter and a lack of
hierarchy. Use appropriate symbols and colors. Colors in particular are often used carelessly.
Maps showing gradations in data from low to high values (e.g., many thematic maps) should use
light to dark color scales or different sized objects. Primary colors, like those used on the
Demographic Data Viewer site make thematic maps very difficult to interpret. [This note applied
to version 1, Version 2 of the Demographic Data Viewer makes excellent use of color]. If your
map is an imagemap, the hotspots should be obvious.
The best solution to map design is to put as much of it into the hands of the users as possible.
Many sites give users control over colors and which layers are turned on. Other possibilities
include control over line types, the order in which features are drawn, and what symbols are used
for point features.
Unfortunately I do not have many tips for Java. Most Web guides do not have a section on Java.
Try to keep Java applets as small as possible to minimize loading time. Otherwise, take advantage
of what Java has to offer. You can embed menus into your map to make it easier to use. Beware
of overwhelming users with options. Try to make it clear how your site works.
As I mentioned before almost no sites allow users to do spatial analysis. GIS vendors should
incorporate abilities similar to those in GRASSlinks into their Internet mapping software. It
should also be possible to make custom programs for spatial analysis in Java. The IRIS site is
notable in that it allows users to manipulate the database directly, the site includes documentation.
While there may be security concerns in giving users access to the database, this is another way
to let them do their own analysis.
I did not have the time or resources to compare the different commercial GIS-WWW interface
tools. The responses I received recommended avoiding making sites that require specific
plug-ins. Requiring plug-ins restricts access to your site, and I did not see any plug-ins that did
anything that could not also be done in Java.
Make sure you have instructions on how to use your site and explanations of your data. If you
are catering primarily to other GIS users, you may not need much explanation. Experienced users
may even be annoyed by too much text, as they want to get to the data as quickly as possible.
You may want to consider offering direct FTP access to your database so that they can skip the
maps entirely. Unfortunately there is no standard file format that has gained common usage
among GIS users, so you may want to offer several options if you decide to use FTP. One
possibility to watch is the Spatial Data Transfer Standard from the Federal Geographic Data
Committee (1997). Novices on the other hand, may not even know what a GIS is. For them you
may want to not only explain your data and how to use the site, but general GIS concepts as well.
The ICE site offers an example of how to accommodate both groups by offering extensive
instructions and explanations as separate help files, which the experienced user can simply skip.
Think globally when creating your site. It is called the World Wide Web for a reason. This is one
of the reasons I recommend using locator maps. Write out the date on your pages since the U.S.
and Europe use different conventions when abbreviating dates. Avoid slang or jargon that may be
difficult to translate. See Lynch and Horton (1997) for other tips on how to accommodate other
languages.
Last updated 8-10-97
back to the Interactive Mapping Resources Page