5 November 2010
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
MERI
collected using SUSHI/COUNTER; licence and financial information can be tracked; reminders can be set for individuals to perform certain tasks within workflows
ERM demos NOV 05, 2010 01:29A.M. For the past few weeks we have had some demos of various ERM systems. Some brief descriptions are below:
BLACKLIGHT AT HULL’S BLOG
Swetswise ERM as a Service: This system builds upon services already available through Swetswise; a benefit for existing Swets customers is that a lot of the subscription information, including licensing and financial information, is already in the system. This can also get usage statistics from publishers and present them in userfriendly formats
OCT 31, 2010 10:08A.M.
blacklightathull We’re pleased to announce that we have managed the last major task of the project – a union search across the library catalogue and a repository index. We’ve taken a small extract from our repository and re-indexed it using field names in common with the library Solr index to produce a single, combined index.
TDNet Core ERM: looks after the ‘core’ processes of electronic resource management – acquisition of resources, licence information, access, statistics and contact information. It’s possible to link to licences from their A-Z list; we were shown the front-facing element of this system. It is possible to import and export data to/from other systems
We’ve also solved a little mystery that we had over why the facet counts didn’t match the content of our libraries! Hull’s libraries don’t use the default MARC field for format and language and for BL@T we were indexing the wrong one… Oops!
Innovative Interfaces ERM: designed to manage the whole life-cycle of electronic resources, from identification and trials, to purchasing the resource (or subscribing to it), and then managing access and harvesting of usage statistics using SUSHI, providing information such as cost per use for renewals decisions etc. The system can be populated using data from e.g. an SFX knowledgebase.It can be used as an integrated part of Millennium LMS or as a stand-alone system; at the moment there are no sites using the ERM module with Talis,
KEVEN
What’s wrong with VuFind: a developers view
Serials Solutions 360 Manager: tracks changes in titles and licences; deals with trials including reminders when the end of the trial period is approaching; The system can include retrieval of statistics which will work with SUSHI and COUNTER. It’s possible to display key points from licences; also to search for resources using alternate titles (abbreviations etc) There is also an online community/support centre
OCT 29, 2010 11:37A.M. VuFind is pretty good Let me start by saying, that this is not the whole story, there are plenty of good things about VuFind. But thats not the point of this post, you can easily find plenty of blog posts on the merits of VuFind. Neither is it an analysis of VuFind’s web interface, sure it’s not perfect and a lot of the work we’ve been doing is to make it better, but again I’m not going to go into that now (may be at some point). The aim of this post is to highlight some of the problems I’ve found with VuFind’s code base as a developer trying to expand it and some ideas about how these things could be improved or fixed.
Ex Libris Verde: Can be a stand-alone system, integrates with other Ex Libris products (SFX etc). This system can manage trials, with the option to add notes on reasons to subscribe etc. Licence details can be added manually or a link to website, pdf etc can be added. Uses SUSHI when collecting stats EBSCO NET ERM: This system works best with resources purchased through EBSCO; it can be automatically populated with all the subscription information. This system is fully customisable, enabling users to match field titles etc in the ERM to existing systems (LMS etc). it is able to work with a library’s catalogue, link resolver etc. Stats are
Name spaced actions Overriding or extending the service actions that VuFind comes with
1
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
5 November 2010
without hacking core code is impossible. We created a hack that looked in a specified folder before the default services folder for the class file, its worked ok but we were replacing the original file, which means copy and pasting existing code. And that means managing any changes in that.
controller and model. If its common code it either belongs in the model or in a base controller class.
The best solution would be to allow plugins that can include actions (either replacements or new ones) that are name spaced with the plugin’s name and can extend the original action they are replacing. In order for this to work well it would need:
ALL html generation should be done by the view (smarty templates) if there is a piece of code you are repeating in your templates then it should go in a helper (Smarty function). Ideally the view will only be called on once. The model shouldn’t being calling the view for html, and then passing that html to another piece of the view (as the Record service does). Everything should be packaged up into variables and the view asked to do its thing. There may be some cases where this isn’t possible or a good idea, but generally context is very important in design and the first call to the view has no idea where it will eventually end up.
Model and controller passing html to the view
A better autoloader I wont going into the merits of having a proper autoloader, but will to say it makes life a lot easier especially when you are extending functionality by extending classes. VuFind has two “autoloaders” one that loads service actions and another that loads classes out of the ’sys’ directory. Neither make it easy to drop new class in with out placing them in core directories.
Outputing from the launch method Currently $interface->display() is at the end of most actions’ launch method, which prints the output for the request. This is a pain if you are in one action’s launch method and you wish to call another actions launch method to do some logic (although really this shared logic should be in the model) but wish to output your own display. You can use output buffers but its far from elegant and given the prolific use of exit; often fails. Which leads me to:
Routing I’m guessing the MyResearch area is so called because it started as favorites: which would be someones research, but from a UX point of view it should really be called Account. We’ve hacked /Account to redirect to /MyResearch but really this should be done via a router that has a config file defining what urls are dispatched to what service actions and with what arguments. This would also remove the need to have more than one rewrite rule in the .htaccess and present an opportunity for non english speaking libraries to have urls in their users native language.
Avoid using exit() Method calls should end naturally or exit in a way that doesn’t kill the process, basically giving the caller a chance to respond to the output. That means not calling exit: If everything went OK return; (even if its null which return; will do with out a value) if not throw an exception.
Get rid of Smarty With the current state of PHP the reasons for using smarty are very much redundant. PHP is already a very good templating language, there is no need for Smarty. I wont go into the details of why Smarty is bad (here’s most of it), but the key points are:
Use tabs for indentation
• Smarty doesn’t provide anything that other templating frameworks with php syntax provide
This is a more a convention and one of personal preference, but using tabs rather than spaces for indentation gives developers more options. IDEs tend to let developers define the tab display size, so tab indents can look like 2 or 4 space or whatever the developer wants. And spaces are a pain to fix when it all goes wrong.
• Smarty syntax is often more obscure or longer than php
Don’t escape in the view
• The act of compiling smarty to php is another layer of complication and overhead that isn’t needed
It’s really important to escape output, but I don’t think the view is the best place for it. Firstly it’s one more thing for the template coder, who may not be familier with the logic code and whats except-able and whats not, to worry about. Secondly the act of escaping content requires some logic to be performed and that doesn’t belong in the view. (Formatting, things like dates and numbers, should be left to the view however).
• Debugging can be a real pain (errors are reported in the compiled code not the template code) Better separation of code Model and view creeping into the controller
JavaScript that interfaces with the DOM should be in the theme
There are some examples where code that belongs in the model or view creeps into the controller. For example the services/MyResearch/lib/FavoriteHandler.php does the work of
The structure of the DOM is dependant on the current theme, therefore any JavaScript that interfaces with the DOM should be part of the theme. More over where ever possible the JavaScript that interfaces with the
2
Today’s Tabbloid PERSONAL NEWS FOR b.showers@jisc.ac.uk
5 November 2010
DOM should be separated from the JavaScript that doesn’t , limiting the amount of code the theme has to implement. Flash messages This is more a UI feature that we didn’t get time to implement, and I know I said I wouldn’t be covering them, but I’m going to squeeze it in anyway because it would need some foundation core code to make it consistant. Good UX requires users get feedback on their actions, often this mean seeing the page has changed when they click a link. But a good system will make it painfully clear whether they action was successful or not and if not why not. This usually means providing flash messages for actions that don’t take the user to a new location, or the new location doesn’t show the change they affected clearly. For example when submitting a search, flash messages aren’t necessary because the fact I’m looking at a results page already makes it painfully clear that my search was successful. If I delete a record from my favorites however, sure I’m redirected back to the favorites page and that record will be missing, but on a page of records that isn’t obviously clear to a user at first glance. A new architecture is needed A lot of this stuff (better mvc, autoloading, replacing smarty, routing, flash messages) has already been done very very well by a number of php frameworks. I believe replacing VuFind’s /web directory with a restructured architecture built on any one of the most popular php frameworks is the best way to build a manageable and stable code base that the whole community can contribute to. It looks like VuFind has been implemented by somebody who understands at least the basic principle of MVC, but a lot could be done to make the code base easier to extend. I think the guys at Villanova have done a sterling job of building an incredibly user friendly system, However if it’s open source community is to thrive and the code base grow in a long term manageable way some big changes need to be made to VuFind to make it “developer friendly”. Report post
3