Understanding and Supporting Mobile Application Usage

Understanding and Supporting
Mobile Application Usage
Matthias Böhmer
Dissertation Defense Talk
September 6, 2013
Saarland University
Faculty of Natural Sciences and Technology I
Saarbrücken Graduate School of Computer Science

Housekeeping Apps
Launching Apps
Introduction
Multitasking between Apps
Discovery of Apps
Conclusion

Today - Hardware changed
- Connectivity improved
- Apps arose

Growth of Mobile Ecosystem
1.1.3 The Age of Application Stores 7
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
900,000
1,000,000
Jun-08
Nov-08
Apr-09
Sep-09
Feb-10
Jul-10
Dec-10
May-11
Oct-11
Mar-12
Aug-12
Jan-13
Apple AppStore
Google Play Market
Figure 1.3: Number of applications available per application stores between June 2008 to
June 2013.14
providers to develop, market and distribute their applications [7], and for end-users
such platforms provide a convenient way to access applications since the end-users
do not have to handle any technical details [124]. While the customization of a
phone’s look and feel and audio proﬁles was a very important feature of ﬁrst mo-
bile phones [109], being able to also customize phone’s functionality in terms of
applications also became increasingly important [17]. As such, the most important
Available Applications
- Number of available mobile apps is increasing
- Number of app downloads is growing rapidly
- Daily time spent with apps also increases
7

Research Question
How do people use apps on their smartphones,
and how can we design systems to support people
in making eﬀective and eﬃcient use of apps?
8
EngineeringTheory Methods
Launching Housekeeping Discovering Multitasking

How do people
utilize the apps they
have installed?

Related Work
Numberofusers
Number of apps
Verkasalo, 2009
Froehlich et al., 2007
Demumieux and Losquin, 2005
this work
StudyDuration
11
Do et al., 2011 Falaki et al., 2010
0
0
research
in
the large
4,000
22,000

App Lifecycle
being used
not being used
closeopen
install uninstall
update
12

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
14

During Course of a Day
- App usage correlates with circadian circle
- Type of apps used changes during the day
25,000
50,000
75,000
100,000
125,000
150,000
175,000
200,000
12am
2am
4am
6am
8am
10am
12pm
2pm
4pm
6pm
8pm
10pm
Applicationlaunches
15

Application Chains
!"#$%&"
'#()*%
'#((+,)*-.)#,
/,.&".-),(&,.
0),-,*&
1-(&%
2&-3.4
5)6"-")&%7879&(#
5):&%.;3&
<+3.)(&=)-
>&$%
?"#=+*.)@).;
A&:&"&,*&
B&..),C%
B4#DD),C
B#*)-3
BD#".%
E4&(&%
E##3%
E"-@&3
F,G,#$,
B-(D
!"#$%&" IJKL MJNL MMJOL PJPL PJML MJQL PJIL PJIL PJKL RJQL RRJOL MJOL PJNL RJSL MJNL RQJNL PJQL PJML OJRL IJIL NJRL KO
'#()*% NJQL UJKL MNJRL PJPL PJIL KJOL PJNL PJIL PJNL QJIL IJSL KJRL PJNL IJIL QJIL KJML PJNL PJKL OJKL IJSL QJPL MR
'#((+,)*-.)#, QJSL IJSL NQJQL PJPL PJIL RJQL PJRL PJRL PJIL RJML IJRL IJQL PJML RJPL RJSL KJOL PJKL PJRL QJPL RJKL MJIL KMK
/,.&".-),(&,. NJSL NJRL INJRL PJPL PJPL MJML PJNL PJPL PJNL QJNL PJNL IJOL PJPL MJML SJIL MJML MJML PJPL OJML QJNL RNJSL
0),-,*& RPJML MJSL MSJML PJPL RJOL IJUL PJIL PJML PJIL RJQL OJNL MJQL PJRL RJQL QJQL NJRL PJSL PJRL RPJNL RJUL MJRL R
1-(&% RRJOL QJUL MPJKL PJPL PJML RQJRL PJML PJKL PJSL RJPL IJRL KJIL PJSL RJQL NJQL KJPL PJOL PJRL OJML RJSL KJIL O
2&-3.4 MJOL KJOL MKJML PJPL PJML IJQL NJRL PJNL RJIL NJRL IJUL MJRL RJNL IJML NJPL KJUL PJOL PJPL RIJKL IJML MJUL R
5)6"-")&%7879&(# NJPL MJSL IMJML PJPL PJIL IJML PJML IJNL PJOL RJML RJSL MJIL PJML RNJIL RRJUL MJSL PJML PJRL RMJKL MJIL QJQL M
5):&%.;3& OJIL QJML RSJML PJPL PJRL KJPL PJQL PJNL MJPL PJUL IJML KJML PJSL IJML IOJSL MJRL PJIL PJKL RPJIL IJIL QJQL K
<+3.)(&=)- NJIL RPJQL MOJIL PJPL PJIL RJKL PJNL PJIL PJKL IJQL IJQL NJIL PJML IJPL RJOL KJKL PJML PJKL UJQL MJIL UJRL RI
>&$% MMJNL MJML MMJML PJPL PJQL RJNL PJIL PJRL PJIL RJKL MJUL IJUL PJKL RJKL MJPL MJSL PJKL PJPL NJQL RJPL IJKL IQ
?"#=+*.)@).; SJKL QJPL MOJQL PJPL PJKL IJNL PJKL PJIL PJNL IJOL IJOL SJIL RJRL MJOL KJOL QJRL PJNL PJML UJSL IJKL KJKL MR
A&:&"&,*& RMJRL KJQL MKJML PJPL PJIL SJQL PJNL PJML RJPL RJPL IJQL KJNL IJUL RJSL QJIL KJRL PJKL PJIL UJOL RJSL KJKL I
B&..),C% OJUL QJNL INJML PJRL PJIL RJOL PJKL QJIL PJSL IJPL IJNL NJUL PJQL PJPL QJNL KJSL PJNL PJQL RRJNL KJOL RRJRL RM
B4#DD),C OJQL SJOL IMJIL PJPL PJKL KJOL PJKL PJUL UJNL PJUL IJOL QJIL PJSL MJPL KJSL KJML PJQL PJQL RNJNL RJNL MJOL IR
B#*)-3 IKJRL MJPL MQJML PJPL PJML IJML PJIL PJIL PJML RJIL IJUL IJOL PJML RJQL IJSL RIJKL PJSL PJRL QJML RJIL MJML MQ
BD#".% SJKL KJML KMJML PJRL PJKL IJQL PJKL PJIL PJML RJML MJPL KJOL PJQL IJKL MJOL QJKL SJNL PJPL SJPL RJQL MJUL I
E4&(&% OJQL RPJIL MSJIL PJPL PJIL IJKL PJRL PJIL RJKL MJIL PJKL KJSL PJKL MJML NJQL MJNL PJRL RJIL OJNL MJML KJNL R
E##3% RRJPL QJRL MNJRL PJPL PJIL IJSL PJML PJKL PJNL IJRL IJKL KJIL PJNL IJRL QJQL KJRL PJKL PJIL RQJSL IJOL MJQL OO
E"-@&3 NJSL UJRL MNJIL PJRL PJIL IJML PJML PJQL PJSL RJUL RJNL NJSL PJKL QJPL IJUL KJKL PJML PJIL RPJIL NJNL MJNL RI
F,G,#$, RPJSL KJKL KPJOL PJRL PJIL IJRL PJIL PJML PJNL MJUL RJOL MJIL PJML MJUL IJUL KJSL PJML PJIL NJKL RJQL RRJNL KO
16probability of transitions

Support for App Launching
17
- Adaptive launcher menu
- Support visual search for apps
- Presenting 5 icons for next app
- Implements diﬀerent 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

g Housekeeping Discovering Multitasking
How do people
organize applications
on their phones?

- Barreau and Nardi, 1995; Ravasio et al., 2004
- Studies on file organization on stationary computers
- People dedicate screen areas to different purposes
- People cluster documents by their types
- Shipman et al., 1995
- People create implicit structures
when manipulating layouts
- Ziefle and Bay, 2004
- People built mental models of their phone menus
- Häkkilä and Chatfield, 2006
- Customization is a way of personalizing devices
- Stages: (1st) alter look-and-feel, (2nd) customize
functionality, (3rd) change complicated settings
Related Work
Ravasio et al. 2004
20
2.3.1 General Mobile Phone Use
participants were active users of mobile phones, and over
90% had had two or more phones in active use during the
last year. The respondents consisted of 42 males (70%) and
18 females (30%), and were predominately in their 20’s
(30%) and 30’s (55%). The time participants had used their
current (new) mobile phone was mostly between two weeks
and a month (43%), or from one to two months (45%). The
participants were predominately Finnish.
The study consisted of an online survey, which the
participants filled out anonymously. The survey consisted
both multiple-choice and free text questions. The following
mobile phone customisation items were investigated:
- Background image (wall paper)
- Ringing tone
- Message alert tone
- Screen saver
- UI Theme (UI skin)
- Audio profiles
- Specified a ringing tone for certain contacts
- Alarm clock tone
- Speech commands
- Adding photo to a phonebook contact
- Defining fast dial numbers
- Reorganising menu items
- Soft key shortcuts
- Active idle shortcuts
- Screen brightness
- Screen backlight off timer
- Automatic keylock
In addition, we also investigated the editing of access point
and email settings, although these are typically not
considered as personalisation items. Figure 1 illustrates
some of these personalisable elements of the Nokia Series
60 mobile phone.
Figure 1. Personalisation elements on the idle mode screen.
RESULTS
Intensity of Customisation
A primary motivation of this survey was to examine how
and when users personalise their mobile phones. We asked
(a) By Häkkilä and Chatfield [109]
3.1.1. Content
Users can pers
applications fro
users add capa
Some applicati
the user, but m
to personalise t
Table 1. Items
Personalisation it
Content
Installed apps
Interface
Moved apps o
Moved apps o
1st & subseque
Ringtones
Physical/appeara
iPhone case
Lockscreen im
Figure 1. iPhon
4
Figure 2.1: Personalization elements o
lated work.
Häkkilä & Chatfield, 2006

Quantitative data, e.g.
- number of apps
- number of folders
- number of icons on page
- x/y position of icons
Qualitative data
- participants‘ experience levels
- concepts of icon arrangement
- participants labeled with
concepts
„most used apps first
page, groups of apps 2nd
space, then games“
„most-used items should
be on the first page,
otherwise I try to group
items (e.g., news outlets
together)“
...
1
2
Screenshot Study
grounded theory
majority rule
template matching
- 132 participants
- 1,486 screenshots

Usage-based icon arrangement
Relatedness-based icon arrangement
Usability-based icon arrangement
Aesthetics-based icon arrangement
External concepts for icon arrangement
llll ll
llll
lll
ll
ll
ABC
123
...
=?
22
5 Concepts for Arranging Icons4.3.2 Results of Scree
(a) Usage-based
Figure 4.5: Example sc
their icons: (a) one part
on the first screen”; (b
[applications] by what
would “keep third row a
has created a checkerbo
alternates between blue
4.3.2 Results of Screenshot Study
(a) Usage-based (b) Relatedness-based
Figure 4.5: Example screenshots of participa
their icons: (a) one participant who reports to
on the first screen”; (b) a user with five fol
[applications] by what they do or what I us
would “keep third row available for easy swip
has created a checkerboard pattern: “most ico
alternates between blue and brown and I try to
4.3.2 Results of Screenshot Study
(a) Usage-based (b) Relatedness-based (c) Usability-based
Figure 4.5: Example screenshots of participants who used certain c
their icons: (a) one participant who reports to “put the most freque
on the first screen”; (b) a user with five folders on his first page
[applications] by what they do or what I use them for”; (c) a pa
would “keep third row available for easy swiping to the next page”
4.3.2 Results of Screenshot Study 117
(a) Usage-based (b) Relatedness-based (c) Usability-based (d) Aesthetic-based
Figure 4.5: Example screenshots of participants who used certain concepts for arranging
their icons: (a) one participant who reports to “put the most frequently used applications
on the first screen”; (b) a user with five folders on his first page who tries “to group

Occurrences of Concepts
(1) (2) (3) (4) (5)
(1) usage-based
(2) relatedness-based
(3) usability based
(4) aesthetic-based
(5) external concepts
62 % 28 % 6 % 2 % 4 %
28 % 60 % 6 % 3 % 3 %
6 % 6 % 9 % 2 % 0 %
2 % 3 % 2 % 5 % 0 %
4 % 3 % 0 % 0 % 9 %
- Usage-based and relatedness-based most used
- Participants applied hybrid concepts
- Concept impacts icon layout
- More apps on ﬁrst page if usage-based
- More folders on ﬁrst page if relatedness-based 23
%ofparticipantsusingconcepts

ing Discovering Multitasking
How can we support
people discovering
new applications?

- Finding good apps can become a diﬃcult task
- Recommender systems for discovery
- Mobile apps are a special type of items
- Context is important
- The location of the user
- The time of the day
- The previously used application
26
App Recommender

Related Work
27
- Woerndl et al., 2007
- Location-aware recommender system for apps
- Only based on installations as feedback
- Jannach and Hegelich, 2009
- Recommendation of mobile games
- Personalization increased number of views and sales
- AppAware by Girardello and Michahelles, 2010
- Tracking installations, updates, and removals of apps
- Recommending popular apps by aggregating events
- AppJoy by Yan and Chen, 2011
- Based on recency, frequency and usage times of apps
- No usage-centric evaluation method available
2.3 Related Work
dation technique. In addition, one can determine whether
or not personalized recommendations can raise additional
interest in certain items by measuring the number of item
views. This number might be particularly important in pay-
per-click advertisement scenarios. Finally, also “conversion
rates” that, e.g., measure how many site visitors are turned
into buyers, can serve as an indicator for the business value.
In this paper, we focus on the question, whether users
that receive personalized recommendations (a) view more
items, and (b) buy more items than those users that re-
ceive non-personalized or no recommendations. In our ex-
periments (see [3] for additional measurements and results)
also hypotheses regarding two di erent conversion rates were
tested. In short, these measurements show that in certain
navigational situations a slight increase with respect to con-
version rates can be observed (e.g., more visitors also ac-
tually purchased at least one item). Overall, however, rec-
ommender systems did not measurably help to turn more
visitors into buyers, most probably because the conversion
rates are already relatively high as we only consider frequent
users. Long-term e ects and“indirect revenues”as described
pAware shares online users' installations, updates and removals
Android applications. In this way a user becomes conscious of
at is hot on the Android application portal. To meet these
ditions, the AppAware system consists in a client-server
hitecture.
1 General Concept
e client component in this system is the Android mobile
lication, which represents AppAware's graphical user interface
UI) and allows following installations, updates and removals of
lications shared by other users. Most of the core
ctionalities are supported by the main screen (see Figure 2)
are accessible from the application's menu or by touching a
item. Each list item represents a single event with its details,
mely: the name of the application with its description, the type
event (installed, updated or removed), the user involved and
Android version together with the phone model. Moreover, to
inguish the type of event at a glance the application’s name is
ored in red in case of a removal, green for an installation and
e for an update.
52 2.3 Related Work
Figure 5. Step 2: list of recommended
applications
By selecting one application, the detailed
scription is shown (Fig. 6) and the user can either
tall or use the application, or select “Nicht wieder
pfehlen” (do not recommend anymore) to express
at she does not want to use this application. The user
n always click “Zurück” (back) to go back to the
evious screen.
Figure 6. Step 3: application details
The actions of the user are recorded to be used in
bsequent recommendations. If the user starts an
plication, this information is stored as a positive
ing for the CFAppRecommender. The ratings
clude available context information. At this time, we
cord the GPS coordinates when the application is
rted. Other than the option to express dislike (Fig. 6)
an application, we do not let users explicitly rate
plications, because this would presumably be too
(a) Woerndl et al. [262]Figure 1: Catalog navigation and categories
Method Description
CF-Item Item-to-item collaborative filtering [7].
Content-based A content-based method based on item
descriptions and the cosine similarity of
TF-IDF vectors.
Hybrid A switching hybrid of the first two
which used the content-based method
in cases where less than 8 item ratings
were available.
SlopeOne An item-based filtering technique de-
scribed in [4].
TopSeller Ordering based on sales rank.
TopRating Ordering based on average customer
rating.
Control Manually-edited lists (mostly based on
release date) as before the experiment;
no “My Recommendations” section.
Customers remained in their groups to which they were
randomly assigned throughout the experiment. Each group
comprised around 22,300 customers. Note that from all por-
tal visitors, only such customers were selected for the exper-
iment, for which all algorithms were able to provide rec-
ommendations. Thus, it was also ensured that only similar
customer groups (frequent users) were compared. The item
catalog consisted of about 1,000 games. Since the number
of explicit item ratings was particularly low (less than 2% of
the customers issued at least one rating), also implicit item
ratings were taken into account. On a rating scale from
2 to +2, an item view action was interpreted as a rating
of 0 (medium); an actual purchase corresponds to a rating
of 1 (good). Explicit customer ratings, finally, override the
implicit ones.
2. RESULTS ANALYSIS
In order to determine the “business value” of a recom-
mender system (as opposed to the system’s accuracy), di er-
ent measurements can be made. Obviously, one can measure
and compare the total number of sold items per recommen-
in [1] were also not in the focus of the current study, because
in our application domain items are only bought once.
In the following, we summarize a selected subset of im-
portant observations from our study in the context of the
following navigational situations; see [3] for more details.
My Recommendations:
Figure 2 shows on how many items a user clicked when
viewing the personalized “My Recommendations” list.1
We
can observe that all personalized methods (except Slope-
One) successfully stimulated users to view the details of the
proposed items, i.e., they have raised more interest in the
o ered items than a simple list of top-selling or top-rated
items did. The di erences between the following groups of
techniques are statistically significant (p < 0.01) when con-
sidering the absolute numbers: CF-Item/Hybrid – Content-
based – SlopeOne/TopRating/Topseller.
Figure 2: Average number of item detail views per
“My Recommendations” visits
With respect to downloads (Figure 3) things look dif-
ferent. Although the content-based method raised addi-
tional interest with respect to item views, this did not lead
to significantly more downloads compared with the non-
personalized methods. This indicates that users are gen-
erally interested in things they have bought before (e.g.,
sports games) as they view many of them. Once they have
seen di erent ones, they however download only one game
1
As mentioned above, the control group had no access to
the “My Recommendations” section.
(b) Jannach and Hegelich [132]
ss applications’ details from a personal computer. These
enable users to search for and download Android
ions on the web instead of doing it directly from a mobile
Good examples are AndroLib2
and AppBrain3
. The major
ce between the two is that AppBrain provides a user with
cations shopping cart that can be synced with the device
an Android client application. However, the idea is not
ve since it is trying to port the concept of Apple's iTunes
Android world. In fact, iTunes already allows its users to
and sync applications from their computer to an iPhone.
are does not aim at replacing the Android Market or
ng a proxy, it is rather a companion to plan users'
pity [5] in applications finding.
Appazaar and aTrackDog
ar [2] is a recommender system for mobile applications,
project of the Lab for Software Engineering at Münster
ity of Applied Sciences. Based on a user current and
al locations and applications usage, Appazaar recommends
ions that might be of interest for her. Therefore, Appazaar
different algorithms from the research field of context
ss to analyze all the input data and create profiles of
t situations. Another tool related to AppAware is called
Dog4
. It is a program for Android devices that makes sure a
s the latest version of every installed application by
g the release information from either the Android Market,
ers’ devices or the vendors' web site. Doing this manually
me, thus aTrackDog supports the user in this activity. Even
ata from users’ devices is used to generate a most popular
t that can be sorted by category, time, and price. Despite
are generates similar stats and providing apps
endations is an appealing feature, we focused towards
ys to explore mobile apps on an application portal (i.e.
e stream, proximity based) and we further underlined the
esence into these activities.
CONCEPT AND DESIGN
ection, we describe the system design, AppAware's most
features and their implementation in the user interface.
www.androlib.com
www.appbrain.com
atrackdog.a0soft.com
list item. Each list item represents a single event with its details,
namely: the name of the application with its description, the type
of event (installed, updated or removed), the user involved and
the Android version together with the phone model. Moreover, to
distinguish the type of event at a glance the application’s name is
colored in red in case of a removal, green for an installation and
blue for an update.
Figure 2. Real-time stream of installed, updated and removed
applications (a) and analogous events in user’s proximity (b).
The server component is a web application accessible though a
standard browser and at the same time integrated in the mobile
client through an Android WebView element that displays web
pages. The client connects to the server through a RESTful
interface that accepts and then stores events from users. Among
the required parameters we have: the user ID, the application
package name (used by the Android Market as unique identifier
for an app), event type (installed, updated or removed) and the
location (latitude and longitude, whenever allowed by the user).
The server offers its data through an RSS feed that the AppAware
client uses as data source for its core functionalities as described
in Sections 3.2 and 3.3. This design decision allows at the same
time any standard feed reader to keep track of installations,
updates and removals of Android apps.
Along with this architecture, AppAware integrates with Twitter
too. This allows a user to share applications' installations,
removals and updates on the Twitter account, thus letting her
followers to see what applications are being installed by that user.
An example of a Twitter status update is: “Just updated Google
Translate http://appaware.org/1z on my #Nexus One - via
#AppAware”. This tweet tells that the application “Google
Translate” has been just updated on the Android phone model
432
(c) AppAware [103]
Figure 2.5: Screenshots of systems recommending mobile software for download.
applications also became a recent research topic, especially in the field of context-
aware recommendation, since mobile application usage is context-dependent (as
we will discuss in Chapter 3). However, although the ecosystem of mobile appli-
cations is rapidly growing as discussed in Chapter 1, so far there is little research
on recommender systems for mobile applications.
Pioneering work before the application store era was done by Woerndl et al. [262]
and Jannach and Hegelich [132]. Woerndl et al. [262] present a recommender
system for mobile applications that exploits context information and is based on
capturing the installations of applications in relation to this context (basically lo-
cation), though installation times are irrelevant compared to measuring the actual
usage.19 Their recommender engine is based on a hybrid engine following a multi-
dimensional approach. Jannach and Hegelich [132] evaluate recommender engines
suggesting game applications for downloads on a mobile internet platform. They
found that the personalization of recommendations results in an increased number
of views and sales. They did not investigate contextual factors at that time.
Girardello et al. [103, 104] present AppAware: a recommender system that is based
2.3 Related Work
mended
the detailed
user can either
“Nicht wieder
ore) to express
ation. The user
go back to the
62]Figure 1: Catalog navigation and categories
Method Description
CF-Item Item-to-item collaborative filtering [7].
Content-based A content-based method based on item
descriptions and the cosine similarity of
TF-IDF vectors.
Hybrid A switching hybrid of the first two
which used the content-based method
in cases where less than 8 item ratings
were available.
SlopeOne An item-based filtering technique de-
scribed in [4].
TopSeller Ordering based on sales rank.
in [1] were also not in the focus of the current study, because
in our application domain items are only bought once.
In the following, we summarize a selected subset of im-
portant observations from our study in the context of the
following navigational situations; see [3] for more details.
My Recommendations:
Figure 2 shows on how many items a user clicked when
viewing the personalized “My Recommendations” list.1
We
can observe that all personalized methods (except Slope-
One) successfully stimulated users to view the details of the
proposed items, i.e., they have raised more interest in the
o ered items than a simple list of top-selling or top-rated
items did. The di erences between the following groups of
techniques are statistically significant (p < 0.01) when con-
sidering the absolute numbers: CF-Item/Hybrid – Content-
based – SlopeOne/TopRating/Topseller.
(b) Jannach and Hegelich [132]
g its implications for then
ection 5.
e state of the art and related
and indicate how AppAware
s Websites
portal can be accessed just
and, in a limited way, from
these design decisions by
s are launching new services
a personal computer. These
or and download Android
oing it directly from a mobile
b2
and AppBrain3
. The major
ppBrain provides a user with
an be synced with the device
on. However, the idea is not
he concept of Apple's iTunes
es already allows its users to
their computer to an iPhone.
ing the Android Market or
companion to plan users'
g.
ackDog
tem for mobile applications,
ware Engineering at Münster
ased on a user current and
usage, Appazaar recommends
for her. Therefore, Appazaar
he research field of context
data and create profiles of
lated to AppAware is called
oid devices that makes sure a
ery installed application by
m either the Android Market,
web site. Doing this manually
the user in this activity. Even
ed to generate a most popular
ory, time, and price. Despite
ats and providing apps
eature, we focused towards
AppAware shares online users' installations, updates and removals
of Android applications. In this way a user becomes conscious of
what is hot on the Android application portal. To meet these
conditions, the AppAware system consists in a client-server
architecture.
3.1 General Concept
The client component in this system is the Android mobile
application, which represents AppAware's graphical user interface
(GUI) and allows following installations, updates and removals of
applications shared by other users. Most of the core
functionalities are supported by the main screen (see Figure 2)
and are accessible from the application's menu or by touching a
list item. Each list item represents a single event with its details,
namely: the name of the application with its description, the type
of event (installed, updated or removed), the user involved and
the Android version together with the phone model. Moreover, to
distinguish the type of event at a glance the application’s name is
colored in red in case of a removal, green for an installation and
blue for an update.
Figure 2. Real-time stream of installed, updated and removed
applications (a) and analogous events in user’s proximity (b).
The server component is a web application accessible though a
standard browser and at the same time integrated in the mobile
client through an Android WebView element that displays web
pages. The client connects to the server through a RESTful
interface that accepts and then stores events from users. Among
the required parameters we have: the user ID, the application
package name (used by the Android Market as unique identifier
for an app), event type (installed, updated or removed) and the
(c) AppAware [103]
ots of systems recommending mobile software for download.
me a recent research topic, especially in the field of context-
n, since mobile application usage is context-dependent (as
pter 3). However, although the ecosystem of mobile appli-
ing as discussed in Chapter 1, so far there is little research
Woerndletal.,2007JannachandHegelich,2009AppAware,2010

Design Space
- Covers dimensions of recommender engines
- Users, items, context, relevance
- Implicit or explicit parameter capturing
- Propose possible signals for capturing
28

App Recommender System
29
- 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 diﬀerent recommender engines

- Novel method for evaluation of recommendations
- So far methods were based on installation counts
- Evaluate recommendation based on engagement
of user with applications
- Apps can reach diﬀerent stages after
recommendation (AppFunnel)
Usage-centric Evaluation
VIEW INSTALLATION DIRECT USAGE
LONG-TERM
USAGE
RECOMMENDATION
30

Results of Case Study
- Diﬀerence in performance of engines
- Context-less engines: more views
- Context-aware engines: better from installation to
direct use
31
Averagenumberofoccurrences
perrecommendationlist
0.0
0.2
0.4
0.6
0.8
1.0
Location−aware
Collaborative
Filtering
App−popularity
Filtering
App−aware
Filtering
Usage−based
Collaborative
Filtering
Time−aware
Collaborative
Filtering
AppFunnel stage
view view market installation direct usage long−term usage
App-popularity
Usage-based CF
App-aware
Time-aware CF
Location-aware CF

ng Multitasking
What are the costs
of multitasking
between apps?

Related Work
- Jin and Dabbish, 2009
- Study of self-interruption on stationary computers
- Waiting for primary task is one reason to self-interrupt
- Salvucci, 2010
- Resumption is a reconstruction process rather than
memory-based, e.g. re-reading previously written text
- Oulasvirta et al., 2005
- Attention to mobile device is fragmented
- Mostly due to environmental distractions
- Fischer et al., 2010
- Study of opportune moments for interruptions on phones
- After episodes of device use reaction to notiﬁcations was
fastest
34
No text input was required. Altogether 25 tasks were cre-
ated, all in Finnish.
In a study like this, the route itself is an inherent part of
both stimulus materials and procedure. The route consisted
of several places in the Helsinki city center. Locations,
situations, transportation, and times are given in Figure 1.
Training and Procedure
Before the trials, the experimenter greeted the participant,
committed to paper background information about her/him,
and read aloud an overall description of the study (without
revealing its purpose). Next, participants were trained on
using the phone and browser. Training was incremental,
starting from simple tasks (e.g., opening the application
menu) and ending at two full tasks (e.g., looking from
whatis.com at what “ITV” means).
After the training, the trial started. The search task was read
aloud to the participant, with the associated bookmark num-
ber (e.g., “Choose bookmark number 4”). Some situations
involved doing “mobility tasks” related to that location si-
multaneously with the Web search task (see Figure 1, right
column); these were instructed when not implied by the
situation. Some tasks were done while moving (route was
provided if the participant did not know it) and others while
standing or sitting. When moving, the participant led the
way and the experimenter shadowed few steps behind with-
out disturbing or helping the participant. After accomplish-
ing the task, the participant’s answer was recorded by the
experimenter. New instructions were then provided.
Each task was performed in one of the Instructed Time
Pressure (ITP) conditions: (1) in the hurry condition, the
instruction was to “Do as many tasks as quickly as possi-
ble.” (2) In the baseline condition, it was to be done within
a given (4 minutes) or implicit timeframe (e.g., “You can
do the task until we arrive to the Sörnäinen metro stop”).
The timeframe was sufficient to perform the task, but if
exceeded, the experimenter stopped the task and instructed
the next task. (3) In the waiting condition, the participants
waited for something, and were told they had plenty of time
to carry out the one and only task: “We’ll be waiting for a
call from my colleague, you have plenty of time.”
den in a phone shell, captured the overall environment. This
video stream was sent wirelessly to a receiver in the partici-
pant’s backpack. Since we knew that wireless video is sus-
ceptible to distractions, we backed up this view onto a tape
carried by the experimenter. (See Figure 2.)
The participant carried most of the equipment in a back-
pack. It contained a microphone, a video camcorder, batter-
ies, a wireless link receiver, and a 4-channel quad processor
for building up one video from the four video streams. (See
Figure 3, Video Figure, and, for a system diagram, [29].)
Coding
The coders held a calibration meeting where they coded a
part of one tape together to agree on and elaborate the cod-
ing scheme. Several items were dropped and others simpli-
fied to reach a high level of consensus. The revised, final
Figure 2. Configuration of recording equipment.
Figure 3. Output video data integrated on-the-fly.
CHI 2005 PAPERS: Interruptions and Attention 2: Attending to Interruptions April 2–7 Portland, Oregon, USA
Oulasvirta et al., 2005

app use ...... app use cont‘dinterruption
time
...app use...
time
- Study based on data set of mobile app usage
- Mining for interruptions within data set
- Another application (self interruption)
- Incoming phone call (external interruption)
- Duration of overhead
Detecting Interruptions
3541
overhead
app use app use cont‘d
app use
time

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)
36

No Evolution of Phone UIs
37
- When phones became computers the design of
phone UI did not change accordingly
- Still only accept and decline button
- Call application has superior status

Re-Design of Phone UIs
plementation
ved form single-purpose devices to multi-purpose devices
call applications did not evolve accordingly
s can interrupt concurrent application use
of call applications to allow for higher degree of multitasking
one Call Applications
screen modal dialogs providing only options to accept or decline call
ditional third option besides accept/decline to allow user to return to previous application
user to keep attention in previous application while call is pending
tions: Puts incoming call into background for user to pickup call at will
ompletion: Wait until task is done and display call when user leaves previous app
CALLER NAME
CALLER NAME
b) Postponing calls c) Multiplexing d) Background notification
Interruptions do not happen as often as expected
- Extending the design space for phone call UIs
- New interaction design for phone call handling
- Support for better multitasking with call notiﬁcations
- Application CallHeads deployed on app store (30,000 users)
38

40
Summary of ContributionsSummary of Contributions
- AppSensor (tracing of mobile application usage)
- Understanding mobile application launching
- AppKicker (adaptive menu for supporting app launching)
- AppFunnel (method for usage-centric evaluation)
- Design space for mobile app recommender systems
- Reference architecture and implementation of appazaar
Launching
Housekeeping
Discovering
Multitasking
- Understanding people‘s concepts of icon arranging
- System to support icon arrangement
- Understanding the costs of mobile app multitasking
- Phone call UI for lowering the impact of call interruptions

41
Discussion and OutlookOutlook

Future Work
- Understand usage of AppKicker and CallHeads
- Build formal models to describe user behavior
42
Engineering
Theory
Methods
- Enhance quantitative large-scale research
with qualitative methods
- Build supportive systems for
new generations of devices

Thank you!
Publications
-Böhmer, Krüger: A study on icon arrangement by smartphone users. In Proc. of CHI 2013
-Böhmer, Hecht, Schöning, Krüger, Bauer: Falling asleep with Angry Birds, Facebook and
Kindle: a large scale study on mobile application usage. In Proc. of MobileHCI 2011
-Böhmer, Ganev, Krüger: AppFunnel: A framework for usage-centric evaluation of
recommender systems that suggest mobile applications. In Proc. of IUI 2013
-Parate, Böhmer, Chu, Ganesan, Marlin: Practical prediction, prefetch, and prelaunch
for faster access to applications on mobile phones. In Proc. of UbiComp 2013
-Böhmer, Bauer: Exploiting the icon arrangement on mobile devices as
information source for context-awareness. In Proc. of MobileHCI 2010
-Leiva, Böhmer, Gehring, Krüger: Back to the app: the costs of
mobile application interruptions. In Proc. of MobileHCI 2012
-Böhmer, Bauer: Improving the recommendation of mobile services by
interpreting the user’s icon arrangement. In Proc. of MobileHCI 2009
-Böhmer, Prinz, Bauer: Contextualizing Mobile Applications for Context-
aware Recommendation. In Adjunct Proceedings of Pervasive 2010
-Böhmer, Gehring, Hempel, Krüger: Revisiting Phone Call UIs for
Multipurpose Mobile Phones. In Proc. of MobileHCI 2013
-Karatzoglou, Baltrunas, Church, Böhmer: Climbing the app wall: Enabling mobile app
discovery through context-aware recommendations. In Proc. of CIKM 2012
-Böhmer, Bauer: The case for Context-Collaborative ﬁltering in
pervasive services environments. In Proc. of CAM3SN 2009
-Böhmer, Bauer, Krüger. Exploring the design space of recommender systems
that suggest mobile apps. In Proc. of CARS 2010
-Böhmer, Lander, Krüger. What’s in the apps for context? Extending a sensor
for studying app usage to informing context-awareness. In Proc. of UbiMI 2013

Understanding and Supporting Mobile Application Usage

Recommended

Recommended

More Related Content

Similar to Understanding and Supporting Mobile Application Usage

Similar to Understanding and Supporting Mobile Application Usage (20)

More from Matthias Böhmer

More from Matthias Böhmer (7)

Recently uploaded

Recently uploaded (20)

Understanding and Supporting Mobile Application Usage