1 / 22

Applying Web 2.0 Design Principles in the Design of Cooperative Applications

Applying Web 2.0 Design Principles in the Design of Cooperative Applications. Niels Pinkwart Clausthal University of Technology niels.pinkwart@tu-clausthal.de. Talk Outline. Part 1: Social Software systems vs. traditional Groupware - Five dimensions of comparison

esme
Télécharger la présentation

Applying Web 2.0 Design Principles in the Design of Cooperative Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Applying Web 2.0 Design Principles in theDesign of Cooperative Applications Niels PinkwartClausthal University of Technologyniels.pinkwart@tu-clausthal.de

  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

  3. 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 Social Software vs. Groupware Similar aims and definitions – where are differences?

  4. 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 Criterion 1: Application Areas

  5. 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 Criterion 2: Control

  6. 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 Criterion 3: Technology Requirements

  7. 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 Criterion 4: Success Factors

  8. 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 Criterion 5: Algorithms

  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

  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

  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

  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?

  13. Example: Tests and Hypotheticals Test Hypo TestModif. Hypo

  14. An Example LARGO Diagram

  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

  16. Content Analysis?

  17. Idea: Make use of peer students working on the same task Have students rate peer solutions as part of their working with the system Feedback in LARGO

  18. Feedback in LARGO • Exploit that the system knows what part of the graph refers to certain important parts of text… Student A Student C Student B

  19. Feedback in LARGO • … and use these relations to generate the dialogs Student A Student C Student B

  20. Collaborative Filtering in LARGO 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 Recommended items Non-recommended items

  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

  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”

More Related