Creating and Maintaining Online Communities Through Rhetorical Thinking
AmyLea Clemons
Submitted on 27 November 2007 to the On-line Interaction and Facilitation Seminar, Fall 2007, Purdue University,
Dr. Sorin A. Matei via the I Think Blog
Creating successful and vibrant online communities has been the subject of much debate: How much control should the founder have? Who should moderate and mediate for the community, if anyone? What design plans best encourage development of and participation in communities? How do we ensure the community will operate as planned? Although the ideal answer to any of these questions is “It depends,” this paper examines the best practices any community founder should follow and the processes he or she should consider at each step of community creation. The essay concludes with a discussion of Lloyd Bitzer’s “The Rhetorical Situation” as a quick and easy schema that online developers can use to simply the process.
Although the dotcom burst has leveled the enthusiasm for the internet somewhat, online communities—that is, a group of users who post to and create a central web space—still present as viable and vibrant spaces for growth. Creating successful and vibrant online communities, however, has been the subject of much debate: How much control should the founder have? Who should moderate and mediate for the community, if anyone? What design plans best encourage development of and participation in communities? How do we ensure the community will operate as planned? Although the ideal answer to any of these questions is “It depends,” this paper examines the best practices any community founder should follow and the processes he or she should consider at each step of community development.
Definitions and exclusions“Online community” can mean several different things. Although we are now long beyond the debate over whether or not communities can exist online, what exactly these communities do or how they relate to their real world counterparts is still in discussion. Online communities differ from face-to-face communities in several ways, but also share significant overlap. Jenny Preece (2000) divides online communities into four components: People interacting “socially;” a “shared purpose;” policies; and computer systems (p. 7). These four components help identify an online group as a “community” and can serve as areas of analysis for developers.
Although all online communities may share these four components, the “shared purposes” can vary greatly. In a 2004 study of twenty seven bulletin boards (BBS) communities Ridings and Gefen found that use of online communities is not just limited to information-seeking, but that “virtual communities, like real ones, are joined not only because of utilitarian information exchange, but also because they serve the social need of having a friend and getting social support.” It is clear that some online communities are skewed toward information exchange or social support, and that the design, development and implementation of any online community will depend heavily upon the goals and activities the developer expects to occur.
This essay will be limited to discussing online communities that mainly foster social interaction instead of information gathering; of course, information distribution can be expected within these communities as well, as per Ridings and Gefen’s study, but the communities and processes described in this discussion will focus on groups that emphasize interaction over information, eliminating communities involved in e-commerce, journalistic blogging, and social bookmarking. In the following discussion, then, “online community” will refer to community blogging platforms, support networks, and social networking communities such as Facebook.
Further, it should be noted that, as with “real” or face-to-face communities, no community is prototypical. Preece (2000) reminds us that “Each community is unique, and there is no guaranteed recipe for a successful community” (p. 7). She also provides a helpful metaphor for developers to consider:
“Communities develop and continuously evolve. Only the software that supports them is designed. Thus, the role of a community developer is analogous to that of the mayor of a new town, who works with town planners to set up suitable housing, roads, public buildings, and parks, and with governors and lawyers to determine local policies” (p. 26).
It is with this metaphor in mind that best practices for online communities are proposed for each of the following areas: Planning, Designing, Implementing, and Evaluating.
PlanningWhen planning an online community, developers should be prepared to conduct research in at least two areas. First and foremost, the community should have a clear, central focus. Because online communities do not have a physical locale to ground them, they must be grounded in other ways, particularly in a common goal. Users report participating in online communities for several reasons, especially for discussing a shared interest. (Ridings & Gefen, 2004). Thus, developers should engage in initial studies to determine possible user interest and the specific direction of that interest. A community for sufferers of Chronic Fatigue Syndrome, for example, would not only be interested in sharing their experiences, but might be specifically interested in sharing coping tips, trading doctor names, and linking to unique treatment options. More importantly, developers should recognize whether the “interest” is strong enough to translate into “participation.” The purpose must be strong enough to incite action among regular users and lurkers alike.
A secondary research area is related to the first: audience analysis is essential to determining the direction of an online community. No online community is created in a vacuum; a profile of potential users can tell developers much about the probable direction of the community. While there are many approaches to audience analysis, Baym provides a simple and effective schema. Baym (1998) lists four categories for consideration: external contexts, temporal structure, system infrastructure, and participant characteristics. Of these, the external context of the participants and the participant characteristics should be the main focus for developers at the planning stage. In determining the context and characteristics of potential users, researchers should ask several questions: What demographic would this community serve? What do we know about their access to and familiarity with computer mediated communication? What constraints might there be on the users’ abilities to participate? What environmental conditions might actually encourage participation by our target audience? These questions are essential to address before the community is made “live,” so that designers can use the tools available to them to encourage participation in specific ways. For example, while Chronic Fatigue patients may be interested in such a community, the conditions of the illness itself will prevent many from participation; developers should note such constraints and determine if they will effect the initial building process.
As they prepare such research, developers should note that “participation” comes in many forms. “Lurkers,” or users who read the exchanges of other members of an online community without contributing to the community themselves, must be considered as part of the community, despite their invisibility. Ridings and Gefen assert that “arguably lurkers are members, albeit silent ones, in virtual communities” and that they
“should be of interest to companies and to researchers. Moreover, lurkers must actively navigate to the URL and occasionally even login to this type of a virtual community to obtain access to it. In doing so, even a lurker becomes an active, albeit silent, participant” (Ridings and Gefen, 2004).
Developers must keep lurkers in mind when planning a community: because research suggests a large percentage of “users” of online communities are actually lurking, a community should be built to accommodate lurkers without pressuring these users to give up their anonymity or to invest more time or emotion that they are willing to. When considering potential uses, developers must assume lurking will occur, and should design accordingly.
In summary, community developers must begin with a strong purpose and sense of audience before beginning design of software and web spaces. Once interest and audience have been established, developers can move on to the more difficult task of creating a style, a signature, a theme, and a “presence” for their community.
DesigningOnline communities have sprung up across the web in such vast numbers that the introduction of a new community will not necessarily register to most users. Therefore a new community must not only be easy to use in order to encourage participants in the early stages of the community’s development, but it must also stand out visually and conceptually.
The best designs are “intuitive,” as Krug says in his 2005 book Don’t Make Me Think! “Intuitive” in this case, refers to ease of navigation; users must be able to sort through the layers of the site in order to find specific areas of interest. For this reason, the front or “home” page requires the most consideration. One option that many businesses and nonprofit online communities alike now use is a “splash” page, which provides easy entry to the subsequent pages for both regular and first time users. Splash pages include simplified instructions, large graphics for site navigation, and prominent login boxes. Splash pages limit the number of options a user may take to enter and move through the site, which thus limits the overwhelmed feeling many first time users get and prevents regular users from wading through unnecessary material. Splash pages must be visually interesting without looking “busy” however; Krug (2005) finds that many sites, in an attempt to catch the user’s eye, are instead distracting and confusing, causing readers to abandon their search.
From an introductory page, such as a splash page or a more traditional “home” page, each major activity developers expect to occur on the site must be accessible and easy to locate. For example, a community for single fathers might focus mainly on forum or bulletin board postings, and these forums should be accessible from the home page. Other activities on the same “level” as participating in the forums (such as uploading photos, linking to news articles, making important site-wide announcements) should also be accessible from this page, and each page on the same level should carry the same basic design. Maintaining a “theme”—a page template that keeps color, pattern, navigation and language uniform across several pages—not only makes the site easier to navigate, but creates a sense of location in “real” space; recurring design motifs help to stabilize an otherwise ephemeral “cyberspace,” and these motifs give the site a visual identity users can connect with on a sensory level.
Above all, design should aim for ease of use, because when a site is easy to navigate and post to, users will be more likely to participate. For the best interaction, posts to the online community should be made using the simplest software available—no user should have to learn special coding (unless they want to) in order to participate. Wiki softwares that allow users to simply add content without “uploading” are best, although any software (such as WordPress) that uses a WYSIWYG (what you see is what you get) editor that works like a word processing program should suffice.
Using software that allows users to post without learning extra codes should ease some of the posting anxiety that might prevent lurkers from participation. Another way to encourage lurkers to become more visible is to create levels of participation. Many sites now track the number of readers each post receives, which can serve to highlight the presence of lurkers, even if they choose not to “speak.” Yet another option is to require users to log in to read and comment on some posts; LiveJournal requires users to create an account to read material that posting members select as “private.” By requiring log in, developers can better track who logs in when, and how often.
The best designs are not only easy to use, but attempt to make the community feel “real” to users; this can be accomplished both visually and via the software’s functionality. Visually, the site’s various sub-pages should be unified by a common theme, as described above. By maintaining consitency among pages, developers create a sense of static, permanent space, as “real” communities tend to occur in a single physical place. Structurally, the software platform should support this sense of community by creating other visual cues for the users. Because computer mediated communication tends to filter out the social cues we are used to experiencing in a “real” community, an online community may be made to feel more “real” by adding back in cues that allow users to identify themselves in whole or in part, as with a picture of themselves, or simply adding their real names (Walther & Parks 2002).A prominent “Who’s Online” function in the navigation or side bars can show visitors and registered users alike the names of users currently occupying the site; this function emphasizes a shared space and shared time, and encourages users to connect to each other—they know they are not alone in the cyberspace of the community. Other functions that should be considered include
- Large, easily visible “Comment” buttons on each user posting so that threaded conversations can begin in the space they are begun.
- Time stamps on each comment that allow users to more easily imagine the person on the other end of the conversation.
- “Tags” for each conversation. Tags are key words that users categorize their posts with. Lists of tags on the main page allow people to see what’s being discussed most frequently, and links them to users discussing similar topics.
These simple functions should be incorporated into the site design when available. The prominence of each feature depends upon the purpose and function developers want to foster in a given community, and these decisions should be made early in the design process.
One final feature that communities working with a younger demographic should consider is the use of avatars. Avatars are graphical representations of the user—small images attached to each user’s post and profile that can be changed easily depending on the user’s mood, the post topic, or the community’s focus. Older users may not feel comfortable with these images, or may not have the technical ability to create them as easily as younger generations do.
Once the design has been set, the community _site_ is ready to “go live”—to be made public to the internet in general. As the community begins building, developers should begin considering key questions of implementation and evaluation.
ImplementingHow to manage and implement online communities continues to be a hotly debated subject. Some argue for a central moderating figure (usually connected to the supporting organization), while others find that moderation is best done “organically,” by users themselves. Nearly all, however, agree that some type of moderation is necessary, and moderation begins with setting initial guidelines and rules for all users to follow.
Guidelines or rules should be set early on, but should always be open for reconsideration. In particular, developers should consider the following issues before beginning:
Politeness to other users. “Flaming,” or harrassing or abusive comments between users on a given thread or topic, should be kept to a minimum. Politeness online also includes restrictions against profanity or overly graphic descriptions. The level of “adult” language allowed is contingent upon the goals and audience of the community.
- Length of posts. Overly lengthly posts can clutter a site, and often makes other users feel croweded or silenced. Krug (2005) states that “We don’t read pages, we scan them,” and that “if the document is longer than a few paragraphs, we’re likely to print it out because it’s easier and faster to read on paper than on a screen” (p. 22). Most software platforms provide a “cut” or “more” function that trims posts to a more readable length for the front page, but a maximum post length should be set to keep the design looking even.
- Off-topic posts. While the occasional non-related post can lighten the mood or break the monotony of a group, too many off-topic posts can detract from the original goals and purpose of the community. Limiting off topic posts can also limit spamming and advertising.
Once the rules have been tentatively set, developers should post them high in the hierarchy. To ensure users at least know about the rules, the guidelines should be presented as part of the registration process. Many sites now require users to agree to a “Terms of Use” contract before joining communities as registered users; these contracts list the rules and any other legal information, such as copyright laws. In general, rules are not only a good legal reference (for extreme cases of abuse), but gives users a shared responsibility that, again, builds a sense of “real” community.
Legislation of the rules should be carefully considered. Again, the use of a moderator is necessary for almost any site, but the type of moderator and the process of moderating varies. :Developers must first decide between a moderator chosen by the administrators and a moderator that arises “naturally” from the users themselves. Once a moderator (or moderators) is selected, the particular role this moderator would play must be outlined. Questions to consider include
- What “punishments” are appropriate for rule breakers? Will moderators have the power to remove users or deny them access?
- How will users be alerted of offenders and offenses? Some sites issue mass emails, others send separate notes to each offender for each offense.
- How will rules be enforced? Some communities periodically post site-wide reminders, others assume users will conform without reminders.
One of the touted benefits of online communities is the tendency of such communities to be more friendly to those who are less socially adept or who are marginalized by the dominant society. These utopian notions are likely naïve, but the presence of rules and guidelines should not detract from the sense of “communitas”–an almost magical sense of communion that moves “toward universalism and openness” (“Rites”). Finding balance between regulation and chaos may emerge “organically” from the users themselves, but developers should be prepared to step in when necessary.
EvaluatingThe key questions a developer should ask once a community has been active for several weeks are “Is it working?” and “What can we do better?” Evaluating an online community’s success can be difficult, as markers of success can sometimes be less thank obvious. Although success can be measured in many ways, the easiest aspect to measure is volume; although there is much more to a successful community than the number of users and posts alone, these can be good places to begin evaluation. In particular, developers should address:
Number of users, both registered and lurkers, if possible.
- Number of hits.
- Timeline of hits: When are people logging on? What are peak hours? Is there a particular time of month? Is the timeline related to any site changes or administration changes?
For those that find a community failing to meet expected volumes, new strategies of finding and motivating users should be implemented. To advertise the community, developers should locate sites focusing on similar issues in order to promote their own sites. For communities related to a profession or trade, developers might consider advertise in the journals or magazines that serve those trades. To ensure users can find the site easily, web managers should ensure that search engines such as Google can find the community.
Other enticements can increase participation. An empty community is rarely inviting; developers should make the space look occupied; founders can begin threads in forums or post questions to invite conversation. Some sites benefit from “guest bloggers” well known among the potential community members. Any post from a new community member should be promptly and encouragingly commented upon by founders and developers.
Ultimately, even well-populated communities may require evaulation and revision if users find the site design and software structure difficult to use. Periodic informal usability testing can help designers improve the functionality of the site with little cost to the developers; brief surveys every few months can keep designers and developers abreast of any emergent problems as the community changes and grows.
The Rhetorical Situation: A shorthand guide to community developmentThe above suggestions and points for consideration detail possibilities for online community development. However, many of these decisions are contingent and based in the specific situational context. When considering each of the above possibilities, developers should keep in mind what is commonly called the “rhetorical situation,” a “complex of persons, events, objects, and relations presenting an actual or potential exigence which can be completely or partially removed if discourse, introduced into the situation, can so constrain human decision or action as to bring about the significant modification of the exigence” (p. 6). Bitzer offers three points to consider when attempting to define the rhetorical situation: Audience, exigency, and Constraints (p. 6). Others have added to the list, adding a “Context” category to further define historico-political elements; extrapolating the “Audience” seciton to include gender, race, and class issues; and adding to “Constraints” to discuss means of production. Taken as just Bitzer’s original schema, however, “the rhetorical situation” offers a framework for analyzing any situation in which texts are produced.
Online communities, as text-based constructions, are rhetorical situations as defined by Bitzer. Each of the previous sections–planning, design, implementation, and evaluatoin–can benefit from an analysis of the rhetorical situation at each stage. Because each community is different, each rhetorical stuation is different, and by detailing the situation, developers can better tailor the above suggestions to their own community. Additionally, a rhetorical analysis prevents developers from developing hard and fast rules that can stagnate a community. Thinking rhetorically can also highlight room for potential change and growth; in analyzing constraints, developers can find ways to remove barriers or exploit an absense of limitations. Thinking rhetorically also helps developers to determine the best way to moderate communities; remembering the users are also humans who interact textually can prevent clashes and promote good relations between moderators and users.
Many of the points for consideration above should be read through the rhetorical situation. The particular rhetoricity of online communities seems to call for extra attention to the community’s textual practices (both verbal and visual). While it make take a little more work for developers to learn rhetorical language and theories, adding a rhetorical perspective to the above will doubtlessly promote growth and vibrancy in the community.
ReferencesBaym, N. (1998). The emergence of on-line community. In S. Jones (Ed.), Cybersociety 2.0 (pp. 35-68). Thousand Oaks: Sage.
Bitzer, Lloyd (1968). The rhetorical situation. Philosophy and Rhetoric, 1 (1), 1-14.
Krug, Steve (2005). Don’t make me think! Berkeley, Calif: New Riders Press.
Preece, Jenny (2000). Online communities. Chichester, England: Wiley and Sons.
Ridings, C. & Gefen, D. (2004). Virtual Community Attraction: Why People Hang Out Online. JCMC 10(1), article 4.
Rites of Communitas (2004). The Routledge Encyclopaedia of Religious Rites, Rituals and Festivals. (pp. 97-101) Ed. Frank A. Salamone. New York: Routledge.
Walther, J. B., & Parks, M. R. (2002). Cues filtered out, cues filtered in: Computer-mediated communication and relationships. In M. L. Knapp & J. A. Daly (Eds.), Handbook of interpersonal communication (3rd ed., pp. 529-563). Thousand Oaks, CA: Sage.
