SPP phase I  was largely devoted to considering how five Resource Discovery Network (RDN) hubs might be turned into subject portals, but at this stage did not include the development of portlets. During the course of phase I it became clear that many potential users of these portals would choose to access content from within their local institutional portal or a virtual learning environment (VLE). The choice of functionality for these portlets was in part determined by the results of user testing on users of the BIOME Web site, which gathered feedback about various potential portlets and the ways in which they might deliver information .
Portlets were a much more important part of SPP phase II, which ran initially till 2004 (with an extension to 2006). Two portlets were felt to be worth developing further because they were thought to be especially innovative and useful: an alerting portlet and a cross-searching portlet . The idea of an alerting portlet developed out of the concept of an aggregated newsfeed searching portlet. Its function is to notify users about new resources in their subject interest areas and to allow users to register those areas with the portlet software. Nothing similar exists elsewhere to our knowledge and this is one of the most original outcomes of the SPP project.
During the latter stages of phase II of SPP, the project developed a close relationship with the Integrative Biology Virtual Research Environment (IBVRE) in Oxford . IBVRE has been involved with the development of the portlet, producing a list of requirements (see below) validating screen designs, testing a prototype and suggesting suitable users for test cases.
A functional specification for the alerting portlet was drawn up. The portlet was defined as 'an SPP facility designed to provide a means for delivering timely notification of update information of various kinds, for example: details of new bibliographic records, new records to the IRC catalogues, news items, additional services such as events, call for papers reminders, etc.' The document also gave a definition of alert preferences (currently called 'subscriptions') as entities comprising 'a unique ID, the user ID, a query string, a set of targets and a set of delivery preferences defined by the Portal User (i.e. e-mail address, RSS news channels, alert frequency, etc.)' The output of the alerting portlet (the 'alert') should comprise 'a unique ID, a search results list and the information prepared by additional services and the newsfeed service for the user'.
Other requirements related to what users could and could not do and defined some areas of functionality which were beyond the scope of the portlet (such as a search mechanism and a user profiling mechanism).
There were also three requirements relating to technology:
In addition, IBVRE independently identified its own requirements for an alerting tool, which turned out to be covered by those already drawn up in the functional specification for the SPP portlet .
The following additional requirements were also agreed with IBVRE:
The alerting portlet has been designed to keep to these specifications.
The portlet is written in Java. It has been designed in the first instance to be used within standards-based portals (such as uPortal) as it conforms to the JSR 168 portlet standard; it is also expected to conform to the WSRP portlet standard. It uses the following libraries and frameworks: Spring 2, Hibernate 3, Jena 2.5 . The quickstart is bundled with the relational database HSQLDB 220.127.116.11 and the JMS message broker ActiveMQ 4.1.1 . The portlet also requires: JDK 1.5 or greater; a JSR 168-compliant portal; a JMS 1.1-compliant Message Broker; a relational database and appropriate JDBC driver; a servlet container, such as Tomcat 5.5.x .
When users first open the portlet, they are asked for their name and email address and invited to create a new subscription. The subscription options are of two kinds:
It is possible for a user to have multiple subscriptions. This is likely to be desirable if the user has diverse interests or if the maximum number of resources in each alert is set at a low value by the administrator (the default is 20).
The email message that notifies users of publications which match the keywords and data sources specified in the subscription is in the following form:
In May 2007 a draft version of the alerting portlet was made available to selected users for testing. This used a restricted data source of a selection of medical journals from PubMed Central , and allowed users to receive alerts as emails rather than on logging into the portal. After a trial period of about two weeks, the users were asked about their experience of using the portlet.
A copy of the portlet was also supplied to the manager of a university portal service to test how easily it could be installed.
User 1 is medical researcher working at a major U.S. university. This user successfully set up a subscription and started receiving alerts. User 1 did not usually use portlets, but found the alerting portlet to be a useful way of getting information about areas of interest, preferring it to redoing saved searches and to RSS. The user described it as 'straightforward and intuitive' and that he expected to use it in future, but from a central source rather than a more local portal.
The presentation of results was good, and the direct links to PubMed in the alerts were especially appreciated. User 1 suggested that there should be more online help on the portlet, perhaps as a 'what's this?' link or a few words on the screen. It would be especially useful to have help on selecting by subject for a subscription, explaining what a 'data source group' is and what happens if you select nothing.
Suggestions for improvement focused on the selection of journals which could be included in a subscription. This user had research interests that crossed boundaries between subject areas and so he would like to be able to create and re-use his own customised list of the journals which he regularly uses. Failing this, it would be good to be able to copy a subscription and edit it to create a new one. Repeatedly compiling a list of the same journals for each subscription is laborious, especially because navigating through the list of journals is not easy. It was suggested that some aids to navigation could be added: searching for a word/phrase, jumping to a given letter, or being able to choose the number of journals visible on screen at one time.
User 1 also suggested that alerts could be consolidated into one feed (with duplicates removed), like an RSS feed. Some further comments came from another test user: a doctoral student at a British university, working in bioengineering and based in the computer laboratory. This user thought the idea behind the portlet was very good and liked the interface, saying that it 'had a nice format and easy window controls'.
This user raised one important issue, which was that it should be possible to check and/or amend one's user details. Online help on creating a subscription would also be useful.
Another suggestion was to be able '[to run] the filter on previous days to see how many hits I got'. This would have allowed the user to see how useful different combinations of keywords (for example) would be.
This user works on the portal team in the computing service at a large British university, and has written a number of portlets. Here the brief was rather different: the user's evaluation of the portlet also included setting it up on an instance of uPortal which mimicked the university portal in other respects and commenting on any technical issues raised by this.
The user found that the portlet installed easily, but would have welcomed more transparency about some of the configuration options, and information on how to alter them. For example, the harvester is set to start at 35 minutes past the hour; it would be desirable to be able to change this, so that harvesting could be tested quickly during the installation, and so that if different installations of the harvester used the same resource, that resource need not come under excessive strain once an hour. Other needs included information on how to port to other databases such as Oracle.
The installation bundle was felt to be large at 118 Mb and Maven 2 was suggested as a way of reducing this . A more serious concern was that when the portlet was running, it could be heavy on CPU and bandwidth under certain circumstances, an issue currently being investigated by the development team.
This user too requested more documentation, particularly in the areas of how to configure the portlet when it is initially installed, interpretation of the log files and a general introduction to the architecture of the portlet. It was thought highly desirable to have an alternative way of delivering alerts other than via email, where the interface to SMTP servers can cause problems.
This user also had some observations to make about the user interface. Like the user in Case 1, it was felt that the long list of journals should be made more navigable, perhaps by including a clickable A-Z, a search box or an option to jump to a given page. A navigation toolbar should also be included to enable the user to move between different functions such as editing contact details and editing subscription details. From a local point of view, this would also make the portlet resemble others in use on the user's university portal. Some of the terminology was also thought to be potentially confusing, particularly 'data source' and 'subscription'.
The user testing exercise confirmed a demand for several changes which could be incorporated into the portlet if further work is done on it: for example, the option of seeing alerts on logging into the portal. Users should to be able to access and edit their own details. Online help, particularly in the area of managing subscriptions, would make the portlet easier to use.
The testers made further suggestions for improvement; their suggestions included making the available options more visible to the user, allowing users to test their subscriptions and providing a better way of navigating multiple data sources.
The software is being placed in open-source repositories. It will be in the public domain and so open to further contributions of code and documentation.
A beta version of the portlet has been placed on Sourceforge site for open-source software  and will be made available for download in appropriate repositories (POST has been suggested) 12] and will be promoted via email lists and publicity at relevant conferences. Its target audience in the first instance is portal managers, developers and administrators.
Consultation with potential users has been important in the development of the alerting portlet, from the initial decision to develop it to determining details of its final interface and functionality. It has the potential to be a useful addition to the growing number of open-source portlets.
I am grateful to Jasper Tredgold of ILRT for comments on an earlier draft of this article.