garry’s posthaven

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.

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.

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.