Scenario
John is a Ph.D. student in a robotics lab at the University of Michigan. Last year he was on-track to finish his thesis in two years, but this year he feels like he's still got two years left. John's project involves cooperative maneuvers on autonomous quadrocopters and he's hoping to show that his systems can build complex structures autonomously. He implemented his communication system via LCM channels on a wireless network and so far has been relatively happy with it.
One of John's collaborators on the more theoretical side, Craig, is in town, so John fires up his base-station computer to run a short demo. He was up late last night getting the code ready, and managed to get his new cooperative block-lifting code to work. As the computer comes up, John hooks in the quad's batteries and confirms their normal startup beeps and bloops.
Once the ground-station is online, John walks into the shared motion-capture studio and places his two vehicles on their starting positions. He taps the "Robo-Monitor" app and takes a quick glance to make sure everything is online. All looks good so he hits go.
The quads jump to life and Craig unconsciously steps back. John smilies as he sees his friend watch their work in action. The test goes well until the third task when one of the helicopters refuses to move. It slowly lowers itself to the ground and remains there idling. John looks at Craig who seems surprised but doesn't know what is wrong. John looks at his phone and sees that data is still moving on all of the channels. He takes a closer look at the "QUAD2_COMMAND" channel, but valid commands are clearly being sent.
A few weeks ago, John had some integration trouble, so he created a "debug" mode for the system. Might as well try it, he says to himself and a few taps later he is on the command channel of the Robo-Monitor app. A quick tap sends the "debug" command, and the other quad lands. A flood of new data appears on the screen and John drills down into the QUAD2 subsystems. On-board sensing seems good... battery voltage is nominal... internal temperatures are valid... embedded processors are running... plenty of free RAM... wait... looks like position isn't correct. John picks up his ill craft and notices that velocities remain zero.
"Stupid Vicon always breaks," John tells Craig who laughs and says something derogatory about real hardware. Why would it only be one quad? John thinks and looks at the quad. "It was working last night!"
As John is thinking, Craig starts pacing and steps on a small silver ball. He asks John, "what's this," showing John a small silver ball. "That's a Vicon marker... where did you find it?"
"On the floor over here, " Craig replies. "Could it be the problem?"
"Well, only if it came off of this one. Let's check." "Hey, looks like it must have gotten bumped off when it picked up that last block. That would definitely do it."
Ten minutes of marker-repair later, John switches back to his app. He punches "normal operation" command to move out of debug mode and the quads jump back to life. "It's always something," says Craig. "This is why I work in simulation."
------
For each high-level task that the user works on there is a separate layout.
A layout describes a specific configuration of the interface best suited for certain task. For example,
a user might use one layout for monitoring, another for debugging and a third for developing a certain system.
Multi-Layout Rectangular design
In the multi-layout rectangular design the user can have several layout open as shortcuts / tabs.
That will allow for easy switching between high-level tasks and lets the user to organize the visualizations into categories.
When the user selects a layout by tapping, the screen slides to the left and and the layout is shown.
Each visualization is contained in a rectangle (hence Rectangular) the user can move visualizations around by dragging them and change their properties by tapping on them. The screen slides to the right where the user can specify the parameters of the visualization : channel, property (within the channel), visualization type (histogram, plot through time, etc.).
A challenge for this design is making visible the affordance that the visualizations can be dragged around with a finger. For this we rely on intuition the user has from using other mobile interfaces (ex. iOS main menu behaves in a similar way).
Single-Layout List design
<working on now>
List-Based Interface
The main screen shows a list of available channels and color codes them based on recent activity. Tapping a channel selects its detailed view (bottom right) which displays live graphs of any numeric quantities. Tapping a graph or number in a channel brings up the graph interface (below).
Graph interface fills the screen. Interaction is similar to a photograph which users are familiar with. Pinch or double-tap to zoom, drag to pan. A single tap anywhere freezes/unfreezes the graph (ie stops or starts live data being added.)
More traces can be added to the plot by pressing Menu and then selecting Add Trace. The Add Trace window appears (lower right) which allows the user to browse through available channels and variables in those channels. More than one new variable can be selected.
A control mode, accessible from the Menu button on the main screen allows the user to change parameters. Options are presented as spinners which update in real-time (send data on finger-up). An interface for selecting the resolution of the spinner is shown in the lower right.
When graphing text, we display small colored bars at the bottom of the screen that change color when the text changes. While this does not convey what the text is, it conveys that it has changed, which may still be useful. We use a hashing strategy to display colors, so that the same text will always have the same color.
