Tag apple

iPhone 4 Antenna issues are a UX issue: What the user doesn't know makes them happy.

Apple this morning is reporting that they've figured out what is really going on with the iPhone 4 antenna. 

We have discovered the cause of this dramatic drop in bars, and it is both simple and surprising.

Upon investigation, we were stunned to find that the formula we use to calculate how many bars of signal strength to display is totally wrong. Our formula, in many instances, mistakenly displays 2 more bars than it should for a given signal strength. For example, we sometimes display 4 bars when we should be displaying as few as 2 bars. Users observing a drop of several bars when they grip their iPhone in a certain way are most likely in an area with very weak signal strength, but they don’t know it because we are erroneously displaying 4 or 5 bars. Their big drop in bars is because their high bars were never real in the first place.

To fix this, we are adopting AT&T’s recently recommended formula for calculating how many bars to display for a given signal strength. The real signal strength remains the same, but the iPhone’s bars will report it far more accurately (ed: emphasis mine), providing users a much better indication of the reception they will get in a given area. We are also making bars 1, 2 and 3 a bit taller so they will be easier to see.

As Gruber reports, this is the best phone antenna ever created. All the lab tests show its amazing. So what's the cause? The antenna does get attenuated if you hold it a certain way, but in a less dramatic way than 4 bars dropping. Perhaps only 20-30%. Not worse than other phones at all. Turns out it is not an antenna issue, but a user experience issue. 

Mark Twain said if you tell the truth, you don't have to remember anything. The pithy saying applies here. I can just imagine the wheels turning as Apple engineers and execs scramble to understand the situation. But it starts with a simple, pretty innocent idea: gosh, the bars look so low. AT&T reception is terrible. Lets just add a couple bars, and nobody will be the wiser. Years later, the issue is exposed in a public and grand fashion as a truly unintended consequence.

While truth will set you free, a little fib will make people happy...

When I was at Microsoft, we had a related UX problem with Microsoft ActiveSync. Customers would consistently complain about how awful ActiveSync was, even calling it ActiveStink. But after a pretty comprehensive review of feedback and failure rates, we figured out that ActiveSync wasn't that bad at all. For instance, we'd often show this error:

The server happened to be down at that very moment, but it would sync again and be fine. We put "Attention Required" and we'd call out that they hadn't synchronized against Exchange. 

What did Blackberry do? Nothing. It wouldn't tell you that the server couldn't be contacted. Users just kept thinking they were up to date. And if they weren't? Oh, it wasn't the Blackberry's fault. It was probably the server or the network or something. Everything is fine. They loved their Blackberries. Brand loyalty through the roof.

Is it important that I'm connected? Or that I FEEL connected?

When it comes to communication technologies, there's a unique UX force at work. There are few things more annoying than a communication device (that costs hundreds of dollars no less!) that makes me feel disconnected. So device makers are forced to think about ways to make people happier by hiding errors or pretending things are fine. There is a very real incentive for them to do so, as I saw first hand with the Blackberry vs ActiveSync status issue. Sometimes it can literally make your brand.

But in the case of Apple, sometimes the things you do to make your users happy can come back to haunt you.

Steve Jobs on Flash: substandard apps that limit the progress of the platform

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

--Steve Jobs re: Flash via taoeffect.com

Kind of interesting. Is he talking about Flash or is he talking about Java? 

I spent a few years writing deeply complex user experiences in Java. Invariably it was a technology tax we had to pay to try to get proper native-like experiences on exactly this kind of thing -- an intermediate layer (Java Swing) between the underlying machine (Win32).

Writing desktop apps in Java was a real pain. Flash, while easier, is still another inefficient layer between you and the underlying metal. You're right, Steve. Lets not subject people to that anymore.

On designer humility

The latest much ado about nothing on the Internet: Blogger Joshua Blankenship has written a pot-calling-the-kettle-black diatribe against Dustin Curtis's apparent lack of humility in criticizing American Airlines. He seems to think that Dustin should be a little more humble in his criticisms of such a large, immovable corporation whose complexity seemingly exceeds that of a very good designer.

I call bullshit.

A humble designer is one who affects no change indeed. Designers should be less humble. When engineers or business guys or management or *anyone* makes a product lousier, they should get up and shout, and raise hell. Designers should NOT 'know their place.' Because if the powers that be keep their power, then we will continue to live in a barely working cesspool of compromises and bad experiences.

Apple wins because the guy who cares the most about user experience happens to run the show. And last I checked, humble wasn’t really a word you could use to describe him.

The iPhone killer of the future needs vertical integration. (Why Android is doomed.)

Google’s dependence on hardware and carrier partners puts the final product out of their control — and into the control of companies whose histories have shown them to be incompetent at design and hostile to users.
--John Gruber via daringfireball.net

Windows Mobile was a failed experiment in relying on hardware vendors, partners, and carriers to build a great consumer device. There were too many cooks in the kitchen. There were too many integration points.

Case in point: Bug fixes from the field. To get a device to market, there was the core device team, then a mobile operator/commercialization team, and finally the carrier's support / deployment team. There was no shared database of bugs. No shared responsibility. When schedules were stretched thin and the device was failing even simple tasks, it was too easy to point fingers. Oh, that's the carrier team's fault. That's the OS team's fault. That's the commercialization team's fault. Hardware's fault. Nobody took the reins to ensure a quality product was being created.

The Palm Pre team is doing it right. Google would do well to take note here. Building cool techie platform toys that let you create nifty Powerpoint decks is all well and good. But it's all a huge waste until there's a satisfied user using your awesome phone that works great.

It comes down to responsibility. Someone has to be responsible. If you're creating a device, and you want it to succeed, it better be you and your team.