Telecommunities '95



[Rapid Contents] [Conference Home Page] [Program Information] [Proceedings]





A Web Magazine as a Telecommunity

Dr. Michael Levy, University of Victoria, Department of Computer Science

Introduction

As a specific example of how the Internet can create a community of geographically dispersed individuals, we describe Merlin’s Web - a web magazine written by and for magicians. Merlin’s Web is available by subscription only, although the tables of contents are freely readable by anyone with a Web browser.

There already exist numerous conventional magic magazines, and there is a news-group, a news-list and several electronic bulletin boards devoted to the subject of magic. Merlin’s Web was designed to be different from both paper magazines and the news list. Specifically, we have exploited hypertext capabilities to provide a reading experience that cannot be matched by lists, newsgroups or bulletin-boards. Furthermore, we have designed the magazine to allow for user interaction. For example, there is a button attached to every page in the magazine that links to a reader’s comment form.

For all the possibilities of hypertext, using it effectively has long been recognized as a problem [1]. Netscape and similar browsers usually incorporate many of the general facilities that help readers avoid getting lost, such as backtracking, history lists and page titles in the window title position. These facilities help hypertext readers to formulate a coherent cognitive model of the document they are reading, but they are not sufficient. The additional techniques used in Merlin’s Web will be described in section 3 of this paper.

Why Magicians?

Magic is in many respects an ideal candidate for a telecommunity. There are several kinds of people who might want to join a community of magicians. Aside from professional entertainers, there are part-time performers, hobby performers, people who collect books about magic, collectors of magical equipment, collectors of posters, archivists, charlatan-exposers and others. Any moderate-size city may have a couple of dozen of such folk. World-wide there are probably around 60, 000 magicians, if we allow that loose definition to coverall of the categories listed above.

We have, then, a geographically dispersed collection of interested people. Furthermore, the notion of exclusivity is an intrinsic part of the magic community. This arises naturally from the fact that many professionals make their living partly from knowing secrets. A community that wishes to discuss these affairs would want to ensure that casual visitors are excluded. (However, part of the culture of magicians clubs is to be very open to new-comers who have exhibited a serious interest in the subject). The notion of exclusiveness will contribute to the success of an internet magazine as a telecommunity of sorts. Less targeted magazines may generate revenue and have loyal readers, but they are unlikely to engender any sense of community.

There is a thriving market of magic literature. These books are not available in the usual retail outlets. They are usually sold by mail or in specialty magic stores. Magic books cover history, performance philosophy, techniques and so on. Many modern magic books are a description of a number of tricks or effects invented by the subject of the book. (It is common for a book about a magicians tricks to be written by someone other than the magician). Magic writing is very referential (and hence is ideal for hypertext). Most references fall into one of two categories: references to other performers and references to standard moves or techniques. Most authors are very careful to pay proper attribution to previous magicians. Sentences like "This effect is X’s version of an effect first performed by Y. Y had adapted it from Z. X felt that the method presented here simplifies the presentation." A second source of references are references to techniques or moves. "To make the card disappear, use an X move followed by a Y shuffle." This second kind of reference creates problems for authors. Do they interrupt the description of a trick to explain the move? Do they leave the move to an appendix? Do they simple refer to another book, or omit a description altogether? All these approaches are used in the magic literature.

In summary, the topic of magic is a natural one for both the creation of a telecommunity and for a hypertext treatment.

The Structure of the Magazine

Our objective was to create a magazine that would be informative, would exploit hypertext, and would create an on-line community. We wanted to be sure that our magazine was different from conventional paper magazines.

Sign-posts

The difficulties of hypertext navigation have already been mentioned. In this section we list some design axioms that we used to assist our readers. We were aiming for a reading experience that would allow readers to concentrate on the material. They should not necessarily be aware of "good structure" or navigational aids, but they should find that articles read well or flow well. Early feedback from readers suggests that we have managed to achieve this objective. How did we do it? Perhaps our most obvious axiom is this: every page in our magazine should have an identifiable look. Our readers should be able to tell at a glance that they are looking at a Merlin’s Web page. The next axiom: Every page in our magazine (other than the table-of-contents) should have at least one link back to the table-of-contents. This link should appear in the same position on every page in the magazine, so that it becomes familiar to any regular reader. Furthermore, the table-of-contents can then serve as a navigational beacon for the reader.

Each merlins web page (other than the contents pages) has a header that looks like this:

[Contents] [Rapid contents]

The footer is similar, except that the logo is omitted. The words in braces are linked to the table-of-contents and the rapid contents respectively (the rapid contents is explained below).

One of the difficulties of designing for readers is the difficulty in recreating all reading circumstances. Not all readers use the same browser. The speed of access to material varies by location and by connect type. Time to render graphics varies depending on the client machine. Since we expected most of our readers to be using home-based computers over a modem, we adopted an axiom that no page should take more than about 10 seconds to download or render unless an explicit warning is given. We wanted to avoid what we think of as a pot-hole effect:a reader requests a page, and suffers a lengthy wait while one or more unexpected graphics of unknown size are downloaded.

The problem is particularly severe for modem users, but it is a potential problem for anyone who is not close to the network containing the originating host. The creators of the page are often unaware of the problem because (a) they are probably using a high-speed network (Ethernet or better), (b) they are probably on the same side of the router as the HTTP program and (c) they are often using expensive computers that render graphics rapidly. When they view the page, it displays in an instant on their screen.

I think that the worst example of this that I have seen is at , Apple Computers support home page which contains a large graphic that is used as a context-sensitive map for links to the various sections of the support pages. All the button on the image are repeated in text below the image. It is an attractive picture, but it gives no information to the reader. I wonder how many customers have been alienated by a 30-60 second wait while this unexpected and useless graphic hogs their modem?

Magic articles often use diagrams. We never have these inline. Instead, we provide links with an indication of the size of the referred-to page. For example: "The position of the fingers is shown in Figure 6 [42K]", with "Figure 6" being the link.

Our table of contents features a large attractive logo, designed partly for advertising reasons. In fact, the entire table of contents of each issue is designed partly to summarize the contents of the issue, but also to entice people to subscribe to the magazine. It is likely that our readers will read the summaries, but after a time would prefer a more concise table-of-contents. We thus provide a second table of contents called the rapid contents. This sports a miniature version of the logo, and just the article titles (no summaries).

Inline References

We found an intrinsic problem with hypertext is that it can be disruptive. Consider, for example, a sentence like this: "The steam-powered engine was first built in Scotland by James Watt". In a hypertext encyclopedia, this sentence would present a number of candidate words for hypertext links. (Steam, engine, Scotland, James Watt). Suppose that you are reading the sentence, and that each of the words is highlighted or underlined (or both), indicating the presence of a link. We are required to first ignore the links in order to understand the sentence, and then peruse the sentence again to decide whether or not to follow the links. The physical appearance of the links does not follow this logical reading pattern (and, we contend, contributes to a tendency for hypertext skimming as opposed to reading). When just one word is linked in a paragraph, we use this kind of linking. But when there are several links in a paragraph, we have adopted a different strategy that we call archival side-bars. What we do is place the links in a separate indented, centred block. This block always incorporates a book icon, and has small horizontal lines that serve to demarcate the side-bar from the text. We adopted this approach because paragraphs form a natural break for readers and because it is very easy for a reader to find the side bars after reading the entire article.

The Archive

A major feature of Merlin’s Web is a section called Merlin’s Archive. This is a reference section containing bibliographies, explanations of special techniques, historical material and so on. Unlike the rest of the magazine, this section is not issue dependant, rather it grows bigger as material is added. The basic idea is to add relevant material to the archives with each issue. Most of the material in the archive is reachable from links in articles, but it is also possible to browse through the archive. This does create a few navigational problems. For example, to which table of contents should an archive be linked? We have chosen as the answer to this question the current one, but this could create some surprises for a reader of a past issue.

Because of the complexity of the archive, we have designed a hierarchical file structure using a classification system invented by John Gilliland, one of the magazine’s editors.

Interaction

A Web magazine creates the possibility of a magazine that can be changed after production. An obvious use of this would be to allow readers to add shared annotations to articles. This idea is not part of the HTTP protocol, but experimental work to support this and related ideas has been reported[2]. We approached the problem within HTTP by adding a form link ([Comment]) to every page in the magazine. When readers wish to add comments, they do so by clicking on the [Comment] link, and submitting the associated form. We could automate the inclusion of the comments in the article, but presently prefer to vet the submission before adding it to the comment. One problem we have not solved is a way to inform our readers about comments that have been added since they last looked at the issue. We do have a link ([Read Comments]) that becomes active when a comment has been added to a page.

As well as comment pages, we have a readers section where we have advertised our willingness to include readers material. We are starting to receive some material for this section of the magazine.

File-structure and Production

A simple Web document might consist of a collection of documents with links. These could all be stored in a single directory on the server machine. Our magazine needed a more complex file structure for reasons that are essentially identical to the problems of structuring source code for production software.

Firstly, since the magazine is subscription-based, we needed a simple way to distinguish between public and private documents. For this purpose, we created a subdirectory which contains all private documents and directories. Secondly, the file structure was designed to try to simplify the production effort. For example, it was natural to create a "shop" folder in which all pages for the on-line shopping area are placed. This directory is public. Since we have multiple authors, we have created a directory for each author. This simplifies article creation and editing, and solves a so-called "name-space" problem (fig1.htm, for example).

Since the magazine is to appear monthly, the author directories are placed in a monthly directory. Thus there are directories called "may95", "june95", "july95" and so on. A particular author can use the same article title each month(may95/cardlesson. htm, june95/cardlesson. htm and so on). The public portal to Merlin’s Web is the table of contents

. The link to the table-of-contents in the articles cannot point to this file, since it changes each month. We therefore created a directory of tables-of-contents, containing a different table for each issue of the magazine. These tables could not be placed in the monthly directories, because they are public, whereas the monthly folders are in private areas of the magazine.

Design for Portability

By far the largest part of our market are not connected to the Internet. Now it turns out that a very under-utilised aspect of most Web browsers is the fact that they can be used in "off-line" mode to read hypertext documents. It is thus possible to create documents that can be placed online or distributed by diskette.

To do this, all references in the document must be relative. Let me explain why. A typical URL contains an absolute path name like /A/B/C/f. html. The HTTP server treats this as a path name that starts at a fixed location known to the server, usually defined in its configuration file. The rules for href tags allow relative references, with the assumption being that the referred file is available from the same location (and with the same protocol) as the current document. Consider the above path, for example. A reference in f. html such as a href=g.html will be translated by the Web browser to /A/B/C/g. html. This is convenient, because it means that f.html and g.html can be moved to a different directory without a need to change the link. They can even be transferred to the client machine and read offline: as long as they are placed in the same directory on the client machine. Any absolute references within the document prohibit offline reading.

In the presence of a complex file-structure (as required by Merlin’s Web, for example), creating relative references is not trivial. Consider, for example, our small logo, known as "merlogos. gif". The URL for this file is http://www.swifty.com/MW/merlogos.gif. Files that use the logo (they all do) could refer to it like this: img src=/MW/merlogos.gif. The problem is that any file that does this is no longer portable. If we save the referring file locally, and then read it with a browser, the /MW/merlogos. gif reference makes no sense. In Merlin’s Web this problem is solved by prohibiting absolute paths. We use the ".." path name to refer to files that are in directories higher in the hierarchy. A typical Merlin’s Web header therefore looks like this:

TITLE Merlin’s Web: Interview with Thomas Fraps /TITLE
img src=../../../merlin_s. gif align=middle hspace=20 vspace=8
a href=../../../tocs/toc0695. htm[Contents] /a
a href=.. /../rtocs/rtoc0695. htm[Rapid Contents] /a
a href=../../forms/com0695. htm[Comment] /a [Read Comments]
hr6. The Merlin’s Web Telecommunity

The community of magicians is, naturally, complex and diverse. They are served by a couple of major organisations (The International Brotherhood of Magicians and The Society of American Magicians), as well as numerous other national organizations. These societies typically mail periodical magazines and hold annual conventions. They also sponsor local chapters (clubs). These structures naturally do create a (real) community. The ethics of the fraternity is a strict guarding of techniques and secrets, but a willingness to help newcomers of any age.

People who don’t like clubs, who wish more frequent contact or who do not live close to a club are likely to enjoy being a member of a telecommunity. This allows them to share ideas, to ask for advice, to discuss new items or books and so on.

It is too early to claim that Merlin’s Web is a telecommunity. However, we are confident that this is likely to happen. Magicians certainly have telecommunities. The most successful of these are alt.magic and a newslist called The Electronic Grymoire. Alt.magic, like other USENET groups, is freely available to any of the millions of USENET readers around the world. It is loosely governed (like other news groups) by a "nettiquette" - essentially vigilant readers who are willing to "flame" violators. The most significant rule of alt.magic is that secrets may not be revealed. At best, requests such as "how does David Copperfield" fly are treated with a polite short lecture. At worst, regular readers send back nasty or sarcastic responses. This rule, plus the fairly significant number of intrusions, keeps alt.magic from being a satisfying community. To some extent it seems to have been usurped by The Electronic Grymoire. The is a newsletter that is mailed almost daily to its subscribers. Membership is granted by the originator of the newsletter, based on a fairly detailed questionnaire that he mails prospective members. He also posts the names of applicants in the newsletter before granting membership. (This allows members to veto applications, based, for example on unprofessional or unethical conduct). This is a very successful newslist, although the discussions tend to be restricted to a very small set of regulars.

Merlin’s Web has received readers comments on several articles. One comment was so extensive that we included it in the next issue as a special article (with the authors permission, of course). One inhibiting factor is the publication schedule: my hunch is that a weekly would likely generate more interactive response than a monthly. Time prevents us from creating a weekly magazine.

Running the Magazine

We conclude this article with some remarks about how the magazine is managed. Subscriptions come from an online form. The results of the form are sent to us by email. We mail a registration package to the applicant. The package contains a login id, a password, an invoice and a return envelope. We use our servers login authorization feature to restrict access to the "mweb" sub-folder to registered readers.

The magazine is written by an editorial board of 7 people: Ron Bell, Tony Eng, John Gilliland, Michael Levy, Jack Poulter, Dave Scanlon and Orland Wilkerson. The board meets weekly to review progress and plan future production. Each editor is responsible for one section of the magazine. We share the responsibility for obtaining other material. Only one editor knew HTML when the magazine started. HTML training is essential to simplify the production process. Ideally, a new issue can be created by copying each authors contributions to their folders, and then modifying the previous table-of-contents to reflect the current issue.

A major advantage of Web publishing is the ability to distribute material at very low cost to a distributed community. We already have subscribers from Asia, Europe, Australia, New Zealand, Canada and the USA. Our costs have been restricted to a nominal one-time mailing cost for each new subscriber. On the other hand, we only started to discover mechanisms for generation of further revenues. We levy a small fee for processing on-line orders. We have not yet explored the possibilities of hyperlinked advertising.

Acknowledgments

Thanks to David Godfrey of Softwords Research International for helpful suggestions.

References

1. Jakob Nielson, "The Art of Navigating through Hypertext", Comm. of the ACM, vol. 33 no. 3, March 1990, pp. 296-310.

2. Martin Roscheisen, Christian Mogensen and Terry Winograd. "Beyond browsing: shared comments, SOAPs, trails, and on-line communities". in Proc. of the Third International World-Wide Web Conference, published in Computer Networks andISDN Systems, Vol 27 (1995) No. 6, April 1995, pp. 739-749

For more information, please contact:

Dr. Michael Levy at merlin@pinc.com


Mail your comments and questions about these web pages to rowena@softwords.bc.ca