Chapter 9: Notifying and Informing Users

Sometimes the user’s attention needs to be directed away from the task she’s currently occupied with. Different situations need different notification methods. Few things demand user’s attention immediately and most can be brought to the user’s attention more subtlety.

This chapter covers notifications in a wider sense. It covers more than just the Android status bar notifications, which are the most common association people make when talking about Android notifications. Android SDK provides developers with multiple ways to notify and inform users.

All notifications are interruptive by nature. Using the right kind of notification method in the right circumstance is important for creating a good user experience. This chapter explains when notifications should be used and which method is best in which situation.

Android Notification methods

Let’s first take a look at what kind of notification methods Android offers. Each of the methods is suited for a different situation. Some of them are more interruptive than others and must therefore be used more carefully. On the other hand, the less interruptive notifications go unnoticed more easily and, therefore, aren’t a great choice for important notifications.

The following sections cover these techniques in order from the least interruptive to the most interruptive.

Inline/embedded notifications

Inline or embedded notifications include information about tasks and events and are shown as part of the user interface. This kind of notification doesn’t interrupt the users, but also goes unnoticed very easily. Evernote’s notification messages, which appear at the bottom of its landing screen, are a good example of an embedded message. See Figure 9-1.

In general, use these kinds of notifications to indicate something that adds value to the user’s experience but isn’t something that users have to worry about or react to.

Toasts

A toast is a simple text message that appears on-screen for a short time and then disappears automatically. Users cannot interact with toasts.

Toasts are rendered on top of the user interface, so they are likely to draw the user’s attention. Therefore they are slightly more interruptive than inline notifications. Because the toasts get dismissed automatically, they are unlikely to irritate users if used moderately. They can also be easily missed by users who are distracted. Therefore toasts cannot be used to indicate anything that is important enough not to be missed. You would not want to use toasts to notify users about new emails, for example.

A very good use for toasts is to confirm operations and operation success. For example, the Gmail client shows a toast message when a message the user has composed is being sent (see Figure 9-2). If the user misses this message, it’s not a big deal. The toast also does not prevent or delay the user from moving to a new task.

Status bar notifications

Whenever Android notifications are mentioned they generally refer to Android status bar notifications. Status bar notifications are subtle but informative. They also have a very low risk of being unnoticed by users. Also Android APIs provide developers very easy ways to implement them.

By far the biggest problem plaguing Android applications related to status bar notifications is overuse. Consider the following criteria before creating a status bar notification. Each notification should fill all of these criteria.

• There is a single screen where the tapping the notification will naturally take the user, or tapping the notification directly terminates the ongoing task.

• The user can do something about the information and react to it.

• The user needs or wants that information. I mean the user! It is not enough for you to want the user to see it.

Tip: A good example of a status bar notification is a new email notification. Users are likely going to react to a new email or at least want to be informed about it. A bad status bar notification would be a notification about a background task, such as an email being sent successfully.

Pop-up dialog boxes

There are very few situations when pop-up windows are justified. A pop-up always interrupts the user’s task and thought process. They are likely to irritate users and make the app feel cumbersome.

Use a pop-up dialog box to alert users about something critical that simply cannot be ignored. A good example of a justified pop-up is the Android system pop-up telling the user that the device battery is nearly empty (see Figure 9-3).

Figure 9-3: The Android system battery low window is an example of justified pop-up usage.

Source: Android

When to notify users

Users don’t need to know everything that’s going on in the system. Never bother users if you don’t absolutely have to. Unnecessary notifications will only irritate your users and make your app look bad.

The following sections take a look at few situations where a notification is needed and justified.

Ongoing background tasks

When your app is doing something in the background that consumes a lot of resources or uses a network connection, you should let the users know that is going on. This doesn’t apply to short network usages like checking if a server has updates or sending short burst of information over the network. This applies to downloading large data files or maintaining a continuous connection to a server, for example during an IP phone call.

Using status bar notifications in these cases is the right choice. If you can estimate how long the process will take, you should use a progress bar to give users a better understanding as to what is going on and how long they can expect the task to continue. The progress bar also gives the users an idea as to how fast the task is going. Google Play uses the on-screen progress indicator (see Figure 9-4) and the status bar notification (see Figure 9-5) when users are installing an app. The on-screen notification allows users to cancel the process. The status bar notification, if tapped, takes the users to the app installation page where they can cancel the process.

It is very important that users feel like they are in control of everything that is happening on their phones. This is especially important with background tasks.

Events

Updates can be sent to users via event notifications. These kinds of events might be a new email, an incoming message, a calendar event notification, and even a completed background task. These are by far the most common cases for using event notifications.

Figure 9-6 demonstrates three event notifications. Each one takes the user directly to the logical app and screen if tapped. The screenshot notification opens the Android gallery, allowing the user to view and share the image very easily. The notification opens the email app directly from the email, which is being previewed in the notification. The Google Play notification opens the newly installed app. Note that the Google Play notification actually opens a different app that has triggered the notification. Nothing prevents you from doing that if it makes sense.

Figure 9-6: Three event notifications using status bar notifications.

Source: Android

Tip: Do not use status bar notifications if the event is happening on the screen the user is currently viewing. Use user interface components, and embedded notifications to keep the information in context.

Errors

When an app encounters an error that it cannot correct automatically, it must usually be brought to the user’s attention. Depending on how critical the error is and if it happens on a foreground or on a background task, the means of notification can be very different.

A good error notification should always do the following:

• Try to fix itself automatically without notifying the user. Only after you have tried this first should you show an error!

• Explain what happened, concisely and using laymen’s terms. Avoid long explanations and technical terms.

• Provide the user a direct and simple way to react and fix the problem.

• Stay out of the way.

• Be displayed in the context where the error happened.

Errors in Foreground Tasks

When there’s an error in the foreground task, the one the user is trying to perform, it usually stops the workflow. These errors also have the biggest probability to irritate the users. When users are already dealing with an error, you should make sure that the user interface that displays the error is as helpful as possible.

Consider an example of a common error-handling situation, an app login. Many apps require users to log in to the app system in order to fully benefit from the app. A user is normally provided a login screen with two text fields—a username and password.

If the user types in the wrong password or username, the app will fail to log the user in. There isn’t much the app can do to automatically recover from the problem, so an error notification is needed.

What is the best notification method to use in this case? A status bar notification would not make sense as the error happens in the foreground task. You have to select among a pop-up window, a toast, and an inline notification. Compare the following three screenshots. Figure 9-7 shows an example of an app using a pop-up window; Figure 9-8 shows an example of a toast; and Figure 9-9 shows an example of using an inline message.

A short analysis of the three options clearly points to the inline error notification. Its benefits are many. It is displayed right in the context, users cannot miss it, and it does not prevent users from continuing. The same approach applies to many problems. The pop-up will always prevent the user from trying again directly. The toast is too subtle and can be missed easily by the user, especially when you consider the hectic environments in which many people use their phones.

Make sure your errors stay out of the way, and don’t prevent users from trying to solve the issue.

Figure 9-9: An example app that uses an inline message to tell the user that the password is wrong.

Errors in Background Tasks

When something goes wrong with an automated background task, you must use more subtle ways to notify the user. A failing background task rarely needs the user’s attention right away. Figure 9-10 shows an example of an app using a subtle embedded notification to tell the user that a background task, syncing in this case, did not work due to a connection problem. A failure in the sync process does not prevent users from using the app, so there’s no reason to make the notification more obtrusive. The same thing applies if your app is loading new information like emails, tweets, or news stories. Let the users continue to use the app without interrupting them.

Figure 9-10: Evernote uses an embedded notification to tell the user that background sync did not work.

Source: Evernote Corporation

Sometimes there is an error in a background task that the user started. This could be, for example, when installing an app to the device. Because the user started the task and the error is preventing the task from being completed, this error needs to be brought to the user’s attention. Creating a status bar notification is the best option. Make sure that tapping the notification takes the user directly to the screen where the user can do something about it or at least see more information about the problem.

When not to notify users

As mentioned, users don’t have to and don’t want to know everything that is going on in their phone. Apps launch processes and check data on servers all the time. You can use an embedded notification in the form of an animated progress bar or something similar to tell the user that the current app is doing something. You should never use a status bar notification to simply point out that your app is checking for new messages or something similar.

Many apps download data in the background. Not all of the data, like social network messages, are directly aimed at the user. Think carefully when using notification in cases like that. Flooding users with notifications is probably going to annoy them and likely lead to a bad review and users uninstalling your app.

Note that giving a user an option to disable notifications is not an excuse to overuse them. Your default notifications settings must be good. You can give users options to add more notifications through the app settings, but pick a conservative default to begin with.

Avoiding pop-ups

There is a good reason why most desktop Internet browsers ship with pop-up blockers enabled by default. At some point the Internet was overwhelmed with unnecessary pop-up windows. Many users still associate pop-up windows with bad Internet websites. You don’t want your app to be one of them!

Here are some things you should never use pop-up windows for:

• Ask users to rate your app. A much better alternative is to use embedded notifications to do this.

• Advertise anything.

• Ask users to subscribe to additional services or mailing lists.

• Notify users about a completion, progress, or failure of a task that is not in the foreground.

As a rule of thumb, never use pop-ups. Break this rule only when you’re sure that the pop-up is the only possible way to notify your users. Only when the app is simply unable to continue without user input should a pop-up be used. You might think that having to press the OK button is just one tap and it should not matter, but it does. Figures 9-11 and 9-12 show two examples of apps handling the same error, a loss of network connection. The first app uses a pop-up, which forces users to stop and press the button. The second app simply replaces the content with the error message. The second app is much more fluent and pleasant to use.

You might be tempted to think that using pop-ups is okay if you time the pop-up trigger to open the pop-up between user tasks. Although on paper it appears as if user tasks have natural points where users seem idle and not concentrating on anything, in practice this is not usually true. Users are likely already occupied by the next task, and a pop-up will interrupt them.

Getting the most from status bar notifications

As mentioned, status bar notifications are very useful in many situations. The Android notification system is also very flexible and easy to use for both developers and users. This section looks into using the status bar notifications and related design guidelines. Using the status bar notifications correctly will make your app that much better.

The Android Design guidelines have a lot more information about status bar notifications at: http://developer.android.com/design/patterns/notifications.html. Note that in the design guidelines when they refer to notifications, they generally mean only status bar notifications.

Notification content

A status bar notification is composed of multiple parts. Note that not all of these are available in older Android versions.

The status bar notification icon is the most important part of the notification. Once the operating system has rotated the text, users can see the icon only until they pull the notification bar down (see Figure 9-13, F).

Figure 9-13: Components of a status bar notification.

Source: Android

Pulling down the notification bar expands the status bar and displays more information about the notifications. Table 9-1 describes the components outlined in Figure 9-13.

Table 9-1 Notification components shown in Figure 9-13.

Symbol	Description
A	Large icon or image. If this is not provided, the operating system will use the notification icon.
B	Notification title. This should be short but descriptive.
C	Notification text. This describes what the notification is about in more detail or tells users what actions they can take.
D	Notification timestamp. The time of the event.
E	Notification secondary icon. This is the same icon used on the status bar. If no large icon or image is provided, this area will be empty.
F	Status bar notification icon.

The notification bar icons are covered in more detail in Chapter 11 with rest of the platform icons.

Stacking notifications

Events often occur multiple times before the user reacts to them. For example, maybe the user receives multiple emails, or maybe there are multiple instant messages. You have two options to handle situations like this. Either you create a new notification, or amend the one that is already visible. The right method depends on the situation. When the notifications are very similar in nature and come from the same source—for example multiple instant messages from the same person—stacking them into a single notification makes sense. But when the user receives emails from different accounts, it probably makes sense to create a separate notification for each account.

For stacked notifications, you can add a number that indicates the number of notifications pending next to the secondary notification icon.

Be timely

Events happen at certain times. Remember to track the time correctly. The timestamp on your notification can tell the user a lot about the notification if it is correct. If you, for example, poll a server for new information every hour and notice new messages, you should use the time information in the messages to set the notification timestamp. The information as to when the message was received is more valuable to the users than when your app decided to poll the server.

In some cases notifications are meaningful only for a limited period of time. You should consider if your app’s notifications are like that. If it is clear that a notification is no longer useful to your users, consider removing it automatically.

Ongoing tasks

There is a special notification type for ongoing tasks like music playing, background downloads or other ongoing background tasks, and so on. If you set the ongoing flag on your notification, it cannot be removed from the status bar. Even when a user clears all notifications, all the ongoing notifications will remain.

For any ongoing notifications, make sure that you provide an easy way for users to terminate the operations. Also remember to handle all errors correctly. Few things are more annoying to users than ongoing notifications that are left behind due to an error in the process.

To cancel an ongoing notification, you can either open a page where the user can cancel it or you can cancel the task directly when the user taps the notification. In the later case, you must add text informing users about that. Add something like “tap to cancel download” as the notification text.

Implementing status bar notifications

To create a status bar notification, you use a NotificationManager class. You get an instance of the class from a context object with the following call.

(NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE);

To create the notification itself, you create a new notification object and set the parameters and flags you need. Note in Android 3.0 or newer that you can use a helper class Notification.Builder to create the notification.

Notification notification = new Notification(icon, tickerText, when);

notification.setLatestEventInfo(context, title, text, pendingIntent);

notification.flags |= Notification.FLAG_AUTO_CANCEL;

notificationManager.notify(NOTIFICATION_ID, notification);

To make the example an ongoing notification, you simply add an ongoing flag to the notification, as the following line of code demonstrates.

notification.flags |= Notification.FLAG_ONGOING_EVENT

For the full specification, see the Android developer documentation at http://developer.android.com/reference/android/app/Notification.html and http://developer.android.com/reference/android/app/Notification.Builder.html.

What actually happens when a user taps the notification? Well, the notifications are integrated into the rest of the system using the Android intent system. When you create a notification, you give the operating system a pending intent that is triggered when the user taps your notification. As discussed in Chapter 6, the intent mechanism is very powerful and flexible. You can use what you’ve learned about intents when building your notifications.

The pending intent is given as a parameter to the notification (see the previous code snippet). To create the pending intent, you first create the intent you want to be triggered and wrap it into a PendingIntent object. You can use everything you’ve learned about intents here. All flags and so on are available to you.

Intent notificationIntent = new Intent(this.context,TargetActivityActivity.class);

notificationIntent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);

PendingIntent pendingIntent = PendingIntent.getActivity(this.context,

   NOTIFICATION_ID, notificationIntent, 0);

Status Bar Notifications in Android 4.1 Jelly Bean

One of the best features of Android 4.1 Jelly Bean is its much improved notification system. The new notification system allows developers to build much richer notifications that can contain graphics and action buttons for users to perform actions lime posting a Google+ post directly from the notification. Figure 9-14 shows two examples of the new notifications on Android 4.1.

Figure 9-14: Two examples of the Android 4.1 notifications.

Source: Android

To create these new notifications, you can utilize a helper class called Notification.Builder. You can easily build notification with larger images, more text, as well as new inbox style notifications. You can find the full definition of all of the new notification types from the Android online documentation at http://developer.android.com/reference/android/app/Notification.BigPictureStyle.html, http://developer.android.com/reference/android/app/Notification.BigTextStyle.html, and http://developer.android.com/reference/android/app/Notification.InboxStyle.html.

The following example shows how to use the Notification.Builder helper class to build the second notification in the Figure 9-14:

        Notification.Builder builder = new Notification.Builder(this)

                .setContentTitle(“Inbox Style”)

                .setContentText(“This is a inbox Style notification”)

                .setSmallIcon(R.drawable.ic_launcher)

                .addAction(android.R.drawable.ic_dialog_dialer, “first action”,

                        pendingIntentFirst)

                .addAction(android.R.drawable.ic_delete, “second action”,

                        pendingIntentSecond);

        Notification notification = new Notification.InboxStyle(builder)

                .addLine(“First message”).addLine(“Second message”)

                .addLine(“Thrid message”).setSummaryText(“+5 more messages”)

                .build();

Scan the QR code with your Android phone to open the companion app and try out a functional example.

Notification Priority

Android 4.1 also added notification priorities. This is a welcome change as it allows developers to define how important each notification is. There are five notification priority levels. They are defined as constants in the Notification class (see http://developer.android.com/reference/android/app/Notification.html).

The notification priority affects the way the operating system shows each notification. Low-priority notifications might be shown only when a user opens the notification tray. High-priority notifications might be shown more often expanded.

Tip: When defining your app’s notification priorities, be conservative. Use the lowest priority that is appropriate. That way your app will feel like it knows how to behave. Setting all notifications to the maximum priority will likely only annoy your users.

Backward Compatibility of Notifications

The new notifications will not be back-ported to the older operating system versions. Notifications are such an integral part of the system that they cannot be changed without updating the whole system. This doesn’t mean that you should not use the new notifications in your apps. You should! You just need to make sure that doing so won’t break the compatibility with older Android versions.

Google has hinted that the new notification builder helper will be added to the support package, and developers can use it to build notifications. They are automatically adapted to the runtime Android version. At the time of this writing, Google has not yet made this addition. There are, however, community-maintained projects that have the same functionality. One of them is Jake Wharton’s NotificationCompat2 project. You can find it from github at https://github.com/JakeWharton/NotificationCompat2.

Summary

Informing users is a delicate task. Picking the wrong mechanism to inform them can lead to compromised usability. You must carefully consider which method you should use in each case. Your notifications should be as discrete as possible, but also noticeable. Different types of events require different methods. Correctly selecting among inline notifications, toasts, pop-ups, and status bar notifications is important.

The Android status bar notification system is a very powerful tool in your toolbox. Status bar notification can be used in many different cases. Be careful not to overuse these notifications, though. Overuse can annoy the users and your app can seem to behave arrogantly.