We love mobile devices because they provide us with a lot of convenience. If you need to read your email, view the weather forecast, or check current driving conditions, you don’t need to be in front of a computer; all of that information is available on a device that fits in your pocket.
Wearable devices take this convenience to a new level – you don’t even need to pull your phone out of your pocket. If you are the developer of an Android application (or are considering creating one), you may want to consider extending your app for wearable devices, to provide the best possible experience for your users. Android Wear is the version of Google’s Android operating system that runs on wearable devices.
It is important to understand that a wearable app should not attempt to duplicate the functionality of your mobile application. There are many things that work great for a phone or tablet, but would make a poor user experience on a watch. Also, since an Android wearable device needs to be paired with a handheld device, the user of your wearable app will always have a handheld device nearby. This means that your wearable app can focus on tasks that work well on wearable devices (things that are quick and simple), knowing that the full mobile app is available nearby should the user require it.
What should a wearable app look like? Here are some guidelines from Google:
- It should be glanceable. The information provided should only need a quick look to be understood.
- It should attempt to offer information automatically when it is relevant; the user should not be required to request it.
- It should require only short interactions. The app should focus on tasks that can be accomplished quickly by the user, such as clicking a confirmation, or selecting an item from a short list. Tasks that require a lot of interaction are best left to the handheld device.
When considering how to build a wearable app, I have found it helpful to think of the wearable app as an extension of the mobile app. Try asking these questions:
- What information from my mobile app do I need most frequently?
- Is there any information the app could automatically present to the user based on circumstances (e.g. location or time of day)?
- Are there tasks that I do frequently that are simple enough to be done on a wearable device?
I found these questions relevant regarding the Intertech Time Entry mobile application. If I forget to enter my time, there are consequences. Wouldn’t it be nice to receive a reminder at the end of the week, if I have not yet entered time? Furthermore, sometimes my time entries are simply a copy of the previous week. Maybe it would be nice to simply click a button on my watch, and have my entries from last week copied to this week. Even better, I can combine the two: at the end of the week, if I have not entered any time, my watch can remind me to do so and present the option to copy entries from the previous week.
This is a great opportunity for a wearable app, to make our mobile app even better. In this Android Wear developer tutorial, I am going to walk through how I extended our Time Entry Android app for wearable devices.
- Note: for the purpose this tutorial, when I say wearable devices I am referring to smart watches that run Android Wear
Android Wear UI Overview
In the Android Wear UI model, two key concepts are Suggest and Demand. Suggest is exactly what I am talking about above by extending Time Entry: to proactively provide information and actions that are both relevant and convenient. Suggest is implemented by the Context Stream. According to Google: “The context stream is a vertical list of cards, each showing a useful or timely piece of information.” Ok, so what is a Card? A Card is similar to a notification on a handheld mobile device, and you may find it helpful to think of a card as an extended notification. Adding a card to the context stream is similar to creating a notification on a handheld device.
However, in Android Wear these cards play a much more prominent role. The cards in the context stream are the primary way in which the user interacts with the wearable device, by scrolling vertically through the list of current cards. Cards can also contain actions and additional pages of information, accessible by swiping horizontally from the context stream. Furthermore, the appearance of cards is fully customizable. It is very simple to create a default card with a background, app icon, text, and title. But if this does not suit your needs, you can create a custom layout and use that instead of a default card.
Demand is implemented via the Cue Card, opened by saying, “OK Google” or by tapping on the background of the home screen. From the Cue Card, the user can speak a command or swipe up to select from a list of suggested commands. Using Demand, a user can request information at times when it is not automatically provided via Suggest.
Take a look at the rest of the parts in this series: