The article outlined the early origins of groupware and specifically described eight problem areas, suggests solutions to these problems and examines groupware successes such as email. The eight problem areas examined were; the disparity between who does the work and who gets the benefit, critical mass and prisoner’s dilemma problems, social, political and motivational factor, exception handling in workgroups, designing for infrequently used features, the underestimated difficulty of evaluating groupware, the breakdown of intuitive decision-making and managing acceptance: a new challenge for product developers.
It is interesting to see that many of these problem areas are still relevant in the context of today’s world, even as groupware services have become ubiquitous. Thinking of the enterprise level, it is still true today that the end user does not always have a say in the final design of a groupware product, this may lead to situations where people have to conform to a certain requirement to make a system work. A good example is the virtual Kanban system mentioned in Matthiesen et al.’s 2014 paper on collaborative work. The designers of the system did not account for who would end up using it in the context of teamwork.
Additionally, for a groupware system to be successful, it requires a critical mass, this was most obvious in our class. Some students had to sign up and download slack for the slack channel for cscw to work effectively. Social and political motivational factors also seem an important criterion in the design of modern groupware.
In my opinion, the exception handling in workgroups, and designing for infrequently used features have been problems that modern designers have been actively working to solve. The use of various user research methodologies as well as the success of groupware integration by google (docs, sheets, calendar, etc.) confirm this.
As groupware grows with technology and innovation, evaluating them becomes harder, which is inline with the paper. This is especially true when evaluating crowdsourcing and citizen science-based software.
The design and evaluation of groupware has been iteratively changing since the time of publication of this article, though many of the problem areas still remain, while some seem to be addressed. With an ever-connected world, it would be interesting to integrate more factors (such as the effects of culture, demographics, etc.) that affect the design of groupware.