UI and UX design for OpenROV Cockpit


#1

So we've been thinking a lot recently about UI and UX (User Interface and User Experience) for OpenROV, and it seems like there is a lot that can be done in this realm. OpenROV Cockpit is the way we relate with the ROV- it's our connection to what the ROV is seeing, how it is doing, and where it is.


This is an obviously overcrowded mock-up of a possible OpenROV Cockpit screen, but it shows how a bunch of various widgets could be configured.
Lately, I've been brainstorming ideas and trying to put together a mock-up of what my ideal OpenROV Cockpit might look like. I expect that everyone's ideal cockpit would be a bit different (and situations may call for different looking cockpits even for the same user), but I wanted to post the mockup I made for myself and see what the ideal OpenROV cockpit would look like for other people. This is certainly the kind of thing where there is no right answer- just different preferences.
Here's a little about my design:
There were several driving forces behind the appearance of my ideal OpenROV Cockpit.
1. Dark Background
I like having a dark background because it allows maximum contrast to be given to things shown on the screen but allows you to keep fairly good night vision when piloting in dark places. I used shades of a color for the contrasting figures as opposed to just varying brightness of grey, because it gave me more comparative options. I could have used shades of red instead of blue since the red light is less damaging to night vision, but I figured that the difference with such sparse features compared to how much light would be coming from whatever video image there is would be negligible, and frankly blue fits with the color theme of OpenROV and looks cooler. I do think adding some more colors to the pallet would make things look better, and I can picture using reds (or more likely dark oranges) to indicate values that are cause for attention (such as a temperature getting to high or a voltage getting to low). I got a lot of inspiration from one or two shots of the pretty pretty user consuls in the movie, Oblivion.
2. Form Follows Function
Superfluous features and "stylistic" objects that serve no purpose bother me to no end. That's not to say that making something look clean or consistent with its surroundings is a bad thing, but if there is no method to a theme, then in my opinion it should be done away with. I chose four shades of blue (let's call them "1", "2", "3", and "4" in order from darkest to lightest) and for the most part stuck with a theme of "1" for borders and boundaries, "2" for reference points, boundaries of value outputs, and incidental labels, "3" for primary labels , and "4" for values and plots. Boundaries have curved corners so that it is more clear which lines go to which boxes, and lines are used to underscore primary labels to help distinguish them from values.
3. Modularity
Depending on context, different displays may be needed at different times. Just as a combo TV, DVD, VCR, Radio set becomes blatantly unfitting once any part of it stops working or is made obsolete, being committed to data displays that are irreverent is frustrating and distracting. Additionally, it's very nice to be able to add displays for new devises without having to make edits to a single system that you might already have. What I think would be really cool, is if displays could be designed as widgets by various people, and a user could simply download the ones they like and insert them into their own Cockpit display. Perhaps hardware such as sensors could even come with widgets... Anyway, all this is food for thought now, but it seems like there is a lot of potential here.
4. Lots of Plots
In my own experience, I've found that how things are changing is often just as, if not more valuable to know then what the current state things are. Because plots tend to take up a fair amount of real-estate, and trends upward or downward with out exacting values are sufficient for the most part, I made most plots pretty basic with a min an max value for y-axis reference, and standardized the time increment (which could be adjusted, but in this case is 30 seconds per tick) to all plots in a given section.
For plots where the specific values are important, I used more space and labeled things more frequently.

5. Corner-of-Eye-usable displays
This is a concept I think I could have done better with in this mock up, but at least I gave it a shot. From my own experience, readouts that you don't have to look directly at (so you can keep your eye on the video feed) are very handy. This can be achieved in a variety of ways. I used "ribbon" displays for depth and heading (in addition to the numerical readouts) which give you a sense of relative moment peripherally, and I also used arrows that would light up in different places to indicate the direction of vertical movement. (Yes these are redundant for depth, but I'm just playing around here). The ultimate don't-take-your-eye-off-the-ball telemetry readout would obviously be a heads-up display like what Brian Adams has been working on, but I didn't feel like addressing that with this mock-up. In general, it might be nice to have more dials and displays with more graphical (as opposed to numerical) outputs for other telemetry, but this was a start.

There is also one huge thing missing from all of this: input features. I definitely think that clicking on things with a mouse is a pretty bad way of sending commands when your out in the field ( your hands may be busy controlling joysticks, there may be glare that impedes seeing where your mouse is, etc), but certainly this can be explored. The growing popularity of touch-sensitive screens is very likely to have an influence on things, but in the mean time, dynamically mapping gamepad buttons and keyboard keys to different functions, and displaying what those mappings are on the screen might be the ticket.
What excites me the most is the idea of many people contributing pieces of the OpenROV cockpit, and users being able to adopt things that are useful. As I mentioned in the beginning of this blog, I don't think there is any "right answer" to UI and UX, but allowing people to choose what suits their needs best is a great way to progressively make interacting with the ROV better.
What is it you'd like to see in a UI for OpenROV?

#2

Matt says on Facebook:

"If it looks that cool you are going to need torpedos."


#3

I like it! My one request is that there be a section that allows the user to easily reconfigure the controller. I'd like to be able to change what keys are bound to a particular action.


#4

Marcus was working on an OpenROV Auto Pilot which I think could be very useful to hold the ROV on a compass heading or even better at a depth setting. this would be a nice feature in the cockpit.


#5

The total current draw graph should be bigger than the sub-graphs, but aside from that, the cockpit looks pretty good. Does the current prototype/design of the electronics board have current sensing for every channel or is that still up in the air?

As for the compass/gyro inputs, pololu has a nice selection of stuff depending on how much information is needed, or we could spin out our own sensors. I'm not sure how well they'd work with high current stuff, but it's a start.

I think an incredibly important part of the cockpit will be its versatility depending on screen size. There are netbooks still using 1024x600 screen resolutions as well as a majority of common laptops using 1366x768 or older 16:10 and 5:4 ratios. The cockpit design must be able to be edited to work with those. For instance, the preview screen earlier in your post isn't very wide, which would hinder those who have widescreens. To accommodate for them, the video feed could take up the center of the screen from top to bottom while everything else fills up the edges.

How is this cockpit going to be shown? Still sticking with the current CSS and javascript, or moving on to something different?