Google Glass apps are easy to develop, but brutally difficult to design well

Timothy Jordan, developer advocate for Glass, takes a small stage in a large anteroom at Moscone West.

“[Glass] is a moonshot about our relationship to technology … technology that’s there when you need it and out of the way when you don’t.”

He’s selling the device, but in this crowd, there’s no need.

Currently, there’s only one way to develop apps for Glass, which Google calls “Glassware”: Using Google’s Mirror API. (Although Google itself is hosting a session on hacking Glass later today — called, appropriately enough, Voiding Your Warranty.) A more full-fledged software development kit (SDK) called the Glass Development Kit is coming, Google says, but hasn’t said when.

That means it’s relatively easy to Glassware now, but until the SDK arrives, it’s challenging to make them look good and work well with users’ expectations.

At this, the very first session for the Google Glass track at I/O, the session room seating a couple hundred developers had filled to capacity a half hour before the session started. Five minutes later, the overflow room (again seating a couple hundred devs) was also full. A hundred or so devs milled around in the hallway outside, queuing for no apparent reason and obviously miffed.

I can’t stress enough how fascinated these people are with Glass. For something that’s still a buggy, crash-prone prototype, it’s inspiring imaginations enough that I can see a nascent ecosystem growing around it long before the first consumer devices ship.

Jordan’s job for today is to guide those imaginations in the best directions. He has to explain the Glass platform and teach web and mobile developers how to design for a tiny screen with new ratios and new paradigms for user-device interaction. He’s not just teaching old dogs new tricks; he’s teaching dogs how to do Shamu’s Sea World routine.

Jordan runs through a Glass demo — how to turn it on, how to take and share a picture. As other writers have mentioned, nothing about the user experience is particularly (or even remotely) intuitive. But once (and if) you get the hang of it, Glass becomes remarkably interesting very quickly. It’s then that you realize the wonderful possibilities of technology that is literally in your face but still somehow out of the way.

So far, Google’s Mirror API is the only way to build Glassware. With the Mirror API, which we’ll talk about more later today, the developer’s service never communicates directly with Glass devices. Instead, the service “talks to” Google services, which sync with the Glass device in question. Devs can use location and subscriptions to make their services more interesting. All this happens with three common technologies: REST, JSON, and OAuth.

There’s no native API yet for accessing the hardware or working offline, but Jordan says this tool, called the Glass Development Kit, is coming soon. The company is soliciting developer wishlists for the GDK now.

Beyond the tech side, there’s the graphic design, UI, and UX. The screen size is more limited than any other modern screen, so what is presented on the display must be drop-dead simple — a photo, a video, some text, or the simplest HTML you can imagine (Google has made a few handy templates to get you started).

What you see on the Google Glass display are called “cards.” They’re more TV-shaped than phone or computer screen-shaped, but even though they’re parked right next to your eyeball, they’re a lot smaller than you might think, and designers have to work carefully to make the most of the tiny screen. Cards can be bundled, threaded, paginated. Jordan calls this ability “super powerful but tricky.”

And while Jordan doesn’t mention it aloud, we’re noticing a trend with the Glass card examples: Most of the cards contain some kind of prompt — otherwise, how will your users know what to do next? They’ve never worked with anything like this before, and they don’t know where to tap or swipe or what to say. There’s no norm yet, so you have to leave a visual breadcrumb trail throughout the entire UI. Jordan does say each prompt or menu item should be just a few characters long, with only a handful of menu items on a single card.

The technology of building for Glass is the easy part. Designing for a totally new interface is the hard part.

“We’re always thinking at Google, what’s good for the user?” says Jordan. “Really understand the design and experience of Glass,” he says, encouraging devs to do whatever they need to do to demo a Glass unit if they don’t already have one.

“The user experience is about design. It’s about making an excellent service for the user… the paradigms and patterns,” he continues. “The essential thing you must do is test Glass and use it in your daily life.” Over and over, Jordan tells the audience they need to test on Glass.

Designing for a device you know and use is Rule Zero of Glass development. The next rule is to not “get in the way.” Then, Jordan says, make sure all content is timely. Finally, he says, “Avoid the unexpected. This is particularly important on Glass … They’re wearing your service. Be honest about the intention of your application, and give them preferences to get notifications at certain times or to know what they’re going to get when they sign up.”

Facebook, Twitter, Path, Evernote, Tumblr, Elle, the New York Times, and CNN already have Glass apps out, and Jordan points to them as great examples of how to start. And of course, he recommends using Google’s own services, like Google+ and Hangouts, on Glass.

Glassware product design is the only big challenge facing developers who want to make apps for Glass. The tech is simple. The users, while few, are low-hanging fruit, willing to test just about anything you throw their way. But as hungry and fascinated as the developers at Moscone West are today, I’m sure they’ll find truly imaginative ways to work around and with Glass’s challenging interface in short order.

Image credit: Dylan Tweney/VentureBeat, Jolie O’Dell/VentureBeat