Mobile Web Applications
- , ,
Abstract
Web applications, often referred to as AJAX, are increasing in number and capabilities. Application developers now routinely target the Web instead of operating systems. A core set of Web Standards – HTML, CSS, JavaScript and DOM -- form the foundation for most Web applications.
One guiding principle of the Web is that there is only one; the same Web standards and the same Web content should be usable on all Web devices. As such, Web applications are challenging for mobile devices. For example, they often demand certain screen sizes.
This paper discusses how web applications relate to other web content. The notion of "dynamicity" is introduced to measure how dynamic the content is. Finally, web applications for mobile devices are described.
Introduction
On the web, AJAX is the acronym of the year. While the name itself is problematic, the fact that developers how routinely write applications for the web and not specific operating systems is a significant change, one that will increase the extent and importance of web standards in many ways. At Opera, we are especially interested in mobile devices. This paper will discuss how AJAX can be used in mobile devices, both for downloadable and resident applications. Before doing so, however, we will discuss the AJAX acronym and what we mean by a web application.
The AJAX acronym
The AJAX acronym was introduced by Jesse James Garrett in a blog entry February 2005. As has been explained by many, it stands for “Asynchonous JavaScript and XML”. The term quickly caught on and is currently one of the most used buzzwords of the web; Opera's marketing department has learnt to use it and XTech 2006 has an “AJAX” day.
The introduction of the term AJAX coincided with the deployment of advanced web applications. For example, Google's Gmail service used client-side JavaScript that communicated asynchronously with the server. For the discerning user, these applications offered functionality and usability at a new level. As such, a new term to describe them were warranted and AJAX is the term of choice.
However, from a technical angle the term is problematic. Let's go through it, letter by letter.
A for Asynchronous: while many advanced web applications communicate asynchronously with the server, not all applications will have this need. As such, this feature isn't worthy of the first letter of the acronym.
J for Javascript: web applications are written in JavaScript and the "J" is therefore well-deserved.
A: the "A" may be regarded as an extra vowel to make the acronym pronounceable, as the second letter in "JavaScript", or as the first letter in "and". Either way, it doesn't add any technical value.
X for XML: “XML” is possibly relevant in two different ways. First, the XML grammar may be used to encode the content (e.g., XHTML). However, the use of XML grammar is optional. Second, the “XMLHttpRequest” is the name of the object used for communication between client and server. Again, however, the use of XML is optional; more often than not, non-XML data crosses the wire between client and server.
AJAX applications are written using technologies that are not mentioned in the acronym, including:
HTML: All web applications are written in HTML, some in the XHTML dialect.
CSS: All web applications are styled in CSS.
DOM: The Document Object Model ties the components together.
In addition, some underlying technologies (e.g., image formats and network protocols) are required for web applications to work.
So, the “AJAX” acronym fails in two respects. First, the acronym is composed of technologies that are not essential to web applications (except JavaScript). Second, the acronym fails to mention technologies that are essential.
It is tempting to try to correct these problems by changing the spelling of the acronym while retaining the pronunciation. Below is a list of possible alternatives:
AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
AJACS: Asynchronous JavaScript and CSS
ADJACS: Asynchronous DOM, JavaScript and CSS
ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
(One benefit of ending the acronym with an "S" is that it can be allocated to SVG if SVG becomes a customary part of web applications. Alternatively, the "S" can be given to the "canvaS" element.)
Web documents vs. web applications
Traditionally, web content is referred to as “pages”. That is, web content started out as static content which only rarely changed once presented to the user. In the early browsers, one of the few exceptions were that links changed color when visited.
Today we discuss applications for the web. In theory, there is a significant difference between documents and applications; applications are written in Turing-complete programming languages while HTML is not a programming language. In practice, however, the web contains content in a continuous spectrum between static documents and dynamic applications. Understanding this spectrum is key to understanding web formats.
Web applications are often referred to as being “dynamic”, as opposed to static documents. (In fact, a third criticism of the “AJAX” acronym – in addition to the two above – is that it is merely a rewording of “Dynamic HTML” from 1997.) I believe it is important to establish ways to measure the degree of dynamism, or “dynamicity” as I call it in this paper.
The term "dynamicity" does not appear in the dictionary. It does, however, appear in several places on the web. One notable mention is quoted below:
Concerning the Word Dynamicity [...] I wanted a word that conveyed the notion of "dynamicness" (or the quality or state of being dynamic). Someone suggested dynamism, the technically correct term. But this didn't "feel" right to me, in some way I could not define or specify. [...] So I did a web search; and do you know what I found? I found more than two hundred uses of this word... and all of them were used in the sense in which I was instinctively using it. The overwhelming majority were in the context of programming languages.
–Hal E. Fulton
Therefore, it appears to be a need for the word “dynamicity”. Dynamicity, when used in the context of web content, expresses how dynamic the page or application appears to the user. I propose that dynamicity has tree main components for current web content:
Visual expressions: the rate at which pixels change on a screen. An early – and still widely used – form of visual dynamicity is animated GIF images. In CSS, the “text-docoration” property can make text blink and the “:hover” selector is used to change the style of content as the pointer moves from one element to the next. Also, JavaScript is routinely used to change values on CSS properties in order to dynamically change the appearance of content.
User interaction: the ability to react to, and foresee user requests. Building user interfaces was not the purpose of neither HTML nor CSS. However, in combination with JavaScript and DOM, quite sophisticated user interfaces can be built. When asynchronous communication is added, further advances can be made. For example, by dispatching to the server characters that a user types into an input field, the application may provide suggested completions.
Network communication: the amount and frequency of communication between server and client. The XMLHttpRequest object provides a way for web applications to communicate with a server. By fetching and display data from the network, the application will appear more dynamic.
In mobile environments, devices are constrained with regard to visual expressions (due to smaller screen sizes) and network communication (due to bandwidth, latency, and costs). Dynamic web applications must therefore be built slightly differently from desktop web application. The next section will explore how.
Mobile Web applications
One guiding principle of the Web is that there is only one; the same Web standards and the same Web content should be usable on all Web devices. Although web documents are often – and unfortunately – marked up for certain screen sizes, smart formatting technologies like Opera's Small-Screen Rendering has made it possible to present the content on small screens.
Web applications present a new set of challenges to mobile devices – along with one major opportunity. The opportunity is that a modern web browser, once installed on a mobile device, can be used for much more than just browsing. In fact, the whole user interface for the device can be built using web formats. See figure 1 and 2.


Figure 1 and 2 shows how a phone UI can be built using web standards.
There are also several challenges for web applications on mobile devices. First, the device must be capable of running a full-featured browser; a certain amount of memory and processing power must be available. A full-featured browser anno 2006 must support HTML, CSS, JavaScript, and DOM. Increasingly, mobile phones are able to run full-featured web browsers.
Second, web applications must be authored so that they run well in mobile environments. As discussed above, mobile devices are constrained in several ways that are important for web applications. Techniques have not yet been developed for web application authors to “write once, run everywhere”. For the moment that means that web applications must be developed specifically for mobile devices. If one accepts this premise, the range of applications that can be developed and deployed in current mobile phones is vast. Figure 3 and 4 show some examples.


Figure 3 and 4 show sample web applications running in a browser on a phone.
Both these applications fetch data from a server (images and weather information, respectively) and presents it to the user. In addition to the standardized HTML, CSS, JavaScript and DOM, some mobile-specific extensions are provided. For example, there is an API to query the battery level and the signal strength.
Conclusion
Web applications are here to stay and so is the term AJAX. While the acronym itself isn't technically accurate (we prefer to spell it AJACS) it still captures the zeitgeist of the web: the web is becoming an attractive target for application development.
The web is a generous place where there is room for both static documents, dynamic applications and everything in between. We also believe that all sorts of devices can and should become first-class citizens of the web.




