iPhone Applications and Start Screens

Have you ever launched the Notes application on your iPhone, tried to open a note, and wondered why the application would not respond? Here’s the reason: iPhone apps can show an image while they’re loading, and Apple has decided to show an image of how the application looked the last time you used it. So you weren’t actually looking at your notes; you were looking at an image of your notes, and no amount of tapping could possibly have caused a note to open.

You can not figure out when Notes has finished loading, other than by frantically dragging around the screen until the application starts responding.

There’s a lot of discussion going on about what kind of image applications should show while they are launching¹. When deciding what image to show, you have to consider what the image tells the application’s user.

Here’s what Apple’s image tells the iPhone’s user:

The application is basically making the user look like a fool for trying to use a picture of an application.

Another popular approach is to show a logo or a similar “please wait” image. What is this telling the user?

It doesn’t matter that showing the logo is not the reason why the user has to wait; his perception is that the logo makes him wait.

I should also point out that these types of start screens go against Apple’s iPhone Human Interface Guidelines, which say:

It’s important to emphasize that the reason to supply a launch image is to improve user experience; it is not an opportunity to provide:

• An “application entry experience,” such as a splash screen
• An About window
• Branding elements, unless they are a static part of your application’s first screen

Because users are likely to switch among applications frequently and quickly, you should make every effort to cut launch time to a minimum, and you should design a launch image that downplays the experience rather than drawing attention to it.

So do avoid these types of start screens.²

A third popular approach is to show a generic user interface which makes it obvious that the application is loading. This is the actual start image shown by the fantastic Instapaper iPhone application:

Now we’re finally getting somewhere. This is a pretty reasonable start screen: It makes it obvious that the application is not yet usable, and it makes it obvious that the application is busy working on the user’s behalf instead of needlessly interrupting him.

While Apple’s iPhone HIG tells developers to avoid text in start screens since start screens can’t be translated, I think in this particular case, the “Loading…” label is quite universally understandable.

But it’s not quite the best solution yet. While iPhone applications from developers outside of Apple can’t have dynamic start screens³, the best solution would be to show the application’s previous state and point out that the application is still loading:

In addition to explaining to the user why he has to wait, this gives him some context; it reminds him of what he was working on the last time he used the application, and it tells him what state the application will be in once it has finished loading.

November 10th, 2008 / Tags: iphone, default.png, splash screen, start screen, launch screen, please wait, loading / Trackback

Dear iPhone Game Developers

Please don’t turn off my music when I play your game.

October 11th, 2008 / Tags: iphone, games, development, music, podcasts / Trackback

Write an App Store Review Today

You’ve probably noticed that most user reviews on the iPhone’s App Store are beyond useless. Instead of talking about the app, many reviews complain about the application’s price or its icon or its screenshots. Presumably, these reviewers never even bothered to try the application before they wrote their review.

I propose we make Monday “App Store Review Day”. Every monday, pick one application you’ve actually used and write a sane review. It doesn’t have to be a positive review, but it has to be an informed review.¹

If enough people wrote at least one informative review each week, perhaps App Store reviews could yet become useful.

August 11th, 2008 / Tags: app store, apple, iphone, user reviews, craig hockenberry, furbo, Marco Arment / Trackback

NetShare and International iPhone Owners

About a week ago, Nullriver released an iPhone application called NetShare. The application briefly appeared in Apple’s iPhone App Store, then disappeared. It reappeared again shortly thereafter, only to disappear again. As of now, the application is not available, and Apple has given no explanation for why the application was removed.

NetShare is a tethering application. It can be used to wirelessly share the iPhone’s Internet connection with a Mac or PC. Since AT&T does not allow tethering for iPhones, a possible explanation for Apple’s removal of the application would be that they are enforcing AT&T’s contract.

Unfortunately, the application was removed from the App Store not only in the US, but world-wide. The App Store does allow for area-specific applications. Some applications available in the US App Store are not available in the European store. Apple could have removed NetShare only in the US store; instead, they removed the application everywhere.

My iPhone contract is with Swisscom. I do not have an unlimited data plan, so it makes no sense for Swisscom to forbid tethering.¹ Assuming that Apple did indeed pull the application to enforce AT&T’s contract, it is a bit disturbing to find out that they plan on enforcing AT&T’s contract even for people who have signed no contract with AT&T. Hopefully, Apple will clarify this soon.

Addendum : iPhone Alley writes that Apple is “reviewing user contracts with providers” to see whether NetShare is allowed. So hopefully, it’ll come back over here. Can Apple show an app solely based on what contract the user has, or will it simply not be shown in areas where there may potentially be people who have contracts which don’t allow NetShare?

August 6th, 2008 / Tags: netshare, nullriver, apple, iphone, swisscom, at&t / Trackback

iPhone, third-party applications and Settings.app

In the Mobile Human Interface Guidelines, Apple recommends putting application preferences into the iPhone’s system-wide Settings application. Here are two quotes from the Mobile HIG:

Another important facet of the single application model is the way you handle application-specific preferences. On iPhone OS–based devices, users set preferences in the Settings application. Your iPhone application can supply such preferences, but this means that they must quit your application when they want to access them in Settings. If you follow the standard guidelines and offer settings that users need to set once, and then rarely, if ever, again, the user experience of your application should be smooth.

And

Among all types of iPhone applications, a productivity application is the most likely to supply preferences, or settings, the user can specify in the Settings application.

John Gruber points out that many applications ignore this rule:

One other thing I noticed might prove important when using other applications, as well. AIM’s settings are not accessed within the app itself; rather, AIM adds a settings panel to the system-wide Settings app.

(…)

AOL is not being untoward in this regard; this is actually what Apple encourages iPhone developers to do. Based on the apps I’ve seen today, though, most developers aren’t doing it. That’s a bad combination — if most third-party apps display their settings screens themselves, then when users do encounter an app that uses the system-wide Settings app, they’re very likely to assume that the app simply doesn’t have any settings.

One of the applications not putting its preferences into Settings.app is OmniFocus for the iPhone. If you don’t have the application, you can see this in this screencast. I decided to ask the Omni Group what their rationale for keeping preferences inside the application was, and the OmniGroup’s Ken Case replied, saying:

Settings which appear in the built-in Settings application can’t have any code associated with them, they can only use standard controls which store data in a few limited data types. We wanted to provide the ability to copy synchronization settings from a Mac on your local Wi-Fi network, which involves code—making it impossible to put our settings in the global Settings application.

The above point makes this moot, obviously, but in general another important factor to consider is whether the user might change a setting more than once or whether it’s really just a one-time configuration. If you’re talking about something like Mail settings, it’s pretty much fire and forget—but in OmniFocus’ case, the user might want to quickly switch between looking at all their completed items and then switch back to looking at just their available actions, and they wouldn’t want to have to relaunch OmniFocus each time they did this.

(The built-in Settings also gives us a convenient place to put commands to Send Feedback, look up Online Help, and view Release Notes, but that wasn’t a primary factor.)

This makes sense. Apple should either update Settings.app to support the features developers need, or change its HIG, telling devs not to put settings into Settings.app, but to keep them in their applications.

If Apple decides to update Settings.app, applications should put all prefs into Settings.app and turn preferences which users want to change regularly - such as whether the user sees completed items or just available actions - into “regular” application features accessible outside the application’s preferences.

Either way, the current situation is confusing, as it is never clear where a particular application’s settings can be found, or indeed if an application has any settings at all.

July 12th, 2008 / Tags: iphone, gruber, daringfireball, omnigroup, usability, settings / Trackback