furbo.org

First off, thanks to everyone for the kind words about the new version of Twitterrific. It’s really great to get all this awesome feedback! Don’t forget to post a review on iTunes: we want as many stars as possible :-)

As with any first software release, there are a few known issues:

• After you upload a picture to TwitPic, the keyboard disappears. This is an Apple bug which we can’t fix (they are working on the problem.) In the meantime, you can try to tap on the text area and when the loupe appears, so will the keyboard. If that doesn’t work, try tapping the “Close” button and then tap the Reply or Post button again to refresh the interface (your text will be preserved.)
• Some images uploaded to TwitPic are not rotated correctly. Again, this is a bug with the EXIF data that Apple is putting into the JPEG image. We are working on a workaround now, but didn’t have it ready in time for the launch. We’ve also heard from TwitPic that they are working on some AJAX code that will rotate the images directly in the browser, so that may help in the short term.
• Scrolling is jerky. Because we have links and variable height rows in the list, we are pushing the limits of the processor. We have some ideas of how to improve this in the future, by only displaying the text of the tweet after the scroll finishes (similar to how the avatar images work now.) This is really tricky code to write and we had a very tight deadline—trust me when I say it bugs us, too :-)
• The Sigur Rós ad from The Deck displays incorrectly. The root of the problem is that Twitterrific can’t handle HTML entities. It could, but that would compound the problems with jerky scrolling mentioned above. We’re working with the folks at The Deck to change this over to UTF-8 so it will work OK on the phone.
• Entering a “+” sign in your tweet ends up as a space after being posted. It’s surprising that no one typed this character in several months of testing. We’ll fix this ASAP.
• Launching the application can cause a restart of the iPhone. All indications at this point are that this is a problem with the iPhone OS and not Twitterrific (it’s happening with other applications.) We are working with Apple to resolve the issue. Please make sure to send any crash reports if prompted by iTunes. No matter how much you beta test, there’s always one problem that slips by—even if you’re Apple.
• Sorry, but we can’t offer discounts or free upgrades for the iPhone version to current Twitterrific users. There are no provisions on the App Store for developers to do this. Please contact Apple if you think there should be a way to do this—we already have :-)
• The push notification service announced by Apple during the WWDC keynote will not be available until later this year. We don’t know if Twitterrific will be able to support it or not: it requires additions/changes at the source of the data (Twitter) and the volume of information may be too great for Apple to handle. We are definitely keeping an eye on things and talking to the right people.

If you find something that’s not on this list, please let us know by using the contact form at the Iconfactory. Select “Support” in the drop-down menu. Thanks!

Now that I’ve covered some of the technical issues with background processing for iPhone applications, let’s take a look at why it’s a bad idea from the user’s point-of-view.

Assume that Apple changes their mind about background processing tomorrow–anyone can do whatever they want in the background. All the naysayers rejoice, and in a year’s time they’ll be asking Apple to remove background processing.

Why? Same reason as always. The iPhone requires a fundamentally different approach to user interaction. Something that goes way beyond the obvious things like the multi-touch interface.

If you can have a background process running on your iPhone, what is that process going to do when it detects a state change? What happens with a buddy comes online, or a new piece of data is available, or when a long running calculation is completed?

You’re going to want to notify the user, right? Again, “desktop thinking” makes this sound like a simple thing. But it’s not.

The iPhone is going to attract network aware applications like moths to a flame. In a year’s time there will be hundreds, if not thousands, of applications using the Wi-Fi and EDGE connections. You’ll likely have several of them on your iPhone: let’s say you have five.

You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”

Can you see where I’m going with this? Your phone soon becomes a fricken’ pinball machine as multiple applications fight for your attention. With 24 notification permutations for every application, things will quickly get out of hand.

The desktop has evolved several mechanisms for notification: bouncing Dock icons, bezel windows, menubar icons, and things like Growl. These mechanisms all work together because they can share a common screen without unduly overloading the user.

But on the iPhone, you have a limited area and associated mechanisms for getting the user’s attention. In effect, it creates a notification bottleneck.

This notification bottleneck forces the user to work when figuring out who needs attention. First they have to recognize the notification by sound, feel or sight (or a combination of those senses.) Then they have to navigate to the recognized application, which may not be easy given the phone’s current state. Finally they need to deal with the source of the notification. Now imagine doing all this frequently: the network will end up being a constant source of distraction.

If you’re still unconvinced, let me ask you one final question: do you want to get IM notifications while you’re making a 911 call?