According to Grudin [1994] there are eight main challenges that groupware developers might face. Since these were done in -94 and the application development has evolved, it is intresting to see whether these challenges still apply. I'll pick those which I feel are not as important anymore, and try to explain why that is.
1. Disparity in work and benefit. Groupware applications often require additional work from individuals who do not perceive a direct benefit from the use of the application. This might still be important to think of when developing but the effects of it has greatly reduced, due to better internet connections etc. For example, one could work with Googledocs just as he would on an offline text editor, since most groupware parts of the application like saving and showing it to other group members, is done automatically.
2. Critical mass and Prisoner's dilemma. Groupware may not enlist the "critical mass" of users required to be useful, or can fail because it is never to any one individual's advantage to use it. Like I mentioned above, the groupware applications have evolved a lot, and most of them are usually just as useful to use for one person than they are for many, which is why the "critical mass" is so small that it can be reached even with one user.
6. Difficulty of Evaluation. The almost insurmountable obstacles to meaningful, generalizable analysis and evaluation of groupware prevents us from learning from experience. Sure, the evaluation may take longer than normal application and it might be needed to look from different perspective and concentrate on different issues, but I feel that Grudin's explanation of this issue is more of an excuse to "I don't want to learn new techniques and change my viewpoint", and thus I don't see how this has ever been an issue.
I feel that rest of the challenges Grudin presented are still more or less accurate and should be taken into consideration when developing groupware applications.
References:
[Grudin, 1994] Jonathan Grudin, Groupware and social dynamics: eight challenges for developers. Comm. ACM 37, 1 (Jan. 1994), 92-105.
Good points, although I think that the critical mass problem is still pretty much the same. If some group members refuse to use the same application as others, it generally causes problems. Also, many applications that are "mainly groupware" still need a lot of user in order to become useful e.g. Wikipedia or Facebook :)
ReplyDeleteNowadays there is of course also a lot of applications that are groupware "in addition to many other things", but I think that is a bit different. Application with "groupware features" might be success, even if it is not success AS a groupware application.
Sry guys, but could you add your names (writer) into the posts, because we in discussant team have to read and rate them. I would allways like to know who is writing the Blog and this time it's even mandatory.
ReplyDeleteI also disagree with your opinion about the Difficulty of evaluation challenge. The reason of why it has been a challenge is not in the lengthy evaluation process itself but the challenges of collecting data in the field from "real users". When software is still under construction, it can be tried out easily e.g. in the lab and that is enough "evaluation" for single user software. When the software is meant for groups, you need to collect field data from the actual experiences with the software since usually it is impossible to simulate the real world circumstances in the lab. If they did not adopt it, can you explain why they did not use it, and will the bad experiences then result in improvements in the software so that the next field trial will succeed? There are so many contextual factors involved in each case, many of which are not related to the software itself but to the actual processes and ways of working in the group.
ReplyDelete