From "I-Share Liaisons Forum: Future of the ILS discussions - May 21, 2009 "

Things you /your library can’t do without that the current system does

General:

• Reporting/Flexible reporting
• Reports locally run & CARLI’s annual
• Bulk importing and reporting
• Local instances-specific to library not UC
• Ability to deal with multiple campus locations
• Centralized tech support
• Anything else we want has to work FAST
• Discovery layer and back end work seamlessly together even if from different vendors
• “Instant” updating
• Client based
• Maximum access, minimum barriers

Circulation:

• Resource sharing
• Universal borrowing
• ILL capabilities
• Reciprocal borrowing
• Seamless delivery
• Seamless Universal borrowing
• Electronic reserves/ Reserves
• E-mail overdues
• Call # browse (staff side)
• Search patron name
• Resource sharing is the heart of our ILS and our greatest strength

Acquisitions:

• Flexible fund structure
• ACQ-flexible fund structure

Cataloging:

• Selective bib records (ability to choose~modify)
• Full support-holdings, MARC format
• Access Auth references
• Local control-items & holdings
• Data integrity
• Bulk import
• MARC’s functions

OPAC:

• Text messaging call numbers (expand)
• Easy for patrons to use and understand
• Shelf status, limit by location, hot links to call numbers, authors, etc
• Easily going between local & shared catalogs

Things that annoy you/your library in the current system

General:

• Duplicated effort between institutions
• Inability to communicate with campus accounting
• Not easy interface to other campus systems (Banner)
• Unable to move easily between modules
• No interoperability-have to open multiple clients
• Hard to set reasonable defaults
• Too much clicking
• Not very efficient—lots of steps, or repeat steps
• Clients are clumsy
• Bouncing the system every night
• Scalable efficiency
• Cumbersome to have 77 different databases instead of one (especially for circ)
• Reports system
• Build it to handle serials, then monographs will be easy
• All modules—more control over default settings (customize reasons—preset reasons for clearing fines)
• Have to log into each module separately (would like one universal login to access all clients)
• Need easier to locate system documentation (how to mark an item for circ review for example)
• ‘Click heavy’
• Easier authentication (minimum passwords)
• Have to bounce each night
• Lack of integration between clients (Circ & Bib info)
• Having to recustomize with each upgrade
• Money is an issue. In the current economic climate, resources are extremely limited for CARLI and for public and private institutions. Commercial systems are very expensive and would likely be an investment by libraries in both initial purchase and for annual maintenance fees.

Circulation:

• Can’t communicate loan period to patrons
• Loading new patron records
• ILL coming in from diff locations
• Media scheduling unit that works
• Circ—no back button when searching
• Circ—unable to print results
• Cannot see ILL items checked out to users via Circ client
• When charged item lists print, doesn’t include call numbers
• Cannot set temporary fixed due dates for some patron types, but can others
• Can’t resize windows in circ & acq
• Management module (for e-reserves?) can be improved—more robust platform—could be easier, better for staff
• Finding (returning) lost items doesn’t undo patron statistics (counter) for lost item
• Multiple volume requesting
• Communication with external billing systems
• Need more clarification (or better terms) for call slips

Acquisitions:

• Reporting not integrated within ILS modules (cannot get Acq info directly from Acq)
• Acq reporting—hard to get info from modules without using Access
• ACQ awkward-kicked out too often
• Prediction pattern settings (lack of flexibility)
• Can’t easily add funds to PO’s (currently have to add each item and fund to each before moving on)
• Can put data in (ACQ) but difficult to get data out
• Can’t resize windows in circ & acq
• Can’t delete bibs that have attached PO
• The current Voyager client is click heavy. Most tasks require moving through many screens and processes are scattered.

Cataloging:

• Not following MARC standards
• Delay in record changes
• Better record integration: global bib data change by change to auth
• Shouldn’t “need” Gary Strawn utilities (should come with such)
• Reduce wait for replace record after suppressing one
• Adhere to cataloging standards better when adding URLs to records (currently not adhering to MARC standards & do not display well)

OPAC:

• Timeouts OPAC response time
• Slowness
• Need faster system (current system too slow)
• Public side—show how many copies are available for REQUESTING, rather than available including reference or other non-circ items
• Ability to choose borrowing library
• ILS & OPAC issues (systems too separate for ease of use)
• Popular title issue
• No way to display loan period expectations to user
• “Extra” screen with “first available copy” in UB requesting. (since there is only one choice, why go to this page?)
• Response time, (long time to load, work faster)
• Search logic (should default to ‘and’)
• Can’t choose library from which to borrow
• Lack of customization
• Easily linking and presenting streaming visual media

Things you/your library feel are missing from the current system (“blue sky” ideas welcome!)

General:

• Specialized searching per library (e.g."all health science libraries"
• Easy authentication by affiliation & privileges
• FRBR
• Inventory module
• Kindle support
• Open Source
• Use local talent
• Services for mobile users
• Service extensible with new technology
• Embed map with call #
• Embed images & video in catalog records
• Electronic copy of local—Embedded PDF’s
• Management system compatible with any interface/discovery system
• XML customizable interfaces for staff
• Flexible, customizable at the local level, can be integrated with other products.
• Networked based instead of client based and have 1 sign-on for multiple modules
• Productivity stats and reports for employees
• Data mining for collection development
• Collection analysis
• More flexibility with check date on materials
• An open source ILS that CARLI can improve without relying on an outside vendor
• Make library resources more open & discoverable on the Web
• Being able to share/compare data with other institutions as an integrated feature
• Collection analysis tool individually & across consortium
• Upgrade when we want w/o reliance on vendor
• Seamless searching across systems
• Type a question & find your answer
• Multiple metadata schema
• Mashup catalog/article database, single do-it-all library spot
• Ease of access combined with ability to get to very deep levels of resources. Users able to decide what they want.
• Smooth, reasonable functionality for the user. Easy to use and learn.
• CARLI-hosted for most or all libraries.
• System should be flexible and expansible.
• System is flexible enough to support different types of users
• Retain some commonality so that users have a familiar experience in catalogs outside of their home institution.
• Single search is balanced by performance. Trying to put too much behind a public interface may overwhelm the system. single
• Accommodates the consortial environment.
• Possible to extract data out of the current system or an understanding of what we would potentially lose in the transition.
• Accommodates multiple levels of users.
• Accommodates the leaders as much as the smaller, non-technical institutions.
• Improved access to reporting functions.
• Small and large organizations must be able to fully exploit capabilities. Not dependent upon in-house IT expertise.
• Modularity to enable institutions to participate in parts of the system—not an all or nothing solution.
• Robust performance, improved speed.
• Ability to mine search information, borrower data to return results that are ‘intelligent’ rather than just ‘relevant’.

Circulation:

• Video reserve option for faculty
• Ability to send notices etc SMS text messaging
• Door to door delivery (e.g. Netflix)
• Take ILL to the next level-handle article requests seamlessly—one button
• Recall feature
• Document delivery for ILL
• Auto look-up in Circ for access (for patron security)
• RFID tracking-linked to maps
• ILL connect to library info for patrons with borrowing issues at specific libraries (easier for patron to know how/who to contact with a problem)
• Ability to see UB records as well as local for patrons (in circ client?)
• ILS that communicates with billing systems (Banner)
• Resource sharing should be enhanced in the next ILS to allow journal borrowing, direct patron borrowing across disparate ILS’s and non-I-Share governing members
• From the patron’s perspective, one way to do ILL.
• Institutions able to set local borrowing privileges and borrowing periods.
• Supports emerging technologies in resource sharing (e-books, print on demand, electronic document delivery.)
• The next generation ILS enables resource-sharing across disparate systems much as is possible without sacrificing the performance of the system and the level of service to existing I-Share libraries.
• Allow disparate systems to encourage broader participation in resource sharing.
• Flexibility to create resource-sharing subsets—i.e. all ARL libraries in the state.
• Supports resource sharing among academic institutions and public libraries alike.

Acquisitions:

• ACQ system for better collection management
• Integrate electronic resource management
• ERMS
• Collect cataloging/acquisition statistics in real time
• Integrated ERMS into acquisitions client
• Acquisitions still needed to interact with the catalog
• We need standards to facilitate interoperability and communication between the acquisitions system and the campus enterprise system
• We need to be able to easily obtain output data for campus accounting and from campus accounting.
• We need standardized pieces of data that are easily accessed and exchanged, not proprietary
• Reports from accounting system should be easily imported and manipulated in the ILS.
• One library has a student actually check the online availability of individual issues. What sort of tool could automate this process?
• Could publishers provide RSS feeds announcing journal availability then have a spider program check the link and report problems?
• Whatever emerges needs to be more flexible, streamlined with easy ways to pull together required data and simpler screens.
• . Could it be possible to build your own screens to focus on just the tasks you need to accomplish? It would be great to be able to customize for a task or workflow.
• A new system should understand and be able to apply MARC Holdings Record standards.
• The system needs room to grow and we need to be able to easily map data to migrate to new systems.
• A knowledge base would be nice to be able to identify reasons for purchase decisions and to inform decision cycles and payment cycles

Cataloging:

• Global data change
• Dynamic linkage between SH(?) & authority files
• Linking analytics to main series
• Collect cataloging/acquisition statistics in real time
• Not MARC based but still provide for good subject searching precision (might work better)

OPAC:

• Tag Clouds
• Catalog that looks and acts like Google & Amazon (better search logarithms & computing power)
• “Did you mean” feature for spelling & authority control
• Personalized searching (system knows what you want) (others who’ve searched for this have also searched…)
• Add comments in OPAC
• User tag functionality
• Comments, reviews, tagging—searchable
• Link in catalog to institutional repository
• Single box—federated search in OPAC
• Natural language searching
• User helper like Amazon
• Patrons customize their own OPAC “personal”
• Update to feeds or social network site
• Link call # to map of library, or in ILL will give directions to libraries
• Federated search
• Geographic searching link cartographic resources (enter longitude & latitude & retrieve maps)
• Something already ready for mobile browser
• Widget approach to catalog searches
• Contact info/location information within catalog
• Chat messaging within catalog
• Text messaging within catalog (overdue notices etc.)
• Built in citation management tools
• “did you mean” feature, more than dictionary, also thesaurus
• Transparent search logic
• More Robust faceted search approach
• ‘Other users searched’ helps
• Federated search/faceted searching that works across different types of materials.Must search more than MARC.
• Allows discovery and linking to digital collections and other resources that are already in collections but not discoverable in the current system. Enables access to all the content we own, and the ability to share it.
• Allows for maximum personalization of the patron experience.
• Available from a variety of public search and discovery tools. Google Books, Facebook, online course platforms etc. Patron chooses how they want to see it.
• Social networking capabilities.
• Local control of user tagging to maintain the high standard of the catalog.
• Compatible with mobile devices.

Assuming a timeline is NOT forced by outside circumstances, how will we know when it is time to move to a new system?

General:

• Nothing better to move to at this time
• When everyone is frustrated enough
• Now!
• Users demand more
• Don’t have to do everything at the same time
• Money issues
• Cost of ownership becomes prohibitive
• Keep eyes & ears open to alternatives to what we have
• Keep topic a periodic feature of meetings & listen to feedback
• When there is a critical mass who want to explore further
• Need to know what’s out there
• Performance degradation. Users waiting longer for results.
• The current system can’t fulfill the basic list of critical functions.
• The number of widgets we’re developing to maintain critical functionality becomes overwhelming.
• Obsolescence from the user perspective or the technical support perspective.
• Peer institutions are offering tools that are significantly better than what we can offer. Patrons can’t do what they could do at other institutions.
• Something better becomes available.
• Inability to grow the current system. New libraries shut out of consortial borrowing.
• Timing—mass rush in the marketplace to a particular system.
• Compelling cost-savings. Introduction of a new product that’s a good solution, is inexpensive, and has a robust development community supporting it.
• In a disintegrated system the timing of decisions would be influenced by the availability of new modules.
• CARLI and library staff have the time and the resources to make a change.
• Question: If there is disintegration of system components, would a certain number of institutions need to commit to various components to make it possible?
• Workload of integrating various components and systems would probably shift to CARLI. (Cost of stitching vs. cost of switching.)

Voyager & Vendor related:

• If Voyager development stops
• Vendor support dwindling
• Vendor emerges who has what we want
• If we find and ILS that supports what we want
• When vendor is not developing what we want
• When vendor stops responding to CARLI requests
• Vendor ceases to support the system, goes out of business or is acquired by another

Open Source related:

• Develop our own open source
• Does CARLI have enough staff to support open source?

Patron related:

• Patron satisfaction moves the selection/timing
• Waiting too long may have consequences (might lose younger patrons)
• Students want to go to one place. The current focus on traditional print library materials and the inability to put other resources behind our current system is intolerable.

OPAC related:

• Performance issues with new OPAC might make us move sooner
• Lots going on with OPAC, need to move soon

What is your library’s tolerance for risk in selecting/developing the next ILS (e.g., open source, a mixture of vendors’ modules)

General:

• Low tolerance for circ (want to make sure users aren’t negatively affected)
• Will it work? Need to know performance will be at least as good as now
• Cost factors (money & staff time)
• Cost of ownership
• Politics makes the change uncertain (who owns the data?—OCLC example)
• Open source is fine if infrastructure is already there
• Public services staff more resistant to change
• No tolerance of losing data or functionality: CARLI is protection
• Willing to risk time/hopes
• Has to work
• cannot lose information
• Migration simple?
• Parallel systems a possibility
• Strong & healthy CARLI organization
• Percentage of responsibility between CARLI & local library
• Sharing risk across the state
• Tolerance for risk will be higher if production-critical modules are maintained when experimental modules are introduced (the VuFind model.) Public access can be implemented independently of staff functions. Staged implementation of staff functions depends on system architecture, practical adherence to standards, etc.
• People are more knowledgeable about open source now than 5 years ago.
• We want CARLI to be a leader, a developer, an innovator.
• CARLI should be engaged with the current development environment to ensure new systems to grow with the consortial environment in mind.
• Open source may be more predictable and allow for more control of our own fate than if we’re relying on commercial vendors or a product that may not be around in 5 years. It may be better to invest in a CARLI solution that is closer to what we need ther than buying an external system and making it fit our needs.
• Open source development leverages the strength of the consortium.
• All open source products are not alike. Different products have varying levels of support in the development community. Responsiveness and timeliness of development in response to functionality varies from product to product.
• How many libraries should be on an Open Source product before we’d be comfortable with putting it in production?
• Universal borrowing is unlikely to come as a part of any commercial system. If we’re adding this ‘on top’ of any existing system, we may as well add it on top of something else that isn’t exclusive.
• Tolerance may depend upon how much data libraries would lose in a conversion to a new system.
• Support for a larger community and disparate systems changes the role for CARLI from running the system for a select clientele to running a bigger variety of systems. Staff time for support increases. Time commitment moves from switching to stitching. It’s not necessarily riskier, cheaper, or more flexible; it’s just a different business model.
• We might be developers or we might work with a support firm.
• Open source may allow better linkages with local accounting systems.
• Open source development allows for a model of “Crowd-sourcing” solutions for ILS.

View Calendar    Email Lists

Search

Featured Links

CARLI Digital Collections
CARLI Systems Status
CARLI Blog
CARLI Wiki
CARLI twitter
Information for ILLINET Libraries
Newsletter Archives