(For more resources on iPhone, see here.)
Starting the application with a proper Default.png
When an application loads for the first time, the user is presented with a variable duration of loading time. This period can change depending on the device processor or RAM, memory requirements of the application, current free memory available on the device, and any number of other variables.
Ideally, the user will only be required to sit through this period for a brief moment. However, this duration can last up to several seconds in length if we're loading an image intensive app on an older device.
Apple has designed a loading screen method that is required by each app, through the inclusion of a PNG file in our app bundle. In this recipe, we'll discuss two interface strategies for this loading period.
For this recipe, we should have a computer with Photoshop or another image creation tool. We should also have knowledge of the devices and orientation types that our application will support.
How to do it...
Loading times are an inherent problem with all types of software, regardless of platform. As hardware has increased in speed, these times have diminished, but they haven't become non-existent.
Apple created a simple design fix for this problem, offering up a quick and easy way to load an image during the loading period. Here are quick, simple steps in order to create an image that will display during the loading period:
- We should start by designing up an art image measuring either 320 x 480 pixels or 320 x 460 pixels (or the equivalent Retina display double resolution size), containing the art piece which we would like the user to see during the loading screen.
- Next, we should then save and name that file Default.png.
- Finally, we should include that image in the resource bundle of our application project in XCode.
- If we're creating a web application, we can also include the image in our HTML code so that the image is displayed when the user launches the web app. To do this, we should name our file startup.png and place the following code in our HTML header:
<link rel="apple-touch-startup-image" href="/startup.png">
iOS is designed to search the bundle for a PNG with this name, and then display it on load if it's available. Once we finish these steps, we have accomplished everything we need to do to have the image load on startup.
When it comes to design styles and technique on what we should include on the image, there are two different strategies that we can take:
The right way
Apple's documentation on the Default.png is fairly clear. According to their design documents, this image should serve as a clean visual of what the application would look like with no pre-populated data.
In essence, this provides the perception that the application has already loaded, but the user is just waiting for the data to populate. It's a subtle way to trick the user into thinking our app loads quicker than it actually does.
This trick works because it typically takes the brain about 2-4 seconds to see an image on screen, process the layout of what is before them, and then make a decision. Because the loading process for an application is relatively short, typically under three seconds, presenting an overlay of the interface as the Default.png loading image allows the brain to use this time to process what is about to be presented on screen.
Phone - © 2007-2011 Apple Inc.
As shown above, Phone, Messages, and Photos all load preview images with their Default.png displays, which offer the perception that the application loads very quickly. By preparing the user for the app during the Default.png load image period, the user will subconsciously perceive that our application loads faster than it actually does.
The wrong, but possibly preferable way
While we're supposed to use the loading image to prepare the user for our app, we may want this time to serve another purpose, such as a way to advertise our development team or Twitter account. It's an important and powerful moment for application branding, so we should feel free to use this moment as a way to build brand equity through use of a logo and appropriate styling.
There is no set rule that says we can't use the Default.png as an advertisement of sorts, and many applications succeed using this strategy.
We'll need to include a Default.png in the application package, to give our app something to display before loading has concluded. Depending on our application type and loading period, we should be able to include a screen that fits into one of these two methods with ease.
How it works...
Apple has designed iOS so that it is easy to present a loading screen to the user—we only need to create a PNG image, name it Default, and include it inside of our application bundle. The operating system will do the rest for us.
Because this predetermined method works so well, we can instead focus on optimizing the image to best fit into our application. It's important to remember that the Default image is the first thing that the user will ever see in our app, and we should take considerable care in the creation of the art. Attention to detail with such seemingly minute application attributes is what sets outstanding applications apart.
For some situations, creating an image that looks like similar to the first screen after launch will be ideal; as it will offer the perception that our application loads quicker than it actually does. This will increase user appreciation and enjoyment of our app.
In other situations, it may be desirable to go with this splash screen approach instead of the prescribed approach of faking application load. For applications where loading takes a considerable period of time, usually anything over four seconds, it is difficult to use the load to ease users into our app like Apple does with Mail, Messages, or Phone. The pause becomes so long that the user instead believes that the application has broken.
So in such situations, these banner loading Default.png images may provide a better alternative, offering up a way for the user to know that they have indeed loaded the correct application, but that it will still be several seconds before they're able to interact with the initial view.
Regardless of what method we choose, it will be necessary to include a Default.png in with the project. With a bit of work and consideration, we can create something that will win the hearts of our user base.
Now that we've learned more about different styles of Default images, we can put a bit of extra effort into going the extra mile with the image as well. Here are a few tips on how to produce a great Default.png.
We can retina optimize our Default.png too
Like any other art piece, we can include a Retina display specific graphic inside our application. By adding the standard @2x modifier to the end of the image, iOS will know to pull this image instead when running a higher resolution device.
As the Default.png is the first image presented to the user, we should take extra effort to show that we're dedicated to a full retina optimized experience.
Prepare for multiple orientations
On the iPhone, we're limited to only one Default.png orientation requirement, as applications tend to be optimized for one orientation and we can create the Default image to account for the prominent orientation.
However, on the iPad, each application should be designed for optimal use in either orientation. This requires us to create two Default images, one for the app launching in portrait and another for if the app launches in landscape.
Apple has created an easy system for the simple creation of such different images. We only need to create the images and add a simple –Portrait or –Landscape modifier (for example, Default-Portrait.png) in order to launch the appropriate view.
Planning our application UI for a first impression
In the real world, we spend a good deal of time preparing for first impressions. We tuck our shirts in, spend time making sure our hair looks perfect, and iron our shirts so that they're wrinkle free. We do this because it's a common understanding that others will greatly have their feelings toward us determined on the basis of how we look or talk during our first meeting. If we don't impress them off the bat, they'll never be willing to warm up to us.
Mobile application development falls under the same sense of unspoken understanding. If our application isn't easy to manage or understand in the first 30 seconds, users will have no qualms over closing our work and deleting it off their device.
Are the colors attractive? Is information easy to access? Do they seem to know what the correct next step is? These are all important questions that the user will subconsciously answer during their first several minutes inside our work.
In this recipe, we'll discuss a couple of design decisions that we can make, in order to impress our users early.
Little is needed for this recipe. Ideally, the implementation of this recipe will take place throughout the course of development, as we fine tune along the way.
How to do it...
The Default.png image is the first visual that every user will see when they check out our app, but it isn't necessarily the first visual that their brain will take a good deal of time processing.
That honor will fall on our actual application, once loaded in full glory for all eyes to behold. It's a somewhat magical moment, as our work is first presented to the audience. Like the opening line of a play, first chapter of a book, the front door to a house, the first few minutes of a game, this is an important moment in the user's determination of what they think about our app.
So how do we present our application with its best foot forward? Here are a couple of simple tips, to help users quickly feel at home inside of our application:
- Use simple, clean In-App icons to help signify key features: When selecting icons to fall inside of Tab Bar cells or Navigation buttons, it's important to ensure that our icon use falls in line with expectations found in other applications. The magnifying glass represents search, a star presumes favorites or top performers, three dots represent that the tab contains multiple options, and a square with a pencil infers that the button composes a new email.
- Start by giving users a push in the right direction: Feel free to offer up a friendly push to the user from the get go. If we make the first step clear, the subsequent steps may become a bit more obvious, as shown in the following screenshot from Grades by Tapity:
Grades - © Tapity
- Hold back sound, flashy animation, or bright colors until the user has had the chance to settle in.
- Offer content early, if only a little taste of what is to come.
How it works...
Creating an intuitive application interface from the first second a user opens our app is an art, which requires that we shape our app carefully overtime. As we add new features, create new art, or conceive new ways to present data on screen, we should always be thinking about what a new user will think upon first presentation of our app.
For Step 1, Apple routinely updates the Mobile Human Interface Guidelines , https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html, with suggestions on how to use icons that come built into the iOS SDK .
These guidelines account for a limited quantity of icons and uses, which makes it a bit difficult to gain a good grasp of how we should truly utilize such pieces in our app. While it would be impossible to create an exhaustive list of general shapes and their associated meaning on iOS, the best we can do is make ourselves familiar with as many apps as we possibly can in order to best understand how others have paved the road of user expectations.
In Step 2, we took a look at Grades by Jeremy Olsen. The application allows users to manage test scores and class grades, with an exceptional level of open-ended opportunity. No matter how complex or simple a class's grade scale may be, the application handles the data with ease.
The application makes such scalability easy for the user by using a simple contextual clue on initial launch. By offering direction on how to start tracking information for a class, the user is essentially given a tutorial without even realizing that they're being taught. There is no confusion as to what the first step is, and the user can jump right in and start keeping track of their grades.
For Step three, if we are in the mood, or feel as if it's necessary to make our application stand out through a good deal of noise, eccentric color, or excessive animation, that's perfectly fine. Each application has a different art strategy and depending on our target audience, these elements may very much make sense in our work.
However, we should be hesitant to use such vivid visuals or loud sounds during the user's introduction to our app. While the user may be in our target audience and enjoy our app otherwise, such sudden extreme sense stimulation may be off-putting.
Instead, we should slowly walk our users into the application and give them a chance to prepare for any noise or bright lights that we may throw their way. This way, the user is expecting whatever we decide to present. For example, if we offer loud noises right after the initial launch and our user is sitting in a quiet auditorium, the successive embarrassing situation may turn the user away from our application, just because we presented them with an unexpected bout of displeasure.
By working the user into our loud, colorful, flashy application, we'll be less likely to scare away potential long-term users in the first five minute of using our app.
With regards to Step 3, if our application is a content heavy application, such as a social network or application that features extensive listings of local sport scores, we may be inclined to encourage users to sign up for our service before we offer the meat and potatoes of our app. Most designers are confident that their content is so valuable, users will jump through whatever hoops necessary in order to gain access.
However, the typical user is an impatient soul, unlikely to fill out forms in order to gain access to an app's walled garden. Instead they'll download our app, see the frictional barrier in front of the content, and decide that they're not that interested.
By offering a quick glimpse, we hold some hope in convincing the user that our content is worth going through the sign up process. Service applications such as Instagram and Twitter do a great job at this, offering a handful of images or text entries before asking the user to sign up.
These quick entries give an example of the wealth of content laying behind the apparent barrier of a sign up form. Through these quick previews, the user can gain an idea as to whether they'll enjoy the service or not. By using a preview method such as this, users are able to gauge interest before the sign up, saving everyone's valuable time.
Finally, we know that every iOS device user is familiar with Apple's bundled applications, as they are the only applications that come pre-installed and as such, are the only applications that every user is likely to have used. We should look here for inspiration, as Apple offers a good deal of guidance with their work. When placing an icon on our Tab Bar, ask yourself if every user will instantly know the tabs function based on the imagery. If we have doubts, there is probably a better alternative icon.
In many respects, this recipe isn't so much a one-time action like many others found throughout this book. Instead, it's a design philosophy which we will fine tune as we create more applications for the iPhone or iPad.
Tutorials and help menus were a somewhat taboo topic during the early days of the App Store, with Apple holding a hard stance that apps requiring such a menu were too complex for the mobile platform.
Times are changing a bit, with Apple themselves offering help menus in complex apps like Garageband or iMovie. Here's a tip on how to best offer support inside of our app.
Lend a helping hand
While most early apps were capable of success without a help menu, many new apps have become much more complex and require such a way to teach the user about app features.
If we want to provide help for our users, we have two choices. One thing we could do is create a specific help view; we could do something like provide a table of topics that the user can tap upon in order to learn more about. This allows us to dive in-depth into a variety of topics, with as much detail as we feel is required.
We could also provide a tutorial through on screen overlays, where tapping a help button presents short tips on screen with insight into different app features. This method works well because we can directly point at an interface element and tell the user what its purpose is. However, because we're overlaying such information on top of the interface, we must be brief when using this choice.
Our app may be simple and self-explanatory enough, that we won't need one of these two methods in order to provide a help menu. However, if we think that we need to lend a hand, either of these two routes would work well.
(For more resources on iPhone, see here.)
Dealing with phone calls or text messages
iOS may be capable of multitasking on newer devices, but the foundation of the operating system is still very much focused on presenting one application at a time. Even though applications can run in the background, there is still only one app visible on screen.
So what happens if the user gets a text message or phone call while in the process of using our application? It's extremely likely that a call from mom or dad is much more important than our app, even if we'd like to believe otherwise. We have to assume that at any given moment, the user could leave unexpectedly.
So how we design our interface to transition the user in and out of the application is key. If the user has spent minutes configuring our app a specific way, and that work is lost when they leave to answer a text message, they may find themselves extremely frustrated with this experience.
For this recipe, we'll discuss ways in which we can prepare for text messages, phone calls, or anything else that may pull the user away from our app.
For this application, you may think that we need an iPhone with an active service plan on hand in order to test entering back into an app after having left for a text or call, but we really don't. To test this behavior, we can simply press the Home button and return to the home screen, then re-launch our app.
When a user leaves for a text message or phone call, no special processes are going on behind the scenes, and the operating system handles the event much like any other instance in which the user quits and leaves our app. So we only need to press the Home button and leave in order to test this scenario.
How to do it...
So what's the best way to go about preparing our application for persistent back and forth switching? Here are a few tips:
- If the user is in the middle of an action when the call or text message comes, then find a way to bring the user back to that action
- However, if the action is time sensitive, like an action in a game, find a way to ease the user back in
- In complex situations, try to offer help or a reminder about what is going on
How it works...
Phone calls or text messages are a somewhat unique with regards to the user's experience on leaving an application, as such scenarios are always sudden and unexpected.
For the first point, regardless as to if our application is optimized for multitasking in iOS 4 or not, we should be sure to save data inside of the application as often as possible. This will allow the user to ease back into the app quickly.
For example, imagine that we're writing an application that lets a user send digital postcards to friends. In our app, the user needs to select their friend's email address, select an artistic background, and compose a message. Imagine this application if no data is saved and when the user leaves to check a quick text message, their entire postcard is deleted. This experience would become rather frustrating, as the user would need to remember this problem when using the app and hold off on answering calls or messages when composing a message.
We should help the user out with this problem by saving their content in order to offer them the opportunity to continue the card they were previously working on before they left. Save intervals will vary based on what we're building, but in general, it would be optimal to save whenever new content is created.
On the second point, we don't always want to rush and place the user back in the same position they were at before they left. If we're building a game, or some other application in which timing is important, this could be disorienting and also cause frustration.
For example, a game that requires users to avoid enemy spaceships requires a strong sense of timing as pace picks up in the game. If the user receives a phone call and must leave the app, then returns after the call, we need to ease them back into the game as their sense of timing is completely off.
Working users back into our game doesn't require an advanced interface, as we may need to only create a quick several second countdown timer before restarting game play. A simple "3, 2, 1, GO!" can help get the user ready to avoid alien invasion.
In the most advanced application, we should remember that under the circumstance of a user being pulled away from the application for a call or text message, there will be little time to prepare for being pulled from the app. The user may not have time to finish an important impending complex task, which may be difficult to jump back into.
Finally, if this scenario seems likely for our application, we need to take a step back and evaluate how our interface can be designed in order to toss the user back in without fear.
A great way to go about easing the user back in, is to save their data but start the user back a step or two behind where they were when they left. We don't want to take them far back or require them to start a complex process from scratch, but walking someone back through their last step can be an easy way to refresh the memory.
We could also go about offering a quick visual overlay reminder to give a clue as to what step is required next. If we point the user toward the next step, they'll also have a sense of direction to help lead them through our app.
In the case of a phone call, the user must make what is essentially an instantaneous choice as to if they want to leave the app and answer the call. If they choose to leave, there is no time to sit and assure that all data has been saved. As such, it's our job to ensure that when they come back, it will be as if they never even left.
If our application doesn't stand up against such a test, and it takes considerable time to jump back into our app after leaving, users will find such scenarios frustrating and find another app to use instead.
For this recipe, we focused on text messages and phone calls, so we may be lead to believe that the iPhone is the only device where we need to worry about having the user pulled away from us. But if we're working on an iPad or iPod touch compatible app, we still have a bit to worry about.
They're not text messages, but they're close enough
As of iOS 4, Apple has decided to use an alert-based notification system. This method works extremely well given the small iPhone or iPod touch screen, with a simple blue alert view popping up on screen and allowing the user to take action. Text messages arrive in this way, so the view is extremely familiar to any iPhone user.
The same alert method is also used for local notifications and push notifications as well, which means that the entirety of this recipe is also applicable to any application that uses either notification type. While such distracts are less likely on devices that can't receive calls or texts, it is still a problem we should keep in mind.
Working with multitasking in iOS 4
With the advent of iOS 4, iPhone applications could finally multitask, allowing users to quickly jump back and forth between applications. In reality, the devices aren't actually multitasking; they're instead saving the state of our application temporarily until the user returns.
However, this save state allows users to jump right back where they left off. This change has brought new user expectations, and our interfaces should respond accordingly.
In this recipe, we'll break down what users expect, and how we can deliver an exceptional multitasking experience in our app.
To understand multitasking, we could get by using the iOS Simulator built into XCode. We would be best off with a capable device on hand, so that we could test the features on an iPhone or iPad, but it isn't a requirement.
iPhone models 3GS and beyond, third generation iPod touch devices and beyond, and all iPad models are capable of multitasking functionality.
How to do it...
In iOS 4, Apple provided new ways for our application to multitask, which has greatly benefited the overall operating system user experience. With this new technique, users can quickly switch between applications, with no need to restart their task from the beginning just because they opened a text message.
While multitasking is helpful, it isn't multitasking in the sense that we may be familiar with. Instead of letting any app run at all times, applications can perform one of six different multitasking services to enhance their app. Here is a rundown of each service, and how they'll affect the interface of our app:
- Fast app switching
- Background audio
- Voice over IP
- Background location
- Push or local notifications
- Task finishing
Multitasking has provided a variety of new features and interface complexities in iOS, which is both good and bad for our application. If used well, we can create an exceptional new experience beyond what was previously possible. However, if we become careless, we can quickly create an interface nightmare for the user. If we work to include these tips into our app, then we'll be well on the road to multitasking success.
How it works...
The most important development change of iOS 4 was the implementation of fast app switching, as all applications could now load much more quickly for the user. This change allowed users to move from task to task with ease, which in turn created a more powerful computing experience where applications could become more in-depth and feature filled.
This ability for rapid movement was the most influential change from a design standpoint, and the most important consideration change when it comes to interface design. Pre-multitasking apps were much like movies; a dedicated start and end with the expectation that the viewer will see out the entire experience. Multitasking changed the experience to be much more like a book, specifically a dictionary or encyclopedia, where the user will instead have a dedicated beginning with the assumption that they can come back whenever necessary with little friction.
Fast app switching is the one type of multitasking that we should always include in our application, as it allows for the user to quickly jump out of the app and then return back to where they had been before leaving. While the user is gone, the app isn't actually running in the background. Instead, the app is essentially frozen in memory until the user returns, when state is restored.
For most applications, little interface work will need to be done for fast app switching, as the user will be able to jump back in right where they left off. It's a great solution for users, and for designers as well.
In applications such as games, it may be best to provide the user a countdown restart to the game after returning from a fast app switch. Games typically require quick reflexes and for the user to be prepared for action on screen, and throwing them back into the game immediately may cause frustration.
Otherwise, little work is required from an interface aspect when it comes to fast app switching.
For audio applications, such as Music or Pandora, background audio allows for music to play in the background while the user browses other applications.
From an interface standpoint, this has always been a point of consideration as the user has always been able to play the Music application while using other apps, iOS 4 just allows third party App Store applications to do the same.
The biggest problem for our interface will revolve around if we use audio cues to help aid our interface, with actions on screen leading to sound effects to verify that the action has occurred successfully. The audible swoop heard when sending a message in Mail is a great example of this type of sound. If we include these in our app, we should verify that our application does not interfere with background audio, or force background audio to quit playing while the user is inside of our app.
If the user is playing music from Pandora in the background when they load up our app, it's probably because they're rather listening to their music. We shouldn't take this as an insult. Instead, we should ensure that the user will have an exceptional experience regardless as to what audio is playing.
Voice over IP (VOIP) allows applications to use Internet calling services such as Skype as an alternative method for calling friends or family. Such applications were previously allowed on iOS, but the user was required to remain inside the VOIP app while on the call. Now, the user can stay on the call regardless as to which application is currently open.
If we're looking to build a VOIP application, essentially no work is required for us to handle users when outside of our app. If the user is to leave, the device status bar will double in to denote the VOIP connection, much like it occurs when the user is on a regular call.
The only interface situation that we may want to consider is the scenario that occurs when the user ends a VOIP call outside of our app, as we should design the interface to be easy to understand and manage the next time they return.
The new background location multitasking capabilities allows us to keep note of the user's coordinates when they are using another app. This can be useful if we are developing a GPS or location-based social networking app.
From an interface standpoint, we should design our app views so that they can quickly change in order to accommodate for the user's new location, once they hop back into our application.
For example, if we're designing a social network that allows a traveling user to identify local restaurants, a slow and clunky interface may cause background location to make our app look inaccurate and useless, especially as if it appears our location is incorrect because the app interface hasn't provided obvious enough clues to inform the user that the content on the screen is adjusting to account for the new location.
Push notifications have been a fixture since iOS 3, and Local notifications were introduced in iOS 4 to help provide similar functionality without need of an Internet connection.
Notifications themselves don't really affect our interface, as they're more of an intrusion on another application's interface when we implement them into our app. However, we should prepare our own interface with regards to how we'll ease users back into our app if we decide to do so with the notification.
For example, an application designed to promote animal care may send a local notification to remind users that it is time to walk their dog, thanks to a timer we've set. Our two notification options for the user may be, Walk the Dog or Cancel. If the user taps Walk the Dog, we may prefer to send the user back into our application, where they will make note that the dog had been walked.
We should concentrate on optimizing the view that the user arrives in on, as it will quite possibly be the only view that they see while making the note and we'll want to make the experience quick and simple for the user by making it easy to enter whatever data is required so that they can get back to what they were doing.
Task finishing in iOS 4 allows our app to finalize any process that may need to finish, without requiring the user to sit and wait for the process to end. For example, if we create a photo editing application, this service could be offered to allow the photo to be uploaded to Facebook or Flickr without requiring the user to wait to finalize the upload.
The one subtle change in our interface for this feature could be a simple note or reminder to the user that our application includes this service, as it may not be directly known to the user that the feature is supported. A user may instead assume that their upload progress would be deleted if their app was closed, driving them to stay inside our application and wait when they really don't have to.
While the metaphor may be somewhat of a stretch, we should take note of the drastic fundamental changes between the two experiences and work to optimize our work accordingly.
Multitasking brings a multitude of great features to iOS, but it does have its disadvantages as well. Here's a look at how our multitasking app may actually upset users.
Multitasking can be frustrating
While there are many advantages to multitasking, the solution can be frustrating to certain users.
The required application close on exit of iOS 3 and earlier was often seen as a significant advantage to novice users or young children. When such users became frustrated or confused with an app, they only needed to hit the big Home button , and then reopen the app in order to start again from the beginning. It was a crude method, but effective at solving a problem.
iOS 4 ruined this solution, which caused a bit of frustration for those who relied upon this strategy when stuck. Upon closing and reopening, the user is brought right back to the point of difficulty, unable to escape.
If we have a hunch that our target audience could be classified as "new to the operating system", we should probably provide easy access to the home view whenever possible, to offer an escape button of sorts. This way, users can still get back to square one if something does go wrong and don't know how to navigate themselves out of the jam.
(For more resources on iPhone, see here.)
Periodical downloads and Newsstand in iOS 5
Apple finally included a highly desired feature in iOS 5, allowing for magazines and newspaper applications to download new issues while running in the background. This simple feature allows for users to have fresh content waiting upon launch of our app.
If we're designing a magazine, newspaper, or any other type of periodical, this will be a desirable feature and we'll need to make some small interface changes to accommodate. In this recipe, we'll take a look at what we'll need to do to help our application handle this new type of multitasking in iOS 5.
For this application, an iPad or iPhone device running our application will be desirable to help test the multitasking features of our app.
How to do it...
Designing an application to support background issue downloading and the interface change requirements associated with the new Newsstand feature are quite simple. In a few easy steps, our interface will be ready for Newsstand:
- Include the UINewsstandApp key in the application's Info.plist file.
- Create the server programming backend to send the new periodical background push notification to the application
- Integrate icon art files that will allow for the periodical cover to change as content is updated periodically
- Design an application interface that properly notifies users of new content
After instituting these quick changes, our application will be ready to shine using Newsstand on the iPhone or iPad.
How it works...
Newsstand is an easy to integrate way to help the user enjoy the daily, weekly, or monthly content that may come along with our magazine or newspaper application for iPhone or iPad. Using the simple steps above, we'll quickly be up to speed with the new form of multitasking.
In step one, we'll make a quick Boolean addition to the Info.plist to help indicate that our application utilizes background downloads for periodical data. Likewise in step two, our programming team will need to follow Apple's Newsstand Kit Framework Reference located on the iOS Development Center at http://developer.apple.com/library/prerelease/ios/#documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html#//apple_ref/doc/uid/TP40010838.
With step three, we'll need to provide an updated icon file to represent the updated content of our periodical. Much like a magazine cover, attractive and relevant art provides an easy way to win over reader's attention and Apple has allowed for us to quickly update our icon to reflect content updates in iOS 5. We'll include these new cover art assets to the bundle of each issue and then the updated cover will display in Newsstand.
For step four, we'll need to take a look at our application individually and determine what would be the best way to provide information inside the application on updated content. We have a lot of old tools available as well, as we can use badges on the app icon in order to also indicate to the user that a new issue is available. Inside of our app, we may want to provide an Alert View or another context sensitive feature to notify the user that content has been updated inside of our periodical.
Once we've followed these simple steps, our application will be ready for Newsstand and periodical background downloading on iOS.
Periodical background downloads are new to iOS 5, but they're not the only way to provide background task services in iOS.
Periodicals are quite an exclusive application genre and it won't be common to work on such projects for the iPhone or iPad unless we work for a big newspaper or magazine publisher.
But we can still use multitasking inside of other applications. In iOS 4, Apple allowed developers to tie their app to specific multitasking types so that music could be played in the background, VOIP calls could be made, and more.
For a complete breakdown of different multitasking options and how they can influence our application interface design, see the previous recipe titled Working with Multitasking in iOS 4.
Making accommodations for other apps that are multitasking
In a preceding recipe, we discussed a multitude of multitasking services that were introduced to developers in iOS 4, along with several suggestions as to how we could alter our interface in order to take advantage of such features.
Nevertheless, how do we optimize our interface in order to be mindful of other applications that are currently multitasking? In this recipe, we'll discuss strategies for creating a super app experience, even when other developers are attempting to steal the glory.
For this recipe, we should have a multitasking device on hand if possible in order to test how our app performs while other applications are running.
It is possible to simulate the tall status bar inside of the iOS Simulator built into XCode, but it would be ideal to experience the change in usable resolution on an actual device.
How to do it...
Any app can take advantage of multitasking, so we should prepare for the design benefits that are possible through implementing it into our own app, along with the potential compromises required when other apps include the services as well. Here's a look at a couple of potential design problems that we should be aware of when other apps are multitasking:
- Fast app switching
- Background audio
- Voice over IP
Now that we've discussed both ways to benefit from multitasking, as well as ways to ensure that other applications multitasking doesn't ruin our experience, we'll be more than capable of creating an application that is flexible under any circumstance.
How it works...
Being a good multitasking steward for other apps is often an important interface consideration, as it is one of those traits that is implemented in a manner that the user will never notice such subtle differences unless we've messed it up completely. And when we do mess it up, it will be painfully obvious and ruin the app experience.
Often, the problem can be solved with a little extra spacing or other minor adjustments, so the actual implementation isn't tough. It's remembering to test for such a scenario that is the hard part; as developers often overlook such use cases when on a deadline.
Optimization for fast app switching isn't the exception as much as it is the reality with iOS development in a post iOS 4 world. Because users aren't required to finish a task in one app before finishing a task in another, we'll find that it isn't uncommon to see users swapping back and forth between two or three apps in repetition and quick succession. A power user could easily slip between an RSS reader, instant messaging client, and email in a 30 second period.
To conquer this problem, our application should be continuously saving user data in preparation for an exodus. The fast app switching service offers many services to aid this inside of our application; it's just our job to assure that our application flows properly.
There really isn't a magic formula to answer the question as to what "feels right" when it comes to application entrance and exit. It's a skill that takes time, but we'll quickly recognize the flow when we see or feel it. The goal is to eliminate interface components that cause friction or increase the amount of time that it takes to open our app and accomplish a task. When a user can quickly move back and forth with ease, we'll have mastered fast app switching.
As we discussed in the previous recipe on implementing multitasking for our own gain, the biggest difficulty for our interface will occur when we depend upon the audio inside of our application but the user is currently listening to an audio track from another application.
Ideally, we should abide by the user's clear intention to listen to the previously playing track, and never interrupt this audio when possible. We should feel free to quickly interrupt if necessary for short sound effects, but we should keep the primary audio track in control of the application that had possession of the user's headphones when they entered our app initially.
Apps that are the biggest criminals of this behavior are game applications, which look to use their own audio instead of the musical track being supplied by an app like Music or Pandora.
It's important to remember that users were listening to this song before opening our application for a reason, likely because they prefer the song to a game soundtrack. This is a personal user preference that we're never going to change, so we shouldn't attempt to force our music, even if we think it's a better choice. Instead, we should allow the user to listen to their preferred track when inside our app.
While this tip applies to Voice over IP with regards to specific device multitasking services, we will also run into this same interface problem when the user is currently on a phone call or using WiFi tethering while concurrently using our application.
When such services are used, iOS doubles the size of the status bar as a way to notify the user that a phone call or tethering service is currently taking place on the device. In the following screenshot, we can see how Calculator solves this problem:
Calculator - © 2007-2011 Apple Inc.
The resulting shift gives our application essentially 20 less pixels to work with. 20 pixels only accounts for approximately four percent of our total screen height, but this distance can create a drastic shift in the appearance of our application on screen.
Depending upon how our application is coded, this double status bar will either cover up or push down part of the interface view. Such small changes seem minute, but can easyily cause a drastic difference and make parts of our application unusable.
It seems as if these situations are outliers, as an individual is less likely to be off a phone call than on a call, but these scenarios are essential because when a user enters our application when on a VOIP call or regular call, it's probably because they're looking up information to share with the person on the other line. If they are unable to access the information because of our inability to plan for the tall status bar, the user will become disappointed or frustrated with our work.
It is possible to cover the tall status bar, but only when our application is in a full screen mode where the status bar is covered throughout all use of the app. Game applications most commonly use such a behavior and while this helps eliminate the 40 pixel status bar problem, it may not be ideal for our application to always feature this trait.
The iPhone Simulator built into XCode lets us simulate these double status bar cases with ease, and we should test each view of our application for such a scenario, to guarantee that users will always be able to gather information from our app.
If we want our work to be exceptional, we should be mindful to test for the double status bar or audio problems when using our application.
We talk a bit about the tall status bar in this recipe, but when exactly will it become a problem? Here's a look at different scenarios that can create a tall status bar.
Double status bar all the way
This 20-pixel addition to the standard status bar can cause quite a bit of design headache if we're unprepared. Here's a look at different ways in which the user can bring about the tall status bar:
- When on a phone call and leaving the Phone application, which is only applicable on the iPhone.
- When in the process of using WiFi, Bluetooth, or USB tethering, which is also only possible on the iPhone.
- When on a VOIP call using an application such as Skype, and the user leaves the VOIP app. This behavior is possible on all iOS devices.
- During an audio recording that continues to run even though the user exited the app, a double status bar will be shown. Any device with a microphone is subject to this possible double bar.
In this article, we discussed the finer points of application launching, closing, and multitasking. We discussed a few techniques that will help ensure that users enjoy their first experience, their transition back to other iOS apps, and their return to our application.
- Development of iPhone Applications [Article]
- Interface Designing for Games in iOS [Article]
- iPhone: Issues Related to Calls, SMS, and Contacts [Article]
- iPhone Applications Tune-Up: Design for Performance [Article]
- iPhone: Customizing our Icon, Navigation Bar, and Tab Bar [Article]