applying web 2.0 design principles in the design of cooperative applications

22
Applying Web 2.0 Design Principles in the Design of Cooperative Applications Niels Pinkwart Clausthal University of Technology [email protected]

Upload: esme

Post on 19-Jan-2016

44 views

Category:

Documents


0 download

DESCRIPTION

Applying Web 2.0 Design Principles in the Design of Cooperative Applications. Niels Pinkwart Clausthal University of Technology [email protected]. Talk Outline. Part 1: Social Software systems vs. traditional Groupware - Five dimensions of comparison - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

Applying Web 2.0 Design Principles in theDesign of Cooperative Applications

Niels PinkwartClausthal University of [email protected]

Page 2: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 3: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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?

Page 4: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 5: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 6: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 7: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 8: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 9: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 10: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 11: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 12: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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?

Page 13: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 14: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

N. Pinkwart Applying Web 2.0 Design Principles in the Design of Cooperative Applications 14

An Example LARGO Diagram

Page 15: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 16: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Content Analysis?

Page 17: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 18: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 19: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 20: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 21: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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

Page 22: Applying Web 2.0 Design Principles in the Design of Cooperative Applications

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”