Вы находитесь на странице: 1из 6

An introduction to Widgets with particular emphasis on Mobile Widgets

Christian Kaar, BSc


Mobile Computing University of Applied Sciences, Hagenberg Softwarepark 11, 4232 Hagenberg, Austria

Technical Report Number 06/1/0455/009/02

October 2007

An introduction to Widgets with particular emphasis on Mobile Widgets


The demand for accessing information from the World Wide Web at any place and any time increases. Network enabled

mobile devices (e.g. mobile phones) provide that access via browsers. Though recent browsers are able to display most

of the web sites, they don’t provide a rich user experience.

A technologically similiar concept to browsers addresses this

problem: Mobile widgets. They provide an elegant way of delivering personalized web content and especially Web 2.0 services to mobile devices. This paper introduces the con- cept of widgets and general principles of widget develop- ment. The main section deals with the characteristics of mobile widgets and outlines differences to desktop widgets and traditional mobile appplication development platforms. Eventually a case study of porting Apple’s Dashboard wid- gets to Nokia’s S60 platform is presented.


Widgets are leightweight web applications which are de-

signed for a single specific function and quick instant access to Web 2.0 services or internet content. The World Wide Web Consortium (W3C) defines widgets as interactive sin- gle purpose applications for displaying and/or updating lo- cal data or data on the Web, packaged in a way to allow

a single download and installation on a user’s machine or

mobile device [17]. Typical examples of widgets are clocks, weather forecasters, news readers and photo albums. Widgets are developed using standard web technologies such as HTML, CSS, JavaScript and XML. These technolo- gies are exactly those which are incorporated in the AJAX development approach [4]. In this sense, widgets could be regarded as a kind of AJAX application. To put it another way, AJAX enables and encourages the creation of widgets [7, p. 96,99]. Widgets are executed within a special runtime environ- ment, commonly referred to as widget engine. Due to the similiarity between widgets and web pages, widget engines act like web browsers: Rendering HTML and CSS instruc-

tions, interpreting JavaScript code and handling user inter- action. In the last couple of years widgets emerged on the desktop

of personal computers and lately also on mobile devices, e.g.

mobile phones. Large players in the mobile phone industry, like Nokia and Apple, announced the support for widgets in their products. Gartner Research states that Nokia’s S60 Widgets will be an important mobile application delivery technology by 2009 [5].


Jaokar and Fish [7] present mobile widgets in the context

of Mobile Web 2.0 and the AJAX development approach. In

[6] Grassel describes widgets as one of three main use cases

for Web applications and AJAX. Jeon and Lee [8] support this thesis and state that mobile widgets are a potential use case of Mobile AJAX. Caceres [2] demonstrates how incompatibilities across wid- get engines affect different aspects of widget development. The W3C works on standardising widgets and client-side web applications [15, 16, 17]. Netvibes [10] develops a Universal Widget API (UWA) which enables the execution of widgets on different widget platforms.




Classification of Widgets

Widgets can be classified in three groups: Desktop wid- gets, web widgets and mobile widgets. Desktop and mobile widgets satisfy the requirements of the W3C definition. Web widgets however are reusable components of a web site which can be embedded in other web pages. They are not packaged and needn’t be downloaded and installed on a client. Desktop widgets attracted the attention of operating sys- tems vendors and therefore Microsoft and Apple integrated a widget engine in their latest products. Windows Vista introduced the Sidebar [9], where a user can keep gadgets 1 always available on the desktop. Apple’s pendant is called Dashboard [1] and is included in MacOS X. Other major vendors of widget engines are Yahoo! [18] and Opera [12]. Widgets needn’t necessarily serve web content but can also provide local data, e.g. a clock or a calculator. From this perspective widgets can be categorized by means of their function. Apple distinguishes three types [3]:

Accessory Widgets: don’t require support from an ap- plication or from the internet, e.g. clocks and calcula- tors.

Application Widgets: enhance an application by pro- viding a less complicated and often read-only interface, e.g. address book.

Information Widgets: work with data from the inter- net, e.g. news reader and stock tickers.

3.2 Widget Development

Due to the use of standard web technologies, the develop- ment of widgets is very similiar to traditional web develop- ment. The user interface is built by a combination of HTML, CSS and additional resources like images and sounds. In- stead of HTML some widget vendors (e.g. Yahoo!) intro- duced a proprietary XML format. The interactivity and event handling is achieved by ECMAScript (often referred

1 Microsoft’s term for widgets

as JavaScript). To retrieve data from a web server, wid- get engines support the XMLHttpRequest-object within EC- MAScript or a similiar method. The returned data, which is mainly XML formatted, is parsed and the user interface is updated. Updating means a manipulation of the HTML content via ECMAScript and the Document Object Model (DOM). Fig. 1 summarizes the relevant technologies in the field of widgets according to W3C. A widget consists of one or more HTML, CSS and EC- MAScript files. Similiar to web pages, images and sounds can also be included. Additionally, a widget has a manifest file, which contains metadata about the widget itself. Meta- data fields are for instance the widget’s name and version as well as the main HTML file. All the files of a widget are packaged into a single file using a standard packaging for- mat, like ZIP. Depending on the widget vendor, the exten- sion of the resulting single widget file has to be renamed in order to be recognized by the widget engine. The packaged widget file can then be deployed and installed on clients. In contrast to well known web pages, the application files are downloaded only once and installed on the client. Only the widget’s data content is retrieved from a web server during runtime. Widget engine vendors usually provide a dedicated area on their web site for the deploment of widgets. Inter- ested users can browse the catalogue of available widgets and download them.

3.3 Interoperability of Widgets

Although widgets are developed using standard web tech- nologies, they usually can’t be executed on more than one widget engine. Main incompatibility issues are:

Manifest document: Metadata fields and the mani- fest’s filename are not standardized and differ between vendors.

Packaging: This includes the packaging format (e.g. ZIP), file extension and internal package structure.

Platform specific functions: Widget engines support different platform features and furthermore the API for accessing those functions is not standardized.

The World Wide Web Consortium (W3C) addresses the problem of widget incompatibility and tries to standardize widget development within the Web Application Formats Working Group (WAF-WG). Relevant specification docu- ments are: Client-Side Web Applications (Widgets) Require- ments [15], Widgets 1.0 Requirements [17] and Widgets 1.0 [16]. All of them are currently in the Working Draft status and are going to reach Candidate Recommendation status in 2009 [2, p. 4].


Mobile Widgets are in their infancy. Compared to Desk- top Widgets, the development is mainly not based on stan- dard web technologies but proprietary markup languages. The widget engines are mostly implemented as Java ME applications and therefore not well integrated with the de- vice operating system. Running a widget means starting the widget engine and selecting the widget within the en- gine. This is contrary to the nature of widgets which should be instantly accessible and directly visible on the desktop (phone home screen) respectively.

Popular examples for Java ME based mobile widgets are Nokia’s WidSets 2 and Mojax Moblets 3 . The first real mo- bile widgets, i.e. widgets which use standard web technolo- gies and are well integrated with the operating system are Nokia’s S60 Widgets. Such widget engines should allow easy and fast porting of desktop widgets to mobile platforms. Ide- ally desktop widgets run without any modification on mobile platforms and the code base for desktop widgets could be shared by mobile widgets.

4.1 Applicability of Mobile Widgets

Applications for a single specific purpose and with low functional complexity are appropriate to be developed as mobile widgets. Their user interface can be kept simple, which allows easy and intuitive interaction though the lim- ited input capabilities of mobile devices. The simplicity of widgets is concurrently one of their greatest weakness: The provided functionality could be too limited for exacting users and the creation of complex applications is difficult. Widgets encourage the creation of ”Long tail applica- tions”, i.e. applications for a small audience. Using the widget approach an application can be developed quickly, deployed widely and also be profitable [7, p. 109]. From an Web 2.0 service developer’s point of view, Mo- bile Widgets are well suited to provide mobile users with an interface to their service. The development of the widget can be done quickly because existing code of the ordinary browser interface can be reused. Furthermore a dedicated application for a service increases the customer’s commit- ment to it. For Third Party developers, Mobile Widgets provide an easy and powerful possibility to link various Web 2.0 services together and create Mashups. In comparison to the access of a service within a browser, widgets have the advantage that less data traffic is caused. Instead of downloading the full web site only the service’s data needs to be retrieved. This results in lower costs for the user.

4.2 Differences to Desktop Widgets

First, the screen of a mobile phone is much smaller than

a desktop computer’s screen. Nevertheless, widgets are usu-

ally so small they fit on a small area on the desktop (e.g. Microsoft Windows Vista’s Sidebar). Therefore the limited area on a mobile phone should suffice for a single desktop widget.

Second, on mobile phones the input and navigation capa- bilities are limited. On the desktop, pointing devices (e.g. a mouse) are the preferred navigation instruments in graphi- cal user interface environments. But such pointing devices are available only on the fewest phones (e.g. phones with touchscreen). Therefore mobile phones usually provide only

a sequential navigation through the selectable items of an

application’s screen. Due to the small dimensions of a wid- get this solution should suffice in most cases. If not, a virtual cursor could be an alternative approach. Another difference between desktop and mobile environ- ments are the costs for data traffic: Data transfer on mobile phones is much more expensive than on desktop comput- ers. Therefore the update cycle of a widget has to be longer than on the desktop and the user should have the choice to update the widget manually or specify the update interval.

2 http://www.widsets.com

3 http://mojax.mfoundry.com

Figure 1: The technology stack of widgets according to W3C [17]. 4.3 Comparison to traditional

Figure 1: The technology stack of widgets according to W3C [17].

4.3 Comparison to traditional Mobile Appli- cation Development Platforms

Widgets are a new way of developing applications for mo- bile phones. This section compares widget development to traditional mobile application development platforms such as Java ME or native SymbianOS. By using markup and scripting languages, widget devel- opment is on a higher abstraction layer than developing with Java ME or SymbianOS and therefore provides several ad- vantages:

The user interface design is simplified and rich user interfaces can be created easily.

The development process is short and development costs decreases.

The similiarity to web development results in a huge increase in the number of potential developers for mo- bile applications.

Widgets are well suited for applications which access ser- vices or resources on the web. The development of such ap- plications as widgets is faster and more efficient than with other mobile platforms. But there are other types of appli- cations where widgets are unsuitable, e.g. games and ap- plications which make use of device specific functions (e.g. camera, GPS). Java ME and especially SymbianOS provide low level access to those functions. Vendors of widget en- gines also want to provide access to – at least basic – native functions through a JavaScript API. However there are se- curity concerns. Caceres states that the scope of security in widgets deals mainly with access-control, i.e. what a widget is allowed and not allowed to do in order to prevent users from malicious widgets [2]. Due to the security concerns vendors will most likely introduce access to native functions in a later phase.


This chapter introduces the first and up to now only mo- bile software platform that enables the creation of mobile widgets using standards-based Web technologies. Nokia sup- ports widgets on their S60 platform since its 3rd edition, Feature Pack 2 [11] but hasn’t released a SDK and docu- mentation for widgets yet. However the S60 3rd Edition

SDK for Symbian OS, Supporting Feature Pack 2 Beta, for MIDP 4 , supports the Web Run-Time environment for de- veloping and testing widgets in the emulator. The widget engine is called Web Run-Time and is based on the open source project WebKit 5 , which is also used by S60’s web browser and Apple’s Dashboard widget engine. S60 Widgets are very well integrated with the phone op- erating system. They are installed and accessed like other S60 applications. In the first release of the Web Run-Time environment, widgets can’t access native functions, e.g. cal- endar, address book and GPS. This features are intended to be added in a second phase in 2008 [14].

5.1 Porting Dashboard Widgets

Because Web Run-Time and Dashboard are built on the same technical foundation, porting a Dashboard widget to the S60 platform should be quick and straightforward. We made a short study and tried to port randomly choosen Dashboard Widgets to the S60 platform. The list of inves- tigated widgets included YouTube, Sudoku Widget, Google Gmail, Heise News and ORF News. All of them are avail- able on the official Apple Dashboard Widgets web site 6 .



Running a widget without any modification didn’t work in any case. Main problems were:

1. The syntax of the manifest file "Info.plist" differs between Apple and Nokia.

2. HTML, CSS and JavaScript documents use resources (e.g. images, JavaScript files) directly from Apple’s filesystem. Those resources are either not available or located in another directory on the S60 platform.

3. Some widgets use special Plug-Ins. Those Plug-Ins are natively written components, which provide access to the operating system’s or an application’s functions via JavaScript, e.g. access to the iTunes application. In the Sudoku Widget the Plug-In is used for generat- ing and solving a Sudoku. Plug-Ins are included in a

4 http://sw.nokia.com/id/9c781347-1206-4bb0-86a1-\


5 http://webkit.org/

6 http://www.apple.com/downloads/dashboard/

widget’s package as Mac OS binaries and therefore not directly executable on S60.

4. Creation and access of files on the filesystem and within the widget package. As an example, the widget Heise News reads the widget’s version out of the manifest file by a local XMLHttpRequest. S60 Widgets doesn’t provide those features in their current version.



For each of the listed problems, a general solution is pre- sented hereafter. Additionally we explain the concrete mod- ifications we applied on the widget Heise News.

1. The Document Type Definition (DTD) of the manifest file has to be adopted to Nokia’s requirements:









Additionally some property keys have to be renamed:

The prefix "CF" of keys which start with that prefix has to be removed, e.g. CFBundleName has to be renamed to BundleName. After these two modifications, each tested widget could be installed and launched success- fully on the S60 platform.

2. The used filesystem resources can be included in the widget bundle. This implies that the references to those resources within the source files have to be up- dated. If there are further references within those re- sources (and possible again in a recursive manner) the work for updating increases and the widget’s size could grow quite big. Heise News references within the file Heise.css two images (white i.png and white rollie.png) which point to a location on the Mac’s filesystem. We copied them from their original location on the Mac OS to the widget’s Images-subdirectory and updated the ref- erence within the CSS file. The file Heise.html also uses a resource from the Mac’s filesystem: The JavaScript file GenericButton.js. Be- cause this file references many other files, we didn’t in- clude the file in the widget’s package but simply used a standard HTML button.

3. Widget Plug-Ins are not supported in the current ver- sion of S60 Widgets and therefore can’t be ported. Moreover porting of Widget Plug-Ins doesn’t make sense for applications which are not available on the S60 platform. Nevertheless the functionality of some Plug-Ins can be implemented in JavaScript, e.g. gen- erating and solving a Sudoku for the Sudoku Widget. Heise News doesn’t make use of Plug-Ins.

4. As an alternative for saving data in a file, S60 Widgets provide the persistent storage of key/value-pairs. For that purpose the methods setPreferenceForKey() and preferenceForKey() are available. In the widget Heise News, we defined its version within the JavaScript file (VERSION = ’1.0’), instead of read- ing the version out from the manifest file via the method getLocalVersion().

from the manifest file via the method getLocalVersion() . Figure 2: Screenshot of the ported widget

Figure 2: Screenshot of the ported widget Heise News, running in the S60 Emulator.



After applying the aforementioned solutions, the two RSS reader widgets, Heise News and ORF News, run nearly per- fectly. The only feature which didn’t work was viewing the news details, because the platform’s browser couldn’t be launched from within the widget. This is a known issue from the beta release. Fig. 2 shows a screenshot of the S60 Emulator running the widget Heise News. The other three widgets mentioned before couldn’t be executed correctly be- cause they make use of Widget Plug-Ins. As can be seen in Fig. 2, the widget is wider than the screen width. This leads us to another important issue re- garding porting: the screen size. The investigated Dash- board Widgets are mostly too big for the QVGA (240x320 pixel) display of the phone. Although the widget engine au- tomatically provides scrolling, widgets should be designed to fit entirely on the screen. For existing desktop widgets this implies downscaling of images and adjusting dimension relevant parameters within HTML and CSS documents.



Widgets are convenient applications whose power rests on the strong relationship to web technologies. Their elegance lies within their simplicity and orientation to a single spe- cific task. Due to the simliarity to Web development the developer base is huge and therefore thousands of widgets are available. The AJAX based development approach leads to a rich user experience. Mobile widgets are in the initial stage of their develop- ment. By now, nearly all vendors of mobile widget engines use proprietary markup and scripting languages. But this is in our opinion only an intermediate step in the evolution of widgets. Nokia’s S60 Widgets are a first promising develop- ment and point the direction where mobile widgets should go. It is desireable that other mobile platforms integrate

support for widgets which are compliant to web standards too. To avoid fragmentation, standardisation of widgets has to be progressed. The presented case study on porting widgets revealed that Apple’s Dashboard Widgets are executable on Nokia’s S60 platform in principle. The effort for porting depends on the widget type: widgets which don’t access native functions can be ported easily, whereas the effort for other widgets is much higher or porting is not possible at all.



[1] Apple Inc. Apple Mac OS X Dashboard. URL, http:

//www.apple.com/macosx/features/dashboard/. Accessed: September, 24th 2007. [2] M. Caceres. Standardising widgets. URL, http://datadriven.com.au/thesis/confirmation/ confirmation.pdf, August 2007. Accessed:

September, 24th 2007. [3] C. Dunnigan and K. Shradel. Mac Widgets. URL, http://www.cs.rit.edu/ ats/xml-2006-3/p/ dunnigan-shradel/widgets.pdf. Accessed:

September, 24th 2007. [4] J. J. Garret. Ajax: A New Approach to Web Applications. URL, http://www.adaptivepath.com/ ideas/essays/archives/000385.php, February 2005. Accessed: September, 24th 2007.

[5] Gartner Research. Nokia Widgets Will Encourage S60 Mobile Services. URL,




April 2007. Accessed: September, 24th 2007. [6] G. Grassel. Position Paper: AJAX in Widgets and Web UIs. URL, http://www.w3.org/2007/06/ mobile-ajax/papers/nokia.grassel.pdf. Accessed:




September, 30th 2007.

[7] A. Jaokar and T. Fish. Mobile Web 2.0. Futuretext,


[8] J. Jeon and S. Lee. Position Paper: Toward a Mobile Rich Web Application Mobile AJAX and Mobile Web 2.0. URL,



Accessed: September, 30th 2007. [9] Microsoft Inc. Microsoft Gadgets. URL,

http://microsoftgadgets.com. Accessed:

24th 2007.


[10] Netvibes. Netvibes UWA Specification. URL,

http://dev.netvibes.com/doc/uwa Accessed: September, 24th 2007.


[11] Nokia. S60 goes beyond Web browsing with Web Run-Time and widgets. URL, http://sw.nokia.com/







Widgets.pdf. Accessed:

September, 24th 2007. [12] Opera Software. Opera Widgets. URL, http://widgets.opera.com. Accessed:

24th 2007. [13] T. O’Reilly. What is Web 2.0. URL, http://www.oreillynet.com/pub/a/oreilly/tim/ news/2005/09/30/what-is-web-20.html, September 2005. Accessed: September, 24th 2007.


[14] G. Sivaraman. S60 Widgets. Audiocast, http:







Accessed: September, 24th 2007. [15] W3C. Client-Side Web Applications (Widgets) Requirements. URL, http:


November 2006. Accessed: September, 24th 2007. [16] W3C. Widgets 1.0. URL,


November 2006. Accessed: September, 24th 2007.

[17] W3C. Widgets 1.0 Requirements. URL, http://www. w3.org/TR/2007/WD-widgets-reqs-20070705/, July 2007. Accessed: September, 24th 2007. [18] Yahoo! Inc. Yahoo! Widgets. URL,

http://widgets.yahoo.com. Accessed:

24th 2007.