Starting with a presentation from Matti Shem Tov – the CEO of Ex Libris. First point of business is following up on the recent press release announcing that the private equity firm ‘Francisco Partners’ have wholly acquired Ex Libris.

The message from Matti is that this changes nothing in terms of the day to day business or management. It simply gives secure financial backing to the company, which will allow expansion, or acquisitions for the company.

Some impressive statistics – according to Newsweek 71 of the top 100 univiersities in the World use at least one Ex Libris products. SFX seems to be the best selling at the moment, with over 1000 customers – and to ‘celebrate’ together with eIFL.net, they have dontated a copy of SFX to the University of Lesotho (in southern Africa).

To support this donation, Ex Libris are asking the community to share their expertise to help with the implementation and use – you can register at http://www.exlibrisgroup.com/sfx1000.htm

Another poster session – some interesting stuff this time from Budapest and Berlin. They are using php and SQL to produce web based reports. They’ve created a structure so that you can easily extend the available reports.

You first define a form for variable input, and then the SQL – using the entered variables where appropriate. This makes for an extendable system, without requiring detailed knowledge of php – and results can be output in html, excel, csv etc.

Perhaps just as interestingly for us is that they’ve used an open source package called ‘ahk’ (auto hotkey), to allow for easy movement between the results of these reports and viewing related information in the Aleph client. We might be able to use something like this to enhance our ‘liaison dashboard’ – which is an application built with MS Access and ODBC to Aleph to allow display of information not easily available in the Aleph client (or at least not on a single screen).

Done by Nagy Elemer Karoly from Budapest and Leo Krauthausen from Berlin (eknagy at omikk.bme.hu, krauthausen at ub.fu-berlin.de)

Another poster session – some interesting stuff this time from Budapest and Berlin. They are using php and SQL to produce web based reports. They’ve created a structure so that you can easily extend the available reports.

You first define a form for variable input, and then the SQL – using the entered variables where appropriate. This makes for an extendable system, without requiring detailed knowledge of php – and results can be output in html, excel, csv etc.

Perhaps just as interestingly for us is that they’ve used an open source package called ‘ahk’ (auto hotkey), to allow for easy movement between the results of these reports and viewing related information in the Aleph client. We might be able to use something like this to enhance our ‘liaison dashboard’ – which is an application built with MS Access and ODBC to Aleph to allow display of information not easily available in the Aleph client (or at least not on a single screen).

Done by Nagy Elemer Karoly from Budapest and Leo Krauthausen from Berlin (eknagy at omikk.bme.hu, krauthausen at ub.fu-berlin.de)

An interesting poster session from Roskilde Bibliotek in Denmark. They have started to accept online payment for Aleph fines. They do this very simply with a 3rd party service called ‘DIBS’ (http://www.dibs.dk) which handles the credit card payment, and communicates with Aleph.

The workflow is that the user logs into Aleph, sees payments due, and chooses to pay them. They click a button which passes them onto the DIBS website, with the correct amount ready to pay. They enter their details (credit card number etc.) and click ‘pay’, and DIBS accepts payment, and passes details of the payment back to Aleph.

It wasn’t completely clear how this last bit of communication was achieved – apparently programmed by Fujitsu (who are the Aleph distributers in Scandanavia), but the presenter though it had been done using the x-server.

We’ve always been slightly wary of taking card payment for fines, partly because of the transaction charge is high on relatively small amounts. However, in this case, they were passing the charge on to the user (approximately 10-12 pence per transaction), and this seems to be accepted.

I’m not sure this would be accepted in our library, but perhaps we could support this when the fine is over a certain amount?

An interesting poster session from Roskilde Bibliotek in Denmark. They have started to accept online payment for Aleph fines. They do this very simply with a 3rd party service called ‘DIBS’ (http://www.dibs.dk) which handles the credit card payment, and communicates with Aleph.

The workflow is that the user logs into Aleph, sees payments due, and chooses to pay them. They click a button which passes them onto the DIBS website, with the correct amount ready to pay. They enter their details (credit card number etc.) and click ‘pay’, and DIBS accepts payment, and passes details of the payment back to Aleph.

It wasn’t completely clear how this last bit of communication was achieved – apparently programmed by Fujitsu (who are the Aleph distributers in Scandanavia), but the presenter though it had been done using the x-server.

We’ve always been slightly wary of taking card payment for fines, partly because of the transaction charge is high on relatively small amounts. However, in this case, they were passing the charge on to the user (approximately 10-12 pence per transaction), and this seems to be accepted.

I’m not sure this would be accepted in our library, but perhaps we could support this when the fine is over a certain amount?

Trying to hammer out how exactly the ‘product working groups’ (PWGs) will work is the aim of this afternoon’s sessions. Unfortunately not the most thrilling business, but clearly essential for the user group to work well.

The constitution of IGeLU leaves a lot of flexibility to the PWGs about how they structure themselves, and currently it looks like the Aleph one is going to bear some resemblance to the old ICAU structure, with ‘module co-ordinators’ looking at specific areas of functionality.

This makes some sense, as Aleph is a large and complex product. However, it isn’t entirely clear what roles these co-ordinators will take, and what should be regarded as worthy of having a ‘co-ordinator’. This used to be based very much around the Aleph enhancement process, but this is also now up for discussion, which leaves a bit of a ‘chicken and egg’ situation.

An interesting progression is that ELUNA (the North American group) have decided to change their Aleph enhancement process so that they work with Ex Libris on a single area of functionality each year, rather than spreading effort over a larger number of small requests.

I have to say I’d really prefer to see IGeLU go down this route, as when I look at how tiny pieces of functionality crept slowly into the product (and are sometimes not even implemented to the satisfaction of the original requester), I don’t think the effort that went into the old ICAU enhancement process was ever worth it.

Trying to hammer out how exactly the ‘product working groups’ (PWGs) will work is the aim of this afternoon’s sessions. Unfortunately not the most thrilling business, but clearly essential for the user group to work well.

The constitution of IGeLU leaves a lot of flexibility to the PWGs about how they structure themselves, and currently it looks like the Aleph one is going to bear some resemblance to the old ICAU structure, with ‘module co-ordinators’ looking at specific areas of functionality.

This makes some sense, as Aleph is a large and complex product. However, it isn’t entirely clear what roles these co-ordinators will take, and what should be regarded as worthy of having a ‘co-ordinator’. This used to be based very much around the Aleph enhancement process, but this is also now up for discussion, which leaves a bit of a ‘chicken and egg’ situation.

An interesting progression is that ELUNA (the North American group) have decided to change their Aleph enhancement process so that they work with Ex Libris on a single area of functionality each year, rather than spreading effort over a larger number of small requests.

I have to say I’d really prefer to see IGeLU go down this route, as when I look at how tiny pieces of functionality crept slowly into the product (and are sometimes not even implemented to the satisfaction of the original requester), I don’t think the effort that went into the old ICAU enhancement process was ever worth it.

At the moment in the UK we have an ‘Aleph’ Usergroup and a ‘SFX/MetaLib’ Usergroup. The former is quite formal, and the latter more informal.

With the new arrangements internationally, I do wonder how long this will continue to be practical. It looks like the next AUG and SMUG meetings will be held back-to-back in the UK, with hopefully some overlap discussion.

I’m really in favour of one annual meeting – more conference like really – for all Ex Libris users in the UK – more like the ELUNA conference in the USA, and with the large number of Ex Libris customer’s in the UK, I do think this is a viable suggestion. However, there are practical problems in organising a single large conference, whereas the small AUG-UKI meetings three times a year can be managed more easily perhaps (although finding volunteer sites with big enough venues for this is also a problem sometimes).

At the moment in the UK we have an ‘Aleph’ Usergroup and a ‘SFX/MetaLib’ Usergroup. The former is quite formal, and the latter more informal.

With the new arrangements internationally, I do wonder how long this will continue to be practical. It looks like the next AUG and SMUG meetings will be held back-to-back in the UK, with hopefully some overlap discussion.

I’m really in favour of one annual meeting – more conference like really – for all Ex Libris users in the UK – more like the ELUNA conference in the USA, and with the large number of Ex Libris customer’s in the UK, I do think this is a viable suggestion. However, there are practical problems in organising a single large conference, whereas the small AUG-UKI meetings three times a year can be managed more easily perhaps (although finding volunteer sites with big enough venues for this is also a problem sometimes).

ELUNA is ‘Ex Libris Users of North America’. Because the North American market is an important one to Ex Libris, and because ELUNA (previously NAAUG – North American Aleph Users Group) is large, they have traditionally had a large influence over development – in a way most national user groups have not.
To be honest, this tends to work well for RHUL, as ELUNA is exclusively (I think) academic libraries, and there are quite a lot of issues in common with the UK University library sector.
I suspect that there will continue to be a large amount of agenda setting from ELUNA, but with at least one ELUNA member also on the IGeLU steering group, this should work OK I think.