What’s Next for Wearable Tech

The news out of CES last week highlights the growing profusion of wearable devices: smartwatches are the most widespread, but there are also smart glasses, earphones, bracelets, rings, and more. It’s a real “wild west” time for these devices; nobody really knows where they’re going, or what the best use cases are.

For developers, the situation is especially acute, because essentially every device is siloed right now. If you have a good idea for a wearable app, you need to write it for Pebble, rewrite it for sony_sw2Sony’s Smartwatch, again for Google Glass, and so on. It’s true whether you’re building primarily for the device itself, or even just trying to interface your existing phone app with a wearable display: each device has its own little ecosystem. Some of the more shortsighted manufacturers haven’t even opened up their devices to outside devs (I’m looking at you, Samsung).

It’s not dissimilar to the state of the phone business circa 2005. Most phones of the time supported apps, and there were even a few smartphones around, but they were all siloed in this same kind of way. If you wanted to deploy a phone app to a good-sized audience, you had to write it for Blackberry, then rewrite it for Windows Mobile, JavaME… and don’t get me started on Symbian, where Nokia couldn’t even maintain compatibility within their own product line. It was a mess.

Even within each of these platforms, there wasn’t a good, low-friction way for devs to sell and deploy their wares. The different silos may or may not have had “stores”, but those that did were all pretty small, and app discoverability and monetization was a real challenge. And again, this is mirrored in the current state of wearables: Sony’s Smartwatch pairs with Android phones, so they’ve piggybacked off the Google Play store. Pebble, on the other hand, is just opening a store of its own. Glass has a small selection of officially-sanctioned apps curated by Google, but it’s far from easy to break into, and (as of right now) you can’t charge for your apps there. And so on… it’s a mess.

The first thing that changed in the phone business, of course, was the introduction of the iPhone. Apple was the first vendor to really nail it, not just the device, but the app store too. And for the devs, it was a veritable gold rush. This is one route that the wearables market could take: one vendor could “get it right”, have a device that’s a breakaway success, and build a big enough silo to be self-sustaining. You get a definite sense that most of the current players are hoping for this kind of outcome, but don’t know how to get there.

But there’s another route, one that we’ve seen before in the phone business. I’m talking about Android, of course: although it was released over a year after the iPhone, and took another couple of years to really pick up speed, it’s become the dominant ecosystem in mobile. And it has done it in large part by not being siloed to a single vendor; its openness has unified the vast majority of phones and tablets onto a single platform. The wearables market doesn’t just need something like Android to unify it, it needs Android. And essentially all the pieces are already in place, if you know where to look…

To start with, Google already has one of the leading wearables – Glass – and it’s running full Android on board. Google has also bought one of the pioneers of the modern smartwatch era – WIMM Labs – and rumors about a forthcoming “Google Watch” have been rampant for a couple of years now. It’s not really a secret that Google is moving into wearables, but I’ve seen little analysis about the bigger picture of that move – not just about Google selling a smartwatch or Glass to the general public, but about the broader ecosystem play. So here’s how I see that playing out.

Sometime this year – most likely at I/O – Google will take the wraps off Android 5.0, let’s call it Licorice. Licorice will give Android full, native, first-party support for wearables, in much the same way that Honeycomb brought first-party tablet support to what had previously just been a phone OS. [Sure, there were Android tablets pre-Honeycomb, but they were half-baked, not-overly-successful forays into unsupported territory. Remember the original 7″ Galaxy Tab, back in 2010? That’s what the Galaxy Gear is now.]

The wearable support features introduced in Licorice will include:

  • A new screen size bucket, for screens less than 2″ in size, which will extend the lower end of the existing small-normal-large-xlarge Android screen size range. Alternatively, Google could extend their newer minimum-width-and-height resource selectors with maximum-width-and-height descriptors, but that seems clumsier to me.
  • A set of new UI conventions and development paradigms appropriate for small, glanceable displays without keyboards. Want to see a preview? Look at the Glass Development Kit (GDK) introduced last month. It’s all there, and most of it would work equally well on most any wearable, not just on Glass.
  • New low-power optimizations, quite likely in cooperation with one of the major ARM vendors. This actually already started with support for Bluetooth LE in Android 4.3.
  • Wearable-specific extensions to the Play app store, analogous to the improved tablet support that Google brought to Play in 2013.

The point here, of course, is to extend the Android phone-and-tablet ecosystem to include wearables as first-class citizens. And this will enable a whole new generation of Android wearable hardware. Glass is the forerunner, but for everyone speculating about of “the public release of Glass” or “the Google watch”… you’re thinking too small. We need to be thinking about a whole range of such devices, from a variety of manufacturers. Some will bear the Google name, but certainly not all.

I expect that the first of these devices (after the current Glass XE) will arrive at the same time as Licorice, probably also with announcements at I/O. We’re getting further into speculative territory here, but I think we can make a good conjecture from Google’s past hardware ventures – essentially, projecting Google’s known hardware tendencies into the this next realm. There are some definite patterns to the hardware Google has used to introduce other new ventures – phones, tablets, and laptops (Chromebooks) – that will likely also apply to wearables.

  1. The pioneer hardware, designed and built with Google’s close supervision, defines Google’s role in a new space. This is essentially a public hardware beta, whether or not it’s openly acknowledged as such, and is usually a bit clunky and prone to widespread criticism as “an unfinished device, for early adopters only”. Well duh.
    • Phone: G1
    • Tablet: Moto XOOM
    • Chromebook: Cr-48
    • Wearable: Glass XE
  2. The second wave is populated by other OEMs, producing variations on the original hardware, more or less independent but still running Google’s OS. This crop of devices begins the move into the mainstream, and historically, has included the early Android and ChromeOS devices from all the major manufacturers.
  3. After a year or two of this, Google weighs in again, producing a device that “sets the standard” for where the big G thinks the ecosystem should be going. The Nexus One, Nexus 7, and Chromebook Pixel all fit this description.
  4. Everyone iterates, of course, Google and OEM alike.

The first thing to notice in the Android wearable space is that we’re still in phase 1 of this progression. Glass is the only official-Android wearable device we have so far, and the Explorer program is nothing if not a public beta – we’ve got a long way to go. I think Google’s Web DNA includes a strong “release early” tendency, and that applies to hardware too.

And if other Android wearables follow the same sort of pattern, then they’re even further behind. The first “Google watch” we see is likely to be a hardware beta comparable to the G1 or Cr-48: clunky, unpolished, with just a glimmer of its true potential. As I said, it’ll probably be announced at I/O 2014 – hell, it’ll probably be given away to attendees – but don’t expect it to be an instant game-changer. Google plays a longer game than that, and wants you to be a part of the process.

Ready for another gold rush?

AFTERWORD: What about Apple?

Apple doesn’t play the same game as Google, of course, but the introduction of the iWatch is at least as eagerly anticipated. The thing is, Apple thinks different: it develops its hardware in strict secrecy, and doesn’t release until it’s been polished within an inch of its life. Compare the G1 to the original iPhone, the XOOM to the iPad, the CR-48 to the Macbook Air. A Nexus or Pixel can go toe-to-toe with its Cupertino counterpart, but that’s only after a couple of years of public hardware iteration.

The point being, Apple won’t release an iWatch until it’s good and ready. Could be anytime, could be years down the road.

The other thing about Apple is that it doesn’t tend to join a rough-and-tumble, free-for-all market like wearables are in right now. It tends to let other companies make the early mistakes, learn from them, then release a product that overcomes the widespread issues affecting the first generation. If this pattern holds, Apple might not release its iWatch for some time yet. You can bet they’re watching the space closely, though, and refining their own plans all along.

The API of Unintended Consequences

A change to the Android API that arrived in the KitKat is that alarms don’t necessarily arrive when your code requested them to. From the docs:

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; seesetWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.
Now, many apps won’t be especially bothered, but I have two apps with clock widgets that rely on the alarms being delivered exactly on time; otherwise, the clock widget is wrong until the alarm does get delivered. Which means that my widgets now need to use setExact() rather than just set().

Which is fine as far as it goes – but what’s not mentioned above is that there is no setExactRepeating(). Here’s another extract from that same page:

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whosetargetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.”

This means that my widgets must now reschedule their alarms every minute. Which means my widgets are now running more code every minute than they were before. Which means that my widgets are now using more battery than they were before – exactly the opposite of Google’s stated intent with this change.

Footnote #1: I should also mention that, in my testing, these inexact alarms occur on KitKat devices even if targetSdkVersion is set to 18. That’s not what the docs (quoted above) say, but that’s how it works on my Nexus 7.

Footnote #2: No, I can’t use AnalogClock and Chronometer to avoid these alarms (and use less battery). They’re too limited for my widgets. My analog clocks are 24-hour (the AnalogClock class is 12-hour only), and the Chronometer class really isn’t suitable for digital clocks.

Resistor Decoder

An app like Barcode Scanner but for resistor color codes: Using the camera (and probably requiring the flash), read the color bars off a resistor and output the resistance value.

I have little doubt that it’s possible, but at the same time, it’s probably a nontrivial problem in image processing and pattern matching. And, beyond its niftiness factor, it’s not something that very many people would pay for. So, not worth the effort, unfortunately.

It’s more the sort of thing that some geeky Googler should do in his 20% time. Or, some random geek with more time on his hands than me.

Meta Cloud Drive

After seeing yet another “sign up for our new cloud drive, get 20GB free” offer, it dawned on me: could you make a “meta” cloud drive that works purely by piggybacking off others?

The idea is that the MCD would have interfaces to loads of “normal” cloud drives, and would manage your storage appropriately. So if you had 5 or 10 GB from each of Dropbox, Box.com, GDrive, iDrive, SkyDrive, Copy.com, Wuala, and so on, you could easily end up with a couple hundred gigabytes. Then your MCD would bring them all together, managing them as a single virtual drive, so you don’t have to worry about what’s actually stored where.

If you had enough space, it could even incorporate RAID-like functionality: replicate individual files across multiple cloud services so that, if one is unreachable, you wouldn’t lose your data.

Ideally, it’d also manage your accounts with the different services. If you had existing accounts you would go ahead and enter those credentials, but I’d like to see it automate the sign up process for others. IOW, you open an MCD account, and can then automatically sign up with 10 services behind the scenes. We might even be able to do something crafty with referral bonuses behind the scenes to leverage extra storage for our users.

Travel Weather

This idea was inspired by WUnderground’s Road Trip weather, but I envision something much more configurable, useful. Basically, to be able to set dates (and optionally, times) for a list of locations and see the current weather forecast for each time/date combination. Obviously, it would update with new forecasts as time passes.

It could be standalone (enter your itinerary manually), but would be better if it integrated with something like TripIt. It’d also be nice if you could enter endpoints for driving directions (for a multi-day road trip) and build from that.

FAD Followup

…where FAD stands for Free App of the Day, the Amazon Appstore’s program where they offer a different paid Android app free to customers every day.

This is a followup post to my original FAD thoughts, posted shortly after I had my first app in the program. Exact download numbers are Amazon-confidential, but suffice it to say that Moon Phase Pro got hundreds of thousands of downloads that day, which significantly boosted its visibility in the Appstore and led to a marked increase in paid revenue for weeks afterward. A good deal all around.

Some months later, Amazon offered me another FAD spot for another app, PolyClock – and since my first experience had been quite positive, I didn’t hesitate. This time things didn’t go nearly as well; the total downloads were much lower, and there wasn’t a significant sales boost after the day. I simply chalked it up to the app in question being more niche-oriented, with a narrower appeal. And since there really wasn’t a downside, I didn’t worry much about it.

Then came my third app in the Program, Convertor Pro, after Amazon extended FAD to their European markets. And unfortunately, I have to say that this was a downright disaster. Again, I can’t reveal exact sales numbers, but since around Christmastime Convertor Pro has been selling reasonably well in the UK; it’d been hovering in the top 5 in its category. Not paying for my retirement, perhaps, but a respectable earner.

Then came its FAD spot – and sales immediately plummeted, to a small fraction of what they’d been before. It’s been about ten days now, and its ranking in category is currently around #15 and still dropping.

Of course, I have no proof that FAD was responsible for the drop, but when you look at a graph of its ranking over time, the correlation is hard to deny:
image
That green bar there is its free day. (The numbers below are its ranking on a given day before FAD.)

So in summary, I’m nowhere near as impressed with FAD as I was a year ago. Perhaps it still makes sense for some apps – but my advice right now is: if your app is already earning any kind of money in Amazon’s Appstore, don’t risk it.

First-Person Minesweeper

That’s it, in a nutshell… Reorient the classic Minesweeper from top-down to first-person. It’d be surprising if nobody has done it before, but I don’t think that I have seen it. My vision is for it to have a maze/dungeon appearance, where the game play involves knocking down walls as the metaphor for clearing cells.

Not clear how you’d get “past” flagged cells… Maybe a 3D aspect?

Working title: Sweepminer