Tear-free App Updates

Have you seen those home improvement shows where a team of decorators surprises a family with an made-over house? The results cause more huge frowns, tears, and chaos than you’d expect.

Mom stares catatonically after discovering her Grandmother’s antique dresser holding the bathroom sink. Her hand leaves a fuchsia trail of Krylon on her jeans from the last minute paint job. Dad faints on the avant-garde cardboard lounge chairs replacing his beloved leather reclining couch. The kids roll on the floor and wail at their legos glued to the playroom ceiling.

The viewers marvel at the chaos, wondering what the decorators were thinking.

The same shock and disappointment hits customers when a company drastically changes their app:

Dear @Marriott - please go back to your old app - it worked perfectly.  Get rid of whoever designed the new one - it is awwwwful.

Bad app makeovers cause tears, and not just for poor taste. Large updates change how an app works. New features are emphasized and existing features are moved, removed, or altered. Our customers finds themselves stumbling through a new, unfamiliar interface, yanking their hair out, not getting work done.

When customers have trouble using a new version of an app, they don’t see a learning curve, or a beautiful new concept they should give time. They see low quality. They got stuff done on version 2. Version 3 leaves them fumbling like a toddler at nap time.

Customers know that they didn’t wake up dumber. The app changed and now they’re balding and can’t get their work done. The simplest explanation: the app sucks. One star — they’d give zero if they could!

We app makers often see quality as a one-dimensional measure. The app crashes, or it doesn’t. A feature works or it fails. Simplistic models of quality work for a while, but mature apps need a wider perspective. Measures of quality must incorporate customer sentiment and behavior. An frequent user of your app might prefer an occasional crash to a setback in usability or functionality. A crash is a temporary glitch; an inability to locate or correctly operate a feature leads to a cascade of hurt.

When users get stuck or make an mistake using an app, recovery is difficult. Who do they call for help? There is no AAA to come jump-start your app or tow it to the nearest app repair shop. App support hotlines are rare. Book stores don’ t sell Dummy’s Guides for your app. As app makers, we must anticipate and prevent customer issues so our users don't redline their frustration gauges.

The Great Skitch Update Debacle

Evernote proudly released Skitch 2.0 for Mac in 2012. It was a big moment for the company. Exciting blog posts. Press coverage. Customers reacted like we burned down their house. They wrote reviews that made us double over and clutch our bellies.

Internally, we saw Skitch as a visual communication tool. We worked hard on Skitch 2.0 addressing many shortcomings of the original app. We worked long hours fixing quirks and adding useful communications features. From our perspective at Evernote, the features we dropped seemed unimportant and a distraction from what we saw as Skitch’s purpose.

But we didn’t understand Skitch’s purpose. Our experienced users ached at the loss of features like FTP and custom fonts. To those customers, the features that went missing were key pieces in how they used Skitch. Skitch wasn’t just a visual communication tool to them. For some, Skitch was a tool for uploading images to their blog or website. Others used Skitch as a simple image editing package. Skitch 2.0 broke those workflows, forcing those users to use a different product.

How could we be so dumb? We didn’t control Skitch’s purpose. We could influence it, but the customers ultimately decide what they use the app for. Our team didn’t understand these customer perspectives until after we ruined their week. Like the interior designers on TV, we made drastic changes while ignorant of how people really lived in our app. Where we saw an ugly couch, our customers saw a cozy place to watch an action flick.

Evernote acquired Skitch in part for the passionate user base. We took great care. We didn't want to upset anyone or turn that passion against us. We sat for long meetings, testing betas, debating the user experience. Developers wrote code late at night, trying to get each feature ready for the big 2.0 debut. We put in so much effort that Skitch 2.0 took longer to release than planned.

Quarters of work, probably man-years of effort, and our customers still recoiled in horror. It doesn't matter how much we debated UX and reworked features. The success of an app lies with the customers, not the executive team, product management or the team building the app. That lesson arrived in an avalanche of 1-star reviews. Ultimately we apologized and promised to return the missing features. Too bad it cost us so much good will.

For the record, things have turned around for Skitch. Skitch 2.8 for the Mac has a five star average review. My Evernote friends have worked hard to make Skitch a world-class app.

More Growth Doesn’t Mean More Churn

Remember Skitch 2.0. Never forget your current customers as you scramble for growth or glory. Your best customers have learned every detail of how your app works, even the quirks and flaws. They’ve become experts in your app, probably even more so than you. Like a carpenter with a hammer, or a mechanic with a box wrench, they use your app without effort. They prize this ability because it gives them an advantage. It makes them productive.

If you alter your app too much, you steal their productivity. Skitch’s choice to remove features fell on the extreme end of the productivity-robbery spectrum, but even a simple reorganization of the app can break workflows. When the app no longer feels familiar, even long-time users fall to a novice skill level. Imagine a mechanic having to concentrate on their box wrench technique, or a carpenter having to relearn their hammer. They’d fall out of the zone, lose their happy thought. A forced return to conscious thought means slowing down. It robs them of productivity and leads to busted knuckles.

Even if your new design will make all users more productive in the long term, your formerly most productive users will grind their teeth. Minor productivity setbacks feel like getting stuck in traffic on the way to a party.

Hopefully customers won’t abandon your app before they return to productivity, because you’ve just created a moment with lower switching costs: “since I have to learn a new app anyhow, I may as well try something new.”

Don’t sacrifice your existing users just to attract new users. Customer growth depends on manageable churn rates, not just higher conversion rates. If you pop the balloon, you lose any gains from adding air faster. A successful app requires customer engagement in all cohorts, not just the tire-kickers drawn in by a pretty window display.

Planning Updates

I wish I could explain how to make everyone like your app updates. That's a fairy tale though. With a large enough user base, you will always have one customer scribing a zinger on the App Store. Some people just love to hate. The best you can do is mitigate customer pain by making conscious tradeoffs.

Like a family road trip, smoothly updating an app requires planning and staging. You can’t just drive from Florida to California without a break. Adults need to stretch their legs. Kids need stimulation and snacks. Everyone need bio-breaks, to eat food and hydrate. Transforming your app is a journey, for both you and your customers. You need to know your destination, how to get there, and where you can take breaks.

To craft high quality apps, you must orchestrate changes to take customer needs into account. Needs like: don't break my workflow. Or: don't let me get lost in an unfamiliar user interface. Or even: give me feature X. And, of course: don't let anything break.

Every change you make to your app adds a little risk to the proposition. Risk that customers won't be happy. Risk that the app might crash. Risk that customer data is lost. Who knows? Limiting the scope of your updates helps you manage risk. Smaller scopes mean faster updates, less for customers to learn, and the ability to respond quickly to customer feedback. Large updates compound that risk and also inhibit your ability to rapidly respond to customer feedback.

The journey metaphor is not without flaws. As you attempt to reach a beach oasis, you'll be camping in the jungle, climbing mountains, and fording rivers. The app may start to look a bit janky: some new bits of interface are slick and beautiful, while older parts of the app seem worn and tired. There are tradeoffs. Spending 6 months on an update that directly helicopters your users from 1.0 to 2.0 could be the right decision for your business (incidentally, there are more than 2 paths; you can helicopter your business focus to 2.0 while leaving the customers at 1.0).

What do You Want?

Start your update planning with self-knowledge. Why does your team wants to change the app? Are you matching competitor’s offerings? Reducing churn? Attempting to increase the average revenue per user? What results do you want?

If you have multiple goals for an update, prioritize. Pick one thing. Having one goal to per release lets you limit the scope of your changes. Big releases can overwhelm your customers. Spreading out the changes over time helps limit the burden on them. Save your second priority for your second update.

If you worry that your app looks uglier than a hippo’s rear, you can start a makeover without impacting the functionality. You don’t need to change how your app is organized, what vocabulary it uses, or how you make money. Hold those variables constant while you reign in the colors, pick more tasteful fonts, and improve your use of whitespace.

When you users open the re-skinned app, it will look cleaner and more modern, and their muscle memory will still work. Is that just putting lipstick on a hippo? Maybe. But your customers understand lipstick. Makeup is useful -- ask any actor. Customers won’t understand if one update transforms a hippo into a narwhale. People understand an ungainly hippo getting a makeover.

For your following release, maybe your goal is to add a new feature. Again, you keep the change surgical. You add the feature, but keep the appearance of the app, the overall organization of it, and so on. Let that change sink in for a bit before your address how the app is organized, or whatever the next stage of your update might be.

If you lose sight of the purpose behind an update, you will go overboard. Without focus, designers, developers, and product managers start to think that they “might as well” add X, Y, Z, and also Ƣ to the release. When you finally ship — and it will probably take a while if you keep glomming on features — your customers won’t recognize the updated app.

You must have the discipline to limit the scope of changes. Otherwise your customers will choke on their grande mochaccino and hurl their phone into the nearest storm drain. Clunk. Clunk. Splash!

After they upset your customers, these bloated releases hurt you again. Mistakes in a bloated release takes longer to fix than a tiny one, don't they? Bigger changes also make it more difficult to untangle the feedback you get. Return your gaze to the tweet about Marriott above. Can you tell what went wrong?

How Will Your Customers React?

Great updates require empathy. You can't make good decisions for your customers without knowing how and why they use your app. Some companies use customer personas to help them empathize with each kind of customer. They give their personas names, and sometimes even mascots (e.g. stuffed animals).

You might feel too shy to name your customer personas (Bobby the Ballerina!), but you should keep in mind how different categories of customer have different needs, workflows, and expectations. Your most active customers almost certainly have worn a path through your app. Know what those paths are. Customers won't smile if you obliterate their favorite path with a taco stand. Thanks for the tacos, but how do I get to the FTP feature?

Discovering your customer taxonomy will take some research if you don't already know. There are many tools to help you understand your customers: analytics, customer reviews, and other tools like Jobs to be Done interviews. Your app exists to serve customers. You better understand who they are!

In addition to personas, there are different stages of the customer lifecycle. For instance, most apps have both new and existing customers. A new customer can have a completely different reaction from someone familiar with your app. While you don't want to upset your best customers, you also don't want your new ones to bounce right out of your app and delete it!

Systematic Empathy

Once you know the different kind of customers you have, you can examine each change through their eyes. Make a spreadsheet of your customer taxonomy so your empathy rays don't miss anyone.

Here is one way to think about it. For each customer persona, add a column to indicate if a proposed change would go unnoticed by that kind of customer. For each persona who might notice the change, fill out a column indicate if they will be helped in the short term, helped in the long term, or hurt by the change. Add a final column where you will document your strategy to smooth the transition for this customer. If any of those strategies don’t seem trivial, that’s a sign that your update has grown too large. Consider breaking the update down into a chain of smaller updates.

Pro tip: you're allowed to talk to anyone. Test the assumptions in your spreadsheet with conversations, beta tests, and demonstrations! Even if you're speaking one-on-one with customers regularly, never forget to look at the reality of your releases. Analytics and reviews are real feedback from a broad representation of your actual customers. Use all of this feedback to steer your app's direction.

TL;DR

Why not take your users on a steady gradual journey over time? Why kick them out of the airplane over unfamiliar territory? This isn’t the 1990’s, where massive releases were the norm. People no longer hire the Rolling Stones or U2 to launch updates. The world has changed. Abandon the Massive Release Mindset! You’re not mailing CD-ROMs or floppies to users; there are no material costs to save by piling up major changes into one massive release.

The more incremental your updates to your app, the lower the burden on existing customers, and the more specific your analytics and reviews will be. Stacking up big changes just stacks the risk: risk your customers will hate it, risk that the changes won't work correctly, and so on.

Skyscrapers of change looks beautiful while they upload it to the store. Apps always look sleek and clever before customers touch it. The moment of truth arrives soon enough. The update goes out, someone shouts JENGA!, and now you have pieces of app littering the floor.

Or maybe you got everything perfect. What do you think? Can you reliably ship a massive update without bruising your business?

Sign up to get an occasional note on topics of interest like this. No spam.

More App Store Ad Experiments: Platform Targeting

Note: This essay continues from questions raised by the previous essay on A/B testing in the App Store. 

In my last essay, I explored some ideas on how to improve results in the App Store by experimenting with ads. I ran Facebook Ads to A/B Test the Click Through Rates (CTR**) of two different images.

Based on the differing CTRs, I jumped to the conclusion that the composition of the images made the difference. In one ad, an entire iPad was shown. In the other ad, most of an iPhone was cut off, except for the screen. In other words, I believed that the way I depicted the iPad or iPhone resulted in more clicks. I didn't doubt that I was one step closer to buying a tropical island.

Manton Reece read my article and immediately wondered if maybe the iPad vs. iPhone split could account for the difference. In other words, maybe folks were more likely to click on an ad that depicted the device they were holding in their hands. I immediately slapped my forehead. My app island slipped below the waves. I vowed to figure out what really happened with my last experiment.

TLDR: Manton was correct. Also, implementing the changes suggested by Manton’s hypothesis improved my CTRs quite a bit.

A New Experiment

To start examining the Manton Hypothesis, I first tried sifting through the ad data Facebook provides. Perhaps I could see which clicks belonged to iPads and which belonged to iPhones or iPod Touches*. Unfortunately I couldn't find that information. It didn't seem like I could examine Manton’s theory with the ad data I already collected.

No worries, I can find out with another experiment! The Facebook Mobile App Ads for Installs (!) allows the each ad to target a different device. Keeping the other parameters the same, I set the underperforming ad (the one with a photo of an iPad) to only target iPads. Even one day into the experiment, it seemed like Manton was correct. The CTR for the iPad photo jumped up nicely.

After a week and a half of targeting the iPad ad to the iPad, the CTR rose from 1.5% to 3.08%. Double!

I was so impressed, I decided to try the same thing for the ad with the cropped iPhone. I targeted it to only display on iPhones or iPod Touches.

This time I didn't expect to see a huge jump in performance. Why? Remember, in the previous article, the iPhone ad was already out-performing the iPad ad. If the Manton hypothesis was the only explanation for the differences in CTR, that implies that there were a lot more iPhone or iPod Touch users getting my ads. The diagram below shows how the ad with the iPhone Photo gets a higher CTR when both ads get the same mix of iPhone and iPad users.

As the diagram shows, the iPad photo (right side) gets a lower CTR because the viewers as a whole are dominated by iPhone users. According to the Manton Hypothesis, iPhone users aren't as likely to click on a photo of an iPad. That’s why the pie is smaller on the right, and why that pie is mostly iPad clicks.

But the iPhone photo has the reverse situation: the iPhone users still dominate, but this time they are seeing a iPhone photo. So in this case the majority of the users see a photo which matches the device in their hands -- a favorable situation. This leads to the bigger pie on the left. This time the less interested party is the iPad users. They are the smaller percentage of the folks seeing the ad. Their diminished CTR has a smaller impact on the aggregate CTR.

So, what happens when you target the iPhone ad at only the iPhone users? Just as the Manton Hypothesis predicts, the CTR improved, and the impact of targeting the iPhone ad to only iPhone and iPod Touch users wasn’t as large. The CTR for the iPhone photo the week before the change was 2.686%, and was 3.128% after the change.

Ad Description	Combined CTR	CTR Targeting only the pictured device
iPad Photo	1.5%	3.08%
iPhone Photo	2.686%	3.128%

Noise

But here is an important point: the lifetime Combined CTR when I was indiscriminately showing an iPhone photo to both iPhones and iPads was 2.931%. The baseline I picked for the numbers above were for the week before my change. The improvement looks pretty small when compared to the larger baseline. 2.931% vs. 3.128% doesn't seem as exciting as 2.686% vs. 3.128%.

Why was the week-prior CTR lower than the all-time CTR? I don't know for sure. The numbers I’m dealing with here are small. I’m not spending hundreds of dollars a day on ads, and I’m not getting a huge number of installs. I don't have a $50,000 advertising budget. These tests are being done for $5 a day.

My experiments here come from 1,000’s of clicks, not tens of thousands or millions. The sample size may not be large enough. What looks like an insight might just be noise. So take these results with a grain of salt. Or, even better, run your own experiments using your own money.

If you have a small budget like this project, the best cure for uncertainty is to hedge your bets and keep re-checking your assumptions. If you have real money riding on an outcome, it makes sense to double check your work. At the very least, be prepared to revert your changes!

Making a Model

I did have another idea for examining our results. What if we could mathematically model our hypothesis and see how it fits the data. I would feel more confident of the hypothesis if I could make a model that makes a decent prediction about a different data set.

One cool thing about these Ads is that we can see the size of the potential audience for each ad. The audience for the iPad Ad is 182,000 people. The audience for the iPhone Ad is 620,000 people. The only difference between these audiences is that one targets the iPad and the other the iPhone / iPod Touch.

So, lets make lots of assumptions about the size of the audience and the probability of getting a iPad versus a iPhone user. Lets assume that if we don't target the iPad or iPhone specifically, the probability the ad will be shown on either device is proportional to the size of the audience. For instance:

Probability(iPad) = 182,000 / (182,000 + 620,000) = 23%
Probability(iPhone) = 620,000 / (182,000 + 620,000) = 77%

So, now we can make some assumptions and create a model for the iPhone ad targeting both iPads and iPhones:

77% * sameDeviceCTR + 23% * differentDeviceCTR = combinedCTR

Or visually:

Now we can do algebra:

23% * differentDeviceCTR = combinedCTR - (77% * sameDeviceCTR)

differentDeviceCTR =  (combinedCTR - (77% * sameDeviceCTR) ) / 23%

now assume combinedCTR = 2.686% (the iPhone image CTR when targeting both devices) and sameDeviceCTR = 3.128% (the iPhone image CTR after targeting only iPhones)

then differentDeviceCTR = 1.2%

Now lets take the differentDeviceCTR we just calculated from the iPhone ad and see if it predicts the outcome for the iPad Photo ad in the same situation: targeting both iPhones and iPads.

In this case, the equation looks a little different because we're flipping sameDevice (now iPad, because we're considering the iPad image) and differentDevice (now iPhone):

77% * differentDeviceCTR + 23% * sameDeviceCTR = combinedCTR

Now we plug in the same numbers from before:

77%* 1.2%  + 23% * 3.128% = combinedCTR

combinedCTR = 1.64%

This model doesn't seem too horrible! It predicted 1.64% CTR for the iPad photo ad when targeted against both iPad and iPhone. The reality was 1.5%. I'm pleasantly surprised. Again, the Manton theory seems quite reasonable. I'll leave it to you to see what happens if we use the other iPhone photo combinedCTR of 2.931% baseline -- the model doesn't agree as well.

Conclusions

So what do we conclude from this exercise? For one, targeting your ads specifically to the iPad or iPhone user could be worth your time. I doubled the CTR of my under-performing ad with two clicks.

Even more importantly, running experiment on your ads can really pay off. And the steps aren't difficult: form a hypothesis, run an experiment using ads, collect the data, and make a simple model. With a model, you can try to predict the impact of your change.

With this first bit of new knowledge, maybe I'll save tons of money on ad spend. And then maybe I can apply what I learned to other areas of the sales funnel. And then I can try another experiment, learn, and implement. Maybe my tropical app island isn't entirely out of reach.

I’m really glad that Manton commented on my last article. Thanks! An extra set of eyes is invaluable!

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

*No, it’s not called the iTouch! Also, be aware that Facebook lumps together the iPhone with the iPod Touch. For certain questions that could be important.

** Yes, technically it should be TTR, not CTR, since you tap on an iOS device.

A/B Testing for the iOS App Store

Update May 1, 2014: Manton Reece had a great question about my results. Scroll to the end for details.

As someone with a career attached to the iPhone App Store, I sometimes feel jealous of the folks who sell things on the web. Websites can use analytics and split testing to learn lots of things about how to make their product more profitable.

In the App store, you feel lucky to see your sales numbers a day after they happen. If Apple tracks how customers found my app’s page, the number of visitors, or how much time they spent, they don't share it with me.

This shortage of information has interesting consequences. First, there are lots of tools out there that try to help developers figure out what's going on in the app store. Tools like SensorTower, App Annie, Flurry, and AppCase.

Second, you'll find lots of lore on how to boost rankings, get listed higher in searches for keywords, and how to get featured by Apple.

Finally, there are tricks we use to get better reviews in the store.

These techniques are nice, but they aren’t proactive or customer focused. Even the best of these tools tell you almost nothing about the organic traffic coming to your App Store listing. It isn’t even clear what impact an improved ranking in the app store has on conversions.

Am I supposed to take it on faith that efforts spent on improving my rankings will be repaid by increased sales? I want tools that help me build a product that customers want to pay for. I also want tools to make it easy for customers to find my product.

Rob Walling's book Start Small Stay Small advocates that a developer-entrepreneur worry about developing the product last. Finding a market for a product, and figuring out how to reach it are the first priorities. Once the entrepreneur has found a market, she can tailor the product to fit.

Can mobile app developers can do something similar? Can we learn about the market for our apps in spite of the opaque App Store, or are we doomed to just make apps and fight our way up the charts?

I don't think we're doomed. I've decided to stop treating the App Store like the mouth of Moving Average's customer acquisition funnel. Instead, I've been experimenting with Facebook's Mobile App Ads for Installs.

These ads are cool because you can target an audience based on the things users have expressed an interest in on Facebook. Not only that, but you can tap into some interesting data about who is clicking on your ads. Note that I’m not saying Facebook is the only solution. I hear that Twitter has some similar tools. I just haven’t had a chance to play with them yet.

My Facebook ads are now the mouth of the customer acquisition funnel. Each ad has a small amount of copy and a 1200 x 627 image. To make my first ad, Facebook requested two different images. Out of the gate, I would have an immediate split test! Cool. And now my customer acquisition funnel looks like the below image.

Note that I still have organic traffic that might throw off my understanding of who is getting through the checkout stage. Since this is an app that is relatively new to the App Store, and it doesn’t rank very high in any search or rankings, I can make some assumptions. The real benefit here is trying to understand why folks are clicking through the ads. I’ll be able to get a better handle on this when I install the Facebook library in the app — it is supposed to let you attribute installs to their ad campaigns.

To make my A/B test, I decided that one image would feature an iPad showing my app and one image would feature an iPhone.

I opened one of my existing iPad screenshots and realized that Facebook was asking for a strange image resolution. I spent some time experimenting on how to resize the asset from the app store to fit the Facebook ad. By the time I got the iPad mockup looking OK and then uploaded it, I was feeling impatient. Below is the image for the first ad.

Like I said, I was feeling impatient. I opened my iPhone mockup and haphazardly cropped off parts of the top and bottom of the phone so the image fit the required dimensions. Not my best work, but I figured I could always replace it. I uploaded the image and launched my ad campaign. You can see the haphazard image for the second ad below.

When I looked at my campaign the next day, which ad do you think was doing better? The second ad with my haphazard, off-the-screen iPhone! After seven days, the ad with the iPad image had a 1.6% click-through-rate while the iPhone had a 3.7% CTR. That’s a pretty big difference that held fairly constant.

With my next app update, I'll replace my first App Store screenshot image with something more like the winning Facebook ad. My hypothesis is that the continuity from the ad to the store listing will help sales. I'm also hoping that the organic App Store traffic will feel attracted to the image as well.

Let me know if you find this sort of post interesting and I'll try to write more about the business of selling a product in the App Store.

Update: Manton Reece of Core Intuition fame had a great question after reading my article, which you can read on App.net. Basically, he asks if the difference in ad performance could have resulted from the differences in iPad versus iPhone impressions. In my words, the hypothesis is: "Users are more likely to click on an ad that features the same device they view the ad on." One of the assumptions behind that hypothesis is that more of my ads are getting viewed on iPhones rather than iPads.

Unfortunately, I was unable to find a way to report the iPad vs iPhone split from the past impressions. Fortunately, the ads do allow targeting along that split. To test the hypothesis, I'm going to change the iPad ad to only target iPads. If the hypothesis is correct, I would expect the CTR to increase for that ad.

If that seems to work, I will also test targeting the ad with the iPhone against only iPhone users. The hypothesis would predict that ad would also get a higher CTR targeting only iPhones. The effect might not be as strong because, again, I assume more Facebook users view Facebook on the iPhone. Still, wouldn't it be wild if I could target each specific color of the iPhone 5c?

If Manton's hypothesis is correct, I've still made the correct decision for the app. I've already submitted an update where I replaced the first screenshot with an image that looks like the second ad, but matches the target device. iPad users on the app store will see an iPad with the top and bottom cut off. iPhone users will see the same iPhone as in the second ad.

Thanks Manton, I'll have a good laugh at myself if the image composition ultimately has nothing to do with the CTR! Even if the composition does have an effect, it's a great experiment. And I'm reminded again that getting third-party opinions and doing things in public is a good idea.

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

*Moving Average Inc. is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com. Buying items through this link helps sustain my outrageous camera addiction and is much appreciated!

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