The SPP Alerting Portlet: Delivering Personalised Updates
Background: Identifying a Need
SPP phase I [1] 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 [2].
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 [3]. 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 [4]. 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.
The Portlet
Specifications
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:
- the service should be an ‘open implementation’ accessible from different hardware/software platforms using standard unmodified Web and email clients.
- the development of the service should allow for incremental future development. For example, to increase the number of email formats supported.
- the development of the service [was] expected to involve the use of object-oriented programming language and open-source technologies.
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 [5].
The following additional requirements were also agreed with IBVRE:
- a user would be able to have multiple alerts which they could manage through the portlet interface.
- an alert would consist of the following: keywords, one or more data sources (e.g BMJ), one delivery format (e.g. email, RSS), a frequency, an active/inactive flag.
- a data source could be a subset of a repository (such as a journal).
- an alert would be built by running the alert’s query (with keywords joined together by AND) against the selected data sources.
- the amount of text available to search would depend on the source. (Our test portlet has used PubMed and searches titles and descriptions.)
- an alert would contain items that had arisen in the data source since the last execution of the alert, up to a configurable maximum.
- each item in the alert would include a synopsis and a link to the alert item source.
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 [6]. The quickstart is bundled with the relational database HSQLDB 1.8.0.7 and the JMS message broker ActiveMQ 4.1.1 [7]. 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 [8].
Figure 1: Architecture of the SPP Alerting System
The User Interface
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:
- Subscription details. These are the name of the subscription, a description of it, keywords which will be applied, method of delivery, frequency of delivery and whether the subscription is active. The name and description of each subscription are for the user’s own information. The keywords are matched against the abstracts of articles; articles matching those keywords will be included in the alerts. The delivery options are to receive the alert(s) as email messages or alternatively on logging into the portals (at present only the former has been implemented). Email messages can be sent out daily, weekly or monthly.
- Data sources. All data sources are listed and the user may optionally filter by repository, then select one or more data source groups (in the test version, publications in a particular subject area), or select data sources (in the test version, individual journals) individually. The selected data sources are listed at the bottom left of the screen.
Figure 2: Creating a subscription
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 Alerts
The email message that notifies users of publications which match the keywords and data sources specified in the subscription is in the following form:
- a greeting by name
- introductory text saying which subscription the resources are from
- list of resources, with the following information for each: title, beginning of description (first 250 characters), date, URI. If more than 20 resources have been found, only the first 20 are shown.
- a reminder of the URI of the subscription at the end of the alert.
Test Cases
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 [9], 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.
Case Study 1: The End-user
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.
Case Study 2: The Portal Administrator
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 [10]. 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’.
Development Possibilities
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.
Hosting the Portlet
A beta version of the portlet has been placed on Sourceforge site for open-source software [11] 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.
Conclusion
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.
Acknowledgements
I am grateful to Jasper Tredgold of ILRT for comments on an earlier draft of this article.
References
- SPP phase II http://www.portal.ac.uk/spp/
- User Testing Report http://www.portal.ac.uk/spp/documents/testing/phase1/usertestingreportv3.doc
More detail in de la Flor, G, Summary and Analysis of User Testing and Focus Group Sessions
http://www.portal.ac.uk/spp/documents/testing/phase1/user/BIOME-report-03/Summary-AnalysisV3.1.doc - These correspond to 2.3.2.4 and 2.3.2.2 in the Subject Portals Project final report (phase 1)
http://www.portal.ac.uk/documents/phase1/finalreport/finalreport.doc - Integrative Biology Virtual Research Environment (IBVRE) http://www.vre.ox.ac.uk/ibvre/
- IBVRE Third Party Tool Evaluation 7.3: Literature Alerting http://www.vre.ox.ac.uk/ibvre/index.xml.ID=literaturealerting
- Spring Framework http://www.springframework.org
Hibernate http://www.hibernate.org
Jena http://jena.sourceforge.net - HSQLDB http://www.hsqldb.org/
ActiveMQ http://activemq.apache.org/ - JDK http://java.sun.com/javase/downloads/index.jsp
Tomcat http://tomcat.apache.org/ - PubMed Central http://www.pubmedcentral.nih.gov/
- Maven http://maven.apache.org/
- SPP Portlets http://www.spp.opensource.ac.uk/
- Portlet Open Source Trading http://portlet-opensrc.sourceforge.net/