Gently Guiding Users to Do the Right Thing

Imagine that you are designing a mobile app that lets users add a profile picture via their phone's camera. How would you go about preventing users from uploading pictures of their 'naughty bits' as their profile pic?

One option might be to do advanced image analysis on the picture once it has been taken. This could potentially be a very good way to weed out images based on their similarity to forbidden images. Unfortunately, this adds complexity to the system since the image analysis algorithm needs to be developed internally or selected from off-the-shelf components. In addition, this design implies that the user's profile pic probably can't be added immediately to their profile. No matter how fast the image analysis algorithm is, the feature will never really feel quick.

Let's say you decide not to go the sophisticated route. Another option might be to put a warning on the screen before the camera is displayed to the user. That's a very inexpensive option since you only need a warning dialog prompt or perhaps just warning text on the screen. Unfortunately, you never want to be in a position of telling users to "Please don't poop on the tables" if you can avoid doing so. While trying to catch the small percentage of users that were going to do the wrong thing, you end up admonishing the majority of users that were going to do the right thing.

The best solution is simple: display the front-facing camera by default. The user is most likely interacting with your app in a way where their face would naturally be aligned with the front-facing camera. The path with the least amount of friction is the path we want the user to take. The user simply launches the camera and snaps a photo. No muss, no fuss.

This simple user interface design choice helps to reinforce the idea to the user that they should take a photo of their face and not their naughty bits. In fact, it would take more effort to switch to the rear-facing camera than it would be to simply tap the shutter button.

Folks, sometimes users just need a gentle push in the right direction. Trust that your guidance will lead to the desired result.

You Can Afford to Design with Affordances

There is a refrigerator at the office that has both a water dispenser and an ice dispenser. The first time that anyone new to the office attempts to dispense a cool, refreshing glass of water ends with that person being splashed with water.

Care to guess why?

The design of the water dispenser is unexpected. In fact, many people first attempt to push their cup against the curved metal plate in the back (which dispenses ice, not water). After realizing that they pushed the wrong plate, many people will push the flat metal plate at the top (which does in fact dispense water). Unfortunately for them, they usually push the water dispensing plate while keeping their cup adjacent to the ice dispensing plate. As you may have noticed from the picture, the water is dispensed from the tiny spout at the top of the dispensing nook.

The end result? Splash.

Why does this happen? Why don't new users immediately grasp how to use this dispenser? Quite frankly, because the designers of this dispenser didn't make proper use of affordances.

Affordances provide users with a hint as to how something is to be used. They take the infinite number of possible actions that might activate a feature and reduce those possibilities down to the proper actions. The critical quality of an affordance is that it must be obvious.

The designers of the water/ice dispenser made a mistake by having the water dispenser's plate be flat in shape. There isn't anything about a flat, vertically-oriented metal plate that says 'push a cup here'. In contrast, the ice dispenser's curved, vertically-oriented plate practically begs you to push a cup against it.

The ice dispenser's curved plate arguably makes things more confusing for the user than having a flat plate would in this instance. The ice dispenser's affordance attracts the user to keep their cup located in the wrong spot in order to successfully dispense water. Ideally both plates would be curved, or neither plate would be curved.

Folks, take care when designing your user interfaces. Make sure that you are creating affordances in the design that make things easier for your users. They will thank you for it.

Bonus Content:

The folks at Extra Credits have a great video on the use of affordances in game design.

My Two Cents on BlackBerry's 'App Neutrality' Nonsense

John Chen, CEO of BlackBerry, discussing his concept of 'Application/Content Neutrality':

Unfortunately, not all content and applications providers have embraced openness and neutrality. Unlike BlackBerry, which allows iPhone users to download and use our BBM service, Apple does not allow BlackBerry or Android users to download Apple’s iMessage messaging service. Netflix, which has forcefully advocated for carrier neutrality, has discriminated against BlackBerry customers by refusing to make its streaming movie service available to them. Many other applications providers similarly offer service only to iPhone and Android users. This dynamic has created a two-tiered wireless broadband ecosystem, in which iPhone and Android users are able to access far more content and applications than customers using devices running other operating systems. These are precisely the sort of discriminatory practices that neutrality advocates have criticized at the carrier level.

Therefore, neutrality must be mandated at the application and content layer if we truly want a free, open and non-discriminatory internet. All wireless broadband customers must have the ability to access any lawful applications and content they choose, and applications/content providers must be prohibited from discriminating based on the customer’s mobile operating system.

Remember when BlackBerry (née Research in Motion) joyfully joined the Apple Developer Program and launched its market-leading BlackBerry Messenger service for iOS as soon as it was possible to do so back in 2008?

Wait, that never happened. Must have been an alternate universe.

Instead, what happened is that BlackBerry refused to open its messaging client to Apple's users. Why did they not do so? Because they were the market leader at that point in time.

What has changed in the intervening years? Quite simply, iOS and Android have given BlackBerry the old heave-ho off the top of the mountain. As it turned out, the BlackBerry Messenger service was not valuable enough to keep customers loyal to the platform. The superior user experiences provided directly by Apple and indirectly by Google won the war. The market spoke, and it spoke clearly--BlackBerry was no longer relevant for today's users.

Chen's statements are ludicrous. He attempts to conflate 'net neutrality' with his bogus concept of 'app and content neutrality'. Despite having similar-sounding names, the two concepts are worlds apart in meaning.

The basic underlying principle of net neutrality is that the so-called 'gatekeepers' of the Internet (e.g. Internet Service Providers) should not be allowed to interfere with the natural open market. Take, for example, the time that Comcast (allegedly) throttled Netflix's video streaming performance in order to get Netflix to 'pay a toll' for good performance. That's a perfect example of a gatekeeper exerting undue influence on determining the winners and losers in the market.

The basic underlying principle of app and content neutrality, as proposed by Chen, appears to be the idea that marketplace participants should be required to make investments that benefit their competitors. On the face of it, this is an absurd requirement. Is there a minimum threshold for a competitor to qualify for this standard? Should Apple and Netflix be required to spend the time and resources supporting Ubuntu's smartphone platform? How about Firefox's smartphone platform? Companies would quickly go out of business if they had spend money to support every conceivable competitor.

On the one hand, you have a concept that is better for the market by preventing gatekeepers from strangling market players. On the other hand, you have a concept that is worse for the market by requiring market players to take actions that are detrimental to their own businesses.

Chen is correct about one thing, though. There is in fact a 'two-tiered' ecosystem--the good choices (i.e. iOS and Android) and the terrible choices (i.e. BlackBerry and Windows Phone). Microsoft learned its lesson by realizing that, in order to stay relevant, it had to make its services available everywhere. BlackBerry should do the same without trying to force others to pay for its own business mistakes.

Folks, don't be fooled by this nonsense.

Please Don't Poop on the Tables

At one point in my career, I was caught in the middle of a contentious change to an app's user interface. The app allowed users to communicate with each other about products via a chat feature. One side of the team wanted to add a disclaimer that said something to the effect of 'Please don't use Feature X to ask about blah blah blah. Use Feature Y instead." The other side of the team didn't want to add this disclaimer because 'people won't read the disclaimer and it clutters up the UI'.

I was on the side that didn't want to add the disclaimer. In my view, the reason that some users misused the chat feature (and therefore annoyed other users) is because the user interface did not make the correct choice obvious to users. Adding the disclaimer felt like we would be admonishing users for our design mistakes.

The 'add a disclaimer' side of the house was not convinced. The debate raged on for quite some time until I was able to break the stalemate with a hypothetical situation. I told my colleagues (paraphrasing here):

Imagine that you went to a restaurant for dinner. As you approach the door, you notice a sign that says "Please don't poop on the tables". Would you eat at that restaurant after reading that sign?

I suppose that the proprietor of that hypothetical establishment might have had a perfectly good reason to put up such a warning sign. Likewise, the folks that wanted to add a disclaimer had a perfectly good reason in mind. Unfortunately, the intended effect (avoiding unwanted behavior) is overshadowed by an undesirable effect (scolding users when they haven't done anything wrong).

Folks, we all know that users probably won't read the manual. The best way to handle undesirable behavior is to guide users towards the correct behavior with an excellent user interface. Avoid telling people to not poop on the tables.

Fail Faster

The fine folks over at Extra Credits have an excellent video on a topic that is near and dear to my heart: failing faster. The gist of the video is that it is important to learn how to use tools such as low-fidelity prototypes to validate an idea. The key takeaway is that you want to learn from your mistakes as quickly and as cheaply as possible. Waiting until you have the perfect idea all figured out takes too much time (and really, you won't have it all figured out). Likewise, immediately jumping into writing code means that fixing your mistakes is much more expensive to do (and you will be more hesitant to do so).

I have personally been involved in this type of situation many times throughout my career. In one particular instance, I was part of a team working on a new major feature for an app. Unfortunately, the development process devolved into 'prototyping in code' as major changes were made on a daily basis to the visual design, user flow, and business logic of that feature. This was a terribly expensive way of figuring out how things should work. When we tested the feature with a few handpicked users, the flaws in our design were immediately obvious. We thought that the design was generally good and understandable (albeit with a few rough edges), but the participants in the user testing pointed out sizable problems with the design that made it clear that this feature was not ready to ship. It's as if we were blind to our own design.

After this particular experience, I championed the idea of using interactive prototypes for further design iterations. Each design iteration consisted of 'tappable screenshots' that our test users could try out and use to provide us with feedback. Making changes to a particular screen or to the user flow was as simple as dropping in a new image file from Photoshop or designating a new tappable area on an existing screen. The turnaround time for these changes could be measured in minutes or hours instead of days and weeks. In the end, the ability to 'fail faster' with the interactive prototype helped to make the feature better in a shorter period of time than what could be done with code.

Folks, I know it can be tempting to immediately jump into code; that's pretty much what developers are inclined to do. However, understand that it may not always be in your best interests to do that. Find cheaper and faster ways to validate your ideas.

Bonus:

There are many different tools that can be used to help you 'fail faster'. These are the ones that I use on a regular basis:

• Pen and paper or a whiteboard - you really can't get much faster and cheaper than this.
• POP (Prototyping on Paper) - this app makes it easy to take a photo of things that I have made in my sketchbook or whiteboard and add tappable hot zones with transitions.
• InVision - this web app provides a lot more horsepower in terms of the transitions, collaboration, and version control that it supports. I use this with Photoshop mockups to provide a more "real" feel than what POP provides.

The Windows Store is Filled with Scam Apps

Chris Hoffman, writing for How-To Geek about app scams in the Windows Store:

Why doesn’t Microsoft care about the cesspool of garbage they’re hosting and offering to hundreds of thousands of Windows 8.1 users? The only answer we have so far is that Microsoft doesn’t care how good apps are — they’re just approving everything to get as many apps as possible. It’s been nearly two years now, and we haven’t seen any indication Microsoft actually cares about the pile of garbage they’re hosting.

The various app stores have their fair share of problematic apps. Google Play, with its focus on automated store rule enforcement, allowed a scam anti-virus app to become the #1 paid app. Apple's App Store, with its focus on manual store rule enforcement, allowed a bootleg Pokemon game to become the #3 paid app.

However, in both the App Store and Google Play examples, these scams were the exception rather than the rule. The numerous examples illustrated by Hoffman in the linked article are damning for Microsoft. While Hoffman's stated reasons for why Microsoft allows these blatant scams to exist is pure speculation, it is speculation that makes a lot of sense. Microsoft's Windows Store and Windows Phone Store are woefully behind the App Store and Google Play in terms of quality and quantity of apps. There is no subjective way to measure the former, but the latter is easy to measure (and is arguably even easier to inflate). There is a strong incentive to increase the number of apps in the Windows Store.

Folks, we all know what happens to an app store's credibility when it allows such garbage to become commonplace.

Don't Be Too Hasty To Do-It-Yourself or Pick-Something-Off-The-Shelf

A common question I get from folks that want to create an app or website with a backend system is what I would recommend they choose for a toolset. Should they use something baked into the platform like iCloud? Should they use a multi-platform service like Parse or Heroku? Should they write their own backend system from scratch?

The answer? It depends.

Honest. That's the truth. That's not an attempt to evade the question.

Rather than immediately jumping to answer the question, I always ask my own question to gain more context:

What are you trying to accomplish?

There are two different ends of the spectrum for that question. On the one hand, you have the Marco Arment (formerly of Tumblr and Instapaper) camp:

The common wisdom, which Justin suggests, is to go directly to a highly abstracted, proprietary cloud service or a higher-level hosted back-end — the kind that are so high in the clouds that they call themselves “solutions”. But the “BaaS” landscape is still very unstable with frequent acquisitions and shutdowns likely, and hosting on VPS-plus-proprietary-services clouds like Amazon Web Services or higher-level services like Heroku or App Engine can get prohibitively expensive very quickly. Developers who build everything on these services by default would probably be shocked at how cheaply and easily they could run on dedicated servers or unmanaged VPSes.

On the other hand, you have the Brent Simmons (Q Branch / Vesper) camp:

Well, my first thought was I don't want to run an actual server. I don't want to do that. Life's too short; I have to write code.

I often see debates on Twitter, blogs, or podcasts about the merits of both approaches. Depending on the particular biases of the author or host, the result is typically choosing one of the two extremes. Before jumping into one side or the other, however, it's important to understand the fundamental assumptions being made and what each side is attempting to accomplish.

The fundamental assumptions behind the Do-It-Yourself side, as exemplified by Marco, are that you are trying to create something that will need the greatest amount of flexibility and independence. By picking this extreme, you are deciding that the control over your own destiny outweighs the burden of creating and continuing to maintain your own backend solution.

The fundamental assumptions behind the Pick-Something-Off-The-Shelf side, as exemplified by Brent, are that you are trying to create something that will need the least resistance in reaching fruition. By picking this extreme, you are deciding that the effort saved by outsourcing outweighs the risk of not completely owning your backend solution.

Of course, these are two opposite ends of a spectrum. The solution that meets your particular needs will probably fall somewhere in the middle.

By all means, if you are intent on creating The Next Big Thing, then it makes sense to do things yourself and not be at the mercy of platform owners. However, if you are building something as a hobby then it makes sense to offload the things that aren't core to your interests.

It also makes sense to consider whether this is intended to be the start of a business or is intended to be a learning experience. In the former case, you have to weigh the tradeoffs between controlling your livelihood and getting to market quickly. In the latter case, you have to weigh the tradeoffs between focusing on breadth versus depth.

Folks, don't be too hasty to do it yourself or pick something off the shelf. It's not a simple decision.

Announcing The More Than Just Code Podcast

I'm proud to take part in announcing a new podcast that is now available. That podcast is called More Than Just Code.

It's a weekly show that covers topics that impact iOS and Mac developers. As the show's title suggests, we also consider the business perspective on each week's topics (i.e. 'more than just code').

The show is co-hosted by a transcontinental panel of developers: Tim Mitra, Aaron Vegh, Mark Rubin, and yours truly, Jaime Lopez.

Folks, check it out (and subscribe!): http://mtjc.fm/

Update Feb 25, 2015: New website URL, folks.

Teach Users How to Use Your App by Having Them Actually Use Your App

It's late at night. The empty cans of Red Bull tower over your desk precariously. You've done it. You've finally created your beautiful, polished, delightful app. The blood, sweat, and tears will all be worth it once you hit that delicious button to submit to the App Store.

You hesitate. You have a sense of worry gnawing at the back of your mind. 

What if users don't immediately comprehend my glorious design?

What shall I do?

I know! A tutorial! That's the ticket!

Netflix app for iOS (image via http://www.mobile-patterns.com/coach-marks)

Suddenly, your beautiful app isn't so beautiful anymore. You've decided to smack the user in the face with a brain dump tutorial.

...

Why is it that so many apps fall for this trap? The most common reasons seem to be that app developers run out of time to properly implement a tutorial system or the developers fail to realize that the onboarding experience is an integral part of the app that requires just as much design effort (perhaps even more effort) as the rest of the app. Yet, it is still common to see apps that don't give much thought to how users will learn to use the app.

Whatever feelings you may have about Facebook's Paper app, they at least took a relatively uncommon approach to the problem of teaching users how to use an app with an uncommon design. While it may be somewhat heavy-handed at times, the tutorial system in Paper clearly took a bit of time to design and implement. In fact, the Facebook Paper team gave a presentation on how they approached the problem with contextually aware tutorials.

Developers can look outside of the traditional app development industry for inspiration as well. The game industry has spent decades working on this very problem. Take, for example, this analysis of the first level of Super Mario Bros. by the folks at Extra Credits:

The game designers at Nintendo carefully crafted the first level experience to teach players the skills that they will need throughout the game. They did so without dumping a bunch of explanatory text right at the start of the game or requiring that a player read the manual.

You might very well ask, 'how can these same design principles be used when creating an app?'

For starters, you should consider what your first-run experience is like for a user. Does your app have a bunch of empty states? Design a way for those empty states to have a call to action or design the app's first-run experience so that the user doesn't have those empty states to begin with (for example, pre-populating an app with content that the user is reasonably expected to enjoy). Does your app involve a complicated ecommerce transactional experience? Design a way for users to get progressive disclosure on where they are in the process.

Folks, Super Mario Bros. doesn't bombard players with every possible bit of information they could ever need at the beginning of the game, and there is little reason why apps should be any different. Teach your users how to use your app by having them actually use your app.

Bonus:

If you enjoyed the design analysis done by Extra Credits, you might also enjoy these videos (warning, they are longer videos and may include profanity so be careful at work).

Amazon is Adding More Cute Robotic Workers

From the Wired Business Conference comes a video showing 'A Day in the Life of a Kiva Robot'.

This isn't the first time that Amazon has shown us a video about the Kiva robots. This video, however, goes more in depth as to how the robots operate in Amazon's warehouses.

Folks, this is the wave of the future.