Web-based management of subject guides for academic libraries
anthropology • english literature • history • american studies • psychology • your guide here!
ResearchGuide is a web environment allowing creation and delivery of online subject research guides for academic libraries. Benefits include standard look and feel of guides and centralized management of content. ResearchGuide also creates information pages about librarians who maintain the guides.
It was a collaboration between two people, one a librarian and the other a student, at the University of Michigan. The librarian was looking for a way to deal with all kinds of HTML pages all over the directory structure. Also, reference librarians have different levels of familiarity with HTML. This system aims to make things easier by providing a web-based interface [try it] for creating and updating guides, and a standard look and feel across all guides.
All data is stored in a database. A web interface is used to enter and update the data. When library patrons look at a subject guide or a page about a subject specialist, these pages are dynamically created. PHP runs database queries and inserts the results of those queries into HTML pages which it then serves up to the browser. The user doesn't need to know this. Most librarians won't either. But it will be important to have someone around who knows something about PHP and MySQL databases. For more information check out the tour and the architecture diagram.
Libraries seem to face a common challenge in creating research guides, and here's a piece of software that handles it. I sought out permission to make this code available as open-source software. Thanks to the University of Michigan for agreeing to make it available under the MIT license after supporting development of the application.
PHP is the web-scripting language that creates the web pages, based on queries to a MySQL database. Here's a dump (from PHPMyAdmin) of the MySQL database structure.
There are two levels of users: specialists and site administrators. Specialists have a lower level of authority. They can modify guides for which they are the designated author (assigned by a site administrator). A site administrator can add, change, or delete any guides.
The authorization system is built around these assumptions: 1. There is an admin directory which, whenever anyone accesses it, requires authorization through an outside system. That's right, there is no internal authorization system. This is admittedly a weakness of the current design (well, a weakness if you're not the University of Michigan. It was built around UM's internal authorization system but may require customization for implementation elsewhere). Administrators are assigned by listing them in the "admin" table of the database.
Sure (possible other places ResearchGuide might be useful: public libraries and schools).
Yes. That would take some revision of code -- not too difficult if someone has a moderate level of experience with PHP/MySQL applications.
PHP installed. MySQL installed. Some programming expertise in PHP/MySQL. Readiness to provide some instruction to librarians and administrators using the system.
Yes.
1. Unless your authorization system works the same way as it does at the University of Michigan, you may need to come up with a system that works for you locally. For more on the authentication system, see the documentation. (But in the source code, the auth system is initially disabled so this should not be a barrier to testing on, say, a development server.)
2. It's less than ideal that specialists have to be added by a site administrator and assigned to a guide before they can edit it. This may be an inconvenience.
3. You can put categories into any order you wish. But within each category, resources are sorted alphabetically. In other words at present you cannot customize the order of resources within a category.
It has been very difficult, on top of a full-time job, for me to find time to prepare this code for release. However if there is interest in continuing development, I would certainly consider staying involved. Or maybe handing over the lead-developer role to someone else who wants to run with this. Yeah, that's sounding a lot more reasonable.