1 / 74

Paul Dourish Xerox Palo Alto Research Center

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

wolfgang-richard
Télécharger la présentation

Paul Dourish Xerox Palo Alto Research Center

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. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000

  10. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000

  11. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000

  12. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000

  13. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt UC Berkeley, 29/2/2000

  14. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk UC Berkeley, 29/2/2000

  15. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish UC Berkeley, 29/2/2000

  16. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Status = in progress UC Berkeley, 29/2/2000

  17. document properties T:\dourish\inprogress\talks\ucb\placeless.ppt Type = talk Author = dourish Status = in progress Backup = true UC Berkeley, 29/2/2000

  18. 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

  19. 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

  20. 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

  21. 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

  22. properties for appropriation • properties are unordered & composable • coordination between different applications • no “path” constraintsmultiple 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. case study #1 UC Berkeley, 29/2/2000

  33. 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

  34. UC Berkeley, 29/2/2000

  35. UC Berkeley, 29/2/2000

  36. 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

  37. 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

  38. 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

  39. variability in the UFS UC Berkeley, 29/2/2000

  40. 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

  41. 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

  42. layered trees Basic view vehicle land sea 4-wheeled 2-wheeled UC Berkeley, 29/2/2000

  43. layered trees Paul’s view vehicle land sea 3-wheeled submarine 4-wheeled 2-wheeled UC Berkeley, 29/2/2000

  44. layered trees Tom’s view vehicle air land sea 3-wheeled submarine 4-wheeled 2-wheeled car UC Berkeley, 29/2/2000

  45. explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000

  46. explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000

  47. explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000

  48. explicit customisation Basic Paul’s Tom’s UC Berkeley, 29/2/2000

  49. multiple contexts organisation project workgroup personal UC Berkeley, 29/2/2000

  50. multiple contexts organisation project workgroup personal UC Berkeley, 29/2/2000

More Related