What’s in the Apps for Context? Extending a Sensor for Studying App Usage to Informing Context-awareness

Matthias BöhmerChristian LanderAntonio Krüger

UbiMI Workshop at UbiComp 2013September 8-9, 2013Zürich, Switzerland

1983

Evolution

4

Logging app usage AppSensor: Tracing App Usage

who wherewhen how longwhich app

A

Data from Deployment

- 4,125 users from various countries- 22,626 apps from 20 categories- 4.92 million data points- 127 days

6

During Course of a Day

- App usage correlates with circadian circle

25,000

50,000

75,000

100,000

125,000

150,000

175,000

200,000

12 a

m

2 am

4 am

6 am

8 am

10 a

m

12 p

m

2 pm

4 pm

6 pm

8 pm

10 p

m

Appl

icat

ion

laun

ches

7

Probability of Launches!"#$

!#$

"#$

%#$

&#$

'#$

(#$

)#$

*#$

+#$

!,#$

!!#$

!"-$

!-$

"-$

%-$

&-$

'-$

(-$

)-$

*-$

+-$

!,-$

!!-$ ./01/203#4/

5#6789:; <;:=; >--;?=0@;:= )A+. )A). )A*. )A(. )A%. )A&. )A,. )A+. *A!. *A,. )A). )A%. )A,. (A+. (A*. (A&. (A(. (A(. (A&. (A(. )A,. )A&. )A'. )A&. (A*%. "B%+* +C0$D8; &A'. 'A". 'A&. 'A*. 'A*. 'A(. 'A'. 'A". 'A&. 'A!. &A). &A%. &A%. &A". &A". &A%. &A&. &A,. &A&. &A". &A!. &A!. &A!. &A&. &A%!. "B!'! !B*!,

C0$$67D8#3D07 &&A+. &!A!. %*A%. %'A&. %!A(. %!A*. %"A). %&A). %+A&. &&A*. &+A,. '"A(. '&A*. ''A". ''A". '(A!. ''A). '(A*. ')A!. '(A!. '&A*. '%A%. '"A,. &+A,. &+A',. "B)(+ '',E73:=3#D7$:73 ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,. ,A,". !"( &%

FD7#78: ,A". ,A%. ,A%. ,A". ,A!. ,A!. ,A!. ,A". ,A%. ,A%. ,A&. ,A'. ,A%. ,A%. ,A&. ,A%. ,A%. ,A". ,A". ,A". ,A". ,A". ,A". ,A". ,A"'. (,& !(&G#$:; %A". %A,. %A,. "A). "A'. "A%. "A". !A). !A+. !A+. "A,. "A!. "A". "A". "A". "A%. "A%. "A". "A". "A&. "A). %A,. %A,. %A". "A%,. !B)!( !B),"H:#439 ,A%. ,A&. ,A&. ,A&. ,A(. ,A(. ,A). ,A(. ,A&. ,A%. ,A%. ,A". ,A". ,A". ,A". ,A". ,A". ,A". ,A". ,A%. ,A". ,A%. ,A". ,A%. ,A"(. '&, "")

5DI=#=D:;/J/K:$0 ,A&. ,A'. ,A(. ,A). ,A+. ,A*. ,A). ,A(. ,A'. ,A&. ,A%. ,A%. ,A". ,A". ,A". ,A". ,A". ,A". ,A". ,A". ,A%. ,A%. ,A%. ,A%. ,A%,. !B"() !!)5D1:;3L4: ,A*. ,A+. !A,. !A&. !A%. !A'. !A&. !A&. !A!. ,A+. ,A(. ,A(. ,A'. ,A'. ,A'. ,A'. ,A(. ,A'. ,A%. ,A&. ,A&. ,A'. ,A'. ,A'. ,A(,. "B!%" &'!

M643D$:ND# "A!. "A!. "A&. "A&. "A). "A&. !A*. !A*. !A+. !A). !A*. "A,. "A,. "A,. "A". "A!. "A". "A&. "A%. "A%. "A". "A!. !A+. "A,. "A,%. !B)!% )(O:@; "A(. "A'. "A(. "A'. "A'. "A). %A%. %A). &A!. %A(. %A,. "A(. "A'. "A). "A'. "A&. "A". "A!. "A%. "A". "A%. "A". "A%. "A%. "A&(. !B))) &&,

P=0N683DQD3L %A(. 'A,. 'A,. 'A*. (A%. (A'. (A,. 'A&. &A*. 'A!. &A+. &A%. &A". &A,. &A,. %A). %A&. %A&. %A,. %A!. %A!. %A,. "A+. %A". %A)(. "B!+, (&*R:1:=:78: ,A). ,A). ,A). ,A). ,A). ,A). ,A(. ,A(. ,A). ,A'. ,A'. ,A'. ,A&. ,A&. ,A&. ,A&. ,A%. ,A&. ,A&. ,A&. ,A'. ,A'. ,A'. ,A(. ,A&). +,% %&(S:33D7T; !A%. !A(. !A'. !A%. !A(. !A". !A". !A!. !A%. !A&. !A&. !A&. !A". !A%. !A". !A". !A%. !A!. !A!. !A". !A". !A%. !A%. !A&. !A"%. "B!)* !S90--D7T %A+. &A'. %A). %A&. %A". %A". %A!. %A,. %A!. %A%. %A". %A". %A". "A*. "A+. "A+. "A). "A). "A). "A). "A*. %A!. %A(. %A'. "A+(. "B''( !+*

S08D#4 'A). 'A,. &A+. &A%. &A". &A,. &A&. 'A!. 'A%. 'A&. 'A". 'A,. &A). &A*. &A+. &A'. &A'. &A(. &A(. &A+. 'A". 'A&. 'A*. 'A). &A)). !B+," %&"S-0=3; ,A'. ,A%. ,A%. ,A". ,A%. ,A%. ,A". ,A%. ,A%. ,A%. ,A%. ,A&. ,A&. ,A(. ,A). ,A*. ,A+. ,A*. ,A(. ,A(. ,A). ,A*. ,A). ,A). ,A'(. ')! "!'

29:$:; ,A". ,A!. ,A". ,A%. ,A&. ,A&. ,A&. ,A". ,A". ,A". ,A!. ,A!. ,A!. ,A". ,A!. ,A!. ,A!. ,A". ,A!. ,A!. ,A". ,A!. ,A!. ,A!. ,A!&. "&+ "%!2004; !,A+. !"A". !&A(. !)A(. ",A%. "!A'. "!A&. !*A(. !&A). !,A&. *A&. (A*. (A!. 'A+. 'A+. 'A+. (A,. (A!. 'A*. (A,. (A%. (A*. )A&. +A!. )A*+. "B'!" !B(**2=#Q:4 !A&. !A(. "A!. "A". "A&. "A(. "A". !A+. "A,. "A!. "A,. !A*. !A+. !A+. !A+. !A*. "A,. !A+. "A". "A". !A+. !A). !A(. !A&. !A*(. !B)'" &,)

<7U70@7 &A). 'A%. 'A!. 'A,. 'A%. &A&. 'A,. 'A+. &A(. &A&. &A!. %A*. %A'. %A*. %A). %A). &A,. %A(. %A). %A). %A). %A+. &A!. &A'. %A**. "B"*& !B)+(

203#4/5#6789:;/-:=/H06= !,

%B(,&/

))B,'%/

'%B(%%/

&,B%%"/

%%B&%*/

%,B+&+/

%*B!(!/

'(B*+'/

*%B&**/

!,+B'',/

!")B,(+/

!&"B(&"/

!'*B*)(/

!(*B,*"/

!(+B,!*/

!)"B+%'/

!)%B+(%/

!)+B*,!/

!*&B,!"/

!)(B,',/

!(%B,*,/

!'%B*%'/

!&!B%,%/

!"%B(%+/

Figure 5. Hourly relative app usage by category in terms of launches. Each cell value refers to the percentage of app launches done by our userswithin each hour for each category. Colors are normalized by row, with green indicating each category’s maximum percentage of application time,and white indicating each category’s minimum. For example, games reach their peak in the evening (green) and trough in the morning (white).

!"

!#"

!##"

!$###"

!#$###"

!##$###"

!$###$###"

!#$###$###"

!" %" !!"

!%"

&!"

&%"

'!"

'%"

(")#"

!"#

$%&'(

)'*++"&&%,+%-'

.%,/01'()'2%-3(,'4!"#$%&'()'25%"%,67889':-%;'<==->'

Figure 6. Number of apps used in a session. We aggregated sessionslonger than 40 apps since the graph flattens out and scarcity increases.Maximum length is 237.

Probably the most revealing statistic in our analysis of appli-cation chains is that for nearly half of all chains (49.60%) thefirst application belongs to the category Communication (asFigure 8 shows). Digging deeper, we found that 15.7% of thechains within our sample were initiated with an SMS appli-cation (9.5% default sms app, 6.2% an app called HandcentSMS), 9.6% with the phone application, and 5.9% with thestandard mail application. Interestingly, a browser was onlyused first in 5.9% of the application chains.

Figure 9 shows the transition probabilities between appli-cation categories in an application chain. Accordingly, thediagonal of the figure indicates transitions from one app toanother in the same category. As such, the values along thediagonal are non-zero. This graph considers only those ses-sions where two or more apps have been used. For each app,it is very likely that the app used next is a communication

!"

!#"

!##"

!$###"

!#$###"

!##$###"

!$###$###"

!#$###$###"!" %" &" '" (" )" *" +" ," !#"

!!"

!%"

!&"

!'"

!"#

$%&'(

)'*++"&&%,+%-'

!"#$%&'()'.,/0"%'122-'/,'3%--/(,'

Figure 7. Occurrences of sessions according to number of unique appsused within a session.

!"#"

$!"$#"%!"%#"&!"&#"'!"'#"#!"

()**+,

-./0

),"

1))23"

45)6

375"

8).-/2"

()*-.3"

95):

+.0;-<=

"

+,>,)6

,"

8?)@

@-,A"

B/*73"

C76

3"

D+20*

7:-/"

15/;72"

87E,A3"

8@)5<3"

F-G73<=27"

H7G757,.7"

F-I5/5-73"J

"K7*

)"

L7/2<?"

M-,/,.7"

1?7*

73"

N,<75</-,*

7,<"

!"#$"%

&'(")

Figure 8. Categories of first used app within a session.

- Type of used apps changes during the course of the day- During day: primarily communication apps- During night: scope of apps more heterogenous

8

Support for App Launching

9

- Adaptive launcher menu- Support visual search for apps- Presenting 5 icons for next app

- Implements different models- Sequentially used apps- Prediction model- Locally most used apps- Most recently used apps- Most frequently used apps

- Application AppKicker- Extension as a widget - Deployed on app store- 53,000 installations

Will be presented at UbiComp 2013

Session „Systems“Wed 8:30-10:00

App Recommender System

10

- Implementation of a recommender system- Context-aware (location, time and previous app)- Based on traces of application usage (AppSensor)

- Application appazaar- Deployed on app store- 7,200 installations

- Testbed for different recommender engines

Figure 4. Examples of screens a user sees when traversing the stages of our testbed’s conversion funnel. This usage-

centric action sequence can be captured for evaluation of the di↵erent recommender engines.

a certain stage, e.g. the long-term usage metric is thenumber of apps that have been used in the long-term.Conversion rates are the quotients of two counters ofstage events, e.g. the ratio of the number of people whoviewed a recommended app to the number of people whoused it in the long term.

Recommender Engines under TestThe focus of this paper is on the AppFunnel as an eval-uation framework and not on investigating new enginesthemselves. Therefore we have used the recommenderengines that already have been developed and deployedwithin appazaar for testing our framework. As shown inTable 1, the engines under test can be classified accord-ing to the two dimensions of personalization and contextawareness. The personalized engines take informationabout specific users into account, i.e. their app usagehistories. The context-aware recommender engines gen-erate recommendations based on users’ current context,e.g. time, location, and previously used apps.

Non-personalized Personalized

Context-

less

– App popularity – Usage-based CF

Context-

aware

– App-aware filtering – Location-aware CF

– Time-aware CF

Table 1. Design space of tested recommender engines.

Within appazaar, users’ requests for app recommen-dations have been scheduled to the di↵erent recom-mender engines randomly. This allows for counter-balanced within-subject testing of the engines. All en-gines that are utilizing collaborative filtering are imple-mented based on the Apache Mahout framework.5

It is worth mentioning that not every recommender en-gine was able to produce results for every request. Thesystem su↵ers from the cold-start problem [19], in par-ticular for the context-aware engines. When no recom-mendation could be presented to the user respectively,no user interaction with the recommendation list waspossible, and as a result no AppFunnel -related data wascollected. However, to present apps to the user regard-less, the fallback strategy for all engines is to return arandom set of applications. Since the interaction with

5http://mahout.apache.org/

such random data does not contribute to the evaluationof the engines themselves, we do not take into accountthis data for the presented evaluation framework.

App Popularity

The first recommender engine implemented in appazaaris based on apps’ popularities measured by their usage.Since installations alone do not reveal much about thequality of an application6, this engine ranks applicationsaccording to their popularity based on their global usagein terms of total number of launches. This engine isneither personalized nor context-aware. Therefore, thisengine was able to return results for all issued requestsfor recommendations, since it did not require any specificadditional data.

Usage-based collaborative filtering

The second engine implements collaborative filtering. Itutilizes users’ app usage data as implicit feedback en-coded as binary values for user/item pairs: 1 meaning auser has used an app and 0 meaning a user has never usedthe app. This engine is personalized, but not context-aware. The core of this engine was implemented using auser-based collaborative filtering algorithm. Therefore,it su↵ers from the cold-start problem and cannot rec-ommend any applications to users that are new to thesystem, or to those who did not upload app usage data.7

App-aware filtering

This recommender engine is based on the idea that peo-ple’s usage sessions between screen-on and screen-o↵have a specific contextual scope. For instance, thereis an increased likelihood that people stay with gamesonce they have used a game, or with social apps oncethey have used a social app [6]. Also, for app usageprediction the preceding app is a strong predictor [22].Therefore, this app-aware engine recommends applica-tions that are similar to those that have been used re-cently within the same session. The app-aware filteringis a context-aware but non-personalized approach. Sincethis engine is based on the apps recently used by theuser, this engine has failed whenever the user asked forrecommendations without having used an app other thanappazaar previously in the same session.6Jakob Nielsen, http://goo.gl/KR09G7Users could opt out from uploading data for privacy reasons.

Findings

- Interruptions do not happen as often as expected- 8% of app use is interrupted by app switching - 3% of app use is interrupted by phone calls

- If interruptions happen, overhead may be exceedingly high

phone call app switch

Daily interruptions (% usage) 3.2 (2.2) 8.3 (5.3) per user

Regular app runtime (s) 24.8 (31.8) 18.9 (24.4)per app

Overhead duration (s) 43.2 (65.9) 34.4 (40.7)per app

mean (SD)

11

Re-Design of Phone UIs

Prototype ImplementationAndroid-based implementation of approaches b) to e)Available for study in the wild and testing:

Problem and IdeaMobile phones evolved form single-purpose devices to multi-purpose devicesThe design of phone call applications did not evolve accordinglyIncoming phone calls can interrupt concurrent application useWe revise the design of call applications to allow for higher degree of multitasking

Extending Phone Call Applicationsa) Current design: Full-screen modal dialogs providing only options to accept or decline callb) Postponing calls: Additional third option besides accept/decline to allow user to return to previous applicationc) Multiplexing: Allows user to keep attention in previous application while call is pendingd) Background noti!cations: Puts incoming call into background for user to pickup call at wille) Scheduling on app completion: Wait until task is done and display call when user leaves previous app

Revisiting Phone Call Applicationsfor Multipurpose Mobile Phones

CALLER NAME CALLER NAME

CALLER NAME

Discussion, Challenges and Future WorkA model for predicting overhead would allow to determine which option (b to e) to choose for handling callsWhen user is multitasking the caller needs to be kept in line, e.g. by signalling “user is currently writing a mail”Other modalities need to be taken into account (esp. vibration and ringtone) and aligned with visual noti!cation

a) Current design b) Postponing calls c) Multiplexing d) Background noti!cation

Interruptions do not happen as often as expected3% of app use is interrupted by phone calls (external)

8% of app use is interrupted by app switching (internal)

- Extending the design space for phone call UIs- New interaction design for phone call handling- Support for better multitasking with call notifications- Application CallHeads deployed on app store (30,000 users)

12

What‘s in the apps for context?

tourist using city guide shopper shopping list

ContextApp

Usage

Matthias Böhmermatthias.boehmer@dfki.dehttp://matthiasboehmer.de