archive.blogs.harvard.edu/inscriptiodemo

Inscriptio:  Interactive carrel seating application
Ann-Marie Costa
Cheryl McGrath
27 October 2011

Project summary
·         Accomplishments

The Interactive Carrel Seating application aka Inscriptio successfully launched in the Fall of 2011.  What was once a time-consuming process involving an excel spreadsheet, paper applications, and thousands of pages printed yearly of carrel packet information is now a streamlined online function.  Where before staff had no reporting mechanism for available or expired carrels and did have the challenge of explaining to patrons that even though the carrel they want is physically empty of books it is actual reserved by four of their peers, thanks to Library Lab and the Berkman Center we now have an online reservation system with strong visual elements to assist patrons in choosing the best option for research adjacencies.  We estimate that this application will ongoing save five weeks of an FTE and $800 in supplies per year, making this a green initiative.

Eligible patrons are now able to apply for a carrel or hold shelf in Widener or Pusey library via an online application.  Once registered, they can navigate their way through floor maps of the libraries, showing which carrels and hold shelves are available.  They can cross-reference availability with subject classification adjacencies, ensuring they are as close as possible to their research area of interest.  Patrons can then choose a carrel, much like one chooses a seat on an airplane or train.  Staff run reports on pending reservations, approve the patron, and an email is generated, sending the patron information on how to charge items to the carrel/hold shelf and any relevant information such as the locker combination for the carrel locker.  Patrons assigned to a particular carrel can communicate with each other to schedule use times via a bulletin board built as part of the application.  As patrons reach their chosen reservation end date, the application will automatically send an email with renewal options.  Staff can run reports on expired reservations so that the space can be cleared and made available for future use.

As the project was developed, staff were inspired to create a workaround in Aleph, streamlining the process of charging items to carrels/hold shelves for staff and patrons.  In the past, when patrons applied for a carrel, they received a separate library card allowing them to charge material to the carrel.  Patrons then had to carry around two cards (their HUID and their carrel card) when coming to the library to engage in research.  By populating the Additional Notes Field One in Aleph with the patrons’ carrel number and the Aleph psuedo-patron card number for the corresponding carrel, we were able to push that information to the loan screen in the patron details box.  This eliminated the need for a separate carrel card.  Patrons now show their Harvard issued ID at the Circulation desk, and from there the staff copy and paste the carrel number so that materials are charged appropriately.

Prior to launch this Fall, staff entered 498 existing reservations; post-launch, 272 patrons have reserved carrels and another 113 have been registered but have yet to reserve a carrel.  Carrel reservations typically follow a two year pattern based on length of study for graduate students.  Statistics over the past five years show a consistent pattern of alternating increase/decrease with an 11% spread.  As FY11 saw the greatest increase in carrels in the past four years, it is consistent that on average, application for carrels using Inscriptio for FY12 are down about 11%.  We expect that FY13 will show a corresponding increase in carrel applications—if this does not hold true to the pattern on the past five years we will need to investigate further. Staff have received no negative feedback from patrons, and have been astonished at how seamless it was to go into production at a high-traffic time of year with a brand new tool. We have a netbook available for people to use who come to apply in person.
·         Challenges – please explain anything you couldn’t do

Prior to launch, it was determined that the original goal of having patrons use their HUID and PIN to authenticate into the system would not be in place by the intended launch date.  A work-around was established where patrons used an edited version of the previous online application form.  Once staff received the contents of the form in email, they verified eligibility and created an account for the patron in the application.  The account creation generated login and password instructions, and the patrons were able to then fully access the application.  We decided to implement the HUID/PIN authentication piece in December, when requests for carrels and hold shelves in Widener and Pusey libraries experience a lull.

The application was named Inscriptio: latin for address.  Not particularly self-explanatory, however, since the application may be used at a variety of Harvard Libraries for carrel, lockers, hold shelves, study rooms we had a hard time finding a name that was relevant and yet encompassing.  Any and all naming ideas are welcome.

·         Next steps

It was the original intention to launch the application for several libraries at once, and we hope to do that in the coming year.  Development of a macro is under way to facilitate the copy/paste function in Aleph for charging materials to a carrel/hold shelf.  We have also drafted a user survey based on our own observations and initial user feedback, including questions to rate the interest in patrons being able to access a list of items charged to their carrel/hold shelf from the application.  Yale visited the Widener Privileges office in September and is interested in using the application and further partnering with Harvard on developing the application further.

·         Budget spent

Total development hours:

349.2

Total development cost (including salary, benefits, overhead, and administration):  $43,137.44

·         A list of any publicity you did, e.g., articles, blog posts, podcasts, etc.
·         A list of any presentations you gave that involved your project

Information on Inscriptio is available here:

blogs.law.harvard.edu/inscriptiodemo
http://www.screencast.com/t/62rnlxoI
https://inscriptio.harvard.edu/demo
Login:  admin at example.com
Passcode: kcnjs7mjwgy
https://github.com/berkmancenter/Inscriptio

Inscriptio has been demonstrated at the following:

Harvard University Inaugural IT summit June 23, 2011
Library Lab Project Showcase August 4, 2011
Yale visit to Harvard campus September 28, 2011
ENUG: Ex Libris Northeast Users Group October 27, 2011
Library Lab Project Showcase October 27, 2011

http://www.screencast.com/users/studesco/folders/Inscriptio%20Demo

Inscriptio is a tool for libraries and patrons to manage addresses such as carrels, hold shelves, lockers, and studies.

To play with a demo of Inscrptio, login here:

https://inscriptio.harvard.edu/demo
Login: admin@example.com
Passcode: kcnjs7mjwgy

Inscriptio Requirements
System Requirements

* Ruby 1.8.7
* Rails 3.0.5
* A postgresql 8.x database server. Other databases MAY work (e.g. mysql), but they are untested.
* A webserver capable of interfacing with Rails applications. Ideally, apache or nginx with mod_passenger installed.
* Linux or OSX. Linux would be easier.

Application Set-up Steps

* Get code from: https://github.com/berkmancenter/Inscriptio
* Run bundle install. You will probably have to install OS-vendor supplied libraries to satisfy some gem install requirements.
* Create the database and run migrations, modifying “config/database.yml” to suit your environment.
* Modify environment.rb for action_mailer config
* Run bootstrap rake tasks:
rake bootstrap:inscriptio:run_all
* Create cron job to automatically run rake tasks for sending out notifications expiring and expired reservations as well as deleting bulletin board posts after post lifetime:
rake inscriptio:cron_task:delete_posts
rake inscriptio:cron_task:send_expiration_notification
rake inscriptio:cron_task:send_expired_notification
rake inscriptio:cron_task:run_all

Order of Operations for Fresh Install¶

* Sign in as admin
* Create User Types (may change once PIN is in)
* Create School Affiliations (may change once PIN is in)
* Create library
* Create floors
* Create asset types
* Upload/create assets (for upload you will need floor and asset types ID’s)
* Add assets to floor map (remember to hit ‘Apply’ button to save asset on map)
* Go to ‘Reservation Notices’ section and click ‘Generate Notices’

Testing Scenarios¶

Admin Functions¶

Libraries:

* Create new libraries
* Edit and delete existing libraries
* View all subject areas for a library (on library main page)

Floors:

* Create new library floors
* Edit, delete and reorder existing library floors

Subject Areas:

* Create new subject areas
* Edit and delete existing subject areas

Call Numbers:

* Create new call numbers
* Edit and delete existing call numbers
* A call number can be associated with a subject area not is not required

Reservable Asset Types:

* Create new reservable asset types
* Edit and delete existing reservable asset types
* Can have specific user types associated with it but not required

Assets:

* Create new reservable assets
o If the min/max reservation time, max concurrent users and reservation time increment are not entered for an asset, the fields from the asset type are inherited
* Edit and delete existing reservable assets
* Admins can view existing reservations by asset
* Admins can batch upload assets by importing a CSV file

Reservations:

* Can create a reservation for a user
* Can edit and delete existing reservations
* Asset drop-down will be pre-populated if reservation form was reached going through the asset page (alternative to using the top navigation)
* Can mark reservations as approved
* A seat is considered unavailable if there is a reservation whose end date is greater than today
* A reservation only claims a seat if it has been approved

User Types:

* Create new user types
* Edit and delete existing user types

Users:

* View all users and update user type and admin flag

Search:

* Users
* Libraries
* Floors
* Subject Areas
* Call Numbers
* Reservable Assets

User Functions¶

* Can create their own accounts
* Can view library information, floors within library and subject areas within library
* Can view assets, subject areas, and call numbers within a floor
* Can reserve an asset if there are seats available and the user has not already reserved that asset
* Reservation dates chosen must be greater than the min reservation time and less than the max reservation time (in days)
* Reservation end date will automatically be set to the last day of the month of the chosen end date
* Can edit and delete their reservations
* A user is considered a “current user” on the asset if their reservation end date is greater than today
* Can only view the bulletin board if their reservation has been approved
* Can post to their approved asset’s bulletin board

New file

Optional description
Add another file (Maximum size: 10 MB)
Cancel

Also available in: HTML TXT
Loading…
Powered by Redmine © 2006-2010 Jean-Philippe Lang

Carrel Object List

This was originally a google document developed collaboratively by project principals. This is still a work in progress and will evolve over time.
Library

A library:

* has many floors
* has an address, including latitude / longitude, URL and basic contact info
* has many reservable asset types
* has a bulletin board post expiration time

Floor

A floor:

* belongs to a library
* has a map, most likely a high quality PNG
* is ordered relative to other floors – meaning a different floor is above or below it.
* has many call numbers
* has many subject areas.
* has many reservable assets

Subject Area

A subject area:

* has and belongs to many floors
* has many call numbers
* has basic attributes like description and name

Call number

A call number:

* belongs to a subject area
* has and belongs to many floors
* has a code, description and other basic attributes

Reservable Asset

A reservable asset:

* belongs to a floor
* belongs to a reservable asset type
* has a location on the floor map – most likely an x y pixel offset to place it in the proper place.
* has many reservations
* has many users through its reservations
* has a section and number
* has a bulletin board
* has current users
* has a photo (optional)
* has a video (optional)
* has a minimum reservation time
* has a maximum reservation time
* has a reservation time increment – can only reserve in – say, 1 day or 1 week chunks.
* has a maximum number of concurrent users
* has a locker key / code (if defined in the reservable asset type)
* has general information, that’s probably merged into the welcome message.
* can be relinquished by the user reserving it, returning a slot to the reservable pool.

Reservable Asset Type

A reservable asset type:

* belongs to a Library
* has many reservable assets
* Has a name – carrel, locker, hold shelf, etc.
* Sets defaults for reservable assets – minimum reservation time, maximum reservation time, maximum number of concurrent users, reservation time increment, whether or not it has a code / key,
* Has options that effect the bulletin board – can have one? How long should posts live?
* has a photo
* has a welcome message, which may include follow-up instructions (Pick up your carrel reservation card here)
* has an expiration extension time period: the time before the expiration in which a user can renew a reservation for up to the maximum reservation time.
* has user types that can reserve this asset.
* has many Reservation Expiration Notices, which define the content and scheduling of reservation expiration messages. These messages can be related to either when an active reservation expires, or when a “reservation hold” is expiration. A reservation hold is a reservation that hasn’t been approved by a moderator.
* has a moderation flag – meaning, either the reservation goes through automatically without administrator approval OR an asset reservation must be OK’d by an admin.
* has a “moderation held” message. The welcome message can serve as the moderation approved message.

Reservation Expiration Notices

A reservation expiration notice:

* has a type – “hold” or “actual,” where “hold” is a notice for the reservation hold expiration times, and “actual” is a notice for when an actively reserved item is expiring.
* belongs to a reservable asset type.
* has a “days before expiration” attribute, which sets when this message is sent.
* has a message and a subject line
* has a reply-to
* is a multipart text/html message
* will template tags to substitute simple parameter like Library name, user name, date, etc.
* belongs to many reservations, but is only invoked when the “days before expiration” time is hit.

Reservation

A reservation:

* belongs to a reservable asset
* belongs to a user
* has a code to uniquely identify it
* has a start date
* has an end date
* has an approved flag, which means the reservation has been approved by an administrator.

Bulletin Board

A bulletin board:

* has many posts ordered by creation time
* belongs to a discussable asset – currently only a reservable asset, but could include a library.
* has many users through the reservable assets list of current users
* has a maximum “post lifetime”

Post

A post:

* belongs to a bulletin board
* belongs to a user
* has a creation time
* has a message
* has an (optional) image file attachment
* has many (optional) moderator flags
* has a “public” flag, allowing a post to be seen more broadly.

Moderator Flag

A moderator flag:

* belongs to a post
* has a reason – Abusive, Offensive, etc?
* belongs to user

Authentication source

An authentication source:

* has many users
* has many user types
* has an “authenticate” method that accepts user information and does a backend lookup returning a true or false if a user has authenticated properly to that user type.

User Type

A user type:

* has many users
* has a name – “grad students”, “undergrads”, etc.
* has many authentication sources

User

A user:

* has many reservations
* has many reservable assets through reservations
* has many posts
* belongs to a User Type
* has an authentication source through its user type

Administrator

An administrator:

* Has a username and password.
* has an email address