So What?

1.Current (April 2004) discussions of Web usability usually involve some degree of user-centered design from the extremes of Control to Consensus (perhaps better termed "indivualization"). Somewhere between those extremes exist groups of users in face to face (F2F) communities. These communities often use Web tools and online interfaces for communication, and those exchanges become public content based upon (or private archives keeping record of) their interactions. These F2F communities have observable cultural features (rituals, traditions, taboos, expectations, etc.) that may inform the process of designing Web sites and tools that facilitate communities' needs rather than interrupt the exchange of information. These cultural features may suggest a better solution than Control or Consensus: a Compromise, dictating certain features or interfaces when necessary but soliciting feedback on other aspects of the site.

2.In To Engineer is Human, Henry Petroski relates the story of making a slingshot for his son Stephen. Though their first attempts broke from strain, and the middle attempts offered weak firepower and difficult operation, they finally developed a model that outperformed the store-bought slingshots of Stephen's friends. The process offered the younger Petroski the opportunity to learn to make things that work by steadily improving upon things that did not work. He learned from mistakes(34). Can we not skip ahead? Learn from our own and others' mistakes? Anticipate? Jakob Nielsen's and Donald Norman's design recommendations reflect this type of learning from mistakes. Usability testing offers controlled ways to make mistakes and learn from them. In current models, though, these tests and recommendations focus on test users as representative but individual users.

3.Nielsen's and Norman's recommendations tend toward a "least common denominator" approach to design, placing the onus of usability upon the designer, but expecting very little from the user or community. This seems over-corrective. Robert R. Johnson's user-centered model, though, is likewise over-corrective and again places the onus of usability on the designer. This time the imperative is easily extrapolated into making either a "one size fits all" site that flexes to any possible users' need or wish, or a "one stop shop" that has every feature ever requested by any user.

4.We must focus on the specificity of our user base rather than specific users, or even representative users. My intent is to position Compromise as another range of alternatives, in which designer and community of users negotiate to achieve a middle ground, and renegotiate as needs change. Sometimes designers (and sysops) need to dictate a design or an interface for efficiency. Hopefully, the designer has sufficient facility in rhetoric and usability to adequately Control this feature. At other times, the needs and desires of the community require reaching some sort of Consensus, in which the designer in not only a provider of resources for the community, but also a contributing member of that community.

5.The design process must be iterative. The interface must evolve as we communicate with the real users, not a test group. Users and designers should both expect some degree of change--an almost organic ebb and flow. But there should be limits. To some degree, every Web site should be unique. But every designer need not reinvent the wheel, as it were. Testing a custom-built site is a different process from testing a build of a proprietary or packaged software tool. Petroski describes much of the Web, particularly portal systems for community Web sites, when he says that

there is a difference in the design and development of things that are produced by the millions and those that are unique, and it is generally the case that the mass-produced mechanical or electronic object undergoes some of its debugging and evolution after it is offered to the consumer. (26)

Deploying ready-made, proprietary software without first doing a user test or demo guarantees a repetition of what Petroski describes. Deploying portal packages and packaged forum builds is a Control strategy infused with some distant, uninvolved designer's expectations for usability. Sometimes a portal package is the best way to go, but even a decision like this could be tested and discussed with the user community.

6.The goal of this site is to suggest new ways of thinking about audience in order to help designers find strategies for building the best site for their context. That context may include aspects of time, place, audience, and purpose; therefore, the designer must be flexible and recognize the need for that flexibility. Access to certain portions of a site should be easier or faster at certain times (e.g. positioning course list links on the first page of a site during registration times, or including on main entry pages links to special events in the weeks leading to those events), but it is not possible to make that ease and speed universal and consistent. We should reverse engineer websites based on criticism and research about users and their needs within the context of communities. We must keep in mind that there is no one "representative user" for any site, but there may exist a representative culture. That culture should be the basis for developing Web sites for F2F communities, and, if possible, should inform designs for other many to many community Web sites.