TABLE OF CONTENTS
LIST OF TABLES
LIST OF FIGURES
CHAPTER 1 INTRODUCTION AND STATEMENT OF THE PROBLEM
Significance of the Project
Statement of the Problem
Limitations of the Study
Definition of Terms
Advising S.O.S. Background
2 REVIEW OF RELATED LITERATURE
Mobile Development Strategies
HTML5 Web Applications
Hybrid Web Applications
Responsive Web Applications
Software & Hardware Details
User Interface Design
Marketing Campaign Results
Data Analysis Results
Security Scan Results
5 CONCLUSIONS AND RECOMMENDATIONS
APPENDIX A: Interview Transcript
APPENDIX B: Survey Instrument
APPENDIX C: Google Analytics Custom Dashboards
APPENDIX D: Security Scan Results
APPENDIX E: jQuery Mobile Device Support Matrix
APPENDIX F: Alpha Mobile Design
APPENDIX G: Advising S.O.S. Flyers
APPENDIX H: Pillar Banner Photo
APPENDIX I: Mobile Browser Detection & Redirection Script
LIST OF TABLES
1 Peak advising walk-in numbers pre & post launch
2 Native development languages for various mobile operating systems
3 Android versions and API Fragmentation
4 Google Analytics comparison, desktop vs. mobile
5 Cost estimates for outsourcing the mobile Advising S.O.S. development
LIST OF FIGURES
1 Advising S.O.S. traffic over time
2 Advising S.O.S. architecture.
3 Top eight U.S. mobile platforms from May 2012-2013
4 W. P. Carey mobile platform traffic from 2012-2013
5 HTML5 browser support over time
6 Original Advising S.O.S. desktop application interface
7 Redesigned Advising S.O.S. desktop application interface
8 Mobile Advising S.O.S. application interface
9 Touch friendly dialog box
10 HTML5 inline constraint validation
11 Mobile application icon
12 Survey respondent data
13 Survey respondent data
14 Mobile S.O.S. traffic vs. desktop S.O.S. traffic
15 Desktop vs. mobile traffic by mobile device visits
16 Operating systems by visits for mobile S.O.S
17 Goal completion vs. abandonment rate
18 Estimated cost savings calculations
20 HTML5 DNS prefetching call
21 Application manifest for mobile Advising S.O.S
22 Event listener and alert for connectivity state changes
23 YSlow performance of desktop Advising S.O.S. application
24 YSlow performance of mobile Advising S.O.S. application
25 Advising S.O.S. mobile Document Interactive Timing (DIT) distribution
26 Google global page speed comparison
Mobile devices are shaping the future of computing. Nearly 94% of Americans own a cell phone and 53% of those are smartphones (Nielson, 2013). For higher education, this means 50% of teenagers aged twelve to seventeen use their smart phones as their primary internet access device with traditional desktops trailing behind (Pew, 2013). College-age students expect mobile compatibility not only on websites, but web applications as well. Addressing the growing mobile demand requires study, strategy, and development. Mobile development is critical for institutes of higher education, but it is also fraught with complications, costs, and confusion. The mobile landscape is constantly shifting for developers and consumers; it is creating a need to carefully calculate and evolve solutions to improve software for mobile users.
Cisco has estimated by the end of 2013 there will be more mobile connected devices than people on earth--- over 7 billion. In 2012, mobile data traffic grew by 70% globally to 885 petabytes a month (Cisco, 2013). Mobile devices can take many forms, such as an iPhone, a tablet, or an E-reader with Wi-Fi. Essentially, it is a mobile computing device with a small screen ranging in size from two to ten inches. The devices’ input controls range from touch screens, hardware buttons, to mini keyboards. A web application that works well on a 17 inch monitor does not automatically work or work well on a mobile device. Higher education information technology (I.T.) departments will be challenged to support these new devices and development methods.
In 2008, the W. P. Carey School of Business created a web application called Advising Services Online System (S.O.S.) that all undergraduate business students use to progress through their undergraduate careers. This application allows students to complete over 20 individual advising processes online: such as booking appointments with their advisors to researching career information. It is imperative to create a mobile strategy that addresses the mobile users’ needs, due to the importance of this application and its popularity. The existing web application is not mobile-friendly or mobile optimized in any way. It has generated several error reports from students attempting to use it on mobile devices.
The research in this report will delve into this application and mobile development strategies to address these issues. This research is significant because it has real-world risks and benefits for the school. The research will be applied directly to creating a production application for fall 2013 to be used by over 9,645 undergraduate business students (Institutional Analysis, 2013).
Significance of the Project
In the past 12 months, over 8,682 visits to the application were from students trying to use mobile devices (Google Analytics, 2013). This represents 7.1% of the overall traffic for the application. While the growing need to address mobile users is apparent, there is intense debate on the varying development strategies. The shift in computer sales from traditional desktops to mobile devices is evident with incoming college students. Some students are buying only a tablet or mobile device and supplementing computer labs for traditional desktop computer usage. These students and their use cases should be addressed. Currently there is no “one size fits all” solution for addressing mobile users. With each strategy, there are varying costs, development time, and potential problems.
Questions needing further research are:
- What is an appropriate mobile strategy?
- What devices or platforms can and should be targeted?
- What is the cost of developing and supporting a mobile application?
- How can the impact be measured?
- How can a mobile application be launched that can be supported by an existing team not necessarily trained in mobile application development?
Business students are encouraged to use the Advising S.O.S. application, but it has only been supported and tested on desktop browsers. With no advertising or prompting, students are naturally trying to access the tool with their mobile devices. A study specific to the College of Business is needed to ascertain the optimal mobile strategy, due to the potential costs, risks, and benefits. A generalized approach will not adequately address the specific needs, use cases, and strategy for this application.
Statement of the Problem
The purpose of this research project was to find an effective way to create a mobile version of the Advising S.O.S. for both current and prospective students’ use. The research was applied to create a mobile version of the Advising S.O.S. application to be tested and launched in fall 2013 while addressing the following goals:
1. Investigate the differing mobile development strategies and their implications
2. Support various mobile devices, manufacturers, and browsers
3. Create a touch-friendly user interface, while retaining the value and functionality of the application and providing an engaging mobile experience that could be applied to other applications
4. Optimize the code base by the single lines of code (SLOC), and file size
5. Perform traffic analysis to compare trends before and after mobile launch
6. Include device detection to present mobile versus desktop operation.
Limitations of the Study
This study is specific to the W. P. Carey School of Business, the available I.T. resources, advising staff, students, and in particular the Advising S.O.S. application. The results of the study may not be directly applicable to other institutions, due to time, budget, and the specificity of the study. It should also be noted that the Advising S.O.S. application has no direct monetization model, and there is no intent to charge for it, so commercial applications and related research are not directly applicable. This study assumes there are limited I.T. resources, based on what is currently available. For this project, the back-end administration and reporting functionality available to advisors do not need to be available on mobile devices, so no effort will be expended on this. Finally, the current state of mobile technology is so cutting edge that changes to industry are happening as the research is taking place. Currently iOS 7, Apple’s mobile platform, is in development and is speculated to reveal a complete user interface redesign as well as new features. In addition, Google is currently preparing Android 4.3 for release on its mobile ecosystem. HTML5 is currently in Candidate Recommendation by the W3C and some features are still being actively updated.
Definition of Terms
In 1998 U.S. Congress amended the Rehabilitation Act with Section 508 to require Federal agencies to make their electronic information technology accessible to people with disabilities. This section requires disabled persons to have access to comparable information that is accessible to nondisabled.
Android is a Linux-based operating system designed for touchscreen mobile devices such as smartphones and tablet computers.
An application store is a type of digital distribution platform for application software.
The cache manifest is a new HTML5 software storage feature, which provides the ability to access web applications offline, without a network connection.
Code base or codebase is a term used in software development to contain the entire collection of source code used to build an application or component.
ColdFusion is a server-side commercial rapid web development application platform invented by JJ Allaire in 1995.
Cascading Style Sheets (CSS).
CSS is a style sheet language used for describing the look and formatting of a document written in a markup language, typically HTML.
Document Object Model (DOM).
The DOM is a cross-platform and language independent convention for representing and interacting with objects in HTML.
Application frameworks define underlying code structures used by software developers to implement the standard structure of an application.
Google Analytics (GA).
Google Analytics is a service offered by Google that generates detailed statistics about a website’s traffic sources.
HTML5 is the fifth revision of the HTML standard. It is currently at the W3C Candidate Recommendation status.
iOS is a mobile operating system developed by Apple Inc. Originally unveiled in 2007 for the iPhone it has extended to support many other Apple devices.
It is a web design approach with the goal of creating sites to provide a flexible and optimal viewing experience, with functional navigation, easy to read text, and minimal panning and zooming across a wide range of devices and screen sizes.
Source lines of code (SLOC) is a software metric used to measure the size of a computer program by counting the number of lines of text in the program's source code. It is usually used estimate the programming productivity, maintainability, and to predict effort required to create a program.
Software Development Kit (SDK).
A SDK is a set of software development tools that allow for the creation of applications for a specific software package, framework, platform, or operating system.
Source code is a collection of computer instructions written using a human-readable computer language, usually text.
Microsoft’s proprietary extension to Structured Query Language (SQL). T-SQL expands upon standard SQL to provide procedural programming, local variables, string processing, mathematics and more.
User Experience refers to a person’s perceptions or responses that result from the use of a product, system or service (ISO 9241-210).
User interface is the system by which people interact with a computer or device.
YSlow is a web browser extension that analyzes web pages, and why they are slow based on Yahoo!'s rules for high performance websites.
Advising S.O.S. Background
The Advising S.O.S. application is a web-based, self-service system for current and transfer undergraduate business students. It provides individualized answers to students’ questions and online submission of requests in lieu of an in-office visit. Students can access the system 24-hours-a-day, seven-days-a-week online. The students’ online requests are captured in a ticket system that has a back-end for advisors to log into and process the students’ requests. It keeps a dated history of all requests and their outcomes, in addition to notifying students electronically of the status of their requests. The software was initially developed with the following primary goals:
- To improve case management, documentation, and efficiency across four campuses
- To allow advisors to spend their time more effectively with students
- To increase the student's ability to self-serve
At the time of the application’s development, Arizona State University was the largest public university in the United States by student enrollment (Institutional Analysis, 2009). In the fall 2009 semester, there were 68,064 ASU students. Of those, 10,191 were business students, and there were an additional 287 nonbusiness students applying for admission to business programs. There were 27 W. P. Carey staff advisors who were available to meet with students for 30-minute appointments made in advance and during walk-in hours where no appointment is necessary. Prior to each semester, there is a hectic time for students and advisors. Academic advisors refer to this period as “peak advising”. Students need to schedule for classes, lift holds, and make sure they are on track. This is the time in August, October, January, and March when advisors switch to all walk-in hours instead of appointments to help as many students as possible. Prior to implementing the Advising S.O.S. wait times could be unusually long, and lines in the lobby would occur.
During the August 2008 peak advising period, advisors saw 1,283 walk-in students. In the next year after launching Advising SO.S., there were only 791 walk-ins, despite an increase in enrollment. This represents a 38.3% reduction in walk-in traffic. Table 1 depicts the decline in walk-ins for the year prior and after the launch of Advising S.O.S.
illustration not visible in this excerpt
As of 8/25/2013 there have been over 24,547 Advising S.O.S. cases processed, saving 12,273 hours of potential advising appointments. Initially, Advising S.O.S. was launched with just six modules. Modules are small free standing applications that walk a student through a particular process; for example, there is a “Change of Major” module that guides a student through all the steps they need to change their major. Today, Advising S.O.S has expanded to include 20 active modules. The Advising S.O.S. application has proven itself invaluable in meeting the advising demand of students, allowing self-service, and organizing the students’ needs. The initial version of the tool included reports for cases created and case history. In 2011, Google Analytics tracking was added to the application to allow more advanced data and metrics on the users and traffic patterns. Since 2011, there have been over 1.1 million page views in the Advising S.O.S. application (Google Analytics, 2013). The average time spent on a page is one minute and fifty-four seconds. Figure 1 graphs the student traffic over time from January 2012 to August 2013. The spikes in the traffic align with the peak advising periods of August, November, January, and March.
illustration not visible in this excerpt
Figure 1. Advising S.O.S. traffic over time 1/1/12 – 8/11/13.
The software was built with a modular design that allows new modules to be added or removed without affecting each other or adding complexity to the main code. This ability has enabled the software to scale with demand over time and minimize the complexity. Figure 2 illustrates the modular structure of the software.
illustration not visible in this excerpt
Figure 2. Advising S.O.S. architecture. This figure illustrates the modular nature of the software.
Application data is stored in two main databases. One contains application data called UPO with read and write access. The second database called EPM offers read only access to university biographical data. There are two main components “Advising.cfc” and “Appointment.cfc” which contain the business logic and data queries for the application. New modules can be added or removed from the modules folder at any time. The modules themselves are freestanding and access their data from the two main CFCs.
As with any software project, there are a set of requirements established by the client and developer to limit the scope of the project and ensure desired results. Research Objectives 2-6 set some general requirements for the project. Objective 2 requires that the new application work on multiple mobile devices of varying screen sizes and browsers. The mobile device market is always changing, so tailoring the application to a specific device would only address some of the students’ needs. The new Advising S.O.S. needs to be a flexible device agnostic solution. Objective 3 requires the application to use a touch interface, while retaining its valuable modular design and core features. A secondary goal of Objective 3 is that the user interface could be applied to other software.
The 4th Objective is to optimize the code base. Over time as patches, updates, and additional functionality are added to an application, the code base can grow large and need optimization. As a code base grows larger, so does the cost of developer support and testing. The 5th Research Objective is to monitor the traffic analysis and performance of the new application before and after launch, so that it can be measured and compared. This means an analytics solution will need to be in place to track this data. The 6th Research Objective addresses the need for the application to know if it is being used on a mobile device or not and have the ability to switch intelligently if needed.
As a public university, there are some additional requirements that all applications must meet. The Family Education Rights and Privacy Act (FERPA) is a Federal law that protects the privacy of students’ educational records. It applies to all colleges and universities that receive applicable funds from the U.S. Department of Education. Some of the data used by the Advising S.O.S. application is covered under FERPA, so it is vital the data, as well as access, be secure. The new application must also comply with the ASU Information Security Office web application security standards and will be subjected to security scans and audits according to ASU Secure Web Development Standard (ASU, 2013). Finally, maintenance is an essential aspect to the Advising S.O.S. application. At the end of each academic year, the Advising Tech Committee, made up of academic advisors meets to review the system and request necessary updates and possible new features for the next year. The changes are reviewed with the developers and then coded, tested, and moved live for fall semester. In addition, if fixes or updates are needed outside of this window, support tickets are created and processed based on severity.
The Advising S.O.S. application meets a specific need for the W. P. Carey School of Business, however the challenges faced with developing mobile software are not unique to higher education or businesses. The variability is in finding a way to satisfy mobile users with a solution that fits the budget, can be readily supported and updated, and meets the software requirements. In this study, current development strategies will be reviewed and applied to create a new application that addresses the research objectives and software requirements.
According to Cisco, mobile device traffic last year alone was twelve times greater than the entire global Internet traffic in 2000 (2013). The data is astonishing, but leaping into development strategies without planning leads to disaster. As McWherter and Gowell suggest “Sometimes, a bad mobile application or website can be worse than no mobile app or website” (2009). The head of Arizona State University’s mobile application development team described the state of mobile application development as:
Hysteria….because from my perspective, in talking to others in the university, everybody wants a mobile application, but no-one is thinking of mobile use-cases. As far as exactly what we need, or how we are planning to use the application, is this the best way to actually use it? (Cumaranantunge, 2013)
Refer to Appendix A for the entire interview with Chandima Cumaranantunge. The difficulty with mobile development is that it has challenges not found in other areas of software development (Wasserman, 2010). The vast multitude of operating systems, browsers, languages, and features, each with their own characteristics, presents an arduous challenge (McWherter & Goul, 2009). There are four generally accepted approaches to mobile application development in the industry today. This chapter will review these strategies and their merits.
Historically, when the original iPhone was announced and unveiled on June 11, 2007 Apple touted its Web 2.0 capabilities and support:
Developers can create Web 2.0 applications which look and behave just like the applications built into iPhone, and which can seamlessly access iPhone’s services, including making a phone call, sending an e-mail and displaying a location in Google Maps. Third-party applications created using Web 2.0 standards can extend iPhone’s capabilities without compromising its reliability or security. (Apple, 2007)
All of the original 3rd party applications for the iPhone were to be web applications (Charland and Leroux, 2011). It was not until a year later in 2008 that Apple announced “The App Store”, allowing native applications to be written with their SDK and submitted for publishing (Apple, 2008). That announcement triggered a change in momentum from web applications to native applications. Tech research company Gartner, however, is predicting that by 2016 over 50% of mobile applications will be hybrid (Gartner, 2012). David Mitchell predicted “While hybrid apps will be the majority of enterprise mobile apps, web technologies like HTML5 will make up the most commonly used languages for building mobile applications by 2015 (Gartner, 2012)”.
One challenge unique to mobile application development is the diversity of the mobile ecosystem (Wasserman, 2010). There are hundreds of different phones, tablets, and mobile devices in the market today. These all run on different platforms or operating systems and even differing versions of the same operating system. Mobile applications written for a specific OS version do not generally work on every version of that OS without changes made to the application code (Charland and Leroux, 2011).
In the market today, there are a plethora of mobile operating systems (OS) such as Chrome OS, Android, iOS, Blackberry 10, Symbian, Windows Phone, Windows RT, webOS, as well as some upcoming platforms including Firefox OS, Tizen, Ubuntu Touch, and Sailfish OS (NetMarketShare, 2013). Figure 3 helps illustrates the current market share of the top eight U.S. platforms. The top two platforms in the United States are the Android operating system from Google and iOS from Apple (StatsCounter, 2013).