Page Comparison

• Magda: We have a guest presenter today. Uh, Christine Tobias will be talking about the documentation for Bulk Edit and the project as well. But before we get to the point, I would like to give a quick update on the development progress and go over the list of agenda items after Christine's presentation.
• Magda: I will start with the, with the development board of the team. We have a new quality assurance engineer on the team. She is very thorough. Every ticket goes through her for review and to completion. As you can see we have an additional column in QA. So once the developers complete their development and the code is committed and reviewed by other developers, then it is evaluated by the quality assurance. And after that it is landing in my column where I review if what was implemented is what we expected. That it's a huge step forward to assure that the quality is as we would like to. I was struggling in the prior releases spending a lot of time on finding bugs that should have been prevented earlier. So this is, this is really good news. Do you have any questions about that?

Image Added

• Magda: When it comes to the work, as you see, we have a lot of work in progress. We have also some other work because the team is responsible also for OAI-PMH. But everywhere you see mod data export worker (MODEXPW), it is the backend work for the bulk edit.
• Magda: As we discussed at our last meeting, I added stories for narrowing down the options in the bulk edit form.  This is bulk edit 76 and also to enable type ahead in the location look up. The team estimated that hopefully we will be able to work on this in the next sprint that starts in two weeks. And this will be the last sprint of the Morning Glory development. So there's a big chance this will make that release.

Image Added

• Magda: I wanted to show you the snapshot version that was building this morning, We addressed several bugs that we saw recently.

• Magda: We added the progress bar the displays once the data is being loaded.

Image Added

• Magda: And this is the "are you sure" form that we had problems last time. The record count was incorrect. This has been resolved.

Image Added

• Magda: I have a question about the expected behavior. Hopefully you will be able to discuss this later today and downloading the preview.
• Bob: Was there a confirmation of the changes?
• Magda: There used to be the green popup. It is gone. This is a work in progress. We lost it as some point. It will be back confirming the changes were committed.
• Magda: And as you can see here is the "New Bulk Edit" button.

Image Added

• Magda: It will reset to the original state but It does not reset the radio button and keeps the App that was selected, in this case "Inventory Items."  Any questions for comments?

Image Added

• Bob asked about the narrow options in drop-down.
• Magda: This is what I was referring to with UIBULKED-76. Hopefully this will get squeezed into Morning Glory.
• Bob: Exciting to see the changes.
• Magda: Yes it is moving along. This is it for the development update. Any questions?
• Don: I have a question about the preview screen. Is it possible to show what the current state is next to the preview of the changes we intend to make on the "Preview of records to be cahnged" screen to provide one last opportunity to catch any problems, e.g., records you did not intend to change.
• Magda: This ties into what I want to discuss later in this meeting regarding selected vs. affected recrods. But I do agree with you that you would like to have here additional column, that if you are changing the location, you would like to see. What is the location. So it will be just repeating whatever was on the, on the first preview preview.
• Don: Exactly.

• Bob: So, one thing you can do in Sierra is you can check on check and uncheck at that point (agreement from Don).

• Magda: Yes, we don't have this option right here right now, but I'm not saying we will not have this ever. This is something we can discuss. The checkbox definitely will work on the smaller data set. Let's say you have like 100 records and you want to make those changes on the 100. And then this is the moment you want to have the check boxes. But if you have thousands of records the check boxes may not be that helpful. So I'm making a note for two things are the columns of the records that will be modified, and the other one checked boxes to narrow down the list of the records that would be updated.

• Bob: And if we couldn't have check boxes for larger sets, then there was a point in the process where you can re-upload after you take out the ones that you don't want from the preview spreadsheet to start a new bulk edit?

• Magda: But you cannot upload the preview. Not in the in-app approach. For this you will need to extract only the one column from the preview spreadsheet, the ids, and then run a new bulk edit using those ids.

• Bob: I see. You cannot have all those other fields from the spreadsheet. Just the ids can be in the file.
• Magda: We will be working on CSV approach for items, but this will not be available by the end of Morning Glory, but I'm really glad that you see that connection, the fact that you can use this approach also. I will make a note of this as well for the CSV upload.
• Lloyd: I'm wondering, will there be a possibility of selecting the thing I want to change? So I only want to change all annex to another location but leave the others unchanged.
• Magda: We will get back to this shortly when we discuss matched and affected records.

• Sara: I'm confused by what Donald, Bob, and Lloyd said. I would have understood that if I had three records and two of them had permanent location stacks, and the third one said annex, and I indicated that I wanted the change to be stacks to new books that then only two records would be affected by my change because the item in annex would not have the permanent location that I was indicating needed to be changed. And so I'm not sure why the check boxes are necessary. What for me would be more relevant would be identifying which records did not actually meet my expected criteria so that I can perhaps re-run the file to pick up the records that were not identified in my original query.

• Magda: We will be working on bulk edit for several releases to come. And once you start having a little bit more time to play with the application, I'm sure you will be providing more feedback like we are getting now of what would make your life easier. I'm not saying we will be able to address all of your suggestions and address them right away. But I will definitely put them on the roadmap. And from this discussion it's obvious you need a little bit more on the screen and more flexibility in seeing the columns. And regarding the selection, maybe instead of doing it on the "are you sure" form, we should allow the selection of the record on that preview screen. I would like to table this conversation for now. We will definitely come back to it. I would like to give Christine time to talk and then we can come back to the conversation about selected and affected records and also to spend at least couple of minutes to talk about the user acceptance testing and what we can do to make it better in the future.

Bulk edit documentation for the app for docs.folio.org (Christine Tobias)

• Magda: And I would like to move to the affected versus, um, selected records.

• Magda: So here's the example of the records that we plan to update. We have three records and two of them have ORWIG ETHNO CD, and one that has Annex.

  
  

Image Added

• Magda: On the in-app edit fom, we select that we would like to change the permanent location to Annex.

Image Added

• Magda: Then when we go to the "are you sure" form, we see only two records instead of three, because only two will be changed. So those are the affected records. And this is what you see on the form. So you see here two records because only the two records will be changed. And 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 to see three records records on the screen. What would be the most intuitive behavior for you?

Image Added

• Sara: I'm sorry that I misunderstood earlier, Bob and Donald, about the Check marks. 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. 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 need to 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 be there.
• Magda: So you go the list of the barcodes. This is how how this bug edit started. So let's say you got a list of the barcodes from circulation that was scanned. You uploaded it and you see the records. But you know, in my example it is prominent. It's visible because the first record is annexed. But in reality, if you have hundreds of records and the one that is already matching the new location may be further down in the the list and you will not see it on the previous screen. So from what you're saying, the behavior that we implemented that on the screen is not intuitive and needs to be changed?
• Bob: 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 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 telling you why it was excluded.
• Sara: If you have quantity, as soon as we have a thousand records with five not there, how do you locate them? How do you know why they didn't change. It could be different reasons.
• Kimie: 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?
• Magda: But this is not an error because we are not even attempting to record. Okay.
• Kimie: So maybe it's a different accordion.
• Magda: Yeah, it is.
• Kimie: 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.
• Sara: It sounds like in all reality, you could have both right. There could be two error. two could be errors and three could be, well, they were already annex. And so they didn't change.
• Magda: So from what you're saying, we could change the label from "Errors" (in the screen below) and instead of make it  "notifications" and list here the records that were not affected because the data was already there.

Image Added

• Kimie: That or may an additional bar. Isn't the thing that's happening different than just an error? It's not quite an error.
• Magda: Yeah, exactly. So that's why I suggest to rename this as errors and notifications.
• Christie: In data import we use discarded for the records where there's no error, but no action was taken because it didn't meet the criteria for the import. So I just wanted to throw that out there as potential language for describing this category.
• Magda: Discarded is not not, I think, applicable for bulk edit because we are not discarding. In our case, we are just not modifying the record not discarding it.
• Magda: We are on like one minute left. We will definitely come back to this conversation to get how we can handle the options that I heard today.
  • One of them was information on the "are your sure" form stating that some of the records will not be affected.
  • The other one is to add notification on the confirmation screen.
  • And, the third option would be instead of showing the only the affected records on the "affected records" screen, you will see all of them on the form. So, in our example, you will still see three records, showing records if there are affected or not.
• Sara: If on this screen the system knows these are the records that will be acted on, can we have a next button that we click to get a list of the records that will not be acted on?
• Magda: 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.