|
Line-mode Web browsers, such as Lynx, can't display images. Folks with slow connections often turn off image autoload, even though they're using browsers (such as Netscape Navigator version 3.0) with highly-advanced graphics capabilities, in order to improve performance when combing the Web for information. Both kinds of user deserve to know what they would be seeing, if an inline image were actually being displayed. Simply adding an ALT="textstring"" attribute to the <IMG> element makes this possible and, in my humble opinion, scores big points with Webmavens, bandwidth-impaired users, potential customers and other shut-ins. Here's the proper syntax: <IMG SRC="image.ext" ALT="Describe the image"> One of the big problems with links to external resources is that, by default, they send users somewhere else -- with no guarantee that they'll find their way back. There's an easy way around the problem, though. Consider the following fictitious hyperlink: <A HREF="http://www.elsewhere.com">Somewhere Else</A> If that link was real, clicking on it would send you Somewhere Else -- and leave me here talking to myself. However, by adding a target= argument to the hyperlink, I can cause your browser to create a new window in which to open the link to Somewhere Else. And the original window -- which displays this site -- remains open behind that new window, allowing me to keep you here and send you Somewhere Else, too. Here's the new, improved hyperlink to Somewhere Else: <A HREF="http://www.elsewhere.com" target="elsewhere">Somewhere Else</A> All I've done is add a target= argument and given the target window a name -- in the above example it's called "elsewhere", but I could just as easily have named it "Monica" or "Fido" or nearly anything else that caught my fancy and it would still work the same way. (There are a few reserved names -- mostly for frames -- but, name your targets after friends, pets or celebrities and you'll be fine.) If you use one, standard target name for all your external links, they'll always open in the same secondary window, with the content of each new link replacing the current content of that window. If you want each link to open in its own, separate window, just give each target a different name -- but be aware that new browser windows chew up graphic memory and other resources like mad, so the more windows you create, the more sluggish and unstable you'll make your visitor's computer. Netscape introduced background images in its Navigator version 2.0. Now, both Navigator and MS Internet Explorer (along with quite a few wannabes) support the BACKGROUND attribute to the <BODY> element. It's also incorporated in the current HTML version 3.0 spec, so any future HTML 3.0-compliant browsers will also support it, which makes it a safe bet for inclusion in the design of this site. Here's the proper syntax: <BODY BACKGROUND="image.ext"> When the inspiration to model these pages after the physical pages in a notebook struck me, I realized that the actual image I used could be fairly small, since I only needed it to be 1 "line" high (23 pixels or .31 inches). It's 1,199 bytes, because it's 1047 pixels (13.65 inches) long, to make it display properly on screens set at 1024 x 768 resolution (otherwise, it would wrap horizontally, which it does, regardless, at 1280 x 1024 and higher resolutions). I created a second graphic with a blank, white background and a carefully-placed pair of vertical red lines to act as a template for the "handwritten" billboard at the top of each page. Getting it to line up properly was difficult. The first solution I tried, using the HSPACE="x" attribute, didn't properly display in Macintosh versions of Netscape Navigator or in other, non-HTML 3.0-compliant browsers, so, eventually, I resorted to creating a 4-pixel transparent left border to on the billboard graphics to permit the ragged left margin of the background graphic to show through, but still mask out the blue horizontal lines to create the illusion of the wide top margin of most standard notebook paper. I tried both making the background yellow (as if it were a legal pad) and leaving out the ragged left margin. Neither variation was as satisfying nor as convincing as the image on which I settled. I also tried creating a tunnel effect in the ragged margin (and with the binder holes) to simulate a stack of paper. That didn't work, either. The finishing touch was the notebook cover background for the Home Page. I created a cardboard-colored base, with spiral "rings" superimposed over a black background and black "performations". I tried a lot of different variations on brown, before settling on the one I use. Even though my Home Page has a different background image (at 1,196 bytes, it's 3 bytes smaller!) than does the rest of the site, there're only three other images on the page (the caricature of me at 15,844 bytes, the "three-ring-binder holes" at 110 bytes and the completely-tranparent "spacer" GIF which I use to separate the "binder holes" from each other at 67 bytes). With the small size of the page itself (3,118 bytes) the total load is only 5 HTTP connections for 20,335 bytes, which meets my design criterion for high performance. In order to preserve maximum downward compatibility, I resisted incorporating HTML tables into my Web site for almost a year and a half. However, the current iteration depends on tables to achieve its full effect. Essentially, each page (including my Home Page) uses a simple, two-column HTML table to create the impression that there are "handwritten" notes in the margin of each page and page-specific content "typed" in the body of each page. The first column is 130 pixels wide and constrains the "notes" and "holes" to the left margin. The second column, 450 pixels wide, constrains the page-specific text to fit into a 640 x 480 resolution browser screen (lines too long to fit simply continue offscreen to the right). The billboard graphic at the top of each page isn't part of the table. If a browser doesn't understand tables, the marginal notes simply cluster below the billboard at the top of the screen and the page-specific text begins below the last graphic, maintaining my downward compatibility design requirement. There are two broad types of clickable HTML image map: server-side maps (the original recipe) supported under HTML 2.0 and the newer client-side maps (the extra crispy recipe) first introduced in Netscape's Navigator and supported under HTML 3.0. Server-side image maps support one of two formats. The NCSA format is by far the most common and that's the one that the Apache Webserver chosen by our host, Direct Network Access, Incorporated, uses. It uses an external map file to determine which URL is linked to any given set of coordinates on Web page's image map. The alternate format for server-side maps is the CERN format. The syntax of its .map files is just different enough that they don't interoperate with the NCSA-compliant servers. One annoying aspect of server-side maps is that they don't work properly if you're modeling image maps on a local computer. Click on a section of the mapped image and your browser will display the contents of the .map file, rather than the URL to which those coordinates are supposed to link. Thus, in order to test server-side image maps, you have to upload them (and the page in which they're embedded and their associated .map files) to the server on which they'll run. Client-side map data is embedded in the HTML page which invokes them. Both Netscape Navigator 2.0 and up and MS Internet Explorer support client-side maps, (as, indeed, do any other HTML 3.0-and-above-compliant browsers.) That's a Good Thing, for several reasons. Firstly, client-side maps are self-contained. No external .map file is required. Secondly, client-side maps are locally testable. If you're developing them on a local machine, you can test them without having to upload them to a Web server. Thirdly, client-side maps display the actual URL to which a given section of the mapped image points, rather than simply displaying the coordinates over which the pointing device is currently passing. This is much friendlier to the end-user (another one of my design criteria). Finally, client-side image maps can coexist in the same document with server-side maps, using the same images. If a browser supports only server-side maps, that's what that browser will display and use. If, on the other hand, a browser supports client-side maps, then that browser will use and display the client-side map data. The hybrid map approach is the one I recommend for my clients who use image maps. Here's an example of the proper syntax: <A HREF="mapname.map"> <IMG SRC="image.ext" USEMAP="#mapname" ISMAP></A> Note that mapname.map is the name of the external, NCSA- or CERN-style .map file and that #mapname refers to the client-side map data embedded in the current HTML document (although, theoretically, the #mapname could have it refer to map data embedded in a different document, it pretty much defeats the purpose of making client-side maps self-contained..) Note, too, that you can also specify any standard attribute (BORDER=x, WIDTH=y, HEIGHT=z, etc.) for the mapped <IMG>. I experimented with using image maps for the links in the left margin of the other pages, but eventually decided against that strategy on the grounds that it would leave users with non-HTML 2.0-compliant (or non-graphical) browsers with no convenient way to make lateral jumps from section to section of the site. In other words, using maps on the individual pages would violate my design goal of providing full downward compatibility. Aside from the fact that the header on a JPEG turns small images into unacceptably large images, there is no current mechanism for designating a color which will drop out (i.e.--be transparent and let the background of a page show through) when a JPEG image is displayed. Fortunately, the GIF 89a specification permits you to do just that with a GIF and pretty much everyone on the Web uses transparent GIFs for "floating" images, logos and the like.
I used a larger version of the same font on the billboard images at the top of each interior page. In order to allow the white background of the billboards to overlay and conceal the blue lines of the interior pages' backgound image, (creating the illusion of the unlined top margin so familiar to us from notebook paper in the real world,) I created a 4-pixel-wide green vertical stripe at the left edge of each billboard image and designated that color green as the transparent background. That allowed the edge of the "torn perforations" at the left side of the background image to fully display, while still concealing the horizontal blue lines (the red double vertical line is also part of the billboard graphics--it took a lot of work to get it to line up with the red double vertical line on the background image). I use an animated GIF to denote the newest addition to my selection of published articles and columns. I created that image in order to experiment with animated GIFs (and to address the complaints of my friends who reviewed the site and complained that there weren't enough graphics). All this is pretty simple stuff, but it meets my criteria for esthetics, high performance and user-friendliness, without sacrificing the content which makes this site something more than an empty exercise. Go on to the Javascript Tricks Page. Go back to the top of this page. Go back to the Design Considerations Page. Go back to the History of This Site Page. Go back to the About This Web Site Page.
(Copyright© 1995/1999 by Thom Stark--all rights reserved) |
