Limits...
ECCE Toolkit: Prototyping Sensor-Based Interaction

View Article: PubMed Central - PubMed

ABSTRACT

Building and exploring physical user interfaces requires high technical skills and hours of specialized work. The behavior of multiple devices with heterogeneous input/output channels and connectivity has to be programmed in a context where not only the software interface matters, but also the hardware components are critical (e.g., sensors and actuators). Prototyping physical interaction is hindered by the challenges of: (1) programming interactions among physical sensors/actuators and digital interfaces; (2) implementing functionality for different platforms in different programming languages; and (3) building custom electronic-incorporated objects. We present ECCE (Entities, Components, Couplings and Ecosystems), a toolkit for non-programmers that copes with these issues by abstracting from low-level implementations, thus lowering the complexity of prototyping small-scale, sensor-based physical interfaces to support the design process. A user evaluation provides insights and use cases of the kind of applications that can be developed with the toolkit.

No MeSH data available.


Excerpts from the XML file with the templates for the definition of sensors: (a) a button; (b) a touch sensor and; (c) a proximity sensor.
© Copyright Policy - open-access
Related In: Results  -  Collection

License
getmorefigures.php?uid=PMC5375724&req=5

sensors-17-00438-f005: Excerpts from the XML file with the templates for the definition of sensors: (a) a button; (b) a touch sensor and; (c) a proximity sensor.

Mentions: As an example, Figure 5 shows excerpts from the XML file that stores the templates for physical sensors in the ECCE toolkit. Each sensor has a field (sensor_type) that defines the type of sensor (e.g., button, touch, proximity), an optional controller that identifies different implementations of the same sensor type (e.g., infrared proximity sensor versus ultrasonic range finder) and a unique identifier (uuid). Each sensor generates data of a different datatype—(i) high/low boolean values; (ii) discrete values within a range or; (iii) string—that can be mapped to produce output values according to different mapping functions. For example, a proximity sensor can send raw values as directly read from the sensor or use a utility function (getDistanceCm in the example in Figure 5) to convert raw data in the actual distance in centimeters. The XML code in Figure 5 is provided by the toolkit and it can be extended by users to create additional functionality or add new sensors as shown in Section 3.5. The XML description provides templates for sensors and UI elements that are completed with additional information at the time the user selects the component in his/her project. For example, the actual pin for a sensor will be specified in the output tag once the user will drop the sensor in the desired port (Figure 3).


ECCE Toolkit: Prototyping Sensor-Based Interaction
Excerpts from the XML file with the templates for the definition of sensors: (a) a button; (b) a touch sensor and; (c) a proximity sensor.
© Copyright Policy - open-access
Related In: Results  -  Collection

License
Show All Figures
getmorefigures.php?uid=PMC5375724&req=5

sensors-17-00438-f005: Excerpts from the XML file with the templates for the definition of sensors: (a) a button; (b) a touch sensor and; (c) a proximity sensor.
Mentions: As an example, Figure 5 shows excerpts from the XML file that stores the templates for physical sensors in the ECCE toolkit. Each sensor has a field (sensor_type) that defines the type of sensor (e.g., button, touch, proximity), an optional controller that identifies different implementations of the same sensor type (e.g., infrared proximity sensor versus ultrasonic range finder) and a unique identifier (uuid). Each sensor generates data of a different datatype—(i) high/low boolean values; (ii) discrete values within a range or; (iii) string—that can be mapped to produce output values according to different mapping functions. For example, a proximity sensor can send raw values as directly read from the sensor or use a utility function (getDistanceCm in the example in Figure 5) to convert raw data in the actual distance in centimeters. The XML code in Figure 5 is provided by the toolkit and it can be extended by users to create additional functionality or add new sensors as shown in Section 3.5. The XML description provides templates for sensors and UI elements that are completed with additional information at the time the user selects the component in his/her project. For example, the actual pin for a sensor will be specified in the output tag once the user will drop the sensor in the desired port (Figure 3).

View Article: PubMed Central - PubMed

ABSTRACT

Building and exploring physical user interfaces requires high technical skills and hours of specialized work. The behavior of multiple devices with heterogeneous input/output channels and connectivity has to be programmed in a context where not only the software interface matters, but also the hardware components are critical (e.g., sensors and actuators). Prototyping physical interaction is hindered by the challenges of: (1) programming interactions among physical sensors/actuators and digital interfaces; (2) implementing functionality for different platforms in different programming languages; and (3) building custom electronic-incorporated objects. We present ECCE (Entities, Components, Couplings and Ecosystems), a toolkit for non-programmers that copes with these issues by abstracting from low-level implementations, thus lowering the complexity of prototyping small-scale, sensor-based physical interfaces to support the design process. A user evaluation provides insights and use cases of the kind of applications that can be developed with the toolkit.

No MeSH data available.