Applying Web 2.0 Design Principles in the Design of Cooperative Applications Niels Pinkwart Clausthal University of Technology

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 2 Talk Outline  Part 1: Social Software systems vs. traditional Groupware - Five dimensions of comparison  Part 2: The LARGO System - Social Software for legal argumentation  Conclusion

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 3 Social Software vs. Groupware Groupware  Software products of CSCW  Exists since 1980’s  Designed to support intentional group processes  Serve users with shared aims or goals  Enable users to collaborate via shared media  Do often not gain much attention in practice Social Software  Not a result of CSCW research  Term coined in 2002  All kinds of systems that support group interaction even when that interaction is offline  Highly successful, millions of users, media attention Similar aims and definitions – where are differences?

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 4 Criterion 1: Application Areas Groupware  Traditionally oriented towards supporting group work and enabling collaborators to interact efficiently and effectively  Note: CSCW 2008 sessions will include Wikis & Wikipedia, Naughty & Nice issues in Social Networking Systems, Gaming, Health Informatics, and Deployments at Home Social Software  Much greater variety of application areas, including areas such as hobbies, leisure, or play  tools are less driven by goals like productivity and efficiency  Work related Social Software exists prominently – e.g., XING, linkedin

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 5 Criterion 2: Control Groupware  System side control about possible user actions is an important factor: groupware tools are often about scaffolding a group collaboration process – this implies a certain intervention in the options of single users in order to coordinate the overall group workflow.  User rights often determined based on role and hierarchy in company  Process control is important factor (e.g., BPMN, IMS-LD) Social Software  Typically very open: they delegate a lot of control to the users and the user community. E.g., Wikipedia entries not centrally reviewed/edited by default. Quality control by social protocols and technology support  Trust often achieved through reputation system (e.g., Ebay)  No central authority that assigns the status based on company organization or some other hierarchy  Little “process control”: Where predefined processes exist at all, these are usually simple

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 6 Criterion 3: Technology Requirements Groupware  Groupware tools are often research products, used to study how state-of-art technologies can be used to support group interactions (e.g., big wall displays, high-end cell phones, …)  Their use thus requires buying (or already owning) the specific hardware Social Software  Typically rather “low tech” client- side and requires not more than Web access and a simple piece of software, often only a browser  JavaScript and XML (e.g., AJAX, DHTML) technical base for successful systems like last.fm, amazon, Ebay  Avoidance of expensive proprietary technology enables masses of users to use the system

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 7 Criterion 4: Success Factors Groupware  Frequently tailored towards smaller but more structured groups and group processes - systems like shared calendars, collaborative text editors, meeting room technologies or shared workspace systems do not need huge user communities  Quality and practical value are largely determined by productivity or functionality gains for group  Measurement of system success is a research question – typically interdisciplinary (socio-technical systems) Social Software  Participation is key success factor for Social Software, since these systems live from the interactions of their (large) user communities  Therefore: extremely easy to use and do not require complicated software installations and configurations  Benefits of the systems are clearly visible for the users and often also available for non-members (e.g., flickr, Wikipedia, amazon)  Usability and immediate benefit motivate the system usage - a Social Software tool without a large user base would not be called successful

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 8 Criterion 5: Algorithms Groupware  CSCW research involves wide variety of algorithms – e.g., methods for controlling concurrent text editing, algorithms for calculating and displaying awareness information, etc. Social Software  The one by far most prominent and widely used type of algorithm is collaborative filtering  Through their actions in the system (buying or looking at books at amazon.com, entering profiles in online dating services or tagging images on flickr), users get associated to system artifacts in various ways  System exploits this to recommend artifacts to other users  Analyzing user actions to generate the added value of the system is algorithmic core of Social Software – here, collaborative recommendations play key role

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 9 Social Software vs. Groupware  Summary result 1: Groupware tools and Social Software applications are not the same – they do have differences  Most prominent common point is aim: facilitating group interactions and communications  Most important differences: technology requirements, degrees of user control and application areas  Summary result 2: These differences are neither strictly defined through clear-cut rules nor overwhelming or a necessity  Summary result 3: Fields tend to merge - CSCW researchers can learn from Social Software success factors to improve the level of collaboration and the practical impact of the systems they design

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 10 Example: An ITS for legal argumentation  LARGO (Legal ARgument Graph Observer)  System design approach: Engage student groups in analyzing, visualizing & reflecting about examples of expert Socratic reasoning  Not driven primarily by the idea of developing “Social Software”  To the contrary, LARGO is designed for rather small groups where users have to work through a well-specified task without having a great degree of control  Also: the success of the system is finally subject to empirical studies of learning and not a question of widespread usage  But: Application of social software principles  Markup, “tagging” resources, recommending objects created by peers  Collaborative filtering employed as tool to generate better feedback in Intelligent Tutoring System

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 11 US Supreme Court Oral Arguments  Important part of decision process  Attorneys propose a decision rule (“test”) to determine how to decide a case  Justices challenge these tests, often by posing hypothetical scenarios  Educationally valuable (but difficult) material for students

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 12 An Example Case  Example: Lynch v. Donnelly 465 U.S. 668 (1984)  Facts: The city of Pawtucket annually erected a Christmas display located in the city's shopping district. The display included such objects as a Santa Claus house, a Christmas tree, a banner reading "Seasons Greetings," and a nativity scene.  Question: Did this violate the constitutional separation of Church and State?

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 13 MR. DE LUCA: With the possible exception of the cross, the nativity scene is one of the most powerful religious symbols in this country, and most certainly one of the most powerful Christian religious symbols in this country. ( … ) Pawtucket's purchase, the maintenance, and the erection of the fundamental Christian symbol involves government in religion to a profound and substantial degree. ( … ) JUSTICE: Now, if the city did not own the cr è che itself, so that everything that was contributed to the display, including the cr è che, were privately owned, it wouldn't violate the First Amendment, the fact that it was right next door to the City Hall, would it? MR. DE LUCA: I think that in understanding that the city owns all of the symbols and all of the artifacts that are contained in this display, and assuming that the cr è che were purchased and paid for privately without any other explanation that it is private, then I think it would still violate the establishment clause for the First Amendment, because there is no indication to anyone looking at that that the display or the cr è che is not part of the broader display which is put up and sponsored by the city. ( … ) JUSTICE: Would you regard the prayer that I spoke of to your friend in the House or the Senate or in any state legislature as purely symbolic, or is it a matter of substance? Example: Tests and Hypotheticals Test Hypo Test Modif. Hypo

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 14 An Example LARGO Diagram

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 15 Intelligent Support  How help students  analyze the argument transcript?  navigate the interlinked information spaces?  Automated diagram analysis allow for:  Graph structure inspection  general argumentation principles, e.g. “there should be at least one test”  Checks of links between graph and transcript  case specific “important passages”  Not subject of this talk

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 16 Content Analysis?

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 17 Feedback in LARGO Idea:  Make use of peer students working on the same task  Have students rate peer solutions as part of their working with the system

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 18 Feedback in LARGO  Exploit that the system knows what part of the graph refers to certain important parts of text… Student A Student B Student C

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 19 Feedback in LARGO  … and use these relations to generate the dialogs Student A Student B Student C

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 20 Principle for quality rating q: weighted average of base rating and evaluation rating (0=poor, 1=excellent)  Base rating  Based on how student rates other solutions  Serves as initial score heuristic, immediately available  Assumption: having good solution correlates to recognizing good solutions Collaborative Filtering in LARGO Recommended itemsNon-recommended items

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 21  Evaluation rating  Based on recommendations a student’s answer receives (or not), and by whom  Develops over time  Takes peer opinions into account  Assumption: measures actual quality Collaborative Filtering in LARGO Actual recommenders All possible recommenders

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 22 Conclusion  Social Software and traditional Groupware  Both terms used for systems that facilitate social interaction  Clear borderline cannot be drawn  Differences exist in terms of application areas, degrees of user control, technology requirements, success factors and algorithms  But: differences are not necessity – success factors of Social Software can be used to inform the system design of CSCW systems  Example: The LARGO system  Groupware for legal argumentation training  Cooperative visualization of arguments  Makes use of Social Software design paradigm “collaborative filtering”