Web widgets for the EGI Community
Part 1 - Introduction
The sheer volume of web sites and portals provided within the European Grid Infrastructure (EGI) ecosystem has grown so overwhelming that an increasing number of people are adopting multipurpose tools to help them manage and personalize the vast amount of data thrown at them every day. Personalized web pages in iGoogle and Netvibes, dashboards developed within the community reflects attempts to make the web-enabled services of EGI more manageable. This post – the first part of a series – provides an overview of the "web widgets concept" and shows how widgets could contribute to the more efficient promotion and reuse of software services within EGI. (Part 2, Part 3, Part4)
Until recently, the whole thesis of providing and sharing EGI software services has been that these applications must be either accessible through well defined web sites operated by EGI members, or must be available as downloadable packages so users can operate their own installations. But nowadays, there are several problems with this approach. One is that users from one part of the community (from example from an NGI or VRC) are less willing to leave the site they're using to visit another NGI’s or VRC’s site in order to access services there. Another is that this approach does not really facilitate the reusability of services across EGI: the integration of services into web sites that target users from a specific country, discipline or with known common interest simply requires too much skill and effort from the site operator. This is where web widgets can make a difference.
Web widgets are part of a rather broad concept, based on the general idea of code reuse, targeted towards the reuse of components within Web pages [1]. A web widget is a small application that can be embedded into third party web sites by any user on a page where they have rights of authorship (for example within a user’s personal website, within an NGI or a VRC website). From the developers’ perspective web widgets are components that can be executed across multiple platforms without additional compilation.
Originally, the goal of widgets was to simply deliver a miniaturized version of a specific piece of content outside of the primary web site [2]. A classic early widget is the Flickr badge, which allows users to show a preview of their photos. Clicking on the badge would lead to the Flickr user's profile page with all the user's photos. Widgets gained momentum in the last few years and now companies see widgets as an important method of reaching audiences both inside and outside their domains.
One could say that the concept and technologies for code reuse on the Web is around for a long time. Indeed, solutions such as Microsoft's ActiveX and ActiveForms, JavaBeans, portal and portlet frameworks (Drupal, Gridsphere, etc.) promote the reuse of components and services across web pages. However, while some of these solutions are specific to a platform or programming language, others are simply not as flexible and easy to use as web widgets: a web widget can be embedded into any site that is written in HTML. The look and feel and the functionality of widgets can be typically customised to a large extent. But the best of all – you do not need to be an experienced Web developer to customise and to integrate a widget into a website!
Meanwhile the concept of web widgets is quite well understood, there is no single technology or specification for it. Even the name “web widget” is just one of the many names in use. Small embeddable web applications are sometimes also called as gadgets (by Google), badges, modules, capsules, snippets, minis or flakes – with or without the “web” foreword.
Web widgets are used by clients – web pages written in HTML (See figure below). The web pages actually use a chunk of code provided by a widget provider site. The functionality is implemented by the widget code and by code residing on a remote server. The client does not have to care about the implementation of the widget, the implementation of the code provider, or the communication between them. Sometimes an optional system, called Widget Management System, manage the output of the widget. In such a configuration the widget developer can focus on what to widgetize and why, while the widget management system is focused on how to make the widget installable in as many destinations as possible, and how to track the widget usage [4].
Different technologies exist to create and host widgets. For example Javascript or Adobe Flash for the widget code, AJAX mechanisms for the server and for the communication between the two sides. Most of the existing, freely available widgets, such as Google Gadgets or Yahoo! Widgets, do not follow any common architecture.
So how should You, member of the EGI community adjust to this new situation? Well, this is something what will be discussed in the the forthcoming posts. In the meantime, here is a list of references for you where further information can be found on the topic.
[1] Wikipedia - Web widgets: https://secure.wikimedia.org/wikipedia/en/wiki/Web_widget
[2] The Evolution of Web Widgets: From Self-Expression to Media Companies: http://www.readwriteweb.com/archives/the_evolution_of_web_widgets.php
