Practitioners Look At SmartWatches

Not a week goes by without seeing an article about a new SmartWatch or some discussion about the future of wearable computing (rings, clothes, IOT, …). Having being always inspired gadgets like Dick Tracy’s watch I have always kept a fairly close eye on this space and recently decided to jump in and build something to better learn about the opportunities and constraints of building for a SmartWatch (or wearable tech in general). In this short article I’ll describe my learnings and present my opinion of some practical uses for a SmartWatch.

The watch used in my experiment was the Sony SmartWatch (first edition). Given that out of all the SmartWatches, it is probably the lowest denominator i.e. it acts more like dummy terminal than an independent device. Regardless of this it still provides a good appreciation of what a SmartWatch could be used for.

Watches uses are limited by their real-estate for input and output. Without inspecting the real constraints (discarding battery) constraints, ones imagination can run wild of how the watch can be used. Some example include: speaking into it to activate phone calls or ask questions, small casual games that you can play more discreetly than on your mobile, conversing in conversation with your friends via your chosen social network, and teleport you home. But once you start looking into the details you soon realise why the watch calculator never took off, it’s because certain functions demand more space for input and output which, obviously, the wrist watch does not have.

So what can a SmartWatch be used for; one way to look at this is by looking at what it does already – tells the time – time being a type of continuous notification or, better put, signal. Given that our environments are becoming smarter, a watch can now provide other useful signals based on your context (location, scheduled calendar, peers in proximity, etc). But even this is limited by the available bandwidth (real-estate) for the amount of information you can display and how frequently you can signal the user. One example of an signal could be a reminder to prompt you to drink another glass of water to meet your 6 glasses a day or get up and move around if you’ve been stationary too long (limited to when you work i.e. you don’t want to interrupt the user while watching a movie).

Another obvious function of a SmartWatch is to be used as a monitor/logger i.e. replicate the functionality of devices like Nike+ to monitor and log your activity during the day. The SmartWatch has the advantage of being a multi-purpose therefore more likely to be used than single purpose units.

Another form of input that may get some traction is using it as a key either to unlock or pair to other devices (e.g. activate payments, unlock car/house doors, pair with public displays/computers). It have the advantage of being more accessible than your phone, especially if you’re balancing groceries in your hands, and being attached has added security.

The experiment I created was to use it as an input mechanism for another device – the idea was that the watch could be taught gestures, once these taught gestures were detected the watch would broadcast to trigger set actions. Imagine that you’re watch TV and wanted to pause it, waving your hand up and down (trained gesture) would broadcast a ‘pause’ command to nearby paired/selected devices.

My experiment used the Sony Smart-Extension API (a subset of their Add-on SDK) – which is a SDK to (currently) build for their SmartWatch and Headset. It is broken down into 4 components, each focusing on a specific role of your extension. These are:

  • Requirements and Capabilities register; essentially the hub for their extensions that allows devices to register themselves when paired.

  • Notifications e.g. notify users of an incoming call.

  • Widgets; floating window presenting some detailed information

  • Controls; provides you with the greatest control, allowing you to take over the whole screen and functionality (touches etc).

  • Sensors; Accelerometer, light.

As a developer, you create extensions that are managed by a host app on your phone. The managers responsible for matching your requirements with the capabilities of the devices and then installing and running your extension on a capable device i.e. you don’t ask for a SmartWatch but rather register the features (capabilities) you you need and the appropriate device(s) will be returned.

The application I created has 3 modes – idle which does nothing, training, and classifying. As you would suspect, training and classifying use the same mechanic to compose the gesture and register it for either training or classification (i.e. comparing it to the set of training data previously collected).

Gestures are made up of a set of accelerations, i.e. set of acceleration readings, each reading must be significant (i.e. we normalise the acceleration as we are only concerned with the direction, each subsequent reading must have a significantly different direction than the previous). A sample is registered (either for training or classification) when it has recorded n values and their has been little acceleration for a fixed length of time.

In the training mode this sample is added to the training set, in the classification mode the sample is compared with all the samples in your training set. The closest match is broadcasted i.e. our ‘trigger’.

Comparison is done by calculating the distance between 2 samples using an Algorithm called Dynamic Time Warping (used to measure the similarities between 2 samples that may vary in speed and time, originally created for analysing speech). Once we have calculated this distance on all trained sets – we return the one with the lowest distance as the recognized gesture.

Code available on Github

Might have to squint your eyes to see the gestures working.