What is Glass?

Note: The last few paragraphs were scratched and replaced to discuss the new GDK on 4 December 2013. 

When Steve Jobs introduced the iPhone, he called it a telephone, an iPod, and an internet communicator. One of the most common questions I get when I wear Google Glass is "What is it?" I wish I had an answer as concise as Steve's.

Glass isn't a phone, or an iPod. I think it qualifies as an internet communicator. But more than that, I claim that it is a tool for simplifying and speeding up the common interactions you might have with a smartphone or computer. Perhaps it will inspire computer interactions that don't yet exist. Like most devices with Apps, what it does depends a lot on the software you use.

The Pieces

If you tear open a Glass device like these folks, you will find a camera, a display, a bone conduction speaker, a touchpad, a shutter button, an accelerometer / gyroscope, WIFI and Bluetooth transceivers, and a CPU. It comes with a snap-in polarized sun shield too.

The display technology works by projecting an image into the prism which sits above the right eye. The images it creates are translucent; you can see right through them. The positioning of the display above the eye -- not in front of it -- means that you aren't trying to peer through it to see the world. The prism appears to have a photosensitive film on the side away from your eye to create a darker background for the display in bright light.

The bone conduction speaker is a tiny pill-shaped apparatus that touches the head near the right ear. It looks temptingly like a button. One of the curious properties of the bone conduction speaker is that in loud environments you can hear it better by plugging your ears. It also tickles just a little bit when it makes sound.

Using Glass

To begin interacting with Glass, you either need to tap the touchpad near your temple, or perform the Glass head flip. The head flip involves tilting your head up until the screen activates, a configurable behavior. With both the tap and the flip, the display shows the home screen and begins listening for the magic words: “OK Glass”.

If you say “OK Glass”, you can verbally select from a menu of commands: send a message, take a picture, record a video, get directions, make a call, start a video hangout, or take a note. Speak and Glass obeys. Some of the commands appear depending on what services you have connected, or how your phone is configured. The “Take a Note” command, for instance, can be handled by the Evernote Glass app, and it lets you dictate a note.

Using the touchpad, the same options are available, and you can also navigate the card-based interface of Glass. To the left of the home screen there are a collection of cards mostly related to the Google Now service. You might find a card with upcoming events on your Google Calendar, a card for the local weather, a card for stock prices, or a card offering driving times and directions to destinations recently searched for or for calendar events. These cards and their contents are contextually sensitive just like the Google Now cards on an Android Device, or in the Google Search app on iOS. They appear and vanish depending on what Google thinks is most useful. The card furthest to the left is the settings card, which shows the battery charge, and allows the user to configure Glass.

To the right of the home screen, there is a row of cards in reverse-chronological order, starting with the most recent. These are cards which come from your own interactions with the device, from communications, or from third party services. If you take a photo, you’ll find a card for it in the timeline. Did you search google? You'll find a card for that. Text messages and emails too. The interface feels like a long strip of film that you can click through one frame at a time, like an old-fashioned slide show.

Typically, each card responds to a tap on the touchpad. Depending on the card, it will either show a menu or another collection of cards that were metaphorically stacked. Text messages are a good example of stacked cards. In the timeline, only the most recent text is visible. Tapping on that message reveals a card for each message in the conversation. Tapping on any one of those cards offers a menu: reply, read aloud, call, delete.

You can see in the image above a diagram of the Glass interface stitched together from actual Glass screenshots. Click or tap on it to see a larger version. The home screen is where you usually start an interaction, and is one of the indications that Glass is ready for a verbal command. If you swipe forward on the touchpad, the next thing you would see is a text message, followed by a photo taken with glass, and finally a search for "will it rain today."

The triangular dog-ear in the top right corner of the message card is a clue that this is a stack of cards. If you tap on the touchpad while the text message is visible, if will dive into that stack of cards: a list of messages in that conversation. Follow the yellow arrows above. If you tap on any of those message cards, you are offered a menu.

The vertical stacking of the interface is a useful way to think about the UI. Swiping down on the touchpad will return the user to the next level up. From any of the menu cards, you can swipe back to the messages list, and from there you can swipe back to the top level timeline. From there, an additional swipe down will turn off the screen.

Incoming Communications

If you get a new message or interaction from an App, Glass will chime. If you respond immediately by tapping or performing a head flip, you will be shown the card associated with the notification. Depending on the notification, there will often be an “OK Glass” cue on the card indicating that you can address the notification verbally. When I get a new email or text message, I can say “OK Glass, read aloud”. Glass will then read the contents of the message to me. When it’s finished, I can say “OK Glass, reply,” and then dictate a response.

One useful UX trick that Glass uses is that it will display the text you dictate for a few seconds before performing an action. This gives you an opportunity to cancel a message in case there was a transcription error..

Photo and Video

In addition to the audio commands, you can take photos or a video by using a physical button on top of Glass. Photos and videos can be explicitly shared or pulled off of Glass using USB. In addition, once Glass is on a WIFI network and has a decent battery charge, it will automatically upload the media to a private Google+ album. You can choose to share or download the images from there.

The camera Glass has (at least the first generation Explorer Edition I have), is a wide-angle fixed-focus camera. I don’t really think that the camera compares to what you would find in an iPhone 5. However, Glass uses some computational photography techniques to create better photos that what the hardware normally would produce.

Navigation

I've only used Glass for walking navigation, but it works really well. Walking navigation seems like a killer app to me. The map is continuously projected in the display, and is oriented in real time with your head motion. Since the map spins so that it orients where your head is aimed, there is no need to look at street signs. Just line up the arrow with the path and walk.

You look like a normal, purposeful human being using walking navigation on Glass. Compare that to folks trying to navigate with their smart phone. They walk with their heads either down, or looking for street signs. They walk ten feet in a direction before making a u-turn to go the correct direction. Glass is a nice improvement.

Apps

Glass offers two main paths for developing apps. The first is the Mirror API. To use the Mirror API, the app developer doesn't write code for Glass. Instead she writes server code. Your server interacts with Google servers which then act as a proxy for a user’s Glass device. The server and the Mirror API interact with JSON and HTML representations of timeline items through RESTful endpoints.

Since the app runs on your server, you can use whatever technology you want to implement your side. Google has example code written in a variety of different technologies.

Users enable an app that uses the Mirror API by authorizing them with a familiar Google authentication flow. If Google has approved an app, it can be switched on through the MyGlass Android app, or the Glass dashboard.

The second path for creating Glassware is writing an Android app. You can load apps using the traditional Android development tools and load them with a USB cable. Developers will want to heavily customize their app for Glass since there is no touch screen and most apps aren't quite ready for a 640 x 360 display. At the moment there is no simple distribution method for apps created this way. Glass doesn't yet come with the equivalent of the Play Store.

Update: Google has released a preview of what they're calling the Glass Development Kit (GDK). The GDK is an Android library that gives developers direct access to the Glass-specific elements of the device: the timeline, the cards, menus, and so on. It also enables Glass apps with real-time interaction.

Apps developed using the GDK are installed the same way the Mirror API apps are: through the MyGlass web interface, or the MyGlass Android app. Flip the switch, and the package is pushed on to the device and installed. Glass requires an internet connection to retrieve the APK.

Along with the GDK, Google and several third-party companies released GDK based apps. Google released a compass app. Word Lens released an impressive translation app that replaces text in a live video feed from the camera. And there are several other apps in categories like sports.

The GDK opens up a lot of new possibilities for Glass development. It offers more challenges too, since it takes careful work to get smooth performance and low energy usage from code run on the device itself. That's just the sort of thing I enjoy. I've already started having fun with the GDK.

First Impressions: Zeo Sleep Manager Mobile

I felt quite excited when my Zeo Sleep Manager Mobile arrived in the mail yesterday. I'm definitely not a morning person, and I feel like my sleep sometimes isn't satisfying. The Zeo promises to help these problems by letting you measure sleep quality, and by ringing the alarm at a less jarring point in the sleep cycle. This particular Zeo is a headband which communicates wirelessly to a mobile device.

Since I'm a mobile app developer, I have several different devices to choose from to use as a base station for the Zeo. For my first night with the Zeo, I chose to use my Samsung Galaxy Tab 10.1 (Google IO edition, what what!).

Fitting the headband wasn't too hard once I figured out that it could be adjusted with little velcro tabs hidden behind sock-like padding. The instructions in app were not very clear on how that worked. I thought I had an abnormally large head until I figured out the trick.

The first night went well, although I woke to loosen the head band several times to make it more comfortable. The band is comfortable and light once it is adjusted -- at least that is what one night of data tells me.

When I woke in the morning, I found that my Tab's screen was on (but black). I unlocked the device and the Zeo app was showing a nice chart of my sleep.

Oddly the Zeo never seemed to register me being awake at any point in the night -- I distinctly remember adjusting the head band several times. Also, it didn't register that I was awake at the beginning or end of my sleep period.

I tapped the sleep chart hoping to get an enlargement or more detail. Instead of that, the app crashed. I repeated this crash several times. The version 1.0 blues, I suppose. The good news is that I scored a ZW of 94 last night.

Tonight, I have started using the iPad 2 version of the Zeo app. Like the Android app, I was prompted to pair the head band with bluetooth. After succeeding with the pairing, I returned to the Zeo app. The app was unchanged: it still insisted that I pair the headband with my iPad. Huh.

I returned to the settings screen and verified that I was paired. Check. I returned to the Zeo app -- it still gave instructions on pairing. The app offered no buttons to continue, so I killed the Zeo app and restarted. Success! The app now recognized the headband.

Next I decided to sync the iPad app with the myzeo.com service. I entered my credentials, and got a infinitely-long spinny ring for my trouble (note: I didn't actually wait forever). Like before, I killed the app, restarted, and the app seemed to have linked with the service.

Ok, I'm clearly an early adopter here. This thing has tons of issues, but also lots of potential. Here are my suggestions for the Zeo team:

• Find and squish the crashes and hangs on the Android and iPad. You can rent devices if necessary. I would go through the initial pairing process 100 times per platform at least.
• Rent a usability lab for a week and have normal people set up a Zeo from box to bed without any guidance. You'll learn a ton -- and everyone will have fun if you do it right.
• Explain the headband resizing thing with either a ton of photos or a video in the app.
• Figure out some way to calibrate the Zeo for people who it thinks are never awake. Or maybe that is another bug. Zzzzz.
• Tell the users that the charger base magnetically attaches to the headband. I was confused (possibly because the magnets are weaker than those used in the magsafe connectors). Photos or videos go a long way.
• Provide some more real-time feedback in-app when the user is wearing the headband. I want to see my brain doing things!
• Tell the user a story, or at least walk them down the path of using the app for a week or month. Put it right in the app.

A lot of these suggestions apply to any app or consumer electronics device these days. If you make apps, you can definitely learn from Zeo.

That's all for now. I look forward to trying the Zeo with my iPad 2 tonight. I expect that the Zeo experience will improve a lot once the device has been on the market for more than a few hours.

Why Not to Make an iPhone App

When I tell business owners that I make iPhone, iPad, and Android apps, one of the first questions I hear is:

Is it worth it to make an iPhone app for my business?

I've been thinking about it a lot recently, and I think that the answer is usually NO. Your business probably doesn't need an iPhone app.

This sometimes feels a bit awkward. I think many people want an excuse to make an iPhone app, because apps seem clever or high-tech. Lets look at some of the difficulties in creating an app.

Ideas

You might have a clear vision of what your app would look like, but you also need a clear idea of what your app should do. If you can't explain exactly how the app functions, you probably shouldn't try making one.

All sorts of concepts may or may not work as an app. One way for them to find out is to write a detailed story about what the app would do from a user's perspective.

A sword fighter might write about his app idea:

As the user, I would tap the iFence app and first see a menu titled "I want to..." followed by a list of choices: 

defend myself from bullies, 

impress women, 

attack ships and steal gold, 

extinguish multiple candles impractically but dramatically, 

have a good costume for halloween 

When I tap a choice, a screen will appear which explains whether a sword fighter could help with the situation. In some cases the app will tell me "No, we can't help you with that, that's a bad idea. Please don't try." In other cases, the app will respond "Oh yeah, we can teach you to do that" and then explain how, and provide a way to contact a sword fighter.

After writing down the concept from the user's perspective it's possible to ask questions like "Would it be easy for the user to do this without an app?", or "How likely is it that somebody would look in the app store for a solution to the problem this app solves?"

If you can't do that, or if you can't explain how your app would be different from those apps already in the store, you may not be ready to get an iPhone app developed.

Cost

Developing an iPhone app is expensive. Unless you regularly exercise in a swimming pool full of cash, you might find the market rate for contract iOS app development a tad high. I don't have a statistically significant data set, but the rates I've heard are often numbers like $120, $136, $150, or $175 per hour. These are rates for one or two developers working from home or a small office.

If you contract with a team that has an office filling an entire floor of a high-rise and buys lots of ads online and in magazines, expect to pay more. You can find some data about how much it costs to develop an iPhone app here.

More complex iPhone apps typically involve a team of experienced designers and developers working a significant number of hours. Experienced mobile developers are not cheap, and they are often not easy to find or hire. I've personally interviewed several alleged iPhone developers who seemed unfamiliar with basic development practices. Buyer beware.

Also consider design. Although sometimes a developer is a decent designer, it isn't uncommon to have a dedicated designer working on the graphic elements and overall look of an app. Just because your website has graphics doesn't mean they will be suitable for the iPhone; graphics for the iPhone have specific technical requirements and different expected appearances. Mobile designers cost money too.

There are cheaper mobile developers on the low end of the market, but be sure to talk to their clients and see what kind of apps they have in the store. I have heard in one case of a "cheap" shop who failed to deliver a useful product after six months of development and many thousands of dollars of client money spent. The client had to switch developers to get the job done; who knows if they will ever recover money from the developer who failed.*

Focus

Expense isn't the only reason an iPhone app might not make business sense. If you have limited resources, you may wish to focus your efforts on a product that will work on PCs, Android devices, ChromeBooks,  MacBooks, and so on -- probably a web app. The market for iPhone apps is large, but web apps have an even larger audience.

Are you really sure that your customers will want to use your service on the go? Will they benefit from the extra features possible in a mobile app? If you already have a web version of your software, what do your analytics tell you about mobile browser usage? Are many of your customers trying to use your app from an iPhone? Are they spending much time on it?

If you already have a customer base and they don't seem to need an iPhone app, be sure that you couldn't better spend your time working on a different project.

Support

iPhone apps have support costs.You may not like getting one star reviews on the app store, or emails from unhappy customers, but it will happen if your app is popular enough. 

iPhone apps will require updates. You will almost certainly change your feature set, and Apple will change their devices. The risk of Apple breaking your app is low, but the risk of you adding a feature or needing an app update is high.

The chances that your users will find a bug in the app is high also. Even fancy, completely competent software developers create apps with flaws. It happens to everybody -- even Apple releases software updates to fix bugs.

Expect to spend some time and money keeping your app up to date. Version one is unlikely to be your last version -- unless your app is a flop.

Market Research

iPhone app market demand is opaque. You might make an app that there is very little demand for. Unfortunately, I know no way of seeing what customers are searching for in the app store. BatTracker Pro might be awesome, but unless someone is searching for bat tracking software, or your app gets featured, you won't make much money.

Online at least, you can research what folks are searching for on google, and you can try Adwords placements without actually having invested much. With the App store, there is some expectation of a nice-looking, well featured app even for version one. An ugly "coming soon" app will almost certainly be rejected by Apple, and will get low scores in the App store.

I have not seen evidence backing this up, but iOS developers seem to believe that releasing a low-rated app initially will hurt your success even after the app has been cleaned up and polished to look and perform like a porsche. I'm not sure if it's true, but it certainly discourages me from releasing an unattractive product for the purpose of market research.

Rejection Risk

Your app might get rejected or banned. Check out the review review guidelines (someone re-published the review guidelines here, but they may not be up to date) Although the app store rules are far more clear than they were in the beginning, there is always a chance that your app might get rejected from the store. You might even be lucky enough to add to the list of banned categories (e.g. fart apps).

Unless your app is cutting-edge from the rules perspective, this is unlikely to keep you out of the app store. Still, it's worth considering the possibility of rejection. Finding apps with similar features to your own is at least some evidence that Apple is likely to accept yours.

Conclusions

I've given you a few reasons why developing an iPhone app might not be as romantic as it initially seems. It mostly boils down to time and money. Or you might call it opportunity cost and expense. Could you spend your limited resources on a project with a higher rate of return?

iPhone apps are no guarantee of financial success; I've had a hand in at least two apps that only bring in tens of dollars per month in revenue. I suspect that better marketing and market research would have helped.

To make money in the App store, good execution and good marketing are a requirement. Just being there won't cut it. In many cases, a "boring" old web app works just as well, if not better, than an iPhone app at generating revenue. This is especially true if you research the demand in advanced of building a product.

Despite these warnings, there are many good reasons you should consider making an iPhone app. As an iPhone, iPad, and Android developer, I'm passionate about mobile apps. I make a living by developing iPhone apps for myself and my clients. There are opportunities to be had in the app stores, but they do require up-front market research and planning to make them a hit. 

*Note that I'm not saying problems can't happen at an expensive contract house. I've head whisperings of work on fixed-price jobs slowly trickled out to too many clients. Think about those construction projects on highways that never seem to have anybody working on them. Software is difficult, and software planning and management is even more difficult. Track records matter.

Subscribe for early access to future essays about Business in the App Store

TSA Opt-Out Day Update: Suspicious Bagel

The Daring Fireball reported on a passenger arrested after passengers reported his package to authorities. It contained a bagel, among other suspicious items.

I think the professor was arrested for being uncooperative, not for having a bagel. Just to play it safe, you can now screen for suspicious bagels in the TSA Opt-Out Day game.

None of the news stories reporting on the bagel incident have included an actual photo of the suspicious bagel, so I have created an "artist's" interpretation of the device. You can see it in the screenshot of the game to the left. If that isn't a suspicious looking bagel, I don't know what is.

Let me know in the comments if you know more about bagels and airplane safety.

Links:

Android-only link to the free TSA Opt-Out Day Game

Previous updates to the game and TSA news

The original TSA Opt-Out Day Android Game announcement