Introduction
Widget is a funny word. For some people it means a small device at the bottom of a can of Guinness for others it’s a character in Marvel comics. In technology terms desktop widgets (or gadgets) are small programmes that run on your desktop to give you useful information.
The Wikipedia definition of a desktop widget is: "a small specialized GUI application that provides some visual information and/or easy access to frequently used functions such as clocks, calendars, news aggregators, calculators and desktop notes. These kinds of widgets are hosted by a widget engine."
On my desktop I have a small Yahoo widget toolbar with the weather forecast, the date and the capacity of my computer battery, information on the web or my computer I’d otherwise have to go and search for [2]. Widgets and gadgets can do the same job for educational applications too. The TENCompetence project has been using widgets to create an innovative run time system for IMS Learning Designs [3]. We spoke to Scott Wilson about widgets, the TENCompetence project, and the potential for using of widget technologies in institutional applications.
Christina Smart: How do widgets work?
Scott Wilson: If you think about the e-Framework and its service layers, widgets are at the user agent, or application layer [4]. At one level you have the e-Framework, a set of systems exposing services. At the other end you have what we call containers, which can be VLEs, blogs, social applications – the applications that users make use of. For widgets to work we need another element which is the widget engine or server which works with the container. The widget engine will hold any number of widgets that you want your users to be able to access. So the container might be something like Moodle [5] and the engine might be something like Wookie (the engine we used in TENCompetence). Typically the widgets are aligned with or call services, either directly, or indirectly through a layer of mash-ups or processes (Figure 1).
|
|
Figure 1: A service oriented architecture including a widget engine
CS: But widgets are discrete applications aren’t they?
SW: Yes. For the user, widgets are doing a particular job which can either be done entirely locally within their own code, or by calling remote services or mash-ups which are chains of services. So from that view point there is potentially a direct relationship between having a widget front end model and having a service oriented architecture.
Let’s take the timetabling example. The institutional Management Information System for timetabling might be something like CELCAT Timetabler [6]. On top of that the institution might have developed a timetable web service to interact with CELCAT. Then you can add a widget like a personal timetable widget which can be displayed in your VLE, or an iPhone, or other application. So there’s a connection all the way through the architecture.
What we’re talking about now in the widget world is very much what we were talking about a couple of years ago with composite applications [7]. What we have now is a fairly well elaborated and standardised way of doing what the e-Framework called the user agent layer. While we did have some ideas before about how you implemented the user agent layer using things like portlets, widgets offer a more modern approach to composition that users are becoming increasingly familiar with. What is especially powerful about widgets is that the same widgets can be displayed through a variety of different containers e.g. WebCT [8] and Elgg [9]. All the containers need is a widget plug-in.
CS: And how easy is it to write the plug-in for the containers?
SW: Very easy. You write a plug-in for the VLE or container, and the plug-in talks to the engine, to tell it to display particular widgets, so we’re talking purely about the rendering of the widget. There is of course another connection by which the widget talks directly to a service via the web.
With many of today’s web applications there are already built-in local extension points, such as Moodle Blocks and Wordpress Plug-ins, and so what we do is use those to enable users to add widgets too.
It’s important to distinguish, though, between native plug-in systems used in particular applications and the kinds of widgets we are discussing here. Most applications have native plug-ins, even “widget” capabilities, which are tied to that application. For example, there is a PHP API for writing widgets for Wordpress. However, what we’ve been doing is using an external widget engine and set of standards-based APIs, so the widget developer doesn’t need to know anything about the container, which means the same widget can be deployed in Wordpress and Moodle without any extra work.
CS: Are there any big differences between using widgets in web containers and on the desktop?
SW: What is surprising, based on the W3C work, is how little difference there is in terms of how you may want to write, package and deploy widgets [10]. There are two big differences though: one is multi-user capability, and the other is the security aspect.
Unlike desktop widgets, web widgets can run in containers that are shared by many users, and so it becomes possible to create widgets that are multi-user. There are already social widgets in the sense of Facebook applications and Google OpenSocial gadgets, but not really many collaborative widgets, and so we focussed on extending the W3C specification in that direction. So you can create widgets that enable chat between users within a container-specific context, such as a Moodle course.
On security, the biggest issue is that a web widget may want to communicate using AJAX with services across the web in different domains from that of the container application. Most browsers prevent this type of activity using what is sometimes called a “same origin policy”. This is a useful security precaution, however this also completely blocks the functionality you want to support. So for web widgets to work they need to be able to access services using a server-side proxy offered by the widget engine. We use a whitelist-based proxy that the widget engine administrator can configure. However, we then have the issue of how widgets can make use of services that require some form of authentication or authorization.
An emerging technology that’s really important in here is something called oAuth. OAuth is an open protocol which allows a standard method for secure API authentication for desktop, mobile and web applications [11]. One example is when I have a Gmail gadget running in a container such as Netvibes, somehow I need to get my credentials to the Gmail service and I don’t want to necessarily pass them through the container or server. oAuth enables the transaction to happen, prompting me to grant access from Gmail to this widget to access my mail, but without exposing my login details or user id to the container or the widget.
CS: How have you been using widgets in the TenCompetence project?
SW: At Bolton we’ve been developing two pieces of software as part of the TENCompetence projectfunded by the European Commission through the IST programme. We’ve developed a new IMS Learning Design editor called ReCourse which allows users to author more complex Units of Learning [12]. However, there has also been a need for more sophisticated run-time tools to be able to run these units and co-ordinate appropriate activities for learners [13]. So in the project we’ve been exploring how desktop and web widgets could be used to provide chat, discussion and voting services within a run-time Learning Design environment, so that users could seamlessly be offered the features specified by a particular learning design. Paul Sharples is the main developer on this and he has got a number of widgets working within a number of environments including the SLED learning design run-time tool (Figure 2).
|
|
Figure 2: A Forum widget running within the SLED run-time engine
SW:There are two widget engines that we have been working on. The one we’ve used for the TENcompetence project is called Wookie. Wookie follows the W3C Widget specification, the other one is called Shindig for Apache and that implements Google Gadgets [14]. The overall approach seems to be one that has a lot of merit to it. The neat thing about these systems we’re talking about is that the widget is written purely in Javascript, and they have no other code, so the same widget will work on a VLE written in PHP, a staff page written in C#, a blog that uses Java – it doesn’t matter what platform, what server, what language they are written in, the widget will work in exactly the same way. As we’ve followed the W3C specification, and that is quite close to Apple Dashboard, it’s actually been possible for us to easily convert widgets written for Dashboard to run in all kinds of web-based containers.
Plug-ins at the container level, such as Moodle blocks, Web CT modules and Blackboard building blocks all have to be written to the APIs defined by that system and in the language of that system. So you’d have to write a plug-in for each individual system for each widget. Whereas with widgets you still write a plug-in for each system, but it’s much simpler to write, it essentially just says, “show widget” and the user configures it with the type of widget to display (“chat”, “voting”, etc). It’s a “write once show many strategy”. To demonstrate the approach we wrote a widget plug-in for Moodle, which is basically a blank block in Moodle with one property which is the widget type e.g. chat (Figure 3). It also of course makes it easier to change the widget, simply adding a new chat widget to the widget engine will display the new widget in all your different containers. Potentially it’s a good way for institutions to manage the services they want as part of their service oriented architecture, without having to do a lot at the front end.
|
|
Figure 3: Moodle with two Apple Dashboard widgets and a chat widget
CS: What do you think in a broader sense are the wider applications for widget technologies?
SW: What it influences is how as an institution you deliver your service oriented architecture to users without mandating a single user application. So looking at the diversity of containers (Figure 4), that includes VLEs, personal staff pages, Blogs, iphone, social software, all of these are containers capable of displaying widgets. Some of these will have a widget engine built in (e.g. iPhone), some will have to have one attached (eg VLEs and blogs). The institution can use a single timetable widget, located on its server and know that that widget can be displayed in ALL the different containers that people use. That widget can be linked to one web service to provide the data. Take the timetabling example again, The timetable system can have a single service to access timetable data and institutions can provide a single widget which can be displayed in a diverse set of containers from the institutional VLE to people’s blogs or iPhones. This gives students and teachers a lot of variety and flexibility over the tools that they use, with a constrained architecture.
|
|
Figure 4: The same widget can be rendered in a variety of different applications and containers
SW: This approach links very closely to the original e-Framework ideas. A couple of years ago I wrote an article about how the e-Framework could allow greater pedagogic diversity at the level of the user interface [15]. This is the technology that can really make that happen, because before we had to rely upon assembling these composite applications, pretty much by hand. Whereas now we can just attach a widget engine and a widget plug-in and you can keep using Moodle if you want, you don’t need to build a new service oriented application, but you can incrementally increase functionality of your legacy systems. I believe it could give high impact benefits for low investment of effort.
Conclusion
So the power of widget technologies is that it offers institutions a relatively easy way to provide additional functionality to a variety of existing user applications. Given the time and effort that institutions spend in familiarising staff with new applications widget technologies clearly have a lot to offer. Further information on the W3C specification for widgets can be found on the W3C web site [10]. The Google Gadgets [16] and Yahoo widgets sites [2] are also good places to discover desktop widgets. The more adventurous might try building their own widgets using the Sprout widget building tool [17].
courtsy: Christina Smart[http://www.elearning.ac.uk]
No comments:
Post a Comment