Using metalevel techniques in a flexible toolkit for CSCW applications Export

@article{citeulike:383536, address = {New York, NY, USA}, author = {Dourish, Paul}, citeulike-article-id = {383536}, citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=287676}, citeulike-linkout-1 = {http://dx.doi.org/10.1145/287675.287676}, comment = { * note the use of fieldwork to motivate what should go in a tool (an early example of this) * dourish argues convincingly that interface level and infrastructure level decisions interact. How does this play out in other papers assigned for this class? Where else might it play out (e.g. sustainability) * note the fact that he co-opts a proven technique (open implementation) used in other domains * note not only lack of diagrams but lack of concrete examples in many places: not ideal How does this toolkit differ from the issues that are the focus of the Myers and Olsen toolkits -- not about UI design. most toolkits today aren't about ui design (subArctic is an exception, as is recent work of Brad Myers). Instead, they focus on tasks or structures that are needed (e.g. ptk, momento, dourish) Basic idea of OI: have an interface for changing the black box, as well as one for using it. inconsistency avoidance vs consistency management main approach: divergence and synchronization - enables/mentions scalability (will or should be a theme in toolkit work) - enables opportunistic work (relate back to everyday computing) - synchronization seems ill-defined by p. 20 -- as if it might encompass multiple algorithms (i.e. versioning versus operational transformation promises and guarantees -e.g. I will edit X and need a guarantee that X is mine (structure vs content in hypertext, for example) meta level programming and open implementation seem like extra confusion: it is, simply, a highly extensible toolkit, and few decisions are made up front/it has a small library. In my mind, at least. For non cs folks, section 8 is key ---=note-separator=--- WHAT's special about cscw (data distribution; consistency control) For non cs folks, section 8 is key: basic components of the toolkit (streams, actions, promises, and guarantees); Streams have been used to support both fairly synchronous and fairly asynchronous forms of interaction, in the first and second examples, respectively. Actions have been used to characterize a range of application behavior, and guarantees have been used to give different degrees of feedback to users about the likely effects of actions. So, we can step back and ask a more general question. How does Prospero address the flexibility problems we encounter in designing CSCW toolkits? These four fundamental structures offered by Prospero emphasize the design of applications that avoid temporal or structural constraints, which interfere with the performance of collaborative activity. Second, and more importantly here, they were chosen for their value as points of articulation at the metalevel; they provide a conceptual separation for the areas of flexibility and control offered to application developers. "fluid use \& static infrastructure" }, doi = {10.1145/287675.287676}, issn = {1073-0516}, journal = {ACM Trans. Comput.-Hum. Interact.}, keywords = {architecture, cs-mini, cscw, distributed, hcii-minis, metalevel-programming, tools}, month = {June}, number = {2}, pages = {109--155}, posted-at = {2007-01-16 03:59:18}, priority = {0}, publisher = {ACM Press}, title = {Using metalevel techniques in a flexible toolkit for CSCW applications}, url = {http://dx.doi.org/10.1145/287675.287676}, volume = {5}, year = {1998} }

TY - JOUR ID - citeulike:383536 L3 - citeulike-article-id:383536 IS - 2 JF - ACM Trans. Comput.-Hum. Interact. SN - 1073-0516 AD - New York, NY, USA EP - 155 TI - Using metalevel techniques in a flexible toolkit for CSCW applications PB - ACM Press VL - 5 SP - 109 KW - architecture KW - cs-mini KW - cscw KW - distributed KW - hcii-minis KW - metalevel-programming KW - tools N1 - * note the use of fieldwork to motivate what should go in a tool (an early example of this) * dourish argues convincingly that interface level and infrastructure level decisions interact. How does this play out in other papers assigned for this class? Where else might it play out (e.g. sustainability) * note the fact that he co-opts a proven technique (open implementation) used in other domains * note not only lack of diagrams but lack of concrete examples in many places: not ideal How does this toolkit differ from the issues that are the focus of the Myers and Olsen toolkits -- not about UI design. most toolkits today aren't about ui design (subArctic is an exception, as is recent work of Brad Myers). Instead, they focus on tasks or structures that are needed (e.g. ptk, momento, dourish) Basic idea of OI: have an interface for changing the black box, as well as one for using it. inconsistency avoidance vs consistency management main approach: divergence and synchronization - enables/mentions scalability (will or should be a theme in toolkit work) - enables opportunistic work (relate back to everyday computing) - synchronization seems ill-defined by p. 20 -- as if it might encompass multiple algorithms (i.e. versioning versus operational transformation promises and guarantees -e.g. I will edit X and need a guarantee that X is mine (structure vs content in hypertext, for example) meta level programming and open implementation seem like extra confusion: it is, simply, a highly extensible toolkit, and few decisions are made up front/it has a small library. In my mind, at least. For non cs folks, section 8 is key N1 - WHAT's special about cscw (data distribution; consistency control) For non cs folks, section 8 is key: basic components of the toolkit (streams, actions, promises, and guarantees); Streams have been used to support both fairly synchronous and fairly asynchronous forms of interaction, in the first and second examples, respectively. Actions have been used to characterize a range of application behavior, and guarantees have been used to give different degrees of feedback to users about the likely effects of actions. So, we can step back and ask a more general question. How does Prospero address the flexibility problems we encounter in designing CSCW toolkits? These four fundamental structures offered by Prospero emphasize the design of applications that avoid temporal or structural constraints, which interfere with the performance of collaborative activity. Second, and more importantly here, they were chosen for their value as points of articulation at the metalevel; they provide a conceptual separation for the areas of flexibility and control offered to application developers. "fluid use & static infrastructure" AU - Dourish, Paul PY - 1998/06// UR - http://dx.doi.org/10.1145/287675.287676 ER -