A Hands-on approach to WIDGETS & OPERA WIDGETS

What is a WIDGET?

Essentially, a widget is a local HTML/CSS/JavaScript web application. A mobile phone user downloads a widget once, and from that moment on he has a web application stored locally on his mobile phone. Widgets are small web applications running on your desktop. They are implemented using client-side web technologies, and creating one is very much like creating a web page, except that it is run in a slightly different context.

Although currently widgets are mostly used for relatively limited functions such as clocks, RSS readers, or Twitter or Flickr clients, as well as for games, there’s no theoretical reason why they couldn’t contain a complete, complicated, JavaScript-heavy web application; for instance a mobile-optimized spreadsheet application.

The beauty of the widget model is that, even if this spreadsheet application needs 200K of custom JavaScript plus a few libraries, the end user has to download these scripts only once instead of every time he/ she starts up the app, as in the traditional web application model. After the initial download the entire application is installed locally and can be fired up from the local files. Many web applications will want to display fresh data, and therefore most widgets will fire an Ajax request as soon as they’re started up. For that they need a network connection and some data traffic.

Nonetheless, the fact that the application itself doesn’t have to be downloaded every time the user starts it up diminishes the network traffic by a lot; and that’s important on mobile phones with their unreliable and sometimes crawlingly slow connections.

Unique Selling Point

In itself the widget concept is no different from the countless application models currently being set up for the iPhone, Android, Blackberry, Windows Mobile, and many more systems. These, too, will put the core files on your phone and use the network connection only for data traffic.

All proprietary systems, however, require programmers to train themselves in new skills and techniques that are not interoperable. Widgets, on the other hand, use the open web technologies that hundreds of thousands of developers all over the world are already familiar with.

Better still, widgets will eventually conform to the “write once, run anywhere” principle; though right now that’s not yet the case. Personally I firmly believe that widgets are the future of the mobile web. They are easy to create, they’re based on open standards, they save the end user quite a bit of network traffic, and many people around the world already know how to create them.

Technical Overview

Widgets are nothing more than zipped websites. You create an HTML file, add as many CSS, JavaScript and image files as you need, zip the lot, change the extension to .wgt and it works. Just like that.

Well, almost just like that. The rest of this entry explains the “almost.”

Specification

Widgets are specified by the W3C Widgets specification. Currently this spec is still a work in (slow) progress, as so many W3C specifications are, but the outline is pretty clear.

The widget environment that is shown here has been created by Vodafone in close cooperation with Opera. Because they wanted to work according to a standard but the specification was (and is) still in draft stage, at a certain point they decided to freeze the then-current version and implement it. Subsequently it was slightly modified to be shown as a prototype.

All technical details are extracted from this Opera/ Vodafone implementation, which does not quite match the current W3C draft.

Widget SDK

Opera Widgets are cross-platform and cross-device applications made with Web technologies; therefore, you can develop Opera Widgets quickly and easily and deploy them to different devices with a minimum amount of adaptation.

The Opera Widgets Software Development Kit (SDK) is made up of tools, libraries, documentation, and examples on how to make Opera Widgets for different devices. This article will point you to different resources available to help create Opera Widgets. You can also watch a full widgets SDK guided tour video to get up to speed on the main features and learn how to create a basic widget.

Packaging widgets

Opera Widgets are packaged as regular zip files, renamed to use the extension .wgt. All the files related to your widget should be stored inside the widget file. A typical widget contains the following elements:

• A widget configuration file. This is an XML file in the root of the widget structure that holds information about your widget including its size, name, author, and security information. 
• An index document. Like on a web page, this document contains the basic skeleton/ content of the widget. Widgets content can be created using any markup that Opera handles natively, for example HTML, SVG, or XML files. This file also lives in the root of the widget structure. 
• Images. These are contained in a single images folder.
• JavaScript files. These are contained in a single script folder.
• Style sheets. These are contained in a single style folder.

When a user running the Opera desktop browser clicks on a link to a .wgt file, Opera will download the widget, start it, and ask the user if the widget should be kept on his/her computer. Note that behavior on different platforms supporting widgets may differ slightly.

The next time the user wants to run the widget, it can be started from the Widgets menu.

What do you need to create and deploy an Opera Widget?

In order to be able to create an Opera Widget, you will need the same as you need for regular Web development:

• A basic understanding of web technologies.
• A text editor or web IDE that allows creation of JavaScript, HTML, and CSS files.
• A tool for creating .zip archives.
• Somewhere to publish the widget. The Opera Widgets web site offers the perfect place to host our widgets, and is visited by tens of thousands of people every day looking for widgets to run.

How are widgets related to web pages?

We keep saying widgets are very similar to regular Web pages, but there are a few differences:

• The widget lives outside the Web browser, directly on the user’s desktop without any of the regular user interface elements, such as title bars.
• The security restrictions of a widget are different from regular web pages - you can create a widget that will simultaneously interface with different Web services living on different Web servers.
• Widgets have a widget object available via JavaScript that allows you to access widget-specific functionality.
• Widgets have access to a permanent storage facility for its settings and downloaded data. This mechanism is similar to cookies, but the storage capacity is larger than for cookies, and does not automatically expire after a given time.
• Widgets typically have several views available in the same document. Typically there will be one or more views used to access the widget's normal functionality, and a separate view wherein you provide the user with configuration options. Switching between these views is done by performing transitions on the views sing regular JavaScript/ CSS methods.
• By default, widgets are drag-gable, so you can move them around on the screen simply by clicking and dragging. If this behavior is not desired for a widget (or parts of it,) you need to  specify control regions where the widget does not respond to dragging.
• By default, the widget background color is transparent. The transparent area of a widget does not respond to mouse events but instead passes them through to any underlying application.

An example for config.xml

A widget requires a config.xml file that specifies some configuration information. Here’s a sample config file:

<widget id="http://quirksmode.org/widget" dockable="true">
    <widgetname>Test widget</widgetname>
    <icon>pix/myIcon.gif</icon>
    <width>200</width>
    <height>200</height>
    <security>
        <access>
            <host>quirksmode.org</host>
        </access>
    </security>
</widget>

Most of this stuff is pretty simple. <width> and <height>, unsurprisingly, define the width and height of the widget in pixels.

These are start values; if you want you can later on change the widget size by the normal resizeTo() and resizeBy() methods. The widget cannot in any case become larger than the screen.

The <icon> tag specifies the icon that the user sees when the widget is turned off; and this is of course a local file.

The <widgetname> tag contains the name that will be shown with the widget icon. It’s advisable to use short names, because there’s only about 60 pixels of space to show the name when the widget is docked. Some phones auto-scroll longer texts when the user focuses on the icon, but that’s not an optimal means of communication.

The id attribute is required if you want to be able to update your widget. I’ll get back to the updating process in a later post; for now it’s sufficient to say that an id must be a unique URI. As to the <host> element, it specifies with which host(s) the widget is allowed to communicate via Ajax requests. Widgets don’t really have a same-source policy; they’d be worthless if they did because they must be able to download data from anywhere. However, the widget creator is required to specify which domains the widget may access. (Unfortunately Opera unexpectedly changed the security policy in Opera 10 Desktop.

You need the syntax shown above for Opera 9 and the Widget Manager, but a different one for Opera 10.)

The widget workshop: hello world!

OK, with the background out of the way, let’s start coding! It is better to have the first widget as simple as possible - a “Hello World!” widget. Earlier on we talked about widgets containing CSS, Image and JavaScript files. Many do, but at the very least, a widget requires two files:

1. The main document.

2. The widget configuration file.

We will start this tutorial by creating a minimal widget, and then expand the widget into a complete widget with style, and a configuration view.

Creating the main document

First, create an HTML document inside a new directory and call it index.html. This document will be what your users will see when they first load the widget. Add the following code to it, and save the document.

<!DOCTYPE html>
<html>
    <head>
        <title>Hello World!</title>
    </head>
    <body>
        <p>Hello World!</p>
    </body>
</html>

Creating the widget configuration file

Next, we'll show you how to create the widget configuration file, which is needed in order to run your widget. It is always named config.xml, and holds information on certain properties of the widget. The properties required inside this file are as follows:

• The widget’s name.


• The widget’s dimensions. This is the maximum viewable area for a widget.


• Author information. Feel free to brag.


• A unique ID for the widget. This ID is made up of three parts: A hostname, a path and a revision date on the YYYY-MM format (you can also use YYYY-MM-DDDD if you plan on revising the widget more than once a month).


• Security information that provides the widget user with information about which domains the widget will be contacting. Even if this security information is optional, any widget that contacts a third-party service is highly encouraged to include this, since this will establish a trust  relationship between you, the widget author, and the widget user. For more information, view the config.xml specification here.

Create a new file in the same directory as your index.html file called config.xml. Add the following code to it, and save it.

<?xml version='1.0' encoding='UTF-8'?>
<widget>
    <widgetname>Hello World!</widgetname>
    <description>Demo widget from the Hello World tutorial.</description>
    <width>440</width>
    <height>200</height>
    <author>
        <name>John Doe</name>
        <email>john.doe@example.com</email>
        <link>http://acme-widget.example.com</link>
        <organization>Acme Examples, Inc.</organization>
    </author>
    <id>
        <host>example.com</host>
        <name>HelloWorld</name>
        <revised>2008-01</revised>
    </id>
</widget>

Running your widget for the first time

Let's test what we have so far - run your widget by opening the config.xml file in the browser. When you run the widget defined above, you should see something like that shown in Figure below.

Support

Although I firmly believe support for W3C widgets will become better and better as time progresses, right now it’s still in its infancy.

Opera is a major defender of the widget concept, so it comes as no surprise that Opera Desktop supports it. If you’ve created a .wgt file on your computer, double-clicking it starts up Opera, which shows the widget in a special widget mode. That’s useful for testing.

Vodafone Widget Manager

On mobile phones the situation is murkier. The Vodafone Widget Manager that runs only on Symbian S60 phones (basically Nokia), supports only W3C widgets, but few other applications or phones does.

The Vodafone Widget Manager has been created by Vodafone in order to manage widgets. It contains a system for installing them, as well as a complete Opera Mobile runtime engine that is used to actually interpret the HTML, CSS, and JavaScript. There are some slight differences between a regular Opera Mobile and the Opera Widget Runtime.

Opera is a pretty good browser, so you can be quite certain that your widgets will run pretty well as long as you use proper HTML, CSS, and JavaScript. On the other hand, this is a new, untested technology, so nasty surprises will definitely turn up at the worst possible moment in your development cycle.

Opera/ T-Mobile Widget Manager

Opera announced just now that it has built a similar system for T-Mobile. Because all the screenshots feature Windows Mobile interfaces, we kind of assume it runs (only?) on that OS.

Confusingly, when I search for “widgets” on the T-Mobile site I get three pages about other widget systems on the German site, while the UK and US sites each have one unrelated match.

Interestingly, this widget manager seems to contain a device API. A device API is a JavaScript interface meant for accessing phone functionality such as the camera, the calendar, the contact list, and so on. It’s obvious that device APIs are going to be extremely important for creating widgets that tie in more closely with mobile phones.

As far as I can see now the Opera/ T-Mobile device API is proprietary (and possibly restricted to Windows Mobile). That’s not entirely unexpected; currently the BONDI specification is supposed to formulate a standard for device APIs, but it’s not ready yet and unreadable for non-Java programmers anyway.

Despite this touch of proprietary-ness the Opera/T-Mobile initiative seems to be on its successful path. The more companies support widgets, the sooner they’ll go main stream.

Nokia Web Runtime Widgets

The Vodafone widgets can be ported to Web Runtime Widgets, the native Nokia S60 widget environment. These, too, are HTML/CSS/JavaScript widgets, although they run in S60 WebKit and need an info.plist XML file instead of a config.xml.

As far as we can see, making your widget Nokia-compatible entails nothing more than adding this info.plist to it, and making sure your widget runs well in S60 WebKit. By the way, the “XML” in the plist is weird. The schema is based on Apple’s Dashboard Widgets, so knowing them would be advantageous.

Palm Pre?

Maybe the Palm Pre, which has made Web technologies the very cornerstone of its webOS operating system, will support them, but there’s so little data available to be explored, except that it would be a logical extension of their plans. The Palm Pre uses a WebKit branch as default browser, by the way.

Summary

Finally, as it can be seen that development of widgets can be pretty straight forward. Widgets are going to play a major role in mobile applications. Opera widgets are the most easily available SDKs currently; with much more developments to follow in the months to come. Widgets are the easiest way for users to access your service. Widgets are quick and easy to write. The use of web widgets has been increasingly proposed as a marketing channel that could replace the less effective targeted banner ads taking advantage of the viral distribution in social networks.

Reference

http://en.wikipedia.org/wiki/Web_widget

HTML - Hyper Text Markup Language (and file extension)

CSS - Cascading Style Sheet

RSS - Resource Sharing System (libraries)

W3C - World Wide Web Consortium Extensible Markup Language XML - Extensible Markup Language

SVG - Scalable Vector Graphics (W3C)

IDE - Integrated Development Environment

URI - Universal Resource Identifier (web; less common)