Home \ Computer Mediated Communication \ Factors of a CMCS
Intro

There are certain general characteristics and factors of Computer Mediated Communications Systems that are key to success. These are helpful in conceptualizing the basics behind a CMCS as well.

Evolution
Typical information systems are static: information is sent and received, input and output. However, dynamic systems change throughout time. They have pasts and futures, in addition to existing in the present. Just as creatures evolve in order to survive in changing conditions, the system should be able to adapt itself to any environment and issues that crop up.

Comprehension
A comprehensive system finds a striking point between two extremes: simple and complex. A simple system means that the user can enter and participate in the system quickly, but may lack general functionality. A complex system could be amazingly functional, but requires a steep learning curve from the general user community. A "Comprehensive" system should include functions that facilitate the general purpose that the groups are collaborating over, while allowing the user to begin communications as quickly as possible.

Forgiveness
This point is tied into comprehension, in relation to the time necessary to become acclimated to a system. A new user will be unfamiliar with the commands and may try a few out. After all, the old saying goes, "You can only get used to something by getting your feet wet." However, the user should know that they can't break the system by experimenting. If while experimenting, a user enters a command and garbase text is returned, that user may not be as inclined to use the system. On the other hand, if you take the same scenario and substitute a polite error message: an answer to the effect that "The action you have taken is not possible, please re-enter the command", the user will correct their actions and continue to use the system.

Community
This point is an interesting play on the Groupware concept that capable software should be able to support the necessary group processes, but there must be a group that can use that system. Even if a system is perfect: if there is no group to use it, or the audience is incorrect, the system is missing a critical component.

User Activities
The title of this section is a bit of a misnomer. Users need methods to collaborate, whether the method is through conferencing, chats, voting, games, or any other medium. Any of the formerly mentioned are "Activities" for the user.

Text Abilities
Since the communication medium in a CMCS is text, the user should have an advanced ability to manipulate and describe their thoughts through that text. This is accomplished in varying ways: text decoration (such as underlining, italics, and bold), paralinguistic cues (such as "smilies" or "emoticons"), or graphics (The latter being impossible in CMCS in the 70's/80's, though a reality today). The EIES system took this a step further, by allowing general functions coded in their INTERACT language to be executed from within the text.

Privileges
Murray Turoff once famously said, "It's just as easy to program a dictatorship as a democracy into a Computer Mediated Communication System." In reference to this statement, the level of ability in a system is controlled by privileges. These range in all aspects of the system, from initial access to functions within the system. Taking EIES as an example, a user could have access to the default EIES interface, or be "trapped" into a conference, so that on login they were taken directly into that exchange. Taking EIES again to given an example of privileges for functions within the system, the NOTEBOOK system allowed a user to read an modify their own notebook, and grant the ability to any user to read and/or modify that notebook. This particular example has not of yet been replicated with modern technology, and is an excellent example of the power of privileges within a CMCS.

Histories and Logs
Without histories and logs to keep track of user activity within a system, there is no accountability. Histories are needed for both edits within elements in the system, and edits to elements of the system (see Evolution for details on the latter). A log does not need to be elaborate: simply who did what on when, why is optional depending on the user policy in the system.


Bookmark Us | Getting Started | Change Languages | Site Map