Heuristic #1
The use of synchronous modes of CMC like text-chat and instant messaging are not requirements but merely suggestions made in Baker, et. al. 2002. All four RVCS do not offer these types of synchronous modes within their environments. Hence, synchronous CMC must be done out of band. However, all four RVCS do require the group member to provide comments as to what edits and changes were made and their rationale upon checking the artifact back into the repository following editing. In support of the heuristic, PVCS-RCS, as previously stated, can be tailored and customized to include synchronous forms of CMC as suggested. Moreover, this form of CMC, though asynchronous, can and has been used as a makeshift discussion forum …show more content…
As shown in the previous two heuristics, awareness is prevalent in all four groupware. Inarguably, awareness is not an issue with respect to this heuristic. In contrast, the latter condition of this heuristic is at best ambiguous, but completely disastrous in the worst case. As stated, the CSCW group member who checks an artifact out of the repository is clearly identified by the RVCS. The problem that occurs when two or more group members must edit the same artifact that is checked out the repository can become potentially worse with respect to this heuristic. The group member who has the artifact checked out of the repository owns a proverbial lock on the artifact or document. If this person is not available for consultation, coordination, and communication, the other group members who need to work the artifact will experience various lengths of delays, resulting in various degrees of frustration. Perhaps the group member owning the lock on the artifact via checkout is home sick, out in the field, or in a meeting. The other members can make unofficial changes to their local copy of the artifact in the interest of progress. However, these changes must later be integrated into the official copy of the artifact that is checked into the repository. This results in double work and is time consuming. As stated, delays can be potentially long. In the event of an extreme emergency, the administrator of the RVCS can override and undo the checkout so that the other users can make changes to the document or artifact. This practice however is dangerous and should only be done as a last resort. Unfortunately for the user who originally owned the lock on the artifact, if this is done, any changes made to the artifact will have to be integrated into the official copy of the artifact in the repository. As described, the result is double work