Context Aware Mobile Commerce

1. Context AwareMobile Commerce For CSE 535 Mobile Computing Phase III Colin Juillard, Duo Li, Joseph Caglio, Sayan Cole

2. Road Map • Goal/Motivation • General approach • Accelerometer context collection and analysis. • Accessibility function implementation.

3. Goal & Motivation • Add context to Mobile Commerce, and provide a whole new approach to plan activities. • Late to meetings, appointments, reservations. • Plan ahead of time. • Take interruptions into consideration and provide automatic update to events. • Efficiency for both users and clients in terms of time and resources. • Easy to use and easy to adapt to. Application learns from user, unlike the other way around.

4. Location Aware Where the user is

5. Location awareness • Mobile phones have the necessary hardware to support context awareness. • Context awareness can be used to provide relevant information to a user based on his/her location. • GPS can be used but has limitations • Consumes a lot of power vis-à-vis Wi-Fi. • Does not work indoors.

6. Wi-Fi for context information • Wi-Fi hotspots becoming ubiquitous. • Hotspot broadcasts the SSID’s which give a hint as to the nature of service it provides. • Configure the Wi-Fi scanning process to search for specific SSID names. E.g. Starbucks if you want coffee

7. Challenges • SSID name might not be unique or provide good representation. • Use IP address matching, as IP address of router is unique. • Wi-Fi scans consume more energy than average power consumed by GPS . Hence determination of scan interval extremely important for energy efficiency. • Scan only when required. Use accelerometer readings to set scan interval. (based on user movement)

8. Wi-Fi vs. GPS power consumption • Used free software PowerTutor to measure energy consumption. • Using 10s scan interval, the power consumed by Wi-Fi for scan was 800 mW and average power consumption was 10 mW. (800*6 + 54*10 = 5.3 joules) • Using GPS, power consumed was 450 mW . (450 * 60 = 27 joules)

9. Accelerometer Detecting what user is doing

10. Why Accelerometer? • Measure and monitor user motion • Estimate time of arrival • Save energy • More activity – scan interval decreases • Less activity – scan interval increases • Provide interval decision for Wi-Fi scanning • Dynamic scanning provides accurate data while consume less energy

11. Data Collection • Using Android API to collect accelerometer accelerations. • Acceleration in terms of X, Y, Z acceleration, then take the difference in magnitude divide by time between each sample. • Find the “cutting value” to distinguish various activity by accumulating number of actions detected over the “cutting value”.

12. Data Analysis

14. Overall • Using difference in Magnitude of Acceleration over time, we’re able to find cutting values for determining user motion. • Drawback • Prediction is only as accurate as the sensor. • Takes 20 seconds to collect 40 samples. • Future Work • Varying “cutting value” to improve accuracy. • Using Bluetooth accelerometer with smartphone.

15. Accessibility Help user to do what they want to do

16. Accessibility • Goal: Make our application accessible to visually impaired users. • Features: • Text-to-Speech: Give directions and information to the user on how to interact with the application. • Advanced User Mode: Once users have learned the interface, many of the directions do not need to be given again. • Speech recognition: Get user input and commands.

17. Text-to-Speech • Requirements: • Android v1.6 (API Level 4) • TTS resources (must check to ensure language-specific resource files available) • Text-to-Speech usage • Install any required resource files • Initialize the engine • Convey instructions and information to the user by manipulating the TTS engine’s queue of commands • Add, Flush, Silence

18. Advanced User Mode • Goal: Make our application useable on the go, which means less distracting. • Visually impaired users sometimes learn programs offline before using them on the go • Once learned, there is no need to repeat instructions • Advanced user mode speaks only required information

19. Speech Recognition • Speech Recognition Usage • When button pressed (camera button used), start speech recognition activity. • Use results to change the state of the program. • Potential to speed up the process by creating shortcut commands • Problems Encountered • Slow to initialize the first time • Could not detect when the activity had started without being able to see it • Future Work • Use with newer phones. Android API Level 8 has new functions available for creating your own SpeechRecognizer instances.

20. User Modeling Predicting what the user is going to do

21. Different Ways of Doing It • Machine Learning • Complex (e.g. Gradient Decent requires differential) • Large Dataset (e.g. Netflix has millions of dataset • Simple Statistics • Simple (e.g. Average requires summation and division) • Can Have Small Dataset

22. Our Solution (Simple Statistic) • Histogram Based on Time • High Occurrence Can Easily Be Seen • Can Add Complexity

23. Implementation More details on how we implement it on our application

24. What We Did • Each Day is a Separate Histogram • Each Histogram is Divided into 5 Minute Increments • Each Time User Use Application, Mark it on Corresponding Day and Time • Look at Next Day Histogram at 8:00pm Each Day • Group Neighbors Together (can have 1 or 2 gaps) and Set Notifications

25. Results… TBA • Results for this requires extensive testing • Multiple Users is Needed to Get Accurate Measurements • Can Have Study of Different Users to See the Average Usage Base on Type of User

26. Questions?