Android Developers Blog
The latest Android and Google Play news for app and game developers.
🔍
Platform Android Studio Google Play Jetpack Kotlin Docs News

25 août 2017

How to improve app design for Wear 2.0


Link copied to clipboard
Posted by Steven Tepper, App Quality Consultant, Google Play

Wear 2.0 launched back in February with added support for new hardware features in addition to adopting new Material Design themes, guidelines, and a simpler vertical UI pattern. It also introduces a complications API, making it easier for apps to provide data to watch faces, and watch faces to incorporate external data. The final big update was that, apps targeting Wear 2.0 now have the ability to operate in a standalone mode, without needing a connection to a companion app on the phone.

There are a few design considerations in relation to navigation, notifications, the complications API, and the standalone functionality to help you better optimize for Wear 2.0 devices:

Navigation

  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent navigation: Simple navigation includes tasks such as accessing app settings, switching users or logging out. You can implement this on Wear 2.0 to switch between different views or sections of the app via a swipe down from the top of the screen, or an action drawer can be set up for context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users to navigate views quickly: A navigation drawer can be presented as either a multi-page or single-page drawer. The single-page layout is useful for when the user is expected to navigate quickly between 7 or less views of the app. Remember that if the app is using a single-page drawer, the iconography should be clear and understandable as there will not be any sort of text labeling in this layout. If there are more than 7 views to navigate to or the views are not easily represented by icons, you should instead use the multi-page drawer layout.
  3. Use multiple app launchers if your app has two or three discrete functions: For example, if your app supports both activity tracking—with various options, actions, and views—and historical analysis and management of tracked activities, you can use multiple app launchers to handle these tasks. Alternatively, if your app has a simple home screen, these features could be placed in line, at the bottom of the screen.
  4. Use peeking at the top of the action drawer to provide quick access to the primary action: If there is no primary action associated with the view, override the default behavior and force an overflow button to peek instead, exposing all actions at the bottom of a view, when tapped.

Ensure that for devices using Wear 2.0, your app takes advantage of these new UI patterns to provide a consistent user experience. Check out more training resources for Wear Navigation and Actions and the Material Design specifications for Navigation and Action Drawers.

Notifications

Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal swiping gesture to present actions for a notification. Notification actions are now presented as a single primary action (if applicable) at the bottom of a notification. If there is no primary action, expanding the notification will present options in a single, vertically scrollable view.

Notifications will work without needing many changes on both 1.x and 2.0 devices, but appear quite different:

When creating apps for Wear 2.0 devices, improve the user experience with notifications by applying the following best practices:

  1. Support expandable notifications: Use BigTextStyle so that users can see more content on their watch.
  2. Use the collapsed view of the notification (if applicable): Add the primary action for your notification to the collapsed view of the notification using setContentIntent(), where appropriate.
  3. For messaging apps, use the MessagingStyle: Provide a rich chat app-like experience in the expanded notification using this style.
  4. Update user directions which are specific to Wear 1.0: Remove any text guiding users to act on a card by swiping horizontally (the Wear 1.x pattern).
  5. Enhancing notifications to use inline actions: This allows users to do things without needing tap to see the expanded notification details. Actions for messaging notifications can use several different input methods including Smart Reply presets, voice, and keyboard input. Take advantage of these features to provide added functionality and delight users.

To learn more about adding wearable features to notifications.

Complications

The complications API in Wear 2.0 makes it much easier for watch face developers and third-party data providers to surface important information users want, at a glance. Watch faces that support the API can be configured to use any of the data providers that have been installed on the watch while maintaining complete control over their appearance. Apps supporting the complication API allow the app's data to be accessible on any watch faces that support complications. These complications can be displayed in a variety of forms (short text, icon, ranged value, long text, small image, and large image) depending on what the data provider has configured and how much space has been allocated on the watch face.

To ensure that complications fit the overall design of the watch face and properly handle their data type, when adding complication support we recommend watch face makers should:

  1. Use the TextRenderer class found in the Wear 2.0 SDK: This allows the text within complications to be adjusted to their bounds by shrinking the text, dynamically supporting line breaks or ellipsizing strings when they exceed the bounds of a text-based complication.
  2. Use the ComplicationDrawable class to set the background color, shape, border, and font options for the complications: This gives complete control of how the complication is rendered to the watch face.
  3. Design the watch face to provide a way for users to configure or adjust complications on the watch face through a settings menu: To learn how to construct these settings see the watch face sample on GitHub.
  4. Use the data provider test suite app to feed dummy data to the watch face complications: This will enable you to verify that all of the complications render properly and have fonts formatted for their bounds.
  5. As a complication data provider, expose relevant data by using the ComplicationProviderService: Simply define and configure what types of ComplicationData the app can provide for complications.

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion app installed when using the android.hardware.type.watch hardware feature flag: Using this feature enables your app to become searchable and installable directly on Wear devices without needing to install a companion phone app, so ensure your app can handle itself to avoid a confusing or broken user experience.
  2. Ensure your wearable app doesn't rely on the phone app for sign-in/authentication or primary functionality: When requiring complicated input for authentication (for example, password entry) your wearable app can point to the companion phone, but should rely on web UI for account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app in some other way, the app should use the CapabilityApi: This should be used to properly direct users to the Play Store listing on their companion device to install the missing app. Otherwise, the app should function on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.
  4. Include wording about any companion app requirements or briefly mention how your Wear app should function within the Play Store listing description: This will help set expectations and guide users to install the correct apps for the best possible experience.
  5. Incorporate the com.google.android.wearable.standalone flag in the manifest if your Wearable app can function without any phone companion interaction: This flag indicates that the wearable app can be installed and will fully function when not paired to an Android or iOS companion phone.

Though a lot was covered here, there are additional resources you can use to ensure that your apps or games are optimized and use the latest patterns and functionality on Wear. Be sure to review the quality guidelines and check out the developer training documentation to learn more best practices for wearable app development and wearable app design in order to build quality apps for Wear.

How useful did you find this blogpost?