How a Neighborhood Association Uses the Internet: Advice and Reflections

Index

• Change Log: for repeat visitors: a time-stamped listing of significant updates
• Neighborhood Profile: provides context for subsequent comments
• E-mail to residents
  • Role of E-mail
  • E-mail uses
  • E-mail list management
  • E-mail list entry tracking
  • E-mail lists
  • List membership restrictions
  • Etiquette
  • Experience reducing Spam
• E-mail between Directors
  • Origins of use of e-mail
  • Caveats
  • Problem of getting information in e-mail messages to directors who do not use e-mail
    • Attempted Solution 1: hardcopy before monthly meeting
    • Attempted Solution 2: immediate copies: FAX or pickup
    • Attempted Solution 3: get e-mail for all
    • Current Solution
• Web Site Design
  • Purpose
  • Content decisions
  • Links to other sites
  • Design decisions
    • Diversity
    • Our Experience
    • Graphics load
    • Use similar organization
    • Page Division
  • Privacy concerns
  • Location of home page
  • Payment
  • Standard Page Footer
  • Copyright
  • BASE tag
• Search Engines can be your friend
  • Finding other useful sites
  • Page titles
  • Helping other groups find you
  • Better listing entries
  • Explicit index pages
• Differences accentuated by Internet usage
  • Different professional cultures
  • Web bias
  • Misunderstanding motives
• Web "Case Studies"
• Virtual Web Site
• Hints and Tricks
• Collaborative Authoring
• Other Resources
• bottom of page, copyright

Neighborhood Profile

• Size: Roughly a square mile. The exact boundaries of the neighborhood are fuzzy -- the count of households varies from 1200 to 2000 depending on the criteria and definitions used. We hope that use of the Internet is helping us better cope with this fuzziness.

• Occupational Backgrounds: The neighborhood is near Stanford University and adjacent to the Stanford Research Park. Many of the residents are academics, professionals (e.g., medical doctors, lawyers), and engineers and scientists in various high-tech fields (especially the computer industry).
  However, the neighborhood was an unincorporated county area until it was annexed to Palo Alto in 1977, and consequently it has attracted many people who do not fit the "Silicon Valley" stereotype.
  Retired people are estimated to be about one-third of the households.

• Membership: In a typical year, 300-400 households have paid the voluntary dues. Perceived membership is higher because many households occasionally misplace the reminders to renew their membership (for example, missing 2 out of 7 years).

• Internet Usage: There are slightly under 140 households represented on the neighborhood's e-mail list (as of Spring 1998). I expected a somewhat larger number, but suspect that some of our membership is very cautious about joining mailing lists because of bad experiences with flaming and spamming. Our survey of December 1997 included a question on e-mail list membership that was useful in gauging level of participation.

  The e-mail list membership had climbed to 100 in late 1996 and held roughly constant for a year. Membership climbed to 140 in Winter 1997-98, largely as a result of the key role of the e-mail list in getting information to residents about an important, rapidly evolving problem (potential flooding).

  Of the Board of Directors (as of Spring 1997, rounded to 5%):

  • Hyper-connected (handheld with radio modem): 5% (1 of 13)
  • Routine users/Well-connected: 40% (5 of 13)
  • Infrequent users/Poorly connected: 25% (3 of 13)
  • no E-mail: 30% (4 of 13)
  Note: although there has been some shift in these percentages (more connected directors), I am freezing them relative to the time the relevant sections below were written.

E-mail to residents

• E-mail is but one of many ways we communicate with our membership:
  • Quarterly newsletter
  • Leafletting: too labor-intensive except for the most significant of events
  • Postcard announcements and reminders: expensive
  • Kiosk (in park): limited size, target of vandalism
  • Lawn signs along major streets: reminders for major events
  • Word-of-mouth: all of the above "prime" the personal networks (through which a lot of the information passes).
  Many of our communications use multiple of these methods, trying to take advantage of complementary strengths.

• Because of the low proportion of our membership on our e-mail list, e-mail is consigned to being a supplementary method of communication: It is used as the primary means only when none of the other means are appropriate. E-mail's advantage is that it is fast and very cheap (especially in labor). It is used for information that is either very perishable (information that would be obsolete before other methods could distribute it), or it is information that would be useful to our membership, but is not central enough to the mission of our Association to warrant the cost of the other forms of distribution.

• E-mail use examples:
  • Last minute reminders of events announced elsewhere.
  • Reports by residents of problems in a forum where other residents can expand on it or provide additional information. For example, one person may report a problem and then 4 or 5 others add "important to me too". The Association directors can then contact the appropriate city official and tell him/her that 6 residents have complained about X, which carries greater weight than the complaint of a single person (one person may be dismissed as a crank or chronic complainer, but 6 people ...).
  • Broadcast of monthly crime summaries (from the police department's Community Relations / Crime Prevention office).
  • Alerts of new crime trends (for example, auto burglaries)

• E-mail list management: In the summer of 2000, I decided to switch to using the Majordomo package, revising my previous decision on this topic. This followed several bursts of unsubscribes resulting from annoying behavior on the list by a very few people.

  I was quite surprised by how many people had how much trouble with the instructions (I expected a moderate amount). If you read between the lines of the instructions on the mailing lists, you will find hints of the problems encounted. The biggest ones were that various people had problems

  • grasping the need for precision in the input to the system
  • reading and following a recipe from start to finish, rather than snatches here and there.
  • using the content of error messages to identify their mistakes.
  • understanding that they would not be added to the list if they didn't respond to a message telling them that they need to confirm the request (after having been told that they need to do this in the original overview). My reading of comments from many people was that they did not understand the need for confirmation, and consequently decided that the process was "too complicated."
  • understanding that quote characters in a template should not be included in the command, even when told not to include them and given an example showing them not present.
  • scanning messages for the information that they needed. For example, people who got the majordomo help message decided that it was too long and did not scan it for the short section relevant to their problem (the subscribe command).

  Since the turn-over rate on our list is so small, we decided not to use an automated system to do adds and drops. My experience with the various Majordomo systems is that they can be perplexing in all but the simplest cases to all but the most savvy and experienced of users.
  I have been on mailing lists where the majority of messages related to unsubscribing (no exaggeration): (1) why won't the Majordomo unsubscribe me, (2) shouting at the person about not bothering the whole list with these messages, (3) shouting at the people in (2) to be more polite to (1), (4) flame wars about whether "unsubscribe" is hard to spell (the most common user error), and whether or not Majordomo should be able to handle the various common misspellings, and (5) ...
  Since just one of these events can drive many members off the list, I decided to handle subscription requests manually, so that I could deal gently and intelligently with requests from our less experienced/sophisticated users.
  Note: The examples published (in our newsletter and on the Web) for subscribe/unsubscribe requests is consistent with using Majordomo, in case we decided to switch to using it.

• E-mail list entry tracking: Even with only 100 addresses on the list, I have had frequent problems with bounced messages. Most have been related to people changing their ISP (Internet Service Provider) or employer (for those receiving e-mail there) and forgetting to notify me of their new address. However, a significant fraction have been related to problems at the ISP. Since I don't want to be inundated by bounces, nor do I want to unnecessarily remove addresses from the list, I encourage people to give me a street address and/or telephone number so that I can leave a message when there are persistent problems.
  Note: this was a problem for us because of the decentralization common in volunteer organizations: I am managing the e-mail list but not the membership database, so many of the requests to add entries to the list formerly came with only the e-mail address and nothing to tie it to an actual person.

• E-mail lists: We started with one list, and then established a second one. The first one was for official and general interest communications (with guidelines offered). The second list was for want ads, looking-for ads, and recommendations (example: have a great sitter, looking to cost-share).
  We were worried that items in the second category might create enough volume to drive people off the primary list. So far, the volume on the second list is very, very small, and it is questionable whether the confusion created by having two lists is warranted.

• List membership restrictions: We have very few restrictions on who may be on the neighborhood mailing list.
  • typical list member: a resident of the neighborhood: we explicitly state that membership in the Association is not a requirement.
  • City government: some city council and relevant/interested staff members, including "the dog catcher" (actually, Animal Control staff deals more with other critters, but I couldn't resist the image).
  • Other Association Liaisons
  • Not News Media: although several members of the media are on the list as neighborhood residents.
    We decided that if we allowed the media access to the message stream, we would be licensing them to extract informal discussion and put it in news articles. We felt that this was going a step beyond the caveat that new e-mail users are typically told: don't put anything in e-mail that you wouldn't want to see in the newspaper. Since members of the news media who are on the list are there as residents and not a representatives of the media, any use by them of messages in a story is no different from any other member of the list forwarding a message to a member of the media (including all the ethical questions).

• Etiquette: We are currently considering how to handle the very sensitive topic of guidelines/rules for etiquette. There are a number of very basic set of etiquette guidelines on the Web, but most are not specific to the problems that can arise during discussion of controversial topics.
  Concern: Most etiquette is learned by example, especially from more experienced members of the group you are in. However, with the explosive growth of Internet usage, many people are not in the kinds of groups where this experience is passed on. I don't know how much experience our e-mail list members have with lists and newsgroups, but I suspect that many of them use the Internet to primarily to browse the Web and for personal e-mail. If this is the case, many of them have not seen examples of how to handle the usual problems that arise, either when they are the target of inappropriate behavior, or when they (unintentionally) behave inappropriately.

  My etiquette guidelines

• Experience reducing Spam

E-mail between Directors

• Directors are members of the Association's governing body, the Board of Directors. Also referred to as "members of the Board".

• Origins: Our use of e-mail started as a frequent substitute for the telephone between two of our better network-connected directors, and soon escalated into a broadcast notification system for all the connected directors (at the time, less than half). From there, it crept towards occasional virtual meetings.

• Caveats:
  • Our directors come from many different backgrounds and bring with them many different styles of decision-making. E-mail favors certain of these styles. By accentuating the differences between different director's approaches to decision-making, e-mail has the potential of exacerbating friction between directors.
  • It is very easy to have the directors who do not use e-mail to perceive (rightly or wrongly) themselves as being excluded from discussions and decisions.
    While e-mail can be a significant tool in breaking up cliques based upon which directors interact as part of their normal lives (by simplifying the distribution of information), it can also be a significant factor in dividing the board into cliques, based upon have/have-not, degree of access, experience, and style of interaction. Aside: Our board had little turnover during the transition to e-mail so established personal relationships served to keep our problems here as minor ones.
  • Because of the potential for fast turnaround, e-mail is a two-edged sword:
    • When rapid response is needed, e-mail provides an easy method for informing and checking with other directors. There is rarely any excuse for a director to take unilateral action.
    • It can be tempting to not give yourself enough lead time to have an issue debated or a document fully reviewed.
      It is not acceptable to send e-mail stating that you will take action in the Association's name unless you hear an objection.
    • People who use e-mail as a standard part of their business are typically accustomed to fast turnaround times. Widespread use of e-mail in an association might bias the decision-making process towards those who are already comfortable with this faster pace.

• Attempted Solution 1: Relevant e-mails were included in the information packet that is distributed to directors prior to the monthly meetings.
  Problems:
  • Retaining messages and selecting the ones that should be included in the packet was an error-prone process.
  • Editing out extraneous information (especially headers and signature blocks) was labor-intensive.
  • Editing a sequence of mail messages in a way that they would make sense to a non-user of e-mail can be more difficult than you might imagine:
    • The varying methods for including a message, or portions of a message, being replied to can be very confusing to the non-user.
    • Deciding how to control the redundancy is often difficult, especially when a message replies to a portion of another message: the included text of the original is necessary to establish context, which argues for keeping it, but you also need keep the original message for its full context.
      Similar problems occur for responses to multipart messages where the original does not easily provide nice mechanisms for indicating which sections are being addressed when.
      Redundancy was a bigger problem than anticipated: many of the directors who were not experienced with e-mail did not develop the strategies for dealing with included text: rather than identifying text as being repeated merely to establish context for the subsequent response, they would re-read it carefully and complain about the mass of repetitive verbiage.
    • The messages often are not a simple linear sequence.
      Non-users can become confused when messages are linearized into a single stream.
      Experienced e-mail users know how to look at the various headers to determine which messages are response to which, but even they can have problems.
      And this assumes that the critical headers haven't been edited out prior to printing.
    • Distorting effects of "column-inches" on importance.
      All the headers and included text makes e-mail exchanges use a disproportionate amount of paper. This can create the perception that a particular item is more critical, complicated or contentious that it really is.

      I randomly picked a response and found 26 lines of headers, an 18-line signature block, >40 lines of included text and 2 lines of actual content.
      Consequently, an e-mail exchange that is printed on four pages in a reduced font may represent less than half a page of content if it were to be merged and rewritten.

  • Time delay: Including relevant e-mail in the packet often only let the non-users know what had happened, and did not let them participate in the discussion, and could effectively exclude them from the decision-making process:
    • decision officially made
    • decision effectively made: too much momentum for non-users to have influence
    • non-users would have just started thinking about problem, whereas e-mail users were already up-to-speed.
  In retrospect, the failure of this approach was inevitable because it violates several basic tenets of learning:
  • Non-users were expected to cope with complex messages from the beginning, rather than ramping up from simple to complex.
  • Messages were dumped on the non-users as part of a larger packet of materials. They had no easy way to obtain explanations, or ask questions, about how to read these messages.
  • Repetitions (of the learning opportunity) were too few and too widely separated to become embedded in memory.
  • A major reason that many non-users are non-users of e-mail is that their aptitudes and training are in other spheres.

• Attempted Solution 2: Set up a system that would FAX e-mail messages to those non-users who had FAX machines, and print copies for others who would then be alerted by telephone to pick up their copy at a central location.
  Problems:
  • Did not want to distribute all e-mail: many message were of the form Can anyone substitute for me at hearing X and Does anyone have information about X.
    Selecting which messages to forward was non-automatic and very error-prone.
  • Impenetrability of e-mail conventions to non-users: see Attempted Solution 1.
    Often by the time a topic was identified as warranting full distribution, it was already several levels deep into replies.
  Again, in retrospect, this approach was almost certainly doomed to failure. Since full distribution of e-mail was a small proportion of the e-mail between directors (most messages were the equivalent of telephone calls unrelated to policy), and a minuscule proportion of the director's total e-mail (work-related, personal, ...), no one ever got enough practice (repetitions) doing full distributions that it would be remembered.

• Attempted Solution 3: Get e-mail accounts for non-users (possibly subsidized). Also get low-end computers (for example, ones that are so old that the only groups that would take them are schools and other charities).
  In retrospect, it is fortunate that none of the non-users were willing to switch to e-mail.
  • Learning in unforgiving environment: These non-users would likely not use e-mail for anything but their activities as directors. Thus, they would be engaging in e-mail exchanges only for the most significant issues. This is not the time to be learning e-mail, because minor mistakes can be horribly magnified.
    For example:
    • Learning that e-mail messages often come off stronger than intended. The new user needs to become slightly desensitized to the tone conveyed by a message (develop a "thick hide"), and to become more sensitive about how a message he/she is writing might be perceived.
    • Using Reply-All where Reply was appropriate/intended, and vice versa.
    • Other addressing problems.
    • Coping with bounced messages.
  • E-mail is multiple environments: E-mail is used in a variety of ways, for example
    • Substitute for other forms
      • Substitute for FAX or overnight delivery: distribution of results
      • Substitute for telephone call / voicemail
      • Substitute for conference call or meeting
      • Substitute for memos: broad announcements
    • Overlap/mix of above
    • Transition from one form to another: Example: an e-mail announcement which becomes the basis for a virtual meeting which then results in a draft document distributed by e-mail.
    Each of these uses has conventions. New users typically start in a small subset of these, and eventually learn them all.
    However, a director who was otherwise a non-user would be thrown into the middle of all of these uses and would not have time to learn to distinguish the various uses and when what conventions apply.

• Current Solution:
  • E-mail is used for announcements. Relevant announcements are included in the director's information packet. Since these are simple messages, they are equivalent to other documents included in the packet (on par with newspaper clippings).
    Still error-prone: However, board members who sent e-mail that they thought should have been in the packet can bring photocopies to the meeting.
  • Coordination of meetings and requests for information: can be more efficient than a series of telephone calls for the subset of the relevant directors who have e-mail.
  • The most important use of e-mail is for refining drafts and finalizing statements of policy approved by the board (typically at the monthly board meeting). For example, positions to be presented to city government: city council and staff concerned with planning and zoning issues.
    Our active users of e-mail represent a wide-enough spectrum of the directors that this is an efficient way to hone these documents. In a typical interaction, the director who is assigned responsibility for the position sends a draft by e-mail. Several other directors make small suggestions, and one or two make suggestions on rewriting or adding a paragraph, and the cycle repeats after the modifications have been incorporated. It is not uncommon to have several cycles of this process (8-12 messages, most of them brief) in a day, or a little more. Vastly superior to old method of where the draft was read over the phone for approvals (or FAX'ed or dropped on the doorstep).
  • There is limited policy discussion, but it is limited to refining a proposal to bring before the full board. Since making a decision via e-mail is not an option, the discussion typically involves only the "major players" on that topic, and there seems to be little difference from what happened when the same thing was done by telephone.
  • Some actions can be taken without the approval of the full Board of Directors. E-mail is often used instead of the telephone to obtain the approval of the necessary set of directors for such actions.
  • E-mail from residents to directors: The address for the list for the board of directors is published and residents are invited/encouraged to send requests, problems, and observations to this list. This simplifies getting the information to the correct director, and not letting things drop if the director with primary responsibility is unavailable.

Web Site Design

• Purpose:
  • Information for members (not necessarily in any order)
    • Contact Information (Board of Directors, Committee Heads, government officials)
    • News
    • Status of various projects
    • Calendar
    • Background information, History
  • Web presence to help establish connections with similar groups: they might find us through search engines or simply by browsing
  • Databases for various activities:
    Simplifies sharing and access: Easily accessible by all net-capable members rather than stored on one person's computer or in someone's filing cabinet (or to-be-filed pile).
  • Start centralizing corporate memory
  • Provide a better match to the tempo of many resident's lives (an experiment)
    The situation many find themselves in:
    • Less time for community involvement
    • Far too many demands on their time
    • Available time typically comes in small increments, and may be interrupted
    • Available time comes at irregular, often unpredictable, intervals
    The problem for our Association:
    • General meetings are increasingly impractical because of the conflicting constraints on people's time
    • Need to provide the motivation for your activities to rise above competing demands on people's time
    • Need to breakdown activities into units that are small enough that people can see themselves completing them in the available time slices
    • Reduce start-up costs: in many activities, people wind up doing nothing because by the time they have figured out what to do and how to do it, they have run out of time.
    Use of the Web as a part of the solution
    • Web is information pull rather than the information push of newsletters, meetings, ...
    • Database of tasks that people can scan to find ones matching their interests and available time.
    • Mechanism for reducing start-up costs by allowing people to more easily share their experience on similar tasks, both direct advice (do this and don't do this) and indirect help (recommendations of publications, products, stores, ...).
    • Information source that has appeal to many children, who will then serve as advocates with their parents.

• Content decisions:
  • Undercutting the value of membership?: One of the primary perceived benefits of membership in the Association is the quarterly newsletter. There was considerable concern that putting the newsletter online would reduce dues-paying members. Our solution was to put most, but not all, of the newsletter online after a delay. The delay was determined by when the editor had time to convert the articles to HTML, and the selection was largely determined by what was easy to convert (photographs and other graphics are typically not included).
  • Tone: Advocacy and/or Reporting
    The leadership of a neighborhood association (or other grassroots organization) typically attracts people who could be categorized as
    • issue-oriented activists,
    • fledgling politicians, and
    • reporters
    with respect to their approach to release and distribution of information. As with other publications, you should consider how you are going to mix the different approaches, especially how to mix advocacy with straight reporting so that credibility of the latter is not undermined by the former. For example, newspapers mark blatant advocacy as Editorial or Opinion sections, and have thresholds for how much advocacy can be included in articles in other sections.
    Remember that the Web is not a newspaper or other hardcopy document: you do not control the access paths to your pages (a majority of your accesses may come from search engines or links from other sites). Consequently, you need to consider the relationship of each page to your overall site. For example, if I found a page that read as advocacy, I would assume that most of the links from that page were to other pages of advocacy, unless that page was marked as Editorial (or similar) in which case I would assume that its links were to pages giving the factual background behind that opinion.
    
  • Approvals:
    • Initial position: all content was to be approved by the Board of Directors at the monthly meeting before being put on the Web site (except newsletter articles, which had already been reviewed).
      • Unworkable: This was not a surprise to the Web-savvy, but needed to be demonstrated to be convincing to the whole board.
      • Unresponsive to needs and opportunities
      • Most of the content was uncontroversial, if not downright prosaic.
    • Current: The people putting content on the Web site have a track-record of judgement and discretion, of double-checking with others, and of referring potentially controversial items to the relevant parties.
• Links to other sites
  • The power of the HTML is that you not only can have links between your own pages (documents), but that you can link to pages at remote sites. Superior to making your own copy of the information because the link automatically give us the current version on each visit, with no need to worry about getting corrections or updates.
  • A good collection of links can be a strong inducement for people to recommend your site and to bookmark it. Annotation, recommendations, organization and prioritization within a collection of links makes it more valuable to the user.
    It is this localizing and customizing of the collection of links that is the "added value" that makes your page something other than a poor imitation of the big services (Yahoo!, the search engines, ...).
  • Links also provide a way for other people to find you (Finding other useful sites below).
  • Problem: If your user follows a link to another site, he may never return to your site (runs out of time, doesn't have the patience or experience to unwind back to your site, or enters one of those sites that doesn't support the "Back" operation -- typically large corporate sites where the entry page provides redirection, and thus when you back up to that page, you simply get redirected back into their site).
    Solution: We try to position the links to other sites lower down on our pages, especially in sections marked Other Resources. We also try to clearly identify them as being other sites.
  • Disagreement over appropriateness: we have had a few disagreements between page authors about what were appropriate links to include, but these were really disagreements over what they viewed as the charter for the page. For example, one co-author viewed the page as having a narrow focus and wanted to keep it very terse, whereas the other co-author had a more expansive view and wanted to include links that he thought of potential interest.
  • Implicit endorsements: a non-problem: Users may view the presence of a link as a kind of endorsement of the other site, or the information and views presented there. The potential of this becoming a problem has influenced how we present links, and, to date, this has not become a problem.
  • Advice on presenting links: Be prepared for the other site to reorganize its pages, causing your links to become stale.
    • Try to make minimal modifications to the title provided with the page -- if the page is moved, using that title as a query to a search engine is often a good way to find the new location of that page.
      Unfortunately, many authors (including us) forget to make meaningful titles. In this case, you need to exercise judgement in creating a title that is meaningful for your link, without being contrary to the spirit of the page's author.
    • If the page is not a top-level page, we often cite one or more higher level pages as a way of both crediting the author, and of finding the page should it move.
      For example: Bird Identification from Migratory Bird Research program at the Patuxent Wildlife Research Center (Maryland) of the Biological Resources Division of the US Geological Survey
      Note: "top-level" page is a difficult concept to define precisely: a user's home page at an ISP probably should be treated as a top-level, but at many other sites, a user's home page is often not treated thusly.
    • Warning: In some cases, the title of a page may be viewed as copyrighted material and its use to name a link does not fall under fair use.
      The relevant court decision involves one newspaper's Web site providing links to individual articles at a competing newspaper's site and using the original headlines as the names on those links. This is probably a very narrowly construed case, but you may want to proceed cautiously with some sites (for example, asking permission to use titles on links).
    • Warning: In the early days of the Web, etiquette was to link to only the top-level pages of many sites, or to ask permission to link to embedded pages. Today, many sites are so large (and often obscurely organized), that this policy has largely become obsolete. However, some sites regard making links to anything but the top-level page as misuse of their resources -- these typically are sites that have paid advertising and want users to have to see the maximum number of pages (and hence ads) before they reach anything useful.

• Design decisions:
  • Diversity: Be aware that a neighborhood organization likely has much more diversity, in terms of technical culture and expertise, than other organizations that you belong to.
    • High diversity in target audience: difficult design decisions
    • High diversity in designers and content providers: Significant differences in experiences led to conflicting notions of what was and was not good design.
      Differences extended to a much more basic level than I would have anticipated.
  • Our Experience:
    • Our Web site was announced in March 1995. It has since gone through many changes, including the home page changing sites when the original webmaster moved away.
    • At the time, only a few of our directors had much experience with the Web. And the majority had no Internet experience.
    • Because the Web was still in its infancy, there were few comparable sites to use as examples in considering what we did and did not want for our site.
    • Because the majority of the directors were not Internet-based, they did not appreciate the importance and consequences of a Web site. Even when we arranged a live demonstration at a board meeting of what was possible, it did not inspire questions or comments, and no one accepted the invitations to try it for themselves. Again, in retrospect, this should not have been surprising: adult non-users of computers are unlikely to make even the briefest use of computers without strong motivation.
    • The resulting design was controversial: the implementer came from a different community (graphic design) than the Web-experienced directors (technical managers), and consequently he interpreted what was desirable in a different context than was intended.
    • The design conflict: It was interesting that the different people involved in the design process could have such diametrically opposed views on very basic issues.
      • Perceived audience:
        • Browsers: people who would happen on our site (remember this was 1994-95). In order to get them to stop and look at content, the site had to be not just visually pleasing, but eye catching.
        • Repeat visitors: people looking for specific information. These people would want the site presented so that they could quickly and easily navigate through it. Most pages should have a "bullet'ed" format (similar to a typical presentation on overhead transparencies).
      • Audience expertise:
        • Novices: Page should have lots of graphics mixed in with the text, with the links scattered throughout the text (rather than organized as an outline).
          Argument against: Too slow and aggravating for repeat visitors.
        • Experienced: Top-level pages should be primarily for navigating to the page with the desired content. These pages should be little more than the information needed to quickly identify the various links.
          Argument against: Novices would find this style intimidating: the page layout would scream click on something NOW, rather than letting them absorb where they were and where they wanted to go next.
      • Organization of content: The different assumptions above about the audience for our Web pages produced substantially differences in how content was organized, and to such an extent that each side declared the other's organization of the information to be all-but-unusable, even though all parties were trying hard to work together to reach a consensus design.
    • Advice: try to story-board your site's basic design before you start implementing (we did not try this - to my regret). Once implemented, it can be hard to change a site's design and organization:
      • People have a large amount of ego committed to original design and implementation.
      • Re-implementation becomes a deferrable task
        • current version is viewed as good enough "for the time being"
        • implementer does not get enough of a sense of achievement from the changes to motivate him/her to make it a priority
      • Claims that any significant change will confuse users. This argument becomes stronger the longer you delay re-implementation.
  • Graphics load:
    • Effective bandwidth assumptions:
      When designing your pages, pay close attention to the size of the pages, which usually means the amount of graphics. Even if all your residents have high-speed modems, pages may take forever to load (hence the World Wide Wait) because of other potential bottlenecks: the server and the network between the server and the client. Remember also, even if your Internet Service Provider (ISP) is providing good response now, they may be overloaded in a couple of months. Same for the ISPs used by the clients.
      It is not uncommon to see average transfer rates of only 30-300 bytes per second.
    • Visit patterns and caching:
      Graphics load is also a factor of how you think people access the information at your site.

      I have complained to several sites about being very slow because they are graphics-heavy. They responded by acknowledging that it was slow to start, but claimed that this was OK because once you had the images cached, navigating through the site was very fast because subsequent pages reused many of the same images and backgrounds.

      Their notion of how sites are visited contrasts starkly with how I actually visited their site (and most other sites). I typically find a site through a search engine, and although most of the sites I visit are not relevant to my immediate need, some are promising enough that I bookmark them. In a subsequent visit, I typically browse only a small portion of the site, sometimes just exploring, but more likely because I am checking them before going to a search engine. Thus, because I make multiple widely-separated short visits, caching of graphics does little to help me, whereas if I was to spend substantial time browsing the site in a single visit, caching would be a major win.

    • Graphics are not optional for the typical client:
      Some sites believe that being graphics-heavy is not problem, because if you are connected by a slow link, their pages will load quickly because you will have set your browser to not autoload images.
      • They falsely assume that the only reason for slow throughput is that you have a low-speed link from your computer to the rest of the Internet. They do not seem to grasp that the cause could be slow response from their server, or congestion anywhere on the intervening network.
      • So many sites are designed with the assumption that autoload-images is ON (their images include information crucial for navigating) that turning this option OFF is not really viable.
  • Use similar organization: Your users are likely to apply to your site the patterns they learned visiting other sites. Consequently, you should try to make your site's organization similar to sites that are likely to be regarded as examples.

    Aside: This is a best guesswork since your user community is likely to be very diverse and hard to characterize.

    Negative example: As part of my "day job", I visited the site of a vendor (who shall not be named) in search of information on one of their product families. I went down the link entitled "Products" and found the items in question. However, there was spotty technical data, with most of the page devoted to "puffery" (how great their company was). I sent a quick note to their webmaster expressing my annoyance. His response was that the technical data was under the link for "Press Releases" -- I had not even bothered to explore that link because at most similar sites, the press releases were puffery with little technical detail (a press release being something that you give a reporter to lightly edit and submit as a news article).
  • Page Division: How you divide content over pages is can vary radically, depending on how you expect the pages to be used and other factors.
    • Large collection of small pages:
      • Good if people are reading pages from their computer monitors and are likely to view only portions of the larger document represented by a set of pages.
      • Big advantage: little or no scrolling
      • Requires that you have a server that is very responsive, otherwise the delays in between pages is devastating.
    • Few very large pages:
      • Good if people likely to read document sequentially: scrolling is typically easier than click the Next link.
      • Good if downloading from the server is slow: people can start reading as the rest of the document loads.
        However, pages that contain significant graphics may defeat reading-during-loading because the downloading of the graphics may preempt resources (server, net, modem), greatly slowing the downloading of text.
    However, remember that people don't just view the pages on their computer monitor. For example:
    • Printing: almost always easier and faster to print a document that is a single page rather than one that is a collection of small pages.
      If your users are likely to be printing a document, think about the appropriate level of granularity (whole document, chapter, section, subsection, ...).
    • Including a document (as an attachment) in e-mail.
      • Most browsers essentially offer the user an all-or-nothing approach to including a Web page in an e-mail message: there is no simply way to edit-down a page in the same way one would edit-down an e-mail message being replied to.
      • An example serious use for e-mail attachments: lobbying
        Many of our elected representatives have come to take e-mail seriously (or else many of their constituents wouldn't take them seriously :-)). One approach to lobbying is to provide a description of a policy position that your members/supporters can then reference (by attachment) in their e-mail to their representatives.
        This is too new for me to have feedback from the representatives on its effectiveness. I like it because it allows people to send supportive statements without feeling that they have to write a longer message to establish context -- which may well mean that they don't get around to actually writing it -- without it being merely a form letter that people are sending in as if it were their own (a lobbying tactic that many politicians have learned to spot and then ignore).

• Privacy concerns: If you had looked through our Web pages before September 1997, you would have found that the number of directors cited as having e-mail (in the introductory Profile above) was not reflected by the presence of e-mail addresses in the pages. Many of the directors were uncomfortable with having address information (street address, telephone number, e-mail address) on the Web pages, even though this information is available from various sources, especially well-known Web-based directory services. The general feeling was that most residents would have little difficulty finding this information, and that having even one level of disconnect would be useful in reducing the potential for misuse by outsiders.
  In September 1997, most directors accepted having their e-mail address included on the Web pages, but continued to prefer to not have other contact information be listed.

• Location of home page:
  • Current: our Association's home page is located within a domain acquired by the webmaster as part of her larger business activities.
    The hosting site has the advantage of the additional visits to that site providing increased exposure for other home pages there, but may or may not be worth the cost to the sponsor.
  • Geographic-oriented domain name: We considered getting a sub-domain within the geographic/political hierarchy, for example: bpa.palo-alto.ca.us This did not happen because of political/administrative difficulties (probably staffing) for the nameserver for the parent domain.
    Our tentative plan was to have this be a pointer (alias) to our real Web server.
    • Technical detail: a DNS CNAME entry for the pointer
    • Advantage: We would have an unchanging name in the event that our home page had to move to a new sponsoring host.
    • Disadvantage: The webmasters for our first and for our current web server both wanted to have their domain names displayed. And given the amount of work they were contributing, this is fair.
    Another consideration: Many people expressed displeasure at having such a long domain name. You might view this as positive or negative: it could encourage them to bookmark your home page, or it might discourage them from visiting.
  • Links from other pages: We have a link from one of our city's pages, although it can be hard to find. We also encourage cross-linking with other similar organizations.

• Payment: coordinating with Web-based forms: We have a Web-based membership form in addition to our traditional hardcopy form sent to all residents of the neighborhood. The electronic form is little used -- typically fewer than 10 times a year -- so we have done nothing to automatically enter information from this form into our membership database. A disadvantage of the form is that people often forget to send their membership dues by US Mail (we have no way of taking payments over the Net). An advantage is that we have memberships from people living outside the area who have ties to the community (including descendants of one of the neighborhood's original residents).

• Standard Page Footer:
  • URL: An all too common experience for many browsers is finding an interesting page, but being unable to easily locate it again.
    We include the URL on each page because some browser do not include this information when they print a hardcopy; in other browsers, including this information is a configurable option. If someone is interested enough in one of your page to print it, they are likely to want to visit that page, or other pages at your site, at some point in the future.
  • Contact address: An important part of the footer of each page is the contact address of the person who is responsible for maintaining the page.
    I suggest that you state the level of feedback desired:
    • At a minimal level, this is the person to receive problem reports (for example: your page does not display properly under the newest release of browser X).
    • Corrections to content
    • Comments and suggestions for improvements: If you solicit these, you should be prepared to respond in a timely manner, and "timely" on the Internet is often taken to mean virtually immediately. If you have a complex consultation and approval process, you probably don't want to solicit suggestions.
    Do NOT have a contact address only on the home page:
    • The user probably wants to keep the current page on his screen, but this would force him to:
      • Open an additional browser window (to go to your home page): many users do not know that this is possible, and of those that do, many fail to think to use it in these circumstances.
        Additional, this would mean having 3 windows dedicated to this simple response: one for the contact address, one for the page in question, and one for composing the mail message.
      • Navigate back to the home page for this address, then navigate back to the page in question.
        At many sites, the organization of pages in not intuitive to some/many visitors, so they may fail to find their way back to the page they wanted to comment on.
    • If the user has found your page by a link from another site (including through a search engine), they will not have visited your home page. At sites hosting multiple home pages, finding the correct home page for a subsidiary page may not be trivial.
    Suggestion: In the contact address, you can automatically set a default Subject line for the message,

    YourName, <A HREF="MAILTO:YourAddress?SUBJECT=PageIdentifier">YourAddress</A>

    Since the user may have seen only the one page in question, it is unrealistic to expect him to produce a description that distinguishes that page from all other pages that you are responsible for. Do not expect them to type in the URL:
    • May be truncated in the display on the window
    • May be too much trouble
    Having an unambiguous identifier of the page in question can be very useful: Some messages I have received could not be understood or acted upon without knowing what page they referred to.
    You can arrange for mail to multiple people either by having a comma-separated list in the beginning or by putting additional contacts in the CC field

    <A HREF="MAILTO:Person1@Your.Org, Person2@Your.Org?SUBJECT=PageId"> (test)
    <A HREF="MAILTO:Person1@Your.Org?SUBJECT=PageId&CC=Person2@Your.Org, Person3@Your.Org"> (test)

  • Version information: Many of our pages are repeatedly updated, and it is often impractical to mark everything that is new with the NEW! icon, and we have found no satisfactory way to mark things that have been removed.
    A first approximation to helping people know whether the page has changed is to give them a date-of-last-change and optionally a version number. Version numbers are given if they impart useful information beyond that of the date.
    A date is often more useful than a version number because the user cannot be expected to remember the version number of every page he visits, but he may remember approximately when he visited a page. For example, if he visited a page about a week ago, and the current footer shows that it hasn't changed in a month, he knows that there shouldn't be any changes.
    Advice: Programs designed for writing Web pages can typically be configured to automatically set the last-changed date, but many Web page authors do not use these programs (don't have them, don't like them, ...). For these authors, a version control system can be used to automatically set the last-changed date.

• Copyright: Purpose of a copyright notice:
  • To protect your rights
    Horror story: In the mid-1980's, some members of our Association were developing an earthquake preparedness guide and shared the drafts with other community groups (because sharing was the intent from the beginning). Unfortunately, they failed to mark it as copyrighted, and a person took this draft and used it as a basis for a booklet that was then copyrighted and marketed to local governments (for distribution to their citizenry). At the same time, the draft was being pushed as the basis of a booklet to be distributed by our city. However, because the city's booklet had such a substantial overlap with this copyrighted booklet, the city decided to start over, rather than risk being sued for infringing. This delayed production of the booklet for many, many years.
    Note: under the new copyright law, the authors of the draft would have had much better legal grounds to stand on, but still might have had to endure the expense and delay of a lawsuit to assert clear ownership of their work.
  • To encourage sharing by stating the eligibility criteria:
    The Web is a good medium for distributing information not just through URL links, but by providing information that others can take and adapt to their own needs.
    A copyright statement can outline the conditions for reuse (beyond the already permitted fair use). For example:
    • not for commercial gain
    • use in full or use in part
    • acknowledgement must be given
  • Needed: something similar to the copyleft used by the Free Software Foundation, but adapted to community groups.
    We have not had the resources to develop something that was specific enough and still terse enough to be used on the typical Web page.

• BASE tag and relative links: When I have a set of interrelated pages, my practice is to organize them in a directory structure that facilitates using relative links. I then put a BASE tag in the HEAD section of the page.
  • When I am updating the page, I can make a copy in a working directory and edit and test it there, and then copy it back to its public location when it is ready. The combination of BASE and relative links mean that all the links within the working copy still point to the public versions of the pages referred to.
  • The similar capability can be utilized by a co-author. This is especially desirable if the co-author is on a different computer that has a slow network connection to your: he need only save the page in question to his disk, then edit and test it. When ready, he transfers it back to you for installation in the public location.
  • If you move the location of a set of pages
    • Directory move (for example, site reorganization)
    • Host move
      • Change in ISP or other sponsoring organization
      • Transfer of responsibility for pages between people who keep their pages on separate computers
    With this arrangement, within the pages being relocated, you need to update only the BASE tag and the URL in the page footer, and not every link to the related pages within that set of pages. Of course, you will also need to update the links to these pages from pages that are not part of the group being moved (but you would have had to do this anyway).

Search Engines can be your friend

• Finding other useful sites: periodically check the database of one (or more) of the the major Web search engines for sites that point at your pages: Since these sites have included links to your pages as being of interest to their users, their site is likely to be of interest to yours.
  For example, using AltaVista's Advanced Query, the query for our site is

  ( link:"www.cyberstars.com/bp" or link:"www.pgc.com/bpa" or link:"www2.bpaonline.org/bpa" )
  and not ( host:"www.cyberstars.com" or host:"www2.bpaonline.org" )

  Explanation: our pages are spread over two hosts: www.cyberstars.com and www2.bpaonline.org, but both hosts also serve a variety of other home pages, so we have specified the link down to the top-level directories for these pages. www.pgc.com/bpa was the previous host for our site: Some other sites are very slow to update their links (even after we have notified them). Even after they have updated those pages, there can be a significant delay in their being visited by the various search engines. Note: some of the search engines have an easy mechanism for requesting a visit/re-visit to a page, and this request typically can be made by anyone, not just the owner of the page.
• Similarly, you can look for sites that link to prominent pages at other related sites. For example, you could pick an appropriate page at Yahoo! (either at a topic level or one of the pages they point to) and check who links to that page.
• Page titles
  • Remember that it is the World Wide Web. Many pages are highly specific to one locale or other grouping, but have titles that are deceptively general. Try to strike a balance between describing the coverage and the limits of your page.
  • Have a descriptive title for each page (some sites have the same title for all their pages, whether by carelessness or by policy). Be prepared for it to be truncated: put the most important distinguishing information early in the title.
  • Because many queries to search engines find far too many matches, many experienced searchers limit their query to looking at only the title, or prioritize the listing based on content of the title.
    Hence, you should think about making the page title descriptive for a search engine, as well as for display on the title bar of a window.
• Helping other groups find you
  We are experimenting with the META tags to help the search engines that take advantage of these tags.
  • Because search engines may truncate the information in the tags (for example, AltaVista truncates at 1024 characters), we front-load what we anticipate is the more useful descriptors.
  • Our current set of META tags:
    <META NAME="description" CONTENT="...">
    <META NAME="keywords" CONTENT="... Barron Park Association (BPA), neighborhood association, City of Palo Alto, Santa Clara County, California, USA, San Francisco Bay Peninsula">
    Explanation:
    • The "..." provide page-specific description and keywords.
    • Our organization name: Can be used to prioritize the listing produced from a search engine. At extreme, it can be used in conjunction with other words in the search to provide a virtual search engine for our site (we don't provide such a search capability as part of our site).
    • "neighborhood association": type information for people searching for information related to this category.
    • Geographical information: to help people narrow their search to specific regions, or to exclude regions. In ordering the entries, put the most useful first, in case your list is truncated by the search engine.
• Better listing entries
  On various search engines, do a series of searches with various options set and look for pages that show up well and poorly in the listing, and then examine the document source to see why.
  Basic advice:
  • Pages that seem to have nonsense characters in the description of the page presented by a search engine often have graphics as the beginning of the page (others have a different character set because they are in a different language). Different search engines have different capabilities and methods for minimizing this problem.
    
  • On many pages, the first heading is the same as the title. This is often good design: typically the title bar on the window does not give the information enough prominence, and some browsers do not print the page title when hardcopy is made (some by design, others by configuration).
    • When the title is so long that it is likely to be truncated in the search engine's listing, repeating this information as the first heading results it in being displayed (in full) in the description (summary, abstract) component of that listing.
    • Otherwise, this has the disadvantage that the same information is being repeated twice in the search engine's display, taking space away from later text that could be useful to the user deciding whether or not to visit your page.
  • Some search engines use the <META NAME="description" CONTENT="..."> (if present) to specify the description to be displayed in an entry returned by a search (instead of the initial text of the document). This can be a solution to some of the above problems, allowing you to separate how the page gets listed by the search engines from how it gets displayed in a browser.
• Explicit index pages: I strongly advise having one in each directory.
  Problem:
  • If there is no index page (typically index.html or a variant), most servers return a directory listing to the requester.
  • A spider given the name of a file in a directory may decide to "rationalize" its search by, instead of simply following links, to go to the directory index and get those file in order.
  • Even after a page has been deleted (or made inaccessible), some of its contents are easily recoverable from the various search engines, for example, the first N characters of text on the page.
  Consequences:
  • Working files and other drafts will appear in the search engine databases, even though there are no links to them from anything (except the implicitly generated index).
  • Version control files (RCS, SCCS, ...) can also wind up being indexed.
  Danger: Having multiple versions of a Web page listed can be
  • Inconvenient/Annoying: it inflates the search listing with lots of useless entries, causing the user unnecessary scanning.
  • Misleading: the out-of-date version (or draft) may well be listed first, and wind up being what users read (instead of the current version of your information).
  • Embarrassing: Items that you did not intend to make public -- and who among us has not been immoderate in our early drafts -- become very public. This is especially important in the political arena.
  Advice:
  • Automatically generate index files.
    On my UNIX (SunOS) system, I have the following entry in my crontab:
    18 0 * * * find public_html -type d -exec bin/create_html_null_index.sh {} ';'
    Where bin/create_html_null_index.sh is

    #!/bin/sh
    # Intended to be used from FIND command (and it from CRONTAB)
    # Arg 1: directory
    
    # Action: put "empty" index.html files in directly that do not have one.
    # Purpose: keep net crawlers and other indexing system from looking
    #       into directories via the automatically created index file.
    #       This is an issue for
    #       - revision control subdirectories (e.g., RCS): you probably don't want
    #               your obsolete text (and any comments in the change logs)
    #               searchable from these indices.
    #       - draft files in subdirectories.
    PATH=/usr/bin
    export PATH
    
    
    if [ -f $1/index.html -o -f $1/index.shtml -o -f $1/welcome.html -o -f $1/welcome.shtml ] ; then exit ; fi
    echo 'Creating empty (blocking) index.html file in' $1
    echo 'no index' > $1/index.html
    		

  • Do your drafting in directories not accessible through your HTTPD server by remote users.
    Sometimes this is impractical - for example, when you are using the Web to share drafts with your co-authors. In this case, double-check that your drafts are not visible to others and remove them promptly when done.
  • Have your version control files outside the area accessible by remote users.
    On my UNIX (SunOS) system, I use symbolic links.

Differences accentuated by Internet usage

• Different professional cultures have different approaches to information.
  Examples:
  • Information workers:
    Examples: managers, teachers, writers, lawyers, programmers, public relations, writers, ...
    Characteristics:
    • Formal, structured presentations
    • Collect, filter (select, prioritize, ...), and organize information
    • Information is an important product of their work, potentially the primary product.
  • Salespeople, interviewers, ...
    Characteristics:
    • informal, highly interactive presentations
    • establishing or maintaining a relationship with the customer or client is an important preliminary to the conduct of the primary business.
    • Information tends to be viewed as a collection of items that you pull out as needed.
  • Apprenticeship: people who have "learned by doing". Not just blue-collar environments, but a number of white-collar environments (formal education for the basics, but on-the-job training for most of what they do in practice).
    Characteristics:
    • informal, highly interactive explanations
    • information not regarded as a product of activity
    • enquiries often do not get a direct answer, but a reference to experience, intuition, or common sense.
    Aside: every profession I know of has a significant component of apprenticeship. Here I am talking about those that are predominantly this way.
• The Web is heavily biased (by its very nature) towards information workers.
  Although the key people creating and maintaining your web site will undoubtedly be information workers, some of that content will likely have to come from people who rarely create formal presentation of information.
  Potential responses for not providing content for your Web pages:
  • Sales, interviewer,...: Just put in a note telling people who have a question to come ask me.
  • Apprenticeship: It is a complicated area -- people interested in it should join the committee, working group, ...
• Misunderstanding motives: The prime movers behind your Web site should be careful not to assume that others are being uncooperative if they do not participate in providing content.
  • Their professional/technical culture may be so different that they are unable to understand the advantages of information sharing through a medium such as the Web.
  • Because they are not practiced at creating formal presentations, they may quickly become frustrated trying to put together something that they judge to be worthwhile.
    This problem may be more or less pronounced than for other publications (for example articles for newsletters) because the Web has different mixes of priorities and constraints.
  • "A little knowledge is a dangerous thing": People who are not practiced at creating formal presentations often have had bad experience with other people taking action based upon incomplete understanding of the problem or the domain.
    Information workers tend to under-appreciate how difficult it can be to partition information to minimize these problems because they have considerable practice doing it, and often they are not starting from scratch but are effectively working from a carefully debugged recipe or template in their presentations.
  • Giving ammunition to the enemy: On controversial issues, many people will have bad experiences with the information they provided being taken out of context, or otherwise twisted, and used against them. Information workers tend to be more practiced in combating this (some prevention, but mostly by responding to the distortions) and thus have different thresholds in evaluating the advantages and disadvantages of making information available.
  • Knowledge is power; knowledge is valuable: some people come from a culture that teaches that knowledge is valuable and thus not to be shared, but to be exchanged for something of value. Some of these people may see the information as part of their own personal power within the organization; others may see it as one of the organization's assets and that they have the duty to protect it from being squandered.
  If you browse our Web pages, you will see dramatic differences in the level of content provided on different topics, reflecting the above difference in attitudes toward the Web. These differences would be even larger except that some of the primaries behind our Web site have provided content for areas that are normally outside their responsibilities.

  In one case, one of our Web authors created a basic page for a committee and added a substantial set of Other Resources links. The committee vetoed the page, say that the Web was not what they were about.

Web "Case Studies"

• Status Information: Information on Street Construction.
  Web page provides basic list of pending and ongoing construction: simple resealing of asphalt, major resurfacing, excavation (for example, installation and repair of storm drains and underground utilities).
  When you get a telephone call from a resident, it is often easier to point them to the Web page than try to find the folder with the details.

  We have been encouraging the city and its contractors to provide us with electronic versions of their announcements and maps. There have been limited successes, but there is a long way to go.
  We have also attempted to get the contractor to provide detailed schedules of when various streets will be block or partially blocked by their construction so that we can post it on the Web (or provide a link to a page on their Web site). No success here yet. One contractor was willing, but updating the information kept "falling between the cracks"

• Major Issue and Lobbying: Flood Control Decision
  This set of pages tracks a series of public meetings. Information distribution both to prepare residents for a meeting and to inform those who could not attend of the results.

  We used these Web pages as part of our briefing of the press, and the URL of the toplevel page was given in newspaper articles as where people could go to get more details.

  We had this listed under Hot Topics link on our Home Page and, during the key period, a link appeared in the "banner box" on our Home Page itself.

Virtual Web Site

Our Web site is spread out over multiple computers.

• The creation and maintenance of our core set of pages is spread over a small group of people who coordinate to try to maintain some consistency in the appearance and organization of the pages.
• There are a few other pages create by people outside this core group that have been links to them from our core pages.
• Problem: When your sites official pages are spread over multiple, and potentially changing, hosts, how are users to know which pages are truly part of your site, and which are independent pages that you are providing links to?
  Our practice for links that are not subject to (or responsive to) our editorial review:
  • Typically clumped in sections such as Other Resources or Collection of Links.
  • When a separate section is inappropriate, we identify the link with a label that designates ownership, thereby implicitly stating that it is not one of our pages. For example, DESCRIPTION by resident PERSON

Implications and consequences:

• Fewer bottlenecks: since the pages are on the local Web server of the person responsible for maintaining them and updating them, there is no central point that can become a bottleneck.
• More content: By allowing multiple people to create the core pages, we can spread the workload over a larger set of people.
  Note: we believe that the amount of useful information available at a site needs to quickly get above a certain threshold in order for the site to get repeat visits.
• Problem with tools: Many tools for administering Web sites are based on the assumption that a Web site corresponds to a single directory tree on a single server. A virtual Web site can severe limit your choice of tools.
  Aside: and since virtual Web sites are relatively uncommon, my inclination is to be highly skeptical of any claims that other tools handle these situations: while they may have been designed for such situations, I would not expect that they had been adequately tested.
  Exception: Search Engine for your site
  I chose to use ht://Dig for indexing our site because it easily handles the problem of virtual sites. The other commonly used free search engine, SWISH-E (Simple Web Indexing System for Humans - Extended), does not (at least at the time I looked). ht://Dig allows you to:
  • create a database for the search engine starting from multiple roots (URLs or local directories),
  • exclude subdirectories and URLs from the search,
  • create multiple databases that are searched separately. For example, the Web pages are one database and each archive of messages to a mailing list is a database. Thus, by narrowing the items searched, the user gets fewer unwanteded hits, even for simple search criteria.
  • composite databases (called collections) can be created from individual databases directly, rather than by re-processing the web pages (see ht://Dig's multidig package).
• Server-side includes:
  • Advantage: can simplify updating information that occurs in multiple files.
    • Example: the contact information for an individual. If someone changes his/her e-mail address, server-side includes enable you to have that information in a single file that gets updated, rather than having to check all the pages at your site and then update it.
    • Example: coordinating format for contact information
      If all addresses for people are in server-side include files, then if you decide to change the format of that entry -- say from using the person's name as the label of the mailto link to having it labeled e-mail -- then it is much easier to update everyone at once because the include files are typically organized to be in a common directory.
  • Disadvantage: sharing information is typically harder than you expect
    • Forcing initial version of pages to accommodate the current format of the include file.
    • When the format has changed, it may disrupt the readability or format of some of the documents where it is used.
      Problem is finding and checking all those instances.
  • Big disadvantage: incompatibility across our virtual Web site
    • Different servers have different methods of providing server-side includes
    • Some sites turn off the server-side include capability because it increases the computational load on the server.
    • Pathnames used for server-side includes would have to be modified when we moved pages from one server to another because of large variability in the pathnames of the pages on the different servers.
  • Too difficult/fragile/inconvenient for us

Hints and Tricks

• Meeting Locations, Maps, Directions: helping people find their way
  • When you are having a meeting at a location that people may not be fully familiar with, include a link to a map customized to show that location.
    I prefer Yahoo! Maps, but there are other alternatives. I type in the address of the meeting site, get the map, and then copy-and-paste the URL for that page into the Web page as a link.
    For example, I recently wanted to assist people going to a meeting at the SCVWD Offices at 5750 Almaden Expressway, San Jose, CA 95118-3686. Rather than expect each person to manually transfer this address into the generic map-request form, I did the above procedure, producing the link:

    Map showing location of SCVWD Offices

    The reason I suggest copy-and-paste, rather than manual copying, is that it is much faster and more reliable: these links are typically quite long, and filled with special characters. The above link is

    <A HREF="http://maps.yahoo.com/yahoo/yt.hm?FAM=yahoo&CMD=GEO&SEC=geo& AD2=5750+Almaden+Expressway&AD3=San+Jose%2C+CA+95118-3686">

    On some browsers and platforms, it may be difficult to copy-and-paste the URL from the browser window. If so, bookmark it, then open the Bookmark file (varies in name and location for different browsers and platforms), and copy-and-paste from there.
    Warning: The Bookmark file is maintained by your browser. Copy from this file, do not Cut. Also, some browsers do not immediately write out new bookmarks into this file: you may have to wait a short interval, or may even have to exit the browser to force an update.
  • When the location is distant, you may also want to include driving instructions.
    Many of the sites that offer street maps also offer driving instructions, but the generated instructions may not be optimal. However, you can fix many of these problems by slightly changing the starting address. Since this may involve multiple experiments before you get the "right" answer, repeating the above procedure (enter, check, copy-and-paste) saves your readers from having to repeat this experimentation (or having to know that they can fudge the starting address to get a better route).
    For example, to get to the above address, the following two driving instructions were generated:
    • El Camino to 85 to ...
    • Page Mill to 280 to 85 to ...
    The first starts in my neighborhood, and takes you along a route with heavy traffic and many stop lights. The second starts "just around the corner", and quickly gets you on the highway.
  • Depending on the sophistication of your readers, you may want to explicitly note some of the functionality of the map pages that you are linking to (for example, zooming in and out, generating driving instructions from other starting points).
• "Under Construction": This should be used judiciously (rarely, if ever). Be considerate of the reader - don't waste his time. Some guidelines:
  • Current assumptions (2000) is that Web pages and Web sites are dynamic entities, that they are always under construction. Hence, the label of "Under Construction" has become rarely used.
  • If a page is not online, do not have a placeholder page that simply states "Under Construction": your reader has followed the link and may have had a significant wait for this page to download.
    Instead mark the not-yet-activated links to the page with "Under Construction" or equivalent (for example, "Coming Soon").
  • If a page is good-enough to be worth reading, but still a draft, you may want to mark it with "Under Construction" to let the reader know that content and organization may change (especially useful if the reader is considering establishing links to your page). Attach a note to the "Under Construction" notification explaining the anticipated changes.
  • If you have a partial draft, and the completed sections are worth reading, you may want to mark the sections that are absent with "Under Construction", or equivalent, so that the reader can see that they may want to revisit the page in the near future.
  • Some pages that initially appear to be completed documents are actually living (dynamic) documents. My tendency is to mark these pages as "evolving" in the page's prologue, thereby distinguishing them from pages that are likely to change because they are drafts.

Collaborative Authoring

However, collaborative authoring through e-mail has many problems when you apply it to a composite document, such as a newsletter composed of articles from multiple people.

• Overlapping articles: how to resolve
  • Problem: ...
  • Differing styles / voices
    Often easier to blend Person2's contribution into Person1's than vice versa.
  • Differing responsiveness in e-mail: should not be a race (where the fastest wins), but with deadline, it can turn out to be that way.
• Who blends in comments?
  • Example situation: someone responds to a draft saying that there is a problem with a certain passage (ambiguous, confusing, ...) and giving some general suggestions on how to fix it. The author replies "OK", but never supplies a revised wording. Did it slip his mind? Or did he think that saying "OK" meant that the other person should rewrite the passage?
  • Example situation: The author of an article responds to comments with a revised passage, but it does not exactly mesh with remainder of the article (because he has dealt with that one passage outside the context of the full article).
  • Author?
    • Extremes:
      • unwilling to take any suggestions
      • too willing to take bad suggestions
    • May not be responsive enough to deadline pressure
  • Editor?
    • Not best judge of facts related to suggestions.
    • Too many e-mail messages, not linearized, often composites. Can be a nightmare to untangle various suggestions for changes.

Other Resources

• The Tos and Froms of E-Mail
• The Alertbox: Current Issues in Web Usability by Jakob Nielsen, Sun Microsystems
  especially: Writing for the Web (Alertbox March 15, 1997), Inverted Pyramids in Cyberspace (Alertbox June 1996) and embedded links.
  These articles provide a nice, concise statement of many of the basic points of Web design. They are useful not only to the novice Web designer, but to the experienced Web designer who is attempting to explain his design choices to a larger group.
• Web site management tips -- round two by Chuck Musciano, from March 1998 (vol 12, 3) of SunWorld Magazine
• Rights and Responsibilities of Participants in Networked Communities
• Book (out-of-print): NetActivism: How Citizens Use the Internet by Ed Schwartz
  I have not read this book, so I can make no recommendation. Listed because it was one of the few relevant items that my searches found in this area.
  At Amazon.com
  Excerpt at O'Reilly
• How Internet is Changing Politics: A Discussion
• Book: Community Building on the Web:Companion Site with online excerpts.
• Hot US Community and Community Economic Development Sites The result of a class project in Spring 1996 which has not been updated. It could be useful as a listing of longer established sites in this domain (source of examples).
• Etiquette (partial, unordered, random collection):
  • Local Etiquette Guidelines
  • Basic E-Mail Ettiquette
  • E-Mail Etiquette
  • The Net: User Guidelines and Netique by Arlene H. Rinaldi
  • Netiquette Guidelines RFC 1855, from Responsible Use of the Network (RUN) Working Group of the IETF
    Local copy
  • Dear Emily Postnews(satirical) Heavily oriented towards etiquette in newsgroups with some relevance to mailing lists
• Polls/Surveys related to Internet usage:
  • Poll by Wired/Merrill Lynch Forum: The Digital Citizen Survey - Results
    and accompanying article in Wired The Netizen - Special Report
    Assessment: Poorly conceived and executed. Degree of connectedness is based upon the communication equipment that one owns rather than how it is used. For example, someone who has a pager and checks their e-mail three times a week is categorized as more connected than someone who doesn't have a pager, but "lives" inside e-mail and the Web; a person who is both a Web master and e-mail list manager but who does not own a cell phone or a portable computer is classified as only "semi-connected." If you look at the individual questions, you will see multiple cases where a higher percentage of people classified as "connected" behave in a more connected manner than those classified as "superconnected," and there is considerable connected behavior by people classified as semi-connected.
  • Poll (very small) done in East S.F. Bay: Internet Usage, Political Affiliation, Voting Frequency
  • Survey of Barron Park Residents, December 1997.
    Includes several questions about Internet access and use by residents within our neighborhood.

Change Log

• 15 Oct 2000: Added experience switching over to majordomo too E-mail list management
• 15 Oct 2000: Added link to Experience reducing Spam
• 14 Oct 2000: Added link to My etiquette guidelines
• 14 Oct 2000: Added recommendation on search engines
• 02 Dec 1997: Added section Hints and Tricks
• 03 Dec 1997: Added section Virtual Web Site
• 05 Dec 1997: started section Collaborative Authoring
• 19 Dec 1997: started section Web "Case Studies"
• 19 Dec 1997: added Under Construction item in Hints and Tricks
• 23 Dec 1997: added Tone: Advocacy and/or Reporting to section Content decisions in Web Site Design.
• 07 January 1998: added subsection Use similar organization to Web Site Design
• 12 January 1998: added bullet E-mail list entry tracking in E-mail to residents.
• 13 January 1998: added subsection Page Division to Web Site Design