Developing for Google Glass

UPDATE: On July, 1st, 2013 Google released XE7 update to Google Glass supporting a web browser. You can read the post about HTML5 support on the browser.

The new screen #

A mobile experience is not a smaller version of a desktop app or website. And a Google Glass app is not a mobile app or website on a transparent background.

If you have a mobile website or a mobile app and you want to support Google Glass, you need to sit down and understand how the device works and what users will expect from an app on it. BTW, a Google Glass app is known as Glassware.

Google Glass is not a mobile replacement; it’s more than a companion. The Glass, not having a cellular connection, needs a phone companion or WiFi to access its heart: the Google cloud. For example, geolocation is provided only if the Glass is paired with an Android 4.x phone.

Important ideas #

• Users don’t browse the web on Glass (well, they can ask questions to Google but there is no API for that yet) UPDATE 1/7/13: A web browser is now available. Check post.
• Users don’t install apps yet, they authorize just Glassware to communicate with the device as we authorize a website/app to access our Facebook/Google+ account
• We need to let the user decide when to access your services and data, we should not force the user to read what we have to say
• Create an specific and optimized architecture for Google Glass
• While everybody thinks on Glass with AR (Augmented Reality), today the device is not offering AR features apart from Map Directions. We can send contextual information, images and videos to user’s device but we will not augment the reality on user’s vision today.
• It’s not a mobile replacement; it’s not a desktop replacement. It’s a new and different kind of device.

Device specs #

The first Google Glass device has a high-resolution nHD display 640×360 (one ninth of a full HD) equivalent of a 25″ HD screen from 2.5 meters or 8 feet away. It has a 5MP camera, a bone conduction transducer for audio (that means you don’t need to put earpieces for listening), accelerometer, a touch lateral panel, Bluetooth and WiFi. Check more about technical specs.

native vs. web? #

Glassware can be developed today only by using RESTful HTTP services. There is no native development or offline apps. UPDATE 29/5/13: At Google IO 2013, a GDK (Google Development Kit) was announced and it will allow native Glass app development for offline and full sensor access on the device. These apps will coexist with Glassware and its UI and interaction is not yet known.

Everything on Glass runs over the cloud and if we want to develop Glassware we have to use a server-side platform, such as Java, PHP, Node.JS or Python.

• No Java native development yet (GDK will be available later)
• No C++ native development announced
• No HTML5 development (but it supports HTML5 content, later on this)
• No Flash development; just joking here… ;)

A user “installs” a Googleware from our website. Using OAuth 2.0 we will get permission to user’s Glass device that is attached to his/her Google account. Once we have been granted permission, we can now communicate bi-directional with the device through the Google cloud using the Mirror API, an HTTP RESTful-based API. More on how to start using it today, later on this post.

We authorize Googleware to access our Glass device through a website using OAuth 2.0

Cards as the main interface #

The base of Glass interaction is the card. A card is a piece of content that appears on the Timeline (kind of a Glass’ homepage) when you wake up your Glass using your voice saying ‘ok glass’ or the touch panel. The user can flip between the available cards using the touch panel.

Cards contain information pushed to the device from our servers and this is the most important change from a mobile pushing mechanism: it’s probable that our card will never be seen by the user. And that’s ok. It’s not like a mobile push notification. We push, update and delete cards from our server as many times as we need just for being there with refreshed data if the user thinks it’s time to see the timeline. Therefore, it’s possible that we are pulling a card before the user can really see it because the data became obsolete.

Card will be shown as a timeline (newer to older) but they can be also pinned, so they will always appear on the same place (remember, we can update cards’ content anytime).

Interaction with cards #

A card can have menu items attached to a contextual menu tapping on the card so the user can interact with it. Typical system actions include: share, reply, delete, read aloud and pin. These actions have system behavior from the device itself but we can also create our own custom actions. Some actions, such as share, reply or a custom menu item will trigger an HTTP request to our server with the card meta data and the action so we can make things work on our side.

Just to give an example, if we enable the “Reply” menu item action and the user fires it from our card, the user can say something and on our server we will receive an HTTP request from Google’s servers with the original card metadata, the audio file and the transcript text. Cool!

Sharing and suscriptions #

Our server can also register on the Glass to be notified of:

• a share action (so users can share other Glassware card with us)
• user’s location (so we can generate or update cards with contextual information)

In terms of sharing we can add a Contact to user’s device, a sharing destination that will appear in users share menu item. We will then receive that share action from any card through the suscription endpoint. It’s a good idea to have a web-based or mobile UI so the user can manage the Contacts that will appear on the device from our Googleware. Remember a contact is not just a person, it can be a group (such as Family) or a generic destination (such as ‘Twitter followers’ or ‘my blog’).

Multilevel cards #

Cards can also be bundled in groups, as in a folder in a mobile Home screen menu. In that case, a page curl effect will appear on the front card and the user can “enter” the bundle and then browser all the cards inside. These cards can be inserted, updated and deleted individually.

The other way is to provide one single card with different pages that will also appear similar to a bundle of different cards.

Show me, show me! #

To see all these mechanisms working on stage, I suggest you seeing the following YouTube videos:

HTML5 on Glass #

A card can be created using:

• Plain text
• Text plus media (image, video or audio)
• HTML5 content

There are several HTML5 templates already available to use that fits perfectly on Glasses’ screens and we can provide our own HTML code.

All the semantic HTML5 elements are supported, including images and tables and it’s not clear yet (I need to wait for a real device here… Google?) what happens with other type of content. Even, the CSS that Glass is using as the default user-agent stylesheet is available.

One nice thing is that apart from using our own images on <img> elements we can access the native maps system using the glass://map URI scheme. This scheme allows us to show a map with optional points and polylines.

<img src="glass://map?w=240&h=360&marker=0;42.369590,-71.107132&marker=1;42.36254,-71.08726" height="360" width="240">

Just remember:

• Follow Glass card UI Guidelines
• The user is not browsing the web, it’s just reading quickly a card
• There is no scrolling: for more details, you can provide a multi-page card or enable a “read aloud” feature that can read more text than the one available on the screen
• Don’t use any JavaScript or interactive HTML element, such as form elements
• Design for a full card of 640×360 with proper margins, using only following font sizes 30px, 34px, 40px, 50px and 70px or a special size for very short messages: 90px;

Glass emulator #

While there is no emulator available yet and devices are just being shipped only for Google Glass Explorer (did I say I’m waiting for one? ;)), we can start playing with Glassware with the “Playground“, a card viewer simulator. We can connect Playground with our OAuth client, we can use the HTML5 templates and see how they will look like on the real Glass.

Once connected to our Glassware, we can see and edit on the browser how cards look like

Go and start playing #

Google Glass requires to rethink our app or website. Don’t just offer the same services you have on the web and/or on a mobile app. Be smart, simple, accurate and deliver info at the right time without interfering with user’s life.

I can’t wait to get my hands on a real device to feel how useful it might be and to check all we can do with HTML5-based cards.

If you want to start right now playing with the Mirror API, Google is offering APIs for Java, Python, Go, PHP, .NET, Ruby and Dart. Starter Projects are available for Java and Python optimized for being executed on Google App Engine.

And remember, Glassware means just HTTP messages out and in our server-side app, so we can use any platform without using the API helpers from Google.

Official documentation: https://developers.google.com/glass

API and starter projects: https://developers.google.com/glass/downloads

Playground (card simulator): https://developers.google.com/glass/playground