« Previous | Main | Next »

Why a widget? From Chris Bowley

Post categories:

Matthew Cashmore | 12:35 UK time, Thursday, 26 October 2006

With backstage running a Widget Competition, there has never been a better time to get into writing widgets. But the chance of winning 'a well known media player' should not be the only reason why you want to create a widget!

In the last few months I have written a couple of Yahoo! widgets: a what's on widget to demonstrate the prototype BBC schedule API and a widget allowing you to update your Last.fm profile as you listen to the radio.

One of the main reasons why these projects were developed as widgets is that they allow you to make client-side cross-domain XMLHttpRequest calls. The Last.fm widget makes calls to two different domains and therefore cannot be hosted as a web page. Widgets can also make calls to control installed applications, such as streaming audio through Real Player, and display OS information such as laptop battery life or WLAN coverage. In essence widgets provide a sandbox with fewer restrictions than web browsers but they do have their disadvantages.

Widgets are downloaded applications and therefore any updates which you make means users need to download a new version - you do not have control like you do a web page. There are a number of popular widget engines which are all different - Yahoo! Widgets are defined with XML and JavaScript while Apple Dashboard widgets use Safari as their engine and are defined using HTML and JavaScript. Windows Vista incorporates its own Gadgets system which, no doubt, will be different again.

I have only had experience in developing Yahoo! Widgets (originally Konfabulator). I chose Yahoo! because they are (in theory at least) cross-platform. XML defines the widget in terms of visual components (text, image etc.) which have their own built-in events, specified using JavaScript. You can also use JavaScript to define and change the visual components. I guess writing a widget is similar to writing a (sorry, but I can't think a better way to describe it) 'Web 2.0' web page - the vast majority of the page is coded in JavaScript, especially when the visual components are flexible and dependent on remote data. Remote communication is very simple and should be familiar; the XMLHttpRequest object has the same methods and properties as found in web browsers. In writing the Last.fm widget I decided to write a separate class which allocated and released XMLHttpRequest objects in order for multiple calls to be made asynchronously.

Overall I think widgets are a good alternative to web pages and traditional applications, but you should only develop one if the circumstances don't allow the same operations to be carried out in a web page or if a widget will provide a better user experience.


More from this blog...

Topical posts on this blog


These are some of the popular topics this blog covers.

BBC © 2014 The BBC is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.