It is not a rare case, when we have the display with HMI or more conventional GUI, but we are not able to manipulate it by using traditional input means: keyboard, mouse, trackball or touch-screen. It can be because of environmental conditions, for instance if the unit is to be used outside, so rain may affect touch screen usage (like the sailboat display that is located in the cockpit), or if there is no space for separate keyboard and or mouse, or it is the price limitation. But the unit is complex enough, with settings, multiple “pages”, lists of entities with corresponding cards and so on, so the HMI tends to be closer to the user interfaces of mobile devices or tablets.
So, with these inputs, we need a set of physical controls, that will replace as much as possible the keyboard and/or the pointer devices.
Minimum usable set
Here is a recommended minimum set of controls from my experience of making and using such devices, that makes the UX relatively comfortable and supporting more or less automatic, reflexive interaction with the system:
- Confirmation button
- Arrow keys
- Home button
- Back/Cancel button
- Context menu button
- Rotary encoder for entering numbers or symbols
Of course, we can sacrifice some of the controls, like encoder or context menu, but for complex HMIs similar to car infotainment systems, it will significantly reduce the quality of microinteractions, especially in some critical edge cases like map objects interaction and so on.
Confirmation button
The most frequently used button that confirms the action, moves to the next step, changes the state of radio button or checkbox, etc. Basically, it is the same, as the default left mouse button (for right-handed people) or Enter key of the keyboard.
Arrow keys
Up, down, left and right arrow keys are four buttons that allow movement of screen cursor or focus (selection) rectangle of the UI. The screen cursor behavior is straightforward: the buttons just move it in the corresponding direction. But with the selection rectangle it is a bit similar to Tab or Shift+Tab behavior, but it works in two dimensions.
Home button
This button is the default control to go to initial state of the system, regardless of whether it is the main dashboard or a menu. It is needed to interrupt any use case and easily start interaction from scratch, from starting point, instead of pressing multiple times physical back or digital cancel buttons, especially if the user is deep in the system’s pages hierarchy.
Back/Cancel button
In contrast to the Home button, this button is used to return the user one step back in the UIs hierarchy. We all know it in the Android, and poor implementation of back behavior is subject for permanent criticism of iOS platform. It is default action if the information is received and we want to go back, or if the user has selected the wrong item in the menu. Back/Cancel button is very close to the undo action, but in terms of navigation and more major interaction patterns, so it is crucial to support it.
Context menu button
Less critical button, but still valid, if the UI is complex and context dependent. It allows to get the list of contextual actions for any focused item (or the current view), while the left button is reserved for primary action. Same as the right mouse button for right-handed users.
Rotary encoder
The Rotary encoder is the simplest control for more or less convenient input of numeric and even alphanumeric data — it is much easier to operate it than to use arrow buttons for increments/decrements of the selected value. Also with some additional support from development it can be used for short textual data entry, similar to numeric input.
Without encoder arrow buttons may still provide functionality for data input, but clicking multiple times just to move from “a” to “y” symbol, or from “000” to “180” (let’s say for vessel’s course) will be significantly harder.
Also rotary encoder is very convenient for mouse wheel functionality, as another support of arrow buttons — to scroll the list of items, to change the scale of the map and so on. This behavior logic is to be defined in a consistent manner across all the embedded HMI.
Modifications
As it was mentioned above, we can get rid of rotary encoder or context menu button, and in some cases remove some other buttons, but it will reduce the usability of the product. Nevertheless, we may consider other modifications, that keep the same set of “features” (Cancel, Home, OK, etc.), but provide other controls.
First of all, we can replace arrows with simple joystick, that may provide extra opportunities to change the area of focus. For instance, some maritime chartplotters for the outdoor usage keep the idiom of “mouse cursor” (or crosshair, that is very similar to it), but its position is adjusted by joystick, not a trackball. It is some compromise to keep the precise pointing functionality for nautical chart (map), but without more convenient mouse or trackball, that are hard or impossible to use in the limited and open space of boat’s cockpit.
Most of the industrial joysticks also have the click functionality, so we can get read of confirmation button.
Moreover, more expensive models of joysticks also have a rotary encoder, so we can combine six tasks (four directions, confirmations and alphanumeric input) in one hardware control. But accidental joystick tilts while rotating the encoder may cause the focus to shift away from the intended control element, so it requires more testing and adjustment of joystick stiffness (for instance, by selecting specific model), and it is not always possible.