Applying Web 2.0 Design Principles in theDesign of Cooperative Applications
Niels PinkwartClausthal University of [email protected]
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
TestModif.
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
n
kii
k
ii qq
nb
11
)1(1
Collaborative Filtering in LARGO
Recommended items Non-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
j
ii
p
ii
q
qe
1
1
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”