Like my last post detailing the good, the bad and the celebrity of my first 6 months with Glass, this post will start with a little background for context. I’m also going to work on length because that last post was too darn long… sorry about that.
A quick note as well: This post is going to be a little more technical than some of my previous writing. However, I’ll try to keep it meaningful and enjoyable for those without a technical background also. If you haven’t seen this G+ post , my 7 year old nephew put me in my place when I thought something would be too technical for him, so maybe I should have left this caveat out anyway.
I work mainly as a project and program manager with a technical background. I started out in the learning (technology-enhanced education) industry as a software engineer writing mostly web applications on several different platforms ranging from Cold Fusion (yup, I actually thought the fusebox architecture was awesome and would stay around forever), to Java (Applets, Servlets, JSP), to ASP.Net (C#). Over time I found I had a knack for describing technical projects in layman’s terms and soon after I slowly began to have less and less time to dedicate to coding. Also, I was never that great at it anyway… since I’m looking in the mirror (no “API” this time), let’s say I was adequate, at best. Fast forward [jeez... I went to type this number, but it is bigger than I though it would be so... use your imagination] years and I spend more time in meetings and on the phone than I do behind a computer on most days. The good news is that I’m a staunch advocate for those lucky enough to still be able to code daily, and I consider a big part of my job to form a bubble (force field, 10 foot high concrete fence with razor-wire at the top… you get the idea) around the technical folks so they can do their work without constant interference, requirements creep and every other programmer Kryptonite.
Climbing back out of that rabbit hole, I hope you get the picture. I have tried to continue to read and keep up with the latest technologies, I understand how it all works but I haven’t been hands-on for quite a while.
Excitement, exhilaration, and every other energizing word you can think of dragged me back on the do-er side of things, and I’m loving it. I’m taking a Programming Applications for Android Handheld Systems massively open online course (MOOC) to eventually start working with the Glass Development Kit (GDK), but for now I’m going to focus on development with the Mirror API because its based on web technologies I already know and understand. I am in no way claiming to be a Mirror API expert but I may be able to point you to some valuable resources to get started quickly. Google has all of this information on their Glass Development Site, but I found a way to skip most of it and dig in while not really understanding where I was going. It was a misstep. I’ll include my thoughts on some of these resources, so you can get an appropriate introduction to the Mirror API while avoiding a false start.
The Mirror API allows you to write code with just about any language on just about any platform. This makes it ideal for integrating with existing websites or services. Just look at quick and simple integrations like Evernote’s Send to Glass button. This is a quick push of information, formatted for Glass, while using an existing platform. Simple, quick and easy. So, how do you learn how to write tools and services with the Mirror API in a language familiar to you? If you’re like me, you want to see an example and that is exactly what the Quick Start demonstrations provide. Examples and code libraries are currently available in .Net, Java, PHP, Python, Ruby and Go.
During my first glance at the Mirror API, I quickly looked at the Usage Stories page and prematurely decided it wasn’t necessary for me to dig into the details. Don’t make the same mistake as me. Even though your system may not be identical to Google’s Add a Cat to That example, the general flow of information can be valuable when deciding how to design your own Mirror API Glassware service. The Usage Stories contain small diagrams illustrating the flow of data and division of responsibility. These diagrams can help a novice understand how the Mirror API is used to tie together the different components of Glassware that runs as service.
When you look at the vast amount of information on the Design section of the Glassware development site, its easy to get overwhelmed and decide to skip it. I did. I thought I knew better. I was wrong. First things first: Use Glass. See how other Glassware takes advantage of this new type of user interface. Decide what you like and decide what could be improved. For example, a lot of early Glassware sends information to your Glass via cards in your timeline (the history side, to the right of the OK Glass screen). I turned on a lot of these services initially and found that my timeline became useless quickly. There was just way too much information. Over time, Glassware like Winkfeed noticed this problem and started to work on solutions. As a matter of fact there is a great conversation on a related topic on the most recent (at the time of publishing of this article) Wearables Weekly – Episode 29.
The point is, know what works well on Glass by using it. Also, look at Google’s Design pages. They are extensive and intimidating, but valuable. The folks at Google had a certain type of user interaction in mind when creating Glass. Everything from the hardware to the user interface is created to support this new, short-duration, and focused user experience. So, read those design documents and understand what Glass is intended to do. If this is ignored, you could build the most thorough Mirror API service ever and still have something totally useless in the intended operating environment. I can’t recommend this enough. Ask +Virginia Poltrack, who just got Word of the Day accepted as official Glassware. These, sometimes little, design considerations come up if you ever decide to submit your Glassware to Google so its available on the My Glass site/app. Its worth taking the time to gain a complete understanding of what Google and what you, as a user, see as an optimal experience on Glass.
I’ll just say it. The Playground is awesome, a huge time-saver, and an efficient way to fine-tune your user interface without hitting your API quota. Oh yeah… for those not in the know, Google has a 1000 request API limit per day on the Mirror API for each one of your Glassware services. If you use more than that, you will get an error and your API requests won’t work. So how do you get a set of beta testers using your software AND have enough API limit remaining to test and tweak, test and tweak, test and tweak your UI… Answer: the Playground.
The Mirror API Playground contains common templates recommended by Google. In fact, they *strongly* suggest you use a template if applicable. I’m sure there are card formats that are not available in the current list, and in that case invent away. If you can use a provided template, then do so. First, these formats are tested and are known to work well on Glass. Next, the templates provide a consistent user experience across unrelated Glassware making the entire ecosystem of Glassware easier to use.
Don’t miss this note: I used the Playground at first, only to copy template code into my environment and then sent cards to Glass to see what the results look like. Totally unnecessary! You can edit the HTML in the Playground and see the UI change real-time on the Playground website. No API calls, no closer to the limit, no need to have the Mirror API implemented at all to design and try out your UI. You can hook the Playground to your Glass and this is indeed useful down the road when you want to see how it feels on the actual device, but for getting started, stick with the Playground website. Its quick, simple and has no affect on your quota. Play away!
This will seem like common sense, but I missed it at first. Google provides a series of Send to Glass and Get it on Glass buttons for you to use in your Glassware. Again, its all about a consistent experience. I worked on my own buttons to send to Glass and later realized all of these standard buttons are provided by Google. Don’t make the same mistake. They also provide a cascading style sheet (CSS) that is pre-loaded on Glass. You can use their styles that are pre-made and fine-tuned to the Glass UI. If you make your own styles, you better have a darn good reason for it. Google has put a lot of thought into a consistent experience for end users. There are and will be reasons to create your own styles, but be sure you can explain why your feature is a special snowflake, not accounted for in the standard Google Glass CSS file.
When all else fails, go to the community and/or go to Google. There are a lot of options for help. From the community, you can use Google+ or the Explorers community in My Glass. I don’t know if this is still the case, but early Explorers got a phone number and special pin that can be used to talk to Google support directly. This has been worth its weight in gold.
Don’t forget about Stack Overflow. There is a Mirror API tag on Stack Overflow that often gets answered by Google staff. In fact, even though I’m talking about it last, Stack Overflow is a great place to start when you’re having trouble. Definitely check it out.
The summary for this post is short and simple. When you’re diving into the Mirror API, its great to jump in and start coding. However, when you’re ready to seriously write some Glassware that you one day hope will be official Google Glassware, don’t start until you read the documentation on Google’s site for Glass Developers. The links above, and a lot more, are all available there. Take the time to read everything, then read it again. Its not fluff and is there for good reason. Get to know all of the available resources and use standard templates, code libraries and design to make high quality Glassware consistent with the rest of the platform.