See Filip's Discuss Post with recording and images of drafts for a more in-depth overview of this topic
Filip presented a high level overview of proposed RM modules. At this point, his draft establishes the proposed modules, their broad functionality, and how they might interact. Specific requirements have not yet been documented.
The modules are more granular than in typical library systems, so that users will have more flexibility to pick and choose apps and swap out different functionality.
Some apps will be traditional modules that have their own UI, but others will simply provide settings that interact with other apps or smaller apps that create pop-ups or side bars within the main apps.
The goal is to create a single UI that takes advantage of the same mechanisms for lots of apps. These mechanisms will behave slightly differently in different contexts, but will provide for consistency across the platform.
The proposed modules are:
Workflows will allow users to create checklists where each point can be assigned to a different person. Steps can be completed manually or automated. Workflows can be used beyond RM. The workflows app will just be for defining steps – the actual notifications will be displayed in the to-do app.
Contacts will support contact records with basic information. These will be linked to vendor or organization records.
Licenses will allow users to create a license record to represent a contract and store documents. Licenses can be linked to the resources they govern, as well as to vendors and platforms.
Selection will allow users to keep track of various news sources, identify titles to purchase, and request an order. Order requests will link up to the knowledge base. This module will also support requests from library users. Library staff would see a list of all submitted requests and can choose to either buy or reject.
Email integration will support the logging of email communications within the system. There are many ways this could be accomplished including sending a message from within the system, cc-ing a unique email for a particular record, or placing a unique code in an email subject field.
Support will be used to document support requests and dialogues between library staff and users. Support requests will be closed when resolved.
Collection is where FOLIO will store bib, item, package, and platform records. The term "collection" is being used as opposed to "catalog," to represent the blurred line between resources themselves and representation of those resources. Data stored in the collection will be available via APIs and FOLIO users can set permissions to determine how widely it's shared.
Orders allows users to see a list of purchase requests, see purchase options from different vendors, choose which item to buy, identify which account will be used, and encumber funds.
Financial management supports the creation of funds, allocations to those funds, and hooks into external campus systems. We've proposed the use of tags to cut down on the number of funds needed. Each fund will include a visual overview and an activity log. Another possible idea is the ability to create hierarchical groupings of funds.
To-dos will allow users to keep track of workflow items and other tasks that are assigned to them. Users will be able to customize the display of to-dos and create categories of items.
Feedback from the group was very positive. Members felt like the ideas Filip presented were going in the right direction and were very modern compared to existing systems. WE particularly liked the modular nature of the design and the reuse of functionality across various modules.