Future Enhancements

This is a list of possible future changes in design and implementation of the CML/LitCrit application:

• Enable users to access buttons using the keyboard. This would make the CML/LitCrit application accessible to people who have difficulty using a mouse.
• Use a stored SQL Server™ table as a starting point for new searches. The current architecture of CML/LitCrit could accommodate queries that allow you to search only records you found in your last search. The query would be ostensibly the same; you would just need to add the clause "AND t.bib# IN (SELECT * FROM lastsearch)", where lastsearch is the name of the store results table you want to use as the limiting search. Then add an optional parameter to the CML.Search object's CreateTable method and a check box in the main library page, DFilter.asp.
• Disallow duplicate critique submissions. Currently the Outlook® Web Access (OWA) form makes no attempt to disallow multiple critiques for the same item from the same person. However, since the Critique table has defined a UNIQUE constraint for bib# and borrower#, only the first critique for any given title by the same user is allowed. When the form data is copied to the database, the insert will fail if a review already exists.
• Prevent anonymous logon. When viewing or submitting reviews from the CML application, the standard Outlook Web Access (OWA) logon screen is displayed. It is possible that a user could select to log on anonymously, rather than enter a valid mailbox name. If this happens, that user will not be able to submit reviews until closing his or her browser and starting again.
• Add a Delete Item button to the Library Catalog page. This would be an obvious enhancement to the CML/LitCrit application since it is just as appropriate to delete items as it is to add them.
• Provide a View Checked Out and Overdue page for viewing items that have been checked out and items that are due for return. No user interface in the CML/LitCrit application provides this entire functionality. Currently, if an administrator knows which materials are checked out to which users, he or she can view checked-out materials by alias on the Renew Materials page.
• Expand the functionality of the View Requests and Check Out page. Currently, the page has difficulty showing items with no available requests when a request with available items is displayed; the option isn't present until bar codes are assigned to the requests that have items available and Check Out Materials is clicked. Also, when Check Out Materials is clicked, materials with no items available for checkout become hidden and you have to click to show them again.
• Allow ad hoc (in person) checkouts. To provide this functionality, the CML.Admin component would have to be redesigned. Currently, only items from the request queue can be checked out. Checkouts go to the next person in the request queue. You cannot change the order of the queue or check out items to someone not in the queue.
• Add a Cancel button to the View Requests and Check Out page. In CML/LitCrit, an administrator should be able to cancel requests (for example, if there are no items available for checkout). By clicking a Cancel button, for example, an administrator could cancel the request and send cancellation mail to the user.
• Display more than the first request in any given queue. Currently, there is no warning that other requests may be waiting. If the application displayed the number of requests in a queue, an administrator could gather many requested items at one time to satisfy requests.
• Automatically notify the user when materials are checked out. Similar to when material is checked in or recalled, the user should receive an e-mail notification automatically when material is checked out. The user would then be prepared to receive a package if the items had been shipped.
• Improve the error message when entering an invalid bar code in the Check In Materials text box. Currently, if you put an unrecognized bar code into this text box and then click Check In an exception error appears. A more specific error message is needed, such as "This bar code is unrecognizable. Verify the bar code and type it again."
• Use more than one Event Service agent to monitor a folder. When a script fails, the Event Service engine notes the script that failed, and stops running that particular script. This means that not only will the event that produced the error no longer be run, but also all the other scripting events in the same script. Separating the code for each event into separate script files and registering them as separate agents would allow you to modify and update scripts without worrying that an error will prevent other events from being processed. Each agent would react to an individual event (each would contain one subroutine, such as Folder_OnMessageCreated). This enhancement would help you isolate errors; if scripts run individually, a failure in one does not prevent the other three from functioning and each agent would write to its own log file. This solution would mean duplicating some utility code in each script, such as the DebugError routine (see About the DebugReport Subroutine). This is because this type of script does not support the #include directive. As a possible workaround, you could write an object that implements the common functionality, and call this object from each of the scripts.
• Use the Message_OnChange event to finish processing messages that may have failed. Since Event Service uses the Exchange Server change notification feature to determine which messages to process, a message will only get one chance to be processed after it is created. If the script fails for some reason (for example, if SQL Server is down), that message will not be visited by the agent again. Saving data back to the message (the last known error, for example) would trigger the Message_OnChange event to fire the next time the agent checks the folder. This arrangement would serve as an effective means of recovering from error conditions in an enterprise environment.
• Suggest library titles based on the ratings of people with the same job titles. Imagine visiting the library, and being met with a "top ten" list of materials as rated by people in your organization who share your job title. Since job titles are stored in the borrower table, ratings in the Critique table can be individually grouped by job title. Here's a stored procedure that does exactly that:

  CREATE procedure lc_top10_by_jobtitle(@title varchar(64)) AS
  set nocount on
  select c.bib#,b.title,avg(convert(decimal,rating)) avg_rating,count(*) weight
         into #ctemp from critique c join borrower b on c.borrower#=b.borrower# 
         where b.title=@title and c.isapproved=1 group by c.bib#,b.title
  select TOP 10 c.bib#,c.avg_rating,t.title from #ctemp c join title t on c.bib#=t.bib#
         order by c.avg_rating DESC,c.weight DESC
  

• Budget library acquisitions based on popularity of library items. Now that the library has a means of gathering data about what types of materials are popular, they could use that data to purchase more of the items that are rated highly, and purchase fewer of those that aren't meeting the basic needs of employees.