Prototype Photos
TODO upload photos to the wiki
Briefing
Hi,
Our project is a robotic system monitor on a mobile device ( we chose Android ).
Every robot is in some sense a computer which runs multiple processes such as sensors, logical units and actuators. These processes communicate with each other usually via a shared medium.
In the specific types of systems that we consider the communications happens on different channels, and every process can decide whether to publish or subscribe to any channels.
There are messages sent on every channel, where each message is a certain data structure - different for every channel.
The purpose of our interface is to allow the user to observe the data flowing on these channels as well as to allow the ability to publish messages in order to alter the robot state.
Tasks
Before the first task we showed the users the storyline.
Task 1: Debugging the robot
Use the interface to find what is wrong with the robot.
(successful completion of this task means that the user have found the plot of the POSITION channel and it has sharp discontinuity - a bug)
Task 2: Plot multiple graphs on the same plot
Task 3: Publish a message on a channel
Storyline
TODO take a picture of the environment
Task 1: Find a buggy channel
Task 2: Create multi-channel plot
Task 3: Publish specific message
Observations
Our first user was confused about the whole storyline and only completed the first task. We probably didn't do very good job explaining the domain.
Drop-down menus suck - it is hard to figure out what they mean.
If we have several drop-down menues with dependencies (i.e. you set the first one and the options in the second change) there needs to be something to
Prototype iteration
We actually started with two prototypes. We took the two most diverse designs from GR2 and each of team created a prototype around each design. Each team member implemented a prototype, the design for which was proposed by the other team member - this way we better understood each other's ideas and we able to avoid emotional attachment to specific features in the desings.
Our iteration cosists of merging the ideas that we found work in each prototype after the in-class testing.
Discussion
We are targeting a pretty narrow user base (robotics researchers and UROPS), so one of our biggest hurdles in this stage was grounding the subject users in the task domain. In order for a user to operate our interface they'd need to have a certain background which cannot fully and deeply be explained in 5 minutes.
We also discovered that it is pretty hard to create affordances in paper prototypes with low fidelity of look. Good mobile interfaces heavily rely on such cues and techniques in order to stand out. In short - paper prototype is still useful for brainstorming design ideas for mobile interfaces but we believe that the gap between paper prototype and pixel-perfect prototypes is significant.