July 1, 2013 - Five Google Glass development lessons (Mirror API)

July 1, 2013 -

 

This is a technical article written by Mark Scheel, President of Digital Construction.

 

Several years ago I traveled to San Francisco for a Stack Overflow conference, it was a first of its kind, and sadly the last. A future conference was canceled after many folks had bought plane tickets and it turned into a rare debacle for Joel Spolsky and an organization I admire greatly. I got to meet Joel and lots of other smart folks at this gathering, including an enigmatic company called Palantir Software--they would later be featured prominently in Forbes magazine, but what really impressed me were the Rubik's Cube schwag they had at their booth.

 

I bicycle commuted to the event and on the way out got some directions from a Berkeley PhD student who was studying eyeballs and we talked about being recruited by Google. Apparently he was being recruited heavily. It started to rain with incredible force, so we exchanged emails and went our separate ways.

 

Little did I know these events would converge many years later. As a Glass Exlporer a lot has thrilled me about Glass, for example snowboarding with it, explaining it to my mail man, and speaking about it across the country. But nothing has engaged me the last 60 days more on nights and weekends than programming and hacking away at the Mirror API which is how you write software or glassware for other Glass Explorers.

 

Stack Overflow is a published support mechanism for Google Glass development, and I turned to it for help when quickstart projects created by Google gave me fits, or documentation was unclear or buggy. I forked the Java App Engine Quickstart project, made a pull request and have maintained several reference features to accompany issues posted to the official Google Glass tracker.

 

Eventually I started answering questions as much as I asked them on Stack Overflow and am now a top five answerer for the "google-mirror-api" tag. I have developed several glassware apps, and as a result of this development effort learned many lessons.I will now share with you what I consider to be the top five lessons I have learned as a Mirror API hacker, developing glassware for Google Glass.

 

#1 Use Google Plus to Personalize the configuration experience

 

Glassware starts with a web based experience. Users have to turn on or provide permission to your Glassware to send cards to Google Glass. These websites, even the one for a huge company like the New York Times are like the websites I used to write in the late 1990's, flat, static and minimal. A little bit of effort at the onset can help you engage your users and create a more personalized and dynamic experience for them. When you user grants permission to your app they provide the software developer access to limited information about the software user stored in their Google Plus profile. A picture, a first name, last name, full name, birth date (without the year), stuff like that. I have found users are more likely to find your Glassware professional and keep using it if your website experience incorporates this information.

 

#2 - Manage API Restrictions Intelligently

 

Today XE7 was released replacing XE6, and still all but about 15 special Glassware developers are limited to 1000 related API requests per day. When a card is pushed to Glass this counts as a request. When your Glassware runs out of API requests users experience odd behavior. You should program for these edge cases and communicate well to your users. Track API usage on your backend, and share information about requests with your user base. You can see your API usage in almost real time at the API Console, but you can be much more accurate tallying API usage in your own code. Keep track of all requests, allot them to users and let users know through your website, and if possible through visual indications on cards what their current status is. Google has said that the API clock resets at midnight Pacific time, and although I have exceeded my allotment in the past, I have not verified this reset timing yet.

 

#3 - Delete extra cards that are part of REPLY and SHARE actions

 

When you enable a user to reply to one of your cards or to share a card an additional card is generated in the timeline with information about the the request. If the user replies and speaks "peanut butter and jelly sandwich" an extra card showing that text in white on a plain black background shows up in the timeline. This is convenient because it lets you have access to what the user said. This is inconvenient because it clutters the timeline with unprofessional looking cards with duplicate information. You have permission to delete these extra cards and should.

 

#4 - Handle Edge Cases and Errors with Grace

 

Many applications interact with external services. There is a round trip from Glass to your server software to someplace external and back again. If that external location throws an error and your user is expecting something be sure to provide human understandable and ideally helpful information. In one glassware app I have worked on when the external data request fails a cached version of the most recent relevant data is sent back to the user with helpful information. This kind of user friendly experience will keep users from disabling your glassware and if they really enjoy your glassware keep you in one of the few, limited pinned slots on their glassware.

 

#5 - Always test on Glass, don't trust the Playground

 

The Playground is a valuable rapid prototype tool, but there have been many instances of things working in the Mirror API Playground that do not work on Glass. Always test your app out in all edge cases and iterations on a physical Glass device.

 

Developing for Glass using the Mirror API is a rapidly evolving experience, and is constantly improving. I hope you find these tips useful as you write and invent your own Glassware to thrill Project Glass users. Have fun out there!