Uproar Blog

We built Gratuitous in order to learn about developing and selling iPhone applications. We’re always looking for ways to improve our visibility in the App Store. Recently, though, we’ve been looking for ways to increase our visibility from outside the App Store into the App Store.

AdWords to the rescue! Right? Maybe not. AdWords didn’t work out for Gratuitous, so we quickly changed course and moved on. But I’d like to share our findings with you

Keyword Pricing

We didn’t know anything about AdWords when we started, so we kicked it off with default settings. We typed up our ad title and body, and hit “go.” The default setting in AdWords is to optimize for impressions (how many times an ad is displayed) by automatically bidding on clicks. For our keywords (iphone tip calculator), the bid went to $2-3 per click. While that may not be bad for a lot of products, it doesn’t make sense for an iPhone app that sells for $1-2. Even if you were able to get the cost per click down to $0.50 – $1, remember that an ad click doesn’t guarantee a purchase – far from it.

So, we switched over to manual pricing. We figured if we could get some clicks for $0.10 – $0.15, then they might be worth it. At that price, we didn’t see enough ad impressions to be worth our time. When bidding high we saw 3 clicks for 10,000 impressions. At 10 cents, the impressions went down to just a few per day. There is no way we’re going to see enough clicks to make that worth our while. If you’re selling a $10 app, then AdWords might be worth looking at.

Copyright and “Limited” Distribution

When we first submitted our ad, it went into review by the AdWords team because it included the word “iPhone.” It’s kind of hard to sell an iPhone app without saying “iPhone,” so we trusted that Google would see that our use of the term “iPhone” was an instance of fair use. After a few days, our ad was approved, but was marked as “Approved (limited).” Limited, to Google, means US-only. That was good enough for us, so we left it as is. If you need ad distribution outside the U.S. you can email Apple and ask them to approve your use in AdWords. Email lwidup@apple.com with your AdWords account number and a nice, friendly note.

Moving on

It’s pretty obvious that AdWords isn’t going to work out for Gratuitous, but apps are only part of our business. “Apps for your life. Consulting for your business.” Instead of advertising Gratuitous, we’re now trying AdWords as a way to generate leads for our consulting service. This is agile business. We tried something, quickly evaluated the results, and adjusted strategy decisively.

I resisted the temptation to spend a bunch of time becoming an expert in AdWords and going in 100%. There may be a way to make AdWords increase Gratuitous sales a bit, but it’s not worth our time. It’s clear that AdWords will not sell thousands of dollars worth of Gratuitous, so the experiment is concluded and we move on and adjust strategy. As a small business owner, I knew I needed to be quick and just test the waters. You’re going to do a lot of new things as a small business owner. Having a good sense for what to spend time on and what to do “just good enough” will be very valuable.

In case you haven’t heard, Gratuitous 1.2 was approved and is now available in the App Store.  Go grab it!

Right now, if you take a look at the Finance category of the App Store, you’ll see Gratuitous front and center.  If all goes well, we should remain on the Finance category home page for the next few days.  Perhaps due to this increased visibility, we had a significant increase in sales during our first day on the home page.  We understand that correlation is not causation, but we’re still hopeful this significant uptick in sales continues.

8/13/2009 update: Uptick continues! Day 2 sales were 18% higher than day 1.

How’d we pull this one off?

It’s a simple trick involving manipulation of your application’s availability date in iTunes Connect.  When set to the current date, your app will appear in your respective category sorted to the front of the list as by default, iTunes displays apps by release date.

The availability date is intended for developers who want a deterministic release date for their application in order to coordinate press and advertising around a known date.  This is common in the video game, music, and film industries where companies coordinate a media blitz around a specific date.  However, with the uncertainty of the App Store review process, developers do not know when their app will be approved.  Thus, companies can use the availability date to set a future date (after their app has been approved) so they can then coordinate press around this known release date.

However, most iPhone developers don’t coordinate media around applications, instead allowing the application to be made available immediately after it is approved by Apple.  Here’s how to set the availability date to maximize the exposure of your app each time you release an update.  These steps must be taken on the day your app is approved by Apple.

1. iTunes Connect > Manage Your Applications
2. Click Edit Information under your respective app
3. Click the Pricing tab
4. Set the Availability Date field to today’s date.  If this is set to a future date, your app will be pulled from the App Store and won’t be made available until this date.
5. Click Save Changes

This change will take a few minutes to propagate throughout the various App Store servers, after which your app will be shown on front page of its respective category.  Depending on the frequency of app releases in your category, your app could be on the front page for anywhere from less than a day to several days.  Being in the relatively quiet Finance category, Gratuitous should remain on the front page for around 5 days.

You might ask yourself why you shouldn’t just constantly adjust the availability date so that your app is permanently displayed on the category home page.  Well, Apple has this scenario covered by using either the lesser of the date your app was approved or the availability date set in iTunes Connect.  For example:

8/10/2009 – App or update approved by Apple
8/11/2009 – Availability date in iTunes Connect

In this case, Apple will use 8/10/2009 (the lesser date) for your application in the App Store.  This is why you should set the availability date to the same date your app was approved.  Additionally, setting the availability date past the approval date will simply cause Apple to withhold your app from the App Store until the availability date, after which your app will be listed with the earlier approval date.

Know of any other tips for fellow iPhone developers?  Leave a comment below!

After submitting the 1.2 enhancement to Gratuitous, we noticed some changes in iTunes Connect around the meta data you specify for your app and thought we’d share for the benefit of other iPhone developers.

Yesterday, TUAW ran a story about how Apple has recently allowed developers to add keywords to their application to help the search algorithm within the App Store.  The keywords, specified in iTunes Connect for each version of your application, are a comma delimited list of keywords in which the total length of this string cannot exceed 100 characters (note: after this article was published Apple reduced the limit from 255 to 100).  We haven’t been too impressed by the search algorithm within the App Store so it is encouraging to know that Apple is trying to improve the relevancy of the search results.

App Store Keywords for Gratuitous

On the left you can see the keywords we used for Gratuitous.  Should the keywords be organized by most relevant/important to least?  Are the relevancy of your keywords diluted with the more keywords you apply?  Unfortunately, we don’t know.  Other than a small blurb in iTunes Connect announcing the change, there is no additional information on this new field.

After finishing the submission for the upcoming Gratuitous 1.2, we noticed something interesting.  The new keywords field above was dithered and couldn’t be edited.  Looking further, the application name was also now dithered and couldn’t be edited.

Previously, you were able to update your application name display within the App Store at any time.  We took advantage of this when Gratuitous was initially released when we realized it wasn’t being returned for the search term tip calculator.  Updating the display name within the App Store to “Tip Calculator – Gratuitous” had an immediate positive effect to our search result ranking.

Last week, we changed our application name within the App Store back to simply “Gratuitous”.  We were curious if this would affect our search result ranking and frankly, it is the name we’d really like use.  Prepending the name “Tip Calculator” just doesn’t look good to us.  However, changing the name back to “Gratuitous” had an immediate negative effect on our search result ranking (so much so that Gratuitous isn’t returned in the first 150 results for the search term tip calculator).  Now that the application name can only be set once per version, we’re forced to wait until the 1.2 update is approved before our name reverts back to “Tip Calculator – Gratuitous”.

Thankfully, we already had 1.2 in the pipeline when these changes occurred.  Some developers have initially set the keywords field wrong (like not comma delimiting the terms) or want to modify it only to realize they will need to release a new version of the application in order to do so.  Releasing a new version of your application just to modify these two fields is a high burden for developers and introduces noise (in the form of a new app version) to your consumers.

In a perfect world, your application name should be set just once and set to your actual application name, not something to improve the search juju.  Additionally, keywords wouldn’t be necessary and the App Store search algorithm would return relevant results regardless of special terms developers set to try and improve their ranking.  Unfortunately, this isn’t the App Store we currently live in so remember to choose your keywords and application name carefully.

Update: 8/1/2009: Apple just updated the developer program portal news with information on keywords and app names that matches what we found and reported earlier in this blog post.

If you haven’t heard already, an update to Gratuitous was approved and made available in the app store.  With each update to an iPhone application, Apple allows the developer to provide information on what’s changed since the last version.  Here are the release notes for the changes to Gratuitous:

The feedback on Gratuitous has been overwhelmingly positive. Usability and design are very important to us at Uproar and judging by our reviews, our customers agree that we’ve hit the mark.

Two things, however, needed improvement. In 1.1 we improved the user experience of the common tips area by allowing you to touch and drag anywhere to make your selection. This is more consistent with other experiences on the iPhone. We also redesigned the icon to be more representative of the app.

We are in the process of developing and launching an improved brand for Uproar as well, so we took this opportunity to include our new logo in Gratuitous. Gratuitous is the only place you can sneak a peek at our new branding until our new website goes live in a few weeks!

This release also brings the code up to spec with iPhone OS 3.0.

However, here is how most apps would phrase this same update:

v1.1 changes:

• Common tips area is easier to use
• New icon
• New Uproar logo
• Updated to work with the new iPhone OS 3.0

Notice the difference?  The latter reads more like an engineer’s changelog rather than something your user would be interested in reading.  As developers, we tend to gravitate towards the terse changelog format as that is what we’re used to.  However, put yourself in the user’s position and frame the update text in something that is relevant to them.  Doing so will help you look at the update from the user’s point of view, something that they will certainly appreciate.

During the beta testing of Gratuitous, nearly every user reported the same problem.  Sometimes, it would take them several touches before the text field would register their touch and bring up the keyboard.  Digging into this more revealed that on the first touch of a text field, there would be a noticeable 1-2 second delay before the keyboard appeared.  All subsequent touches of any text field resulted in the keyboard appearing immediately.

I examined other apps and confirmed this issue was present there too.  Doing some digging online I found others’ apps had the same problem, but no one had a solution.  Some worked around the issue by immediately bringing up the keyboard on app load (a la the mint.com app).  This is acceptable provided it makes sense to immediately show the keyboard when the app starts.  Not so for Gratuitous.

To me, this initial delay during the keyboard load was a completely unacceptable user experience that we had to fix.  Left as-is, Gratuitous appeared very sluggish and initially unresponsive.  Ick.

Not deterred, I decided to try a little slight of hand with a hidden dummy UITextField and hiding the keyboard on initial load.  It turns out this slight of hand works pretty darn good.  So good in fact that when you touch a text field in Gratuitous, the keyboard appears immediately; even the very first touch.

First, add a dummy UITextField to your root view controller.  We need to make it the first responder on load which will invoke the keyboard.  Note that we’re hiding our dummy UITextField and disabling any user interaction with it.

- (void)viewDidLoad {
    [super viewDidLoad];
 
    dummyKeyboardLoading = YES;
    dummyTextField.hidden = YES;
    dummyTextField.userInteractionEnabled = NO;
    [dummyTextField becomeFirstResponder];
}

Now that our dummy UITextField is loading the keyboard, we need to make the keyboard invisible and disable any user interaction with it before it appears so the user isn’t aware of this initial keyboard load.  It is important to note that we maintain a boolean variable, dummyKeyboardLoading, so that we only hide and disable the keyboard on the initial load (and not subsequent loads).

- (void) keyboardWillShow:(NSNotification *) notification {
    UIWindow *window = nil;
    UIView *keyboardView = nil;
 
    NSArray *windows = [[UIApplication sharedApplication] windows];
 
    for (int i = 0; i < [windows count]; ++i) {
        window = [windows objectAtIndex:i];
 
        for (int j = 0; j < [window.subviews count]; ++j) {
            keyboardView = [window.subviews objectAtIndex:j];
 
            if ([[keyboardView description] hasPrefix:@"<UIKeyboard"] == YES) {
                if (dummyKeyboardLoading) {
                    keyboardView.hidden = YES;
                    keyboardView.userInteractionEnabled = NO;
                } else {
                    keyboardView.hidden = NO;
                    keyboardView.userInteractionEnabled = YES;
                }
                return;
            }
        }
    }
}

Finally, once our dummy keyboard has loaded, we need to make it go away by resigning first responder status on the dummy UITextField.

- (void) keyboardDidShow:(NSNotification *) notification {
    if (dummyKeyboardLoading) {
        dummyKeyboardLoading = NO;
        [dummyTextField resignFirstResponder];
    }
}

And that’s it.  In Gratuitous, this hidden preloading of the UIKeyboard is done while the paper is animating up onto the wood grain table when the app starts up.  This animation was the perfect spot to conceal the hidden cost of preloading the keyboard as the user is completely unaware.  The end result is a very responsive app and a very happy developer.

During the beta testing of Gratuitous, nearly all of the testers reported problems with the responsiveness of the app.  This included anything from difficulty registering a touch to sluggish UI elements.  How many apps have you seen that use the stock info (i) button where, try as you might, it takes a miracle just to register a touch on that button?  Or, apps that use the default slider control and its difficult to control blue dot?

If a user feels your app isn’t responsive, they’re not going to use it.  Here are a few lessons we learned during the development of Gratuitous that maximized the responsiveness of the app.

Don’t rely on the iPhone Simulator for usability testing
Within the first minute of testing Gratuitous on an actual iPhone, we quickly realized fields or buttons that we had no problem accessing in the Simulator, were now difficult using our fingers.  The mouse is a far more precise input trigger than your finger and can hide difficult to register hit areas.  This led us to the next lesson…

Don’t make touchable UI elements too small
The smaller the UI element, the smaller the hit area needed to touch the element.  Sorry guys, in this case bigger is definitely better.

Don’t make touchable UI elements too close together
Bunching up touchable UI elements just increases the risk that the user will accidentally touch a different element than they were intending.  When at all possible, give touchable elements their distance.

Provide a visual indication that the touch was registered
When the user touches an object, let them know their action was received via some sort of visual indication.  Take a look at Apple’s Calculator app, the behavior of the keyboard, or when you launch an app from your device.  By following Apple’s lead and providing a visual indication, your app will feel more tactile and responsive.

Beta test your app using someone who has never used a touch screen input device
We had a few people who had never used a touch device take the app for a spin.  Their input was great as it provided us a way to see our user interface through the eyes of someone who didn’t know what they could or couldn’t do (“I can touch that?”).

UX on a touch interface mobile device is different than traditional computer software.  Developers, we’d love to hear what you’ve learned in the course of developing your apps.

The curious case of the missing decimal point button on the Number Pad keyboard type is discussed in quite a few places on the interwebs.  The discussion around Apple’s decision to not include a decimal point button usually goes something like this…

Newbie: “Nice one Apple.  Where’s the decimal point button in the number pad?  The user can’t enter any decimal numbers using the number pad!”

AcidBurnDev: “You have to use the Numbers & Punctuation keyboard type instead.”

1337_Dev: “Or you could be 1337 and add a custom decimal point button to the Number Pad.”

CrashOverrideDev: “Log an enhancement to Apple about this.  I can’t believe they forgot this vital button!”

Newbie: “Great, thanks!”

For Gratuitous, we explicitly choose not to include a decimal point button on the Number Pad.  Didn’t we see all those examples and forum posts telling us how to add that button? (yep)  Are we just lazy? (yep…er, nope)

Let’s take a currency value of $1.23.  Every other tip calculator requires the user to tap the following:

1. User taps 1
2. User taps a custom decimal point button
3. User taps 2
4. User taps 3

Count ‘em.  That’s four taps and it turns out, it is one tap too many because you can simply infer it from the user’s input.  Going back to this example, here’s what Gratuitous does when the user taps those same values:

1. User taps 1, Gratuitous displays $0.01
2. User taps 2, Gratuitous displays $0.12
3. User taps 3, Gratuitous displays $1.23

Count ‘em.  That’s three taps and we’ve just saved the user time.  At this point everyone should be slapping their forehead and saying “of course that’s how currency input should be handled”.  In fact, that’s what we said too when we saw all of the other tip calculators sticking a custom decimal point button on the number pad.  Hopefully, this isn’t new to anyone (used an ATM recently?).

The above example was using USD currency locale.  Now let’s imagine a currency value of ¥123 (that’s Japanese yen).  Did you know that yen is only represented in whole amounts?  Thus, there is no decimal value for yen.  Including one in this situation does not present a very good user experience because a decimal point is unnecessary is some situations.  Aside from currency, number pads can be used for various types of input (credit card numbers, social security numbers, etc) that do not require a decimal point.

At Uproar, this is part of what keeps us up at night in our goal of designing applications with an excellent user experience.  Let us know how we’re doing.

(For those of you that frequent stackoverflow.com, portions of this post came from my answer to a question on this topic.)

Another post in the Gratuitous design series, this one on tax and its role in tipping.

We’ve seen reviews of other tip calculators where someone will give the app a bad review simply because it doesn’t offer tipping on the pre-tax value of the bill.  Despite knowing that some vocal people want tipping based on the pre-tax value, we left this option out of Gratuitous.  Why’d we do this?  Before we answer that, let’s examine the two ways tax can be taken into account.

Pre-Calculated
Some cities, countries, or establishments include the tip directly into the bill.  So, that $108 bill might actually be $100 + $8 (8% tax rate).  In this case, in order for Gratuitous to calculate the tip based on the pre-taxed bill of $100, we’d have to add a tax percentage rate field, allowing the user to enter in 8%.

Applied After
Other places may include the tip separately on the bill.  So, the bill amount would be shown as $100 with $8 for the tax (based on our 8% tax rate).  Depending on how explicit you want to be with the support of pre-tax tipping, Gratuitous could have a tax dollar amount field, allowing the user to enter in $8.  Alternatively, you could eschew this extra field and the user could just simply enter the pre-tax amount in the existing bill field.

So, in order to correctly calculate the tip before tax, we’d have to add a tax rate percentage and possibly a tax amount field (depending on how taxes are included in the bill).  Sure, we could be clever and combine these two fields into a single field that is toggled between either percentage and a fixed amount.  Now, where should this single toggled field go?  Wherever we place it, it would need to have some sort of an explanation to prevent user’s from being confused over this new field allowing user entry.

We really dislike extra clutter in the UI.  We’re pretty vigilant about this considering the screen real estate is at a premium on the mobile platform.  So, finding a good spot for this additional field (or two) would be challenging.

However, the primary reason why we didn’t include tipping based on the pre-tax value is that we’re confident the majority do not tip this way.  Additionally, most tipping guides will recommend tipping on the post-tax amount for a variety of reasons (wait staff tip out after tax, expected norm, etc).  As to not compromise the design for the majority who would never use this functionality, we made the decision to leave it out.

So, if you tip before taxes, the best we can offer you is to tap in your pre-taxed bill (assuming the check has the tax broken out).  For those who tip on the full amount, be Gratuitous!

Another post in the Gratuitous design series, this time on rounding.  Ah, rounding.  Other tip calculators have up to nine ways to round.  Gratuitous has one.  Staying true to our philosophy on design, we’re not interested in building a huge feature list but rather providing just the features that make sense and are necessary.  Let’s go through each of the rounding methods to find just the one you need.

Round Tip

If you find yourself wanting to round the tip amount, it is most likely because…

• You are leaving cash for the tip
• You want to write in a rounded tip amount because its easier than writing an exact tip.

In the first scenario, a tip calculator would only be used to show you what percentage you are tipping based on the cash tip.  With Gratuitous, you can do this by simply entering the cash amount in the custom tip amount field.

The second scenario defeats the purpose of a tip calculator.  Namely, that it calculates the exact tip for you.  Again, you can still use the custom tip amount field to specify your rounded tip amount.

Round Per Person Total

This rounding option falls into the category of a feature thought up by a programmer but completely unnecessary in actual use.  Take the following scenario…

• 3 friends, Tom, Dick, and Harry go out for lunch
• The total un-split bill comes to $45.36
• The 3 friends agree to leave an 18% tip with Tom paying the bill

Tom’s a smart guy and uses Gratuitous.  Tapping in the values, he sees that the bill + 18% tip comes to $53.52 ($17.84/person).  He tells his friends Dick and Harry that they owe him $17.84 for their portion of lunch.

Dick writes Tom a check for $17.84.
Harry gives Tom his only cash, a $20 bill and asks just for $2 back (Tom obliges).

This is what happens the vast majority of a time when a party has to split the check.  When you walk through this common scenario, it is clear that it does not make any sense to round the per person total.  You tell people exactly what they owe you and at that point people do whatever they think is appropriate.

Round Total

Finally, we have arrived at the only rounding option which makes sense.  You have a bill, want your total amount rounded (so it looks nice on your statement), and need to know the exact tip amount to ensure a rounded total.  Naturally, this is the only rounding method available in Gratuitous.  However, we’re not done yet.

Up, Down, Half-Up, Bankers, etc

For each of the above rounding methods, you can round up, down, half-up, via bankers, or a myriad of other ways.  Other than up or down, these other methods require an explanation, both adding complexity to the app and potential confusion for users.  Do you really need that much fine-grained control over rounding at the expense of the previously mentioned complexities in the app?  Hopefully, you agree that the answer to this is no.

That leaves us with just round up or down.

For Gratuitous, we went with the single option of rounding the total up.  Staying true to the name of the app, rounding up benefits the recipient of the tip; at most an extra 99¢.  For anyone who feels the extra change is not deserved, our guess is that you either:

• Never use rounding in the first place
• Wouldn’t pay for a tip calculator like Gratuitous

At this point you can see the thought that was put into deciding how Gratuitous would deal with rounding.  While we could have put every option but the kitchen sink into Gratuitous, we choose to include just what make sense.

Our last blog post touched on the reasoning behind Gratuitous and as part of that, we stressed the importance design plays in our software.  While the idea of a tip calculator is fairly straightforward, achieving a design we were pleased with required quite a bit of work.  This post is the first in a series on the design of Gratuitous.

Presentation

Features and functionality alone are not enough to draw users to your app.  Presentation is a key element that, if done well, will serve your functionality in an appealing way.  In Gratuitous, we went with the design of a paper on a wood grain surface.  This is reminiscent of a bill at a restaurant but presented in a more visually attractive manner (an actual receipt, while obvious, does not provide for an appealing UI).

Our focus on presentation started with the loading of the app.  Most apps present the static loading image and then, when the app is finished loading, the screen switches to the app, resulting in a a jarring effect for the user.  With Gratuitous, we seamlessly transitioned from the loading image to the application by animating the paper onto the screen without breaking from the loading image.  This took a bit of time to get it just right but we think the results were worth it.

It was important to us that this paper on a wood grain surface was consistent throughout the entire app.  For instance, when you tap the gear button, only the paper flips over to the reverse side.  This maintains the visual theme of the app.

Immediacy

Prior to prototyping the user interface, we discussed design goals we wanted to achieve.  One such goal was immediacy in the understanding of the use and the information Gratuitous provided.

Immediately upon starting the app, you are presented with three of the most commonly used tip percentages and your own custom tip percentage.  At a glance, the tip amount and total for each tip percentage is clear.  Presenting this information up front allows you to quickly view your desired tip percentage without any interaction.  Thus, the majority of the time you simply need to enter your bill amount and you’re done.

Have a tip percentage that you always use?  We’ve saved it for you from your last session.
Received less than optimal service?  Tap one of the lower common tip percentages.
Received great service?  Tap one of the higher common tip percentages.

We’ll follow this post up with further posts in the series touching on specific topics in detail.  How do you think we did the design of Gratuitous?