Outline of issues for ISRS/RSRS replacement.

Background

Currently have two systems in use, one for instructional reporting (ISRS) and on for reference reporting (RSRS). These were built as student projects and have been maintained mostly by Rick in recent times.

Zsuzsa confirms that no data is to be migrated from the old systems. The old systems/data will be discarded.

Requirements

Input

• Web based system
• Must support two options for login. Both should be persistent and have very long timeouts so that staff don't have to log in repeatedly. (Zsuzsa: there are desks that are staffed by students who turn over very frequently. Maintaining who has access rights with every staff change would become too much of an overhead. The other issue is that it is more convenient and less threatening for desk staff, so not having it would make the system harder to sell)
  • CU WebAuth based for individual login
  • Location/Workstation based shared login for staff and students working at help desks.
• Interface presents the question sequence on one page, with appropriate components expanding and contracting based on responses (JavaScript). Page design must assist in keeping the process of data entry quick and easy. Recording of most transactions needs to take less than 15 seconds. Optional questions must be clearly separated at the bottom of the page (see detailed sequence in 2/19/10 question draft from Zsuzsa).
• Need to know some details from login: date, time, which library, which department, what staff level. THIS NEEDS BETTER DEFINITION
  • both: know time, date
  • CU WebAuth - know user from login
  • Location/Workstation based - know location, department from login (though these would have to be maintained as settings with those accounts)
  • Zsuzsa: "Could system allow for personal preferences being set by computer?" – Is this about workstation based shared logins or detection of location for individual logins?
• System should have date and time fields prefilled with current date and time but these should be allowed to be changed
• System should allow the adding and editing of old entries as well and easy input of a sequence of entries at the same time
  • Assume there will be edit/submit for each but optimize to minimize data entry/time
  • Sequence: what fields should be carried forward from one submit to the next?

Output

• System should allow queries on variety of variables, with some predefined reports
• Notes field should be keyword seachable
• Need to be able to dump data out of system
• Need to be able to query system on combinations of all variables (#3 and #7 are most important for definitions, but will need to know things like how many classes did I teach, how many contacts were initiated by Law library staff, how many non-presentation knowledge questions, etc.)

Suggestion: main reporting should be done from LibPAS. This system should have simple facilities for user to query their own records, admin to get some summary stats. Output from DB in CSV or other simple format should allow import into LibPAS and/or other analysis packages (e.g. Excel).

Re: simple user query. Zsuzsa: "I am envisioning most contributors to want to do some querying (e.g. at annual review time I might want to find out how many presentations I've done in the past year."

Implementation scenarios

1. DLIT takes on project

Estimate 1-2 months FTE. Probably some mix of Rick, Jim, Matt, Steve. Initial review says that no parts expected to be hard/uncertain but expect that time to refine/tweak to optimize workflow/experience will be significant.

• UI (including AJAX for fold/unfold)
• Admin (need to work out permissions model)
• Basic reporting
• CUWebAuth/Desktop logins
• Tools for CSV export, import to LibPAS

Other projects competing for time that might need to be delayed if this work to take priority for July 1 completion (note also issues if we have to move for fire safety work):

• LibPAS/datamart work
• attention to staffweb
• 2CUL work
• PSL updates
• unit library websites

2. Keith Jenkins

Notes from Keith/Simeon discussion Fri 2 Apr. Keith's duties include reference work so he familiar with the current system and with the requirements of users. He estimates that there would be about 60k entries/year with 30-50 people using the system. Keith is keen to take on the task of creating a new system and would likely then maintain it. His plan would be to:

1. would start by copying whatever possible from the "new books" code
2. use JSON log file as beck-end "db" (expect to roll over yearly, thinks 60k entries would not be too big to parse in order to answer query)
3. new entry is append of JSON to log file
4. web end - php and JSON, jQuery for UI
5. back end - php, apache, modphp
6. has ideas about UI and how reporting in different places/libraries might want to record different levels of data
7. effort estimate: 1 week

Keith thinks it unlikely that he could contribute effectively to a Drupal based project because he isn't familiar with Drupal.

Questions - what are the minimal reporting requirements? What statistics need to be generated?

3. Outsource

Would have to get work done in an appropriate toolset so that DLIT could sensibly maintain. How much would this cost?

4. Use LibPAS

From Ian at LibPAS: "InformsUs can be set-up to show/hide questions depending on earlier responses in a single page (or these questions can be segmented into different pages)."

BUT: we cannot meet the login needs with LibPAS so if these are a requirement then this is not an option.