We'll respond shortly.
A few weeks ago, Google announced Android Wear – a development platform for extending Android to wearable technologies. This is an effort by Google to stay up-to-date with current trends over the past year which have seen the rise of wearable technologies such as the Pebble, JawboneUP, FitBit, etc. Keeping true with Google’s mantra, they have open-sourced the SDK for developers. The success of Android Wear really depends on the applications made by the developers using this SDK. Google’s aim is to leave it for the developers to figure out what they can do with this SDK and with the new UI guidelines, as well as how traditional smartwatch app concepts (fitness tracking, email and location services, etc.) will be put to use in a wearable Android environment.
While Wear may be adapted to different wearable devices, Google is currently focusing only on smartwatches. Traditional Android OEM partners such as Motorola, Samsung, LG, HTC and ASUS have already signed up. Almost all of the hype for Android Wear has been generated via the 2 launch devices:
LG G Watch: The first smartwatch to have the WearOS
The smartwatches will support features such as Google Now and a rich notifications system. Since the screen sizes are small, there is not much real-estate, and the Google Now cue cards system seems to be perfect for that. Additionally, like the MotoX, the Moto360 may take advantage of user gestures (e.g. twisting a wrist will show an alert for the next calendar event).
As for other devices, Google is already working with several consumer electronics manufacturers, including Asus, HTC, LG, and chip makers like Intel and Qualcomm, as well as fashion brands like the Fossil Group.
The Android Wear UI will have 2 main fragments centred around the core functions of ‘Suggest’ and ‘Demand’. The ‘Suggest’ function is a context stream of vertical cards that show useful pieces of information tailored to user specifications. Navigation is done by swiping vertically with only one card displayed at a time, and background images are used to provide additional information. All in all, the features seem to extend the functionality of Google Now. The ‘Demand’ space is brought up when the context stream is not able to anticipate what the user wants to do, and opens a cue card on voice commands (“Ok Google”) or tapping on a little ‘g’ icon. Unlike Glass, the Android Wear SDK allows developers to work more with voice commands in a more customizable way by sending Android intents that trigger specific voice actions in their applications.
Apart from its features, Moto360 also introduces a unique element to smartwatches – a circular design and UI. The Motorola blog boasts it as a watch that looks and feels great and gives you the information you need, when you need it. Considering Google is highly particular about developers making apps that follows strict UI guidelines, one of the more interesting aspects is to see what developers can do with the new circular design and get creative with the Android UI in a smartwatch context. This includes how they can make use of some use-cases that may appeal to consumers who like traditional smartwatches.
The circular UI demands maximum information to be conveyed in a flat, clear manner – demanding zero-to-low user interaction and contextual awareness. One comment by Lior Ron, VP of Product Management at Motorola states “….there’s something efficient, useful, and easy-to-glance-at in that round face; to take one look and get a 360. That circular shape allows you to convey that information.”
All in all, Android Wear design principles are substantially thorough enough to demand a separate blog article of its own, but it is definitely the most exciting part of the new Android Wear smartwatches.
Google has introduced a developer preview of its Wear SDK. The SDK allows notifications and voice commands, but developers can extend these features by customizing their app notifications for the smartwatches. Google wants developers to focus on making applications that are helpful at a glance and contextually smart – to display the right information at the right time while being aware of the situation and state. It also seems like Google doesn’t want developers to make full-fledged applications using the SDK, but rather just make use of APIs like Activity Detection to extend and enhance a regular smartphone app’s notifications with the Wear’s voice actions and special notification pages.
Some of the drawbacks the community has outlined include:
Fragmentation: The modular, open-source nature of Android makes development for Wear complicated because the developers will have to make/tailor applications for different designs and functionalities. Developers may just choose to support one platform over another with reasons being manufacturer preference, or even just design preference – a circular UI has less screen real estate than the traditional rectangular UI, and an app making creative use of the circular design will look weird and out-of-place with other layouts. This problem is not new to Android developers of course, and Google will have fleshed out the Wear SDK enough to make multi-device support a small burden to bear.
Battery Life: Smartwatches have always had to deal with the hubris of battery life. With the rich UI and action-intensive Google Now feel of Wear smartwatches, it’ll be interesting to see how that issue is dealt with. Some ways may include long-lasting batteries, or making it easier to top up charge while on the move, or even some combination of both. The MotoX was power-optimized, and Motorola has plans to optimize power consumption in a similar manner for the 360.
It is exciting to see the plans Google has in store going forward for Android Wear – custom UI for cards and data transfer between phones and watches. The first of the Android Wear smartwatches are scheduled to arrive this Summer, and by the looks of the positive reaction by the community, will certainly give the other wearables technologies some stiff competition.