You probably know this, but just in case you are out of the loop, I’ll give some quick background.

Apple’s trackpads – obviously including the iPad – can support up to eleven distinct touchpoints per touch sequence. In other words, you can use both hands and…your nose? On the iPhone, and mostly on the laptops, we use one or two touches most of the time.

On top of the number of touchpoints, multitouch development uses a concept of “touch sequences” to track a discrete series of touches over a short period of time. In English, that means you can put ALL ELEVEN FINGERS on an Apple touch screen, twist, twirl, and swipe, and apps can respond accordingly.

This is fairly new to personal computing. We’re used to a keyboard, a mouse, occasionally a trackball or trackpad. We point, we click, and we drag.

Now we can do more. Much, much more. Obvious, yes? Yes.

Today

We’ve all seen touch-and-drag. We’ve seen flicking through a collection, or flicking to activate supplemental controls on a cell. We’ve seen pinch-to-zoom and reverse-pinch-to-zoom-out. We saw these on the most well-funded educational video series ever: Apple’s own iPhone TV commercials.

Apps mostly stick to the meaning of those gestures, and users benefit from that fact. Collectively, we developers and designers have self-regulated in a fairly organic, reactionary way. But with the larger screen on the iPad, can we unify sooner? Preemptively?

Just wait until people begin using the iPad. Think about that form factor, about the usage contexts. It wouldn’t shock me if a QWERTY keyboard disappeared from the device in a couple of years, replaced by something brand new…something one-handed and elegant. If so, the new *thing* should be leveraged across apps to the benefit of everyone. Novel gestures are a fleeting competitive advantage.

Why Collaborate?

In the sort of wild west that popped up around the iPhone – and will likely pop up around the iPad – the earliest adopters gained footing and market share (by virtue of a smaller market) while users floundered in a Stockholm Syndrome situation. Consumers were captive to the limited array of apps that existed in the early days and were willing to invest time learning how each app worked. A lot of folks are still quite flexible, but I wonder how long it can last.

The tipping point between critical mass of users and critical mass of apps happens quickly, though, and we product designers have to make sure it tips the right way. That is, in favor of users. And reciprocally, in favor of product developers. We can do that by lowering the learning curve for each new app that pops into the store.

A Warm and Comfy Blanket Statement

It’s a mistake to hijack established gestures, just as it would be a mistake for every computer to have a different keyboard layout.

I wrote about this in my book on iPhone UX hacking, and still abide by it.

We owe it to users to collectively invest the same meaning in each new gesture we invent/acknowledge, unless there’s a great reason to change established gestures. If that’s the case, we should register the change with other product devs/designers and move everyone else in the right direction.

We should also focus on bringing new gestures to market in a way that prevents confusion. It would be great to share feedback from our users on input gestures. I can even imagine a choreographed A/B test among competing apps. (KUMBAYA!)

Right now, though, there’s no easy way to share. No grand central dispatch. No forum.

We can read the iPhone and iPod Human Interface Guidelines, copy the earliest players, and bank too much on “common sense” (a problematic concept if ever there were one).

Instead, maybe we should talk about this. Contribute. Debate. Share code. Share artwork. Share labels. Share translations.

The Gist – CommonUX

To get to the point, I want product designers to collaborate and focus competition on features that don’t alienate users. I want us all to share our concepts for gestural input, share the iconography that represents actions (and more), and focus our innovation on the features that matter. Let’s assist users by assisting each other, reduce barriers, and make for a great platform where product designers can spend time where it pays off.

I’ve created a GitHub site and have purchased a domain that could – if folks choose to participate – act as a central repo for collaborating on common user experience elements. This post is to get the word out and figure out whether folks care.

Elements we can standardize include:

• Gestures for common actions
• Apple-friendly icons representing common concepts or objects
• Code and icons for both Cocoa and Android (and…?) for handling common gestures
• Colloquial names for gestures

So, welcome to CommonUX. Let’s sort it all out.

Though not a new phenomenon, we think we have a solution.

If pressing a lit elevator button were to cancel the call and simply send the machine to the nearest floor in the current direction, there would be a penalty to pressing it more than once.

The interesting thing about this idea is that it need not be universal. Instead, elevator designers could follow the lead of Jeremy Bentham and create a panopticon-style system in which some small portion of elevators operate this way. It only takes the fear of looking like an idiot to regulate behavior (most of the time).

ChatRoulette Weirdos

As ChatRoulette takes off, it’s becoming plagued by pervs flashing their junk or otherwise being slimy. It’s certainly expected, as the anonymity provided by the web brings out that side of people. It’s just a fact of life on the Internet: if there is an opportunity for a guy to flash his weiner anonymously, he will.

And that’s fine. It’s the way of the world. It’s the way of the web.

But so, my friends, is community moderation.

Enter ChatSnapper

Let’s try an experiment.

1. Follow @ChatSnapper on Twitter.
2. DM or @reply to @ChatSnapper with a link to a screenshot from ChatRoulette (or other online chats) showing offensive (or just weird) behavior.
3. Check posted links and help shine a light on the offenders.

Let’s see if the existence of a rogues’ gallery has any effect on the actions of folks.

If this works, I’ll start calling elevator companies.

ADDENDUM

Alex Bisceglie alerted me to a similar effort: ChatRoulette Cock Map. It includes an app that can track the IP of offenders as well.

The very moment that Alex sent that, I was working on a WebKit browser with screencap and yfrog upload. For now, grab a build at: ChatSnapper – Alpha.

I’ve often wondered about the gap between the story an author creates and the experience had by readers. I’m not thinking of the changes that come at the hand of editors, but rather the effects of the design and marketing process. The number of words per page, the typography, the stock, the cover – all variables that shape the reading experience.

The Kindle – and probably other e-ink readers – displays all books with the same detachment. All texts are reduced to…text. The typefaces are basically standardized and the font size is under the control of the reader. Even the display of the reader’s current “position” in the story is abstracted from physical page count and instead shown as a percentage. Reading on the Kindle is – and I say this with endearment – like reading a digital copy of the original manuscript on a word processor.

This consistency of presentation along with the nearly non-existent display of covers and marketing effort in the Kindle store leads me to pick more widely than if I were ordering a hard copy online or standing in a bookstore. There’s no distraction. No salesmanship or reification of marketing fluff via design.

I’m sure there is a downside to this, but so far, as a reader, I can’t find it. Each book I read stands on the merit of the words, and the words alone.

It actually feels more intimate, in a way. The reader and the author communicating without much noise in between and around the channel separates the story from the package. It’s cool.

Enter iPad?

Surely, the iPad will help spark new forms of storytelling the same way hypertext helped inspire lit movements. I can’t wait to see the first few generations of touch-based, mobile literature. My mind races happily along each time I imagine journalism, poetry, and prose five years from now.

But, much like a time machine – only able to travel back to the moment it was invented – I think there will always be a place for Kindle-like devices because new interactive platforms will probably just get in the way of texts developed for plain-text display and that classic format is both intensely front-loaded and clearly here to stay.

I don’t believe this will be the case. It’s not so much about the pros and cons of e-ink, backlights, or screen resolution.

To me, the Kindle DX is a brilliant device because it forces me to read a f’ing book.

No dock icons blinking. No compulsive checking of Twitter, email, or stock quotes (or Texts from Last Night).

By offering a limited set of functionality and doing less, better, the Kindle forces me to eschew the kind of distractions that make me curl up with a book in the first place.

Apple can create the be-all, end-all Surface or Canvas or Slate or whatever. I will buy it. I will buy the shit out of it. I’m a developer and UX geek (and yuppie hipster scum) – I have to.

I won’t use it to read novels, poetry, or prose. Magazines and news? Sure. Tech books? Maybe, if live docs and errata were part of the mix. But then, that type of reading is work, not pleasure. Not therapy. That’s where the Kindle shines.

I have looked at (an early version of) the Kindle development kit (the KDK) and though I’m tempted to create apps focused on distraction (Twitter client, anyone?) I don’t think I’d run them. Instead, I’m trying to dream up apps that boost the escapism the Kindle already affords me.

So far, nothing beats the core function: making me crave reading as much as my first library card did.

The question is obvious for mobile projects because highly variable environments are par for the course. It matters with all non-stationary touch points, though – from door handles on train cars to Android applications to the work we’ll surely be seeing from the new Schematic Touch group.

Asking the question is easy. Using the response may not be. I see mobile apps all the time that are clearly made for users who are stationary, physically stable, connected to a consistent network, and with both hands free for interaction. High demands, right? They conflict with my more common usage patterns, and those apps rarely get launched.

A great example of a more subtle conflict – and one being addressed without much fanfare by many app developers – is iPhone usage in bed and auto-rotation.

Welcome to My Boudoir

My wife and I are incredibly lame. We tend to lie, side by side, reading news on our iPhones before falling asleep at night.

Apps that auto-rotate when the device orientation changes suck in bed. Or on the couch. Or in a reclining seat in first class. Or in a hammock. You get the point.

The problem is that we all flip-flop all over the place in bed (va-va-va-voom!), changing the point of reference for orientation. What makes a lot of sense when we’re upright is a pain in the ass when we’re horizontal.

A Suggestion

I’d like to encourage developers to carefully consider auto-rotation. A lot of devs are starting to catch on to this one as customers complain or make feature suggestions. I thought I might provide an example illustrating a really easy approach to disabling auto-rotation globally in an app. There are more sophisticated and pattern-y ways for the clever.

Don’t get me wrong – auto-rotation can be a great feature. I am all for it. But I have decided the baseline rule should be: If your views auto-rotate, you should provide a (preferably in-app) preference for disabling the feature.

An Example

So how does a developer do that?

Well, the interface is up to you. Let’s assume you have a project with a button that brings up an in-app settings screen.

If you have a UISwitch in there that represents the global auto-rotation state, just save it to the user defaults when you close the settings.

- (IBAction) dismiss:(id)sender
{
	// Update the defaults.
	NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
	BOOL autoRotationEnabled = self.autoRotationSwitch.on;
	[defaults setBool:autoRotationEnabled forKey:kAutoRotateKey];
	[defaults synchronize];

	// Close!
	[self.parentViewController dismissModalViewControllerAnimated:YES];
}

In your app delegate, declare a method to get the current global auto-rotation value.

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	return [[NSUserDefaults standardUserDefaults] boolForKey:kAutoRotateKey];
}

Finally, in each view controller that should obey the globals, ask the app delegate for the scoop.

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	PillowTalkAppDelegate *appDelegate = (PillowTalkAppDelegate *)[UIApplication sharedApplication].delegate;
	return ([appDelegate shouldAutorotateToInterfaceOrientation:interfaceOrientation]);
}

Here is a quickie example project that illustrates the concept: PillowTalk.zip

Still, I like two things about this blog post about their Office web apps.

First, I like that they are officially focusing on (admittedly, a subset of) modern browsers for their very dynamic web apps. Developers and designers at Microsoft are just like the rest of us, after all: they want to do great work and hate clunky platforms and unfortunate constraints. Bravo for continuing the baby steps forward.

Second, I like that they aren’t blocking or filtering user agents. They are offering “unofficial” support to semi-modern and modern browsers. They aren’t showing upgrade notices that make users feel like losers. They aren’t blocking access as some goofy religious mission. They’re just being practical.

From the post:

If you prefer to use another browser you should still give the Web Apps a try. While we cannot officially support all browsers, customers will not be blocked from using them. It is a goal of the Web Apps to have broad compatibility and reach.

I hope (oh dear lord am I gonna say this?!?) others can follow in Microsoft’s footsteps here and be respectful to users.*

* Yes, I also know Microsoft isn’t the first to do this. I’m being snarky.

It’s shorter than I would have liked, and took longer to write, but it’s nice to have it in my hands.

You can buy it at Amazon.

Yes, creating cross-browser experiences can be painful when support for Internet Explorer 6 (IE6) is required. There are dozens of hacks to get around certain issues, and it is possible to design experiences that are functionally identical on IE6 and more modern browsers. It may mean designers don’t have carte blanche, but that should be fine if their companies or clients mandate full IE6 support. Any good experience designer can work within constraints and still kick ass.

Still, a lot of folks are lobbying their companies, clients, and partners to drop support for IE 6.

My issue is how they’re doing it. The more dickish folks are throwing up an insulting roadblock, patronizing IE 6 users.

A more practical approach is to encourage users to upgrade with prominent, consistent notices. This angle isn’t terrible, but still alienates users and disrupts the experience for those users almost as much as a modified or “broken” IE6 experience. It’s just not friendly, or consistent with the brand message that usually mandates an identical UI across target browsers.

Another Option: Boring but Practical

My suggestion is to take this to the contracts. Redefine the word “support” as it applies to user agents (like browsers). Look at the cost/benefit of all types of support for all types of user agents. This should be a part of your business modeling.

Instead of refusing content to IE6 users or breaking brand guidelines by disrupting their experience with a patronizing notice, why not relegate them into a tier of Content-Level Support as opposed to Design Support?

Good sites already do this with a stylesheet for print: we don’t penalize printers for their lack of a good box model. The same is true of screen readers and most RSS readers. Maybe you can think of IE6 as a perfectly viable user agent for consuming content, but cost prohibitive for rendering top-tier experience design. Serve your print styles to IE6 if you don’t want to offer design support. Or serve a basic white-on-black stylesheet. Or no stylesheet. Pretend IE6 is the Googlebot or JAWS or any other non-graphical user agent. Just don’t punish people or talk down to them.

Channel Your Frustration Properly

You don’t have to be a dick to your less-endowed users. Shift them, officially, to a tier you, your clients, your company, and your partners agree upon and move on. Just make sure you’ve built an economic model that includes the IE6 users and estimates the cost of all possible decisions. Look at the realities of IE6 users of Digg to understand the complexities facing the people your cocky designers and lazy developers want to patronize or abandon.

Justify relegating IE6 with real numbers or choose to give it design support and force your designers to work within the constraints. They do get paid to work, after all. If they can’t create great experience design that doesn’t fuck over the people coding those experiences, fire them. Hire designers who understand browsers.

No matter what you do, keep your users’ needs first. They’re the ones you can’t replace.

A Great Resource

A few months back, I started up a GitHub project to create a baseline CSS file for all legacy browsers. Around the time I got contributions from folks at work, I found out about similar (but completed) projects out in the wild. One such project can be found here: http://code.google.com/p/universal-ie6-css/.

I think iTunes has become the main interaction platform for Apple. Given the popularity of the iPod line and iPhone, combined with iTunes for both Windows and Mac OS X, I’d bet more hours are spent using iTunes than Finder every day.

As with the App Store, Apple seems to be stumbling over itself with the iTunes experience. They need to slow down, reset, and rethink the experience promised by the Apple brand.

We know that iTunes is slow. The UI is inconsistent. The store feels completely alien to the main UI and experience. The app does far too much, plays too many roles too slowly. iTunes is more Wal-Mart than Apple Store.

People tolerate iTunes because it isn’t unbearable. It does work, after all. We all know the flaws I’ve mentioned and begrudgingly accept them because iTunes is the only choice we have. Another case of Software Stockholm Syndrome, I guess?

But here are two new (to me) insights.

1. iTunes focuses on multiple mobile devices paired to one computer rather than treating all Apple machines as peers. If nothing else, Apple should invert the model they currently use. Instead of one machine and one or more peripherals, they should focus on the more common case of one device and multiple computers.
2. Syncing a device to iTunes gets more painful every day, pushing users away from iTunes. Syncing a single podcast from iTunes to an iPhone takes fifteen minutes. It’s painful. This is a big threat the the Apple halo effect.

Mobile devices are for mobile people. Most of us operate in at least two computer-focused environments: home and work. Apple lets us buy, download, and sync content (apps, podcasts, audio, video) on a single computer, but on multiple iPhones or iPods. We still can’t easily add content – with or without DRM – to our devices from work and home. Aside from risky hacks to trick the phone into seeing multiple libraries as one, there are no practical ways to keep the whole digital lifestyle in sync.

My wife has stopped plugging her iPhone into her computer. In fact, she’s stopped opening her computer, save for writing posts on her blog. I asked why.

“I can do everything I need to do on the iPhone. I can get podcasts and music and apps, and iTunes freaking sucks, so why bother?”

The Apple lifestyle brand and experience is amazing when it’s strong, but like so many other things, it’s a bubble. iTunes is a thorn. Apple peripherals once caused a halo effect, but as they get better and iTunes gets worse, the iPhone and iPod Touch might cannibalize the Apple (desktop, laptop) computer market for lifestyle users.

If you are trying to raise awareness, forcing a user to work is generally a bad idea. You have to give users something of high value while minimizing their effort if you want to build a better reputation.

If your goal is conversion, you should be especially careful of the barriers to entry and usage. This seems obvious, but brands consistently require too much of users in their digital marketing efforts.

Augmented Reality in Ads

Industry rags and blogs have spent months reporting on a steady stream of augmented reality (AR) ideas in marketing ever since GE launched their Smart Grid AR site.

A recent entry into the pool is for Always Infinity. The site claims to show you a magic trick.

All you have to do is follow the instructional video and simple two-step process of printing a graphic out on a sheet of paper and holding it up to the camera while it superimposes the magic. What’s the magic in this case? A 3d animation of a rabbit in a hat. It’s cute, but fluff. The real magic trick is making 5-10 minutes disappear with nothing to show for it – including a greater appreciation of their new pads.

This is how most of these campaigns work. I think they’re mostly flops. They’re ideas pulled out of the bookmarks bar of a desperate art director, sold to a client as the next big thing, and supported by an industry press with a shortage of interesting topics.

There were two instances of this particular form of webcam-based AR in recent marketing efforts that were successful. The first was the aforementioned GE project. This was the first big brand use of AR and it seemed like advanced – if novel – tech coming from GE. It was cool and not overtly pushing a product.

The second was a project developed by AKQA for the United States Postal Service (USPS) that let users hold items up to their camera to find the best Priority Mail shipping box. The damned thing had a purpose, and used the tech in an interesting way.

Everyone else doing this stuff has been trying to fit in, adding to the noise. They’ve expected users to find inspiration in the declining novelty of webcam AR, put in the work of printing an image, engage in the theatrics, and eagerly send to a friend.

Instead of patronizing your audience, pushing this gimmick as new to them, why not find a real reward for engagement? Make the payoff ten times as valuable as the work users put in. Only the first project to use a gimmick gets to call the work itself the payoff.

Let me repeat my new rule to the consumer brands out there looking for gimmicks that make demands of people: If it’s easier to buy your product than to engage with your marketing, you’re doing it wrong.

Currently, systems deliver recommendations (like search results, products, or compelling content) based on two types of user input: explicit and implicit.

What You Tell the Robots

Explicit input is what you do to purposefully tune a system. You might opt out of tech news and opt in to sports. You might type in a couple of your key stock symbols. Explicit input is configuration. The cynical idea behind configurable services is that users will interact more with a tool they’ve spent time customizing. This can be true, but it can also alienate non-tinkerer audiences. More importantly, forcing someone to create their own portal removes any kind of authority from the service in question. It exposes the robot behind the curtain.

The Robots are Watching You

Implicit input is what you do without knowing you’re tuning a system. Where you click, what you search for, and what you ignore all contribute. Coming into a magazine site from a particular Google search might change the content you see on the page. Banner ads are usually served based on what you’re reading and what the ad network knows about you. On Amazon, anything you look at feeds into the recommendation system that shows you products that (may) interest you. In fact, I love pranking people by sending links to enema kits on Amazon. It pollutes their recommendations for a while. This is implicit input at work.

The Robots are Watching Everyone

An additional way that sites make recommendations is based on the stuff you tell them you want (explicit input), the stuff you show them you want (implicit input), and the input from other people like you. There are some sweet algorithms out there for determining that people are alike and using the tendencies of members in a group to recommend things to other members in the group.

In theory, the idea is compelling. Unfortunately, most of these algorithms end up turning individuals into caricatures of themselves or of their demographic group. It’s infeasible for a system to know enough about an individual to make consistently great recommendations. No computer will ever be able to recommend a book or a date or a pair of shoes with the same accuracy as a friend. More importantly, they can’t deliver the same accuracy as a casual acquaintance.

Humans can fill in gaps and infer rich meaning from subtle body language, tone, and personal experience. Those factors are noticeably absent in most online recommendation, search, and content delivery systems.

The Perfect System

I don’t think people want to interact much with systems to find information. Weird view, I know.

Some systems are certainly popular (Google) and and very successful (Amazon), but the affinity people feel for those systems is a form of Stockholm Syndrome.

What we all want is to have our grandfather (or an equivalent symbol of infinite wisdom and no-bullshit-taking) sitting on our shoulder, pointing us in the right direction at all times. We don’t need confidence in recommendations (of content, purchases, people) as much as faith. We want to Ask Jeeves, but we want Jeeves to have a clue – not a hundred page slush pile of possible hits.

Bad or boring recommendations lead to a lack of faith in recommendation systems in general and contribute to an overall fatigue. Recommendations need to inspire either confidence or faith. Confidence comes when you’re 100% accurate at all times. Faith comes when I feel like you understand me. Your “you might like…” recommendations are something I care about because I empathize with you. Confidence is for robots. Faith is for humans.

Enter Social Networks

There is a lot of potential in the networks of people we curate online, the reviews we write, the reservations we make, the choices we make on the spot in stores. The data doesn’t say who we are and how we feel, and no machine can step in to fill in the gaps and make the proper inferences.

The best system will have hints of the “#lazyweb” approach to Twitter. I ask my curated audience for advice. Even if I don’t know them all personally, and thus have little confidence in their individual experience and knowledge of my personality, I have high faith in the mechanism. I ask, and I receive. From people.

It’s a model as old as language. Until computers can empathize, algorithms need to shift their focus. Instead of attempting to make recommendations, technology should attempt to facilitate recommendations.

Twitter is on the right track with the new focus on search. I’ve long maintained that the best source of purchase advice is Twitter search. Twitter is a barometer. Nobody searches Twitter to find out definitive, high-confidence information. Instead, we search to get a feel for what people seem to know. We read short statements and either empathize with them automatically or shut them out. We have faith in our ability to read between the lines and derive answers. We use personal brands as clues to authority, bias, and brilliance.

It’s very personal and all too human.

With the insanity around the Yahoo and Bing/Microsoft relationship, I wonder if Twitter – or an app built around it – won’t become the search and recommendation tool we all really want.

The newest example: Mastercard Priceless Picks.

Their location aware social review sharing tidbit finder app is a cute, ephemeral trinket (at best). It would have made a rather interesting location-aware banner ad. Unfortunately, someone told them they should ship an iPhone app instead of a ton of banners. Hey, why not, right?

Here’s one reason: installing an iPhone app is work. If you make users work, you owe them something valuable.

Despite the attempt at “one-click” installation, the App Store is a nightmare. iTunes is still slow and unwieldy. Installing, updating, deleting, and managing applications is still quite a bit of work.

Contrast this to banners. A banner loads when a page loads. Users don’t have to do anything. Actually, users don’t get to do anything – including disabling ads or opting-in – but that’s a post for another day. Unlike iPhone apps, the barrier to entry for a banner is very low. Your debt to users is lower.

They’re fast to develop, cheap to run, and simple to measure. They probably get more traction than iPhone apps, especially as the “first in my category!” novelty slots are snapped up. But alas, the creatives are bored with them.

These days, many digital agencies won’t touch banners. They relegate banner work to a production ghetto, churning them out when they have to, and apologizing to the creatives forced to touch such dismal fare. They blame the format for the lack of satisfying creativity instead of looking at themselves.

Hey, don’t get me wrong: I agree that banners, as a format, are terrible. I want online display ads to die as much as the next normal, sane human – and with them, their concepts.

There is a class of creative concept that belongs in a banner/widget, if anywhere at all. Most of the iPhone apps spit out by brands belong in that class. Transposing formats is a distraction. Sleight of hand. Another paycheck.

The Mastercard app shows the warm reception from the public.

Would so many agencies pitch iPhone apps if their compensation was usage-based? I don’t mean downloads, either. I mean repeat launches, with the first dozen per device being free.

A Mantra

Ad world creatives and strategists, repeat after me: My iPhone app idea sucks. It belongs in a banner. Leveraging the accelerometer, magnetometer or location API doesn’t change that.

If you’re the exception, I’ll buy you a pint. Of gold.

Brand App User Scenario

To those who will pitch their dumb ideas despite my sage advice, I offer a token of friendship: your primary user scenario.

The user will follow these ten steps.

1. Hear about the application.
2. Search App Store or come in via link.
3. Click install, wait for download.
4. Plug in phone.
5. Sync. Take nap while backup and sync complete.
6. Find the app on the many screens of icons.
7. Launch it.
8. Close it.
9. Delete it.
10. One star.

Ouch. I’m sure you’ll win an industry award, though.

According to AdMob, a large portion of iPhone and iPod Touch users claim to use their mobile devices to browse the web more often than they use their desktop or laptop computers. This number is undoubtedly going to grow.

Combine that with an article in AdAge this week examining the problems with Google’s AdSense for Mobile product, and you see the current, expanding dark period for users (victims?) of mobile ads.

Mix in Noah Brier’s thoughts on Google as a market leader and we see a larger risk: if Google ignores UX right now and users acclimate, nobody will have the weight to course-correct where the experience is concerned.

Admittedly, my opinion is that mobile advertising should shrivel up and die. That said, if it’s going to exist, the UX should be at least tolerable and, preferably, stellar.

This is the kind of problem that arises when engineers don’t obsess over UX.

Mobile users are often on the move while interacting with their devices. By definition, their environments change almost constantly and often introduce unforeseen obstacles. Mobile conditions can place limits on many user attributes: focus, input precision, network connectivity, available time, personal space, and patience. Yet mobile devices are becoming as robust and powerful as laptops, inspiring tons of new, high-end functionality. The challenge is to reconcile the two factors, creating a helpful user experience that uses the new tech to the benefit of the largest number of users and the detriment of none.

User-centered designers face some interesting questions: How do you design an interface that allows someone to find directions or call a cab while carrying bags of groceries home from the market? How can an interface accommodate limited agility, gloved hands, a jostling subway train, or fat fingers? How do you let users subtly compose, edit, and erase email messages while in a long, boring meeting? (Hint: shake-to-edit or shake-to-delete or shake-to-anything are not very friendly requirements.) How do you model user behavior when the nature of mobile use is unpredictable and endlessly diverse? How can you solve problems as unobtrusively as possible?

I hear questions like these very often these days. Designers and developers who never paid much attention to the usability of their web or desktop applications are suddenly quite concerned about the UX of their mobile applications and mobile-optimized sites. I welcome the new interest in the topic, as I’ve always been a bit UX-obsessed, but I have to wonder about the inspiration. I think I’m witnessing a new empathy for users and a shift from the assumption that users crave every complex, novel, “innovative” idea a designer can throw at them.

Progressive Enhancement to the Rescue

One of the topics covered in my iPhone book is progressive enhancement. For those unfamiliar with progressive enhancement, it is the art of providing baseline value to all users and additional value to those in favorable environments or with extra abilities. A strong, accessible functional baseline is important for all software products and interfaces because we want our products to be user-centric.

Progressive enhancement patterns are familiar to a lot of web designers. I think a lot of folks kind of fudge the topic, though. They meet their stated requirements (such as 508 compliance), but often ignore the art. They provide baseline functionality, but they make it clear it’s only baseline. They passively penalize the audience that can only meet the minimum requirements and focus all elegance, fun, and inspiration on the most capable users.

Building Empathy Through Adversity

I think the growing importance of mobile devices in our everyday lives can give a new perspective on baseline users, perhaps leading to more time spent providing amazing, elegant assistive applications and reducing the importance placed on gimmicks.

Think about it: these days, we are all mobile users. As such, we all face adverse conditions for use. Suddenly, we all understand what it’s like to have external conditions impose limitations on our abilities. We are all handicapped in one subtle way or another as we go about our day. All it takes is a taste of frustration to ignite passion for assistive interfaces.

The applications we truly appreciate in the mobile space are those that enable us to accomplish our tasks no matter what our environment. We can compose emails in the absence of a network connection–they simply send when we are back online. The better Twitter clients and RSS readers store data on the iPhone to provide some value when users aren’t online. The better interfaces allow us to perform tasks with one free finger and minimal attention. They don’t impose gestural abilities on tasks for the sake of novelty. Or, if they do, they treat the novel interaction as an enhancement, allowing us to accomplish the same goals with the tap of a button.

In interactive design, including software and web design, progressive enhancement is often treated as an annoying requirement. Designers can now tap into their own experience using mobile devices to better empathize with users who lack full control of their environment, tools, and body, leading to a new respect for baselines and a shift in attention from the secondary enhancements to the primary use cases.

Most folks will eagerly update their devices as the new OS is truly stellar.

Many applications will be updated to take advantage of new features like the Push Notification Service, In-App Purchases, and Bluetooth-powered Private Area Networking (with GameKit).

I can’t wait to watch the Twitter chatter.

See, I’m obsessed with UX – especially on the iPhone. I get bent out of shape about ugly applications, hijacked gestures, disruptive branding and flippant differentiation. I fully acknowledge the delicate bubble Apple has created in the form of the iPhone UX, and I hate to see folks pushing blindly at the edges. The aesthetic and experience are what really differentiate the platform from similar devices, and it’s worth maintaining.

Cocoa Touch developers, like Cocoa developers, spend a lot of time thinking about user experience. With Cocoa Touch, there is an additional onus on folks to think about the experience outside their application because the device has limited resources: memory, CPU, battery life. Mobile users also have more limitations than desktop users: attention, coordination, time, tolerance, physical ability.

With iPhone OS 3.0, I am especially worried about the Push Notification Service and its potential for misuse, abuse, and overuse. Without consistency in the meaning of push messages, we might collectively burn users out on notifications.

Notification Misuse: Audio and Text Alerts

Developers can use the push service to send three types of notices to devices: short audio events, strings of text, and a number shown in a red circle (aka badge) on the application icon. Each of these has a place, and Apple cautions developers against using notification mechanisms that are disproportionate to the importance of messages.

For example, you should avoid sending audio alerts unless users are in the application context (that is, the application is running and users are interacting solely with it) and have opted into receiving audio. Nobody wants their phone to chirp away with random noise when they’re trying to listen to music or play a game.

Text alerts can be used to communicate very important events, but they too should be used with care. Text alerts trigger a full-screen, modal alert box that not only steals the focus of the entire phone but requires users to dismiss the alert by tapping a button. It’s pretty cocky to hijack an iPhone for a trivial note, so make sure the message is worthy.

Notification Abuse: Audio and Text Alerts

Don’t flood devices with flippant text or audio push notifications. Understand the disruptive impact of those messages and avoid them unless they are absolutely necessary. And repeat this mantra: “Push notifications are rarely necessary!”

Consider an asynchronous chat service in a social application. It might be awesome to use the push service to send messages to users, SMS-style, even when the app isn’t running. Now mix into the equation the presence of other applications. Most of us have at least two social apps on our iPhones. Suddenly, modal alert messages are popping up for each of them. God forbid you have multiple Twitter clients installed that send alerts for direct messages – redundant popups flooding in would be pretty annoying.

Don’t fall into the “I can, so I should!” mindset. Applications have worked well without notifications thus far. You won’t increase stickiness by pushing notifications to users, catching their attention and helping your icon stand out on the screen. Stickiness is a terrible concept carried over from the ad-driven web and is the banner under which advertising ruined online UX. Even if your application is ad-supported, your best bet for success is to create a tool that fits into the whole iPhone experience rather than trying to use every feature available to you in hopes of standing out. Beat your competition by doing less, better. Don’t steal focus. Earn it.

Notification Overuse: Badges

You should also avoid overuse of icon badging. Think about mobile development holistically. Every badge added to an application icon impacts the overall user experience. It’s your duty (yes, duty) to play nicely and work with the iPhone developer community to create a strong experience. You are not an island. Your app is nothing without the experience provided by Apple, and that experience must be ruthlessly maintained. Your application is a guest on a very expensive, aspirational fetish device. Don’t trash the place, lest you be trashed.

Badge Blindness

So why should badging be limited? Overuse of badging will lead to badge blindness. Badge blindness occurs when users lose faith in the importance of icon badges. RSS readers provide a really great example of this phenomenon.

Imagine you subscribe to 50 feeds – a modest number – and have your feed reader set to poll for updates every hour. If your reader shows a badge that reflects the current number of unread stories in your collection of feeds, you can almost guarantee that you will always have a badge present. Often, it will have a very large number inside. You will never reach zero, and the badge will never disappear. The badge becomes a permabadge – an annoyingly persistent reminder that the application wants your attention. You will probably declare RSS bankruptcy – marking all feed items as read – just to get the satisfaction of seeing the badge disappear… for less than an hour.

Imagine that, on the Mac desktop, several applications in your Dock show badges. Mail, iChat, NetNewsWire, iCal, and Xcode. Suddenly, you don’t feel as though your computer is trying to direct your attention towards an important, but non-critical, focal point. Instead, you feel as though your computer is constantly nagging you.

Now picture the equivalent on your iPhone. A screen of greedy little icons, all raising their hands wildly, begging for attention. You’ll start to ignore the mechanism. You’ll stop seeing the badges.

You’ll delete the annoying apps and leave one-star reviews on the App Store.

Advice

Imagine you’re in a crowded coffee shop. A friend is across the room, reading a book, or chatting with a crush. You think of something you think they may, possibly, maybe want to know. Would you shout the message out across the room? Wave your arms wildly, hoping they make eye contact? Send them a text? Email them? Leave a note with their server?

Whatever your message, make sure the transmission protocol is suitable. In some cases, this will mean badging. When badging, make sure the badge will be invisible more often than not, or it will lose its impact. If the message merits completely stealing focus, send a text alert or sound. Do so only in the rarest of cases, unless users have opted-in and can just as easily opt-out. Be nice. Don’t pop any bubbles.

Wow, long time no write… Typical of me.

I’m wrapping up my newest tech book. Programming the iPhone User Experience will be released by O’Reilly this July.

I spoke at the Web 2.0 Expo (SF) this year on the subject of iPhone UX Anti-Patterns. It was the highest-rated mobile session. Great validation, and I think it’ll go a long way towards squelching the desire to jump off a building every time I have to get on stage.

After the book wraps, I hope to write more often here, on InsideRIA, and for other publications.

Or, I may just drink a lot and lay around.