June 24th, 2009. 2 comments.
Jeff Goodby, from Goodby, Silverstein, & Partners (one of my favorite agencies to work with BTW), wrote an article in AdAge that actually got me thinking.
The article is Jeff Goodby: We are Becoming Irrelevant Award-Chasers.
There are some real gems in this article and I agree with his core position. It echos something a friend of mine told me. He’s the Worldwide Creative Director at one of the world’s largest agencies. His group focuses on the shopper space and measures success in terms of direct sales. The motto he and his team operate under is, “We don’t take gold. We make gold.”
They focus on activation more than awareness, and obsess about ROI. Cases moved, not trophies from their peers. Definitely more MBA than MFA, though they’re no slouches on creativity.
This is a different position and purpose than awareness-building groups and campaigns, but I think the two are artificially separated.
My favorite paragraph from Mr. Goodby’s article sums up a problem a lot of folks joke about: using client dollars to build an agency brand first, client brand second.
It’s a warning that we are, in effect, making things that serve our own agency brands instead of serving our clients and making a difference in the minds of the world.
I see this all over the place. It’s an industry-rag myopia that often leaves consumers/shoppers/users out of the equation. It’s more prominent in the awareness-building side of advertising, because it’s easier to get away with there.
What I don’t agree with is the call for famousness as a driving force – at least not for the agencies themselves.
I want us all to be famous again, outside the walls of our agencies. How can we accomplish this?
I’d rather see the brands made more famous, the agencies fade into the shadows, and awards focus exclusively on metrics. The problem, of course, is finding new ways of measuring success.
In Which Toby’s Optimism Takes Over
If each major agency donated the time and brainpower of one pointless microsite or social network spam tool and focused on using technology to prove efficacy as it relates to activating sales all the way from display media to the credit card machine, they could transform the industry.
We’re all digital-obsessed anyway. Why are all the lines of code squandered on ephemeral campaign collateral? Why not come together and create standards that unify as many digital outlets as possible? Unify digital cable to mobile to web to shopper loyalty programs to e-commerce to out-of-the-home to in-store displays?
It could be awesome… A lot of work, for sure. A lot of ego set aside. Great care to liberate consumers/shoppers/users from privacy concerns, bad UX, and fatigue. A massive battle against inertia. But the payoff could be the ability to tune messages so effectively that we reduce the noise, stop fighting for eyeballs, and help people make decisions.
In Which Toby’s Cynicism Takes Over
But then, who wants to create tools that can measure success accurately? Who wants awards to go to campaigns that help move units if those campaigns end up straightforward and unobtrusive and inexpensive? What if your pet client is pushing a shitty product and user-centered advertising exposes it as worthless? Ouch.
And who can be famous for helping their clients get richer?
What if cabbies are unimpressed?!?!
In Which He Makes a Call to Action
So who wants to discuss the overall role, and future, of technology and user experience in advertising? Who can think outside of their current assignment? Who among us would like to be the Tim O’Reilly of ad-tech? Where are the visionaries?
June 16th, 2009. 3 comments.
So iPhone OS 3.0, drops very soon (aka, tomorrow).
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.
June 13th, 2009. Zero comments. :(
If ever there was a clear example of the need for unit testing during builds, it’s the integer overflow problem this week on Twitter.
For those not in the know, Twitter uses an incrementing integer as an identifier for each message on the site. On June 12, 2009, a message crossed the maximum integer value that could be stored in a 32-bit signed integer (2,147,483,647).
All messages created after that moment had integer values that would overflow the space allocated to the id.
This wasn’t a problem on Twitter.com. They’re surely on some rockin’ 64-bit systems and are continuing along as always.
The problem is with third-party applications using their API. When an application requests a list of status messages from Twitter, it receives the data in a format like XML or JSON. All values are stored as strings in those formats.
When the response is parsed, the string representing the status message id will be converted to a number. Applications that still use signed 32-bit integers will not be able to properly convert the string to an integer and will probably crash.
This problem is hitting a few Cocoa Touch applications. Tweetie seems immune, but the current release of Twitterrific and the in-beta Birdfeed both suffer. This is through no fault of either Craig Hockenberry or Buzz Andersen, though.
Buzz’s app, Birdfeed, is still in beta. Those of us testing it understand that beta means beta. He’s cracking on a fix now.
Craig preemptively fixed his issue well in advance, but – as I understand it – Apple is sitting on it instead of pushing it into the App Store.
This is just one of many ways Apple continues to please developers endlessly with their transparent, fair, open distribution channel.
Lots of folks want to blame Twitter, or shift some of the blame to them.
This is not a Twitter problem. They adapted their system and encouraged developers who use the Twitter API to remain in parity.
It’s probably true that Twitter could have made a bigger deal of the issue, but I think they did a solid job of keeping people informed.
Most people had ample time to update their code, and many of them did.
Daniel Jalkut suggested that Twitter might have provided an endpoint for the API that simulated large integer values, so application developers could test against the newer ids. I heard similar statements by folks attending WWDC.
I think this exposes a slightly dirty secret in the Cocoa world: most Cocoa and Cocoa Touch devs avoid automated testing. Unit tests are few and far between. From what I hear, Apple doesn’t even enforce units.
When you see regression bugs in Cocoa apps, you can assume the issue is in a lacking test suite.
The Cocoa community should learn two things from the Twitocalypse:
1. Write your units.
2. Submit to the App Store at least time * infinity in advance.
I’m about 50% on having test suites in my (admittedly, unreleased) iPhone apps. The half that have tests have strong coverage, though. Those that don’t are from the early SDK days, when the only way to test was with the Google Toolkit.