Application Pill

reifying smart home applications to make them more like a flashlight

I. Ecosystem for resource-flexible pervasive computing at home

Our vision of pervasive computing for the domestic environment assumes an ecosystem of three basic stakeholders (Fig. 1a). The sensor/actuator (API) captures relevant resources in the form of primitives. Object manufacturers produce smart objects, which, in addition to their regular functionality, expose their sensors and actuators through appropriate API primitives. On the other hand, application developers pick the primitives needed for sensing and actuation in their application. The processes of object and application development are totally decoupled.

Fig1-wiki.png

The user purchases objects for their regular functionality. At home, objects jointly form a platform for the execution of pervasive computing applications (Fig. 1b). The platform emerges as a side-effect of populating the home with objects that are useful for its inhabitants as such, without consideration for the applications. In a similar vein, the user acquires applications without knowing how well the object collection in his home can actually support them. Of course, these applications cannot be life critical.

This “unplanned” acquisition of objects implies that it is unlikely for any two homes to feature the same object collection. It follows that the objects (sensors and actuators) of the target platform are unknown when the application is developed. If the application is to be of value across a wide range of homes, it must be resource-flexible, i.e., it should function (instead of quitting) even if it is lacking some sensors and actuators.

Resource flexibility comes with uncertainty about how well the application will actually work; it may be able to deliver its functionality only partially. If so, the application should inform the user about the functionality it can deliver in the home where it is deployed.

II. The application pill: a graspable application for resource-flexible computing

We argue that the best way for the application to “disappear” is (somewhat paradoxically) to reify it as a regular object that blends into the domestic environment. As a yardstick, think how easy it is for anyone to operate a flashlight: it only has an on/off switch, and it is trivial to check if it works, just by glancing at it. We wish this to hold for pervasive computing applications as well.

To this end we propose the concept of the graspable application: a small physical artifact that embodies a single application and features an absolutely minimal interface (without any general-purpose UI elements) for controlling and monitoring its operation. The point is for the user to conceptually identify the application itself with a physical object, which can be grasped and manipulated as easily as the flashlight.

We envision the graspable application as a small object, roughly the size of a matchbox, as shown in Fig. 2. The object has a pushbutton to start/stop the application and a diode to show whether the application is running. We capture the functionality level of the application as a fraction of the functionality it would be able to provide if it had at its disposal all the sensors and actuators it requests from the underlying object community. The functionality level can be intuitively displayed via a simple gauge, like the ones used to show the signal strength of wireless devices. The application object may feature one or more knobs, each for setting a single parameter (e.g., the setpoint for a temperature control application).

Fig2-wiki.png

To stress that such a graspable application object should be truly minimal (in terms of both size and interface), and to hint that it carries the application’s code, we call it the application pill. A pill could be accompanied by a one-page manual describing what the application will do for the user at different values of the functionality level. From the user’s perspective, the application pill is the application. It can be casually placed anywhere in the home (Fig. 3).

Fig3-wiki.png

Of course, one can imagine several variations of our “canonical” application pill design. However, it is important to note that the application pill should not be transformed into yet another attention-hungry computer-like device. If the application has to support complex input/output functions, these should be delegated to other devices with a powerful interface that are likely to be found in the home, such as TVs, computers, and smart phones.



See our paper:

  • Domaszewicz, J.; Lalis, S.; Paczesny, T.; Pruszkowski, A.; Ala-Louko, M.
    Graspable and resource-flexible applications for pervasive computing at home
    Communications Magazine, IEEE, vol.51, no.6, pp.160-169, June 2013, doi:10.1109/MCOM.2013.6525610
    pdf(paper), pdf(presentation), IEEE Xplore


Further related work:

  • Donald A. Norman
    The next UI breakthrough, part 2: physicality
    interactions, vol. 14, no. 4, pp. 46-47, July 2007, doi:10.1145/1273961.1273986
    An argument for "physicality" understood as "the return to physical devices, where we control things by physical body movement, by turning, moving, and manipulating appropriate mechanical devices."