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.