1. Spin Zone
At some point in the development lifecycle of an iPhone application,
a developer must decide how to handle support for rotation
of the device. The basics of rotation support are very simple, though each
view in each application has different, often complicated, considerations.
How will interface elements scale? How will typography react? How should
content react when the rectangle defining its boundaries changes
dimensions and orientation?
Some developers choose to ignore rotation events, keeping the
orientation of their application pinned to the screen and non-reactive to
changes in the device. They always have the option to enhance the
application at a later date, should users request rotation support. Other
developers implement full rotation support, with rich animation and
intuitive layout responses that keep their application usable from any
angle. Both of these options contribute to a reliable user
experience.
The spin zone anti-pattern occurs when an application implements
rotation support in an ad-hoc fashion. For example, perhaps the
application supports rotation only in one direction—90 degrees clockwise
but not counterclockwise. Another example of the anti-pattern is
arbitrarily—from the point of view of the user—supporting rotation for
different screens. Worse still is requiring rotation for some screens, but
not others.
The reasons that partial rotation support is damaging to the user experience
aren’t mysterious. If a user has to constantly check whether each screen
supports rotation, it brings the device to the forefront and makes the
hardware the center of attention, taking users out of the otherwise
immersive experience. Users should not be forced to use a “try and see”
approach to constantly test support for capabilities in an
application.
2. The Bouncer
The App Store contains many great applications that act as clients
for web applications. For example, there are several excellent
applications for interacting with social services like Twitter or
publishing content to blogs.
A requirement for most Cocoa Touch web application clients is to
provide authentication credentials, such as a username and password,
for an account on the remote web service with which the mobile application
interacts.
The bouncer anti-pattern occurs when the Cocoa Touch application
requires authentication credentials for operation, but doesn’t offer the
option for creating those credentials inside the application. Instead,
the application opens Safari and forces registration through a web page,
or worse, offers no option for registration at all.
There are cases in which registration from a mobile application
makes little sense. For example, an application that allows you to check
the balance in your savings account or retirement fund would require that
the accounts already exist at the financial institution. The WordPress application requires external authentication using
a WordPress-powered blog hosted on the Web. Because of this externality,
creating an account using only the iPhone application would be impossible.
Rather than simply blocking access for new users, the WordPress
application allows access to information about the application and about WordPress. Figure 1 shows the WordPress application.
Most web applications are technically capable of allowing
registration from any HTTP compatible client, including Cocoa Touch
applications. The ability to register from an application may be limited
by the terms of service. If policy prevents registration, applications should state as much and offer
details on acceptable registration processes or sites.
The LinkedIn and Facebook applications are good examples of
applications that implement the
bouncer anti-pattern. Figure 2 shows the
LinkedIn and Facebook applications after launch. Each application
assumes that the user is familiar with the purpose of the application and
either has or knows how to attain credentials to use the
application.
An excellent example of an application that avoids the bouncer
pattern is Foursquare. The authors of Foursquare developed the
application with usability in mind and avoided the bouncer pattern in a
simple, clean manner. Figure 3 shows the
welcome screen for the application.
