Accounts: A different approach to abstractions

Supercomputers usually have a variety of storage options including large scratch space, which is local to the system, and global storage for user and project directories. Additionally, users have access to tape storage for long term archival needs. There are various reasons why users may need to move files between these storage systems, including staging input data for faster access and clearing disk space for new files.

One domain scientist shared a story about a middleware solution that provided an abstraction layer to help manage the reading, writing, and transferring of files between these systems. The idea was to free users from thinking about which storage system to use. For example, users could simply issue a read command and let the software figure out where the file was actually stored. Although this provided for ease of use, a problem was quickly identified. Users had no way of knowing whether the file was stored local to the machine or on the tape archive. The difference in latency between the two options was significant, but without knowing where the file was, the users had difficulty estimating this latency. The ability to estimate time for such processes is key in helping users plan their own activities (i.e. deciding to wait for a process to finish or to instead go home).

Dourish and Button have written about this common problem with computational abstractions:

“[O]ne source of interactional problems in HCI lies in the way that computational abstractions are black boxes, in which the activity they encapsulate is obscured from view, and so unavailable to users as a resource around which they might be able to organise their action.” [1]

They argue that instead, systems should be designed such that they are observable and reportable:

“[I]n order to manage the relationship between the user’s work and the system’s action more effectively, we need to provide users with more information about how the system goes about performing the activities that have been requested; and that the place to look for this information is within the implementation, below the abstraction barrier.” [2]

They advocate not to do away with abstractions but for systems to create accounts of their behaviors:

“An account ... is a model of the system’s activity offered by the system to account for and cast light on its own action.” [2]

Frustration with the lack of transparency in HPC systems has been a common theme in our research. Thus, incorporating the idea of accounts into system design seems worthy of further investigation.

References:

1. Dourish, P. 2001. Where the Action Is: The Foundations of Embodied Interaction. Cambridge: MIT Press.
2. Dourish, P. and Button, G. 1998. On "Technomethodology": Foundational Relationships between Ethnomethodology and System Design. Human-Computer Interaction, 13(4), 395-432.