Applying the DOIG model to Android notifications

Conceptually, the DOIG model is suitable for scenarios using Android notifications. The nature of Android notifications causes the responder to discover information about a notification in stages. This enables decisions to be made on whether to continue on towards consuming a notification, or abandon the response part way through. Rather than making an assumption on what point in the response behaviour correctly signifies being interruptible (i.e., the measure of success), which will likely change on at least a per-application basis, a spectrum of potential responses can be considered (shown in Figure 3.2); these being:

• Null Responses - Cases where the user does not show any observable response behaviour, either because the user was not physically interrupted or did not want to switch tasks for any notification, from any application.

• Partial Responses - Cases where the user begins to respond, but abandons after further information. For example, they turn the screen on, discover the notification relates to an email (e.g., through the icon displayed on the top bar, Figure 1.3) but exit at that point (or after unlocking the device and reading the sender or subject).

• Complete Responses - Cases where the user consumes the notification and completes a response. For example, tapping on the notification and reading an email or filling in a survey.

3.2 The Decision-On-Information-Gain (DOIG) model 49

Given that a response can be null, partial, or complete, the potential measures for success can be described as whether the user is at least reachable [122], willing to engage[122] to some extent, or is receptive [29, 122, 76] to what they are interrupted with. These independent measures fit together under the wider umbrella of mobile notification interruptibility, providing flexibility for labelling interruption behaviour for different definitions. From this the following terms can be defined:

• Reachability, which indicates whether a response will at least be started (i.e., not null), or not.

• Engageability, which indicates whether a response will be started but abandoned without formally consuming the notification (i.e., partial response), either because merely noticing the notification is sufficient, or it is undesirable to pursue it further.

• Receptivity, which indicates whether the user is receptive to the notification con- tent and either consumes it by removing it in some way (i.e., complete response).

Modelling a range of response behaviour (as shown in Figure 3.2) means that different definitions of what constitutes a successful notification can be accounted for. It may be that an application considers a notification to be a success if the user was reachable (i.e., the response is not null), such as reminders. Whereas others may require the user to reach a specific later stage in the response (i.e., at least engageable), or consume it completely and open the application (i.e., receptive).

This is contrary to the wider research space, that typically labels interruptibility using a strict measure of success (e.g., just receptivity [29]), which often relies on the user to open the interrupting application (e.g., [97]) or fill in a survey (e.g., [92, 99, 108, 94, 76, 129]).

50 3.2 The Decision-On-Information-Gain (DOIG) model

! Exit

Reachability Engageability Receptivity

(Null Response) (Partial Responses)

(Complete Response)

D1 D2 D3

Exit Exit Exit

Figure 3.2: A visualisation of the linear sequence of decisions made during a typ- ical response to an Android notification (𝑘 = 3). After the interruption occurs (!), at each point new information is given (e.g., the application icon) the user must decide (e.g., D1) whether to continue on to the next decision (e.g., D2), (up until either the notification is consumed) or exit at a particular decision. Figure from [124].

3.2.2.1 Flexibility and limitations in applying the model for Android and other notification systems

Several uncontrollable factors can impact what unique decisions are observable in response to an Android notification. The DOIG model is flexible to these limitations by not defining a set number of decisions or strict methods for observing decisions being made, allowing the model to remain usable if the Android notification ecosystem evolves over time.

For example, due to technical restrictions imposed by the Android operating system, some relevant UI events (e.g., accessing the Notification Drawer, shown in Figure 1.2) are not observable by third party applications without privacy-sensitive Accessibility permissions. This limits which decisions are observable, particularly when the device is in use. Discussed further in Appendix Tables A.1 and A.2, if the device is not in use when the notification is delivered, decision outcomes for D1 and D2 (Figure 3.2) can be observed through the process of the user turning on the screen (indicating reachability) and unlocking the device (indicating engageability) to discover more information. However, if the device is already in use, while a decision process occurs, there are currently no observable system events for D1 and D2.

3.2 The Decision-On-Information-Gain (DOIG) model 51

Secondly, technical limitations of these devices prevent the ability to distinguish between the reasons why a user may not be reachable. For example, it could be that an individual is not physically interrupted in order to make the first decision to begin responding or not, or it could be that they were and chose not to switch from their current task. This is a challenge for interruptibility studies in general, leading to some studies investigating the physiological ability to switch focus explicitly as discussed in Chapter 2 (e.g., using EEG readings [71]). However from the perspective of labelling notifications using the DOIG model, this issue is mitigated as in either case, the outcome remains the same in that the individual was not reachable and the notification was ineffective.

Thirdly, the example decision process visualised in Figure 3.2 represents a typical An- droid notification. While the notification convention is standardised and imposes design constraints, some variability remains for individual applications in what information can be presented, when, and how. Additionally some more recent versions of Android can enable the user to show some notifications on the lock-screen. In both of these cases, the number of observable decisions (𝑘) will need to be adapted, with Chapter 6 addressing this explicitly. For example, D1 and D2 may be merged if the audio tone used for interruption is distinguishable for a given application.

Beyond Android, other mobile operating systems (such as iOS) or environments (such as PC tasks [118, 116]) have slightly different implementations of notifications. For example, on iOS devices, notifications can turn on the screen without explicit user inter- action. However, as the intention here is to observe and not change how a notification is presented and responded to, these variations require a flexible model (and for any future changes), which the DOIG model provides. Finally, in the worse case, the DOIG model falls back to capturing the same information as a black-box approach (i.e., interruption interaction events).