Uproar Blog

Rebrand

We launched Uproar in an instant.  We incorporated, threw up a web site, and started building software.  This is the right way to start a company. A lot of people start things; be they companies, blogs, clubs, or bands; by making a logo, choosing colors, writing mission statements and business plans, and yada yada yada.  Those are the wrong things to focus on when you’re starting something.

Once we got our first product out the door and people started paying attention, then we knew it was time to put our efforts back into the company.  So we’ve recently relaunched the Uproar brand.

When it comes to building a company and a brand, you get a lot of do-overs.  That’s one of the reasons you don’t need to spend your first burst of energy creating a logo.  But there is one thing that is very hard to mulligan, and we got very lucky because we hit a home run on it: the business name.  We’re very proud of the name Uproar and we’ve had nothing short of 100% positive feedback on it.  If you don’t love the name Uproar, please leave a comment – I need knocked off my high horse.

Since we got step 1 right, we started looking at options for colors, a logo, and our brand.

Type & Icon

The new Uproar logo is both typographic and symbolic (not to be confused with iconographic).  I love typography, so I wanted to use a strong, identity building typeface for Uproar.  I chose Gloriola by Suitcase Type Foundry.  Gloriola serves Uproar well because it is a strong, modern, but classy typeface which will stand the test of time and comes in a variety of versatile weights.

Although there are some very good examples of type-only logos (or logotypes), such as Coca-Cola, Microsoft, Google, and id software, I wanted to have a logo that included a graphical element that could be used in isolation as an icon, an avatar, etc.  Examples of logos like this are NBC, 37signals, and Pepsi.

We went through a lot of different iterations on our logo (I’ll post a design exploration if anyone is interested – leave a comment or @ me on twitter).  We wanted something that represented our personalities and really paid off a name like Uproar.  We went with fire and landed on an illustrated flame which I quite like.  This simple shape works at many different sizes, in 1 color, 2 color, or full color, and it gives the right first impression.

Versatility

Versatility was very important to me with the Uproar logo.  The type can work on its own if needed.  ”Uproar” in Gloriola all by itself still carries our brand quite well.  Likewise, the flame by itself is a memorable graphic element that evokes our brand image.  This versatility lets us span the Uproar brand consistently across all media, be it a business card, t-shirt, web site, favicon, avatar, bumper sticker – you name it.  You won’t see the Uproar brand looking out of place. That versatility reinforces the brand of thoughtful, flexible, resilient software that we build.

Pictures of real people

Uproar’s biggest challenge is that no one knows about us.  We don’t have industry notoriety of our founders to rely on (yet).  Therefore, it’s very important that someone’s first impression of Uproar is that we’re a couple of real people — real professionals — not just a web site.  I asked my friend, and amazing photographer/designer, Josh Okun to take our picture.  It turned out great – thanks Josh!

What do you think?  Is having our picture on the homepage a positive or a negative?

Simple, direct message

Also because we’re new, we wanted to have a direct and clear message that describes what Uproar is about.  We sat down one day to talk through what we think sets Uproar apart. The exercise revealed that we combine design and engineering to create an overall best-of-class experience for the user.  This goes beyond just getting a good designer and a good programmer.  Doing this effectively means that all members must be able to significantly contribute to that unison.  It is the nuanced and experienced manner in which we meld these two things together — to the point where they do not exist in isolation during the build process or the final product — that we want to convey.  Do you see how hard that is to explain?  We explained it with a simple infographic that employs the philosophy itself:

This equation is our story.  In Seth Godin‘s book All Marketers Are Liars, he teaches you to tell stories about your company or product.  Good stories get retold; they endure; and they are pervasive.  Stories are way more effective than ads.

Recency

The final, but possibly most imporant thing we did on the homepage was to include “recency.”  We have our blogs titles, tweets, and most recent work on the homepage.  In my experience there are a lot of small business web sites out there that look nice, but you get the idea they were created over a year ago and the company might not even still be operating any more.  This is a “first impression” play, but it’s even more important on the second impression.  If you’re lucky enough that someone comes back to your web site, then you have a chance to show them that you’re an active and vibrant company.  You have the tools to do this — Twitter, blogs, etc. — so you’d better feature them on your homepage!

What could be better?

We could easily tweak this for weeks or months longer, but a small business needs to be quick and deliberate.  We designed a logo, shot photography, built a site, and launched it all.  It was a lot of work, but I’m pleased that we go it done in a timely manner.  Looking at the site now, there are things that could be better.  Most notably, the links in the lower-right corner of the photo don’t stand out nearly enough (unless you’re on the iPhone-specific version).

I want to hear your feedback.  What could be done better?  What do you think we did well?  Finally, if you made it all the way down through this post then you’re a trooper – thank you for reading.  @ me on twitter and tell me your favorite part of this post and we’ll get you a redeem code for Gratuitous.  I know you already have it, but you can give it to a friend or loved one

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.

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?

With the release of Gratuitous, an obvious question is why another tip calculator?

At the time of this writing, there are around 23,000 applications in the App Store.  With that number, there are very few unique applications.  Indeed, there are several tip calculator apps on the market.  We knew this prior to starting work on Gratuitous yet it did not deter us.  Why didn’t we write an app that’s completely unique and new?

Design

We had been discussing writing software together as Uproar for quite some time.  Regardless of the platform our ideas were intended to live in, there was always a common mantra: design is king.  We both wanted our software, whatever it may be, to be driven by beautiful design.  Of the apps that we use, admire, and strive to be as good as, the common thread is an incredible attention to design.

Gratuitous went through several design iterations (including a complete re-write of the UI) before we both were happy with the final result.  We discussed and debated each and every tap, UI animation, and feature.  Yes, we knew there were several tip calculators already out on the App Store but we wanted ours to stand above the rest in terms of look, feel, and usability.  We wanted the design of Gratuitous to separate us from the pack.

Just What You Need

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. –Antoine de Saint-Exupéry

When we discussed the functionality of Gratuitous, we came up with every scenario we could think of.  Then, we began culling that list down to the scenarios that are used around 95% of the time and focused on doing those really well.  Some examples of features we purposely left out (many of these will get their own blog post later):

• Lots of intricate rounding options
• Complex tip calculation rules (eg, pre-tax, checksum)
• Complex bill splitting (eg, drinks, meal percentages)
• Settings for micro-customizations

For instance, we know some people really insist on tipping based on the pre-tax value of the bill.  To each his own, but Gratuitous is not written for these people.  Such oft-used features tend to complicate the design at the expense of the majority of users.  As programmers, we try and include every option to satisfy all scenarios.  As designers, we only include the options necessary to satisfy the most common scenarios.

Start Small

While both of us are experienced developers, Gratuitous still presented a lot of firsts for us.  Our first time working together on a business venture.  Our first foray into programming in Objective-C and the Mac development environment.  Our first iPhone and iPod Touch application.  As such, we felt it important to start small.

A tip calculator was therefore a great first application.  Its purpose is fairly well defined, calculating a tip is something we’ve all done, and if done well, the application will provide value to those using it.  Rather than try and swing out of the park, we stepped up to make a solid base hit.

How did we do?  We’re pretty proud of our work and we hope others think we did well too.  Let us know what you think of Gratuitous, we’d love to hear from you.