We envision the home populated with regular objects that allow programmatic access to their sensors and actuators. The objects jointly form a pervasive computing platform, open for third party independently developed applications. A challenge is how to support people in deploying and managing such applications. Today, the user perceives an application as an immaterial artifact, accessed through a screen-based interface of a general-purpose computing device. Contrary to that established paradigm, we propose to reify the pervasive computing application as a simple physical thing, called the “application pill.” The pill can easily be grasped and operated: the user brings the pill home, switches it on, and checks if it works just by glancing at its on/off diode. As the application is destined for many homes, each featuring a different collection of objects, the user should be provided with high-level feedback on how well the application can work in her home. Accordingly, the application pill is also equipped with a simple “functionality level” indicator. The degree to which the application can deliver its functionality on top of an available object collection is captured as a single number and displayed by the pill. We present a concrete proof-of-concept elaboration and implementation of these ideas in a pervasive computing middleware platform targeted at cooperating objects.

1. ​Based on initial sections of the paper:
​Domaszewicz, J.; Lalis, S.; Paczesny,T.; Pruszkowski, A.; Ala-Louko, M.
Graspable and resource-flexible applications for pervasive computing at home
IEEE Communications Magazine, IEEE , vol.51, no.6, pp.160-169, June 2013
​Prepared by:
Jaroslaw Domaszewicz
​Institute ofTelecommunications
Warsaw University ofTechnology
Warsaw, Poland
​
Spyros Lalis
​IRETETH/CERTH & University ofThessaly
Volos, Greece
GRASPABLE AND RESOURCE-FLEXIBLE
APPLICATIONSFORPERVASIVECOMPUTINGATHOME
reifyingsmarthomeapplications…
tomakethemmorelikeaflashlight

2. PartI.Ecosystemforresource-flexible
pervasivecomputingathome

3. 3|
Sensor/ActuatorAPI ​Our vision of pervasive computing for the domestic environment
assumes an ecosystem formed by an API
and three basic stakeholders (Fig. 1a).
​The sensor/actuator API captures relevant resources
in the form of primitives.

4. 4|
Objectsandapplications
aredeveloped
independently
​Object manufacturers produce smart objects, which, in addition
to their regular functionality, expose their sensors and actuators
through appropriate API primitives.
​Application developers pick the primitives needed for sensing
and actuation in their smart home applications.
​The processes of object and application development
are totally decoupled.

5. 5|
Thesmarthomeplatform
isformedad-hoc
​The user purchases objects for their regular functionality.
At home, objects jointly form an application execution platform
(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.

6. 6|
Applicationsareacquired
withoutthinkingabout
availableobjects
​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.

7. 7|
Result:sensor/actuator
resourcesareunknown
atthedevelopmenttime
​The “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.
?

8. 8|
Solution:
resource-flexible
applications
​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.

9. PartII.Theapplicationpill:agraspableapplication
forresource-flexiblecomputing

10. 10|
Reifyingapplications
tomakethemmore
likea flashlight
​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 smart home 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.

11. 11|
Envisioning
thegraspableapplication
(1/3)
​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.
​

12. 12|
Envisioning
thegraspableapplication
(2/3)
​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.
​

13. 13|
Envisioning
thegraspableapplication
(3/3)
​The application object may feature one or more knobs,
each for setting a single parameter
(e.g., the setpoint for a temperature control application).
​

14. 14|
Theapplicationpill(1/2) ​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).
​

15. 15|
Theapplicationpill(2/2) ​Of course, one can imagine several variations of our “canonical”
application pill design (Fig. 4). 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 devices with a powerful interface,
likely to be found in the home (say, a TV or smartphone).

16. 16|
Forthefullstory,goto
​Domaszewicz, J.; Lalis, S.; Paczesny, T.; Pruszkowski, A.; Ala-Louko, M.
Graspable and resource-flexible applications for pervasive computing at home
IEEE Communications Magazine, vol.51, no.6, pp.160-169, June 2013,
doi:10.1109/MCOM.2013.6525610. Available at http://meag.tele.pw.edu.pl
​
​Some further items in the paper:
1. a tree-based programming model
with resource-driven, partial tree instantiations,
2. an API for programmer-supported hints
that allow runtime calculations of
the functionality level,
3. HumidifySmart – a case study of a resource-
flexible application with two deployment
examples.
​This work was funded in part by the 7th Framework Program of the European Community, project POBICOS, contract no.
FP7-ICT-223984. Thanks to Manos Koutsoubelias, Markus Taumberger, Tomasz Tajmajer, and Vladimir Palacka.