Remember what was said earlier about limiting the amount of user input because a wearable app is a beautiful flower that should be seen and not heard, yadda, yadda, yadda? Clearly at some point the user has to interact with the app. Here are some rules for designing user interaction.
Though the products have different styles of input, there are a number of common user behaviors between them. By working these behaviors into your design, you can make it much easier to port your product between different devices.
- Next/Previous Page
- Many of the Garmin activities are made up of page loops — information for the user spread across a carousel of pages. The next and previous behavior informs you that the user wants to go to the next or previous page.
- The user wants to see a context specific menu.
- The user wants to select a highlighted item.
- The start/stop button is used to begin timing/recording of an activity of some sort.
- The user wants to back out of a page on the page loop. This is often multiplexed with the lap key, which is used to allow the user to demark a marker in their workout.
- Enter Widget
- This is a new behavior specific to the widget app type.
Connect IQ provides some basic Garmin dialogs for item selection, numeric entry, and confirmation. Using these widgets for basic operations will make it much easier to port your application across Garmin devices.
- Menus let you present a list of items for the user to select from. They can be nested (a menu can launch another menu) for selection based flows. You can also use the resource compiler to define them. See the programmer’s guide for details.
- Generic Picker
- The generic picker provides applications with the ability to create onscreen lists of user-selectable objects. These objects can be numbers, strings, and even images, which allows a lot of flexibility in app design.
- Number Picker
- The number picker provides a UI for picking from a number of numeric value types. It provides an up/down/enter interface for selecting numeric values.
- Confirmation Dialog
- The confirmation dialog provides a simple yes/no dialog. This is useful when presenting a simple selection.
- Progress Dialog
- The progress dialog gives a standard wait dialog. It has two modes—one for progress where progress is measurable, the other is for showing a busyness without attaching a specific progress to it.
If your application is monitoring sensor data, you may need to present the user with information about what you are monitoring.
If the notification to be presented is pertinent to the activity, present the information full screen. For example, if the user earns a badge in your game, this should be presented as a full screen page that times out back into your page flow.