ZIFF-Hinweis

Mirjam Fritsch, ZIFF, November 1997

"Virtual seminar" – just a trendy word? Is it scary or does it make you wonder? Let’s for a start forget about the tiny little word "virtual" (anyhow, nobody really seems to know what it means) and concentrate on the rest: seminar. To me seminar is a situation in which a teacher meets several students. The teacher teaches and encourages the students not only to passively consume the contents but to actively deal with them, e.g. through discussion. The teacher is also available for answering upcoming questions and might hand them on to the other participants. In the following the students are asked to apply the new won knowledge, either by themselves or in small groups. Reports on the outcome of the application will be presented and discussed. The seminar might close with a summarizing final discussion and maybe with some sort of test. The elements of communication necessary to carry out a seminar can be described as:

1. Presentation of a common basis of knowledge: In the beginning of a seminar this is the teachers task: introduce the topics of the seminar, present or repeat the main pieces of information, name sources for further literature study. Later during the course of the seminar also the students will be required to contribute to the enlargement of the common basis of knowledge by reporting on the outcome of their application i.e. on difficulties they encountered as well as on the findings they made.
2. Discussion: The discussion takes place among all of the participants, teacher as well as students. Questions are posed and answered, opinions stated more precisely, pieces of information evaluated more deeply. The topics to discuss could regard the common basis of knowledge, the literature, the applications reported on or the seminar in whole. The participants can increase their knowledge by posing questions and getting answers; but they can also learn by just observing the contributions of the others and the reactions they give rise to ("witness learning").
3. Application (eventually as teamwork): The students are required to apply the new knowledge they have acquired, to practice it. To do so, they need access to the common basis of information and eventually a more personal tutoring by the teacher to handle questions or problems related to their specific task. If the application is performed as teamwork the members of each team must be able to communicate with each other in order to distribute the tasks, exchange their findings and organize the presentation of their team’s outcome.

To give a virtual seminar means that these three elements of communication are made available to the participants, without the need of the participants being physically in the same place. The internet has enabled this since many years in a variety of ways: The presentation of the common basis of knowledge can be achieved through HTML-pages in the World Wide Web. Chat-programs or Newsgroups can be used for discussion. The more private communication and collaboration can be held via eMail and file-attachment or ftp. Literature can be provided as sources or directly as text in the WWW, or as links to the download of the texts. Those who participated in such a virtual seminar might have liked the "technology-mix" and been fascinated by the "new" possibilities; probably all in all they were satisfied. Yes, a virtual seminar can be held this way, but: it is possible to offer the same features in a more comfortable setting.

Ideally one tool would be needed, that combines the three elements of communication and by doing so makes the interaction during a net-based seminar easier. Unlikely the traditional way, where information is presented via www in the HTML format in one place and the reaction is sent via eMail or posted in a Newsgroup - another place, with such a system the participants could gather information and react to it on the spot, without the need to switch to another interface. They can take their time when writing a reaction, but once sent, their contribution is still in the context where it originated, visible for everybody. In this way a contribution holds the function of stimulating further reactions. Simultaneity or "real-time" is not a condition for this style of discussion, but when felt to be needed it should be achievable through conferencing-components, be it chat-programs, video- or audioconferences. Synchronous communication though should be moderated, in order to avoid the overlay of several discussion topics, which can be rather confusing. Moderating a discussion is hard enough even when the participants are phisically together in the same room and although one can make use of a look or a gesture to have influence on who is to talk and who is to be silent. In a virtual chat room these resources (unluckily?) are not available.

Such an ideal tool should not only feature the above described communication possibilities, it should also offer several group management functions like registration and membership management, overview of the attendance of the participants, reminders of meeting dates etc.

The several requirements that an ideal tool should meet and the functions it should be able to perform are stated in detail in the following section. In the last section an analysis of the three tools is presented and their functionality compared.

A communication tool is adequate for giving a virtual seminar if it easily allows sending, receiving and organizing the seminar contributions. The tool must though offer certain functions and these functions must be executable in a comfortable way. What exactly comfortable means can differ considerably, according to whom is judging. The participant’s needs in terms of comfort regard the already working system and include aspects of navigation in and usage of the system. The organizers of the seminar who will also need to set up the system in the first place and maintain it during the seminar, will have further requirements, as there could be the easy installation on the server, the possibility to have upcoming questions answered quickly and correctly, the possibility of organizing the level of privacy of the seminar i.e. managing the access rights, the possibility of changing the looks of the user interface freely. In short: it is important that the whole system is easy to handle. Since the success of the seminar will largely depend on how satisfied the participants were, their requirements will be supported by the organizers as well.

Any system that wants to be considered as comfortable, i.e. user-friendly, must meet certain requirements. These general requirements and their application to the tool in question are:

1. Control of the system: The user must be in control of the actions the system performs. The system should allow the user to decide which actions should be performed and when. The user should decide if he wants to read a contribution, which one and when to read it. The user should also be able to control how to navigate through the contributions and how the system displays their structure.
2. Self-explainable system: The functions offered must be easily understood. It should be avoided that the names of functions provided are confusing. The user should have an idea of what the function does without needing to try it.
3. Conformity with expectations: The system should perform like the user expects it to. When the user gives a command exactly that command should be performed, no more, no less; e.g. when a user deletes a contribution it should not only be deleted, it should also disappear from the list of contributions on the screen.
4. Clarity: The system should not be confusing, it should help the user to have a good overview and not to loose track. A well-structured user-interface helps to make the system clear.
5. Error tolerance: If the user makes an error the system should allow a correction. There should be a possibility to "undo" the last few commands. Wrong inputs should be recognized as such and avoided.
6. High working speed: This might be a very important feature to many users. But since working speed depends on many factors that are out of control of the system (server performance, quality of telephone connection) it should not be rated too highly. Out of two tools with otherwise the same features the faster one should be preferred.
7. Automatic install and uninstall: The installation of the system from the first setup to the first application should possibly be easy. Also the system should be easy to uninstall when not needed any more. For system-administrators or for the organizers of a seminar this requirement can be very important. The participants of a seminar are also concerned, as far as the usage of the tool requires the installation of further helper applications (e.g. acrobat reader, Word viewer or similar).
8. Save resources: The System should not use too many resources in terms of RAM and hard disk memory.

In case some of the tools do not fulfill one or more of the above requirements, this is stated in the last section, as far as it is possible to objectively tell. This list is mainly meant to be of help, when inspecting communication tools. Since comfort or user-friendliness are based on personal feeling a look at the test-pages of the tools is strongly recommended. There one can rather quickly find out, if a tool to oneself is comfortable or not.

An internet-based communication tool useable for giving a virtual seminar is expected to perform the following functions:

1. Organization of contributions: A multilevel structure of contributions should be provided. Elements on the same level should be sorted by date. Reactions to a contribution should be located one level below. It should be allowed to insert new contributions on any level. Moving contributions posted in the wrong place should be allowed. To clarify the structure of the contributions a system could provide frames, but it should not require them.
2. Posting contributions: Posing a contribution should be possible from within the system, without detours via separate email, chat, ftp-programs. The system should accept contributions in many different formats as necessary (see below). A preview function and a spell-check feature should be available for text-messages. It should be possible to allow the author of a text-message to edit his message after posting it. It should be possible to disable the function of sending a contribution anonymously, if provided.
3. Formats of contributions (text, HTML, graphic, any file): The format of a contribution should be definable as freely as possible. In text-messages it should be possible to have line breaks inserted, URLs and mail-addresses activated automatically. It should be possible to send in contributions written in HTML, the only really platform independent format. The possibility of uploading files of any format should be provided.
4. Reading / displaying of contributions: The format of a contribution should be easily recognizable for the user. The actual text-messages should be emphasized and easily recognized as such. The author of the message should be mentioned. Whether only one message or all messages of a thread are displayed should be optional. A search function should be provided that helps to retrieve contributions according to their author or contents.
5. New message tracking: Contributions that are new to a single participants should be marked as such. It is of little use if the system still marks a contribution as "new" even after the participant has acknowledged it. When a participant often visits the system, he should be able to quickly see, which contributions are new to him.
6. Email Notification: The participant should have the option to be automatically notified via email if new contributions or replies to his contributions are posted. He should be allowed to choose in which cases the notification should happen: anytime a new contribution is posted, only when a reply to one of his contributions is posted or when a new contribution is posted to a certain thread.
7. Real-time online communication: The system should provide the possibility of synchronous communication online, where the participants connect simultaneously via chat, audio or video conference.
8. Membership: The system should allow the organizers to set different levels of privacy for certain areas of the conference, e.g. main page open to everybody, read access for some people, write access for the participants in the main conference setting, and in some areas access for the organizers only (when preparing a page). The organizers should be allowed to choose, whether participants are entitled to "invite" external people to the seminar, i.e. to create new memberships themselves, or whether this is a function reserved for the organizers. It should be possible, that registered users (members) enter the seminar through a cookie-identification if they wish, so that they do not have to type their password every time they check in.
9. Design options / System administration: It should be possible to adapt the user interface according to the seminar needs e.g. have different buttons, different graphics or a different layout. In case the users do not like the layout of the user interface it should be changeable. Editing of help- or welcome-messages should also be editable. International settings of a seminar might require multiple language versions of the user interface. The installation of the system should be easy to handle. Installation wizards can help. The administration of the running system should also be easy. The possibility of the remote administration of the system might be necessary for those organizers, forced to travel a lot. A tool should be provided to archive old messages. The system should provide statistical information on the seminar activity, such as frequency and/or duration of the participant’s visits. The system should be able to host more than one seminar/conference at a time. For each seminar it must be possible to set levels of privacy and fulfill other administration tasks separately.
10. Price / installation: The system should be freeware or cost less than US$ 100. It must be possible to install the system on the local server, i.e. the system and the server-software must be able to cooperate.

(http://union.ncsa.uiuc.edu/HyperNews/get/hypernews.html)

prerequisite: Java-enabled web browser

1. Organization of contributions: The contributions are organized in a tree-structure. If desired the messages can be numbered, on each level starting with 1 and sorted by date. Numbering the messages helps to identify a cross-reference to a certain message. After the third level the numbering function is activated only of there are more than two messages in the level. HyperNews features comfortable frames-support, but even without frames the structure of the messages is clear. When using frames the advantage is that one can read a message and at the same time see where in the structure it is situated. There are two views-options one can choose from:

• Inline: This is to specify if the contents of contributions in the sublevels are to be displayed in the actual page. The options are: 0: no contents are displayed, the contributions on the following sublevels are only referenced. 1: The contents of contributions on the next sublevel are displayed. Contributions on further sublevels are referenced. All: All contents of contributions in the following sublevels (thread) are displayed. In this last case it is hard to understand on which sublevel a contribution actually lies because the structure disappears and all messages are presented one after the other, in line. When this option is set to All, the option "outline" automatically is set to All as well.
• Outline: This is to specify the number of sublevels shown. The options are: 1: only the next sublevel will be shown or referenced. In case there are more sublevels the number of contributions in the following levels is indicated. 2 (3): The messages of the next two (three) sublevels are shown or referenced. All: All messages are shown or referenced.
• Combinations are possible, e.g. outline=1 inline=1 means that the messages of the next sublevel are shown. Next to these messages contributions on the next further sublevel are referenced only.

1. Posting contributions: Below the message one is reading there is a button "add message" which allows the posting of an answer to this message on the next sublevel. If a participant wants to post a new message on the same level, it is necessary to go on the level above and press the "add message" button there. Anytime this button is clicked the edit-message-page appears (when frames are not active a jump to this page is performed, when frames are active a new Browser is opened with this page). A message can have five formats (se below). System-setup permitting a message can be posted anonymously. Once the text is completed there is the "preview message" button to click, the message is then displayed just the way it will appear after being posted. If the preview is satisfactory the message can be submitted by clicking on "send message", if not the "back" button allows to continue editing the message. Once the message has been sent the system offers a button to directly return to the page where the message was initiated (without frames) or one can get back to the original page by closing the additional browser (with frames) and performing a reload on the original page. All in all writing messages is quite pleasant with HyperNews. There is no spell-checking feature in HyperNews. Once a message has been posted it is not possible to edit it. Each author of a message is allowed to move or delete own messages, including all the messages in the related sublevels.
2. Formats of contributions: Text messages can have four different formats, one of them being HTML. All of them recognize URLs and transform them into active links. The fifth format is an URL on its own. Uploading any files is not possible for the participants.
3. Reading / displaying of contributions: After getting used to the system and provided that reloads are performed after posting a message, one can simultaneously read a message and understand on which level it lies.
4. New message tracking: Understanding which messages are new to oneself is hard: Messages can have three different bitmaps positioned after their reference, all reading "new" in different colors. The newest messages, the ones not older than one week, have a red "new" on yellow ground. The older ones have a black writing on yellow ground, the even older ones only have the black "new" after them. So which "new" bitmap appears is dependent on how old a message is, and not on the question has it been read or not. This feature is rather confusing.
5. Email Notification: Members can "subscribe" any message and by doing so they are notified via email whenever a new message is added to any sublevel of the subscribed message. The email contains the URL of the new message so one can directly go there. If the notification becomes tiresome members can unsubscribe the messages. While editing a new message members can choose to be notified as soon as replies to this message will be posted.
6. Real-time online communication: HyperNews doesn’t offer any kind of synchronous communication. Other internet resources must be used.
7. Membership: Each member can invite new people to become members, if the system is setup this way, which is optional. Each member can but is not required to supply personal information like homepage, postal address, phone number, nickname. Other members can view this information.
8. System administration / Design options: Once HyperNews is installed on the own server there are many possibilities of customizing it regarding the level of privacy, the administration etc. The user interface can be changed too (Colors, Fonts, Buttons). If HyperNews is used on the HyperNews server, these possibilities are missing.
9. Price / installation: HyperNews is freeware and can either be used on the HyperNews server or installed locally.

http://bscw.gmd.de/

prerequisite: Java-enabled web browser

1. Organization of contributions: The contributions are organized in a tree-structure. Similar to the DOS file system there are folders and files. New empty folders can be created on any level. Any folder can contain other folders and contributions. The contributions are not numbered, inside a folder they are sorted by date. The contributions can have various formats, their format is shown through an icon placed before the reference to the contribution. For each contribution a protocol is available that gives information on whom wrote the contribution, who read it and when, wo downloaded it. BSCW doesn’t use frames at all, which is why it works on almost any browser. The user interface is well structured and context sensitive (only those buttons appear that can be used). The buttons are not exactly self-explaining, in the beginning much trying out is needed to understand what certain buttons do. But with a little training the system works just fine. A nice feature is the personal waste bin: contributions can be deleted from the personal context i.e. moved to the bin, but are still visible for the other participants. And from the bin they can be restored to their original place. Contributions can also be copied to the personal bag which allows to create an archive and download it to disk. The BSCW-System is not exactly fast. But speed can be increased by saving all image-files locally or by installing the whole system on a local server. BSCW is a complex system that holds many helpful features. The time invested in learning how to use it is not wasted.
2. Posting contributions: There are two kinds of text messages: replies to existing contributions and new contributions. New contributions can be added in any folder by clicking on the "add message" button. While reading a message there is a list of available buttons above and below the message, one of them is "reply" and enable the user to answer to the message. Composing a text-message happens on a separate HTML page; there is no preview function and no spell check. Except for text messages it is possible to upload any kind of file as a contribution, e.g. a word document, an image file, HTML files. To these non-text contributions any member can attach a note, similar to the replies above. BSCW can also control the versioning of a document and gives information on whom is working on it at the moment.
3. Formats of contributions: BSCW allows multiple formats for the contributions: text messages, GIF-files, URLs, HTML-files. URLs are recognized and activated when written in text messages. Any other kind of file can be uploaded as a contribution. BSCW knows many mime-types, e.g. when a word document is uploaded it receives a link, and if this link is followed either word or the word-viewer are started and display the file. Similarly this works with many other files (Adobe Acrobat Reader, Excel, RTF-files, ...) provided that BSCW knows the mime-type and that the respective helper application or plug-in is present. HTML-contributions are treated this way too. It is also possible to add new mime-types to BSCW, if needed.
4. Reading / displaying of contributions: In the top part of the screen BSCW displays a hypertext path, which shows how one got to the actual message displayed. This path is helpful for navigation and for recognizing on which level one actually is (quite similar to yahoo when searching by topics). Below the contribution on the actual level, each contribution on the next sublevel is referenced. To the left of all references to contributions there are small arrows: when they point to the right only the link to the contribution shows. When they point down all the sublevels following this contribution are displayed and indented. Navigation is easy after understanding how the system works.
5. New message tracking: Messages can have different attributes: new ones receive a bitmap saying "new", messages read by somebody have a magnifying glass with an R in it, etc. There is a button called "catch up" on each page: clicking it means that all the information about what happened on this level and on the following sublevels has been acknowledged. Subsequently the protocol information and the "new" bitmaps disappear. When revisiting the site only those messages are marked as new ones that were added since the last "catch up". A bitmap with a hand means that something happened in the thread; clicking on it all the new protocol information is displayed. Tracking new messages is comfortable with this system.
6. Email Notification: The information that new articles have been added is given through the catch-up mechanism. Email notification is not provided. But BSCW allows to send an email to one or all members of a workspace and inform them manually that changes have occurred.
7. Real-time online communication: Included in BSCW there is a meeting management system that allows members to setup a meeting via different media (Internet phone, CUSeeMe, Chat): BSCW can ask each member for confirmation, remind them that a meeting is scheduled and connect them at the set time.
8. Membership: Each member can invite new people to become members, if the relative option is set to true. Each member has the opportunity to supply information about himself such as a nickname, image, homepage, postal address, phone numbers, email address etc. This information is available for all other members.
9. System administration / Design options: BSCW can be used on the BSCW server in Germany or installed on any other server. If installed locally there are many design and administration options regarding security, level of privacy, administration and user interface (fonts, colors, buttons). If the BSCW server is used the options for the level of privacy can be set and the user interface can be changed by editing the downloadable images used on the interface and sending them to all members, who then have to set their option of loading the images from disk to true.
10. Price / installation: BSCW is freeware if it is not used commercially. It can be used on the BSCW server or installed on the own server.

1. Organization of contributions: The contributions are organized in a tree structure, the top level being the conference level. New messages are added to the first level of a conference. Messages can be added to lower levels only as replies. In case the title of such a reply is not edited manually, it is exactly the same as the title of the original message, the one that is being answered. This is confusing, it would be better to add the common "Re:" in front of the new title. The number of levels doesn’t seem to be restricted. The messages are not numbered, they are sorted by date inside a level. Text messages can be posted in HTML format. To each contribution a file can be attached (upload is possible). The author has to specify which kind of file it is, if he does so, an icon is placed before the reference to this file tat permits the other participants to identify the kind of file it is. A description can be attached to the filename. A contribution with attachment has an italic title (it took a while to find this out). WebBoard offers frames, but the navigation is not easier with than without: In the left frame the conference tree appears, in the right frame there is either a single contribution or all contributions of a thread with content, depending on how the options were set. It is not possible to limit the number of sublevels out of which the messages should be displayed. The messages in the right frame are displayed one after the other, in their order. But it is hard to recognize where in the tree a single message is located. The navigation with the frames is uncomfortable, also because the two frames are not connected, i.e. when unfolding a thread by clicking on the + sign in the left frame, the right frame doesn’t change to display the message(s) of that thread. Clicking on a message reference in the left half one would expect this message to appear in the right half: what happen is that the frames disappear altogether and only that message (and the following ones in its thread) is shown. Quite confusing. Similarly actions in the right half do not affect the left half of the screen. The usage without frames is somewhat more comfortable. But still it is hard to recognize the structure of the messages. The buttons have strange names too. Imagine you have a message on the right side and want to upload a file, there is a button saying "post", but it’s the wrong one; choose reply, do not write any text and check the box "attachment", that’s what you have to do. Again: confusing. Editing messages and deleting them is allowed to the author of a message only. WebBoard gives a good impression in the beginning. But the longer you work with it the more functions are missing or comfort is reduced.
2. Posting contributions: There are two kinds of text messages: New messages are added always on the top level of a conference by clicking on post. While reading a message a list of tiny blue underlined commands are displayed on top. Clicking on "reply" a message is added on the first sublevel of the message where the button "reply" was clicked. Text messages can be previewed and there is an optional spell check (for English only). Except for the text messages any file con be uploaded as an attachment to a text message.
3. Formats of contributions: WebBoard expects that messages are in plain text. Most HTML tags are recognized, URLs are transformed to active links. Images can be uploaded as attachments, as well as any other file. Uploaded files can be downloaded to disk by all members. Viewers don’t start automatically after the download.
4. Reading / displaying of contributions: As stated in point 1 it is hard to read the messages and at the same time understand where in the tree structure they lie.
5. New message tracking: In WebBoard there is a button called "mark all read": after clicking it the user is prompted to choose one or more conferences, the messages of the conference chosen will then all be marked as read. It is not possible to catch up only parts of a conference or single messages. Having marked all messages as read and revisiting webBoard later, a welcome message appears displaying links to all new messages, if there have been any in between. Whether these new messages are replies or messages on the top level, can not be told from the list. Conferences with new messages in them receive a "new" icon, but the single new message is not marked as new.
6. Email Notification: The notification about new messages via email is possible for conferences as a whole, but not for certain threads or single messages. Email can be sent to the author of a message.
7. Real-time online communication: WebBoard has an integrated chat component, which requires a Java enabled browser and is easy to use. One can "whisper" a message to an active member of a chat-group. Short messages can be typed in on the same screen, longer ones can be composed as well, with options regarding font size, style and color. The refresh rate can be set individually. The newest messages are on top of the list.
8. Membership: Membership can be granted by the system itself or by the organizers. Information about members includes name, homepage, email address, country, hobbies and can be viewed by the other members.
9. System administration / Design options: If WebBoard is installed on the own server there are many options regarding security and administration issues, level of privacy and user interface (fonts, colors, buttons). Unluckily the structure of the pages seems unchangeable.
10. Price / installation: The smallest version of WebBoard costs US$ 59.95 and is restricted to two boards with a maximum of 10 conferences each. WebBoard needs to be installed on the own server.

+ available and good

o available but not good

- not available

* WebBoard has a chat component; BSCW has meetings in the form of chat, audio- and videoconferences.