The challenges of user-centered design and evaluation for infrastructure Export

@inproceedings{citeulike:78011, abstract = {Infrastructure software comprises code libraries or runtime processes that support the development or operation of application software. A particular infrastructure system may support certain styles of application, and may even determine the features of applications built using it. This poses a challenge: although we have good techniques for designing and evaluating interactive applications, our techniques for designing and evaluating infrastructure intended to support these applications are much less well formed. In this paper, we reflect on case studies of two infrastructure systems for interactive applications. We look at how traditional user-centered techniques, while appropriate for application design and evaluation, fail to properly support infrastructure design and evaluation. We present a set of lessons from our experience, and conclude with suggestions for better user-centered design and evaluation of infrastructure software.}, address = {New York, NY, USA}, author = {Edwards, W. Keith and Bellotti, Victoria and Dey, Anind K. and Newman, Mark W.}, booktitle = {CHI '03: Proceedings of the SIGCHI conference on Human factors in computing systems}, citeulike-article-id = {78011}, citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=642664}, citeulike-linkout-1 = {http://dx.doi.org/10.1145/642611.642664}, comment = {about evaluating toolkits CS people: care about reuse, performance, scalability, security, robustness, and so on * how are infrastructure features selected (avoid bloat; still support needs) -- could be more user centered: means coupled to application features * how is an infrastructure evaluated -- manifestation means what? -- do user studies change form? What is the value of this paper? Clearly lays out lessons for tool developers Lesson 5—Be clear about what your test-application prototypes will tell you about your infrastructure: It is easy to get distracted by the demands of building applications in themselves and to lose sight of the real purpose of the exercise, which is purely to understand the pros and cons of your infrastructure. a better approach would have been to spend time creating a toolkit with a simpler set of features (reiterating lesson 1) and deriving a base set of usable and useful widgets (analogous to the seven basic widgets in the Macintosh Toolbox) and letting designers explore the building of whatever applications were possible with those. This way, we could have elicited feedback on what additional widgets were desirable as well as on what features were crucial in making the toolkit easier to use. * Lesson 1—Prioritize core infrastructure features. * Lesson 2—First, build prototypes that express the core objectives of the infrastructure. * Lesson 3—Any test-application built to demonstrate the infrastructure must also satisfy the usual criteria of usability and usefulness. * Lesson 4—Initial proof-of-concept applications should be lightweight. * Lesson 5—Be clear about that your test-application prototypes will tell you about your infrastructure. * Lesson 6—Do not confuse the design and testing of experimental infrastructure with the provision of an infrastructure for experimental application developers. * Lesson 7—Be sure to define a limited scope for test- applications and permissible uses of the infrastructure. * Lesson 8—There is no point in faking components and data if you want to test for user experience benefits. ---=note-separator=--- What is the value of this paper? Clearly lays out lessons for tool developers 1 sentence summary: Mostly, they emphasize well-focused, lightweight prototypes that are centered around a small number of core features. }, doi = {10.1145/642611.642664}, isbn = {1-58113-630-7}, keywords = {cs-mini, design-recommendations, hcii-minis, interaction, tools, user-centered-design}, location = {Ft. Lauderdale, Florida, USA}, pages = {297--304}, posted-at = {2007-01-10 02:00:55}, priority = {0}, publisher = {ACM}, title = {The challenges of user-centered design and evaluation for infrastructure}, url = {http://dx.doi.org/10.1145/642611.642664}, year = {2003} }

TY - CONF ID - citeulike:78011 L3 - citeulike-article-id:78011 N2 - Infrastructure software comprises code libraries or runtime processes that support the development or operation of application software. A particular infrastructure system may support certain styles of application, and may even determine the features of applications built using it. This poses a challenge: although we have good techniques for designing and evaluating interactive applications, our techniques for designing and evaluating infrastructure intended to support these applications are much less well formed. In this paper, we reflect on case studies of two infrastructure systems for interactive applications. We look at how traditional user-centered techniques, while appropriate for application design and evaluation, fail to properly support infrastructure design and evaluation. We present a set of lessons from our experience, and conclude with suggestions for better user-centered design and evaluation of infrastructure software. CY - Ft. Lauderdale, Florida, USA SN - 1-58113-630-7 AD - New York, NY, USA EP - 304 TI - The challenges of user-centered design and evaluation for infrastructure PB - ACM T2 - CHI '03: Proceedings of the SIGCHI conference on Human factors in computing systems SP - 297 KW - cs-mini KW - design-recommendations KW - hcii-minis KW - interaction KW - tools KW - user-centered-design N1 - about evaluating toolkits CS people: care about reuse, performance, scalability, security, robustness, and so on * how are infrastructure features selected (avoid bloat; still support needs) -- could be more user centered: means coupled to application features * how is an infrastructure evaluated -- manifestation means what? -- do user studies change form? What is the value of this paper? Clearly lays out lessons for tool developers Lesson 5—Be clear about what your test-application prototypes will tell you about your infrastructure: It is easy to get distracted by the demands of building applications in themselves and to lose sight of the real purpose of the exercise, which is purely to understand the pros and cons of your infrastructure. a better approach would have been to spend time creating a toolkit with a simpler set of features (reiterating lesson 1) and deriving a base set of usable and useful widgets (analogous to the seven basic widgets in the Macintosh Toolbox) and letting designers explore the building of whatever applications were possible with those. This way, we could have elicited feedback on what additional widgets were desirable as well as on what features were crucial in making the toolkit easier to use. * Lesson 1—Prioritize core infrastructure features. * Lesson 2—First, build prototypes that express the core objectives of the infrastructure. * Lesson 3—Any test-application built to demonstrate the infrastructure must also satisfy the usual criteria of usability and usefulness. * Lesson 4—Initial proof-of-concept applications should be lightweight. * Lesson 5—Be clear about that your test-application prototypes will tell you about your infrastructure. * Lesson 6—Do not confuse the design and testing of experimental infrastructure with the provision of an infrastructure for experimental application developers. * Lesson 7—Be sure to define a limited scope for test- applications and permissible uses of the infrastructure. * Lesson 8—There is no point in faking components and data if you want to test for user experience benefits. N1 - What is the value of this paper? Clearly lays out lessons for tool developers 1 sentence summary: Mostly, they emphasize well-focused, lightweight prototypes that are centered around a small number of core features. AU - Edwards, Keith AU - Bellotti, Victoria AU - Dey, Anind AU - Newman, Mark PY - 2003/// UR - http://dx.doi.org/10.1145/642611.642664 ER -