Note: This essay was created some time in 1996, making it practically prehistoric by web standards. Since then, a number of additional technologies such as Flash have become standard parts of the web comics scene. Still, this essay has things worth considering, particularly if you want your comics to work with older web browsers and alternative browsing devices. |
Comics creators have jumped on the World Wide Web as a good, cheap way to disseminate their work. The web is a wonderful opportunity, a chance to bring creators who might have trouble getting their work into comic book stores together with readers, many of whom may never have visited a comic book store. However, so far most comics have been implemented awkwardly, in ways that are slow and can discourage the reader from reading and enjoying the product.
A number of speed improvements can be made using pallet and image size reduction. Those are discussions for another time. What I want to address here has to do with formatting, and how that can affect the speed that a user gets to read the work (which can have a major impact on whether they choose to read it).
In order to understand what I propose, we have to look at the way that many comics have been presented on the web. For purposes of discussion, I will talk in terms of a standard printed comic that has been adapted for the web, and is made of pages of material... although much of the discussion will apply at least as much (if not more so!) to comics designed with the web in mind. The two most common ways that comics have been presented on the web are:
When I was first faced with this problem, I came up with my Single Image method. As this example shows, the entire comic is put onto a single web page. However, instead of having a single image file for page one, another for page 2, etc., I have them all in one very tall image file! The first page is at the very top, then underneath that is a thin black bar to separate the pages, then underneath that is page 2, then another bar, then page 3, and so on. I use a GIF file, although a JPEG will work just fine. (If you do use a GIF file, it's important not to interlace it, or you will lose most of the benefits of this method!) Since a web browser gets a non-interlaced GIF (or any JPEG) starting with the information about the top of the picture, it gets the information about the top tier of the top page first, followed by the next tier, on down until the first page is completed, and only then does it start getting the information about the second page. If the browser is displaying the information as it gets it (and most browsers currently in use do), the reader is reading the first tier pretty quickly, and while he's reading it, the browser is continuing to get the rest of the story. If you have fairly clean graphics and the user has a reasonable speed line, odds are that once he starts reading that first tier, he will never have to wait for the rest of the story; each panel will already be downloaded before he can get to it.
There are, however, some minor imperfections with this system, as I see them:
However, I've come up with a new method that addresses those problems (although it does add one new one.) Let's call this the Animated Single Image method. Am I turning your comic book into a cartoon? Not really. All I'm really doing is taking advantage of some features of the Animated GIF format. An Animated GIF file is a file that contains multiple images. Usually, these images are a series of shots that, when shown in sequence, creates the illusion of motion. However, we don't want the illusion of motion. However, it also gives us the ability to overlap each new image over the previous images, and that will serve us well.
What if we had an Animated GIF file where the first image had just the first panel, and then the next image had the second panel, then the next the third, and so on? When the image gets downloaded, the entire first panel, which is the first thing in the file, gets downloaded first, then the second panel, and so on. Here is an an example, showing the same story shown above only as an Animated GIF file. With the file up correctly, each panel appears in the right spot on the page. Since it's focusing all of its effort on downloading the one panel at a time, there is far less time where a given panel is only partially completed. And because you are directly setting the order that the panels will be downloaded in, there is nothing to prevent you from doing a horizontal-scrolling comic instead of a vertically-scrolling one. (Note, if you want to see the example at work again, click on the link and hit the reload button, forcing your browser to start the download all over again.)
There is, however, one major drawback: a story done in this format will only be visible on browsers that support Animated GIFs. While presumably all graphical browsers support GIFs these days, there have been browsers that only support non-Animated GIFs. Generally, these browsers will show only the first image in the animated GIF file, which means they will show just the first panel of your comics story. However, the current versions of Netscape Navigator and of Microsoft Explorer both support Animated GIFs, and those two browsers make up the vast majority of graphical browsers in use these days. (One more minor drawback is that the Animated Single Image file will end up being slightly larger than non-animated Single Image file; in my experience, the difference is only about 10%, which is a small price to pay.)
These files really are not hard to make, if you have the right tools. I started with a standard Single Image file, which is basically just one tall image file with each page pasted in turn into it.) From there, I: