|
| - 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:
- Graphic novels spread out throughout a large academic library combined into a single special collection.
- An academic library is moving upwards of 180,000 physical holdings to an offsite annex.
- Volumes are being shifted from within the same building may be to a different floor.
- Items sent to the bindery
- 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.
|
| Questions & Answers | - Amanda: Is there a timeline for what you mean by short-term and long-term?
- Ryan: I cannot in good faith say what that would look like. Um, I'm not sure if anyone else on the call can speak to that?
Magda - in-app will not be possible for the pilot project. I hear the feedback loud and clear that the local edit option is not acceptable long-term and we will begin looking at that. Scott Perry: I see the value of both options. I just want to make sure there is a way to go broader with all sorts of data not just metadata but also for example financial and acquisitions data. I would also encourage that permissions be area or module based not just bulk-edit-based. Magda: A couple of things. This group is metadata heavy only because that was who responded to participate in the research. Magda: I did hear from other SIGs that there was the local editing option was useful and helpful, so we will keep both options in the end. We are not going away from CSV options but we may limit access. But it will be kept. - Ryan: Scott that is good context. The one person I spoke to that wasn't an academic metadata librarian was pretty gung-ho on the local editing option. And mostly because like you said, most of the work she was doing was with patron records. And it was much simpler to deal with this data when it is not cataloging metadata.
- Bob: What is the difference in functionality between the FOLIO import-export app and the proposed CSV bulk edit option. In our current Sierra system we do not use bulk edit to export, edited, and re-upload records. We use the Sierra load profile to do this.
- Magda: FOLIO Import-Export does only handles inventory metadata not users, acquisitions and other data. That is one reason we are starting with user data as we assume metadata options to be available via the Import-Export app.
- Bob: But will Import-Export be able to handle user data in the future?
- Magda: There are perhaps plans for exporting users to CSV. But I do not think there are any plans short-term with the Import app to bring in user data.
- Erin: Data Import has been completely focused on Inventory and SRS and the associated pieces. No discussion on user data import.
- Magda: We will table this for now and come back to this next time when we see presentation with mockups.
Sarah: So one thing, to Bob's point, I think we have to consider is that not everything is going to be MARC-based. We are not going to have MARC Holdings in FOLIO. So, bulk editing is happening outside of MarcEdit which is only usable if dealing with MARC data. Sarah: I've been wondering, and I see that Scott in chat has also mentioned that in Orders, Dennis has been talking about editing and export, and Changing records. This has also come up in ERM, around agreements. And I'm always wondering how much communication is going on across the apps to make the experience more similar. Or least help each other with being able to edit records in batches. While this has not come up so far for me in my current system, because I don't have agreements in my current system, that is definitely a thing now in FOLIO where I am actually already in production. It would be great if I could identify a set of records and then batch change them just like I would with other records. I'm just curious to hear a little bit about how cross-app communication is happening around all of this.
...not finished yet. There are more notes to come --Bob |