2022-8-9 Bulk Edit Working Group Meeting Notes

• 00:01:24.450 --> 00:01:25.32
• Magda Zacharska: Hello, everyone. I have a question. I don't see myself as a host, so whoever is the host of the meeting, could you please enable the transcription? This will help Bob with taking the notes.
• 00:03:44.550 --> 00:03:47.100
• Magda Zacharska: We don't have everyone, but we have enough so we can start. The transcript is on, so hopefully, this will help Bob Scheier with his meeting notes.
• Magda Zacharska: I am recovering from COVID, and I'm still coughing, so at some point, I will need to mute myself.
• 00:04:40.620 --> 00:04:44.850
• Magda Zacharska: I share my screen, please let me know if you can see the meeting notes.
• Magda Zacharska: Thank you, we have 17 people in the meeting I don't see 17 names in the attendees least please add your name to the list, so we know who has attended.
• 00:06:27.450 --> 00:06:48.540
• Magda Zacharska: The transcript this on and the last housekeeping item is the welcome meeting for Bulk Edit is scheduled for August 31 at 4 pm Eastern Central European Time, which translates to 10 am US Eastern Time. That will be Wednesday, not Tuesday, and if you can attend the meeting, that would be great, this is a separate meeting, so if you cannot be in Hamburg, you can join by Zoom. So the question for the group is anyone from the group planning to attend in person?
• 00:07:16.530 --> 00:07:17.820
• Erin Nettifee: I'll be there virtually. Aaron Weller and Christine Tobias (in chat) are saying that they will both be there in person.
• Magda Zacharska: for everyone else who will not be in person and who will like to contribute to the meeting in some way, is there anything you would like me to discuss or bring up during the meeting is marked as a work working meeting, so I hope to get additional feedback and requirements. Is there anything you would like me to present or bring to the group's attention?
• 00:08:21.960 --> 00:08:24.750
• Erin Nettifee: Are you asking that now, or are you asking people to think about it?
• Magda Zacharska: You can say it now, or you can reach out to me on slack later.
• Erin Nettifee: I think it might be helpful as you're thinking about that group to somehow surface in this wiki space. A schedule of what's planned because you have talked about that in slide decks. Sort of what will come in this release, and this is what will come in this release. I think actually having that in a wiki page would be really helpful for people, so that would be like a central place to go.
• 00:09:47.940 --> 00:09:55.110
• Magda Zacharska: I was looking at this yesterday actually while working on the presentation for the welcome. A high-level roadmap

• Erin Nettifee: So is that what you're going to maintain this spreadsheet?
• Magda Zacharska: I will create a website or a conference page.
• Erin Nettifee: I mean, if this is the this is the Info, I'll just put it on the page for you, and then you can edit it.
• Magda Zacharska: Okay sounds good.
• Magda Zacharska: So, if you have any other comments about what makes sense to bring up during the welcome, please let me know either now or later. I will be following up on the Slack Channel.

Development updates

• Development status
• Development team scrum board

• Buk edit  - Morning Glory Bugfest tickets:

• Bulk Edit Morning Glory Known issues (as of August 9, 2022):
  • UIBULKED-122 - Implement logic for record counts when items bulk edit is triggered by holdings id
  • MODEXPW-203 - "Fail to upload file" error with large amount of Users barcodes
  • MODEXPW-202 -Incorrect number of records changed on the confirmation banner
• Performance tests results:
  • Item records: Bulk Edit Items App report [Morning Glory]
  • User records: Bulk Edit report for Users App [Morning Glory]
  •  Combined tests: Combined test for data export worker (Morning Glory)

• 00:11:09.870 --> 00:11:19.920
• Magda Zacharska: The biggest part of the development updates is obviously morning glory. We discovered several issues. Here is a list of those issues. They are highly technical, and not all of them, but most of them. We discovered if someone runs Bulk Edit in the Bugfest and exports EDIFACT, eHondings, Circulation logs, or bursar.
• 00:12:10.950 --> 00:12:13.500
• Erin Nettifee: So something is happening on the export manager side?
• Magda Zacharska: Yes, those jobs were being filed and then not being processed. We discovered there are problems with the concurrency of those records. That's why we spent a significant amount separating those jobs and queuing them and also testing the behavior. What are the limits of the records we can safely process at the same time? So If we, for example, lower the number of records that are being processed, will this eliminate the problem, and what are the safe limits?
• 00:13:16.650 --> 00:13:25.710
• Magda Zacharska: Right now, the safe limits are 2500 user records at the same time and 10,000 records for items. And as I said, some work is still in progress and will need to be released and tested in Bugfest. We have two other environments that we are using for testing. One of them is the performance task force Prokachka (spelling??) test and our Bulk Edit performance testing. So there is a lot of testing happening on this. Do you have any questions?
• 00:14:02.760 --> 00:14:03.600
• Erin Nettifee: So, the Morning Glory release is at the end of the month. Is the goal still to get everything that we had planned into Morning Glory, or are you thinking that we might need to back it out or ...
• Magda Zacharska: The plan is to get this into the Morning Glory. The determination will probably be made by the end of this week if we limit the number of records that can be updated simultaneously.
• Erin Nettifee: Would it be a limit that the app would enforce? Would it be expected that the users would know not to go over this number?
• 00:14:46.560 --> 00:14:46.920
• Magda Zacharska: Most likely, we will ask the user to know, and this will be included in the release notes. And once I have the data, I will definitely make everyone aware.
• Erin Nettifee: Is there anything you think we could have done to catch this before Bugfest? The answer might be no, but I'm just wondering if we might have changed our approach.
• Magda Zacharska: I think the challenge here is the coordination between three development teams. Efforts need to go into the teams that work on eHoldings, and Export and the teams that work on EDIFACT export. Obviously, you know when you look back, you know what the right thing is. We started experimenting with large data pretty early, and as you see, I linked to the performance tests (see links in the left column). If we do only user records, we can easily do 10,000 records, however, if we increase the number, it affects other areas. So we need to be cognizant.
• Magda Zacharska: Regarding the known issues. The first one is "implement logic for record counts when items bulk edit is triggered by holdings id." This is the label when we count the records, how many records were submitted, how many records were (Magda could not open Bugfest) ...
• 00:17:51.630 --> 00:18:02.790
• Magda Zacharska: When we upload the records--in my example, I submitted a list of 10 records, and it states that 10 records match. And here are the 10 records.

• Magda Zacharska:  If we submit a Bulk Edit by submitting Holdings UUIDs. I can send a list of two holdings ids and have 10 records matching the search criteria. How we report this on screen is why we have this story, UIBULKED-122. I will bring it up at one of our meetings at some point, and we will discuss what is the best approach.
• 00:18:50.160 --> 00:19:04.470
• Magda Zacharska: The second known issue, MODEXPW-203, is the "'fail to upload file' error with a large amount of Users barcodes," this is happening when we attempt to update approximately 100,000 user record identifiers.
• Magda Zacharska: Since we know we will limit the number in Morning Glory, that is going to move to Nolana, and we will be addressing it in Nolana. The last know issue in the list, MODEXPW-202, is "Incorrect number of records changed on the confirmation banner." I am not comfortable marking it as a known issue, but we don't have the resources to address it.

• 00:19:49.290 --> 00:19:49.830
• Magda Zacharska: Once the update is completed. The preview of records changed displays. But we see in the error counts are zero, and also, the records successfully change is zero. This is happening because UI is not waiting for the back-end to respond. If the user clicks the refresh, the correct number is displayed. This is most likely a known issue for Morning Glory. Any comments or questions?
• Magda Zacharska: Due to the slowness of my machine, I'm not going to open the links to the performance reports. If you are interested, please feel free to follow the links. The most important one is the "combined tests: Combined test for data export worker (Morning Glory), which covers exports of other record types. This is what is the closest to the real-life scenario that those will be executed concurrently, so those are still in progress, but the report started to be created. Any other comments or questions before we move on to reviewing the user acceptance testing feedback?
• 00:22:26.970 --> 00:22:30.030
• Erin Nettifee: I don't have any I don't know if anybody else does feel free to chime in.

• 00:22:41.970 --> 00:22:54.300
• Magda Zacharska: Okay, so this is the document with the feedback I linked the results of the survey, thank you for putting it together so quickly, and Erin for providing data.
• Erin Nettifee: And thank you, everybody, for participating because we actually got a really good response rate.
• Magda Zacharska: I put together the results.

• Magda Zacharska: So column a is what is currently implemented. The properties in bold are those with are displayed by default. Version one is the list of properties that in the survey were selected as the ones that should be included on the landing page. And version two is the fields that will be displayed if we limit the number to the bare minimum. I have to say that I am a little bit confused by the lack of consistency between version one and version two, and I'm not sure how to interpret this.
• 00:24:49.140 --> 00:24:51.600
• Erin Nettifee: There's some consistency there. You can see that the barcode is there, towards the top of both. I think people may think about the types of jobs they would do in version one, and then they may think about the bare minimum they need to identify an item in version two. That would be how I would interpret that. Because if you're talking about identifying an item, you're talking about needing a barcode or an HRID. But the types of jobs I might do with an item, like version one, would include things like loan types and locations and stuff, and that's all pretty close to the top. Actually, I don't know, it seems like version one and version two might be pretty close to each other, except for version one bumps effective location way down. I didn't feel like this is what was in the results. Magda, when did you look at the results?
• Magda Zacharska: I look at the spreadsheet. This is page 11 and page 13. The reason I'm bringing it up is that I believe there is not much consistency between version one and version two, in my opinion, although I may be skewed.
• Erin Nettifee: Jenn, version one was question one in the survey, which essentially is if you were to reorder all of these values, what order would you put them in? And the survey did do that randomly. So the list of columns was presented randomly to people. And so it was put this thing in order. And then version two is question two, and the question essentially was, if we only presented a limited number of values, what would you consider to be the things that would need to be presented?
• 00:27:50.010 --> 00:28:01.380
• NOTE: There was a back and forth between Erin and Magda about how the results of the survey were reported on the spreadsheet and its accuracy. Magda tabled this discussion for now.
• 00:32:25.110 --> 00:32:28.590
• Magda Zacharska: I would like to table this conversation for a moment, I will add the data Erin you pointed out and add one more column in the excel spreadsheet. It does not seem clear-cut. I think there are still a lot of Gray areas. The number of columns and the list of columns being displayed depends on the type of job the user is going to do. If the user wants to update item status, obviously, that is something that would like to be displayed on the first page. But it's the same case for permanent loan types and locations. So, for now, I would propose really leaving the columns as they are. And maybe in later releases, we can come back.
• 00:33:43.500 --> 00:33:52.590
• Erin Nettifee: Yes, I will say that all columns currently available compared to the current implementation were actually pretty close. And so, in my mind, that supports not making immediate changes to this.
• Erin Nettifee: But, I think we should go back and look at the results again and make sure that what came out of the survey is interpreted and make sure we're comparing the right things.
• Magda Zacharska: sounds good. I agree with you. However, I think this conversation about the columns leads to the next problem that was also brought up during the user acceptance testing, the column selection and the persistence of those selections.
• Magda Zacharska: So, for example, how persistent should the selection of the columns be? Should they persist by the user, the session, on the preview of records, on the "are you sure" for, on the confirmation screen? Or should the user have an option to change those columns instead?
• 00:35:56.370 --> 00:35:56.760
• Erin Nettifee: Thomas is saying he would prefer the preference be stored by the user, but there's currently no function for user preferences, which is true. Session is supported and is used in a variety of different places.
• 00:36:20.100 --> 00:36:22.080
• Leeda Adkins: So his session, the amount of time you're logged in is session the Bulk Edit job?
• Erin Nettifee: Session on the RA side is usually the length of time with no activity, if that makes sense, so it's sort of like if there's been no activity for five minutes, time out. There's also an end session button in some Apps.
• Magda Zacharska: So we have new Bulk Edit. That would be the equivalent of a session.
• Erin Nettifee: Okay. So, in that sense, then it would be like preserving it for the duration of the particular Bulk Edit job. To me, that makes sense.
• Leeda Adkins: I think somebody who does these sorts of Bulk Edit jobs wants selections to persist from the preview screen to the final result screen. But then, I think it should just go back down to the minimum amount because I may be doing several iterations of jobs for the project rather than keeping it to a set default.
• 00:37:50.850 --> 00:38:06.990
• Erin Nettifee: Would that experience require you to add the same column for each of those bulk edit jobs if you did not have a default column setting?
• Leeda Adkins: Well, that's true.Erin
• Erin Nettifee: I think in an ideal world, you would store this as a user preference, based on the record type, but there's no user preference system and FOLIO yet, and so session, maybe is the place to start.
• Magda Zacharska: But I want to follow up on this. Let's say FOLIO has the ability to store user preferences. Would that mean that every time the user opens a Bulk Edit for item records, their default set of columns will work, or will it depend on the job type?
• Erin Nettifee: So I would assume in that scenario that I have defaults. I may have five columns as my default, and if I went in and I checked a new column, that persists until I go in and uncheck the box. And then, at that point, I get a new set, so if I end up using it, and then going okay actually, I need to tweak this. I need to add these two columns so that I could do that, and I would just change it.
• Magda Zacharska: So, this, is this was my question, so every time you work on users, you will have those three or four columns that you specify in the settings. Is that something that you would prefer instead of having this driven by the session?
• 00:40:48.720 --> 00:40:53.970
• Magda Zacharska: So, for example, today, I work with the location, and I would like to display all permanent locations and temporary locations as a second column. But tomorrow, I am starting to work on loan type at the first two. Is this a real-life example, is it not how it works?
• Erin Nettifee: That's is, as far as I'm concerned, a real-life example.
• Erin Nettifee: You know, for me, it makes more sense if a system has settings that persist than if they just if they revert, and then I have to go in and check the same things over and over and over again because I think as people do this, they will develop a style of their own or information need. It makes more sense to have a persistent thing that I tweak as I go, rather than having to go in and set it up for each job, which is essentially what session and a session-based would mean, but I think a session-based thing is okay to start. I'm not advocating that we build a user preference system as part of this.
• Magda Zacharska: Most likely not going to happen. But we can do the persistent settings for the session. And my understanding of session persistence is that once you make that selection on the preview of matched records, you see the same columns on the "are you sure" form and the confirmation screen.
• Erin Nettifee: Yes, it would make sense to me that it would be the same columns throughout the job.
• Leeda Adkins: That's more important to me than what it shows for each session.
• Erin Nettifee: So what I hear is a session-based approach. The columns persist throughout the job. When you hit new Bulk Edit, it resets the column order, and then you can go in and tweak the column order for the next job and then ideally, FOLIO will work towards a user preference system that could then be used to help these settings persist per user.
• Magda Zacharska: This is my understanding as well.
• 00:43:35.370 --> 00:43:40.380
• Magda Zacharska: The next question that is on my list is paging through matching records results. Our last meeting touched on the preview showing the top 10 records. It was brought up that 10 records are not enough and that you would like to be able to see the matching records and page through them, something similar to how it is done in inventory, where you get the list of 100 records, and then you page through using previous and next buttons. And we also talked about how this would affect performance; it's easier to return the top 10 records than return 10,000 records, for example. The question I have, I have several questions, but question number one is if let's say, you do the Bulk Edit of 10,000 records. Do you really plan to go through all of them paging through them? How this is done on the large data sets? And where do we draw the line; where is the line where you would not attempt to look to the UI?
• Erin Nettifee: Leeda is saying the current preview shows 10 records, but you have the option to download a CSV of the entire preview, is that correct?
• Magda Zacharska: That is correct. This is how it works.
• Leeda Adkins: Especially if we're getting into performance issues here, that sounds okay to me.
• Magda Zacharska: The issue, I think, is really visible when you have 11 or 12 records, and you get back only 10. What is going on with the other two?  This may not have been communicated by me ...
• 00:46:31.920 --> 00:46:34.680
• Erin Nettifee: The chat says people are fine, with a preview of 10 and then a download for more investigation.
• Erin Nettifee: You could increase it to 20 if you feel like that would be helpful. It may be just an artifact of the Bulk Edit use cases we were using where there were really small sets of data.
• 00:46:57.120 --> 00:47:04.620
• Bob Scheier (Holy Cross): I agree that it's fine to just have the download option when you want to see more, but I think the messaging on the screen could be more clear in terms of saying you're viewing is a preview of 10.
• Erin Nettifee: Right, or even if you didn't change the verbiage, you could pop a little question mark that you could hover over to provide a help message. That might be nice too.
• Sara Colglazier: I think it has to be clear that you are seeing just a few, and also, it does make a difference if it's a random 10 or the first 10.
• Magda Zacharska: So my understanding is it is the top 10. So if your list has 11 identifiers, the first 10 will be displayed. However, I need to double check if the order is not changing, because this depends on how the database returns them.
• Sara Colglazier: Going back to the actual numbers. If I have 10,000, obviously, I'm not going to scroll through 10,000. But I do find that 10 is very, very few. I'm used to seeing potentially all of them in Aleph. I could still see my complete preview and scroll through if I wanted to.
• Magda Zacharska: Leeda adds that in Aleph, there is the "do not update the database" option.
• Magda Zacharska: So you have two options of not committing first the preview...
• Sara Colglazier: I just want to finish. I just tend to think 10 to be very few. I think it would be nice if performance-wise, we could go up to 100.  Beyond that, I'm fine with downloading a file.
• Erin Nettifee: Maybe Magda, one of the ways to think about it would be to fill the white space that appears here. Is there a way to say fill the screen?
• 00:51:41.460 --> 00:51:42.660
• Magda Zacharska: So you see the white space here because there are no errors, but then you will have the additional accordion with errors. And this was actually my second question. Should we also show a preview of the top 10 errors? But you have the option of saving the errors as well. Do you want to see all errors, or do you want to see the preview?
• Erin Nettifee: Could we present a download link outside of the action menu? I don't know if there's a UI pattern for that. I get back to what I think Bob was saying earlier. Just saying preview of records matched first 10 or something like that. You know, is there a way that we could just make that download more obvious?
• Magda Zacharska: I think we can come back to this additional link maybe later. I don't want to commit to this. I agree, maybe we can change the verbiage on this to make it clear that this is the top can preview. Or if we increase the number to 100 to make it a little bit more user friendly, that would obviously require scrolling down, and if you have 100 records here and then the errors below that, you would need to scroll down a lot to the bottom of your preview to see if there were errors or not.
• Bob Scheier (Holy Cross): I have a couple of questions. In other software you sometimes see the option to choose how results you want to see. And then the other is if there's a lot like 100, can we have a tabbed interface in that window that you could tap to see the errors?
• Magda Zacharska: We will come back to these ideas for sure. I think that the simple way right now would be to make the description a little bit more clear to state that this is just a preview and state how many records are included. The next step would be to include 100 results and maybe add the paging mechanism to go to the record. But eventually we will need to draw the line of how many records we are previewing.

484
00:55:52.290 --> 00:55:52.770
Magda Zacharska: and

485
00:55:53.880 --> 00:56:12.060
Magda Zacharska: Let me take a look at the notes, because we are slowly running out of the time and paging through how many records should be displayed by default we touched this pledging to our list, do we need the earliest or downloading their errors is enough.

486
00:56:20.280 --> 00:56:20.640
part.

487
00:56:22.890 --> 00:56:39.090
Magda Zacharska: Right now, when there are errors, we also show top 10 and then to see all there's you need to download that do you do you think it's enough or do you would like to be able to see more as well.

488
00:56:40.320 --> 00:56:43.470
Sara Colglazier : I think they're seeing fewer errors is.

489
00:56:44.130 --> 00:56:45.330
Magda Zacharska: No clinical notes.

490
00:56:50.370 --> 00:56:52.500
Sara Colglazier : Then i'm more likely to download and not.

491
00:56:56.370 --> 00:57:09.060
Sara Colglazier : Because you know there's an air so, on the other, it's more like you're skimming to see there's something that I didn't think about that is actually cause a problem that is not an air.

492
00:57:10.470 --> 00:57:22.830
Sara Colglazier : But some piece of data that I didn't account for in what I was going to do, and so, if I hit submit to the to the ones, am I going to affect something that I didn't actually want to effect.

493
00:57:23.790 --> 00:57:38.670
Sara Colglazier : that's I mean that's very often why I skim through the you know, do not update database option that's why I use that all the time in our previous system, I would run it and then I would just kind of skim through and go oh.

494
00:57:39.750 --> 00:57:42.570
Sara Colglazier : Man oh there's something I didn't think of that.

495
00:57:43.110 --> 00:57:51.270
Sara Colglazier : And it was really helpful, but on the air you're telling me oh there's an error, the machine knows there's an error so.

496
00:57:52.680 --> 00:57:54.900
Sara Colglazier : I want to download that to look at anyways.

497
00:57:56.610 --> 00:57:57.750
Sara Colglazier : I hope that.

498
00:57:58.620 --> 00:57:59.700
Sara Colglazier : As i'm fine with 10.

499
00:58:00.930 --> 00:58:01.650
Sara Colglazier : It helps.

500
00:58:02.490 --> 00:58:07.710
Magda Zacharska: him, but the other question I have because.

501
00:58:08.850 --> 00:58:16.920
Magda Zacharska: We didn't catch the are you sure form it's also showing the top.

502
00:58:18.030 --> 00:58:27.960
Magda Zacharska: records, but we talk about the preserving the column selection, that if we select on the landing page the columns.

503
00:58:29.040 --> 00:58:30.540
Magda Zacharska: The columns will be.

504
00:58:31.740 --> 00:58:36.270
Magda Zacharska: preserved for are you sure, and for the confirmation screen.

505
00:58:37.560 --> 00:58:40.530
Magda Zacharska: paging to the results of the on the.

506
00:58:41.700 --> 00:58:42.420
Magda Zacharska: On the.

507
00:58:43.650 --> 00:58:53.130
Magda Zacharska: Short form, and I think Sarah, this is the closest to what you are saying, do not commit to the database because, are you sure forum shows you.

508
00:58:53.550 --> 00:59:10.380
Magda Zacharska: This is how the data will look in the database once you make the change, but the changes until you click the button commit changes are not committed, so you can still from this form click cancel and go back.

509
00:59:12.210 --> 00:59:23.070
Magda Zacharska: So should we discuss just the paging to the results on the preview page under are you sure page.

510
00:59:24.510 --> 00:59:33.000
Magda Zacharska: We are out of the time we will be shortly out of the time and Internet minutes so maybe we should come back to this.

511
00:59:38.550 --> 00:59:40.020
Magda Zacharska: Discussion of the.

512
00:59:41.370 --> 00:59:43.050
Magda Zacharska: Of the behavior of are you sure.

513
00:59:44.760 --> 00:59:57.360
Magda Zacharska: form, I just want to mention that something that was brought up during the a user acceptance testing could save and close button was not clear enough that users were not.

514
00:59:58.380 --> 01:00:09.330
Magda Zacharska: sure that they are conducting the changes we make the change so right now, when you when you are on there are you sure form so, for example, before I do here.

515
01:00:11.250 --> 01:00:17.490
Magda Zacharska: Look at it and I change the status to missing, for example.

516
01:00:23.220 --> 01:00:25.110
Magda Zacharska: And this is the Community changes.

517
01:00:26.130 --> 01:00:47.640
Magda Zacharska: Here you can download the files, this is where you see all the records that will be affected the data is not safe in the database just yet you just see this is how it will look once you click commit changes and committing changes.

518
01:00:52.590 --> 01:00:56.970
Magda Zacharska: And here's the data that is already committed and changed.

519
01:01:06.390 --> 01:01:08.490
Magda Zacharska: So should we talk more about the.

520
01:01:11.160 --> 01:01:14.100
Magda Zacharska: about the are you sure form or are you.

521
01:01:15.900 --> 01:01:18.420
Bob Scheier (Holy Cross): i'm wondering why why it's different than the.

522
01:01:20.010 --> 01:01:23.220
Bob Scheier (Holy Cross): preview in terms of the way it displays.

523
01:01:24.360 --> 01:01:28.230
Bob Scheier (Holy Cross): As a separate window versus on the screen.

524
01:01:31.380 --> 01:01:37.410
Magda Zacharska: Because this dish you also an easy way to go back so if you are on the.

525
01:01:40.770 --> 01:01:53.040
Magda Zacharska: We need to start from your bucket is right now, but if you are here, there is no way of going back to the changes right, it is a do you see the problem with the pop up.

526
01:01:53.460 --> 01:01:58.890
Bob Scheier (Holy Cross): window I don't know if maybe if anybody if nobody else was wondering about I just wondered why.

527
01:01:59.940 --> 01:02:14.130
Bob Scheier (Holy Cross): When you're looking at a preview you're looking at it on the screen and then, when you get to the point of seeing the changes that you before you commit you get a pop up window and wondering why it can't when when did normally just be the same.

528
01:02:14.820 --> 01:02:20.520
Magda Zacharska: At least, you have the link directly you don't need to go to the action menu, you can link.

529
01:02:20.610 --> 01:02:20.850
Bob Scheier (Holy Cross): That.

530
01:02:21.090 --> 01:02:21.900
to download it.

531
01:02:23.520 --> 01:02:25.860
Bob Scheier (Holy Cross): Maybe so maybe it should both be like that I don't know.

532
01:02:26.280 --> 01:02:30.030
Magda Zacharska: um and I, you know I don't want to reinvent the ui.

533
01:02:30.540 --> 01:02:32.700
Magda Zacharska: Okay what's some reasons.

534
01:02:32.730 --> 01:02:34.620
Magda Zacharska: That we did it this way.

535
01:02:34.650 --> 01:02:38.820
Magda Zacharska: Okay, I just want to be as easier.

536
01:02:40.170 --> 01:02:43.200
Magda Zacharska: for you to use so if something is prohibitive.

537
01:02:44.220 --> 01:02:50.400
Magda Zacharska: For you being efficient, then we definitely need to be addressing it we are.

538
01:02:51.150 --> 01:02:52.440
Magda Zacharska: One minute after.

539
01:02:52.680 --> 01:03:03.750
Magda Zacharska: Our time would probably talk about the label, so we change the labels and also, if you have any suggestions to the.

540
01:03:04.980 --> 01:03:17.880
Magda Zacharska: Welcome meeting, please feel free to reach out and bring to my attention, thank you all for your feedback and time and then i'll talk to you in two weeks bye bye.

541
01:03:18.390 --> 01:03:19.500
Leeda Adkins: Thank you bye.

542
01:03:20.040 --> 01:03:20.400
Magda Zacharska: bye bye.