740 likes | 854 Views
Configuration, Customisation and Appropriation: Integrating Technology and Practice in the Placeless Documents System. Paul Dourish Xerox Palo Alto Research Center. outline. customisation and appropriation placeless documents - motivation placeless documents - design
E N D
Configuration, Customisation and Appropriation:Integrating Technology and Practice in the Placeless Documents System Paul Dourish Xerox Palo Alto Research Center UC Berkeley, 29/2/2000
outline • customisation and appropriation • placeless documents - motivation • placeless documents - design • case study #1: shared document management • case study #2: workflow infrastructure service • revisiting assumptions • appropriable technologies UC Berkeley, 29/2/2000
customisation • customisation in HCI research • adapting systems to individual needs • configuring for different situations • customisation in CSCW research • adapting to needs of groups • individual needs and group needs • customisation as a collaborative phenomenon • MacLean et al., “tailoring culture” • Mackay, “patterns of sharing” UC Berkeley, 29/2/2000
appropriation • customisation as constitutive of collaboration • evolving collaborative working practices • incorporation of technologies, artifacts and settings • reconfiguration and repurposing • appropriation • incorporating technology into working practice • flexibility in mapping technology onto needs • research question • what technical features support appropriation? UC Berkeley, 29/2/2000
importance • problems of appropriation are unavoidable • people work in different ways & different settings • one size does not fit all • practical • building successful systems • learning lessons from use • applying them in different settings (shrink wrap) • theoretical • relating work practice studies to system design UC Berkeley, 29/2/2000
placeless documents • infrastructure for information management • personal and workgroup document collections • integration • multiple users • multiple information domains • multiple tasks and application needs • designing to support appropriation • accommodating different needs • integration with existing technologies and practices • supporting evolving use UC Berkeley, 29/2/2000
hierarchies • diversity of use implies diversity of structure • no single organisation will suit all needs • hierarchies dominate information organisation • files and directories; email folders; etc. • often a poor match to information needs • where to file it? where to find it? • different needs, people and applications • re-addressing the performance trade-off UC Berkeley, 29/2/2000
properties • organise documents according to properties • document metadata tags • “things you already know about your documents” • arbitrary name/value pairs • names are arbitrary structured strings • values are arbitrary Java objects • no predefined structure UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Status = in progress UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Status = in progress Backup = true UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Status = in progress Backup = true Forum = ucb UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Format = Powerpoint Status = in progress Backup = true Forum = ucb UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Topic = placeless Author = dourish Format = Powerpoint Status = in progress Backup = true Forum = ucb UC Berkeley, 29/2/2000
document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Topic = placeless Author = dourish Format = Powerpoint Status = in progress Backup = true Forum = ucb UC Berkeley, 29/2/2000
properties for appropriation • properties are unordered & composable • coordination between different applications • no “path” constraintsmultiple tasks & perspectives • properties are arbitrary & extensible • no prior commitment to styles of use • new tasks can always be accommodated evolution UC Berkeley, 29/2/2000
active properties • control not just organisation, but also behaviour • this is important back it up • this is work in progress track changes • this is work with Keith let him write too • active properties also incorporate runnable code • in-line: intercept and augment standard operations • delegates: extend document behaviour • added individually just like static properties • per-document customisation of functionality UC Berkeley, 29/2/2000
active properties • control not just organisation, but also behaviour • this is important back it up • this is work in progress track changes • this is work with Keith let him write too • active properties also incorporate runnable code • in-line: intercept and augment standard operations • delegates: extend document behaviour • added individually just like static properties • per-document customisation of functionality UC Berkeley, 29/2/2000
active properties • control not just organisation, but also behaviour • this is important back it up • this is work in progress track changes • this is work with Keith let him write too • active properties also incorporate runnable code • in-line: intercept and augment standard operations • delegates: extend document behaviour • added individually just like static properties • per-document customisation of functionality UC Berkeley, 29/2/2000
active properties • control not just organisation, but also behaviour • this is important back it up • this is work in progress track changes • this is work with Keith let him write too • active properties also incorporate runnable code • in-line: intercept and augment standard operations • delegates: extend document behaviour • added individually just like static properties • per-document customisation of functionality UC Berkeley, 29/2/2000
personal/universal properties • incorporate individual working styles and needs • properties have different relevances to people • I think, “this is the order for my new PC” • my manager thinks, “this is a budget request” • Joe thinks, “this is the start of an installation process” • separate personal and universal properties • universal properties are visible to all • personal properties only affect individuals UC Berkeley, 29/2/2000
conceptual model Mike Karin Important Re: Placeless Backed Up On my laptop Re: Placeless Watch progress Show to Jim Format: Microsoft Word Length: 32754 Date: April 24, 1998 UC Berkeley, 29/2/2000
conceptual model Mike Karin Important Re: Placeless Backed Up On my laptop Re: Placeless Watch progress Show to Jim Format: Microsoft Word Length: 32754 Date: April 24, 1998 UC Berkeley, 29/2/2000
incorporating existing content • legacy repositories • “content providers” supply “path to the bits” • active properties for read and write operations • encapsulated per-document access protocols • native FS, NFS, SMB, HTTP, IMAP, etc • legacy applications • application protocols: http, imap, ftp, Java APIs • expect a filesystem, so give them one • NFS server puts placeless content “in” the filesystem • re-establishing filesystem invariants UC Berkeley, 29/2/2000
outline • customisation and appropriation • placeless documents - motivation • placeless documents - design • case study #1: shared document management • case study #2: workflow infrastructure service • revisiting assumptions • appropriable technologies UC Berkeley, 29/2/2000
case study #1 UC Berkeley, 29/2/2000
the project • ethnographic engagement by WPT • one prototype under development (ECSCW’99) • capture and retrieval issues • exploring a different area • using fieldwork and prototype to uncover issues • target project • engineering project in local government organisation • focus on document practices UC Berkeley, 29/2/2000
the “project files” • centralised repository of projectdocuments • reports, plans, letters ... • move with the project throughdifferent phases • some archived permanentlyat end of project • filed according to acommon organisation scheme(Uniform File System: UFS) UC Berkeley, 29/2/2000
filing problems So there’s all these categories it could conceivably go under and I have to pick one. […] certainly my assessment may be different than the guy next aisle over. UC Berkeley, 29/2/2000
filing problems Ok now I don’t see what I thought I was looking for. So, uhm, I guess I would stick it under uh Floodplain Evaluations. What was the other spot? Drainage is usually done during the design phase and we’re not there yet. So that’s why I would pick, uhm, but see 231 is Draft Environmental Document which is pretty vague. So I’ll never find it. It’s just not going to happen. I’d probably be more inclined to stick it under Drainage even though that’s not where it belongs? So that’s what I’m going to do. UC Berkeley, 29/2/2000
variability in the UFS UC Berkeley, 29/2/2000
the UFS in flux • the UFS is continually evolving • organisational changes • adaptations to suit individual and group needs • shared within work groups • the UFS as a collaborative artifact • a site of collaborative activity • not just a resource but an object of work • category scheme and documents are part of the same workspace UC Berkeley, 29/2/2000
macadam design goals • balance customisation and mutual intelligibility • allow modification of UFS at different levels • personal, workgroup, project, organisation, etc. • each level reflects a different set of concerns • support file browsing, search and archiving • adapt local schemes to global perspectives • global intelligibility of local actions • basic approach • cumulative customisation deltas UC Berkeley, 29/2/2000
layered trees Basic view vehicle land sea 4-wheeled 2-wheeled UC Berkeley, 29/2/2000
layered trees Paul’s view vehicle land sea 3-wheeled submarine 4-wheeled 2-wheeled UC Berkeley, 29/2/2000
layered trees Tom’s view vehicle air land sea 3-wheeled submarine 4-wheeled 2-wheeled car UC Berkeley, 29/2/2000
explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000
explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000
explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000
explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000
multiple contexts organisation project workgroup personal UC Berkeley, 29/2/2000
multiple contexts organisation project workgroup personal UC Berkeley, 29/2/2000