Rich Internet Applications The Next Stage of Application Development

Transcription

1 Rich Internet Applications The Next Stage of Application Development Jason Farrell Grand Valley State University Allendale, MI, USA George S. Nezlek Associate Professor, Information Systems Grand Valley State University Allendale, MI, USA Abstract: Early Internet applications were written using a classic client/server model, with multiple content pages refreshed for each user action. As users continue to demand more sophisticated and increasingly interactive Internet programming, applications development is evolving to permit more efficient communication between clients and servers. Techniques such as Ajax are being used to promote this new style of Internet programming. Rich Internet Applications (RIA) offer greatly enhanced usability, and allow Internet programs to rival their desktop counterparts for functionality. This paper explores technologies deployed in creating RIA, and considers relative merits and limitations of this new style of application development. Keywords. Internet Programming, Web Programming, WEB 2.0, AJAX, Client-Server, Application Development 1. Introduction Internet use is changing, along with user expectations regarding the web experience. Early Internet users were typically programmers, with a deep understanding of the systems in use. In contrast, modern users span a diverse range of education, experience, and technical understanding, as well as making a further distinction between application providers and end user consumers. What is usable to a developer is not always useful to a consumer. Usability has become a central concern for software development in general, but even more so for Internet applications. Contemporary applications must often compete in an end user centric environment where viable competition is never more than a few mouse clicks away. Strictly controlled networking models have historically made the delivery of enhanced usability a more formidable task [7]. Web-based business environments are clearly in transition to more experience-oriented models. Brand loyalty is rapidly becoming an antiquated notion, primarily due to the ease of comparing alternatives in an on-line environment. When shopping in so-called 'bricks and mortar' environments, a variety of factors (e.g. distance, cost, etc.) may prevent a person from shopping somewhere else, even after having an unfavorable experience. Web businesses do not suffer from these limitations - the nearest competitor is always a click away. Consequently, developers must work to create positive, memorable experiences for the customers. The goal of enhancing the web experience is to bring users as close to the action/product as possible without actually physically being at an event or in a showroom. When a website is done well, it provides a superior intuitive feeling. As Don Norman of Macromedia puts it: Beautiful things work better. [7] Rich Internet Applications (RIAs) utilize asynchronous techniques such as Ajax (Asynchronous JavaScript and Xml) to enable real time data communication and dynamic rendering, which give the web interface a more desktop-like application feel. The goal is simple: since many people live on the desktop, proper Internet applications should be an extension of where they live; of their comfort zone. 413 Proceedings of the ITI th Int. Conf. on Information Technology Interfaces, June 25-28, 2007, Cavtat, Croatia

2 This paper provides a brief explanation of the relationship between the growing importance of Internet applications and the restrictions imposed by the traditional web development model. The authors then consider Ajax and its involvement with Rich Internet Application (RIA) development, and offer an introduction to various technologies that support RIA development. Finally, we explain how RIA differ from traditional applications in terms of their relative advantages, as well as considering limitations in RIA development that still need to be addressed. 2. Traditional Internet Applications We begin with a brief discussion of the widely acknowledged importance of Internet applications, an understanding of which is critical to our central theme. In the most basic sense, Internet applications allow companies and individuals to enjoy greater reach for less cost. Consider a typical bricks and mortar retail store. Business costs include land and construction costs, maintenance and utilities, and the like. In comparison, the cost of serving web pages off a server a business may or may not own typically represents a small fraction of this amount. This simple case underlines the drastic difference not just in cost, but also in other areas, which enhance the profit potential of the webbased enterprise. However, we also note that purely web-based companies have exhibited far more, and from a consumer perspective potentially less desirable, volatility in many markets where they have tended to be shorter lived and less stable than their brick and mortar business counterparts. Amazon.com offers an excellent example of a successful web-based business. From a starting point with no physical stores and no brand recognition, it has grown over the years and increasingly sought to offer end users the best experience possible. They have often been able to overcome companies that have far more physical market presence and brands of their own. This is in large measure due to the simplicity of their website and the ease of which people can find what they are looking for. The well known client-server model, with some revisions to support the vast scalability needed by the World Wide Web, is the basis for traditional Internet applications. It is built on proven and existing technologies, such as the Transmission Control Protocol (TCP) and HyperText Markup Language (HTML), which allow it to be very cost friendly for companies. [8] The principal tool involved in creating Internet applications is HTML, which is ubiquitous, requires no special tools, and is simple to learn. To further enhance applications, web servers can be loaded with a variety of modules that permit server side scripting, permitting dynamic pages that will change to reflect who is viewing the page and what data are sent to the page via a query string. This is again built on the client server model, where the client makes requests and displays the results, while the server does all the work. Because of the simplistic nature of this model, application development is relatively uncomplicated. However, as the internet has evolved, user expectations regarding the web experience have changed, and the traditional model has started to show its age. One of the disadvantages of the client server model is the reliance on the server for processing, requiring a page refresh for every user action. This results in a lot of redundant data being passed, increasing wait times, and giving pages a start and stop feel due to their multi-page interfaces. Such application behavior is increasingly unacceptable in time-sensitive application domains such as finance and medicine. With the relentless increases in the speed of modern computers and increasing accessibility to broadband internet services, users are demanding more from web-based applications. Finally, HTML was never conceived to create rich interfaces, but merely as a way to present information. With the advent of XML, HTML 4.0 may very well be the last release of HTML as it transitions to extensible HTML (XHTML). The proliferation of the internet has created a void in terms of acceptable user experiences for desktop and Internet applications [3]. To fill this void, developers must continue to enhance the user experience, by creating Internet applications which are more fully capable of mimicking their desktop counterparts. This new stage of development has lead many to adopt the term 'Web 2.0' to describe the change in the development methods and Internet application design, suggesting that it represents a new and different application development paradigm, but we do not fully subscribe to this view. Many socalled new Web 2.0 applications still rely on the traditional client server model, merely using it asynchronously rather than the traditional synchronous fashion. 414

3 3. Rich Internet Applications Rather than merely considering yet another re-working of the client-server model, we direct our attention to applications that take a more significant departure from the traditional development models. These applications are what we refer to as Rich Internet Applications (RIA). By their very definition, RIA will often rely on emerging, asynchronous, and possibly non-client-server technologies (some with a history of incompatibilities!) and/or a reliance on a plug-in being present to allow an application to execute. Consequently, the development process is more complicated, and introduces more variables into the process. [1] RIA can be organized into three distinct types as a function of how they are developed or deployed. The first type, plug-in based, involves creating the application on a dedicated platform (or in a dedicated environment) and then deploying it as either an embedded solution or standalone application launched from the browser. An example of the embedded approach is Adobe s Flex 2 technology, which uses an XML based markup language called MXML to declaratively create Flash based applications. These can then be included on HTML pages using standard HTML tags. An example of the stand-alone approach is Java Web Start. Java Web Start uses the Java Network Launch Protocol (JNLP) to launch a defined java application from the browser. By doing this from the browser, developers can ensure that the specified version is always available. The biggest advantage to the plug-in based approach is the simplicity of development. Commonly referred to as the Sandbox approach, it allows developers to have a stable and understood platform for development, and provides assurances that it will run in the same way across multiple platforms, as long as the correct plug-in is available. Indeed, Java applets are among the first RIA ever created for the web. Other examples supporting plug-in based RIA development tools include Microsoft Windows Smart Client (msdn.microsoft.com/smartclient/) and Open Laszlo ( The second type of RIA is by far the most well known. Rich Internet Applications created with Ajax techniques are referred to as scriptbased RIA. These applications employ a combination of technologies to achieve their results, typically including XHTML/HTML, CSS, DOM, and JavaScript. The idea is to use CSS and HTML to style and present the interface, use JavaScript to make an asynchronous request to the server, and finally use DOM Scripting to perform 'on-the-fly' rendering. This strategy gives the application a minimal footprint and requires no software to be pre-installed. However, some of the technologies have well-documented compatibility problems, based on platform and browser environments. Because of these incompatibilities, developers must exercise caution in order to prevent instances of dead features. The most successful strategy for developing Ajax style applications is to assume that the user's browser has no access to JavaScript. An application is first developed using the traditional model for a normal Internet application. JavaScript is then used to check for its own existence and modify page components as necessary. This is a particularly long and difficult process which requires in-depth knowledge of the various incompatibilities that exist, and how to support the various processes in older browsers. Because of this complexity, a variety of frameworks have been spawned to alleviate the compatibility issues with browsers. Two of the more popular ones are Prototype and Dojo. The final type of RIA, and often the least publicized, is browser-based. These generally incorporate a user interface language, built on XML, which allows developers to specify the needed elements and their interactions in a declarative format. An example is the XUL language from the Mozilla Foundation ( org). The key benefit of this approach is the basis on existing XML standards supported by the W3C such as CSS 1 and 2, DOM Levels 1 and 2, and JavaScript XUL is designed to be platform independent, thus allowing for portability between platforms. The common element of RIA technologies is the ability to leverage the rendering and communication powers of the underlying scripting engine to request the data they need, and update the user interface to display it. This permits significant enhancement of the user interface, and facilitates improved application intuitiveness. For example, these types of applications can provide users with feedback for any action they take. In addition, although the application environment is often one where rapid execution is stressed in order to preserve the real time look and feel of the application, the asynchronous nature of RIAs can also be used to 415

4 update users on the status of long running processes. Because applications only send pertinent data to the server, and only receive lower volumes of information that is changed, the volume of network traffic being generated is greatly reduced. The application still communicates with the server, but fractional rather than full pages are transmitted. This approach permits smaller incremental updates to reflect user actions, making the resulting client very thin and permitting single page interface for applications, rather than the traditional multi-page interface common to older Internet applications. This suggests that even clients with low bandwidth (e.g. dial up) connections are able to fully enjoy the richness of the application. [7] Figure 1. Traditional v. Rich (Ajax) Internet Application Models In all RIA, there is a consistent sequence of events leading up to the asynchronous call and the retrieval of data, as shown in Figure 1. Even in the Ajax communication model, the browser / client still loads the interface as it would normally. During this stage JavaScript is used to enable the required functionality for (we suggest the term ajaxify ) the page. There is no detection involved. If JavaScript is not available, it simply is not executed. The page is initially constructed under the assumption that JavaScript is not available, and no modifications would be made to the page in this case. If JavaScript does exist, it is used to add event handlers and setup the various methods for facilitating the Ajax process. [5] At this initial stage, an XMLHttpRequest object, whose job it is to handle the sending and receiving of data between the client and server, is created. A combination of anonymous and named functions are registered to events to send data, and handle return requests. When a return request is received (in either plaintext or XML format) JavaScript is used to manipulate the Document Object Model (DOM), updating the user interface to reflect the result of the action. [5] When creating RIA, one of the primary goals is to keep data synchronized, and allow the user interface to update in response to user actions. For example, if a user deletes a particular item from a list, that item should visually disappear from the screen. This functionality can be further enhanced with a fade effect, creating a user impression that the item is being deleted in real time. However, some users may not notice when an update takes place, so RIA should also provide some form of notification when a task or process completes. Users may also be directed to more important content or notices with colors or other visual cues. Users are sensitive to relative and perceived response times. Processes should not take what users might regard as too long to complete. One of the main reasons for using RIA is to create a user impression that tasks are being done the instant a user request is initiated. A long running process will easily frustrate users if they are expecting rapid responses. In such cases, RIA should provide a means to show the progress of the operation, and indicate approximately how much longer the operation will take (with periodic or real-time updates). Finally, RIA should support undo and redo operations. When attempting to emulate a desktop application, it is necessary to provide the types of components and functionality that users will be familiar with and will easily understand. 4. Limitations of RIA Development RIA would seem to be an idea with great potential to enhance the web experience for end users. However, they are not without problems. As stated previously, they are built on a set of technologies that have a history of potential incompatibilities between browsers and platforms, although the use of libraries can help eliminate many of these compatibilities and lessen development time. It is also important to note that the idea of RIAs and asynchronous Internet applications is fairly new, and despite the rapid additions to JavaScript to help support 416

5 the new role its taking, there is still a paucity of mature development tools for Script Based RIAs. Plug-in based RIAs, by comparison, tend to be backed by companies that can deliver more robust development environments for these applications; as exemplified by Adobe s Flex 2, and the related Flex Builder Eclipse plug-in. Perhaps the biggest problem is accessibility [4]. Users may not be aware of how application data updates are occurring, so they may not be able to properly identify or locate them. This is particularly true with an update occurring on a different section of a page than the region where the user is currently interacting with the application. In addition, they may be unaware of how to find new or updated content. One of the ways to overcome this type of problem is through an explanation of the interaction to the user. Additionally, the provision of a non-ajax update for these users is also an acceptable addition to enhance accessibility. Aesthetic changes to affected sections of the user interface can help address the problem of users not noticing updated content. Keyboard mapping changes can make navigating a page more like navigating a traditional desktop application. This approach fits well with the DHTML Accessibility Techniques.[4] The Accessibility for Rich Internet Application (ARIA) Standard is currently under development by the World Wide Web Consortium ( ARIA seeks to develop a common model that can ensure equal access and functionality for all RIA. Larger-scale development and deployment of RIA is also hampered by lack of a coherent architectural style for these applications and libraries. There are a variety of styles that exist, from Google s Google Web Toolkit (GWT) to Echo 2, which are discussed in the next section. Most of these styles are derived from similar processes used in the creation of desktop applications.[6] Among these many styles, the REpresentational State Transfer (REST) style is considered the most powerful and useful. REST emphasizes data and service abstraction, permitting execution on demand through downloads in the form of applets and scripts.[2] Flickr, ( for example, uses REST to facilitate binary uploads, but a full discussion of REST is beyond the scope of this paper. 5. RIA Development Environments An in-depth discussion of many of the multiple RIA development environments is well beyond the scope of this paper. However, the Google Web Toolkit com/webtoolkit/ and Echo2 com /platform/echo2/echo/, provide examples of environments that provide a bridge between the sandbox and framework approaches to RIA development, and are briefly compared here. Both approaches make use of standard Java code, which can then be compiled to HTML / JavaScript, allowing programmers to apply existing skills and knowledge to the development of RIAs. This approach offers several advantages: Use of a familiar code base (Swing, SWT, AWT, etc..). Java type checking allows for greater productivity and fewer errors. Java OO designs are often easier to maintain than plain JavaScript designs, which can mix OO and procedural code. With GWT all code is executed on the client. With Echo2, execution takes place on the server. A disadvantage to GWT is that the generated HTML/JavaScript file will typically be much larger than an Echo2 version, which divides the code into smaller pieces. To further enhance developer productivity, Echo2 employs "lazy loading" for all JavaScript modules, caching them for future use. GWT applications are "fat" clients, requiring less communication with servers. This makes GWT perfect for applications that will be simple and not require huge amounts of queries to the data store. 6. Conclusion There is a major shift occurring with respect to the design of Internet applications. The trend is toward providing a richer set of functionality, to close the gap of interactivity and usability between Internet applications and their desktop counterparts. The goal of these Rich Internet Applications is to function like their desktop counterparts, and to be intuitively familiar to end users who spend the majority of their time interacting with desktop applications. 417

6 Contemporary applications such as Google Maps, Suggest, Flickr, Basecamp ( basecamphq.com), and Amazon A9 Search have already started taking advantage of these RIA development techniques, and are leading the way to the next stage in Internet application development. The transition to RIA may signal the decline of traditional Internet applications. While some problems with compatibility do exist with Rich Internet Applications, their growing popularity is undeniable. Such applications are generally seen as a step in the right direction for the modern Internet. Since Beautiful things work better, the new focus for Internet development is about creating a rich and memorable experience, so that end users keep coming back. 7. Acknowledgements The authors wish to acknowledge suggestions from the reviewers of the first version of this manuscript, which have been incorporated into this final version, space permitting. 8. References [1] Bozzon, A, Comai, S. Fraternali, P. and Carughi, G. "Conceptual Modeling and Code Generation for Rich Internet Applications." ACM International Conference Proceedings Series (2006) [2] Fielding, Roy T. "Architectural Styles and the Design of Network-based Software Architectures" PhD Dissertation (unpublished), University of California, Irvine, [3] Garrett, Jesse J. "Ajax: A New Approach to Internet applications." Adaptive Path. 18 Feb [4] Gibson, Becky. "JavaScript and AJAX Accessibility. IBM, [5] Heilmann, Christian. Beginning JavaScript with DOM Scripting and Ajax. New York: Apress Publishing, [6] Mesbash, Ali. An Architectural Style for Ajax. Software Engineering Research Group Technical Report Series. Delft University of Technology, [7] Mullet, Kevin. "The Essence of Effective Rich Internet Applications." Macromedia Whitepapers [8] "Rich Internet Application Development." NetScript Whitepapers. Dec