Designing and Developing for Google Glass (2015)

Part II. Design

Chapter 6. Glassware Antipatterns: Avoiding Poor Design

As we discovered in Chapter 4, an unbiased overview of Glass reveals that while it’s a wonderful and powerful communications platform that’s rapidly expanding with Google and the developer community creating a ton of real-world uses, it quite frankly isn’t the solution to many existing problems—and wasn’t intended to be. A further issue is the ways that Glass can create new problems and be devalued by misapplying it in different scenarios.

As a Glassware architect (either on the design or development side) and even as an end user, you need to know what Glass was meant to do and do well, and not try to cram the Think for Glass philosophy into every situation under the sun. And programmers and designers that spend their days and nights crafting innovative Glassware need to be aware of and respect the implied boundaries and design recommendations, allowing users to get the most use out of the platform in terms of maximizing battery life, minimizing notification frenzies, and keeping the input required from hitting excessive levels. It’s a virtuous cycle: responsible program design emphasizes ease of use and efficient use of system resources, which breeds proper use, resulting in happy users, leading to a huge userbase, meaning favorable reviews, a positive reputation, and a profitable project.

The brutal truth is that at least for its initial incarnation, Glass isn’t very accommodating to purposes for which it was not intended. In that regard, it’s quite inelastic. Smartphones still have the edge here. Some of the design constraints in the system limit some of the applications that are available. Therefore, a simple rule to adopt whenever you find yourself struggling is always return to the Five Noble Truths, as presented in the previous chapter. Let the simplicity of the guiding principles show the way and get you back on track.

We’re going to look into some of the more prevalent potholes that you might run into when beginning to Think for Glass, and how to make sure you understand the ecosystem and can work your way around them. We want to help get Glass all over the world and give rise to a community that’s equally passionate and competent, so this chapter’s focus is on some final design considerations to keep in mind to get that done as we begin to transition into the Development section of the book. And as you’ll see, wise integration trumps sheer force. The really meaty chapters on Glassware coding are right around the corner, so let’s run through some of the major snafus that people tend to make when beginning their journey with Glass, so we can get to the good stuff.

See how many you’re guilty of, and how many you were able to figure out on your own.

Improperly Implementing Ideas for the Glass Experience

Not every idea is naturally a perfect fit for the Glass application model. As a Glassware developer, you’re going to have to get really creative and think hard to figure out how to carve out its place within the ecosystem. Media, particularly video, is an area that’s a big part of Glassware, but the dimension limitations of the prism display are the primary challenge. Netflix and Hulu for streaming video and Zynga for web games are organizations whose products don’t exactly translate well within the confines of the prism as they exist on larger displays, but there should certainly be clever workarounds or helpful integrations that still let members use Glass to interact with their systems, even if not with full-stack functionality.

We fully expect to see managerial access to instant queues and remote control features for separate monitors like Google TV, or rich second-screen data from IMDb that pops up in the user’s HMD while streaming programming on a separate monitor, triggered by timing hints synced with the programming—which several cable networks do currently with tablet apps, notably AMC for The Walking Dead and TBS for Conan O’Brien’s show. We’re already seeing see a scenario where Glass can be integrated with Chromecast via the Google Cast API by the fitness Glassware LynxFit and its LynxCast feature. Could this possibly mean Glass would be aware of a video that the Chromecast is streaming and display supplementary information cards, personalized to the wearer and contextually sensitive to the content? The sky’s the limit!

And relative to the financial services industry, a utility to manage one’s investments is an obvious candidate for Glassware, along with a service for banking/lending companies. While a bank’s mobile app and web presence let customers do the normal range of transactions, it’s largely still a cumbersome process spanning numerous screens and clicks. We’re curious to see how personal banking institutions could streamline actions like funds transfers, deposits, and balance queries using the Glass control set of trackpad swipes, voice commands, and gestures, or using the camera as input. Imagine being able to capture a picture of a check and share it to your bank’s Glassware, which could then apply OCR software to identify various aspects of the check for denomination and account, similar to the feature Concur’s Glassware provides for scanning receipts, and automatically credit it to your balance. Such applications exist today for mobile platforms, so we’re excited to see how they might embrace the Glass experience, and how they will start to Think for Glass.

Turkey’s Garanti Bank has Glassware approved and listed in the official directory, delivering convenient ways members can see their account balances, credit card limits, and much more. Additionally, PayPal developed an app for Android Wear that facilitates payments and bridges notifications about completed transactions.

But obviously paramount to this type of application is member safety. You wouldn’t want a program that determined amounts to be transferred between accounts based on voice input to misinterpret the audio because of background noise and accidentally overdraw from a member’s balance.

The important thing to recall, especially for those of you working with existing brands and looking to expand your reach to another device, is that Glass is different. You need to apply your idea as Glassware in a way that respects the user’s real-world activities and the Glass experience.

The only thing worse than not having Glassware for a particular product is having bad Glassware.

Treating Glass Like Any Other Mobile Device

Some people are of the mind that since the firmware that Glass is running is based on Android, everything Glass is and everything Glass does should copy the phones and tablets that Google and its licensed partners produce. All aspects of the ecosystem, they purport, needn’t deviate from the current mobility model. All Glassware should be listed in the Google Play Store alongside Android apps and Glass should be thought of as just another Android device.

Google’s had an interesting history with forking its mobile OS—Google TV and the Nexus Q may share the same source code as devices running on Android proper, but they weren’t necessarily lumped in with other existing devices. Forking a platform maintains its roots while also introducing new personality. By this merit, Glass is its own entity and needs to be viewed as such.

It’s part of what makes this new realm so interesting…and a bit of a challenge to break new ground in. As we’ve seen, proper Glassware design means thinking about what situations the users could be in when using your Glassware, beyond just whether they have decent bandwidth. Are they walking or jogging? Are they outside in an open environment where GPS is optimal or within a building? How is the ambient noise level surrounding the wearer? And how about their lighting? Does the environment in which the user would likely invoke your Glassware permit the use of voice commands? Most of the great Glassware that sprung up as first-generation examples assume some range of activities by the user, and this directly affects the available input controls and how content is laid out (individual cards or bundles as opposed to custom UIs).

One thing that drives this new paradigm is obviously the form factor—there are tons of digital devices around the world running the Android OS in various ways, but nothing like Glass. The headset’s physical design and supported hardware components occupying such a tiny space with enhanced portability make for some very compelling concepts to try as applications. But challenging this is the amount of raw computing power Glass has…which is admittedly less than its Android contemporaries. The battery and processor don’t stack up to other forms like tablets and set-top boxes, as they are the equivalent of a mid-range smartphone.

HOW DOES GLASS FIT INTO ANDROID WEAR…OR DOES IT?

The role that Android plays in supported computing platforms continues to broaden, and Glass isn’t just another frontend running on top of Google’s mobile operating system. The rollout of Android Wear and Google’s partnerships with smartwatch manufacturers in early 2014 demonstrated the depth of the company’s commitment to supporting wearables.

Riding the momentum (and controversy) of Glass, an entirely new era of mobile computing and multiscreen experiences that bring with it wildly creative new applications, new UIs, and contextual data opportunities for all sorts of situations and environments is upon us, subsequently demanding a new set of tools. Google has carved out its own niche for Glass within the Android umbrella brand—it’s based on a unique user experience that stands apart from anything else the company produces, and writing smart software for Glass demands specific skills.

Sure, if you’re a native programmer there’s going to be crossover and integration, and the design pages of the two systems are strikingly similar. But Android is not Android is not Android anymore. Even within the wearable space, Glass stands alone.

Overloading the System AND the Wearer

Jason works in the broadcasting industry, and like many of his contemporaries he’s considered using Glass as a teleprompter for his live on-air duties. While this would be a really obvious and cool application, it’s highly impractical to the Glass experience because it forces the user’s attention on Glass over an extended period of time, and by the nature of the app Glass would need to stay on and illuminated, which causes the battery to rapidly discharge. It’s still a doable idea, but the core concept needs to be massaged a bit to work with the system constraints of Glass, while still delivering the intended experience. Services like Glassentation have proposed neat workarounds to this idea, so keep an eye on where these go. This very clever Glassware lets users send content from Microsoft PowerPoint slide decks to Glass, to use as a visual cheat sheet when giving a speech—not reading material verbatim, but getting just quick notes to elaborate on.

Glass renders material for the timeline and handles its own version of small-chunk data communications payloads extremely well, but it isn’t meant to load apps even written for other Android builds. The Glass version of Android is very adept, but also very specialized. The fact that Glass overheats when running certain native apps is a well-documented concern. The battery life also isn’t what you might consider to be top of the line, and will drain quickly under certain usage conditions like prolonged use of the projector or the camera, and processing-intense operations.

This is another reason the focus should be on terse usage patterns with reduced information, smaller amounts of data sent across the wire, and minimal user input…or user input that actively uses the wearer’s surrounding or actions as a staging environment. A canvas, if you will. Where they are, who is around them, and what they’re doing become a key part of the application’s user interface. Glass goes beyond the computing platforms you’ve been used to. It’s not stationary like desktop PCs, set-top boxes, and gaming consoles; it’s portable like smartphones and tablets, but without demanding so much attention from the operator as handhelds do, as to remove them from living in the moment.

Remember, we’re always aiming for microinteractions. All of us.

WE MESSED UP, TOO

When Glass was but a blip on the radar of the mainstream media and prior to the Glass Foundries, both of us had spent months thinking about how Glass might shape up, leading us to co-organize a Hangout On Air with several members of the community, attempting to prognosticate how the Glass ecosystem would all play out. A few friends from the Glass team were watching in the background, giving us the supportive nod and saying, “You guys really nailed a couple of points…and we think you’ll be pleasantly surprised at how off you were on some others.”

It’s the most fun we’ve had being absolutely wrong.

Think in Actions, Not in Apps

We introduced this concept earlier: a major way to design your Glassware, as we’ve stressed, is thinking in terms of what the users will be doing when invoking a certain action, not what screen they may be looking or the arrangement of submenus. This is a shift in computing UIs because it puts the emphasis on the user actively doing something in addition to starting an app or making a selection. These design decisions are important, but have largely been decommissioned with the simplicity of the timeline model. Usability in the Glass world is equal parts input controls and the activities they’re engaged in, such as swiping while strolling down the sidewalk, or barking out “Take a picture!” while taking on a sharp curve at full speed while on a go-kart. Or, what Allthecooks Recipes does—allowing users to tilt their head up to quickly glance at a secondary set of instructions that list the ingredients for a dish while they’re cooking!

Another example of this mindset is the native Timer application. Because it exhibits the capabilities of live cards, it’s bound to the parameters of the timeline such as the menu systems and gestures, so it uses a series of custom actions and swipes to invoke its functions. But while it’s a good demonstration of what’s possible with native coding, we also feel it serves to show what can happen when you put too much into a control system. It takes at least seven swipes and taps to create and start a countdown, which is excessive. Clearly, this is an application whose primary choices need to be driven by vocal input, but that’s missing entirely. In contrast, the Stopwatch app is incredibly intuitive, as you’d expect. Once launched, it starts a three-second countdown then begins tracking the time, and can be stopped by bringing up the Stop menu item. Just two taps.

Play with these and other apps to see what we’re saying. And as part of your routine design planning, chart out the number of input steps it takes you to perform each function your Glassware offers, and see if they can be streamlined or optimized in any way in terms of eliminating unnecessary steps or replacing any actions with other types of input.

You’ll also see a tip in Google’s developer docs about not using pinned cards as application launchers (regardless of which Glass framework you used to build your Glassware), but many people don’t really grasp what it really means until they experience why it’s important—and it’s too late. Pinning can be a helpful and strategic way of keeping your Glassware present within the mind of the user, like an application shortcut. For this reason, you may be tempted to pin a card to help your users find your program and to get a leg up on the competition, but this will come back to haunt you, trust us.

The purpose of pinned cards, just like all the other items to the left of the home screen, is to display items that are upcoming, or happening now (items on the right are events that have already taken place). Thus, you should use this space for data, not apps. Items that are perfect for pinning are static cards about an appointment reminder or a “Don’t forget!” occasion; or live cards that update every few minutes (in-game sports scores), every few seconds (store inventory), or even multiple times per second in real time (some sort of animation, like the Compass Glassware).

As part of its maintenance, Glass ensures the timeline doesn’t contain stale items and purges any cards older than a week, which includes pinned items. If you pin a card, it will disappear eventually. Pinning can be a helpful tool for the user as a digital sticky note or bookmark, but as a developer it’s not something you want to use as a normal part of your feature set. Allow it as a menu item, but don’t bet the farm on it.

The primary entry points for your Glassware should be voice actions and menu items, both of which are accessible with just a single tap of the home screen or in contextual menus within cards. Either developmental framework lets you set a voice trigger and icon to launch Glassware; Mirror API Glassware can use the preset voice commands “Post an update” and “Send a note.” And more are coming!

Stick to the Prefab Templates and Styles

You needn’t reinvent the wheel when we’ve got two fantastic resources at our disposal for coming up with great UIs for Mirror API Glassware. The Google Mirror API Playground, which we fully examine in Chapter 9, is replete with a gallery of flexible templates for all sorts of uses, not only provide a guideline for how to structure content within cards, but also get you in the habit of capping the amount of data per card, which makes for better readability. And the base style rules provide a consistent look and feel to your cards through Cascading Style Sheets (CSS), freeing you up to concentrate on manipulating data and not formatting or positioning HTML elements.

This inherits from the themes used in native toolkits like those available for iOS and Android. It’s best to use the same typefaces and sizes for text that everyone else is using so as not to confuse the users or make them weary with radically different designs as they fly through their timeline. Consistency is critical here. When users aren’t shifting their focus based on different color schemes and fonts and readjusting for layouts that vary from card to card, they can concentrate more on the information they contain.

The pitfall here would be applying a custom design and/or layout that’s too far outside the scope of the recommended style. This might be a tough pill to swallow for established brands with signature colors and fonts, but you can find a happy midrange. LynxFit is a great example of an app that applies the general patterns while still tailoring its feel to give it a unique appeal. The software has its own personality while working within the parameters of known templates.

But if you ever do need to apply a UI that’s dissimilar to the timeline motif, like when creating a custom game experience, you use GDK immersions, which take users outside the timeline, and thus put them in the frame of mind that they’re in a different environment completely. We’ll cover immersions and the other types of native interface elements in the GDK chapter in the Develop section.

We’ve mentioned before the importance of being a responsible Glassware designer—adopting a look and feel that’s consistent with what other developers are using. This flow makes the overall experience less intimidating for users. See if the groundwork that’s already been laid for you does the trick.

Don’t Use the Prism Display as a Stage for Complicated Reports

While we’re considering the topic of consistent UIs, it’s also important to note that Glass generally shouldn’t be used for complex graphical data. Enterprise uses are clearly a market that will thrive for wearables in general, but several early adopters have attempted to using timeline cards to hold entire business reports or statistical data. This isn’t anathema, but should be implemented very carefully. Tabular data has a place on Glass, but spreadsheets don’t translate well. Simple graphs can be effective even in a small display, but not complicated stack charts.

The Glass templates mentioned previously provide a tabular layout structure that works well, and excessive data should be paginated over multiple cards or in bundles. Doing sight analysis on business intelligence data is tough enough…don’t impose the additional eye strain of having to check out regression trends in a complicated chart. Maybe use generalized text with color to imply variance, like the stock price template does.

Some companies are already creating Glassware around data analysis, and have managed to find a happy and effective balance—Dawn Data is a Mirror API service that assembles next-day traffic reports for Google Analytics profiles already attached to your account that are sent to your headset. And Australian data science company Loves Data has done some impressive work in merging Google Analytics with the Mirror API’s voice commands to measure Glass usage. They’re both very creative implementations that are worth checking out for inspiration.

Glass Isn’t Necessarily Bound to Your Phone

There may be third-party services that require you to have a paired device, such as using Glass as a viewfinder or controller, but as long as you have a network connection Glass is a standalone smart device, and becomes even more valuable by enabling telephony services when you pair it with your phone. Any network-centric activities that Glass does pass through its associated phone or WiFi hotspot. And even without a network connection, Glass still makes a very capable camera with a ton of onboard drive space. It’s likewise a great client for running apps using sensor data like Compass and Stopwatch, and for playing casual games.

You can’t transfer files or stream videos and music from your smartphone to Glass, or vice versa. GDK apps, running locally, can exist autonomously without needing any outside help. And there’s a lot of room for growth here as far as what we might see with the creative use of offline access. And once you do hook up to a network, Glass sync will download any Mirror API content automatically.

As public WiFi continues to become more widely available and secure, as portable connectivity solutions like MiFi cards become more affordable, and as the software written for Glass by Google and by outside developers evolves in terms of being feature-rich and utilitarian, Glass may begin to evolve as a standalone computing unit.

As we led off with in Chapter 4, Glass is just getting started.

Unrealistic Expectations for Augmented Reality and Gaming

While a major ad hoc selling point was Glass being the first big commercial product to make augmented reality available to a wide consumer audience and easy to work with for developers (many AR frameworks are based on complicated C++ libraries and custom systems), AR isn’t making a huge dent in Glass just yet. The GDK does make these opportunities available to the many programmers interested in creating such experiences natively.

Nonetheless, AR vendors are taking a long look at Glass to determine its viability for their platforms. Opportunities are clearly there to use perspective, geofencing (physically entering a predefined location space like a park or a library, triggering some sort of action within an app), and surroundings as the stage for applications—factoring the user’s world as the base of your app is the design mindset we’ve been discussing in the last three chapters. Wikitude, an Austrian company, has extended its developer SDK, which includes image recognition and location-based features, to support Glass.

The video game Glassware packages Spellista and the Mini Games collection show how GDK immersions can be used as gaming stages for the platform. As each uses various components like the various motion sensors, they tend to cause Glass to heat up, but still provide clever examples of casual, sub-45-second gaming, and animated content running in immersions. It’ll be interesting to see if these one-player titles, where the user competes against a computerized opponent, are ultimately expanded upon to allow multiplayer and have Glass users from across the globe battle each other.

Also keep in mind the turnaround time for a game project. At the San Francisco hackathon that unveiled the GDK, attendees asked about timelines for getting a gaming title from conceptual idea to in-market product. While months earlier it took three developers working as a project group a few hours to come up with Ice Breaker by using the Mirror API, Glu Mobile reportedly spent around four months building Spellista by working with the GDK—but capitalizing on its much more robust toolset for sensor access, OpenGL graphics, and rich audio.

Early hackers proved they could install Ingress and get it to load in Glass and got it on record, but also managed to shine light on the fact that the game couldn’t adapt to the slightly slower chip and reduced memory of Glass (although it is still a very capable computer), as opposed to running the same app on a media device built from the ground up with a quad-core processor and 12-core GPU to handle graphically intense gaming experiences like a Nexus 7 or Samsung Galaxy S4. Just because you can doesn’t mean you should.

Still, Ingress is a perfect example—one of many existing titles—of a game that needs a conceptual rework for Glass to fit the microinteraction model.

Don’t Deviate from Default: Using Categorial Voice Commands

Almost immediately after the Glass docs were posted, the community, programmers, users, and the media began speaking out that the stock voice actions weren’t enough. The media said more choices were needed, users wanted the ability to define their own custom actions, and developers wanted to expand the set to include audibly driven commands for their Glassware. This resulted in sometimes heated back-and-forth on “Issue 6” on the Mirror API Issue Tracker, with developers passionately advocating for and against giving third parties the ability to add their own custom voice triggers to launch Glassware.

Keeping the number of voice actions to a small level was an intentional design decision by Google, to maintain the platform’s light-yet-capable feel—admittedly smaller than the number of voice commands used for Google Now (although that continues to rapidly narrow as more and more cards are added to Glass with each firmware update). The list may slowly expand to accomodate more Glassware ideas, so check back with the list of supported voice triggers, and make sure to review Google’s voice command checklist if you submit a custom trigger phrase. But before you start brainstorming about a cool catch phrase and go off the deep end, let’s keep things simple. And to do this, we all need to think at a higher level.

Think categorically, not in terms of plugging a product name. A rule of thumb here is a repeat from our introduction of the Noble Truths: issue commands, don’t start apps.

Still, a case can certainly be made for why the list needs to be extended. It will invariably hit the wall at some point, and as people get more creative and complex, Glass will need to accommodate that ingenuity, with “Post an update to…” and “Take a note with…” unable to fit the bill. Fortunately, Google is listening and willing to entertain trigger phrases. GDK Glassware is able to submit a dedicated custom voice command for Google’s consideration to use as a trigger phrase to launch the app. You could request a command of your own, or piggyback off of an existing phrase available to you and others in your genre.

The key is to try to select a phrase that clearly conveys the functionality your Glassware delivers, but at the same time is generic enough so that the phrase could be used down the road as a higher-level category to accommodate other products similar to yours.

Again, one of the major aspects of Thinking for Glass is being altruistic. The developer documentation for Glass features some great tips on selecting a trigger phrase that fits with the convention of others being used, so check it out.

Not Fully Utilizing Cloud Computing

One type of misclassification we’re seeing in these early days is developers not properly using the Internet as a computing engine for their data on Glass. It’s very important to understand exactly how cloud computing is implemented on the platform, with data being accessed, stored, and shared from remote servers instead of solely on the device itself. This is a powerful means of enabling multiplatform access, which extends the platform and greatly increases the value of your Glassware, and it’s worth looking into, as long as you understand the requirements.

Essentially, you don’t need to use the cloud in your Glassware, but you can get some advantages if you do—and use Mirror if you do. This itself should lead you to down the right path when deciding whether to build a server-based solution or a native app.

Incorporating online communications into an application is a powerful thing, but what you need to remember as a Glassware designer is how this affects the system in terms of the immediacy of the UI informing the user something is happening, and the impacts it may have on the hardware. The Mirror API’s architecture is such that simple messages and commands are fired off to much more robust backend infrastructures, which do all of the heavy lifting and then at some point are able to return simple data fragments to the client. However, you lose a little in terms of the ability to facilitate true real-time communication due to data roundtrips. In contrast, the GDK can wholly utilize resources on the device for storage and processing if the response loop needs to be more immediate, and also call remote APIs. And in both cases, the obvious requirement is for your Glassware to have connectivity.

Fancy and Sherwin Williams’ ColorSnap Glass, two Mirror services, both use the clever tactic of color-as-query when letting wearers do searches, as opposed to open-ended text. They analyze the hues of colors from photos the user captures and shares with their respective Glassware services, then return items from their databases matching those shades. Both take considerable processing and offload them to more dedicated resources remotely, with Fancy even displaying a “Searching” card to let the user know the operation is working and matches are on the way soon. The end result is a simple HTML payload that gets returned a few moments later. Glass here is a frontend client to their off-site database. And similarly, Preview, which recognizes movie posters and plays back their trailers, lets Glass wearers scan images of those posters, which it sends to its servers; it then returns a YouTube clip.

And Allen’s Glassware, Vodo, which he built with the Mirror API, facilitates real-time collaboration for users working in Google Drive on documents, whether they have Glass or not. Any changes made to the information to the affected files is pushed up to the cloud and reflected in Drive, which others (including Glass users) can see nearly instantly.

Other cloud-centric applications might be image processing, updating databases, communicating with other peers on a system, most multiplatform social systems, or storing progress data for a game.

Knowing when and how to use the cloud capabilities of Glass is a very valuable skill to have, so really think about what your project would be best served by as far as applying the right combination of web API calls alongside local computations and storage. Don’t just architect cloud computing because seemingly everyone else is doing it. If it’s the right fit for your concept and the experience you’re trying to create, make it work.

Choosing the Wrong Development Framework for Your Glassware Project

We’re going to segue more into technical development now and cover some fallacies having to do with coding architecture. One of the big headaches that we saw was people demanding additional functionality, hardware, software services, and backend architecture without really taking the time to try to understand the system as designed out-of-box, or giving it a shot—especially developers. The Glass cloud application architecture (see Chapter 9) is quite comprehensive and handles a lot of issues and challenges that people bring up already.

Perhaps not surprisingly, there were lots of Glassware projects launched that took a design and developmental slant that was ill-fated. We saw many efforts haphazardly implement their ideas as native apps because of the perception that the Mirror API, being RESTful, was too limited. But for many ideas, this does just fine. The result was projects that reeked of overkill—not performant, not fully secure, and not delivering what should have been a true Glass experience—because they thought the Mirror API to be too inferior in terms of capability. They generally looked to the wrong framework on principle to get their things done and it hurt them.

One of the most frustrating things we’ve seen is when developers naively default to using the GDK to write apps that could have very well existed as Mirror API services, or vice versa. Each has its own capabilities and roles, and it’s important to know how to best leverage them to the success of your projects. The deciding factor on the development framework upon which to design your Glassware for many people will come down to skill set—whether they’re comfortable working with the Mirror API, which gives you the pick of the litter as far as using a programming language and server-side environment, or the Java-centric demands of the native GDK.

In deciding which framework to base your Glassware project on, the checklist of questions you should be examining should include these:

§ What specific type of user experience is the Glassware trying to create?

§ Under what real-world situations will someone use this Glassware?

§ Is sensor data a crucial part of the feature set?

§ Is the Glassware dependent on data/notifications in real time?

§ Is it a service whose goal is for publishing, notifications, and sharing?

§ Does the Glassware need total control of the camera, or just photos and videos captured by it?

§ If location is a feature, how often should the user’s geoposition be updated?

§ Does network connectivity play a role or can it exist offline?

§ Can the Glassware be expressed on the timeline through cards or does it require a custom UI?

§ Can the expected experience exist as static timeline cards or does it rely on rapid, frequent updates over an extended period of time, meaning it should be a live card?

As a Glassware developer, you need to know that just because it’s a webby framework, the Mirror API isn’t a junior varsity–level platform. It’s a powerful messaging system that’s very capable and can be coupled with other types of platforms to do amazing things. A great example of using the Mirror API where some people might think it’s a native app is OKDoor, Glassware from Brivo Labs that demonstrates “social authentication” by sending images of people trying to get into a building to a Glass user in a card, who is then able to tap a menu item to unlock the door and let them in. It uses Brivo’s SAM API to control other devices and machines.

And for some truly cool implementations of contextual machine-to-machine hardware hacking, check out the tinkering of Justin Ribeiro from Stickman Ventures, who’s done tremendous work using Glass as a frontend for devices like ‘net cams, Arduino boards, uninterruptible power supplies, 3D printers, and platforms like Google Drive. He’s done some pioneering work for the community based primarily on Message Queue Telemetry Transport (MQTT), a publish/subscribe vehicle for Internet of Things systems. And what’s most impressive is that Justin’s project uses the Mirror API, and doesn’t require native code.

The bottom line is that both the Mirror API and GDK have well-defined purposes, and you should always choose the right tool to do the right job in the right way, in concert with your skill set. And a major part of this is understanding the full range of capabilities that each provides.

UNIFYING THE CAMPS

Given that web developers and native developers have long “enjoyed” a natural friendly rivalry, an angle that wasn’t properly appreciated with the “RESTful API versus native SDK” debate for Glass was that at least catering to both camps lets either side finally code for the same platform. Traditionally web programmers stuck to the browser while native coders worked with devices. It was always a house divided—Chrome or Android (which, ironically, is literally Google’s organizational division).

So while still not functionally the same, the availability of the Mirror API and the GDK might be the first time both groups wrote for the same system. And that’s significant, and we’re excited to see some crossover or merging between them, and possibly some new bridging solution by Google to facilitate communication between the two platforms.

So while it may look like forcing the Hatfields and the McCoys to sit down at the dinner table together, some good could come out of this by having web and native programmers work alongside each other. And that’s to be commended.

Developers will need to choose a path, given the needs and requirements of their Glassware. The Mirror API certainly isn’t without its constraints, as coders who have used the web stack for years may feel a bit jaded with the lack of JavaScript support in timeline cards.

The GDK route isn’t perfect either. Many mobile developers will wish for the total control native coding provides and will want their code to communicate directly with Glass, cutting out the intermediary that is Google’s cloud-backed system. Direct access to the hardware is good, but could lead to a negative user experience—particularly if the battery heats up too much or drains too quickly. Google has optimized its software to work efficiently on Glass, and you’re going to need to do the same. You may not want to go this route if you don’t need it. It’s more work in exchange for greater command.

Once you’ve spent a sufficient amount of time making these critical decisions, your choice of framework and which path you’ll take should be clear—cloud or native…or possibly both. Programs can easily exist as hybrid Glassware, leveraging the best of both frameworks. This lets you use the Mirror API to generate static cards as a frontend that launch an Android app built using the GDK for more detailed processing. Think about a turn-based game like tic-tac-toe. When a friend makes a move, you’d be pushed a static card informing you that he did so, which would include a link that would launch a dedicated activity that contained the game environment. Swiping down would exit the game and return the user to the timeline. This wouldn’t require the game to be running perpetually in memory, but would still let either player know quickly when the other had taken their turn to avoid long waits. Additionally, you could extend the game to be accessible via the Web, too, giving people more surfaces to play on, with the use of the game being only a few seconds. This is a microinteraction at its finest!

Don’t think of it as which horse you should you bet on long term; think about it more generically as a well-rounded Glassware developer.

Done deal.

OK, let’s get coding! The most sound advice we can give for properly adopting and adapting the Think for Glass mindset is to thoroughly learn the system and its capabilities first. Whether as an end user, a Glassware designer, or a system architect, getting up to speed with what Glass can do should be your main goal.

If you’ve read the chapters in order up to this point, we’ve gone through what Glass is/is not and how to design Glassware in ways that keep with the key themes of the mission of Glass to make technology available the moment when you need it and then keep it out of your way when you don’t. You’re now aware of what the aptitudes and limitations are of both the Mirror API and the GDK so you don’t have to unnecessarily reinvent the wheel and can choose the most appropriate tool for your work.

In a tech world where few things are certain, keeping an open mind and attitude about Glass while staying pragmatic will let you get the most out of it. That we can guarantee.