Lesson from Apple? Fixing Problems...

This week I learned a new way to fix problems with applications I build. I learned this lesson from a letter from Apple. I'll call it the "big bar" fix.

Apple recently had people complain about signal reception in its new iPhone 4. It seems at time, the reception can drop drastically if you grip the phone in a certain way. While people have pointed towards a fault in the antenna, Apple indicates this is not the case. In their open letter, Apple describes the problem as follows:

To start with, gripping almost any mobile phone in certain ways will reduce its reception by 1 or more bars. This is true of iPhone 4, iPhone 3GS, as well as many Droid, Nokia and RIM phones. But some users have reported that iPhone 4 can drop 4 or 5 bars when tightly held in a way which covers the black strip in the lower left corner of the metal band. This is a far bigger drop than normal, and as a result some have accused the iPhone 4 of having a faulty antenna design.

Apple identified the problem. They stated that the problem is not the phone, but rather in the logic used to display bars on the phone so that a person knows the signal strength. In some instances, the display is showing too many bars - the signal strength is being overstated on the phone. Said differently, you never had a good signal to begin with, so when it dropped drastically, it actually adjusted to the correct value. The indication of a higher number of bars was wrong.

How do you fix this problem? First you fix the formula used to calculate and display signal strength, which Apple is doing. More importantly, you change the display showing the signal strength. If a lower signal strengths is going to be shown, then rather than have the user see fewer bars that are smaller, Apple is adjusting the bar size so that while you are still seeing fewer bars, they are bigger. Obviously the signal strength won't seem as bad if the bars are bigger.

How do I apply this lesson to my own applications? It is simple. If there is an issue in an application, developers tend to display an error box. While we can't get rid of the error boxes without feeling bad, we can make them smaller and reduce the wording to something simpler. By making the error boxes smaller and simplifying the wording, people won't possibly realize that there is an error. Better yet, we can reduce the display time to a fraction of a second and go ahead and close the error dialog for the user. After all, they will need to close it soon enough anyway.

As an example, why should Microsoft show an error box that says something like "Windows just recovered from a fatal error," when they could simply say "Windows is running (again)." Keep it simple. Keep it friendly. Don't worry your users will problems! Better yet, make this a small box and tuck it down in the corner out of the way. The objective with a "big bar" solution is to make the user feel good. Big error boxes that are in your face don't provide the right big bar experience!

In all seriousness, stating that you are displaying bigger bars as part of a fix for a complaint people have about signal strength is simply goofy and appears to be a ploy to make lower signal strength not seem so low. If any company other than Apple stated this change as part of their solution to a similar issue, they would be skewered alive. It will be interesting to see what people say in response to Apple's taking this stance.

The lesson from Apple is that changing the interface to the user by using bigger bars can make the issue of low signal strength not seem so bad. Clear error messages are always good, as is good feedback in your applications. For some users, seeing bigger bars on a cell phone interface might even make the signal strength seem stronger! Don't consider this a bit of deflection, or even a bit of deception. Rather, consider it a lesson from Apple...



Blog Categories

Blog Archives

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds