What is a WIDGET?
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.
Well, almost just like that. The rest of this entry explains the “almost.”
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.
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.
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.
- 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 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 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.
- 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">
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!
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.
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'?>
<description>Demo widget from the Hello World tutorial.</description>
<organization>Acme Examples, Inc.</organization>
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.
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.
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.
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
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.
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.
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.
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)