Henning Heitk¨otter, Tim A. Majchrzak, Benjamin Ruland and Till Weber
Department of Information Systems, University of M¨unster, M¨unster, Germany [email protected], [email protected], {benjamin.ruland, tillweber1986}@gmail.com
Keywords: App, Mobile Web App, Framework, Cross-platform, Comparison, Evaluation, User Interface.
Abstract: Mobile Web apps are an alternative to native apps when developing mobile applications for more than one platform. They can be accessed from almost any current smartphone and tablet using a browser. However, de-veloping a Web app adapted to the particularities of mobile devices such as limited screen size and touch-based interaction requires consideration and effort. Several frameworks with different strengths and weaknesses sup-port creating mobile Web apps. In this paper, we develop a set of criteria to be met by mobile Web frameworks of high quality. Based on these criteria, we evaluate jQuery Mobile, Sencha Touch, The-M-Project, and Google Web Toolkit combined with mgwt, thereby assessing their suitability for certain situations. We find Sencha Touch suited for mobile Web apps of moderate and increased complexity, while jQuery Mobile is a good starting point for apps primarily concerned with a mobile user interface.
1 INTRODUCTION
Mobile devices such as smartphones and tablets are still gaining popularity among consumers and enter-prises (Gartner, 2012). In some areas they are already replacing – rather than just complementing – PCs and laptops. For software developers, mobile devices are a blessing and a curse at the same time. Obviously, there is a demand for new apps, and the devices of-fer novel possibilities such as GPS positioning and – of course – truly mobile usage. At the same time, a variety of platforms such as Android or iOS (Lin and Ye, 2009), a variety of frameworks, and a lack of best practices make it cumbersome to implement them. If multiple platforms have to be supported, ef-fort increases almost linearly with the number of plat-forms. This leads to a need for cross-platform devel-opment.
In the last decade, companies have significantly invested in Web technology (Chatterjee et al., 2002; Basu et al., 2000). More and more, applications that do not require rich clients for profound reasons (e. g., integrated development environments or professional media editing tools) are provided as Web apps. Users merely require a Web browser to use them.
The ambition to support multiple platforms and existing knowledge of Web technologies make Web apps an interesting choice for app development. In general, they promise to offer almost as good plat-form support as native apps. The latter are developed
using a platform’s source development kit (SDK) and should be employed if truly native performance and look & feel are desirable. Unfortunately, the require-ments for Web apps on mobile devices differ from Web apps in general. To effectively implement them or to make existing Web apps suitable for mobile de-vices, sophisticated framework support is advisable. An abundance of available frameworks hampers an easy selection, though. Moreover, there is hardly any guidance for informed decision-making.
To fill this gap, it is important to evaluate frame-works based on sound criteria. In this paper, we describe our criteria-based evaluation process, which can be sketched as follows: Based on typical require-ments of apps and on an extensive set of information resources, we derive eleven qualitative criteria. These criteria, accompanied by corresponding assessment guidelines, are then used to evaluate four frameworks. Background information and, more importantly, own experience are the foundation for judging to what de-gree a framework fulfills a certain criterion.
Our paper makes a number of contributions. First, we describe a novel set of evaluation criteria use-ful beyond their application in this paper. Second, we evaluate the frameworks in detail and give oper-ationalizable decision advice. Third, we contribute to the theory with a discussion of implications of our re-search. By outlining which approaches look promis-ing and where current frameworks lack features, we highlight areas for further research and development.
This paper is structured as follows. Related work is studied in Section 2. Section 3 introduces the con-cept of mobile Web apps and presents the frameworks analyzed later, including their general characteristics. Our evaluation criteria are developed in Section 4 and then used in Section 5 to evaluate the frameworks. Section 6 discusses and summarizes the findings, be-fore we conclude in Section 7.
2 RELATED WORK
Our kind of research is literature-driven. There-fore, relevant citations are provided in the corre-sponding paragraphs throughout this paper. In this section, we distinguish our work from existing ap-proaches. The main observation is that there are no all-encompassing reviews based on scientific criteria. Rather, many papers evaluate single frameworks in isolation or a combination thereof. This most likely is owed to the novelty of the field of research. Nev-ertheless, these papers have made valuable contribu-tions and in parts have been influential for our work.
Several papers evaluate technologies for Web apps such as HTML5 (HTML5, 2012). With additions like offline support, HTML5 is particularly suited for mo-bile Web apps. This is also reflected in recently pub-lished textbooks (e. g., (Oehlman and Blanc, 2011)). Assessment of HTML5 is positive (Harjono et al., 2010; Melamed and Clayton, 2009). Obviously, it is mature enough for widespread usage (Lubbers et al., 2011). Typically, HTML5 and JavaScript are utilized together (Meyer, 2011).
Frameworks are often evaluated in the context of app development. For example, in a comparison of Web apps and native apps it makes sense to mention jQuery mobile (Charland and Leroux, 2011). This does not help to compare jQuery mobile to compet-ing approaches, though. The same applies to work on HTML5 that includes framework recommenda-tions (e. g., (Curran et al., 2012)). The paper by Smutny goes a step further and briefly compares sev-eral frameworks (Smutny, 2012). However, he does not propose a catalogue of criteria for doing so.
Another thread of research is scenario-based eval-uation of existing technologies. For example, Zibula and Majchrzak (2012) use HTML5, jQuery Mobile, and PhoneGap to build an app for smart metering. However, while such papers help to understand the feasibility of possible technology stacks, they do not provide a greater image such as our work.
Our previous paper on evaluating cross-platform development approaches in general (Heitk¨otter et al., 2012) presents complementary work. It thereby helps
to make a decision on a higher-level: Web app or not. The research design is similar to this article, while the outcome is of course different. Ohrt and Turau (2012) present a broad comparison of cross-platform development tools, but do not consider mobile Web apps.
3 MOBILE WEB APPS
This section examines mobile Web apps as a cross-platform approach to app development and introduces four frameworks that will be analyzed later.
3.1 General
A Web application, short Web app, is a Web site that provides an application within browsers, as op-posed to static content (Connors and Sullivan, 2010, Sect. 1.3.2). It is built with Web technologies such as HTML5, CSS, and JavaScript to enable a dynamic ex-perience. A mobile Web app is intended to be used on mobile devices. It may be a mobile-optimized version of an existing Web app. In contrast to standard mo-bile apps, momo-bile Web apps are not installed on the device (e. g., via an app store) but accessed through the browser. Although built with the same set of tech-nologies, special requirements due to the mobile en-vironment call for a different approach and specific optimizations.
Mobile-specific requirements mainly stem from limited screen size available on mobile devices, a dif-ferent style of user interaction through touch gestures, and the mobile context. The smaller screen of smart-phones and, to a lesser extent, of tablets requires a different user interface (UI) layout and mobile ver-sions of typical HTML elements. For example, a multi-column layout is usually not feasible in mo-bile Web apps; instead, fixed toolbars for header or footer can provide universal navigation. Users act with their devices primarily through touch inter-action, which replaces the traditional pointer-based interaction combined with keyboard input. This re-quires several adaptations. UI elements have to be of sufficient size if users shall select them. Mobile Web apps should not expect the user to enter a large amount of text. They should, however, support ges-tures as an additional means of interaction. The mo-bile context includes more particularities that have to be accounted for such as limited hardware resources and instable or slow network connections. Hence, mobile Web apps should optimize network requests.
Combined with nearly 100 best practices recom-mended by the World Wide Web Consortium (W3C)
for developing mobile Web pages (Connors and Sul-livan, 2010; Rabin and McCathieNevile, 2008), the aforementioned requirements highlight the need for Web frameworks that support the development of mo-bile Web apps. Hence, there are various suchlike frameworks. In order to select promising frameworks for evaluation, we studied Web sites and literature dealing with mobile Web frameworks. jQuery Mo-bile and Sencha Touch were mentioned most often and will be analyzed in the following. Third-placed jQTouch bears close resemblance to jQuery Mobile and is not investigated further, because its evaluation would not provide additional insight. Several frame-works followed with significantly less mentions, of which we selected The-M-Project as a promising al-ternative. Google Web Toolkit combined with mgwt completes the set of candidates. As apps using GWT are programmed in Java, this combination represents a differing approach to mobile Web development.
As they run within a browser environment, mo-bile Web apps have some limitations, mostly regard-ing access to device-specific features and hardware. Depending on requirements, they are not always the optimal choice for cross-platform app development, as demonstrated by Heitk¨otter et al. (2012).. Several popular cross-platform development frameworks are based on Web technologies. They follow a so-called hybrid approach and package mobile Web apps with a runtime that gives access to device features. Such development projects often utilize mobile Web works as well. Hence, we analyzed in how far frame-works can be combined with PhoneGap (2013), also named Apache Cordova, a popular hybrid framework.
3.2 jQuery Mobile
jQuery Mobile (2013) makes the user interface of Web pages accessible on mobile devices. To develop an app with jQuery Mobile, developers merely need to use HTML5; at first glance, development is quite similar to Web development in general. By assign-ing specific attributes and values to HTML elements, they can be transformed into mobile-optimized UI el-ements or get a certain role, such as header or but-ton. Before the app is rendered in the client’s browser, jQuery Mobile enhances the HTML markup based on values of these attributes by adding additional markup and CSS classes. Besides UI components, jQuery Mobile provides animations and JavaScript support for touch events. It does not include an API for ad-vanced features such as data binding or internation-alization. It does, however, incorporate the popular JavaScript library jQuery (2012).
jQuery Mobile aims to deliver a uniform user
interface and high-class JavaScript to a wide range of mobile devices. All prevalent operating sys-tems, namely Android, iOS, BlackBerry OS, Win-dows Phone and Symbian, are supported. Mobile Web apps using jQuery Mobile can also be packaged with PhoneGap. The framework uses progressive en-hancement (Firtman, 2012), which adjusts the presen-tation according to supported features of displaying devices. It thus enables jQuery Mobile apps to run on nearly every smartphone browser.
Created in November 2010 by the jQuery Project (2012), jQuery Mobile is since maintained as open source under MIT license. Beneath the jQuery Project, it is supported by companies like Adobe, Mozilla Corporation, Palm, BlackBerry, and Nokia. It is part of a large ecosystem, which, besides others, includes a ThemeRoller for developing custom styles. Our review assesses version 1.2.
3.3 The-M-Project
The-M-Project (2013) provides a JavaScript frame-work for creating mobile Web apps with a Model-View-Controller (MVC) architecture. Apps are writ-ten entirely in JavaScript, without HTML or CSS. Not only data model and controller logic are imple-mented in JavaScript, but also the user interface. The JavaScript code of an application builds up the HTML at runtime in the client’s browser, resorting to jQuery Mobile for creating the UI. In addition to means for programmatic UI definition, The-M-Project’s API provides features such as data binding, event han-dling, AJAX requests, and internationalization.
It is licensed under MIT License and primarily de-veloped by Panacoda. The first version was released in 2011. Our evaluation examines version 1.2. Since mobile Web apps using The-M-Project only require HTML5, they are available for all platforms where jQuery Mobile is supported and can also be packaged with PhoneGap (“The-M-Docs. Native Packaging”, 2012). The-M-Project includes Espresso, a build tool simplifying the development lifecycle. It sets up the initial project structure and creates required compo-nents. Furthermore, Espresso supports optimizing, packaging, and deploying the mobile Web app.
3.4 Sencha Touch
Sencha Touch (2012) enables the structured develop-ment of mobile Web apps by only using JavaScript, similar to The-M-Project. Main elements of the framework are components: an extensive inheritance hierarchy of components contains all functionality. Hence, developing with Sencha Touch mostly
con-sists of instantiating and configuring these compo-nents. Since most components allow nesting other components or docking them to their sides, even com-plex structures can be realized. This procedure ap-plies to creating the user interface, where layouts de-termine how nested components are aligned, and to dynamic parts. A MVC architecture supports modu-larity and the utilization of dynamic data.
Sencha Touch was announced in June 2010 and is developed by Sencha Inc. We examine Version 2, re-leased in May 2012. It is compatible with Android, iOS, and BlackBerry, but provides no explicit sup-port for Windows Phone or Symbian. Packaging with PhoneGap is possible (Dougan, 2012). Sencha Cmd is a build tool for projects using Sencha Touch. It can be used to set up, build, and deploy a project.
3.5 Google Web Toolkit with mgwt
mgwt (2013) adds support for mobileWeb apps to the popular Google Web Toolkit (2012). GWT allows to develop complex Web apps in Java, which GWT then compiles to JavaScript that can be run in most modern browsers. GWT’s Java API abstracts from browser differences and low-level AJAX or DOM op-erations, aiming to increase productivity. In addi-tion to the extensive features of the Java program-ming language, it offers support for AJAX requests, management of browser history, and internationaliza-tion. Several libraries extend GWT with additional widgets and functionality. Since GWT lacks UI el-ements optimized for mobile devices, mgwt extends GWT with corresponding features, placing a strong focus on native look & feel and performance. To this end, mgwt provides developers with an additional, mobile-specific API for building up the user interface programmatically in Java, including animations.
GWT was released in 2006 and is developed by Google. Developed since 2011, mgwt mainly relies on a single developer. Both are licensed under Apache License 2.0. Versions examined are GWT 2.5.0 and mgwt 1.1.1. GWT supports most modern desktop browsers (GWT FAQ, 2012). mgwt focuses on mo-bile browsers based on WebKit, which are available for iOS, Android, and Blackberry. Native themes are provided for iOS and Android. Mobile Web apps can be packaged as PhoneGap applications with GWT-Phonegap (2013). For GWT, there are numerous tools helping developers in all phases of the development lifecycle, including plugins for the popular Eclipse IDE, debugging facilities, and a graphical UI builder. Setting up a project that uses mgwt is slightly more complicated. No UI builders for mgwt are available.
4 CRITERIA
Selecting a Web framework from a set of alterna-tives constitutes an optimization problem. A decision-maker has to select from a limited choice of alterna-tives, so that his utility or that of his company is max-imized. To deal with the complexity of measuring utility directly, most decision-making methods split up the utility-wise consequences of a selection into the consequences of disjoint criteria on utility (Tri-antaphyllou and Mann, 1989). The utility stemming from individual criteria can eventually be combined using an additive function (Fishburn, 1967) or com-plex functions such as the Analytic Hierarchy Pro-cess (Saaty, 1986). In any case, identifying sepa-rate criteria simplifies evaluation because each crite-rion can be examined on its own. Moreover, it im-proves decision-making because the decision process is dissected into manageable components. Decision-makers can weight criteria according to their needs. Combining all requirements of mobile Web frame-works into a single measure would prove rather dif-ficult and opaque. Hence, the first step of our evalua-tion consisted of developing a set of criteria.
In order to arrive at meaningful criteria, a goal hi-erarchy guided our criteria elicitation. The overall goal was to allow decision-makers to select the op-timal mobile Web framework depending on differing requirements. Two mostly separate sub-goals further define the quality of such a framework: first, func-tionality and usability of mobile apps created with the framework and second, the developer experience when developing mobile Web apps using the frame-work. The first focuses on the users’ perspective and their experience using an app, which literature con-siders an important factor of acceptance (Tarasewich, 2003; Gong and Tarasewich, 2004). The user per-spective is of course highly relevant for the developer as well, but only mediated through the requirement to build a user-friendly app. In contrast, the latter goal takes into account the developers’ perspective and other decision-relevant factors that foremost af-fect developers and the development costs of an app project. Based on these two goals we grouped the cri-teria into user and developer perspective.
Our process of deriving a set of criteria suitable for evaluating mobile Web frameworks included several sources of information. We set out with a review of existing articles and Web sites that give decision ad-vice for choosing frameworks related to Web or mo-bile development in general (Heitk¨otter et al., 2012; Olaru, 2007; Walsh, 2008; Lennon, 2010). Since those areas have some overlap with our topic, the comparisons provided some insights into typical
re-quirements of frameworks, which influenced our cri-teria. Special consideration was given to particular-ities and challenges due to the mobile environment and to Web-specific requirements, both already out-lined in Section 3.1. Our experience developing apps further contributed to the set of criteria, as well as ex-pectation formulated by partners from industry in in-terviews, ongoing discussions, and joint projects.
This process resulted in two kinds of criteria: bi-nary and qualitative. Bibi-nary criteria are concerned with questions whether a framework possesses a re-quired property and can be answered with yes or no. These include, for example, if a framework supports a certain mobile platform or its compatibility with PhoneGap. They have mostly been answered dur-ing the introduction of the frameworks in Section 3. Binary criteria restrict the set of suitable frameworks prior to an evaluation. Qualitative criteria deal with the quality of a framework with respect to its fulfill-ment of requirefulfill-ments. Typically, quality is graded on an ordinal scale. Qualitative criteria are less obvi-ous and can typically not be inferred reliably from descriptions of a framework. Instead, evaluating a framework with respect to these criteria requires in-tensive engagement with a framework. At the same time, they are highly decision-relevant. Hence, this paper focuses on qualitative criteria.
Tables 1 and 2 display our resulting set of qual-itative criteria, divided into developer and user per-spective. Each criterion has a name and is identified through a letter for the perspective and a running digit. A short description motivates each criterion and lists indicators, i. e., factors influencing its evaluation.
5 EVALUATION
In this section, we present the results of our evalua-tion. We assessed the four mobile Web frameworks according to the criteria outlined in Section 4. Re-sults are described separately for each framework in the following subsections. Beforehand, the next sub-section outlines our evaluation process. Table 3 gives an overview of all individual assessments in terms of grades, organized along frameworks and criteria.
5.1 Evaluation Process
Our evaluation of each framework consisted of two steps: collecting information about the framework in question and using it to develop prototypical apps. Publicly available information such as documenta-tion, community resources, and reviews was helpful
in gaining a first impression of the quality of a frame-work. Certain criteria, for example license and costs or long-term feasibility, can even solely or best be as-sessed through such information sources. For other criteria, the information represented a good starting point for the ensuing in-depth scrutiny through devel-opment experience. For example, typical problems as observable via community resources of a frame-work or feedback from our industry partners hinted at potential benefits and drawbacks. We developed mo-bile Web apps for managing contacts and schedules. These apps were intentionally prototypical. Their set of requirements had been compiled so that profound insight was gained while implementing them. Re-quirements included multiple screens with a native look & feel, advanced widgets and layout, local stor-age, and asynchronous loading.
Based on these experiences, two reviewers jointly assigned grades on a scale from 1, very good, to 6, very poor for each criterion. They complement the textual evaluation for a quick overview. As high-lighted in Section 4, each criterion is associated with a set of requirements and guidelines, which formed the basis of the assessment of each framework. This pro-cess ensured that evaluation was as objective as pos-sible given the qualitative nature of the task at hand.
5.2 jQuery Mobile
jQuery Mobile uses the MIT License, which sup-ports both open-source and closed-source projects. As no other costs accrue for support or development tools, License and Costs are suitable for any project (grade 1). In terms of Long-Term Feasibility, jQuery Mobile meets the demand of high popularity as it is frequently mentioned in reviews, literature, and gen-eral developer forums. jQuery Mobile cites sevgen-eral notable references such as Ikea or Disney World. As evident from the success of jQuery and thanks to sev-eral supporting firms, the development team promises a stable and steady further development. Further-more, short update cycles in recent times predict a positive update behavior in future, so that, overall, jQuery Mobile should remain viable long-term (1).
The documentation covers all available features in a concise but understandable way. While it does not showcase sample applications or tutorials, sev-eral textbooks, articles, and tutorials by third-party authors are referenced. Support is available from the highly frequented jQuery Mobile Forum (2013) with about 300 topics per month and from external support forums, in which jQuery Mobile seems to be a rel-evant topic (“Stack Overflow. Tag jQuery Mobile”, 2013). Thus, the criterion Documentation and
Sup-Table 1: Criteria of the developer’s perspective. D1License and Costs
Costs for obtaining a framework and employing it in commercial apps influence whether a framework is suitable for a certain app or a particular company. Hence, this criterion examines licensing costs that accrue for developing and publishing a commercial app based on the respective framework. Additionally, costs of support inquiries are considered (actual development costs are assessed by criterion D5). The optimal case would be an open-source framework under a permissive license such as MIT License (1988) or Apache License (2004). Copyleft licenses (Sen et al., 2011) such as GNU General Public License (2007) might complicate commercial, closed-source projects. This criterion is especially relevant for smaller projects and companies; it might also be relevant from a development perspective (Sen et al., 2008).
D2Long-term Feasibility
The decision for a framework represents a significant investment because specific know-how needs to be acquired and source code of apps will be tied to the framework. Hence, developers will prefer a framework that will most likely be available in the long term. A framework needs continuous updates, especially in view of rapidly changing browsers and Web technologies. Indicators of long-term feasibility are popularity, update behavior, and the development team. Popularity can be assessed through a high diffusion rate among app developers and recognition in the developer community, for example through reviews. A positive update behavior is marked by short update cycles and regular bug-fixes. A framework with a strong development team, ideally backed by several commercial supporters, is more likely to continue to exist in the future. D3Documentation and Support
Documentation and further support channels assist developers in learning and mastering a framework. As-sistance is not only required when starting to use a framework, but also to efficiently employ its API and advanced concepts. Therefore, a documentation of good quality provides tutorials and a comprehensive, well-structured reference. For popular frameworks, textbooks might provide a good starting point. Besides, other means of support such as community-driven forums or paid assistance help in case of special problems. D4Learning Success
Time and effort needed to comprehend a framework directly affect its suitability. While a good documentation (D3) may enhance learning success, learning inherently depends on the inner characteristics of a framework, i. e., its accessibility and comprehensibility. Hence, the learning success is examined separately. It mainly de-pends on the subjective progress of a developer during initial activities with a framework. Intuitive concepts, possibly bearing resemblance to already known paradigms, can be mastered quickly. To a minor extent, this criterion also considers the effort needed for learning new concepts after initial orientation.
D5Development Effort
The cost for developing apps mostly depends on the development effort needed, assuming a basic familiarity with the framework. While certain development phases such as requirements elicitation or design are largely independent of the framework used, it directly influences the implementation. Hence, the development effort is characterized by the time needed for implementing apps with the framework. Indicators for a framework that ease development are expressive power, an easy-to-understand syntax, reusability of code, and good tool support. The latter includes an Integrated Development Environment (IDE), which facilitates implementation and possibly GUI design, as well as debugging facilities.
D6Extensibility
In view of both evolving requirements and a changing environment, it may be necessary to extend a frame-work with additional functionality, either during initial implementation or in later iterations. This will be easier and more stable if a framework offers corresponding features such as a plug-in mechanism. As a last resort, app developers might adapt the source code of the framework itself, provided it is available. Besides considering the existence of extensibility measures, this criterion assesses their usefulness and accessibility. D7Maintainability
Web apps can and will be updated regularly. Therefore, their implementation must be maintainable over a longer period. This criterion is positively correlated with comprehensibility of the source code and its modularity. Both indicators depend on the framework used to implement the app. A framework that allows for concise but understandable code will improve comprehensibility. Modularity requires the possibility to separate different parts of an app into distinct units of code.
port is assessed as good (2).
Looking at the Learning Success, one can easily implement a simple application with jQuery Mobile, as only standard HTML and few custom, intuitive
at-tributes are needed. For developing a richer dynamic app, skills in JavaScript and jQuery are required in addition. As Web developers are likely to have such previous knowledge, a quick learning success can be
Table 2: Criteria of the user’s perspective. U1User Interface Elements
From an app user’s perspective, elements of the UI should be well-designed and optimized for mobile usage. Hence, a mobile Web app framework needs to provide high-quality elements for important tasks. On the one hand, this criterion assesses whether a framework offers mobile versions of common structural elements, i. e., widgets such as buttons or text fields and their layout in containers, as well as their quality. Structural elements need to address limited screen sizes and particularities of touch-based interaction. On the other hand, a framework should support behavioral UI elements such as animations and gestures.
U2Native Look & Feel
User acceptance of a Web app, also compared to a native app, often depends on a native look & feel. In contrast to a typical Web site, apps with a native UI have a platform-specific appearance and behavior. As this is an often mentioned requirement of apps, this criterion assesses whether a framework offers support for a native look & feel. Optimally, a framework would provide different, platform-specific themes, at least for Android and iOS. If that is the case, we examine how closely these resemble truly native UIs. Otherwise, the framework should provide means to efficiently style its UI elements and implement themes.
U3Load Time
The time required to load a Web app is important to users in view of slow and instable network connections on mobile devices. In contrast to native apps, Web apps moreover are not installed but retrieved upon access. Load times partly depend on the code size of the framework and on the typical verbosity of code using the framework. A framework might provide means to reduce initial load time such as support for asynchronous requests (AJAX) or storing application and user data locally on the device (via features of HTML5). U4Runtime Performance
The performance at runtime (after loading) informs the overall impression of an app. Since they run in a sandbox, Web apps might suffer from a comparatively low performance. Hence, the overall performance of a framework, as subjectively experienced by users, is important. The UI elements need to react quickly to user interactions and animations should be smooth for a high-quality user experience.
Table 3: Assessment summary.
jQuery The-M- Sencha GWT +
Symbol Criterion Mobile Project Touch mgwt
D1 License and Costs 1 1 2 1
D2 Long-term Feasibility 1 3 2 4
D3 Documentation and Support 2 2 1 3
D4 Learning Success 1 3 3 3
D5 Development Effort 4 3 2 2
D6 Extensibility 3 5 1 2
D7 Maintainability 4 2 1 2
U1 User Interface Elements 2 1 1 2
U2 Native Look & Feel 5 6 4 1
U3 Load Time 2 3 3 1
U4 Runtime Performance 3 3 2 1
achieved with minor effort. Further education mostly deals with jQuery core elements and might therefore also be achievable with little effort. All in all, learning and mastering jQuery Mobile is easy (1).
Developing static applications solely in HTML re-quired little time and effort. A simple syntax and easy debugging also speeds up development. Dy-namic applications, however, require pages to be al-tered prior to rendering, typically by the use of DOM manipulation. While this is no obstacle to small ap-plications, the Development Effort might increase for bigger projects. There are no special IDEs that sup-port development with jQuery Mobile. jQuery
Mo-bile does not provide APIs for advanced functional-ity such as data binding or internationalization and focuses on creating mobile user interfaces, so that it helps little when developing complex Web apps (4).
jQuery Mobile can be extended via plug-ins that either add custom methods to jQuery Mobile’s JavaScript API or provide additional widgets. jQuery Mobile reuses the plug-in mechanism of jQuery but does not state its corresponding API comprehensively. Only a medium number of extension is referenced on the project’s homepage. Hence, the framework’s Ex-tensibility is satisfactory (3). The source code of a Web app built with jQuery Mobile mainly consists of
HTML code, which tends to be comprehensive. As other parts of the source code are mainly written in JavaScript and no structural concepts are provided, the readability of these parts depends on the program-ming style of the developer. In terms of modular-ity, jQuery Mobile lacks support to separate different parts of an app into individual sections, so that, over-all, Maintainability is limited (4).
jQuery Mobile provides various User Interface Elements such as form elements, lists, tool bars, and grid layouts. Their quality is sufficient as they are adapted to small screen sizes and touch-based inter-action, but does not reach the quality of native UI el-ements. Page transitions can be enhanced by a set of animations and touch gestures can be detected by specific JavaScript-events. All in all, the support for mobile UIs is good (2). The creators of jQuery Mo-bile aim for a unified user interface. Therefore, the look & feel purposefully differs from the native ap-pearances of each platform and no platform-specific templates are provided. A custom adaption of native designs is possible, since the design is mainly influ-enced by CSS, but tends to be rather complex, even when assisted by the ThemeRoller. Hence, the crite-rion Native Look & Feel is not well-fulfilled (5).
The Load Time of a jQuery Mobile application as experienced by users is rather short. On the one hand, this effect is due to the small size of the framework, which is less than 100 KiB in its minified form. On the other hand, jQuery Mobile reduces the process-ing time of browsers, so that the Web app is displayed faster. Several techniques like AJAX or prefetching help to reduce interruptions during usage, while keep-ing the initial load time down. Storkeep-ing the whole application data on a mobile device is possible but not assisted. In summary, jQuery Mobile applica-tions load comparatively quickly (2). On high end de-vices such as Apple’s iPhone 4S or Samsung’s Galaxy S2, experienced runtime performance can hardly be distinguished from native apps, since animations run fluid and response to user interaction is almost im-mediate. Mid-end devices such as Samsung’s Galaxy Ace, show, however, performance issues, as scrolling occurs bumpy and animations are barely visible. On average, Runtime Performance is satisfactory (3).
5.3 The-M-Project
License and Costs of The-M-Project are favorable for all kinds of projects (1). Long-term Feasibility heav-ily depends on the major backer of the project, Pana-coda. New versions appeared in regular intervals over the last year (“The-M-Project. github repository”, 2013). The-M-Project’s popularity is difficult to
as-sess as the homepage presents no references. Its fo-rum (“The-M.Project. Google Groups”, 2013) shows steady, moderate interest (approximately 20 topics per month over the last half year), its repository is watched by more than 500 developers. All in all, The-M-Project’s long-term view is solid (3).
The-M-Project’s documentation provides tutorials as well as a reference of concepts and of the API. Overall, the documentation is well-structured and ex-tensive; at times, in-depth information is missing, e. g., on the class Model. Several sample apps accom-pany the documentation. Additional support is avail-able through the mentioned community forum, which usually provides timely answers. In summary, Docu-mentation and Support are good (2). When familiar-izing themselves with the framework, Web developers need to get used to programming only in JavaScript without HTML or CSS, and, hence, also learn The-M-Project’s API. The build tool Espresso helps with get-ting started, as does the documentation. Mastering the concepts needs detailed information, which the docu-mentation does not provide for all parts. The over-all Learning Success achieved with The-M-Project is slowed due to the extensive API knowledge required and the unusual approach to Web development (3).
The-M-Project advocates many structural require-ments on Web app projects, partly due to the MVC ar-chitecture. For smaller projects, this overhead might complicate development more than necessary, while The-M-Project’s advanced concepts help when imple-menting complex apps. In general, a large amount of boilerplate code is required, which partially can be generated by Espresso. Defining the UI program-matically in JavaScript is quite verbose and cum-bersome. On the other hand, advanced features of The-M-Project, such as content binding, free devel-opers from implementing complex logic manually. JavaScript in general and The-M-Project in particular lack sophisticated development environments that of-fer code completion and other helpful features. Since JavaScript gives developers great flexibility, a larger code base requires strict development guidelines to maintain structure. On average, Development Effort with The-M-Project is slightly increased (3), mainly due to the programmatic UI creation.
The-M-Project offers no means for extending the framework. The only way to adapt the framework is modifying the openly available source code. Hence, Extensibility is poor (5). Thanks to the well-defined architecture prescribed by The-M-Project, apps can be maintained quite well. They typically have a mod-ular design and separated concerns. The rather ver-bose source code might decrease comprehensibility, but overall, Maintainability is good (2).
As The-M-Project reuses jQuery Mobile for build-ing up the UI, most of the assessment of jQuery Mo-bile with respect to widgets, animations, and gestures applies here as well. The-M-Project provides addi-tional widgets not available in jQuery Mobile such as a date picker or a map view. Hence, the set of User Interface Elements is even better than jQuery Mobile’s (1). The-M-Project uses the default theme of jQuery Mobile and allows optional adaptation with CSS. Hence, a Native Look & Feel is not supported, either, and changing the style is less comfortable (6).
The complete The-M-Project framework is rather large with a size of close to 400 KiB (minified JavaScript, CSS, and images) because it bundles sev-eral libraries with its own source code. Apps built with The-M-Project tend to be comparatively large, in part owed to the boilerplate code required for model, view, and controller. At the same time, The-M-Project provides good support for minifying and making apps available offline via HTML5’s application cache, as Espresso generates required manifests automatically. This simplifies reducing the Load Time to acceptable levels (3). The Runtime Performance of apps is satis-factory and similar to jQuery Mobile (3); no obvious stuttering or lag is discernible.
5.4 Sencha Touch
Sencha Touch is licensed under either GPL or a free-of-charge commercial license that allows closed-source distribution. Enhanced support and a special-ized development tool can additionally be purchased at extra charge, so that the criterion License and Cost is well-fulfilled (2), although Sencha Touch is less open than the other frameworks. Long-term feasi-bility of Sencha Touch relies almost exclusively on Sencha Inc. Since the framework is a major product of Sencha and the company is not only dependent on supporters but also on own revenues, a suspension is unlikely. Sencha Touch has an equally high popular-ity as jQuery Mobile. Frequent and major updates in the past year point to a short update cycle. Summing up, Long-term Feasibility seems stable, but is heavily dependent on a single, albeit established company (2). The documentation extensively covers the API, with helpful, modifiable examples and good structure. In addition, one can access several tutorials and sam-ple apps. A support forum shows high activity (in the last year about 700 topics created per month). Be-sides, Sencha Touch offers a special support forum and telephone assistance with costs, so that the crite-rion Documentation and Support is covered well (1). When learning Sencha Touch, one has to deal with JavaScript and the framework’s API. Developers need
to familiarize themselves with the component struc-ture and the way in which components are instanti-ated and linked to each other. As this differs from common Web development approaches, initial learn-ing progress is quite slow. After belearn-ing familiar with the API, further learning is, however, easier, due to good documentation and well-structured components. Overall, Learning Success is satisfactory (3).
Sencha Touch requires a lot of effort for devel-oping small applications due to structural overhead by concepts like MVC. In contrast, larger applica-tions benefit from these concepts. Both MVC and the possibility to nest components simplify structur-ing an app. Additionally, an IDE is available with costs (Sencha Architect, 2013). It provides a WYSI-WYG UI editor, a code editor, and supplementing tools. Summarizing, the average Development Effort is low, mainly due to the structured approach (2).
In terms of Extensibility, developers can add cus-tom components that inherit from other components. Besides, Sencha Touch provides an interface for adding plug-ins to components that alter their func-tionality. Hence, the framework’s extensibility is very good (1). The expressive API, as evident for exam-ple in self-explanatory parameters, leads to compre-hensible source code. As separation of concerns and the allocation into various files facilitate modularity, Maintainability is, overall, very good (1).
The set of UI elements such as widgets, anima-tions, or gestures is wide and of high quality. It can be compared to that of The-M-Project. As nesting of elements is a basic concept of the framework, com-plex structures are realizable. Since Sencha Touch also provides support for gestures and animations, it fulfills the criterion User Interface Elements very well (1). The look & feel of a Sencha Touch app resembles that of iOS apps. Sass (Sass, 2013), an extension to CSS, can be used for customization. Though Sass al-lows powerful and easy design adjustment, a Native Look & Feel would require high effort (4).
Sencha Touch provides a tool to merge and min-imize source code and embed icons into CSS files. Thus, unused components are omitted and the num-ber of HTTP requests is reduced. Additionally, the framework uses an update process similar to that of a native app by storing data in HTML5’s application cache combined with versioning and incremental up-dates. However, an app can be as large as 800 KiB and, therefore, have a significant loading time. Sum-ming up, the experienced Load Time on first launch can be rather high, but caching may reduce that on further launches (3). Runtime performance of a Sen-cha Touch application is close to native performance, as no lag or stuttering is observable (2).
5.5 Google Web Toolkit with mgwt
GWT and mgwt are open source and free of charge, also for commercial projects. Extensive support is also freely available, at least for GWT, so that the cri-terion License and Costs is fulfilled well (1). Since development is mainly sponsored by Google, GWT depends on Google’s steady contribution to the frame-work. There have been some concerns about Google’s long-term strategy with respect to GWT (“Comments on Google Web Toolkit Steering”, 2012), but so far, it received continuous updates at least twice a year and its popularity, also within Google itself, should en-sure its viability for the near future. mgwt, however, relies on a single free-lance developer and has no ad-vanced project structure. So far, it has been updated regularly. Overall, Long-term Feasibility, especially of mgwt, has to be seen as uncertain (4).
While GWT’s documentation is comprehensive and easily comprehensible, mgwt lacks a thorough documentation. Information is scattered among var-ious resources, namely mgwt’s wiki, blog, API docu-mentation, and a showcase. mgwt lacks a tutorial that allows developers to learn how to develop with it. The Google Web Toolkit Community (2012) is large and offers support in a forum and on external sites. The community forum of mgwt (mgwt User Group, 2013) is also rather active, with approximately 70 topics per month over the last half year, and mgwt’s developer answers questions on a daily basis. The active sup-port partially offsets the mediocre documentation, so that Documentation and Support are satisfactory (3).
The initial steps with mgwt are rather hard, be-cause a newly created project already contains more than ten classes and still needs additional ones to work properly. In this situation, the lack of a complete tu-torial becomes especially noticeable. However, after mastering the initial hurdles, further familiarization is easy thanks to mgwt’s clear structure and its easy-to-understand API. Typical Web developers need to learn Java, while, of course, GWT provides an advantage for Java developers. In summary, Learning Success is hindered at first but fast later (3).
Developing Web apps, even complex ones, with GWT is comparatively easy. Programming in Java enables developers to use first-class development en-vironments such as Eclipse, which offer code com-pletion and compile-time type checking. Hence, tool support is considerably better than it is for JavaScript programming, partly due to Java’s static typing. Java’s object-oriented nature offers sophisti-cated means for structuring the source code of an ap-plication. GWT imposes no restrictions on the archi-tecture of applications, making it suitable for smaller
and larger projects alike. At the same time, the frame-work provides a large set of often-needed features such as AJAX handling and internationalization. The API of mgwt is also directly accessible. Hence, im-plementing the UI programmatically is not as cum-bersome as it is in other approaches. The develop-ment life cycle of GWT is slightly more complex, be-cause an additional compilation of Java to JavaScript takes place. However, Google offers free plug-ins for Eclipse that handle these steps. Furthermore, exten-sive debugging facilities are available. In contrast, setting up new mgwt projects is complicated and re-quires several shell commands. All in all, the Devel-opment Effort is acceptable for all kinds of projects (2), especially for developers with experience in Java. As the existence of mgwt itself demonstrates, GWT is extensible by everyone, mainly through object-oriented means. Google and third-parties pro-vide plug-ins for a wide range of functionality such as maps and geo-location. Extensibility is good, al-though there is no formalized plug-in mechanism (2). Java source code of GWT- and mgwt-based apps lends itself well to a modular organization with sepa-ration of concerns. Although some boilerplate code is necessary, overall Maintainability is good (2).
The user interface is primarily influenced by mgwt, which provides mobile-optimized widgets and behavioral elements. The set of widgets provided by mgwt is limited and smaller than that of jQuery Mo-bile: It includes only standard buttons, one default list widget, and fewer form elements, most with a default appearance only. There are no advanced widgets such as map views. The behavior of widgets is noticeably optimized for mobile usage, for example with pull-to-refresh functionality for lists. Additionally, typical animations for page transition are available. All in all, mgwt provides good functionality with respect to mo-bile User Interface Elements (2), since the limited set of widgets is well-optimized.
mgwt has a particular focus on native appearance of Web apps. Therefore, it supplies CSS themes for different mobile platforms and devices, including iPhone, iPad, Android, and Blackberry. The widgets adapt to the respective platform and mimic the ap-pearance of native UI elements as precise as possible. As developers may further change the appearance us-ing CSS, mgwt achieves a Native Look & Feel (1).
The compiler of GWT tries to reduce the number of files to download and their size by removing un-used code and optimizing the generated JavaScript. Hence, a mobile Web app with GWT and mgwt can be as small as 200 KiB. Additional support for HTML5’s application cache ensures a fast Load Time (1). In ad-dition to a native appearance, mgwt also tries to match
the feeling of native apps by focusing on a strong per-formance of the underlying JavaScript code. As a re-sult, the Runtime Performance of mgwt apps is very good and in most cases close to native apps (1).
6 DISCUSSION
This section summarizes the strengths and weak-nesses of each framework. We then analyze which framework tends to be best suited for typical scenar-ios. Eventually, we examine which promising ap-proaches and which pitfalls currently exist, also out-lining further need for research.
jQuery Mobile is a popular framework for build-ing mobile user interfaces. It is easily accessible thanks to its documentation and by being based on HTML markup. By focusing on mobile UI elements, it neglects advanced requirements such as data bind-ing or patterns for complex applications. Hence, smaller application with only little business logic can be created with ease, but larger applications do not benefit from jQuery Mobile. Integrating frameworks that provide such functionality is no simple task.
The-M-Project’s JavaScript API supports such ad-vanced requirements. Mobile Web apps are com-pletely implemented in JavaScript. jQuery Mobile is only used in the background to create the UI and is not apparent to developers. The-M-Project is better suited for advanced requirements and large apps, at the cost of being less accessible at first. Extending it, also with respect to a native look & feel, is difficult. Load and runtime performance are average at best.
Web apps built with Sencha Touch are also devel-oped solely in JavaScript. Its API is of a high quality, so that developers can learn and master the framework quickly. As the API is extensive and powerful, Sencha Touch is suitable for large and complex apps. These also benefit from good maintainability. For smaller apps with simple requirements, Sencha Touch’s over-head may reduce efficiency of development.
Google Web Toolkit takes a different approach to Web development, as apps are written in Java and compiled to JavaScript. mgwt extends GWT with mobile-optimized widgets. Developing with GWT is easy, also due to good development environments. From a user’s perspective, mgwt yields high-quality mobile Web apps with good performance and a native look & feel on Android and iOS. In contrast to GWT, mgwt’s documentation and accessibility is below av-erage. The long-term outlook is rather unstable.
These summaries already suggested some frame-works for certain requirements. The selection of a framework should be based on weighting the
crite-ria according to their importance in the respective app project. Afterwards, the frameworks can be ranked with respect to their suitability for the project at hand. Table 3 provides a good starting point for the selection process. In general, small projects with only limited user interaction and logic tend to be well-supported by jQuery Mobile. As UI design is based on HTML markup, jQuery Mobile is easily accessible to teams skilled in Web development. An app with a restricted feature set suffers less from the lack of advanced func-tionality in jQuery Mobile. Full-fledged mobile Web apps with complex user interaction and advanced re-quirements are a different scenario. They need sup-port for data binding, history management, modular-ity, and possibly internationalization. Sencha Touch is well-equipped for developing this kind of app.
If developers are used to Java, GWT might be a viable alternative, although it so far does not support mobile Web apps directly. mgwt adds this support, but is not as stable. If a look & feel is desired that to some extent resembles native apps, GWT and mgwt might also be suitable. However, in that case, a differ-ent approach to cross-platform mobile developmdiffer-ent than Web apps might be preferable. Which frame-work to choose also depends on the long-term impor-tance of mobile Web apps. For a one-time develop-ment project, the adjustdevelop-ment time needed for a more complex framework such as Sencha Touch might not pay off, so that jQuery Mobile is a natural choice. In case of ongoing mobile development, using the more extensive frameworks might pay off.
Our evaluation highlighted promising approaches but also several areas of potential improvement. Weaknesses outlined in the individual evaluation sec-tions are left up to the developers of each frame-work. Furthermore, we have identified several ar-eas where additional research and exploration seem worthwhile. The examined frameworks either con-centrate on building a mobile UI with HTML, not providing advanced functionality (jQuery Mobile), or implement UI and logic solely in JavaScript (The-M-Project, Sencha Touch). A combination of these approaches in the mobile context seems worthwhile, because it would allow developers to use well-tested technologies such as HTML and CSS to implement the UI, while resorting to JavaScript APIs for more complex logic. Such a combination would require means to connect mobile HTML components with corresponding JavaScript APIs, e. g., for data binding. A better combination of technologies for native development and for Web apps is desirable. How fu-ture technology could combine the strengths of to-day’s competing technologies is an open question. Research needs to deal not only with technology but
also with its application. To our knowledge, develop-ment best practices for mobile Web apps hardly ex-ist. Further research needs to examine whether exist-ing processes designed for Web development can be transferred and it should compile specific guidelines.
7 CONCLUSIONS
We presented an evaluation of frameworks for creat-ing mobile Web apps. Based on typical requirements of apps, we derived a set of criteria that can be used to evaluate (and design) these frameworks. The crite-ria were applied to evaluate jQuery Mobile, The-M-Project, Sencha Touch and Google Web Toolkit com-bined with mgwt. Sencha Touch is deemed suitable for complex apps, while jQuery Mobile is sufficient in case of smaller projects focused on UI aspects.
While we designed our approach to be as objec-tive as possible, some threats to validity remain: Each framework was evaluated by two of the authors as re-viewers. To nevertheless ensure a diversified knowl-edge base, each reviewer brought a different area of expertise to the evaluation. They were experienced with software development in general as well as web and mobile development in particular. However, de-velopers with yet another background might weigh the strengths and weaknesses of framework differ-ently. We incorporated feedback from industry part-ners and community sources to address this issue. Furthermore, we examined one specific version of each framework. Thus, as quality changes over time, the individual assessment might not stay accurate. For the near future, however, it should hold. The general statements as part of the assessment will likely be true for an even longer period.
To overcome the issues mentioned above and to expand our research, future work includes enlisting more experts with diverse backgrounds for review-ing the frameworks, updatreview-ing the evaluation to new versions, and addressing issues mentioned throughout the assessment and discussion. Moreover, we would like to give even more detailed decision advice.
REFERENCES
Apache License, Version 2.0. (2004). Retrieved Jan. 29, 2013, from http://www.apache.org/licenses/ LICENSE-2.0.html
Basu, C., Poindexter, S., Drosen, J., and Addo, T. (2000). Diffusion of executive information systems in orga-nizations and the shift to web technologies. Indust. Manag. & Data Syst., 100:271–276.
Charland, A. and Leroux, B. (2011). Mobile application development: web vs. native. Comm. ACM, 54(5):49– 53.
Chatterjee, D., Grewal, R., and Sambamurthy, V. (2002). Shaping up for e-commerce: institutional enablers of the organizational assimilation of web technologies. MIS Q., 26(2):65–89.
“Comments on Google Web Toolkit Steering” (2012). Retrieved Jan. 29, 2013, from https://groups. google.com/d/topic/gwt-steering/qO9MW9 lSL5Y Connors, A. and Sullivan, B. (2010). Mobile web
applica-tion best practices. Technical report, W3C. Retrieved from http://www.w3.org/TR/mwabp/
Curran, K., Bond, A., and Fisher, G. (2012). HTML5 and the mobile web. IJIDE, 3(2).
Dougan, R. (2012). “Packaging Sencha Touch 2 with PhoneGap”. Retrieved Jan. 29, 2013, from http:// robertdougan.com/posts/packaging-sencha-touch-2-with-phonegap-cordova
Firtman, M. (2012). jQuery Mobile: Up and Running. O’Reilly, Sebastopol.
Fishburn, P. C. (1967). Additive utilities with incomplete product sets: Application to priorities and assign-ments. Operations Research, 15(3):537–542. Gartner (2012). Gartner Press Release. Retrieved
Jan. 29, 2013, from http://www.gartner.com/it/ page.jsp?id=1924314
GNU General Public License (GPL). (2007). Retrieved Jan. 29, 2013, from http://www.gnu.org/licenses/ gpl-3.0.html
Gong, J. and Tarasewich, P. (2004). Guidelines for handheld mobile device interface design. In Proc. DSI 2004 Annual Meeting.
Google Web Toolkit. (2012). Retrieved Jan. 29, 2013, from https://developers.google.com/web-toolkit/
Google Web Toolkit Community. (2012). Retrieved Jan. 29, 2013, from https://developers.google.com/ web-toolkit/community
GWT-Phonegap. (2013). Retrieved Jan. 29, 2013, from http://code.google.com/p/gwt-phonegap/
GWT FAQ (2012). GWT FAQ. Get Started. Retrieved Jan. 29, 2013, from https://developers.google.com/ web-toolkit/doc/latest/FAQ GettingStarted
Harjono, J., Ng, G., Kong, D., and Lo, J. (2010). Build-ing smarter web applications with HTML5. In Proc. CASCON ’10.
Heitk¨otter, H., Hanschke, S., and Majchrzak, T. A. (2012). Comparing cross-platform development approaches for mobile applications. In Proc. 8th WEBIST. HTML5 (2012). HTML5. Retrieved Jan. 29, 2013, from
http://www.w3.org/TR/html5/
jQuery. (2012). Retrieved Jan. 29, 2013, from http:// jquery.com/
jQuery Mobile. (2013). Retrieved Jan. 29, 2013, from http:// jquerymobile.com/
jQuery Mobile Forum. (2013). Retrieved Jan. 29, 2013, from http://forum.jquery.com/jquery-mobile
jQuery Project. (2012). Retrieved Jan. 29, 2013, from http://jquery.org/about/
Lennon, J. (2010). Compare JavaScript frameworks. Re-trieved Jan. 29, 2013, from http://www.ibm.com/ developerworks/java/library/wa-jsframeworks/ Lin, F. and Ye, W. (2009). Operating system battle in the
ecosystem of smartphone industry. In Proc. 2009 Int. Symp. on IEEC.
Lubbers, P., Albers, B., and Salim, F. (2011). Pro HTML5 Programming. Apress, Berkeley.
“The-M-Docs. Native Packaging”. (2012). Retrieved Jan. 29, 2013, from http://panacodalabs.github.com/ The-M-Docs/#espresso/native packaging
Melamed, T. and Clayton, B. J. C. (2009). A Comparative Evaluation of HTML5 as a Pervasive Media Platform. In Proc. 1st Int. ICST Conf. MobiCASE.
Meyer, J. (2011). HTML5 and JavaScript Projects. Apress, Berkeley.
mgwt User Group (2013). mgwt User Group. Retrieved Jan. 29, 2013, from http://groups.google.com/group/mgwt mgwt. (2013). Retrieved Jan. 29, 2013, from http://
www.m-gwt.com/
The MIT License. (1988). Retrieved Jan. 29, 2013, from http://opensource.org/licenses/mit-license.php The-M-Project. (2013). Retrieved Jan. 29, 2013, from
http:// the-m-project.org/
“The-M-Project. github repository”. (2013). Retrieved Jan. 29, 2013, from https://github.com/mwaylabs/ The-M-Project
“The-M-Project. Google Groups”. (2013). Retrieved Jan. 29, 2013, from https://groups.google.com/ group/themproject
Oehlman, D. and Blanc, S. (2011). Pro Android Web Apps. Apress, Berkeley.
Ohrt, J., & Turau, V. (2012). Cross-platform development tools for smartphone applications. IEEE Computer, 45(9), 72–79.
Olaru, A. (2007). Selection Criteria for Javascript Frameworks. Retrieved Jan. 29, 2013, from http://www.infoq.com/ news/2007/12/choosing-javascript-frameworks
PhoneGap. (2013). Retrieved Jan. 29, 2013, from http:// phonegap.com/
Rabin, J. and McCathieNevile, C. (2008). Mobile web best practices 1.0. Technical report, W3C. Retrieved from http://www.w3.org/TR/mobile-bp/
Saaty, T. (1986). Axiomatic foundation of the analytic hier-archy process. Manag. Sci., 32(7):841–855.
Sass (2013). Sass. Sass. (2013). Retrieved Jan. 29, 2013, from http://sass-lang.com/
Sen, R., Subramaniam, C., and Nelson, M. L. (2008). Deter-minants of the choice of open source software license. J. Manag. Inf. Syst., 25(3):207–240.
Sen, R., Subramaniam, C., and Nelson, M. L. (2011). Open source software licenses: Strong-copyleft, non-copyleft, or somewhere in between? Decis. Support Syst., 52(1):199–206.
Sencha Architect (2013). Sencha Architect. Sencha Ar-chitect. (2013). Retrieved Jan. 29, 2013, from http:// www.sencha.com/products/architect/
Sencha Touch. (2012). Retrieved Jan. 29, 2013, from http://www.sencha.com/products/touch/
Smutny, P. (2012). Mobile development tools and cross-platform solutions. In Proc. 13th ICCC.
“Stack Overflow. Tag jQuery Mobile” (2013). “Stack Overflow. Tag jQuery Mobile”. Retrieved Jan. 29, 2013, from http://stackoverflow.com/questions/ tagged/jquery-mobile
Tarasewich, P. (2003). Designing mobile commerce appli-cations. Comm. ACM, 46(12):57–60.
Triantaphyllou, E. and Mann, S. H. (1989). An examination of the effectiveness of multi-dimensional decision-making methods: A decision-decision-making paradox. Decis. Support Syst., 5(3):303–312.
Walsh, D. (2008). 8 Considerations For Choosing Your Javascript Framework. Retrieved Jan. 29, 2013, from http://css.dzone.com/news/8-considerations-choosing-your
Zibula, A., & Majchrzak, T. A. (2012). Developing a cross-platform mobile smart meter application using HTML5, jQuery Mobile and PhoneGap. In Proc. 8th WEBIST.
