HTML5 Zone is brought to you in partnership with:

Mobile and web 2.0 developer, consultant and speaker. Author of "Programming the Mobile Web" book, published by O'Reilly in 2010. Forum Nokia Champion. Maximiliano is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Developing for Google Glass: Mirror API, HTML5 and how to change your mind

04.18.2013
| 5560 views |
  • submit to reddit
GOOGLE-GLASS-LOGOGoogle Glass is around the corner it’s time to prepare our services for this new device type. Reading the specs for the first time can be a little overwhelming; therefore I’ll try to make a quick go through the Glass app development process, the mirror API and its HTML5 support.

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.

headline

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)
  • Users don’t install apps, 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. We can send contextual information, images and videos to user’s device but we will not augment the reality on user’s vision.
  • 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.

No native vs. web discussion

Glassware can be developed only by using RESTful HTTP services. There is no native development or offline apps. 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
  • No C++ native development
  • 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.0We 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

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

accionA 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.

cards2

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 likeOnce 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):



Published at DZone with permission of Maximiliano Firtman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)