2022-5-17 Bulk Edit Working Group Meeting Notes

Housekeeping

• Please add your name to the attendees list

Development updates

• Development status
• Development team scrum board

• Christine: I'm Christine Tobias for anyone who doesn't know me. I'm at Michigan state university libraries, and I'm also a member of the documentation work group. I'm the user management liaison for that group, and Erin Nettifee is the resource access liaison for that group. The documentation work group began last summer in 2021. And what we write the technical documentation for the docs.folio.org site, the official documentation for FOLIO which contains the basics of installing and using the FOLIO UI at a high level. It does not include any institutional workflows.
• Christine:  We have written documentation for Honeysuckle Iris, Juniper, and just yesterday we published a Kiwi. We have different volunteers who are responsible for writing the documentation for each app. With bulk edit coming up in Morning Glory, we need to have somebody start documenting the bulk edit app. So this is basically a call for volunteers.
• Christine: It's not a scary endeavor by any means. The group works together and we meet monthly. We write our documentation in a shared Google drive folder. We use markdown language to write our documentation, but it is okay if you don't know how to write in markdown language, you can write it in plain text. And we have members who can help you converted to markdown. We simply use the release notes and the FOLIO dev sites to iteratively change the documentation. Right now we are starting on Lotus.
• Christine: What we do is write documentation and bring it to the respective interest groups for comments and suggestions. When the SIG gives it the thumbs up it gets published.
• Christine: So we need somebody to take on the bulk edit app. I have to be honest, it will take some time to get started and build a foundation. But with the changes being iterative with each release, once you have that foundational document, it doesn't take as much time to make changes. So if you're interested in more information or you excited and you want to volunteer and jump on board just let me or Erin Nettifee know. We are happy to help onboard you into the documentation work group.
• Christine: Erin and I just wanted to bring to your attention that we need some help with the bulk edit app. Ddoes anyone have any questions or concerns that I can address right now?
• Magda: I would like to add that at this point bulk edit has a pretty decent code coverage when it comes to use test cases in Raleigh, we also have our internal documentation for the team that we would be more than happy to share with the person who is brave enough to start working on the documentation.

• Christine: It's definitely a community effort. It takes a village. So you would have the support of the various groups to get you through it.

• Christine: We meet once a month on the second Wednesday of the month. Our next meeting is scheduled for Wednesday June 8th. And we will hopefully have our Lotus documentation drafted and ready to publish. Let me know if you have any questions or if you're interested.

• Magda: Do we need to have a deadline for someone to volunteer?

• Christine: I think if they volunteered before the next documentation work group meeting, which is June 8th, that would probably be best. The sooner, the better, because even though bulk edit isn't going to be ready until the Morning Glory, this person should allow themselves some time to building that document. So in the next couple of weeks, for sure.

• Magda: So we have 17 people on the call and the 41 people in the Slack channel. If no one volunteers from this group, maybe it would make sense to post also the question on the .

• And the questions, comments, we are not moving to the next bullet, Andrew, someone volunteers,

UAT review

UAT follow-up 

• Magda: I think this become a good segue to my next bullet on the agenda, which is the failed user acceptance testing. I call it failed because I got only one response out of 41 people in the slack channel and at lease 10 people attending on these meetings on a regular basis. And I got only four responses as a followup from those who did not responded. We will another user acceptance testing probably in a couple of weeks and I definitely would like us to do better. So, the question I have is how much time do you think we need to have allocated to the testing to give you enough time to participate?
• Leeda: I would say at least two weeks. I'm more on the metadata side than the user side, but I did want to get in there, time permitting. But I believe Wednesday we were till we had until Tuesday. And when I went to get in there Monday, the system was down. So then we had until Wednesday morning, But then I was booked. I think two weeks I could find some time, but less than a week is just not enough time.
• Magda: I apologize for the system being down. It is something that our team does not fully controls.
• Leeda: We have to be prepared for it and be able to work again. The two weeks would help cushion.
• Magda: My concern was that two weeks will be just too long that we will be postponing the answer, but of course we will allocate two weeks.
• Magda: And then, do we need to allocate a little bit more time to spend playing with the application more as a group before you, UAT so you are more comfortable with what to expect? Because my concern was that maybe this was just too convoluted for you and you just did not allocated enough time and it wasn't enticing for you to start playing with the app.
• Bob: What exactly is, what exactly do you do for this user acceptance testing?
• Magda: Magda explained to Bob that you go through the steps of using the app and then respond to a survey.
• Magda: From the four responses, somebody said more reminders. I didn't want it to be annoying. But I feel that I'm getting a permission to e annoying. I will be sending those reminders next time.
• Sara: I think actually all the suggestions so far are really good. You should be annoying to us, you should be a squeaky wheel, and we need reminders. And I think having a proposed two weeks because things happen and then especially right now, people are towards the end of the fiscal year, and we're getting ready to migrate. But also this time of year, people are desperately trying to take the days off that they need to take off or they lose them. So then that cuts into your weeks. And so having that extra the two weeks but maybe you could say with the caveat that if you get sufficient responses, whatever number you say that you'll close it early. So if you really want to participate better to participate early, but it will also give everybody time to participate of everybody has crazy schedules. I think also the third thing kind of what you suggested and then actually Bob's response was actually kind of confirming it. I think I know for me, I often feel like I need a little hand holding to begin with. Once I've done it once it's okay. But I still get confused and then that just takes more time and then I get frustrated. I have all these other things, emails and chats and slacks coming at me, and I need to deal with those things. I just don't have time. I can't finish this. And then I back out and I just close. I didn't do this with yours, but this has happened to me with others. Where, I just don't have the mind space to figure everything out. So having that initial together kind of walking through, really baby stepping me through it would be helpful and then I'll feel like, OK I think I get it. I can go do this now.
• Magda: So we can devote one of our meetings, probably not in two weeks, but at the following meeting, we can make it a user acceptance testing kickoff. And then we do the hand holding, like walking through the steps and what I would like, what type of feedback I would like to get from you. So after that meeting is over, you should feel a bit more comfortable with the app and with my expectation. And then we will start two weeks for the testing period.
• Magda: The challenge is that this environment is also used for performance testing, but this can be coordinated with the team.
• Jennifer: I just wanted to, um, agree with what's been said so far, please be annoying. The Five Colleges is migrating next month. So our attention span is, I don't think I have an attention span anymore, but anyway, frequent reminders and just having that extra week to fill in that survey would be really nice. I'd appreciate a little more guidance. And I was wondering if we could maybe use a lab as well as a place to come together and test and work on some of these steps step-by-step things as well. I know many of us are in lab.
• Magda: So you're talking about the Thursday lab. This is a great idea. The more the merrier, and I'm not sure everybody that is on this group will be able to to make it. I know I will not be able to make it this week, but I can do this following week. But I like the idea we can do that too. I definitely cannot attend those meetings.
• Magda: Thank you for the feedback.
• Sara: I can snatch moments, right? I can snatch and fit in 10 minutes here, 10 minutes there maybe. There is no way to save your survey adn come back easily or. That is a huge problem.
• Magda: This is a very good feedback.
• Magda: I think the whole user acceptance testing for for this should not take you more than 10 minutes altogether, assuming that you are familiar with with the app.
• Magda: And I think what I would like this application to be be simple. So you don't need to spend hours to figure it out  and make it like really simple to figure out the things that you can do. I think we succeeded with the data export to make it pretty straightforward to use, and I would like bulk to be the same. But also to give you the flexibility as well, and that's why we have both the  in-app approach and CSV approach, one is simple and quick and the other one is in more involving but it's also more powerful. Thank you very much. This was awesome feedback.

• And I would like to move to the affected versus, um, selected records. Uh, can you see my screen? Am I sharing my screen? Yes, yes I do. So, um, I put small presentation, uh, because I think this will help, uh, conveying the message.

And this is the slide. So here's the example of the records that we plan to update. We have, uh, three records and, uh, two of them have a art week, um, Aetna location and the one that has annex on the, for in app edit form, we select that we would like to change the permanent location to honor. So because one of the records already has, um, annex.

Then when we go to the R U shoe form, we see only two records instead of two, instead of three, because only two will be changed. So those are the effect of the records. And this is what you see on the form. So you see here two records because on the two records will be changed. And, uh, the list has also, uh, the preview has only two records.

And when you click down on download preview, it shows the only two records. And my question to you is, is this intuitive, or would you expect on the screen to have three records and then, and so no matter what you have on that, on the data, on the first dataset, if this is overriding the already existing data or, uh, what would, what would be the most intuitive behavior for you?

So if I can just speak up, because I want to, I actually was saying earlier is that I didn't, I'm sorry that I misunderstood earlier, Bob and Donald about the Checkmarx I'm seeing now that my screen is tiny because I'm on a Chromebook. Sorry. So when we, I didn't realize that we're not saying. Change permanent location from this to this, we're actually saying change that location to this.

And so if my permanent, I cannot control which ones are being changed and your case is not the one that's not being changed because it is already permanent location. Yeah. That then, then I go back to, then I totally agree with Donald and Bob that we have to be able to control for that. Because when you have thousands of records, you know that you're not changing things that are not what you intend, and this is a little bit different, but it's the same it's related because there's match and affected.

And so right now, the three records that you brought back, what did they match on? They matched on something. They got selected off of something that is not the thing that you're changing because otherwise the annex one wouldn't. So, uh, you go the list of the barcodes. Uh, this is how, um, how this, uh, uh, bug edit started.

Um, so let's say you go to the list of the barcodes from circulation that was scanned. You uploaded it and you see the records. But, uh, you know, in my example is pretty, pretty prominent. It's visible because the first record is annexed. But in reality, if you have hundreds of records, the, the one that is already matching, then new location, maybe down the road, down the, down the road, and you will not see it on that, on the previous screen.

So, um, from what you're saying, that the behavior that we implemented that on the screen,

Did you see all the affected records is not intuitive and needs to be changed?

I think it would be better to have something, either the message up there that says one record won't be changed for whatever reason, or to have an additional in this case, an additional row that is, has some sort of distinct look to it in some way, showing that it's not going to be changed, maybe red, you know, or a message in one of the columns is as, uh, to tell you why, why it's not going to be why it was excluded.

I mean, for me, it's intuitive now after looking at different for some time, But if you had just showed this to me without explanation, I'd be wondering why there's only two. When I started with three, you will be thinking that the application doesn't work. That the application, I would be confused. I probably would figure it out, but I mean, it's not intuitive.

And again, if you have quantity, as soon as we have a thousand records, how, and there's, you know, five not there, how, how do you locate them? How do you, you know, it's easy with three and know why they didn't change. It could be different reasons. Well, it sounds like, yeah, in this form, the only reason you will not have this record is because the location is already.

Uh, it has already the data and also in, I think we discussed in prior of, in prior meetings that if the user has, um, if, if you are working on the bucket at, and in the meantime, someone change, uh, the record. So between the moment, the moment you populated the screen, and then someone made a change in the location of the, one of the records.

And by the time you get to this screen, this only records will be excluded.

Magda after you submit this saving close modal and it's submitted, doesn't the next screen you come to also have like an error accordion that tells you which ones couldn't be changed, but this is not an error because we are not even attempting to record. Okay. So maybe it's a different, uh, 40 and then yeah, it is.

Yeah, there is. Yeah. If something goes wrong in the process and I don't have slide four for this. Uh, but, uh, yeah, you're you're right. The error, the following. Uh, let me go back to the app.

And eats, we do this quickly. I wanted to go here. Yeah. So maybe there's an additional accordion that says these things couldn't be changed. So you have errors, plus you have something else. So let me try to swim.

Yeah. I have problem with this file of that with me. Um,

and it sounds like in all reality, you could have both right. There could be two error. It's my fault. I thought that go five, right. Two could be errors and three could be, well, they were already annex. And so they didn't change.

I'm sorry. I'm concentrating on the files and. I guess I was meaning most of for CUNY.

Let me, sorry, let me start again and

want to show you this.

Uh,

and this should be defined.

So, uh, this is the notification of the error. When we uploading the file and the duplicate entry, please disregard the quotes. This is because the quote, the quote quotes are in the,

in the, in the file. So now we are starting the, um,

and bucketed. We will make the Fairmont and location. Let's make it.

Now all three records will be affected or we got those two records. Yeah. Because one of them was already in annex. So, um, we are saving it

and those are right now, the errors that we see from the uploading the files. But in fact, you will have the record here, only the errors that, uh, for some reason the, the, uh, update could not happen. So from what you're saying, we could change the label for this instead of make it notification. And list here, the records that were not affected because of it, because the data was already there that, or maybe an additional and another bar, another, uh, isn't it, isn't it different?

Isn't the thing that's happening. Different could be different than just an error or now. So right now we have only ed or, uh, accordion, but from what you're saying to have another accordion for notifications, I thought what you guys were talking about was different, uh, that these, the thing that could happen is different than an error.

It's not quite an error. Yeah, exactly. So that's why I suggest to rename this as errors and notifications.

I think I sold a hence hand up someone was, so that was me. And I have to apologize. I disappeared for a couple of months because of our implementation. So I'm just getting back on the swing of things. But the term that we use for this and data import, I believe is discarded for the records where there's no error, but no action was taken because it didn't meet the criteria for the import.

Um, so I just wanted to throw that out there as potential language for describing this category, this car, this car, uh, this car that it's not, I think, applicable for bulk edit because we are not discarding. Anything that I could import you are discarding the discarding. It means you are not importing it.

Right. So that does not make to inventory. In our case, we are not, we are just not, not modifying the record that I go to stare.

We are on like one minute left. We will definitely come back, uh, come back to this conversation to get, uh, how we can handle the options that I heard today. One of them was, uh, information on the audio short form stating that some of the records will not be affected. The other one is to add notification on the confirmation screen.

And, uh, the third option would be instead of showing the, um,

affected records on the. On this farm, we could continue to show all the records here. So you will still see three and you will see three here, no matter what, if this is affected or not.

If Monday, if this screen, if, if this screen knows these are the records that will be acted on, we not then have next, like a button that we click next. And then we get a list of the ones that I will not act on

about the one that's going to act on. It must know about the ones that's not going to act on. So if we could then just see those as well, I think that would be a big help.

Okay. That's also very good feedback. I think we are on top of the hour. Thank you so much for the great feedback as always good luck with everything else you have besides bulk edits, and I'll see you in two weeks. Bye-bye thanks. Bye-bye