Understanding and Supporting Mobile Application Usage
Upcoming SlideShare
Loading in...5
×
 

Understanding and Supporting Mobile Application Usage

on

  • 164 views

Abstract (Dissertation defense talk) ...

Abstract (Dissertation defense talk)

In recent years mobile phones have evolved significantly. While the very first cellular phones only provided functionality for conducting phone calls, smartphones nowadays provide a rich variety of functionalities. Additional hardware capabilities like new sensors (e.g. for location) and touch screens as new input devices gave rise to new use cases for mobile phones, such as navigation support, taking pictures or making payments. Mobile phones not only evolved with regard to technology, they also became ubiquitous and pervasive in people’s daily lives by becoming capable of supporting them in various tasks. Eventually, the advent of mobile application stores for the distribution of mobile software enabled the end-users themselves to functionally customize their mobile phones for their personal purposes and needs.

So far, little is known about how people make use of the large variety of applications that are available. Thus, little support exists for end-users to make effective and efficient use of their smartphones given the huge numbers of applications that are available. This dissertation is motivated by the evolution of mobile phones from mere communication devices to multi-functional tool sets, and the challenges that have arisen as a result. The goal of this thesis is to contribute systems that support the use of mobile applications and to ground these systems’ designs in an understanding of user behavior gained through empirical observations.

The contribution of this dissertation is twofold: First, this work aims to understand how people make use of, organize, discover and multitask between the various functionalities that are available for their smartphones. Findings are based on observations of user behavior by conducting studies in the wild. Second, this work aims to assist people in leveraging their smartphones and the functionality that is available in a more effective and efficient way. This results in tools and improved user interfaces for end-users. Given that the number of available applications for smartphones is rapidly increasing, it is crucial to understand how people make use of such applications to support smartphone use in everyday life with better designs for smartphone user interfaces.

Statistics

Views

Total Views
164
Views on SlideShare
90
Embed Views
74

Actions

Likes
1
Downloads
6
Comments
0

1 Embed 74

http://matthiasboehmer.de 74

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Understanding and Supporting Mobile Application Usage Understanding and Supporting Mobile Application Usage Presentation Transcript

  • 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
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • 1983
  • Evolution
  • 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 profiles was a very important feature of first 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 effective and efficient use of apps? 8 EngineeringTheory Methods Launching Housekeeping Discovering Multitasking
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • 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 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
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • 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 first page if usage-based - More folders on first page if relatedness-based 23 %ofparticipantsusingconcepts
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • ing Discovering Multitasking How can we support people discovering new applications?
  • - Finding good apps can become a difficult 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- 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 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. 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 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 different 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 different stages after recommendation (AppFunnel) Usage-centric Evaluation VIEW INSTALLATION DIRECT USAGE LONG-TERM USAGE RECOMMENDATION 30
  • Results of Case Study - Difference 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
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • 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 notifications 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 notifications - Application CallHeads deployed on app store (30,000 users) 38
  • Housekeeping Apps Launching Apps Introduction Multitasking between Apps Discovery of Apps Conclusion
  • 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 Launching Housekeeping Discovering Multitasking
  • 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 filtering 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