VMT Rooms Documentation and Specification

Wiki Integration for Topic: Intro

This is the specification for integrating a wiki with Rooms to support the easy sharing of SUMMARIES by users who have worked on the same Topic Problem. Integrating a wiki or some other form of workspace would give students from different rooms (e.g., all the rooms associated with a given topic) a space to summarize their findings and read the summaries from other rooms and comment on them. It is possible that this should be done through the lobby. But it is also possible that this should take place in special ConcertChat Rooms rather than in a wiki.

Description

Gerry wrote: What are the pros and cons for a wiki vs another Concertchat Room?

PROS for Wiki:

MediaWiki? includes discussion pages and history
Wiki allows users to add linked pages, providing unlimited space for many contributions of unlimited length.
Wiki can be formatted differently than ConcertChat whiteboard
With ASCIIMathML? the Wiki can support MathML? (syntax in ConcertChat is inspired by ASCIIMathML?)

PROS for Concertchat whiteboard:

Easy to create and link to within VMT system (from Lobby or a room)
Familiar to VMT users
Consistent interface, well integrated
Supports MathML?
Supports Chat -- which can be used asynchronously to leave messages
Supports the VMT Messaging system -- can invite people to room for synchronous chat
Can be replayed; captures detailed history, easily analyzed
We could customize Concertchat Rooms used as Shared Topic Rooms to have much bigger whiteboards -- which would require more scrolling around.

Michael wrote: As for the Wiki integration, I would argue against using CChat rooms.

: - Usually, the whole point of using a wiki page is to provide a means of asynchronous collaboration. The overhead induced by propagating changes in a synchronous environment like CChat, on the other hand, is associated with a rather large performance penalty, which I feel is completely unwarranted in this scenario. But then again, maybe I'm clear enough on what you want to achieve. If collaboratively editing the wiki page is what you want to focus on, them maybe CChat rooms are the way to go after all, but if it is only for the presentation and referencing of wiki content from within a CChat room, I believe I can offer a better solution:

: - In another CChat-based project I'm currently working on, we use a wiki-like system (CURE from FernUni? Hagen) to organize resources which can then be used in a synchronous collaboration. To this end, CChat has been extended to support multiple tabs, much like Firefox supports multi-tabbed browsing. Usually, one tab in the CChat client displays the whiteboard, while other tabs render simple read-only views of the wiki content or display PDF documents. The content of both HTML pages and PDF files can also be referenced in a chat message.

: - Martin M.: For the commercial PDF viewer you need a licence.

: Maybe we could even remove the "View Topic" button altogether and instead create each room with three pre-defined tabs e.g. "Topic", "Whiteboard" and "Resources". The "Topic" tab would display the existing topic page, while the "Resources" tab would contain a web page linking to relevant resources. A click on one of the links would then open the respective resource page (which could be either HTML or PDF) in a new tab. The participants could then support their actions on the whiteboard by referencing the relevant information (e.g. a theorem in a lecture script) on one of the resource pages. In the same way it would be possible to include read-only views of classic wiki pages containing stundents summaries and comments on the topic by linking them from e.g. the "Topic" page, and also create "Shared Topic Discussion" rooms that do not contain a whiteboard but only a view of the wiki summaries and are dedicated to synchronous discussion on the summarized results.

: (One important limitation to consider lies in the fact that the implementation of the HTML display tab - currently dubbed "WebpageChat?" - does not use a native browser engine like IE or Firefox, but instead relies on the ability of Java text components to display HTML. As a consequence, editing of wiki pages from within the WebpageChat? is not possible.)

Michael wrote: As for linking to rooms from within a web-based wiki, there are quite a few things we have to consider:

: Inserting a picture of the whiteboard content at a given point in time should be no problem, but we will have to think of a way to provide the user with the correct url to the image export JSP. Maybe this could be achieved using a "Post to Wiki" button or context menu action in the CChat client, which would open the browser on a new wiki page, pre-populated with the correct link to the image of the whiteboard at that time. A similar "post to Wiki" action could also be useful for exporting references to the "highlights" or "labels" you mentioned.

Gerry wrote: The wiki/CChat? shared page is a complicated issue.

: Michael's idea about the tabs is appealing. It might be a good solution to the View Topic, which is now awkward. Also possibly a Help tab. We might also put dialogs like Messages or Find Info on a tab.

: Questions for Michael: Can the referencing tool point from the chat into the wiki tab? Why is the wiki read-only? Could an Edit button in there open a window where wiki editing could be done? How important is the overhead of a CChat page vs. a wiki?

Michael wrote:

: The WebpageChat? was originally created as a standalone application for synchronous discussions referencing HTML content, so, yes, references from the chat to both text selections and rectangular areas of embedded images on any HTML page are possible. Moreover, in the multi-tabbed chat application, clicking on chat messages referencing material on a different than the currently active tab automatically activates the correct tab.

: The wiki is read-only for two distinct reasons:

: First, the text field used to render the HTML content is just that: a simple text field with very basic HTML support, not a full-fledged browser capable handling forms or possibly JavaScript?. The possibility of embedding the system's native browser (like for instance in the Eclipse SWT) was abandoned because it is not possible (or at least not technically feasible) to draw on top of COM components using Java2D API, which we need for painting material references. Also, the reference tool needs insight into the document structure of the displayed content.

: Second, the content model of a page originating from a web server is not under the control of CChat, so editing the page at any point after it has been referenced for the first time would introduce versioning issues. For the reference tool to work, it is mandatory that all clients have the exact same version of the page, which means that the url used must be immutable (i.e. pointing to a particular version of the wiki page). This could also turn out prohibitive against putting some of the pages you mentioned ("Messages", "Find Info" ?) into tabs.

: It might be possible to open an "Edit" window with an embedded browser pointing to the wiki edit page. Upon close of this window, cchat would then retrieve from the wiki system the url pointing to this new version of the page and propagate it to the room (or, even better, the wiki system would somehow notify the cchat server about new versions of a particular page, so even external changes are propagated correctly). This, however, requires some integration with the wiki software, i.e. for retrieving the proper urls, notification and the like (I see more web services coming up...)

: As for the overhead induced by synchronous notification, that would depend on the number of clients that have to be notified at any given time. While it is acceptable for small rooms with only a few participants, large "common interest" rooms might suffer considerably. While I cannot quantify this impact, I believe this was one of the reasons why the first, CChat-based version of the lobby was abandoned? Also, keep in mind that the whiteboard has not been designed for long-term storage: I believe you have already experienced the performance issues associated with long whiteboard histories. Imagine the performance hit the server would suffer if, in a short timeframe, a large number of clients attempts to join a "common interest" room which has been undergoing regular changes for a long period of time.

Gerry responded (Jan 29, 2007):

A wikification proposal

: As I understand it, there are two possibilities for workspaces in ConcertChat:

Static pages with limited HTML abilities. These can be referenced from the chat area. All room participants are guaranteed to see the same thing if they have this workspace visible — except for changes they are currently making and except for scrolling the screen.
General web pages, including wiki editing forms and interactive applets. These cannot be referenced from the chat area. They are not shared with other room occupants.

: Suppose we have a tabbed version with tabs for Whiteboard, Topic, Sharing, Editing, Browser, Help, Messages, etc. Some of the workspaces would be enabled for referencing from the Chat: Whiteboard, Topic, Sharing. Other workspaces would not be enabled for referencing — and would not be viewed by other participants: Editing, Browser, Help, Messages, etc.

Topic: Displays the static problem topic for the room
Sharing: Displays the current static version of a wiki page for solutions to the given Topic.
Editing: Opened by a click in the Sharing page. Allows user to edit the wiki page for the given Topic.
Browser: Allows an individual user to browse the Internet.
Help: Allows an individual user to browse the VMT Help system.
Messages: Allows an individual user to read and write his or her messages.

: A room would open with just the Whiteboard and Topic tabs active and with the Whiteboard displayed. A user would have to explicitly open the Sharing window. The Sharing window would only be refreshed when it was made visible (tab selected or a reference to it displayed) or by an explicit refresh request (button push) from the user.

: Pros:

Keeps all work in one window (with multiple tabs).
Maintains a consistent look and feel. The menu system could adapt to the current tabs.
Does not add much communication traffic to the system
Allows chat and referencing to relate to some workspaces.
Provides a general, flexible model for future expansion — e.g., opening a web version of Geometer’s Sketchpad or another math applet in a tab.

Martin M. responded (Jan 30, 2007):

: I've just read the discussion in the wiki. This is a really sophisticated topic, the integration of the synchronous chat with the - usually - asynchronous wiki. My impression is that we should follow the old maxim by van der Rohe: "less is more". Not only for technical reasons, but also to let the whole concept be as simple as possible: here is the portal, you access it in your browser, here you can work browse the materials, individually and asynchronously. There is CChat, where you can meet your team and collaborate in real-time.

: I understand the desire to integrate both worlds:

the materials (provided by the portal) should be accessible as shared artifacts during the collaboration
the results of a collaboration should easily be returned to the portal

: Maybe the metapher of portholes could be a solution: both media - portal and chat - provide portholes to the other side:

In the portal there might be links ("Have a look onto the whiteboard for this room"), and for editing the results in the wiki some functionality to "import" whiteboard content.
In the CChat you might have tabs for displaying the (static) content of portal pages. This could be extended in the future, so external modifications in the WIKI notifies CChat such that the clients automatically reload the latest version (as described by Michael).

: Some useful Wiki links:

Johann's ideas about the Pedagogical role of Wiki in the context of "long-term" engagements of teams

: Central Goal: SBridging Synchronous and Asynchronous Activity over time. Synchronous Collaborative Work might leave things unspecified that people outside the group (e.g mentors, other learners, etc.) might have a difficult time understanding or reacting to.

Examples:

: After Session the first Session:
: As a team, describe your work in Summary Tab or Wiki Page. Structured prompts could include "Describe what you did and what you found out in a way that someone who was not present can understand" or "Describe what you think would be important to remember the next time you meet together to continue the work you started today" or "What things are you still confused about, or wondering about that you will need others to help take a look at?"If possible add snapshots of the whiteboard (as links) to enhance your summary

In-between Sessions:

: Update your Profile

Pre-Activity, Session 2

: Read your teammates profiles
: Read at least one other group's Wiki summary (jigsaw?)
: Read your own team's summary
: Discuss a plan for the session

Added benefit: The Wiki can help increase the number of "engagement/entry points" for a learner who might start browsing topics which have Wiki pages, "Discovery pages" or profiles, and learn about who has contributed to them, last date/time of activity, rooms associated with these pages, etc.

Status

Discussing Functional Specifications

Return to RoomsDev