| Bulk Edit Pilot - expectations - continue discussion So far we discussed and I believe we agreed upon : - Small but reliable functionality that is limited to the user records as defined in in the scope of UXPROD-3225
- Evaluated by Bulk Edit Working Group, SIGs, Product Council and Technical Council:
- Available for acceptance testing in a separate environment that will contain larger dataset and will not be refreshed nightly (RANCHER-63)
We still need to discuss: - Should it be included in Lotus release?
- Next steps
| - Magda: I would like to continue with the bulk edit expectations. In a very short summary, I think we agreed that:
- Magda: The scope should be small, but reliable
- Magda: Functionality is limited to user records as defined in the scope of UXPROD-3225
- Magda: In scope will be:
- Magda: Limited bulk edit for user records
- Magda: Search by user group, list of barcodes
- Magda: Edit: remove permissions, update expiration date, update patron group, update email
- Magda: All elements related to bulk edit workflow (even if only limited form):
- Magda: Identify records for editing
- Magda: Edit record(s): add data, remove data, update data, i.e., change the values of the fields within the records. It is not adding new or deleting recorders.
- Question from Erin: I think that removing permissions which aren't in the core user record shouldn't be in scope for the pilot.
- Magda: I would agree with you that permissions will be a difficult thing to implement, especially since this is a separate record. It is not, as I like to refer to it a linked record, similar to fees and fines. But I would like to keep it for now. And then maybe towards the end of the release, we will evaluate it.
- Question from Jennifer: When you say remove the permissions, is that like both individual and group permissions?
- Magda: I was thinking in terms of groups especially the use case where you have student workers and at the end of the semester you need to remove permissions for this group of users.
- Erin: Permissions are different because you have the concept of a user record and then you have the concept of a permission user record. Permissions aren't directly stored on the user record, they're just linked. It's not like you would go into the user record and just say, remove this attribute and this attribute and this attribute, you have to break the link with the permission user. So that's where this would be really complicated. But if you were to remove permissions, you are removing the link to that person's permissions, whether it was individual permissions, permission sets, visible, invisible, whatever. You're just removing them all.
- Magda: It's not only breaking the link; it is also removing the record from the table that contains the data. We don't want to have abundant data left in the tables.
- Sara: In our current system I can have an expiration date for the permission. So, I can assign a student worker, certain permissions and it expires on such and such date, but the record remains because I find this useful to be back, we'll shoot and see that that person did work here with this username and find if they did anything that I want to fix.
- Erin: Unfortunately, FOLIO does not have that functionality to expire permissions. There's an expiration date on an account, but there is no expiring on permission.
- Magda: I really liked the comment, Sarah. This is important feedback you need to go back to the data, and if we remove it, it's gone. I will make a note of this. Also, if you talk with Erin about this, please include me as well.
- Sara: At the Five Colleges permission groups will be set up by the FOLIO Administrator. Will this be a permissions problem for me in bulk edit if the permissions are controlled by someone else?
- Erin: So, my guess is that it shouldn't if you have one person who creates the permission sets, but then you farm out assigning those permission sets to people.
- Magda: If you have a right to add the permission, you should be able to bulk edit those as well.
- Amanda: That's the same structure that we're using at Texas a and M. And right now, I don't have any problems taking permissions away from someone. So, I wouldn't think that there would be a problem with that unless something gets broken when they're fixing something else, which unfortunately we've seen in a couple of instances.
- Sara: Questions: Will the permission to do bulk edits be separate from the permission to do individual edits?
- Magda: Permissions will be at the app level. So yes, they will be separate permissions.
- Magda: Getting back to scope - I just want to go quickly over the list of the covered elements.
- Magda: So we will identify the records for editing, then edit by adding, removing, updating data within the record.
- Magda: Review changes, commit changes, log results
- Magda: Handle exceptions, including notifying the users.
- Magda: And we discussed who should give the green light to the approach. Not only this group but also Technical Council, Product Council. In fact, the Product Council reached out to me and asked me to present the planned functionality at the next PC meeting this Thursday. The reason for this is that a bulk edit will be a new module. And those new modules will need to be approved to be included in the Lotus release. And the deadline for this is December 3rd and we are coming to close to the deadline.
- Magda: And we also discussed that we would like to have a separate environment for the usability testing for the environment where the group can play around with the functionality that was delivered. I created a story for FOLIO DevOps to create an environment. And as I mentioned, I'm coming from vacation and I'm not sure where we are on this. The status is still open. I will follow up with them to see what is the estimated delivery for this Rancher. I would like this environment to be available for SME's usability and acceptance testing. It would have the latest FOLIO snapshot version, and the environment will not be updated automatically every night. It will be a refresh after we request that. The data there will also be larger than that in the snapshot testing environments. Ideally, it will have several thousand records and have a way easy way to have the developers populate with more data as needed.
- Magda: The environment needs to be stable. SMEs should be able to use the data between when the environment is refreshed. And the environment, as I mentioned, is refreshed on-demand, not automatically.
- Magda: The environment will not be for performance testing.
- Magda: Only a couple of thousand user records should be needed.
- Magda: We will be doing performance testing in parallel. But I do not want this environment to be used for performance testing.
- Magda: Once we move to inventory we will probably go up to 1 million records.
- Question from Erin: So how will performance testing happen?
- Magda: I think the performance task force team has their own environments. And this is how the performance testing happens for the data export and OAP MH. Once development has progressed, we just create a ticket with PTF and they spin the environment and we specify how many concurrent users we want to have.
- Question from Erin: Is the testing that they're doing about the responsiveness of the UI?
- Magda: The performance task force mostly works on the backend. So, they will be checking the behavior of the backend. The team that works on the bulk edit, Firebird, is one of the few teams that has a UI tester, automated tester, and engineer who will be writing the UI tests. I will follow up with the PTF and ask them what they want to do about UI.
- Magda: But from my experience, when the system is slow, it's slow because the backend is slow. The UI will not slow things that much.
- Question from Sara: I was not just thinking about performance, but also about connectivity and interaction. So I would suggest that we think about having users that have things on loan, users that have other issues maybe owe some money, etc., so that we can see if thins break, or if things no longer show up, or we've just erased things that we didn't intend to erase, or broke the link, or it just chokes and does something weird because it can no longer pull that data from the other side. I'm just basing this on experience in our production side, with for example agreements where just weird things suddenly pop up if you put a tag somewhere and it breaks everything. I would hate for us to sign off on the pilot only to discover that there are weird hiccups.
- Magda: So, Sarah, should we create some kind of document that would track all the things that we should keep in mind when setting up the data?
- Sara: Is there a way we can also think about quality in the sense of complex data. So not just simple data where you have users at different levels or different groups. But more complexity with things like loans and fines.
- Magda: I probably will need to reach out to a user management group to provide some real-life examples. And then we will need to do this. Once we move to the other areas, we will need to do this for other areas as well.
- Sara: Is there a way, without invading privacy, to get some kind of dump from a site that is life?
- Erin: There is a dump of that kind of data on bug Fest. The concern about bug Fest is that the data has been permutated over and over and over again, and has a lot of cruft in it. But that is something that has been done before. I just don't think that we have done it for several releases.
- Magda: I will reach out to FSC?
- Erin: Maybe Anton directly.
- Erin: I believe that the user data that's on buck Fest came from the University of Chicago.
- Magda: I agree with you that the best way would be to have real-live data instead of artificially setting up the data because there may be use cases we did not think of. And we would need to anonymize, the data for privacy.
- Magda: Let me follow up on this. And I will get back to you via slack.
- Magda: What I would like to discuss next is whether bulk edit should be included in a Lotus release or not? The survey results show the majority said yes it should be considered as a part of the Lotus if the release meets the use cases. I have a question for this group. What would happen if we did not include the pilot project in the Lotus release? However, we will still have a separate environment where we could do testing, but they release, but the institutions who will get the Lotus release will not have this pilot project, included.
- Erin: I am not from an institution that is going to go live on Lotus or Morning Glory. But I think the concern is going to be less about the user's use case and more about the inventory use cases being kicked even further down the line.
- Amanda: I basically echo pretty much everything that Erin just said.
- Thomas: I would say for us we really aren't going to probably use or need bulk edit for users. But what Erin said is probably true for us too. I think you'll see more grumblings that bulk edit functionality is being pushed down for item and instance records.
- ????: Bulk functionality via data import for inventory records, even though it's not exactly what people want, like deletion isn't going to come about because bulk edit gets finished. So from my perspective as a metadata management person, even if it would push it further out, it's worth it if it's better, especially since we're, we're getting by without it right now. I would rather have it work right than have it kind of work and then not get really what we want until morning glory anyway.
- Mark: I would prefer that If we're going to rush it to get it done by Lotus and perhaps not have all the functionality, I would just assume we wait till Morning Glory and do it right the first time instead of kicking out something that's halfway there, but not there yet. So a lot depends on what can be done. And if you can do it by the end of Lotus, that would be great. But if we're going to be cutting things out, taking shortcuts, and things aren't going to work quite the way they should work, I just assume we have a full feature set when it's unveiled, as opposed to otherwise.
- Magda: I agree with this. I think this is what everybody else was saying too, that we don't want to have something that this part of the release that is not reliable. We don't want to introduce an app that can do more harm than help. At this moment I have to say that the deadline, December 3rd, from the development point of view is rather early.
- Magda: As you saw on the development board, most of the stores are in progress. I will see them for the first time, If everything goes well on Friday, and Friday is the deadline to ask for inclusion in the Lotus release. To be honest, I am not sure I will have enough time to be confident to say we are not introducing a problem. This is a pilot project. We know that the functionality will be limited, so we will not have in-app editing. It will be as discussed, the downloading and uploading of the files only. But what I would like to suggest is that we will start the process with the Product Council, Technical Counsel, and review with you and the SIGs. As if we were planning to include bulk edit in the Lotus release. However, I would like to keep the option open that we will pull the plug before the development deadline and say no, we are not including it in Lotus because the application is not stable enough. Yeah. I think that makes a lot of sense.
- Erin: I think that makes a lot of sense.
- Thomas: Yeah, that sounds fair.
- Magda: Great. Thank you.
- Magda: If someone else has a different opinion, please speak up because I would, like to proceed with, PC, TC, and start getting all the approvals, and feedback, but have the option to say no, we are not ready to include in Lotus.
- Magda: I don't hear any objection. It looks like we all agree. Thank you very much.
- Magda: Next steps - I think it's pretty obvious that the next step after the user app will be inventory and from the inventory will be editing items, because this is coming, um, very often in our conversation. We probably will discuss during the next few meetings what the use cases for bulk editing items are the most urgent. And then I would like us to start talking about what is next after items.
- Thomas: I'm just thinking a little bit ahead with items. And I know one thing that's different with FOLIO compared to our old LMS is that the location is set on either the holding record are the item record whereas before it was primarily just set in the item record. So, we've been setting the locations on the holding record level. And from Access Services' point of view, that is one of the things that we'd probably be changing the most is the location.
- Magda: Then we would need to take into account the holdings, not only the items.
- Erin: But to be clear, the structure of the locations are designed for that, because setting an item value overrides the holding value for circulation behavior. It shouldn't be problematic. Now whether you guys have uncovered something, another question, but you should still be able to do what you need to do on the item record without having that on the holdings.
- Thomas: Right. I'm just thinking about our workflows right now, and locations are being set on the holding record level. So it's a lot cleaner. So I'm just kind that if we add that to the item editing, we might not want to use it until we get to the holding level bulk edit.
- Magda: We may want to change the approach then and concentrate on scenarios because the scenario you are bringing up Tom is the most common commonly mentioned scenario, e.g., items are being moved or the collections being moved and you need to change the location. So instead of concentrating on the holdings or items or other records, just concentrate on locations, moving locations.
- Sara: So I think that there's something key to talk about here. So for example, I've had to move a complete range of call numbers from our sublibrary to our music sublibrary. So that's the library and the collection to Main. So that's one thing. And that had to be done at the holdings level. So, you update the holdings record and it goes down to the items. But, more importantly, or more frequently, what happens is you're putting things on reserve. And that does not happen at the holdings level. That happens at the item level, but at the same time, you have to make sure that you're not changing the permanent location. You're changing the temporary location for a time. We have to keep those two different scenarios in mind as to two different use cases. I changed at the holdings level all the time. It is not just changing the location at the holdings record level. It has to also be possible to do individual items for temporary. That scenario is almost more frequent and common.
- Thomas: Instead of saying that we're wanting to edit the locations at a particular level, we just want to edit locations and then spec that the system to determine where to change that.
- Erin: You are never going to be able to code the logic in FOLIO enough to handle. all the different ways that libraries could choose to use locations or not. I think everything you're saying is correct, but I do think that the way that the underlying effective location logic is set up, which was all designed way early on in the project, is actually set up to accommodate all the scenarios you're thinking of. And we don't need to get that complicated. I think we can start the scenarios, as Magda said. When we get to the items and kind of build our approach based on the specific scenarios. But I don't think we need to get super fancy with this. The librarian is going to have to build the specific logic.
- Sara: I guess as long as we can designate which record we're editing, then we should be safe. Right? I can say, I want to bulk edit at the item level. And in that case, I am bulk editing the temporary location, not the permanent one.
- Magda: So I think differentiating between permanent and temporary location should not be that difficult in either approach. If we do the in-app approach, then there will be a separate field to be picked up. And if we go with the CSV approach, this will be a separate column for the permanent and temporary locations.
|
| Mitigation of Bulk Edit UX issues Slide 9: - Query-based, itemized, combination (for example: change location of the following holdings that are not currently checked out)
Slide 16: - Long term - we will support both in app and local editing
- Short term - local editing for the pilot program
Slide 17: - Provide a more transparent way of understanding what FOLIO did when batch processing
- Better understanding of what a failure means -- did it revert the record, delete the record, invalidate the record?
- Itemize failures so it’s easy to identify affected records, e.g. “record #XXXXXX failed,” not “7 of 10,000 changed failed”
- Pay particular attention to global failure where feedback is especially spare
- Give some indication, if possible, of how failure can be avoided
- Provide some indication on how to re-try or follow-up from a failure
Slide 19 - Optimize .csv files for understandability
- Make it very clear which fields can or should be edited and which should be avoided (in app or local edits?)
- Provide some degree of instruction on how to make changes to commonly edited fields like status and location (in app?)
- Give users the power to rollback changes upon upload if files are corrupted or mistakes were made (pre-update records stored in S3)
- Anticipate potentials error and provide warnings, e.g. “Is this correct?,” “Are you sure?”
Mockup- file upload | Mockup - are you sure | Mockup - delete modal | Mockup - delete errors | - Magda: This is a good point that the temporary location is being more often changed than the permanent location. So we can maybe prioritize how this will be handled in the UI. And in the CSV approach, this will be just updating one column. And when I say, if we are going, I think it’s pretty obvious from the last meeting that we will need to support both approaches, the CSV local editing approach and the in-app approach brought up during the usability UX studies as something that librarians would like to have as well. And I think this is a good segue the next item on our agenda, which is the mitigation of the bulk edit UX issues that were brought up during the research that was done and reviewed last week.
- Magda: Uh, last week I linked to the slides from Ryan's presentation. I was hoping we could walk through the proposed mock-ups. I would like to hear your feedback and if you think what we are proposing addresses the issues or not. We have eight minutes left. So most likely we will not cover all the slides and all the mock-ups. Let’s start and see how far we can go.
- From slides: The first slide was about identifying the records.
- Query base - Records are populated based on conditions, e.g., source type or location, etc.
- Itemized - Barcodes (or another identifier) are already known and provided.
- Combination - Populate records within a known set based on conditions e.g. “change the location of the following holdings that are not current checked out”
- Magda: I understand this to be just a special case for query base record. Is this not if how you understand that?
- Erin: I think the question here is how you figure out what holdings you wanted to change. So, in that case then, yeah, that is query-based.
- Magda: So, let's assume for our discussion purposes, we are talking about items and we would like to change the location of the items that are not currently checked out.
- Jackie?: The itemized list, at least as I understand it, you're saying change all of these locations from this location to this location. Whereas the combination you might have the itemized list and then use that list to query. So that's how it's a combination.
- Magda: So, for example, you have created a list of items or holdings that are associated with the given location, where you have this list, and then next time you would like to narrow down the search and get only those items that are not checked out. Correct?
- Jackie?: That's how I understood it to be and how it was been a combination because you're doing both of the things on the left side.
- Magda: The way I see this is, two things may happen. One is we would not update the record if the record is checked out, if you are changing the location and the record is checked out, we will not make the changes to those records. It's one approach. And so this will fall into the category of the errors when you get the information that the records cannot be updated because it is checked out.
- Sara: So, can I then override that:
- Magda: You would be able to, but not, not at this point.
- Magda: Would you like to change the location of the records that are checked out?
- Sara: Yes, my goal is to move them so that when the book comes back, it is then shelved within the right location. It's not that I want to change the Loan Status or anything like that. It's that all these things that are shelves together next to each other are being moved from location A to location B. And when it comes back, it should go to where everything else is.
- Thomas: Right. But location can also affect circulation rules too depending on how the institution has them set up. So, for instance, we have a few locations that certain things aren't allowed to circulate. So, if you're switching it from a location that allows circulation into a location that does not, that could impact the circ rules.
- Sara: So, this is my point that we need complex data to test because this is exactly the type of thing, right. Whether it's a user or an item. And additionally, let's say, we're going to put a whole bunch of things on reserve. We might then separately know, okay these things are currently checked out. We need to do recalls because now what they're going … that's one scenario or it doesn't really matter. Whether the person keeps it for two months more because they have it out for three months and they already have it out for a month. But when it comes back, we want it. We don't want to have to remember, oh my gosh, there are these five things that are checked out and we have to remember to change them whenever they come back and send them to this other location.
- Thomas: That would require them to put a queuing system in the background so once the bulk edit is done, it would have to go through or see anything that is charged and queue up the edit. I liked that idea. I think that's way too complicated.
- Thomas: Erin’s a little bit better at the rules. Unfortunately, she left. My understanding is that when something is checked out, that the policies at that time are written into the charge record. I do know that they are checked again at renewal if I am correct. So theoretically, if you're moving something and it would affect a circ rule, it would not modify the current record, but if they renewed it, it could enact another rule. And that's where it might get sticky. I'm not sure when recalls are checked. If that policy is written on the charge information, and that is what's used when a recall is placed, or if it rechecks the circulation rules. So that's the part of it that I'm kind of worried might get sloppy.
- Magda: This is a great conversation and I regret it already after 11. We will come back to this conversation at our next meeting in two weeks. And we will continue also on the responses to the other surveys. Thank you very much again for your feedback and let's stay in touch on slack and see you in two weeks. Thank you.
|