Representation of Inputs and Outputs for Sensor Data Survey

The Objectives. The objective of this survey [BFH09c] was to get user opinions with regards to how inputs and outputs can be represented in a tool such as theMobia Modeler. In particular, the following questions are the things we want to answer in this survey:

• How can information from input devices4 such as medgets be represented in a devel-

opment environment such as theMobia Modeler?

• How can all availablemedgets be represented in a manner that it is not confusing to

the user.

• How can the flow of information from an input device such as a medget to the

application be visually represented inside the development environment?

In order to find out the answers to the points mentioned, several designs were made and shown to the participants in order to get their opinions.

The Participants. There were 14 participants to the survey, 8 of which have back- grounds in Computer Science while the others are from Engineering, Mathematics and Physics. All of the participants have some programming background and were exposed to different types of development tools in the past.

The Process. The initial part of the survey involved the usual collection of personal background information from the participants such as profession, field of expertise, etc., and collection of technical background such as programming experience, programming language proficiency and development environments used.

In the second part of the survey, the participants were presented with different designs and questions with regards to how individualmedgetsand their data should be represented, how to display all available medgets, and how flow of information from medgets to the application screen should be represented.

Results and Analysis.

• Representing Individual medgets and their Data. One of the concerns in the design of the medget is the type of information that should be made available to the user in the development environment. Three types of possible information were identified: the name of the medget, the symbol representing the medget, and

4_{Devices that provide information to an application such as sensors that collect information which can}

the possible data it can provide. The table in figure 2.8 shows the three types of information that can be provided by a medget and the possible combinations of these information. The figure also shows the result of the survey in which most of the participants chose the one containing a graphical symbol of themedget and the possible information it contains.

Figure 2.8: Results for the survey on how to represent individualmedgets and their data. A conclusion drawn from the said result is that, the user is not too concerned with the name of the medget as long as the symbols representing it is clear enough for the user. Textual labels were suggested to be shown during a mouseover event for instance. Another thing is the importance of showing the data that amedget provides such as the symbol for Celcius for a Thermometermedget.

• Displaying All Medgets. Another objective for this survey was to find out how all availablemedgets and the data they provide can be presented in the development environment that does not confuse the user.

As an example, let us assume that there are three types of medgets available: med- get A, medget B and medget C. We will not name the medgets here since what is important is how they are positioned and displayed. Each medget can have one or more types of data that it can provide which are shown as cross symbols (figure 2.9). For the Individual display, each medget and all possible data it provides are shown as one component in the medget palette. For instance, if there are three available data type for eachmedget, then three components for that medget are present in the palette.

The Grouped display shows all the possible data grouped according to the medget it is taken from. The medget palette is divided into three sections for the three types of medget, and each section contains all the possible data.

The Minimalist display only shows the available medgets in the palette. Later on, when themedget is added to a screen instance as shown in the figure, double clicking on the medget icon on top of the screen will show possible data representations for each double click.

For the results of the survey, 46% chose the Grouped display, while 31% chose the

Minimalist display and the rest chose the Individual display. From the results col- lected, we can see that what is important to the user is themedget as represented by

Figure 2.9: Results for the survey on how to display all available medgets in the modeling environment.

its icon, and then the type of data it provides. It is also easier to look for what the users need when the medgets are grouped according to their type.

• Visualizing Flow of Information. The final design question for this survey was how to visualize flow of information from medgets to the screen in an application inside the development environment. In order to answer this question, three possible types of interaction were provided (figure 2.10).

The first one is the Choose, Drag and Drop approach which is a common approach in development environments. In this approach, given a set of components in the palette, the user chooses a component and then drags it to a target location.

The second one is the Drag, Connect and Click approach, in which the user drags an arrow from the medget to the target screen. This arrow will signify information would flow from the medget to the screen. After a connection between a screen and amedget is done, the user would then choose the desired data that would appear on the mobile screen.

Finally, the Drag, Drop and Click approach in which the user drags a certain med- get to the target screen and the medget is attached to the top of the screen to symbolize connection. The default data provided by amedget will then be shown on the screen. Clicking on the attachedmedget will show a possible data representation for each double click. For instance, if amedget has two available data representations, the visuals will toggle between the two each time a double click is done.

Based on the survey results, majority of the participants preferred the Choose, Drag and Drop approach (46%). A big factor that may have resulted from this is because it is the concept that the participants were most familiar with. The second choice (38%) was theDrag, Drop and Click approach.The least popular was theDrag, Connect and

Figure 2.10: Results for the survey on how to visualize flow of information in the modeling environment.

Click approach even though it actually symbolizes some sort of connection with the

medget in the presence of flow arrows. The reason that this was the least popular among the participants may be because the steps involved in this type of interaction deviate from commonly used approaches such as the simple drag and drop of icons on the screen. It may be difficult for the participants to envision such interaction by just reading how it works and not experiencing how the interaction works themselves. Recommendations. Some additional recommendations aside from those that were al- ready mentioned for each point in theresults and analysis follows.

In terms of interaction such as visualizing flow of information, the most commonly encountered approach that the participants were more familiar with was the one mostly chosen. This may be because it is quite challenging to imagine interaction when just shown the design and not be able to interact with it. Surveys are not as effective if the participants are not able to try out the interaction themselves. In terms of the designs though such as representation of medgets and their data, the users can easily choose from the designs presented in the survey.