Welcome
Chat tools are nowadays an integral part of many collaborative e-learning environments. However, standard chat tools suffer from important coordination and coherence deficiencies. OmegaChat is an open source generic framework for building malleable structured chat applications (for educational settings in particular). With OmegaChat users can strengthen or relax constraints when they want during a chat session.
Regular chat deficiencies
Research works rooted in the sociological study of conversation have identified important coordination and coherence issues in standard chat tools. The most important is the lack of control over turn positioning. Since turns can be sent simultaneously by a number of participants, there is no guarantee that a next-turn, for example a response to a question, will appear directly after the question. Instead other turns may appear between the question and the response, causing confusion over threads. The consequence is a preference for short turns so that the response might be closer to the question, if sent quickly. Standard chats are not places where carefully constructed messages can be sent. Lack of visibility of turns-in-progress, because chat systems only transmit turns when they are completed (ENTER key), and lack of visibility of listening-in progress, because participants do not receive moment-by-moment information about the reaction of those who are listening to them, are other examples of well known coordination issues.
OmegaChat: a structured chat
We consider that most of the deficiencies are consequences
of the unstructured nature of standard chat conversations. By
constraining the turn talking process and by dividing a discussion
into a set of more focused sub discussions, most of
coherence and coordination problems will be alleviated.
In our opinion, educational settings strongly require such
structuring capabilities.
A central idea of our approach is to distinguish between a
macro level (or process level), and a micro level (or
protocol level).
At the macro level, the process model specifies a
sequence of phase types. Each phase type is characterized
by a name, a description, and an interaction protocol type:
open-floor, moderated open-floor, circular floor passing,
single contribution, unique contributor (all predefined),
and application-specific protocols (defined at the micro
level). Models can be described and modified interactively
by users having the corresponding permissions. A library of
predefined process model templates is also available for reuse
at room definition time. These definitions are stored in a
declarative form (XML files on the server side).
The micro level defines interaction protocol types.
Such a definition may require complex rules specification that
cannot be performed interactively by an average end user.
New protocols are specified off-line with a declarative
XML-based protocol specification language.