|
| - 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.
- Feed back 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.
...not finished yet. There are more notes to come --Bob |