Your SlideShare is downloading. ×
Date of acceptance   Grade


                                          Instructor




Performance of Ajax applications on ...
HELSINGIN YLIOPISTO  HELSINGFORS UNIVERSITET – UNIVERSITY OF HELSINKI
Tiedekunta/Osasto  Fakultet/Sektion –Faculty/Secti...
ii

Content

1 Introduction                                                                                               ...
iii

4 Libraries, Toolkits, and Frameworks                                                                                ...
iv

  6.5 Memory Leaks.......................................................................................................
1


1 Introduction

During the past decade, the popularity of the World Wide Web has grown tremendously
from its humble or...
2

mon on web sites, announcing that the site in question was “best viewed” [Yah07a] with
the designer's browser of choice...
3

and then either processed or the errors returned to the user. From this simple technique,
quite elaborate user interfac...
4

universal web applications for all devices. Until then, it is a question of choosing the
right toolkit amongst the cont...
5

might force the amount of features to decline, not increase.

This chapter reviews the motivation towards more desktop-...
6

one, and try to determine what changes have been made.

These three problems are not random by nature. They closely res...
7

to be adequately supported by existing browsers. This implies that the technologies have
been around for a while, but n...
8

implementations offer differing degrees of support of the corresponding version. Nets-
cape, Microsoft, and other devel...
9

self-defined message formats may yield performance benefits, the use of XML or JSON
is recommended for reasons of conve...
10

the now-familiar refresh delay, the user might easily become alarmed that something
went amiss with the original reque...
11

ample, fixed layouts use more invariable measurement units, usually pixels or points, to
specify element sizes. This i...
12

petitor was Netscape Navigator's layer interface [Sco06a], although it supported a more
limited set of functions. When...
13

2.3 Alternative Techniques
The motivation for this partial review of alternative techniques lies within browser dif-
f...
14

2.3.2 Delayed Inclusion

The technique of delayed inclusion is similar to many other patterns that achieve reduc-
tion...
15

they could easily cause a number of user interface problems [Nie96]. Most notably, us-
ing frames made the back button...
16

specially desirable in conditions where each message has a resource cost, be that in bat-
tery time or financial units...
17

lar due to their lowering effect on bandwidth consumption [Dav07]. Moreover, some
mobile browsers employ proxies for c...
18

new factor of a limited battery lifetime. Simultaneously, the use of techniques like Ajax
involve browser capabilities...
19

with a different overall grade are sternly discouraged – they should only be performed
by the most informed readers, e...
20

Fourth, using the mobile browser as a programming platform offers an additional level
of middleware for application de...
21

development projects is impressive. Since an important reason behind the ubiquity of
the World Wide Web is audience pa...
22

testing includes that the connection time may greatly vary, and indeed be vastly longer
than the time taken to load an...
23

not a mobile phone – it lacks any and all functionality required to connect to a carrier
network. Despite this drawbac...
24

N800, the Opera browser is part of the purchase fee, and therefore licensed by Nokia.

The relevant application packag...
25

3.5 N95
The Nokia N95 is a “true” converged mobile device in the sense that it is no longer mar-
keted as a mobile pho...
26

3.5.1 Nokia Mini Map Browser

The default browser for the S60 operating system is simply titled the “Web Browser for
S...
27

3.6 iPhone
The Apple iPhone [App07a] is far from the first mobile device developed by the manu-
facturer, but it is th...
28


4 Libraries, Toolkits, and Frameworks

As briefly introduced in Chapter 1, the major problem with current web design ...
29

with specific server-side programming languages and environments, and some have ad-
apted their counterpart's style in...
30

Of the toolkits presented, script.aculo.us and prototype have been developed along the
Ruby on Rails framework [Han07]...
31

has enjoyed, the number of web sites employing Ajax has grown explosively. Concur-
rently with the rapid web design, s...
32

cluded in this statistic. The early fragmentation can be clearly observed in the results, as
many toolkits have been v...
33

are the key element of an unbiased comparison between the measured loading times. If
the grades are ignored, the chart...
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Performance of Ajax Applications on Mobile Devices
Upcoming SlideShare
Loading in...5
×

Performance of Ajax Applications on Mobile Devices

4,725

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,725
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Performance of Ajax Applications on Mobile Devices"

  1. 1. Date of acceptance Grade Instructor Performance of Ajax applications on mobile devices Mikko Pervilä Helsinki February 5th, 2008 UNIVERSITY OF HELSINKI Department of Computer Science
  2. 2. HELSINGIN YLIOPISTO  HELSINGFORS UNIVERSITET – UNIVERSITY OF HELSINKI Tiedekunta/Osasto  Fakultet/Sektion –Faculty/Section Laitos  Institution  Department Faculty of Science Department of Computer Science TekijäFörfattare  Author Mikko Pervilä Työn nimi Arbetets titel  Title Performance of Ajax applications on mobile devices Oppiaine  Läroämne  Subject Computer Science Työn laji Arbetets art  Level Aika Datum  Month and year Sivumäärä Sidoantal  Number of pages M.Sc. Thesis 5.2.2008 88 pages + appendix 20 pages Tiivistelmä Referat  Abstract The Ajax approach has outgrown its origin as shorthand for “Asynchronous JavaScript + XML”. Three years after its naming, Ajax has become widely adopted by web applications. Therefore, there exists a growing interest in using those applications with mobile devices. This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and Nokia models N95 and N800. Performance is benchmarked through user-experienced response times as measured with a stopwatch. 12 Ajax toolkit examples and 8 production-quality applications are targeted, all except one in their real environments. In total, over 1750 observations are analyzed and included in the appendix. Communication delays are not considered; the network connection type is WLAN. Results indicate that the initial loading time of an Ajax application can often exceed 20 seconds. Content reordering may be used to partially overcome this limitation. Proper testing is the key for success: the selected browsers are capable of presenting Ajax applications if their differing implementations are overcome, perhaps using a suitable toolkit. ACM Computing Classification System (CCS): C.4 [Performance of Systems]: Performance attributes; H.3.5 [Information Storage and Retrieval]: Online Information Services---Web-based services; H.5.4 [Information Interface and Presentation]: Hypertext/Hypermedia---Architectures, Navigation, User issues; H.5.2 [Information Interface and Presentation]: User Interfaces; D.3.2 [Programming Languages]: Language Classifications---Concurrent, distributed, and parallel languages, JavaScript; C.2.4 [Computer-communication Networks]: Distributed systems---Client/Server, Distributed Applications Avainsanat – Nyckelord  Keywords Ajax mobile devices performance web applications DHTML JavaScript Säilytyspaikka  Förvaringställe  Where deposited Muita tietoja  Övriga uppgifter  Additional information
  3. 3. ii Content 1 Introduction 1 2 The History of Ajax 4 2.1 From Web to Desktop Applications.....................................................................5 2.2 Ajax Builds on Existing Technology....................................................................6 2.2.1 JavaScript......................................................................................................7 2.2.2 XMLHttpRequest..........................................................................................8 2.2.3 Asynchronous Events....................................................................................9 2.2.4 XML and Verbosity....................................................................................10 2.2.5 Displaying CSS...........................................................................................10 2.2.6 Document Object Models...........................................................................11 2.3 Alternative Techniques.......................................................................................13 2.3.1 Dynamic HTML..........................................................................................13 2.3.2 Delayed Inclusion........................................................................................14 2.3.3 Hidden IFrame............................................................................................14 2.3.4 Comet and HTTP Pipelining.......................................................................15 2.3.5 Flash and Java.............................................................................................17 3 Measuring Mobile Devices 17 3.1 Capability and Performance................................................................................18 3.2 Motivation for Mobile Ajax................................................................................19 3.3 Research Questions and Methodology................................................................20 3.3.1 Grading and Results....................................................................................21 3.3.2 Measurement Method..................................................................................21 3.4 Nokia N800 Internet Tablet................................................................................22 3.4.1 Opera...........................................................................................................23 3.4.2 Mozilla based browser for maemo..............................................................24 3.4.3 GTK+ WebCore..........................................................................................24 3.5 N95......................................................................................................................25 3.5.1 Nokia Mini Map Browser...........................................................................26 3.5.2 Opera Mobile..............................................................................................26 3.6 iPhone.................................................................................................................27 3.6.1 Safari...........................................................................................................27
  4. 4. iii 4 Libraries, Toolkits, and Frameworks 28 4.1 Graphics display..................................................................................................29 4.2 Selection and Manipulation................................................................................29 4.3 Widgets...............................................................................................................30 4.4 A Look into the Most Popular Toolkits..............................................................30 4.4.1 How to Read the Results.............................................................................32 4.4.2 Prototype.....................................................................................................33 4.4.3 script.aculo.us..............................................................................................34 4.4.4 jQuery..........................................................................................................36 4.4.5 Yahoo! User Interface Library....................................................................37 4.4.6 Dojo.............................................................................................................38 4.4.7 Ext JS..........................................................................................................39 4.4.8 Google Gears and Web Toolkit...................................................................41 4.4.9 Direct Web Remoting.................................................................................42 4.4.10 MooTools..................................................................................................44 4.4.11 moo.fx.......................................................................................................46 4.4.12 ASP.NET AJAX.......................................................................................47 4.4.13 Frost Ajax Library.....................................................................................48 5 Surfing Web Sites with Ajax 50 5.1 How to Read the Results.....................................................................................50 5.2 Google.................................................................................................................51 5.2.1 Google Maps...............................................................................................51 5.2.2 Google Suggest...........................................................................................52 5.2.3 Google Mail................................................................................................54 5.3 Yahoo! Mail........................................................................................................55 5.4 Flickr...................................................................................................................56 5.5 Journey Planner for Cycling...............................................................................57 5.6 Colorado Geographic..........................................................................................59 5.7 myAOL...............................................................................................................60 6 Considerations 62 6.1 Cross-Site Scripting Attacks...............................................................................62 6.2 Cross-Site Request Forgery................................................................................63 6.3 External References............................................................................................64 6.4 Caching Problems...............................................................................................65
  5. 5. iv 6.5 Memory Leaks....................................................................................................66 6.6 Accessibility........................................................................................................67 6.7 A Side Note on Battery Life...............................................................................68 7 Conclusion 69 7.1 Further Research.................................................................................................71 8 Acknowledgment 72 References 73 Appendix 1. Test notes
  6. 6. 1 1 Introduction During the past decade, the popularity of the World Wide Web has grown tremendously from its humble origins as the Hypertext Markup Language (HTML) for scientific texts [W3C03]. The low learning curve of the HTML language, a host of WYSIWYG editors, and the will to publish are all factors that have enthralled the public as well as enabled it to participate. Eventually, both small and large organizations and companies caught on en masse. These new participants brought new requirements into the picture – require- ments that did not always match with HTML as it was defined. As the number of interested parties grew, the need arose to make each new web site more special in order to distinguish it from the existing ones. To meet the increasing demand, new versions of HTML were specified, adding to the language's power of expression. Later on, its in- creasing layout capabilities were split and endowed to Cascading Style Sheets (CSS). The new specifications were eagerly interpreted and implemented by browser de- velopers, whose aim was to populate the market with their products. But soon it became clear that the demand far exceeded the supply. The major standards organization, W3C, could not keep up with the rapid pace of web designers everywhere. While many new design techniques became available, critics yelled out that some of these techniques wantonly misinterpreted the intent behind the standards (see any discussion on HTML tables). To aggravate the problem, browser developers started to extend the standards with their own, browser-centric features. These extensions started out as guesswork on which new features the users would next like to see. Some were successful, others for- gotten. However, the use of such tools forced designers to dedicate their projects to a specific browser platform. One of the new extensions was JavaScript [W-J07a]; its main competitor Visual Basic Scripting Edition (VBScript) [Mic07a]. Very early on in this history, another problem emerged as well. As new features and techniques started to become available, both the designers and the public became aware of differences in the layout of the pages. Even web sites written to follow the standards did not always look exactly as intended. The human capacity for error manifested as faults in the interpretation of the standards, and the faults were reflected in the browsers. Instead of writing once and displaying everywhere, the designers were now forced to take into account a number of small discrepancies. The flaws were not fatal, but it took more time to test the code on several browsers. Warnings and disclaimers became com-
  7. 7. 2 mon on web sites, announcing that the site in question was “best viewed” [Yah07a] with the designer's browser of choice. This struggle was called the browser wars, and it con- tinues to this day [Wei06]. Gradually, it dawned that these problems were not going to disappear with the next gen- eration of browsers. Most designers calmed their minds and stopped neglecting the other platforms. But not all of them. Ever since, each web site's testing cost has been paid many times, once for each major browser. The strategy is to categorize the public of the web site, and try to support their chosen browsers. Outside of intranet environ- ments, this task might well be impossible to perform conclusively. The number of choices is greater today than ever before, with new browsers released bi-monthly for open source platforms, home entertainment systems, and mobile devices. Commonly, the same browser might behave differently when installed on two operating systems. Automated testing suites [GEO07d] do exist, but their cost and other restrictions remain prohibitive factors for some designers. Before all the combinations can be tested by hand, a new browser version might be released, bringing new features and failures into the mix. Fortunately, the hardy designers have not given up. Instead, they have created web com- munities dedicated to avoiding the inconsistencies and writing the best possible code. These communities have constantly employed the newest technologies to evangelize the word: first forums, then wiki sites and web logs (blogs). A more experienced web de- signer will typically have to maintain his palette of techniques by following several sites. Scientific articles are published only exceptionally, making references scarce. Writing around the problems has met with partial success. Even though the amount of code required for exception handling grows, the available network bandwidth and cli- ent-side processing power seems to grow faster. After the so-called fifth generation browsers [W-J07b] were released, web sites written in XHTML 1.0 and CSS could be labeled as adequately accessible. The vast majority of the users see the same page with little or no differences in layout, and the minority of users with dated browsers are urged to upgrade as soon as possible. Even mobile devices have begun to support mul- tiple browsers and upgrading. The current trend is towards more responsive and desktop-like web applications [Nie05]. The first web applications used forms and links in order to receive input from the user. Combined with server-side scripting techniques, the input would be validated
  8. 8. 3 and then either processed or the errors returned to the user. From this simple technique, quite elaborate user interfaces became possible. But these applications were always forced into the lock-step of the input-validate-process cycle. Usability studies were quick to declare the validation delays harmful, as they stopped the work flow of the user [ShM97]. The users felt that after every minor error, they were interrogated with the same questions over and over. On a larger scale, the bag of tricks created by the ingeni- ous use and abuse of the form tag was beginning to thin. Some UI solutions remained simply unreachable as long as every input-output request required a page redraw, caus- ing its signature interruption to the user. In the rapid fashion typical of web development, multiple solutions were soon published by the community. Some of the early ones stem from the first rounds of the browser war and are dependent on browser-specific capabilities. However, with the heightened in- terest into writing code accessible for all, only the more compatible solutions have gained popularity. Common to most of these techniques is the need for JavaScript. JavaScript has been both the core factor in current Dynamic HTML techniques and, of- ten simultaneously, infamous for its leaky security implementations. With just cause, a number of security experts have gone as far as to recommend keeping JavaScript dis- abled in security-focused environments [CER00], if not everywhere. Luckily for web designers, users do not always listen. As JavaScript was soon defined as its own standard, new browsers kept the scripting language enabled by default. For several years now, even mobile devices have featured improving support. Through this extending deployment, one method for achieving re- sponsiveness has gained significantly more popularity than its predecessors. Once a newcomer, this technique was dubbed Ajax in 2005 [Gar05]. It has since reached a re- spectable level of maturity, and an explosive coverage in current web services. But Ajax is not yet beyond the influence of the browser wars. Writing code for the current browsers requires would-be designers to learn where browser implementations differ. As mobile devices gain in performance, the number of implementations increases, not the opposite. The W3C Document Object Model (DOM) aims to give designers a com- mon interface for all browsers, but accessing this interface requires both new knowledge and discipline. In order to further lower the learning curve, help has arrived from several sources. In two years, a multitude of Ajax toolkits have been released to aid designers master XHTML, CSS, JavaScript, and the DOM. If and when the browser wars will fi- nally end, the designers can do away with these crutches and really start writing
  9. 9. 4 universal web applications for all devices. Until then, it is a question of choosing the right toolkit amongst the contestants. The purpose of this study is to measure how well newer mobile devices perform when handling Ajax requests. Chapter 2 is a review of predecessor techniques, some of which still exists hand-in-hand with Ajax. The chapter also shows how the component techno- logies of Ajax play their part from a mobile point of view. The research questions, methodology, and the selected mobile devices are presented in Chapter 3, along with the browsers available for them. Chapter 4 explores the most popular toolkits currently and evaluates some sample applications developed with them. Chapter 5 examines real, pro- duction-quality applications in their normal environment. Chapter 6 describes still unresolved problems and critique against using Ajax on a mobile, or any, device. The results are concluded in Chapter 7, followed by a short acknowledgment of people par- tially responsible for this thesis. 2 The History of Ajax Ajax is a loosely defined collection of web design techniques used to make web services more responsive by minimizing waiting periods through asynchronous server commu- nication. The name Ajax is based on the abbreviation1 of its core components: Asynchronous JavaScript and XML. Ajax has become very successful in a relatively short amount of time. In the two years since its naming [Gar05], the number of both sci- entific and popular publications has sky-rocketed. However, an easily overlooked fact is that similar solutions have existed for almost a decade. As many of its predecessors, Ajax builds on standardized and mature technologies. The main difference is that while many of the other techniques employ more creative uses of (unintended) side effects, Ajax relies on browser features that are designed for communication. Ultimately, all of these techniques rely on browser support. The flood of Ajax-enabled web sites could not have happened without the gradual shift towards newer browsers. The common requirement is a so-called fifth-generation browser [W-J07b]. This monik- er is borrowed from Microsoft Internet Explorer version 5.0, as it was the first browser that implemented the W3C DOM interface. Other manufacturers were quick to add sup- port for the new recommendation. Today, it is hard to find a desktop browser that belongs to any of the previous generations. But on mobile devices, external limitations 1 The capitalized form “AJAX” has quickly fallen out of fashion.
  10. 10. 5 might force the amount of features to decline, not increase. This chapter reviews the motivation towards more desktop-like web applications. Later, the component technologies of Ajax are reviewed specifically with mobile devices in mind. Finally, the last parts of this chapter present alternative techniques and how they may be combined with Ajax. Program examples are omitted in favor of the multitude of tutorials already available. 2.1 From Web to Desktop Applications As both the public and the features of the World Wide Web grew, it became first fash- ionable and then efficient to design services specifically for the web. Commercial ventures have met with varying success, but public organizations have slowly but surely spread onwards. Reaching as large a crowd as possible by easily accessible documents is a notable principle, for it matches well with both advertising and non-commercial ser- vices. As the web itself is either free or relatively low-cost, it has become a reasonable development platform for applications previously only released for operating systems. This transformation from the desktop to the web has also become a limiting factor for applications. The first hindrances lay in program logic, for client-side scripting support was riddled with inconsistencies, but also because any client-side processing was by nature open and unreliable. These problems were solved by shifting control away from the clients using server-side scripting. Ajax can be seen as an effort to move some of the processing back towards the client. Secondly, the web protocol presented an uniform interface for clients everywhere and every time. Each document request was processed as unique and totally independent of any other. However, this anonymity logically prevented user authentication necessary for identification purposes. Thus, cookies and sessions were bolted on the protocol. Their use met up with heated debate from the web community [StS02], but eventually the necessity was accepted. The third problem is the user interface. The request-wait cycle is seen as both disruptive and disorienting by the users. It is disruptive because the indeterministic delay caused by other users and network traffic. These factors make it difficult to decide when the re- quest has failed to reach the server, which may lead to duplicate requests. The cycle's disorienting effect is caused by the necessity to redraw the browser window after new output from the server. It requires the user to remember the previous page, read the new
  11. 11. 6 one, and try to determine what changes have been made. These three problems are not random by nature. They closely resemble a common design pattern, the model-view-controller approach [CPJ05 ch. 3]. Design following this pattern splits the content of the page into a business model, a view of the the functions available, and a controller intermediating between the two. On web pages, the output of the browser is the view, the business model is held within the web server, and controller functions are traditionally handled by server-side scripting. This split requires every in- put to pass into the server to be processed, causing both the delay and the redraw. Logically, responsiveness improves if we can avoid some of the delays and redraws. To achieve this, two requirements must be met: a communication channel and an interface for partial redraws. The communication channel must enable delayed or event-driven re- quests to the server, or push transmissions from the server to the client. Partial redraws enable the elements of the browser window to be changed individually, either through a standard interface like the DOM or a more proprietary programming layer. Further re- quirements for productivity in web applications are listed by Yu et al. [Yu06]. 2.2 Ajax Builds on Existing Technology Ajax is not defined in any specification. There exists no validation service to stamp a specific web site for Ajax compatibility. Therefore, defining an “Ajax application” is a somewhat ambiguous task. When an application is said “to be Ajax” or to “use Ajax”, the application employs a design pattern [Gam95] that is recognizable despite imple- mentation differences. The implementation depends upon lower-level components or technologies, some of which may be validated against existing specifications. In addi- tion to the core components, a number of other technologies are implicitly assumed, because the primary platform for Ajax applications is the World Wide Web. For ex- ample, pages may be written in (X)HTML and CSS, JavaScript may use the W3C DOM to manipulate partial redraws, and XMLHttpRequest objects may be chosen as the asyn- chronous communication channel. However, using any single component technology is not strictly required either. The following sections will review the components and present some ideas on how they could be exchanged with suitable alternatives. An important design principle with Ajax is the bias towards open technologies, i.e., those that are specified and governed by non-profit organizations. At the same time, Ajax builds on existing technologies in the sense that its components have been proven
  12. 12. 7 to be adequately supported by existing browsers. This implies that the technologies have been around for a while, but note that the support is still not uniform. As Ajax depends on the underlying technologies, differences in their implementation cause variation in the execution of the applications. Ajax components are selected for different purposes. Their tasks can be divided into the layers describing the content (alt. semantics), presentation and behavior (alt. functional- ity) of the web application [Yan07]. In this division, (X)HTML is used to mark the content, CSS to express the presentation, and JavaScript to change the presentation's be- havior. Refactoring and upkeep are simplified by also separating the code in different files [Ant07]. The division may be emphasized by writing the application gradually, be- ginning from the content and continuing through presentation to its behavior. This iterative approach is labeled progressive enhancement, and it is very closely related to its sibling, graceful degradation [Cha03, Ols07]. Common to both is the idea that the browser can “decide” which parts of the application to display, by simply ignoring those layers that the browser does not support. On mobile devices, progressive enhancement may be the better solution, since it tries to guarantee that even the most limited viewers are served a working solution. Without persistent connections (see Section 2.3.4), each HTTP file request yields a sep- arate TCP connection to the server. Each connection requires its own TCP handshake, which takes time [Yah07e, Sou07]. On high-latency links this delay becomes clearly no- ticeable, and therefore, undesirable. This means that if persistent connections are unavailable, the benefits of content separation have to be re-evaluated in mobile envir- onments where the high latency is typical. Placing the layers into a single file may be the better choice, but note that the idea of progressive enhancement need not suffer. An example of this technique is the Google default search page, as it embeds both script and CSS into a single file. 2.2.1 JavaScript JavaScript (JS) is a client-side scripting language originally designed for use in Nets- cape web browsers. JavaScript has been widely adopted for use in other browsers, most notably Microsoft Internet Explorer. In August 1996, Netscape let JavaScript be defined in an open standard by Ecma International2 [And98]. It is important to note that there are currently three different versions of the ECMA-262 standard [Ecm99]. All browser 2 Electronic Computer Manufacturers Association, abbreviated ECMA, before its renaming in 1994.
  13. 13. 8 implementations offer differing degrees of support of the corresponding version. Nets- cape, Microsoft, and other developers have extended their implementations with browser-specific features. At times, browsers have also manifested reduced functional- ity in parts of the implementation. There is considerable confusion regarding JavaScript's naming. JavaScript is a re- gistered trademark of Sun Microsystems3, but the language bears little resemblance to Java. The project was code named both LiveScript and Mocha during its infancy [Cro01]. This confusion has not alleviated, as current browsers have chosen to call the language JavaScript, ECMAScript, or by more local titles. The renaming is done to avoid potential trademark issues. Internet Explorer's variant is officially called JScript [Mic07b] whereas Adobe Flash employs a version called ActionScript [Ado07a]. Please note that Flash is not a browser, but a browser plugin. ECMAScript implementations have begun to surface in other areas outside the browser sandbox as well. Wikipedia makes an effort to list all dialects on its ECMAScript page [Wik07a]. Looking at the amount of names, one expects the language to be a dear child of de- velopers everywhere. In fact, JavaScript's reputation has been quite the contrary. A number of security concerns once made the language infamous [StS02, NVD07], com- promising its use in web design. The merit that balances this flaw is JavaScript's deployment. Barring disabling by the user or a local policy, JavaScript is available wherever a browser is installed. As the ECMA-262 core has been implemented in mo- bile browsers as well, the 80 million [IDC07] mobile devices shipped last year alone make JavaScript one of the largest programming languages in the world. 2.2.2 XMLHttpRequest The XMLHttpRequest (XHR) object was implemented by Microsoft in March 1997 [Esp00, Wil03]. XHR was originally an Internet Explorer 5.0 ActiveX object designed to work with Outlook Web Access. Mozilla-, Safari-, and Opera-based browsers were quick to catch on to the idea and implement their own versions of XHR. Recently, it has also been accepted as a W3C Working Draft [Kes07]. XHR:s purpose is to combine an asynchronous communication channel to the server with the XML document format. Despite its name, XHR also supports plain text as the message format. As JavaScript objects can be encoded into plain text through JavaScript Object Notation (JSON), it is clear that XHR provides a reasonable level of versatility for the designer. Even though 3 http://www.sun.com/suntrademarks/
  14. 14. 9 self-defined message formats may yield performance benefits, the use of XML or JSON is recommended for reasons of convenience, maintainability, and robustness. In desktop environments, a well-tested and maintainable interface is worth the performance cost. An existing limitation with XHR:s communication channel concerns its source domain. By design, XHR requests may be directed only to the same host name from where the original document loaded. This is done to avoid cross-site scripting attacks (XSS), where a malicious host uses the client browser's credentials, e.g., stored passwords, to request services from a trusting host. XSS will be more thoroughly examined in Section 6.1. Server-side request forwarders may be used to bypass this limitation locally [CPJ05, ch. 7.2], but special care has to be taken in limiting the hosts addressable through the forwarder. 2.2.3 Asynchronous Events Mobile devices are used in varying types of networks, which implies that the network properties may also vary. The development of mobile carrier networks has enabled con- nections with increasing amounts of bandwidth, but the latency of current networks has not decreased at an equal pace [CCP02, Cat05, VRP05]. This means that mobile users are susceptible to undeterministic amounts of latency, depending on the available net- work types. A heightened latency quickly yields equally heightened response times, injuring the sought-after property of responsiveness. Whereas shortening latency might remain the long-term development goal, an already available solution is to employ asynchronous requests for the communication channel. An asynchronous request will yield a response after an unknown round-trip time, but the user will be able to continue viewing the current page while waiting. The key ele- ment here is to write the client-side script to react to events from the client browser. An interface event, e.g., click of a button, might cause the original request to be sent. An- other event will be generated when the request is sent, and it may be used to pacify the user by letting her know of the ongoing process. A third event is generated by the arriv- ing request. A call-back function could then be registered with the third event type. The function will process the response content, displaying the output or a suitable error mes- sage. Taking a look from the usability perspective, the second event may be as important to the user as the two others. As the whole point of using the asynchronous call is to avoid
  15. 15. 10 the now-familiar refresh delay, the user might easily become alarmed that something went amiss with the original request [Dis06]. In a normal request-reload operation, the browser's loading icon is animated to signal communication in progress. Due to limita- tions in display area, a mobile browser might not contain a loading icon at all, or it might not respond to XHR requests. It is therefore necessary to inform the user with a separate display element, suitably positioned to convey the meaning but not cause un- due irritation. 2.2.4 XML and Verbosity The Extensible Markup Language (XML) [Bra06] is the X in both XHR and Ajax, but it is not required per se of any Ajax application. As noted, an XHR object is capable of handling responses in multiple formats through its support for plain text. Further, there has been grounded concern [KLT05] regarding the verbosity of the XML document structure and the amount of processing power it takes to read and write XML. These problems have made it questionable whether XML is suitable for use in mobile devices. The answer to that question has recently turned out to be positive, with some reserva- tions [Kan07]. The space and time requirements for XML processing can be much alleviated through the use of binary XML [GoL05]. Also, HTTP might not be the op- timal transfer format in wireless environments, due to similar concerns about the protocol's inherent verbosity. An important side note here is the necessity of server-side support when responding to an XHR call with a XML document. The originating browser does not always know the response type when making the call [Eer06]. Instead, the server-side script must set the appropriate content type before starting its output. Without an explicitly set content type, the output will be received as plain text by the browser. 2.2.5 Displaying CSS Cascading Style Sheets [LiB99] are the most common method for specifying the layout of a web page today. A long-time division of current layouts is between the fixed [Hol99] and fluid (alt. liquid or dynamic) methods. Please note that the following defini- tions mainly address window width, whereas the height is indirectly determined by the amount of content. A layout is said to be fixed if it makes assumptions of the browser window size. For ex-
  16. 16. 11 ample, fixed layouts use more invariable measurement units, usually pixels or points, to specify element sizes. This is done to ensure that the layout is rendered equally among the clients. If the browser window is shrunk beneath the intended display size, the user will be forced to scroll the window in order to view all of the content. It might hamper readability a great deal, as forcing the user to scroll the window for every line read is clearly not a sign of great usability. If no assumptions on the browser window are made, the layout is said to be fluid. This means that the browser's layout engine is left with the responsibility of rendering the page as it sees fit. If the browser window shrinks, the elements may be repositioned in order to retain readability. The fluid technique presents an alternative flaw: when the browser window grows, there exists no maximum width for elements. This will, again, hamper readability if the text lines stretch to become overly long. Another problem with both fixed and fluid elements concerns the use of images. As bit- mapped images contain intrinsic width and height properties, they will not scale with the rest of the page. The use of vector images [FFJ03] has been proposed, but they have not yet reached wide-scale deployment. A newer technique designed to answer some of these problems is the use of elastic lay- outs [Gri04]. Elastic layouts contain both fixed and fluid elements. Picture dimensions may be specified in units that are relative to the selected font size. As a bit-mapped pic- ture will not scale without some artifacts, so this is only a partial solution. As we will see later on, mobile browsers have responded to the layout problem with browser zooming. Zooming the display window allows the user to catch the overall lay- out of the page, and then concentrate on the selected level of detail. Pictures are then typically viewed with a resolution smaller than the inherent dimensions of the image, causing no artifacts but, instead, some redundancy in the transfer size. 2.2.6 Document Object Models The abbreviation “DOM” is used interchangeably with “W3C DOM”, even though the former version is somewhat imprecise. Alternative document models are sometimes called browser object models (BOM) [Ler06] to distinguish the use of a browser-centric version. As briefly mentioned earlier, the DOM was first supported by Microsoft Inter- net Explorer's fifth version. Before Microsoft's decision to support the DOM, competing browsers had very much contained their own models [Koc04]. An important early com-
  17. 17. 12 petitor was Netscape Navigator's layer interface [Sco06a], although it supported a more limited set of functions. When Internet Explorer 5 became the dominant browser, due to reasons not discussed here, the DOM consequently gained much in popularity. Both the DOM and different BOM:s were first used to implement DHTML-like tech- niques, which are now reused in Ajax. The idea of the W3C DOM [Hég04] is to model the displayed document as a hierarchical tree structure, which may be manipulated by adding or removing elements as child nodes. Changes are then propagated to the visual representation. Using a programmatic approach is desirable, for it allows the designer to manipulate whole sections of the currently visible page. More advanced techniques also become available, such as automatically generating repeating elements by just passing the generating function to the client. Critique is mainly directed towards the necessity of strict programming techniques, lest elements be removed with their parent by accident, or other such unwanted side effects ensue. Also, statements that access the interface can become quite lengthy, depending somewhat on the programming style chosen for the browser. With desktop browsers, a tertiary flaw exists, and it becomes more important as we move on to mobile devices. This issue concerns the speed of the browser's implementation of the DOM. The normal behavior for a browser is to build the hierarchical model from server output, parsing and interpreting the text into a tree structure. After this, only small modifications to the presentation are expected. It is wise to concentrate speed optimizations on the most common tasks. When the application's behavior changes and more advanced functions are accessed, speed may quickly become an issue [Geo07c]. A shortcut exists in the form of the innerHTML property, which allows designers to re- place a node's complete subtree with a text string, subsequently interpreted as code. Multiple sources [Rah06, Hed07, Leb06, Koc06] have commented that the innerHTML method is significantly faster on some, but not all, browsers. A similarity exists between this style and the avoidance of XML for its more processor-intensive interpretation. Ad- vocates have gone as far as to coin abbreviations such as AHAH, AJAH, and AXAH, where the replaced letters underscore the use of (X)HTML. The position of this thesis is that the use of innerHTML may indeed be valuable for mobile devices, but these tech- niques are already encompassed by the existing name Ajax. XML has never been a prerequisite, only a suggestion.
  18. 18. 13 2.3 Alternative Techniques The motivation for this partial review of alternative techniques lies within browser dif- ferences. The techniques are not disjunct in the sense that one is prohibitive of using any other. Using two different methods to achieve the same goal might improve compatibil- ity with different browser versions. In the case of Google Maps [Goo07b], the amalgam of Ajax with the Hidden IFrame technique enables the use of the back button within the same browser [Web05b]. In fact, Google Maps is one of the most famous Ajax applica- tions, and it does not use XHR as its main communication channel [Web05a]. A rigorous listing of early communication techniques is by Wilton-Jones [W-J07c]. Many of the solutions listed there have already disappeared from use. In addition to the more inventive approaches, even a W3C recommendation [StH04] has been reduced to having nothing but the most rudimentary browser support. 2.3.1 Dynamic HTML Dynamic HTML [Goo02] is the moniker for the combination of HTML with client-side scripting and a browser interface. DHTML originally appeared at the height of the browser wars. Early DHTML pages used browser-specific extensions for scripting and interface calls, so that their compatibility was severely limited. Later DHTML tech- niques have embraced JavaScript in combination with CSS and the W3C DOM. Thus, DHTML today has much in common with Ajax. Both employ the same core technolo- gies to generate a wider variety of user interfaces. With DHTML, the goal was to make the content more dynamic, not the interface more responsive. Beyond those labels, there was little difference in the effect. The major dif- ference to Ajax was that DHTML, as a technique, did not contain a communication channel for data transfers. If page redraws were to be avoided, DHTML-enabled pages had to be populated in advance with the necessary data for partial redraws. This method was less than optimal, since making each client download irrelevant portions of the ap- plication database can quickly become either inefficient, insecure or both. It is worth noting that some designers [Ash00, CPJ05 preface] were craftier than this, and combined DHTML with a communication channel to avoid the prepopulation of data. However, without a catchy name, targeted publication to professionals, and popu- lar applications to capture the audience, these solutions did not reach the fame of Ajax.
  19. 19. 14 2.3.2 Delayed Inclusion The technique of delayed inclusion is similar to many other patterns that achieve reduc- tions in the initial loading time of the web application [Aja07a]. These resemblances stem from the same basic assumption: not all users will employ every service available. A classic example is a web forum were users might read posts anonymously, eventually register to the service, and then post messages themselves. If the forum is popular, it is reasonable to assume that the majority of users will mostly read and occasionally post. Therefore, it is inefficient to force every user to download the program code required for posting functionality. Different patterns solve this problem by varying the exact mo- ment the additional functionality is downloaded by the user. The common factor behind all these patterns is the fact that when new JavaScript files are loaded by a browser, their contents are immediately evaluated. This means that the additional JavaScript runs within the context of the current page. By defining a script element to load a file from the server upon receiving a suitable event, the developer may control which file is loaded and when it is loaded. This event may be triggered by a cli- ent-side timer [Lun02] to achieve periodical refreshing of content. It is a small task to parse the parameters of the request at the server side and generate client-specific con- tent, if necessary. Further, the communication is not limited to the same server that supplied the original page – any accessible URL will do. This seemingly minor feature bypasses the “same domain” -limitation of the XHR, which is revisited in Section 6.1. Overall, the technique of delayed inclusions is very compatible with the vast majority of browsers. Therefore, it is helpful in several situations where it is beneficial to let the server perform parts of the computation. From the client's perspective, responding in JavaScript offloads the burden of parsing the response. Finally, delayed loading is not strictly limited to JavaScript. For example, image loading may be fine tuned in order to present input queries as early as possible, or to smooth transitions from one page to an- other [Alm07]. 2.3.3 Hidden IFrame The name IFrame stands for ”inline frames”, paying tribute to its predecessor, HTML frames. The major difference between the two is that while IFrames embed the specified page within the current document, frames split the browser window into multiple pages [RHJ99, ch. 16]. Frames and their correct use became a hotly debated topic because
  20. 20. 15 they could easily cause a number of user interface problems [Nie96]. Most notably, us- ing frames made the back button notoriously difficult to predict for the user. Designing with frames quickly became passé. IFrames have not met with the same explosive fame, but their success has turned into a more lasting kind. The hidden IFrame approach is one of the most widely adopted communication chan- nels for asynchronous communication. It enjoys browser support beginning from the fourth generation of browsers, i.e., those preceding support for the W3C DOM. It is rel- atively easy to understand, suffers from no restrictions on the source servers, and has been around since at least 2002 [Cos02]. Even before that, the same technique was pos- sible through the use of frames, with some visual differences. Despite all the praise, the hidden IFrame approach is essentially a hack, meaning that it employs an unintentional side effect of the way IFrames are loaded and displayed by most browsers. Hiding an IFrame involves specifying an invisible window element into the current document, and then loading a page into that element. When the page has fin- ished loading, its content may be parsed and passed back to the IFrame's parent, the current document. All this is achieved with a suitable scripting engine. The IFrame source is not limited to the original server, and the loading may be either caused by an event from a window element or by any script executing in the browser. IFrame has an additional forte. Targeting content with the hidden IFrame causes another side effect – the browser catches on what is happening. This means that the functional- ity of both the browser's history and back button are easily accessible to the IFrame approach. The cost is an increase in memory usage relative to the amount of content loaded into the hidden IFrame. Essentially, the same content is loaded twice. As the IFrame element is trivially reusable, this cost seems low by many designers. 2.3.4 Comet and HTTP Pipelining Common to all current communication channels based on HTTP is that transmissions are always initiated by the client. Clients imitate push behavior by relying on events triggering requests for updates from the server. By choosing event timers or update con- ditions intelligently, this approach may be quite adequate for the task at hand. Still, some of the responses might indicate that no new changes have been made. The most efficient communication method is to avoid these unnecessary requests altogether. Lo- gically, this happens when the server can tell the client to update its content. This can be
  21. 21. 16 specially desirable in conditions where each message has a resource cost, be that in bat- tery time or financial units. HTTP Streaming [Aja07b], also known as “Comet” [Rus06], is a technique designed to remedy the restriction of one-sided connect initiation. Comet extends HTTP [Rus07a] by allowing the server to truly push content to its clients. It works by letting the server keep the TCP connection open, sending delayed responses to the original request. In this manner, the original synchronization request serves as a client registration, giving the server permission to push all changes from that point onwards. Except for this initiator identity, Comet has a resemblance to pipelining, introduced in version 1.1 of the HTTP specification [Fie99]. With pipelining, the client is able to send multiple requests through a single TCP connection. Both of these techniques help the client to avoid mak- ing spurious TCP connections, which can be costly in high-latency environments [LaH03]. With Comet, the responses just take a little longer to arrive. Pipelining is an old extension, while Comet is quite new. Their problems resemble each other, however. Current browsers seem to contain lenient settings for server timeouts [Bur07, Car07], so employing Comet requires only added server-side support. HTTP pipelining requires support from the client as well, and its deployment is patchy at best. The most recent Microsoft Internet Explorer is version 7, and it still does not support pipelining. Mozilla Firefox has featured support for a while, but it is disabled by default. The reason for this is the need for heuristic tests for pipelining support on the HTTP server. Such support can be still seen as experimental, as there are many alternative servers and their development is volatile. Notably, Opera currently features an heuristic test for pipelining support, and thus installs with pipelining enabled. The interest for Comet seems to be increasing [Arc07, IBM07, Kne06], which makes it conceivable that Comet might become better supported than its predecessor. In environ- ments where Comet is supported, it may be incorporated with both the IFrame approach and the standard XMLHttpRequest communication method [Gul07]. But even with the browsers that support pipelining and/or Comet, there are problems with combining the technique with multiple windows. As tabbed browsing has become popular, persistent connections make it easy [Rus07b] to hit the roof of maximum two concurrent connec- tions to each server in the HTTP specification [Fie99, Section 8.1.4]. One simple fix is to direct the persistent connections to a host name dedicated for this purpose. Another problematic area is the need for support in HTTP proxies, which are still popu-
  22. 22. 17 lar due to their lowering effect on bandwidth consumption [Dav07]. Moreover, some mobile browsers employ proxies for content transcoding, e.g., reducing picture resolu- tion to match screen size [Law01, Leh06]. Leaving the TCP connection open would require features similar to Network Address Translation (NAT) from the proxies, essen- tially keeping tabs on each and every client requiring support for persistent connections. 2.3.5 Flash and Java Adobe Flash [Ado07b] is a browser plugin that excels in vector-based graphics, anima- tion and sound. It is commonly used on web sites that rely heavily on multimedia. Typically, Flash is adopted by games and movie advertisement services. Despite its pro- prietary origin, Flash has reached an unparalleled level of deployment. Plugins exist for each major combination of operating system and browser. Flash enables partial redraws and asynchronous communication, among a host of other features. Albeit this overlap, Flash and Ajax are not strictly competitors. Popular sites like YouTube [You07] have demonstrated how the two techniques' separate strengths may be successfully combined. YouTube employs Ajax for the its interface and switches over to Flash for the video content. With the release of Java Web Start [Sri01], the runtime environment required by Java may be bundled together with the application itself. Java Web Start is a step away from the applet paradigm, and it has been criticized because of its loose integration with web content [Rob07]. In the field of mobile devices, Java has typically been supported through the use of the Mobile Information Device Profile (MIDP) [Sun07]. The major problem is that different platforms have small but relevant disparities concerning the ac- tual implementation of many interfaces in the Java API [Jao06]. These disparities have typically required extensive testing to ensure that the cross-platform program truly works on all devices. The magnitude of testing required has proven to become an in- centive for designers to look into other possibilities. Here, Ajax enters into the mobile device scene. 3 Measuring Mobile Devices For the first time ever, users are voluntarily downgrading to browsers with fewer fea- tures than the earlier generation. These mobile browsers feature less display area, less processing power, lower network bandwidth but increased latency, and the completely
  23. 23. 18 new factor of a limited battery lifetime. Simultaneously, the use of techniques like Ajax involve browser capabilities that have only become common enough during the past few years. It seems questionable if the mobile devices can actually support Ajax in the needed capacity. And indeed, it is correct to question this, since many devices can not. As astute reading may have revealed, the selected statistic of 80 million devices manu- factured in 2006 [IDC07] is limited into a subset of all the mobile devices shipped. This subset is called the converged mobile devices, and it is loosely defined as the set of devices that combine features from mobile phones, personal digital assistants (PDA), cameras, tablet computers, and other electronic aids. Here, converging means merging multiple separate units into a single, more intelligent device. The selection is limited to this subgroup because the majority of the devices sold last year, the more old-fashioned ones, are still incapable of supporting all the component technologies of Ajax. 3.1 Capability and Performance On the other side of the spectrum, the smallest laptop computers have reached form factors almost comparable to mobile phones of yesteryear. While testing laptops run- ning the same browsers and operating systems as their desktop brethren would probably be indicative of variations in network properties, in this thesis the focus is on the hand- held category of devices. More specifically, the tests concentrate on the browser performance of the least capable hardware platforms that still are able to support Ajax. It is important to realize that because of the selection criteria, the constrained browsers also feature lessened levels of software capability than their desktop versions. Browsers are separated into a graphical user interface (GUI), sometimes titled the chrome, and the background engine, which handles the interpretation and execution of the content passed to it. While the browser's GUI shares its name with the fully-functional version, some features may have been removed from the constrained engine. These lacking fea- tures may greatly benefit rendering performance, as unsupported program code is simply ignored. The fastest browser is the one that constantly displays a blank page. Therefore, it is important to not only measure the performance of the constrained browsers, but also to evaluate how well the browsers are doing the work they are sup- posed to. This calls for a combined analysis of both the quantitative and qualitative properties of each browser. Combined with the results of each measurement is an over- all grade (see Section 3.3.1) of the the tested browser. Comparisons between browsers
  24. 24. 19 with a different overall grade are sternly discouraged – they should only be performed by the most informed readers, e.g., the browser developers. The selected devices are presented as educated guesses of what the “long tail” of mobile devices might be like in the near future. At the time of writing, the devices are clearly in the enthusiast-level of the market, with local price tags ranging from 320 € to 640 €. Preceding a more thorough description, we present a short motivation for using Ajax in mobile devices, followed by the research questions that these measurements seek to an- swer. 3.2 Motivation for Mobile Ajax Four easily identified benefits with the use of Ajax are user input speed [Nok06], lesser display processing requirements, smaller amounts of transferred data [Whi05], and bet- ter compatibility between devices [ByH07]. These benefits are not unique to mobile Ajax, but their rewards are relatively greater when there is less processing power and bandwidth available. First, writing text on a handheld device is categorically slow. The reason for this is that lugging a 102-key keyboard around is uncomfortable for most of us. Handheld devices employ smaller input methods: both reduced alphanumerical pads and stylus-based vir- tual keyboards are well known by now. Predictive text input has become the proverbial helper wheel. With Ajax, prediction may be performed twice – once on the device, then once more using a more application-specific vocabulary on the server. The trade-off is doing a (costly) network call, which should finish faster than the user can enter text. Second, using the partial redraws customary for Ajax applications allows the mobile user browser to avoid full page redraws, sparing processing power, and thus, battery life. The user experience is simultaneously enhanced, since on slower devices, the white-out between complete redraws is visible for a longer period of time. Third, when delays are considered, newer wireless techniques like EDGE and UMTS are categorically high-bandwidth but also high-latency. Returning responses in a verb- ose format like XML may remain feasible, but XML may also be replaced with JSON or basic HTML. When compared with a complete page transfer, communicating only partial changes reduces the amount of transferred data [SmS07]. If both the browser and the server support pipelining, even the relative overhead of performing the triple TCP handshake is reduced.
  25. 25. 20 Fourth, using the mobile browser as a programming platform offers an additional level of middleware for application developers. Instead of having to port each application to every mobile operating system, the effort can be directed towards making the browsers more compatible. While current browsers are restricted by a security sandbox prevent- ing access to much of the device's services, e.g., audio, contacts, and GPS, crossover Java/JavaScript libraries are a suggested remedy. At least one such project has begun development [ByH07]. Ajax functionality by itself might be improved by using toolkits specifically designed for mobile devices [Geo07a]. 3.3 Research Questions and Methodology Better than the previous motivation for mobile Ajax, the sheer number of devices avail- able makes the time seem ripe for a performance measurement of mobile browsers. While surveying the field of mobile devices, it quickly becomes clear that there are already several browsers available for most platforms. A newer development is the on- set of small web-enabled applications or widgets [Geo07b], which offer more narrowly defined functionality than browsers. Collectively, these mobile user agents reuse com- ponents from each other and desktop browsers. It is therefore interesting to see how the components perform on the much more constrained properties of a mobile device. Wilton-Jones has performed meticulous application measurements for a suite of desktop browsers [W-J07e], noting significant variance between different browser/platform combinations. Further, he has duly noted that browser differences make some measure- ment techniques unreliable [W-J07d]. For example, using JavaScript to measure JavaScript may yield inconsistent results due to a different ordering of processing and presentation phases among the compared browsers. Following the emphasis on practical testing set by Lilja [Lil00], the measurements in this thesis try to avoid synthetic benchmarks. The benchmarked hardware units are com- mercial, off-the shelf (COTS) products, not samples or development units. No modifications have been made to the hardware or their user agents, unless explicitly specified otherwise. The exceptions to this rule are some cache settings, explained in detail with the browser descriptions. All of the device measurements were run without an attached charger to accommodate for power-saving features. Since Ajax employs so many of the available technologies, the newer Ajax applications offer a diverse real-world test suite for browser performance. In addition, the number of
  26. 26. 21 development projects is impressive. Since an important reason behind the ubiquity of the World Wide Web is audience participation, a selection of development libraries are included in the measurements. The rationale is that for Ajax to become successful, the users must have tools that mask browser differences. At the same time, the libraries must attract users. Therefore, the benchmarks target twelve sample applications pro- moted by the developers as showcase examples on what Ajax is capable of. 3.3.1 Grading and Results Before the performance measurements, the applications are first tested for capability is- sues on the selected browser. All defects are noted and explained in the corresponding analyses. Each browser is given a grade on the scale from A to D, explained as follows. ● A represents the highest possible grade, with no defects detected during use. ● B represents minor problems with the layout, or missing functionality. ● C represents major problems that clearly are a hindrance to the user. ● D represents a failure in the workflow, meaning that the user does not receive the requested service from the application Note that application speed is considered subjective, and is not factored in the grade, but may be noted in the analysis (when relevant). This grading is separate from the actual time taken to load an application, which is presented by the later graphs. 3.3.2 Measurement Method After possible defects have been determined, the application is measured using ten itera- tions of the initial loading time or time taken to perform a selected function. The results reflect user-perceived wall clock time, measured using a stopwatch. Although this meth- od limits the precision to 1/10 of a second at best, it is fully adequate to represent human reaction time [Kal04]. Results are separated into cached and cache-cleared categories to calculate an approx- imation of the upper and lower bound of the (perceived) delay. Cached measurements try to indicate the best case, i.e., the one where most parts of the application are already loaded. Conversely, the cache-cleared measurements try to indicate the worst case, i.e., the one where no parts of the application are already loaded. Please note that the worst case still ignores the WLAN connection setup time, as explained below. Preliminary
  27. 27. 22 testing includes that the connection time may greatly vary, and indeed be vastly longer than the time taken to load an application. Additionally, some users may have trouble distinguishing these components of the overall delay. Because of the very mobile nature of said devices, performance measurements are tied to a multitude of real-world factors, the type of the network selected not being the least. It has been shown earlier that in slow networks, the transmission time easily dominates the overall wait time for a page load [LaH03]. In this thesis, I have tried to minimize the dominant factor of the transmission time and concentrate on the browser performance alone. In all of the following cases, the network connection type is WLAN, with the ac- cess point connected to a very high-bandwidth, low latency university network. All of the targets were accessed through a (very plain) XHTML link page so that the WLAN connection was set up during the first request, not the measured one. To reiterate: these measurements do not consider network connection properties. In the cache-cleared category, the disk (flash) cache is cleared between each test, using the functionality offered by the browser. To further minimize the effect of memory caches, on the N95 and N800 the browsers are measured by interleaving the tests. In other words, in each iteration, browser A's cache is cleared, then browser A is meas- ured, and allowed to completely exit. Then browser B is executed, its cache is cleared, the measurement is performed, and B is allowed to exit. On the iPhone, memory caches were flushed by executing other applications between iterations, e.g., viewing photo slide shows, taking pictures with the camera, or browsing the calendar. Many of the details in the measurements have been omitted in the written text by neces- sity. All of the raw data gathered, along with the notes taken during the measurements, have been included in the appendix. In the electronic version of the appendix, the benchmarked values are recorded with the precision measured. The values are normally presented with single decimal precision. The following browsers have passed initial testing of their basic Ajax functionality. This means that using short example programs, the browsers have been verified to support the component technologies of Ajax. 3.4 Nokia N800 Internet Tablet The Nokia N800 Internet Tablet (N800) [Nok07c] is the oldest device of the three, hav- ing been released in January 2007. An important first observation is that the device is
  28. 28. 23 not a mobile phone – it lacks any and all functionality required to connect to a carrier network. Despite this drawback, the N800 includes a host of internet-related features that make it fit into the category of converged mobile devices. To mention a few, the device supports multiple web browsers, can run its own web server, and offers the pos- sibility to use both Skype [Sky07] and Google Talk [Goo07a] for voice-over-IP calls. Mapping services are available through the maemo mapper project. In order to use the Global Positioning System (GPS), a separate GPS receiver must be connected. As of writing, the current operating system is titled the “Internet Tablet OS 2007” (OS- 2007). The tested version was 4.2007.26-8. Most notably, it is based on the open sourced components GNU/Linux and GNOME [Jaa06, Mae07]. The OS2007 contains its own package manager, allowing the device to connect to multiple repositories in or- der to fetch updates and community-developed software. N800's input method is based on a touch screen, either through a virtual keyboard or handwriting recognition. The display size is 4.2 inches, 800x480 pixels with a color depth of 65536 colors. The device has 128 MB of RAM. Storage capacity consists of 128 MB of permanent flash space, plus the possibility to insert two removable flash memory cards, maximum size 2 GB each. The RAM memory may then be extended with virtual memory on the removable flash card. With a total storage area of over 4 GB, the N800 provides ample space for caching purposes. As the measurements do not concern applications with huge cache requirements, only a single 2 GB flash card was used. The maximum virtual memory of 128 MB was exten- ded through the device's control panel. All system sounds were silenced, which may have benefited battery life. We feel that this decision has not corrupted the results, since turning off the system sounds seems to be normal behavior for observed N800 users. Display brightness and volume level were otherwise left on default levels. Additionally, a Google Talk account was entered into the presence settings, and four speed contacts were configured. This is not a synthetic decision, as these are the actual settings for everyday use. 3.4.1 Opera For the OS2007, the default browser is based on Opera's version 8. Its code base is closed and strongly related to the commercial desktop browsers developed by the com- pany. Opera users are normally forced to purchase a license after a trial period. On the
  29. 29. 24 N800, the Opera browser is part of the purchase fee, and therefore licensed by Nokia. The relevant application packages for the Opera browser were osso-browser-opera-dy- namic, version 2.0.43-1, and osso-browser-opera-eal, version 2:1.6.8-1. No application updates were downloaded during the testing period. From the browser settings menu, the memory cache size was extended to 4096 KB, the maximum value selectable. 3.4.2 Mozilla based browser for maemo Thanks to OS2007's engine abstraction layer (EAL), multiple browser engines may be used through the same user interface. The Mozilla-based browser for Maemo4 was re- leased in July 2007 for the general public [Kin07]. The browser claims no shorter official title so, in this work, it is henceforth referred to by its package name “microb”. The installed version of the package microb-browser was 0.0.8-3. By editing the file /home/user/.browser and changing the value of “hidden” to “true” [sic], the browser menu was extended to contain a “Set engine” option. This option made switching between browsers notably easier. The upcoming newer internet tablet, N810, will be released with the 2008 version of the operating system. Nokia has announced that OS2008 will ship with Mozilla engine en- abled by default [Nok07a]. The OS2008 will also be available for the N800 since both contain the same CPU and memory hardware. However, the new version was not re- leased in time to be included in these measurements. 3.4.3 GTK+ WebCore A third browser engine based on the GTK+/WebKit [Kin06] code base has been in de- velopment since at least August 2007 [Tok07, Wri07]. It is perhaps best known for its (promised) SVG [FFJ03] support. There was an incentive to include the browser in the measurements due to the shared code base with the Safari browser described further on. While the project was briefly reviewed, installation candidates were not yet available to the general public. Therefore, the browser was left out. This decision is based on the dual emphasis on currently available technology and the repeatability of the measure- ments. 4 Not to be confused with the “Minimo” or “Moblin” projects, also based upon Mozilla's Gecko engine.
  30. 30. 25 3.5 N95 The Nokia N95 is a “true” converged mobile device in the sense that it is no longer mar- keted as a mobile phone, but as a multimedia computer. It began shipping in March 2007, which places it between the two other devices. The N95 features an internal GPS receiver, enhanced support for video playback, and a 5 megapixel (2592x1944 pixels) camera. The display size is 2.6 inches, 240x320 pixels, and capable of displaying 16 million colors. Notably the display size is much smaller than on the other two devices. Browsing input is handled by a 12-button numerical/lettered keypad plus a four-way navigation button, with the selector in its middle. Additional buttons do exist, but they are reserved for menus and as shortcuts to the device's camera and multimedia applica- tions. The operating system is the Symbian Series 60 (S60) 3rd edition with feature pack 1 [S6007]. Firmware version was 12.0.013 (19-06-07). Due to its widespread nature, there are plenty of mobile browsers available for this platform. In addition to full browsers, Nokia has begun promoting the development of lightweight internet applications or widgets [Geo07b]. For example, the N95 ships with support for multiple image-sharing web sites. The photo application may be configured to transmit pictures directly to these services through HTTP. For the context of this work, the decision was made to concentrate the measurements on just a select few of the available user agents. The rationale is that this should improve the level of detail possible, as every browser multiplies the number of observations re- quired. Therefore, in addition to the S60 web browser, the only other user agent is the Opera Mobile browser. The selection is based on the browsers available for the N800. A functional SIM card was inserted in the N95 to accommodate for processing power required to keep the phone subsystem operational. No other background applications were left running. The local carrier network supports 3G/UMTS [UMT07] and its signal strength was displayed as the maximum possible. The screen saver was set to activate after 45 seconds, whereas the backlight timeout was 30 seconds. The light sensitivity detector was left at its default middle position. Key click sounds were disabled. Wire- less LAN scanning was left inactive, and the Bluetooth [Blu07] interface was kept disabled.
  31. 31. 26 3.5.1 Nokia Mini Map Browser The default browser for the S60 operating system is simply titled the “Web Browser for S60” or sometimes the “S60 Web Browser”. In this work, the latter form is used in its abbreviated form (S60WB). The S60WB is based on the WebKit [Web07a] project, which has been open sourced by Apple. To extend the project, modifications made by Nokia are passed back to the community in the form of the S60WebKit branch [Nok07b]. WebKit's WebCore and JavaScriptCore components in turn derive from the Konqueror browser's KHTML and KJS components, also released as open source. Despite these similarities in their background and naming, it is worth remembering that the browsers are continuously and aggressively developed. S60WebKit forked from WebKit already in 2005. As we shall see, in practice their interpretations do differ quite significantly. Like all other browsers selected in the benchmark, the S60WB includes zooming func- tions designed for applications using fixed layouts. Due to the “limited” display size on the N95, the zooming function was very helpful. In addition, the N95 also features the ability to turn the display into landscape mode by rotating it 90º counter-clockwise. However, in these measurements, the S60WB was run in its default portrait mode, with the full screen option inactive. 3.5.2 Opera Mobile For the S60 operating system, there are two different Opera browsers available [Ope07a]. Opera Mini depends on a server-based proxy and is aimed towards less cap- able devices [Dav07]. The browser engine is split between the proxy and the browser, allowing the browser to offload processor intensive tasks. Unfortunately, this system does not support Ajax. Opera Mini was therefore not an option. The other Opera browser is titled Opera Mobile, and the N95 supports its newer S60 3.x version 8.65. It is referred to as the “S60OM” in this thesis. The installed build number was 9730. All of the measurements were run during the 30-day trial offered by the com- pany. From the settings, cache size was set to “large” and render mode to “quality”. Opera Mobile contains a feature that rewrites web pages into a single column mode for easier viewing on a constrained display size. This “fit to screen” function was disabled. Finally, for easier access, Opera was added to the list of applications available from the N95's active standby mode, i.e., the device's main screen.
  32. 32. 27 3.6 iPhone The Apple iPhone [App07a] is far from the first mobile device developed by the manu- facturer, but it is the first with the ability to connect to a carrier network. The operating system is a variant of OSX, developed by Apple and only available on the iPhone. The system is heavily targeted towards web-enabled widgets. Several of the included applic- ations use HTTP to fetch data, e.g., YouTube, Stocks and Weather. The device also contains a two megapixel camera and enhanced media player functionality. Display size on the iPhone is 3.5 inches, with a resolution of 320x480 pixels (163 pixels per inch). Input is handled by a finger-operated multi-touch screen, with three special buttons for locking the device, accessing the main menu, and disabling the ringer. This unit had a storage size of 4 GB but no selectable options for the cache size. Keyboard clicks were turned off during testing. As of writing, the iPhone has not yet been released in Europe. The device used in these measurements is from the American batch, with the firmware version 1.0.2 (1C28). Due to the fact that the American models are currently locked to only operate with SIM cards from AT&T, there is no carrier network available for the device in Finland. There- fore, the measurements were performed without the phone function operational. This may have skewed the results somewhat, but the magnitude should be lost within the greater one caused by human reaction time. 3.6.1 Safari Safari is the only browser currently available for the iPhone. As mentioned earlier, Sa- fari has been developed from the open sourced components in the WebKit project. It is therefore interesting to see how it compares with the S60WB on the N95. The iPhone's operating system, OSX, also features a landscape mode usable by some applications, Safari being one of them. The view can be activated simply by rotating the device to its side. To maintain compatibility with the results on the N95, and avoid mul- tiplying the amount of observations by having to go through all the combinations, the iPhone was also kept in its portrait mode.
  33. 33. 28 4 Libraries, Toolkits, and Frameworks As briefly introduced in Chapter 1, the major problem with current web design is browser fragmentation. This deviation routinely forces designers to acknowledge the in- dividual perks of the different browsers and to find ways to circumvent these issues. In the practical field, much kudos is given out to designers who can invent the cleverest workarounds for existing problems. Ideally, these helpers will only be used until the rel- evant cause has been fixed in an upcoming browser release, and that release has become sufficiently widespread among the users. Before proceeding into the field of Ajax development, another naming problem must be solved. The names of these “Ajax helpers” have split into three categories. The projects presented in this chapter are described alternatively as libraries, toolkits, or frameworks [Pay07]. For this thesis, the following definitions are adapted. 1. A library is a collection of one or more functions, aimed for reuse, and relating to a specific task. Examples of this are the browser detection technique incorpor- ated in XHR object creation, as well as DOM calls for finding a specific element by its identifier. 2. A toolkit is a collection of one or more libraries related to a specific set of tasks, designed to follow a common programming style. A toolkit may customize its selection of libraries, possibly obfuscating or compressing the code contained. 3. A framework is a collection of libraries and toolkits. Using a framework lends structure to the developed project, possibly forcing the project to adapt one or more preselected design patterns, e.g., MVC. Following this definition and the preceding example of Anttila [Ant07], the projects de- scribed in this section are titled toolkits. Google Gears, which is only briefly mentioned, may actually constitute a framework, but as the definition is inclusive, this level of im- precision can be accepted. Note that many of the developers will probably continue to call their projects as frameworks, conceivably due to the more “official” impression of the title. This is acceptable, because splitting the application into separate files can be loosely categorized as a structural decision (see Section 2.2). In addition to the defined categories, toolkits may be classified according to their style of programming and intended purpose. Different toolkits have been designed to work
  34. 34. 29 with specific server-side programming languages and environments, and some have ad- apted their counterpart's style into the client-side as well [Web06]. Regarding intended purpose, there has been a trend to develop separate projects aimed for “pure” animation and graphics display. Two of the toolkits presented are designed specifically for visual effects, the rest also incorporate methods for the selection and manipulation of events, XHR, and the W3C DOM. 4.1 Graphics display DHTML techniques have not been forgotten with the onset of Ajax. On the contrary, visualizations developed earlier with the help of browser-centric document object mod- els and other incompatible interface calls are now being reinvented into more standards- compliant versions of themselves [Sco06b]. In this chapter, the toolkits script.aculo.us and moo.fx are briefly presented. They are both visual toolkits and require support from a secondary toolkit to function. The sup- porting toolkits are usually Prototype and MooTools, although other choices may be adapted. Complementing the supporting toolkit seems to be a popular decision, since script.aculo.us and moo.fx show up regularly in Ajax-related tutorials and introductions. Splitting the functionality into two different projects may also better maintain the devel- opment focus on the selected task, i.e., employ visual-minded and more algorithm- oriented developers separately. 4.2 Selection and Manipulation Without exaggerating, it can be said that events are the heart of any Ajax application. Writing listeners and handlers for the many event types implemented by modern browsers allows the designer to truly adapt the static documents into functional models with many, if not all, of the workings of desktop applications. But event implementa- tions do vary, and it is unrealistic to expect all designers to be intimately knowledgeable of all browsers and their differences. Therefore, most Ajax toolkits involve easily accessed functions for the selection and manipulation of events and the W3C DOM. These functions mask browser differences and abstract interface calls, perhaps adding a programming style. Toolkit selection may very well be based on the style, allowing the designer to more easily fit in through pre- ceding knowledge of a programming language other than JavaScript.
  35. 35. 30 Of the toolkits presented, script.aculo.us and prototype have been developed along the Ruby on Rails framework [Han07]. Naturally, they borrow idioms from Ruby, even though the toolkits can be used outside of the framework. Google Web Toolkit (GWT) is designed work as an Java to JavaScript gateway – the programmer writes Java and GWT translates the code to JavaScript for the browser. Java is popular with the de- velopers of Direct Web Remoting (DWR) as well. Microsoft's ASP.NET AJAX follows their own ASP.NET framework closely. Not all of the toolkits may be easily categorized by their likeness to an existing lan- guage other than JavaScript. Some projects have chosen their own programming style or have decided to be true to JavaScript itself. Strongly related to the reuse of JavaScript are Widgets, programs that borrow functionality from the installed browser. 4.3 Widgets When discussing Ajax, “widgets” may refer to at least two separate concepts. First, wid- gets can be taken to mean semi-independent software modules that can be included in larger web applications. These web widgets are commonly developed as parts of the toolkit projects and may require parts of the toolkit to function correctly. Examples are date pickers, rich text editors, and time line visualizers [SIM07, Mar07]. Secondly, wid- gets can be understood as lightweight browsers, limited into a single application or a set of similar applications. The widget applications have already appeared on the desktops of modern operating systems, and they are now beginning to get ported into mobile plat- forms5 [Nok07d, App07b]. Examples of widget applications are Really Simple Syndication (RSS) feed readers [RSS07], weather notifiers, and exchange rate monitors. In mobile devices, widgets can work as a gateway between the functions offered by the device itself and web applications [Gra07a]. Widgets can thus benefit from the browser libraries, e.g., (X)HTML/XML parsers, JavaScript interpreters, and security models. Simultaneously, as the widget exists outside of the strict browser sandbox, it may access converged subsystems unavailable from the sandbox. Such subsystems may include GPS reception, contacts and calendar items, and SMS messages. 4.4 A Look into the Most Popular Toolkits Two years is a long time in web development. During the two years of fame that Ajax 5 Apple markets iPhone widgets as “Web Apps”, whereas Nokia has coined the name “WidSets”.
  36. 36. 31 has enjoyed, the number of web sites employing Ajax has grown explosively. Concur- rently with the rapid web design, several toolkits have been released as open source in order to benefit others in their work. The wiki site Ajax Patterns [Aja07c] maintains a combined effort to list all of the toolkits. The list has grown to over 200 alternatives. Browsing through the list, it is easy to notice that many toolkit projects have already been closed or abandoned. This is possibly in favor of the more complete alternatives or just due to lack of time, interest, or both. It would seem possible that other projects will follow, so that the palette will converge to a few toolkits with different strengths and weaknesses. Ajaxian6, a web site dedicated to Ajax development in general, has per- formed yearly polls on its readers to find out which toolkits are most commonly used [Alm05, Gal06, Gal07a]. The results show some support for the theory of convergence. On the other hand, 15 years of web development have not been enough to overcome browser fragmentation. There is a chance that the toolkits will not fare any better. 2005 2006 2007 Prototype 23,1% 43,1% 68,4% script.aculo.us 17,7% 32,9% 58,7% jQuery 7,2% 47,5% YUI 5,0% 40,3% Dojo 10,2% 18,7% 38,3% Ext JS 33,8% Google Gears 22,0% GWT 3,4% 17,2% DWR 11,0% 11,6% 12,7% MooTools 11,3% moo.fx 11,0% ASP.NET AJAX 8,3% 4,4% total votes 763 865 826 Table 1: Ajaxian.com reader surveys 2005-2007. The toolkits measured in this chapter have been selected on the basis of their survey representation. Table 1 shows the ten most popular toolkits, along with their historical figures from the previous two surveys. Most of the toolkits reviewed in this thesis were not yet included in the October 2005 survey [Alm05]. 40,0% of the voters proclaimed that they were not using a toolkit at all, but were developing “directly” with XHR. It is conceivable that both home brewed libraries and not yet released projects have been in- 6 http://www.ajaxian.com/
  37. 37. 32 cluded in this statistic. The early fragmentation can be clearly observed in the results, as many toolkits have been voted less than ten times. Interestingly, Ajax was proclaimed to be in production use as often as in development, with 31,2% and 32,8% of the votes. By September 2006 [Gal06], the situation had changed somewhat. 25% of the voters were still using XHR directly. The amount of production and development use was still balanced at 61,7% and 67,2%. This would seem to underscore the continuous develop- ment cycle of web applications. Prototype and its sibling script.aculo.us had already taken a clear lead over the other toolkits. The latest results are from October 2007 [Gal07a]. Production and development are still in balance, with 81,2% and 79,3% of the votes. It would seem that the convergence con- tinues towards a small number of popular toolkits. Prototype and script.aculo.us keep their top positions, but the gap between them and the next rankings have narrowed con- siderably. There are still a great number of toolkits with only a few votes each. Please note that the unintentional omission of the toolkit MooTools [Gal07b] may have thor- oughly skewed the results for this choice. The percentage shown is gathered from user- entered free text inputs, i.e., the “other” category. In addition to the most popular choices, this chapter contains reviews of the Frost and ASP.NET AJAX toolkits. Frost is an upcoming project dedicated on Mobile Ajax, de- veloped by Rocco Georgi of PavingWays. Georgi is one of the authors of the Mobile Ajax FAQ [JGR07]. ASP.NET AJAX is Microsoft's product, which may explain why it is poorly represented by Ajaxian's user base. 4.4.1 How to Read the Results For those readers that already know the background information and have skipped straight to this section: it is strongly recommended to read Section 3.3.1 concerning the capability grading before trying to interpret the following visualizations. Due to space constraints, the graphs include information for all browsers, although their presentations differ significantly. The capability grades are listed in the legends next to both graphs. The graphs are presented as pairs of cached and cache-cleared measurements. In each measurement, the X-axis shows the 10 sequential measurement iterations. Each Y-axis shows time in seconds. Measured results are marked by the icons presented in the le- gend, and plotted lines are added to enhance visibility. The legend also lists the grades given to the browsers during each evaluation. As outlined in Section 3.1, these grades
  38. 38. 33 are the key element of an unbiased comparison between the measured loading times. If the grades are ignored, the charts can be easily misread. This is a known limitation of the chosen presentation format. 4.4.2 Prototype The Prototype project [PCT07] was created in February 2005 by Sam Stephenson, and it has been well noted in both literature and web sites. Prototype is possibly best known for its terse writing style, as it uses only single characters for some function calls. Much work has been done to improve upon the project's initially criticized level of document- ation. The web site now contains both an API description and tutorials. Cached results Cleared results 21,0 21,0 seconds seconds 18,0 18,0 15,0 15,0 N95 / S60WB (B) N95 / Opera 12,0 12,0 Mobile (D) N800 / microb (B) 9,0 9,0 N800 / opera (B) iPhone (B) 6,0 6,0 3,0 3,0 0,0 0,0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 iteration iteration Figure 1: Prototype PWC-OS demo application, http://prototype-window.xilinus.com/. In contrast to many of the other toolkits, Prototype offers no demo applications on their web site. This disputable lack is balanced by the featured list of production web sites us- ing Prototype. The target for this Prototype test is a “virtual desktop” application, which shows how content may be separated into windows and manipulated in the browser user interface [Gru07]. The PWC-OS sample is prominently a more complex demo, included herein to seek at least some of the limitations of the mobile browsers. As it is the very first measurement, it also serves as a yard stick on what may be attempted in the follow- ing cases. The S60WB shows a respectable level of capability while presenting the virtual

×