2021-11-16 Bulk Edit Working Group Meeting Notes

Housekeeping:

• Please add your name to the list of attendees
• Make sure Transcript is turned on during the meeting

• Ryan: The goal of the research was to figure out how we move forward with bulk edit functionality in FOLIO by understanding some of the challenges that librarians are facing when making bulk edits, not just in FOLIO, but in all the applications that they are using, which are quite varied. I sit within the UX research team at Ebsco and I work on all kinds of products, so FOLIO is less familiar to me.
• Ryan: I wanted to understand what some of the biggest challenges were in the bulk edit process so that we can account for those challenges in Future FOLIO updates. I wanted to understand specifically what you all saw as the drawbacks and advantages to editing local files, especially CSV files, as opposed to using an in-app editor. I wanted to understand the drawbacks and advantages of both, what would tip the balance for individuals and institutions to accept and adopt a CSV bulk edit workflow?
• Ryan: The goal was not to dig into the specific problems with anyone UI but to understand the challenges that you all face generally in performing bulk edits.
• Ryan: The research was conducted over a series of about two weeks. I did moderated interviews, which were open-ended questions designed to identify the bulk edit workflow and understand the toolset that is used for making those edits.
  
  • Were there student workers involved and how does that add an additional layer of challenge to the process?
  • How they reacted to being able to do local edits in FOLIO if that were an option and what the requirements would be for this option.
• Ryan: People interviewed were librarians involved with metadata management and bulk editing. Spoke with one K-12 library assistant. So it was a varied group considering how specific this audience is. This group was using a number of different platforms.
• Ryan: What are the example use cases for bulk editing uncovered via the interviews?
  • All of these cases would require bulk editing of statuses or locations:
    1. Graphic novels spread out throughout a large academic library combined into a single special collection.
    2. An academic library is moving upwards of 180,000 physical holdings to an offsite annex.
    3. Volumes are being shifted from within the same building may be to a different floor.
    4. Items sent to the bindery
    5. Items being withdrawn
• Ryan: How does bulk edit work?
  • Records need to be identified which can happen using one of two methods:
    • Queries - platform is used to query the DB based on some criteria, e.g., location.
    • Itemized - records in the DB are identified using existing list records, e.g., a list of barcodes or another identifier.
    • In reality, it is ofter a combination of these two methods.
  • Once identified the changes can be made in one of two ways:
    • Native editing - the platform has the ability to make changes to records directly within the app.
    • Local editing - records are harvested, exported, edited locally in an external editor, and then re-uploaded back into the DB.
    • There was a lot of feedback on these two options.
• Ryan: Advantages of in-app native editing: data is normalized in the system and hides data that does not need to be changed for the specific edit being done.
• Ryan: The disadvantage of native editing: confined to what can be done on the platform, maybe only one edit at a time. You are not given access to the raw data to edit.
• Ryan: The disadvantage of local editing: dealing with raw data files exposes a lot of meaningless data presented in a chaotic difficult to read the file. And it is not always clear what fields need to be edited to enact the necessary changes. All of which can lead to errors. And there is little or no feedback regarding the errors from changes made and no opportunity to roll back changes if errors were made. There is a lot of room for error.
• Ryan: Feedback for example from UMASS - working directly with CSV files feels dangerous. So much that can go wrong. When you bring data back in, it's hard to know what was changed. And if there is an error or mistake, it's a pain to track down.
• Ryan: As a group, across the board, there was enthusiasm for having some sort of in-app solution that can streamline their workflow, reduce risks of bulk editing, normalize some of the behind-the-scenes processes, and make everything a little bit easier.
• Ryan: When speaking with the Library Assistant from the K-12 school she said doing local edits makes it easier because I don't have to give admin rights to all the students I'm working with. They can save and hand off the file. I'm the only one who does the actual uploading. This scenario is where there are mostly volunteers doing the editing and the scope is small, maybe 10-100 records to edit at one time. In comparison, none of the academic libraries interviewed employ students to do bulk edits because the work is too complex and the possibility for error is just far too great to have students involved.
• Ryan:  I think based on what I heard and you all having some sort of in-app editor that cuts through all that data level noise is going to be the best long-term option for user workflow and customer satisfaction. Of course, this option requires a lot more development.
• Ryan: In the short term, what I heard from folks is that they could accept a local bulk edit option if it was explicitly positioned at a stop-gap measure on the way to meeting an in-app solution. And if a few features were put in place to reduce the risk of errors increase feedback when there are errors in that process.
• Ryans: So one thing we need to focus on is providing really clear error reporting and a transparent way where people understand what's happening. And we also need to know what failure means, e.g., did it revert, invalidate, corrupt, or delete the record? What is the status of the records that failed to process? And when there are failed records there is a way to identify the bad records from the potentially very large set of processed records. Also, some feedback if possible on how to prevent this from happening again as well as some guard rails from the onset so it does not feel so dangerous.
• Ryan: We also need to make sure that we're optimizing the CSV files for understandability and trying to avoid any kind of Ebsco-centric jargon or codes and label the data in a way that it correlates to the records we are changing and is sensical.
• Ryan: We want to make it very clear, which fields should be edited and which should be avoided. And that might mean providing some degree of instruction on some of the more common edits, like status and location fields, for example, indicating that if you want to change the status or location of an item, these are the fields you have to change, ignore everything else. And maybe even by graying out or making some of those fields unavailable for editing.
• Ryan: And if you want to undo the effects of a bulk edit there should be an undo feature to restore the data to a previous state.
• Ryan: Provide some warnings if the data uploaded is problematic before the process is run, i.e., "are you sure?," "is this correct?" Having some guardrails around the process, so it doesn't feel so obscure and opaque and there is some feedback happening.
• Ryan: In the longer term for the in-app development we can return to the group for concept testing, usability testing, so we can gauge reactions and get a sense of what people like and what they don't like.

• Ryan: And for the CSV local editor option in the interim, we just make it really, really clear that this is short-term and what our roadmap looks like. We want to make sure that in the local editing process, we have crystal clear error reporting and feedback and reassurance to really help understand what's happening. Make sure there are instructions on exactly what fields need to be amended to make common changes. And we want to have some improvements to be able to roll back when there are human or computer errors. And we want to provide the user tools to be able to retrace their steps and amend any longer corrupted records, just to try to make this process a little bit easier, a little bit safer and a little bit less of a pain.

• Ryan: And I would just try to communicate that being presented with a local editing option now does not mean this will be the only thing you will ever have. And that there is more on the roadmap to come and it is being worked on.

...not finished yet. There are more notes to come --Bob

Development updates:

• • Development status
  • Development team scrum board

Bulk Edit Pilot - expectations - continue discussion 

Homework:

• Bulk Edit Limit Size
• Bulk Edit Permissions

Please respond to the surveys before Thursday, November 18th.

Future discussion topic (time permitting):

• Mitigation of reported UX issues
• Bulk Edit Permissions
• Bulk Edit of the linked records
• Max number of records to be edited via User Interface
• Scheduling edits