The infrastructure problem in HCI
W. Keith Edwards, Mark W. Newman, and Erika Shehan Poole. 2010. The infrastructure problem in HCI. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '10). Association for Computing Machinery, New York, NY, USA, 423–432. DOI:https://doi.org/10.1145/1753326.1753390This article outlines three difficulties caused by underlying technical infrastructures: constrained possibilities, unmediated interaction, and interjected abstractions. These problems can stand in the way of UX and HCI design implications for more human-centered design. Given interfaces sit atop infrastructure, they argue that HCI needs to expand its methodological toolbox and become more involved in the design of infrastructure.
Broadly, infrastructure can be defined as "any system, organizational structure, or physical facility that supports an organization or society in general" (pg. 423). This work defines infrastructure in the scope of software systems "system-level software providing functions, capabilities, or services to other software. Operating systems, libraries, toolkits, frameworks, services, protocols, and interoperation standards are common examples" (pg. 423-424). Software infrastructures are designed to be reusable, offer interoperability, and separate concerns so that specialized capabilities may also be implemented.
Infrastructure Problems
Constrained possibilities: "Design choices taken by the infrastructure may preclude entirely certain desirable user experience outcomes" (pg. 424).Interjected abstractions: "Technical abstractions in the interface may appear in the conceptual model exposed to users" (pg. 424).
Unmediated interaction: "Users may have to interact directly with the infrastructure to accomplish their goals" (pg. 424).
HCI Approaches to Infrastructure Problems
Surface approaches: "applying superficial layers of user-facing software in an attempt to shield users from unwieldy aspects of infrastructure" (pg. 427). The most common approach in HCI "thus far" (as in, up til 2010). It accepts the underlying infrastructure and attempts to improve user experience through application software. The authors argue this can help with unmediated interaction issues, by providing abstractions that fit user expectations. It can also address interjected abstractions by remapping abstractions in the face of negative outcomes. However, it cannot deal with constrained possibilities due to the infrastructure.Interface approaches: "focus on the interface between the infrastructure and the applications it supports, endeavoring to reduce the problems caused by mismatches between conceptual models and system functionality" (pg. 427). Some researchers have proposed ways of making infrastructure more transparent and more flexible (appropriable) to users.
Seamful design: Bell et al.'s "seamful design" propose exposing aspects of infrastructure in ways users can perceive underlying abstractions, rather than hiding it. Infrastructure limitations then become a resource and means of learning for users. It embraces the pitfalls of the unmediated interaction issue to address issues of interjected abstractions. Once more, it does not address constrained possibilities.
Reflective architectures: Allows software developers to access internal infrastructures in new ways that may be otherwise unforseen by original infrastructure designers. It allows software developers to reason with an infrastructure's internal states, and potentially alter them. This approach is best suited for addressing interjected abstractions and unmediated interaction, but it may also offer potentials for overcoming constrained possibilities.
Support for intelligibility: Intelligibility is explaining system configurations to users in an understandable way. This can help users to overcome mismatching mental models between their expectations and how a system functions. It addresses interjected abstractions through explanation of how abstractions work, and unmediated interaction by providing a new layer of mediation, but it does not address constrained possibilities. Intermediate approaches: "supply new infrastructure technologies that are more amenable to delivering a positive user experience, though they are often constrained by other, more fundamental infrastructure layers" (pg. 427). Intermediate approaches "typically sit atop of a layer of more fundamental infrastructure (e.g. existing operating systems, networking protocols, security mechanisms)" (pg. 428).
New infrastructure technologies: A top-down approach of identifying user needs and then designing those needs and pushing capabilities to the infrastructure. This approach does not work when those needs cannot be implemented with the infrastructure.
New infrastructure processes: When infrastructure must be built prior to an application, some have argued for human-centered approaches to designing infrastructure. However, this may be difficult given many HCI methods are less suited to problems where the system being designed or evaluated is removed from the application, or there is no known task.
Deep approaches: "seek to directly influence the architecture of infrastructure itself. In contrast to intermediate approaches, deep approaches require the engagement of multiple technical disciplines, most notably the systems specialists who have traditionally dominated discussions of infrastructure design. These are the most challenging approaches, and the least understood by the HCI community at present. They represent the next frontier in the struggle to overcome HCI’s infrastructure problem" (pg. 427).
Intermediate and deep approaches both focus on the same types of infrastructure technologies, but deep approaches engage stakeholders outside of HCI, like those in systems, security, and networking communities most commonly building infrastructures.
