Page Comparison

• Magda: The development status, there is not much information on this because we are now mixing Lotus and Morning Glory builds.
• Magda: We have added radio buttons instead of checkboxes. There is a bug. the drop-down should default to  "select record identifier." it should not default to barcode. Uploading the barcode file does not work just yet.

• Magda: We get an error message when trying to upload barcodes.

• Magda: We are working on that. There is some progress on the backend, but this is not visible to the UI. So please continue to be patient.
• Magda: On the Scrum Board, you can see there is are a lot of other issues. There is progress for items, mostly on the backend.  And front-end developers are working on addressing bugfest issues.
• Magda: And this is the work on the backend on issues of displaying records and saving them.

• Magda: The main part of the meeting today, I would like to return to our discussion from the last meeting about the behavior of the action menu, depending on the permissions that they use has. Their permissions will differ between the in-app and CSV approach. After that, I would like to walk again through user records in the in-app approach. I would like to get your feedback on priorities for the next steps. I would like to go back to our conversation regarding the apps with bug edit capabilities that we touched on. Erin mentioned that none of them are actually apps. We will need to either rename them or the options in the accordion. If time permits we will get to the pilot project UIT.
•  Magda: So let me start the presentation. I'll start with a quick review of what we discussed last time. So we talk about the permissions that were introduced in Lotus, which was were separate for edit, view, and delete.

• Magda: And depending on the permissions you had, the behavior of the action menu, once you open the application and you have a CSV type of permission. You could see right away--start bug edit. Even before the preview was populated.

• Magda: Once the preview was populated, you could download the matched errors or start bulk edit. And if the error accordion was populated, you would have the additional options of download errors in CSV format.

• 
  

  Magda: Please feel free to interrupt me at any moment, if you have an additional question.

• Magda: And this is the last screen for a CSV approach. Once the edit has been completed we see the completed process and you can start another by uploading another CSV file. So this is how it works in Lotus.

NOTES ARE NOT COMPLETED YET. STILL WORKING ON THEM...

Revisit naming convention for Apps with bulk edit capabilities accordion

Image Removed

• Magda: Last week we also discussed that in the morning glory we will be introducing new permissions and we agreed that their names will need to be renamed in Lotus. The new ones in Lotus will be named
  • Bulk Edit: In-app- Edit 
  • Bulk Edit: In-app - View
  • Bulk Edit: In-app - Delete

• Magda: With in-app permission enabled – Navigating to the landing page the action menu is not available because there is nothing the user can do.

• Magda: Now we have uploaded the file. The preview is populated with errors. You see the following options:
  • Download matched records (CSV) - a copy of the preview of affected records
  • Download errors (CSV) - a copy of errors
  • Start bulk edit - will open a screen for in-app editing

• 
  

  Magda: Once the bulk edit is complete, what should be the actions displayed there? We discussed that it would have the option to save changed records in the CSV file and also saved errors.

• Erin: I have a question about this screen Magda. The green box success toast. Is that going to behave like a success toast, where it appears on the screen and then it goes away? Or is that going to stay on the screen?

• Magda: It will stay on the screen because I think you would like to have a longer notification, not something that will pass. And if you don't pay attention, you will not notice it. Do you have problems with this?

• Erin: No, that's, that's fine with me. I mean, others can chime in. It just wasn't clear to me from the screenshot.
• Magda: Yes this is the exact behavior we have right now. It does persist. And actually, there is a bug because it persists even into the next bulk edit.

• Erin: But let's say I do an update and for some reason, 340 work, and 10 of them fail. Is it still a green box?

• Magda: (summary of the discussion with Erin about this screen) Yes, but it will be a green box minus those that were not updated. So in this example, you submitted 250 entries. 248 records were matched, 1 was not updated because there was some error. And one was not matched. So you have here notification that one record was not updated of the 248 that has a match.

• Erin: So the error that appears on the screen is found before I push the ...

• Magda: Yes, but it's a matter of updating the mock-up. This actually should read instead invalid date for the status or something like that.

• Erin: Yeah. You would get a better error message?
• Magda: Exactly. And it will specify what went wrong and indicate the record identifier. And it will have the option to save those errors so you can go back to the records directly and see what went wrong? Okay. And the other questions?

• Magda: So this was the easy part of the presentation. Now the hardest part starts. Now we will talk about the case where the user has both CSV and in-app permissions, so they can do both.

• Magda: So the user has CSV and in-app approach. They are on the landing page. They have an action menu and they have start bulk edit (CSV). Does it make sense?

• Erin: Yeah.

• Magda: Okay. Now we are moving to a more complicated thing. We are in the inventory items and in inventory, we can only use the in-app approach edit. But they use it also have the permission to start bulk edit with the CSV approach, which is not fully applicable for items at this point. It's applicable only for users. So the question I have is, should this start bunk edit CSV approach display only when they are on the user tab, or should be displayed also on the inventory items tab when the user cannot do anything here with that?

• Erin: So I think in an ideal world, you would go to that landing page and you have an option in the action menu, but you would document or train people to say that the first thing you're going to do is you're going to select the app that you're going to work with.
• Erin: If I'm going to edit user records and I click that user users radio button, then I should see the action menus options that are applicable to users. If I choose inventory, I should see the option menu options that are applicable to inventory. And then my other thought is that those actions should be sorted based on whether it's CSV or in-app and not sort them alphabetically. So you would have a clump of CSV actions, and in-app actions. And maybe even playing around with labeling of the options because that'll make it even more clear that this is for in-app stuff and this is for CSV stuff.

• Erin: I think the chatter in the chat is mostly in agreement with hiding the stuff that you don't need in places where you can hide it. And then clumping the actions by a CSV or in-app.

• Magda: Great, thank you.

• Magda: So another question is, let's assume then that we are in inventory items and I have both CSV and in-app permissions, but I will see start bulk edit. Right? And then when I click the link and I switched to users, I will see a start bulk edit CSV option. Is this what you are proposing are agreeing or not?
• Erin: That makes sense to me (chat agreed).
• Magda: Now we are in users and we have both permissions.

• The summary of this section is best stated by Erin below after some back and forth with Magda.

• Erin: That's a good question for the group. If you have just edited 500 item records and now you need to do another edit with a thousand item records, a separate record set, how do you want to start that process over again? You could go over to the record identifier and click upload your file. One of the questions I would have Magda is can I get to any of these files after I've started a new load?

• Magda: All of them are stored in S3.  They should be in export manager. But I have not tested for how long they stay there.

• Erin: That's okay. I think we just need to get some clarity on it.

• Magda: But is that something that you would like to have?

• Erin: What happens if I accidentally closed the tab or I have to walk away and I come back in 30 minutes and suddenly I can't get back here. How do I get to my files? I think that's the question.

• Magda: They are stored. The matter is how do we make them accessible to you after a while. But when you are saying you want to access the files, you actually have those files on your local machine.

• Erin: I might not have the error messages. And some staff might change machines over the course of time to go show somebody something. It would be nice to be able to get to the file through a tool, an export manager is certainly available as an option. We don't have to go totally down that road because I know we were talking about resetting. Thomas said in chat that he would favor having some sort of reset or start new, start new edit , or something like that.

• Magda: Should we have an option to start over>
• Erin: I have a little bit of a hard time visualizing that at this point. So I'm not entirely sure. It might be interesting to make up a couple of options. Kimmy is favoring having some sort of reset button or reset option.
• Magda: The other option would be just clicking on the bulk edit icon to clear everything on the screen.
• Erin: I wouldn't want to do that because I would totally randomly do that adn screw myself over.
• Magda: Okay. So an additional option in the action manual, right?
• Erin: People in chat are preferring a button.
• Erin: f you want to see an example, in the checkout app there's is an end session button. So there might be a pattern there that you could look you, your developers could look at.
• This image was added post-meeting for convenience to illustrate the example referred to by Erin.

Image RemovedImage Added

• Magda: But the warning should not be end session?

• Erin: I wouldn't call it end session. People seem to like reset.

• Leeda: If you go to inventory, in the left pane, you see the reset all button underneath the search button there. Is that what we're talking about?
• Erin: I don't like that because I think it's really easy to accidentally click that and get rid of the work that's on the screen.

• Magda: With bulk edit, we will be resetting everything, not just the left pane but the main pane, the notification, preview, and errors if applicable. We can talk about this more. Personally, I like the button idea and start over which may not make sense to others.

• Magda: So it looks like we are in agreement on the behavior of the actions menu, depending on the permissions.

• We will discuss this reset button probably next time when we meet.

• Magda: I would like to work on the bulk edit user records in-app. Something that we discussed in early days of bulk edit.

Still incomplete. working on these notes still --Bob

• Magda: So the behavior right now, it's the same as we have implemented. The identifiers.

Image Added

• Magda: Uploading the file

Image Added

• Magda: Populating the preview

Image Added

• Magda: And then start bulk edit.

Image Added

• Magda: And here comes the in-app. 
• Magda: Select an option and it will be email, expiration date, patron group, and probably others that we have prioritized a long time ago with the users SIG. Permissions will be a separate feature because it is complicated. If we do the permissions, and I understand how important they are, we will need to do it in a separate story. It cannot be a part of user records. So please disregard permission, this row here (in the drop-down).

Image Added

• Magda: Here's the list of the actions.
  • Find
  • Add to existing
  • Clear field
  • Replace with all
  • Find and remove these
• Magda: If we select find, It means you are searching for a string within a field. And then when we are replacing it with another string

Image Added

• Magda: So that would build something similar to what we are planning to do for items, but it's more advance because of the find and replace option. We have that clear field and replace it with some other value. We can have replace with another value. And please disregard the permissions for now. Any comments?

Image Added

• Erin: The options listed there are the fields that you can change?
• Magda: Yes.

• Magda: We may also take the approach that we will be implementing, starting with replace, clear field, with those two options that we will be supporting item and then other two existing, but under the existing will be applicable only for the repeatable fields. 

• Erin: I'm not sure about what the distinction is between find and remove, and clear field.

• 
  

  Magda: Clear field is where you clear, whatever it is, it doesn't matter. Find will find these values and remove them. It's more like a conditional.

• Sara: So I was also just needing to get a better handle on the different nuances of the differences because this is actually quite remarkable. To be able to find something in a field and replace it so discreetly is quite wonderful. And so you're suggesting that this will also be possible for items at the item level.

• Magda: In stages.

• Sara: Because find and remove these, if we could get this, this would be so wonderful. I have to do tortures things to be able to do this when I bulk edit certain fields.

• Magda: So we also may then discuss the priorities about that because we can start adding these actions to items to those fields that we have. And then once we have this action within one record type, we can easily use it for other record types. So we will need to determine what is a higher priority, this in-app functionality for users, or build up the complexity of the bulk edits for items, holdings, and other inventory records. But we can have this prioritizing exercise later.

• Magda: But what I'm getting from you is that you like it, right?

• Sara: This is really wonderful. And I guess one other question. Would "add to existing" mean at the end of existing? 

• Magda: Yea at the end.

• Sara: So, maybe we need to just be really specific, like append to existing or something.

• Magda: But does it really matter? This was actually "append existing." I added it when I was still thinking of having the permissions where order does not matter. But to have it for other fields where the order matters, can you give me an example where the order would matters for items like for inventory?

• Sara: For inventory, I would say in my note fields. Very often I want to have the most recent one first. Or I want to know that this is always going to be the last note or always be the first note, because then if I dump it down in Excel or something and I'm chopping up my columns, I want to know where that certain bit of information is. 

• Magda: I don't know if the notes contain the timestamp when the note was added?

• Erin: It depends on the type of note you're talking about. Because most of the notes in inventory are just free text fields on the record. So they have the metadata of the overall record. But if you're talking about the notes modal, like it's used in users, then that note object has its own metadata.
• Sara: I'm talking about notes within records, in different note fields.
• Erin: Jen is pointing out in the chat too, that we're also talking about kind of two different types of fields that you want to work with. You want to work with a free text field like Sara is describing, and then you also want to be able to work with controlled vocabulary fields, which is what permissions are because you want to use the controlled vocabulary of the names of the permissions. And so you might need to define if there is a controlled vocabulary field where the order matters? There shouldn't be because with JSON it shouldn't matter versus a text field where the order matters, which I think are the examples Sara is getting at where she might expect notes on her records to be in a certain order versus other kinds of records and things like that.
• Magda: It will also be applicable for the custom fields. The way I see append or add to existing is for everything that is on the backend is an array. It's something repeatable and it assumes the order of the elements of the array does not play a role. But this is something important to keep in mind.
• Erin: This really increases the complexity of some of this each app involved. You have to determine the fields that can be touched and the options that can be used in the order, that those options can be applied, and things like that. So there's a lot of requirements work here.
• Magda: Once we get to "add to existing" this can definitely be a separate longer discussion about expected behavior. We can also do this again in stages. The first approach would be to assume that whatever we are adding to the existing is appending. So this will be the last one on the list. And at least it will be a consistent behavior. And then, and then we can tweak it.
• Erin: And Jen is wanting to suggest also that a comparison be made to the language that the data import app uses because you don't want to have different meanings in different apps. So that's an excellent point.
• Sara did you have other thoughts? I know that your hand is still up, so I wasn't sure if you had anything else you wanted to add there. So that was good feedback. Okay.
• Magda: So I think we are good with what I have presented so far. We will need to come back and talk about priorities. Do you want this additional action support in inventory, or do you want to implement some elements in the users? We will come back to this.
• Magda: The last is the downloading preview, saving the preview of the records that are not updated yet. This is how they would look once you click save and close.

Image Added

• Magda: And here's a notification that 300 records have been successfully changed. This is the original first mock-up. It has changed obviously. This is moved on top. We'll need to update those to include the changes we've made so far.

Image Added

• Magda: This is the downloaded updated records, downloading errors, and downloading matching records.

Image Added

• Magda: This is an example of saving and the naming convention. It's the naming convention that we already implemented: year, month, date, and the name of the file that was used to trigger the bulk edit.

Image Added

Revisit naming convention for Apps with bulk edit capabilities accordion

Image Added

• Magda: So we have 10 minutes left. I would like to go back to and spend a little bit more time on the accordion for the apps and bulk edit capabilities. So this is what we have right now.

Image Added

• Magda: For now we have users and inventory items. Later we'll have probably in the in-app approach we will be going with inventory, holdings, then inventory items. And then I remember someone said there is no circulation. And there is no acquisition.

• Erin: Can it just be a list of like record types? Cause that's really what you're talking about. It's with circulation, it'll be loans requests. Uh, et cetera, with acquisitions, I assume it would be orders, invoices things like that. You're really talking about record types. And I think that's clearer verbiage than apps here, but, I don't know what others think.

• Jen says. Yes.

• Sara: That's really important because you can't just say order app. There are orders and there are POLs. And that's a huge difference.

• Magda: And then the permissions. We will have hopefully have permissions eventually. And then the link between user permissions, the link between users and inventory, and all those things coming down the road.

• Magda: So you are suggesting we rename it to the records with the bulk edit capabilities instead of apps?

• Erin: I would just call it record types. I don't even think you need the phrase with bulk edit. You are in the bulk edit app. People know that you're in that app. So I would just call it record types. I think that's clear.

• 
  

  Erin: The chat seems to be in agreement with that.

• Sara: When you were listing them earlier, you said holdings and then items. I thought we were doing items next and then holdings.

• Magda: When I holdings, I was assuming that items are already done.

• Magda: Going back to record types. So users, inventory items, inventory holdings, then requests, then loans then orders, etc.

• Erin: I wouldn't put the record types in there until there's functionality.

• Magda: I absolutely agree. Right now we are using gray-out to show what's coming. But this is a teaser for everyone. And I agree we'll update this.