eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Collaboration is a vague and all-encompassing term that needs to be further defined for the purpose of this discussion. Before proceeding, I would like to replace collaboration with the term document collaboration, which is defined as the ability to present or share documents in real time while simultaneously annotating or marking them up.
Although they are being marketed as such, Web meeting tools are not viable solutions for Web-based document collaboration. These tools were developed to solve a different problem: Web presentation and desktop sharing. Because of their underlying one-to-many architecture, these tools do not promote spontaneity (which is essential for viable collaboration) and aren’t appropriate when they are used for document collaboration.
The only viable solution for participants to collaborate in real time is for all participants to work with the same client application that created the original document. What is required is a many-to-many (that is, clickless collaboration) architecture wherein every participant runs the same document manipulation application on their local workstation, whose input is distributed or replicated to the group.
The collaboration process can be described as a group of people working together to resolve issues and come to agreement on a work product. The group will work independently (that is, asynchronously) to review the product documentation, add their comments, respond to comments of the other members and finally reach a consensus. The collaboration process also requires that the group occasionally come together concurrently (that is, synchronously) so that each member can reinforce their individual points of view, evoke new spontaneous ideas and reach agreement.
Each participant needs to elaborate on their comments, probe the validity of others’ comments and refine all the comments in relation to the group’s overall objective. Effective collaboration requires immediate and spontaneous group interaction to evoke and refine new ideas. Effective collaboration is inhibited by artificial mechanisms that delay and frustrate this interaction. User immediacy and spontaneity decreases exponentially with the number of clicks required to perform an edit.
How Web Meeting Tools Work
How Web meeting tools work
Web meeting tools are built using a one-to-many architecture. A one-to-many architecture is defined as an application running on a single host/presenter platform whose output is visually distributed or replicated to the group. The basic shortcoming of the one-to-many architecture is that, for a participant to make an annotation, they have to request keyboard/mouse control and the host/presenter must transfer control.
This requirement dictates at least two, if not more, awkward transactions, which frustrates and inhibits spontaneous collaboration by adding multiple additional clicks. Some vendors have introduced a workaround to minimize this problem: having participants contend with each other for mouse control (that is, whoever’s mouse clicks first is the one who gets control). But this workaround becomes a fight for mouse control and is very confusing and disorienting.
Most Web meeting tools offer two modes of sharing: desktop/application sharing and document sharing. The host is the initiator of the meeting and is the only participant who can delegate that role to another participant. The presenter is the participant who has keyboard/mouse control at any time and can reassign keyboard/mouse control to another participant.
Desktop sharing, the first mode, enables a designated participant to have keyboard/mouse control of any application on the presenter’s desktop. Application sharing restricts that control to a set of specific applications. Both desktop and application sharing (also called screen sharing) function the same way, so they will be discussed together. When assigned by the presenter, other participants can also manipulate the document by having their client software capture the mouse motion and keyboard entries they make and upload these commands to the server. The server then sends the commands to the workstation where the application actually runs.
When the presenter at the workstation manipulates a document, the updated snapshots of his or her workstation screen are uploaded to a server. The server downloads the screenshots to each of the remote participants. A vendor client viewer is installed on each participant’s workstation to decompress and display. The screen snapshot viewer can be either a browser plug-in or a separate application. As the screenshots are received at the participants’ workstations, their client software updates the view of what appears on the host/presenter’s screen-which sometimes results in an annoying screen flicker.
The second mode of document sharing is designed to avoid the high bandwidth requirements of desktop/application sharing. This scheme uses a virtual printer representation that compresses the complete original document either locally or on a server. The complete document is downloaded to each participant as distinct from desktop/application sharing, which transmits one page at a time. None of these tools cited above support three-dimensional (3D) document collaboration.
All document sharing solutions include a minimal set of annotation tools. Annotations made are replicated to the other participants and applied to an overlay to the virtual representation. Even though each participant’s annotations can be saved in a separate file on the collaboration server for some of these solutions, the comments are not applied to the document.
Many-to-Many Architecture Solution
Many-to-many architecture solution
Just as industry shopping studies revealed that at least 60 percent of online shopping carts were abandoned before checking out, my informal survey of Web meeting users strongly suggests that document collaboration is not a viable use for Web meeting tools because of its clicking awkwardness. What is needed for document collaboration to become viable is similar to Amazon’s one-click patent that overcame buyer confusion and annoyance: less clicks.
The many-to-many architecture enables a participant to run the same document manipulation application on their local workstation, whose input is distributed or replicated to the group. Hence, a many-to-many architecture will provide immediate user feedback because it runs on each user’s local platform. Each participant uses their own mouse, keyboard, cursor and zoom control. Only the application’s menu commands are replicated to the other participants.
A many-to-many architecture enables groups to collaborate on the Web with documents in real time, without the need to click to transfer presenter markup control among participants. Therefore, many-to-many is “clickless collaboration.”
The most obvious criticism of a many-to-many architecture is the contention conflict that would arise. What happens when everyone wants to mark up the document at the same time? This is akin to asking, “What happens if everyone talks at the same time?”
People have been meeting in groups and resolving issues for eons, and it is the software architect’s job to create software that best emulates the human group process as well as software can. A basic requirement for contention avoidance is to get as close to how people do it in a same room environment. A key ingredient for group collaboration is for each person involved to observe the rest of the group’s body language to ascertain the best time to command the group’s attention. So, when someone starts to talk or picks up a marker and walks to the whiteboard, the group waits until that person is finished.
Although software can’t see the group, it can observe when a participant starts to annotate, take that person offline for a quiet period, then allow the other participants to see that that participant has started an edit. This way, they can withhold their edit until he or she finishes. This is similar to the feature in Google chat (that is, gChat) that tells a user that another user is typing so that they can avoid conflict. This simple conflict avoidance protocol can go a long way to solving contention for group collaboration.
Starting from this basic model, more sophisticated contention avoidance protocols that emulate human interaction can also be implemented, which the host/presenter can choose when creating the collaboration event. Only a many-to-many architecture can implement this type of conflict avoidance to not burden participants with extra clicks.
John Mohan is CEO of Rosebud PLM, Inc. He can be reached at John@Rosebudplm.com.