WEBVTT 1 00:00:26.300 --> 00:00:26.780 Alissa Hafele: So… 2 00:00:29.080 --> 00:00:30.120 Owen Stephens: Hello! 3 00:01:06.970 --> 00:01:07.960 Alissa Hafele: Hello! 4 00:01:10.360 --> 00:01:11.500 Kristin Martin: Great. 5 00:01:16.920 --> 00:01:20.300 Alissa Hafele: Tara, apologies, I have to leave halfway through, so I'll just jump on. 6 00:01:20.300 --> 00:01:23.549 Tara Barnett (Index Data): Yeah No problem. Thanks for joining. 7 00:01:24.150 --> 00:01:24.780 Tara Barnett (Index Data): at all. 8 00:01:26.720 --> 00:01:38.739 Tara Barnett (Index Data): I was trying to read, Zach's note on the channel about how what we're asking for is not possible. I'm trying to decide if that impacts what we do today. 9 00:01:39.770 --> 00:01:43.660 Tara Barnett (Index Data): I don't think so, because, like, was it possible, was not. 10 00:01:43.940 --> 00:01:48.139 Laura Daniels: I think we should still outline What we would like. 11 00:01:48.890 --> 00:01:49.470 Tara Barnett (Index Data): Okay. 12 00:01:49.870 --> 00:01:57.159 Laura Daniels: And then we can determine How much of what we want is feasible, maybe? 13 00:02:02.020 --> 00:02:03.140 Laura Daniels: Because we still… 14 00:02:03.140 --> 00:02:03.540 Tara Barnett (Index Data): Curious. 15 00:02:04.950 --> 00:02:12.320 Laura Daniels: Even if a lot of what we want is not feasible, we still have the challenge that we were trying to address. 16 00:02:13.810 --> 00:02:20.630 Laura Daniels: with inconsistency. And so, at the very least, we want to address that in a meaningful way. 17 00:02:23.540 --> 00:02:24.820 Tara Barnett (Index Data): I think that makes sense. 18 00:02:24.820 --> 00:02:29.580 Owen Stephens: I wasn't entirely sure that… Wha… the… 19 00:02:30.350 --> 00:02:37.480 Owen Stephens: What we were asking for was what he was describing, but… maybe I've… 20 00:02:38.260 --> 00:02:42.449 Owen Stephens: I'm not getting… either I'm not understanding what he's posted, or I'm… 21 00:02:42.670 --> 00:02:46.289 Owen Stephens: Getting confused about what it was we wanted. 22 00:02:46.810 --> 00:02:53.730 Tara Barnett (Index Data): Yeah, okay, so maybe if we all look at this together, we'll, we'll be able to figure this out. 23 00:02:53.730 --> 00:02:56.719 Laura Daniels: Is the whoopie behaving for other people? 24 00:02:57.760 --> 00:03:02.539 Laura Daniels: I'm unable to… Get to our meetings page. 25 00:03:04.350 --> 00:03:08.680 Laura Daniels: And maybe it's just… Eyebrows, okay. 26 00:03:08.680 --> 00:03:09.939 Kristin Martin: It's been fine. 27 00:03:10.420 --> 00:03:10.940 Laura Daniels: Okay. 28 00:03:10.940 --> 00:03:11.620 Tara Barnett (Index Data): Yeah. 29 00:03:16.430 --> 00:03:17.699 Tara Barnett (Index Data): Hopefully it's okay. 30 00:03:22.630 --> 00:03:23.390 Tara Barnett (Index Data): Okay. 31 00:03:23.540 --> 00:03:24.980 Tara Barnett (Index Data): Sorry, give me one more second. 32 00:03:24.980 --> 00:03:26.000 Laura Daniels: likes that. 33 00:03:33.110 --> 00:03:33.890 Tara Barnett (Index Data): Alright. 34 00:03:34.570 --> 00:03:43.380 Tara Barnett (Index Data): Sorry for all the frantic background clicking as I try and close things. Okay, so… 35 00:03:44.100 --> 00:03:55.400 Tara Barnett (Index Data): Today, we're continuing our discussion that we started on Wednesday, about bringing acquisitions behavior in line with folio defaults. For those who are joining us a little bit, later, we had some 36 00:03:55.620 --> 00:04:09.950 Tara Barnett (Index Data): late-breaking news this morning about whether or not that's possible, so I think we're going to try and take a look at that together and try to understand what Zach said. Joe let us know that he wasn't able to join this meeting, but our goal for today was to 37 00:04:10.310 --> 00:04:15.570 Tara Barnett (Index Data): Create a short slide deck covering the behavior in question, 38 00:04:15.990 --> 00:04:28.559 Tara Barnett (Index Data): create prompts and talking points for the SIGs, and then make sure that we know who's reaching out to which SIG. And I don't know if the fact that what we're asking for might not be possible changes the fact that it's desirable, either way, so, 39 00:04:28.740 --> 00:04:36.899 Tara Barnett (Index Data): I think that's still valid to do. But before we get into that, upcoming sessions, so… 40 00:04:37.580 --> 00:04:50.469 Tara Barnett (Index Data): Our next session would be on, April 1st, April Fool's. So that is canceled due to calendar calming. We do not yet have a session planned for April 6th. If you have something in mind, let me know. 41 00:04:51.260 --> 00:04:57.969 Tara Barnett (Index Data): The next thing on here is very exciting news. We have… 42 00:04:58.680 --> 00:05:11.959 Tara Barnett (Index Data): found co-convengers for this thing, so it will not die with my, with my departure, which is great. So Alyssa and Laura have volunteered to step up. We will coordinate that, later in April. Yay! 43 00:05:12.380 --> 00:05:16.519 Tara Barnett (Index Data): So, thank you so much for that, I really appreciate it, and I'm sure everyone here does as well. 44 00:05:17.580 --> 00:05:31.689 Tara Barnett (Index Data): The last thing that I put on announcements and housekeeping is the WolfCon presentation. Laura went ahead and submitted that, so we have a working session that has been submitted. I don't think we talked about doing any other sessions, so I think we're good as far as WolfCon is concerned. 45 00:05:32.420 --> 00:05:48.899 Laura Daniels: I had a quick, just temperature check about something else that I might propose. Since Tom and I are ostensibly working on moving forward with item state, I was thinking of doing, like, a 25-minute 46 00:05:49.300 --> 00:05:51.390 Laura Daniels: Item state… 47 00:05:52.550 --> 00:06:05.959 Laura Daniels: where… where we are now, this would force me and Tom to go gather input from the community before that, and use… use the, the Wolf concession as, sort of… 48 00:06:06.180 --> 00:06:14.989 Laura Daniels: Making sure everybody knows What… what the current functionality is, what the challenges are, and sort of determining 49 00:06:15.140 --> 00:06:24.480 Laura Daniels: what direction we want to go. Does that sound like something that people would be interested in going to at WolfCon, or does that sound like something that we should just do? 50 00:06:24.830 --> 00:06:26.070 Laura Daniels: Virtually. 51 00:06:26.650 --> 00:06:28.479 Laura Daniels: And maybe just, you know. 52 00:06:28.640 --> 00:06:42.049 Laura Daniels: Slack… Slack… Slack, yes, sorry, we used… we've moved to Teams. Slack me, or reach out to me, and so my… if you think that's a good idea, you would go, or if you think that's a terrible idea, no, don't waste my time at a conference with Item State. 53 00:06:45.920 --> 00:06:54.719 Tara Barnett (Index Data): I'm gonna predict you get zero of the second option. Like, people directly messaging you to say, that's a waste of time. I'm gonna go ahead and assume, oh my god, Zach's here, we're safe. 54 00:06:54.960 --> 00:06:55.760 Tara Barnett (Index Data): Okay. 55 00:06:56.770 --> 00:06:59.269 Zak Burke (EBSCO): That's a terrifying thing to enter a meeting to. 56 00:06:59.490 --> 00:07:05.090 Tara Barnett (Index Data): We were trying to figure out if we understood what you were saying and what we had asked for, and then I was like, oh my gosh, you're here, perfect. 57 00:07:05.410 --> 00:07:12.539 Tara Barnett (Index Data): But Laura, I'm sure you're not gonna get any, detractors from your WolfCon session, for sure. So… 58 00:07:13.170 --> 00:07:17.150 Tara Barnett (Index Data): Okay, any other announcements, housekeeping, before we keep going? 59 00:07:20.360 --> 00:07:31.779 Tara Barnett (Index Data): Okay, great. So the main thing that we were hoping to talk about today is, the discussion we started last week. Last week when we were, talking, hopefully I actually put notes on here. 60 00:07:31.950 --> 00:07:38.069 Tara Barnett (Index Data): What we agreed on for personalized defaults was that 61 00:07:38.470 --> 00:07:47.720 Tara Barnett (Index Data): URLs that you paste into the URL bar should always be obeyed, no matter what your personal defaults are. Hard refresh should always reset the filters, you shouldn't have to log out and in again. 62 00:07:48.990 --> 00:08:00.029 Tara Barnett (Index Data): some degree of persistence within a session may be desirable across apps, and that's part of why we need to reach out to the different SIGs, so that we understand when it's helpful and when it's not helpful within a session. 63 00:08:00.080 --> 00:08:09.200 Tara Barnett (Index Data): Any defaults that we ask for, that are retained between sessions should be set user by user, rather than by the entire tenant. 64 00:08:09.370 --> 00:08:17.789 Tara Barnett (Index Data): And then, defaults should be set within the app rather than in settings. So we talked about a few different ways that that could look, but ultimately, it was… 65 00:08:18.130 --> 00:08:23.859 Tara Barnett (Index Data): It sounded like people agreed that having a whole mirror interface in settings was not a good idea. 66 00:08:23.990 --> 00:08:28.199 Tara Barnett (Index Data): Is there anything else relevant that we decided that I missed? 67 00:08:32.440 --> 00:08:37.609 Tara Barnett (Index Data): So, as part of that, we realized that we needed to understand the behavior, 68 00:08:37.980 --> 00:08:54.980 Tara Barnett (Index Data): from the perspective of all of the SIGs, because we're talking about changing things across folio. So, one of the things we need to do is plan out who's taking these issues to each SIGS, and each of the SIGs, and what they are going to say, and how they are going to explain this problem, which was hard in the first place for us to understand. 69 00:08:55.330 --> 00:08:59.779 Tara Barnett (Index Data): So we can work on that here. 70 00:09:00.110 --> 00:09:07.100 Tara Barnett (Index Data): But the first question is, are we asking for something impossible in the first place? And that, I think, is… 71 00:09:08.760 --> 00:09:15.139 Tara Barnett (Index Data): Well, I am so glad that Zach is here, because I wasn't sure I understood what you posted on Slack. 72 00:09:17.860 --> 00:09:21.559 Zak Burke (EBSCO): Sure. So, do you want to talk through that example a little bit? 73 00:09:21.780 --> 00:09:27.290 Zak Burke (EBSCO): And maybe it'll explain… Why things get dicey in terms of how… 74 00:09:27.680 --> 00:09:33.889 Zak Burke (EBSCO): data in a URL is mixing with data that's in storage and causing those confusing results. 75 00:09:36.090 --> 00:09:45.379 Zak Burke (EBSCO): So the example that I gave is sort of messy, right, in terms of stepping through a bunch of tabs, but what essentially happens is you do a search in tab A, and… 76 00:09:46.110 --> 00:09:53.319 Zak Burke (EBSCO): that… the filters that you add values to get copied into your… the URL, and they get 77 00:09:53.440 --> 00:09:54.900 Zak Burke (EBSCO): Copied into storage. 78 00:09:55.320 --> 00:09:58.269 Zak Burke (EBSCO): And then you open tab B, and you do another search. 79 00:09:58.630 --> 00:10:04.120 Zak Burke (EBSCO): And those get copied into the URL for B, and then they overwrite what's in storage for tab A. 80 00:10:04.690 --> 00:10:07.439 Zak Burke (EBSCO): You go back to tab A, you do another search. 81 00:10:07.590 --> 00:10:11.649 Zak Burke (EBSCO): It's gonna update URL, it's gonna update what's in storage. 82 00:10:12.080 --> 00:10:16.839 Zak Burke (EBSCO): And now, if you look at tab B, and you copy that URL, 83 00:10:17.360 --> 00:10:20.659 Zak Burke (EBSCO): The URL is now out of sync with what's in storage. 84 00:10:21.060 --> 00:10:32.470 Zak Burke (EBSCO): Right? Because you've been going back and forth between A and B. So now if you copy B, which is out of sync, and open C, you don't actually get what's in tab B. You get a merge of… 85 00:10:32.660 --> 00:10:36.839 Zak Burke (EBSCO): the URL values from B, and the local storage. 86 00:10:37.040 --> 00:10:49.779 Zak Burke (EBSCO): which is the same as the URL storage in A. And so when those two things merge, you know, now there's just a much smaller set, because instead of it being this, it's this, and so you only get the intersection. And so that's what causes the glitch there. 87 00:10:50.020 --> 00:10:53.260 Zak Burke (EBSCO): So it's… 88 00:10:53.900 --> 00:11:09.090 Zak Burke (EBSCO): There's not a right answer in terms of how any of this persistence should work, it's just that there's various trade-offs in terms of what do we put into the URL, what do we put into session storage, which would get blown away and, 89 00:11:11.360 --> 00:11:24.559 Zak Burke (EBSCO): initialized every time you start a new session, what gets put into local storage, which persists across sessions, and so I think it's just making sure that as we think about the different use cases, we think about 90 00:11:24.860 --> 00:11:30.189 Zak Burke (EBSCO): How storing those values in different places 91 00:11:30.480 --> 00:11:40.109 Zak Burke (EBSCO): is going to affect logging in and logging out, is going to affect multiple tabs, and we can decide, you know, what trade-offs are okay. Maybe it's okay that 92 00:11:40.460 --> 00:11:59.849 Zak Burke (EBSCO): writing stuff to local storage causes, you know, URLs to not be completely consistent, because it's really important to us that people can store their preferred search values and have them persist across logins. A side effect is that, you know, URLs might be inconsistent, but maybe we decide that side effect is worth it. 93 00:12:00.060 --> 00:12:11.019 Zak Burke (EBSCO): Or we go the other way and say, you know, a URL has to always return exactly the same results, no matter who's logged in, and so bookmarkable URLs is the most important things, and if that means that 94 00:12:11.380 --> 00:12:19.310 Zak Burke (EBSCO): logging in, and then logging out, and logging in on a new machine means you lost your preferences. Well, that's an okay trade-off. It doesn't really matter which one of those we pick. 95 00:12:19.520 --> 00:12:21.399 Zak Burke (EBSCO): We just have to understand… 96 00:12:21.760 --> 00:12:27.890 Zak Burke (EBSCO): how storing things in the URL, how storing things in session storage or local storage. 97 00:12:28.000 --> 00:12:35.000 Zak Burke (EBSCO): affects those things. So, that's what I was trying to illustrate, I guess, with that example, is that 98 00:12:35.460 --> 00:12:41.719 Zak Burke (EBSCO): data in the URL and data in local storage can get out of sync. 99 00:12:41.880 --> 00:12:44.239 Zak Burke (EBSCO): And… that can be tricky. 100 00:12:45.450 --> 00:12:50.689 Zak Burke (EBSCO): maybe it would… if it would be helpful, I'm happy to talk about how different kinds of storage work. 101 00:12:51.170 --> 00:12:57.479 Zak Burke (EBSCO): and interact, because again, you know, different tabs… I think it makes sense to folks that different tabs have different URLs. 102 00:12:58.000 --> 00:13:12.009 Zak Burke (EBSCO): local storage, though, is shared across multiple tabs, and so that's… that's sort of the reason that we get into this problem, is that all these tabs have different URLs, but they're all sharing the same local storage bucket on the back end. 103 00:13:12.330 --> 00:13:17.410 Zak Burke (EBSCO): And so that's where that discrepancy comes in. 104 00:13:18.500 --> 00:13:30.690 Zak Burke (EBSCO): So, I'm happy to, like, talk through storage, or just to listen to questions that have… folks have, or just to lurk in the background and pipe up when you, you know, start asking for something impossible. 105 00:13:30.840 --> 00:13:32.420 Zak Burke (EBSCO): Whatever would be most helpful. 106 00:13:33.990 --> 00:13:36.309 Tara Barnett (Index Data): Sorry, I see Owens again. Let's start with that. 107 00:13:37.730 --> 00:13:39.250 Owen Stephens: Thanks, Zach. And… 108 00:13:39.460 --> 00:13:50.200 Owen Stephens: Can you just outline what… what's the… why… what is it that we get from the local storage? What… at the moment, why do we use local storage? 109 00:13:51.280 --> 00:13:52.089 Owen Stephens: do for us? 110 00:13:52.090 --> 00:13:55.600 Zak Burke (EBSCO): Yeah, so my… the… I think the big feature that local storage 111 00:13:55.970 --> 00:14:03.419 Zak Burke (EBSCO): ads here is the ability for a filter to persist across sessions. So, if you sign in. 112 00:14:03.530 --> 00:14:07.689 Zak Burke (EBSCO): And you do a search, and add some filters. 113 00:14:08.120 --> 00:14:09.700 Zak Burke (EBSCO): And then you sign out. 114 00:14:09.830 --> 00:14:11.439 Zak Burke (EBSCO): And then you sign back in. 115 00:14:11.880 --> 00:14:14.489 Zak Burke (EBSCO): In the same browser, on the same machine. 116 00:14:15.850 --> 00:14:19.719 Zak Burke (EBSCO): The search from your first session will persist. 117 00:14:19.930 --> 00:14:21.290 Zak Burke (EBSCO): To your second session. 118 00:14:21.440 --> 00:14:25.450 Zak Burke (EBSCO): Right? So the local storage persists across logouts. 119 00:14:26.480 --> 00:14:27.490 Zak Burke (EBSCO): It's permanent. 120 00:14:28.180 --> 00:14:38.680 Zak Burke (EBSCO): The thing to know about local storage is that it's permanent in your browser, right? So, if you were to log in on your desktop and do a search and log out. 121 00:14:39.160 --> 00:14:41.540 Zak Burke (EBSCO): And then log in on your laptop. 122 00:14:42.380 --> 00:14:44.800 Zak Burke (EBSCO): Those two sessions are not really connected. 123 00:14:44.910 --> 00:14:47.290 Zak Burke (EBSCO): Because local storage is on your browser. 124 00:14:47.830 --> 00:14:49.120 Zak Burke (EBSCO): So… 125 00:14:49.120 --> 00:14:56.110 Owen Stephens: And is it persistent, like, across browser sessions, or does the browser clear that if you close the browser down? 126 00:14:56.390 --> 00:14:58.870 Zak Burke (EBSCO): It does not clear it if you close the browser down. 127 00:14:58.870 --> 00:14:59.670 Owen Stephens: It's persistent. 128 00:14:59.670 --> 00:15:01.279 Zak Burke (EBSCO): It's completely persistent. 129 00:15:01.980 --> 00:15:02.790 Owen Stephens: Yeah, okay. 130 00:15:02.790 --> 00:15:04.719 Zak Burke (EBSCO): It's there until it's cleared. 131 00:15:05.480 --> 00:15:10.400 Owen Stephens: And this might not be a question for you, Zach, I don't know, but, like, Do we know, like. 132 00:15:12.150 --> 00:15:15.020 Owen Stephens: Is that used, like, universally across 133 00:15:16.540 --> 00:15:19.220 Owen Stephens: apps in folio, or is it widely, like, that… that. 134 00:15:19.220 --> 00:15:38.660 Zak Burke (EBSCO): No, so it's not at all, and that's why I originally thought that its implementation was a bug. I believe there was a very early requirement, like, think 2017, 18, 19, to have some sessions… to have some of these searches be sticky across sessions. I don't 135 00:15:39.270 --> 00:15:40.610 Zak Burke (EBSCO): We had. 136 00:15:40.610 --> 00:15:41.189 Owen Stephens: I have to dig around. 137 00:15:41.190 --> 00:15:43.360 Zak Burke (EBSCO): Jira to try to find it. 138 00:15:43.360 --> 00:15:47.870 Owen Stephens: I think that's where we started this, right? Because… Orders… 139 00:15:48.190 --> 00:15:50.340 Owen Stephens: does do that, right? Yes, exactly. 140 00:15:50.340 --> 00:15:50.670 Zak Burke (EBSCO): Exactly. 141 00:15:51.200 --> 00:15:58.269 Owen Stephens: Okay, so that… and that's… I think that's where this discussion started last week, Joe Reimer's. 142 00:15:58.590 --> 00:16:02.180 Owen Stephens: Came… Rhyme, sorry, came along and, 143 00:16:02.580 --> 00:16:08.340 Owen Stephens: talked about that, and so this… yeah, I think we… What we were… 144 00:16:08.740 --> 00:16:12.479 Owen Stephens: Looking for is a way forward that has 145 00:16:12.650 --> 00:16:19.020 Owen Stephens: consistent behavior, or the option of consistent behavior across apps. Right. 146 00:16:19.420 --> 00:16:30.880 Owen Stephens: and… Definitely, I think that… That idea of… of having persistence, like, that we talked about 147 00:16:31.990 --> 00:16:33.839 Owen Stephens: The possibility of having… 148 00:16:34.310 --> 00:16:44.590 Owen Stephens: the… the user choose whether some… whether that behavior was on or off, but I… I get that, obviously, as soon as you say, well, that can be on or off, then you get the problem with 149 00:16:44.770 --> 00:16:45.389 Owen Stephens: the. 150 00:16:45.390 --> 00:16:46.170 Zak Burke (EBSCO): Yeah. 151 00:16:46.360 --> 00:16:53.630 Owen Stephens: the URLs. Would it be… this may be digging a bit too deep right now, I don't know, but… 152 00:16:54.040 --> 00:16:59.250 Owen Stephens: The other thing that occurs to me is, like, if we want shareable URLs. 153 00:17:00.610 --> 00:17:04.410 Owen Stephens: I mean, would it be possible to have URLs that shared 154 00:17:05.349 --> 00:17:20.889 Owen Stephens: with a parameter that said, don't apply, like, could you… could you actually, you know, decide, okay, you can't just rely on a URL being copy and pasted, but you can have a shareable URL function that would always produce a persistent URL of some kind. 155 00:17:20.890 --> 00:17:38.890 Zak Burke (EBSCO): Yeah, so the last example that I gave, sort of gets at why we have this problem where… like, the current problem with URLs leading to inconsistent results is because URLs are unique per tab, but local storage is shared. 156 00:17:39.220 --> 00:17:55.539 Zak Burke (EBSCO): across tabs. And so what happens is, when the application loads, it says, alright, let me look at all the values that I have in my URL. Okay, in my URL, I have, you know, a value for color and shape, and in local storage, I have a value for color and size. 157 00:17:55.540 --> 00:18:04.669 Zak Burke (EBSCO): Let me take the color and shape from the URL, because the URL is definitive, and I'm gonna throw away the color value that I have in storage, but I'll add the one for size. 158 00:18:04.670 --> 00:18:12.789 Zak Burke (EBSCO): And so, it, like, it sort of merges them together. The things in the URL win, but then the things that are in local storage also filter up. 159 00:18:12.790 --> 00:18:25.959 Zak Burke (EBSCO): And then now you have an intersection that doesn't have any results. And so that's how we get to that sort of buggy behavior. And so there's a couple ways that you could work around that. One is having URLs that 160 00:18:26.390 --> 00:18:27.870 Zak Burke (EBSCO): include… 161 00:18:28.230 --> 00:18:43.519 Zak Burke (EBSCO): empty values, right? Like, right now, if you look at orders, there's, like, there's a huge number of facets, right? There's, like, 30 or something like that. But if you do a search, or you do a… you apply a filter, you get a URL that only has a key for the filters that you're applying. 162 00:18:43.720 --> 00:18:57.059 Zak Burke (EBSCO): Right? Like, it'll show you just the receipt status, or… but so if you look at that URL, there's nothing about payment status, there's nothing about prefix, there's nothing about suffix, there's nothing about vendor, right? It doesn't include the empty values. 163 00:18:57.620 --> 00:19:01.949 Zak Burke (EBSCO): And so that's what allows… a different tab. 164 00:19:02.140 --> 00:19:10.599 Zak Burke (EBSCO): that does have a value for prefix, suffix, vendor, when that gets lodged in storage, and then you mix a URL 165 00:19:10.840 --> 00:19:14.039 Zak Burke (EBSCO): From a different tab, that's what causes that sort of… 166 00:19:14.670 --> 00:19:22.210 Zak Burke (EBSCO): pollution of the results. And so, one option would be for URLs to always include 167 00:19:23.310 --> 00:19:27.940 Zak Burke (EBSCO): empty values, but that could lead to really long URLs. 168 00:19:28.050 --> 00:19:30.230 Zak Burke (EBSCO): But it would solve the problem. 169 00:19:30.360 --> 00:19:38.830 Zak Burke (EBSCO): Another is something like you were saying, which is add a special value to the URL, which is something like… 170 00:19:39.460 --> 00:19:49.269 Zak Burke (EBSCO): only use the filter values from my URL, please ignore local storage equals true. Something… some kind of flag that basically says. 171 00:19:49.610 --> 00:20:08.170 Zak Burke (EBSCO): hey, don't… don't load filters from anywhere else, only load the filters from this URL, but then how do you get that flag into the URL? Like, because, you know, if you're just going to send this to a colleague, you're going to copy it out of your bar and paste it and send it to your colleague in an email or, you know, in a Slack chat or something like that, so how do you get that value into the URL? 172 00:20:08.460 --> 00:20:12.449 Zak Burke (EBSCO): It would work, but it would be kind of messy, potentially, so… 173 00:20:13.310 --> 00:20:19.880 Zak Burke (EBSCO): my… my inclination would be figure out how to include empty filters in the URL. 174 00:20:20.170 --> 00:20:27.480 Zak Burke (EBSCO): But with something like orders, where there are so many facets, I don't know how… Plausible, that is. 175 00:20:29.140 --> 00:20:37.979 Zak Burke (EBSCO): Once you hit probably about 30 values, we start potentially running out of value, or running out of space in the URL, because it can only be, I think, 4,000 characters. 176 00:20:42.940 --> 00:20:43.720 Tara Barnett (Index Data): Okay. 177 00:20:45.590 --> 00:20:47.680 Owen Stephens: Yeah, I'll… I think this is my last… 178 00:20:47.840 --> 00:20:53.030 Owen Stephens: comment. Thanks, Zach, again, and then I'll stop, which is… One is… is just… 179 00:20:53.290 --> 00:21:00.889 Owen Stephens: Like, in terms of our discussion right now, And… and… taking it to the SIGs. 180 00:21:01.190 --> 00:21:09.030 Owen Stephens: I think that understanding the desired behaviors from the SIGs is a good starting point still. Like. 181 00:21:10.500 --> 00:21:15.479 Owen Stephens: it seems to me that Zach is outlining, like, If we were to currently… 182 00:21:17.750 --> 00:21:21.859 Owen Stephens: Do something here, then we… there would be some significant challenges. 183 00:21:22.500 --> 00:21:31.480 Owen Stephens: with behavior, you know, wanting it both ways, and I get that. It doesn't sound like those are necessarily completely insurmountable in terms of, like. 184 00:21:31.620 --> 00:21:39.399 Owen Stephens: If both… if both behaviors are sometimes desirable, then there might be ways of… of working with that. 185 00:21:39.770 --> 00:21:46.329 Owen Stephens: But it seems to me that unless we understand from the SIGs what kind of behaviours they actually see as desirable. 186 00:21:46.630 --> 00:22:02.700 Owen Stephens: And keep that up, you know, obviously bring ourselves up to date on that, because it does seem like some of these decisions were made a long time ago, perhaps with particular use cases in mind that either never got followed up, or have been forgotten about, or just are no longer relevant. 187 00:22:02.700 --> 00:22:16.069 Zak Burke (EBSCO): Yeah, so, from my point of view, a lot of the use cases are legitimate. Like, I can totally understand not… if you have… if you work in orders and there's some, like, complicated collection of filters that you need to apply to your work. 188 00:22:16.420 --> 00:22:26.409 Zak Burke (EBSCO): it's totally understandable why you would want those to persist. That makes sense to me. And so, I'm not pushing back against that as, a sort of use case requirement. 189 00:22:26.570 --> 00:22:37.300 Zak Burke (EBSCO): the… where I think it gets sticky is, like I described, with this mixing of values from the URL and values from storage, lead to edge cases that 190 00:22:37.480 --> 00:22:39.200 Zak Burke (EBSCO): I think make the… 191 00:22:39.600 --> 00:22:46.919 Zak Burke (EBSCO): can sort of, like, cause problems with, or just cause inconsistencies, and so what's the best way to manage those inconsistencies? Yeah. 192 00:22:46.980 --> 00:23:04.789 Zak Burke (EBSCO): And we probably didn't think about those at the time that that requirement came out. It was just like, oh, this gives us a way to persist this stuff, this is great, let's move on. And it's like, you know what, we've only defined 80% of the problem, and there's this other 20% that we didn't think about at the time, and now we're running into this other 20% and realizing, oh… 193 00:23:04.950 --> 00:23:08.690 Zak Burke (EBSCO): That actually caused some side effects that weren't great, 194 00:23:08.940 --> 00:23:10.809 Zak Burke (EBSCO): Do we care about those side effects? 195 00:23:11.190 --> 00:23:15.130 Owen Stephens: And we did also just… I can't remember who suggested it now, but there was… 196 00:23:15.600 --> 00:23:20.600 Owen Stephens: Also, a suggestion that one approach, or an approach we might want to look at, was 197 00:23:21.610 --> 00:23:24.629 Owen Stephens: Having some signal to the user that 198 00:23:24.780 --> 00:23:33.520 Owen Stephens: a set of, like, there were interacting filters going on here, like, so they, you know, not necessarily changing the behavior, but just alerting the user to the fact that… 199 00:23:33.520 --> 00:23:33.880 Zak Burke (EBSCO): Yeah. 200 00:23:34.950 --> 00:23:54.259 Owen Stephens: like, you know, your current URL filters and your local storage filters are different, or these, you know, the… being able to see what the totality of the filters being applied at any one time was, so at least the user knows what's going on, you know, even if that. 201 00:23:54.300 --> 00:23:54.890 Zak Burke (EBSCO): Leeds. 202 00:23:54.890 --> 00:23:59.880 Owen Stephens: to different behaviour in different cases, at least it's explicable. Yeah. 203 00:24:00.070 --> 00:24:02.309 Owen Stephens: I wanted to say one, kind of. 204 00:24:02.530 --> 00:24:06.720 Owen Stephens: Not… One other thing which is kind of not… 205 00:24:06.960 --> 00:24:19.600 Owen Stephens: pertinent directly to the discussion. But it did… does also occur to me that in orders specifically, and in other modules that apply acquisition units, that actually 206 00:24:20.060 --> 00:24:26.349 Owen Stephens: there's two things here. There's one that the results should always be the same, and that's not possible to guarantee 207 00:24:26.450 --> 00:24:35.529 Owen Stephens: once acquisition units are in play, because they can block certain users from seeing results. So, 208 00:24:36.650 --> 00:24:41.659 Owen Stephens: Result sets not being the same is different… And, and is I, is… 209 00:24:41.850 --> 00:24:48.350 Owen Stephens: with acquisition units, unachievable, deliberately, right? That deliberately blocks you viewing particular things. 210 00:24:48.350 --> 00:24:53.069 Zak Burke (EBSCO): So you're talking about, like, if people with different permissions might see different things because of acquisition units? 211 00:24:53.730 --> 00:25:03.520 Owen Stephens: Well, people would… yeah, I mean, if we create acquisition units as a kind of permission, this is… yeah. Yeah, so permission to view a particular order. 212 00:25:03.590 --> 00:25:12.010 Owen Stephens: So, you will not get the same results, just to be clear, even if you achieve the same filters. Or at least… no. 213 00:25:12.010 --> 00:25:27.999 Owen Stephens: you cannot guarantee the same results, even if you can guarantee the same filters. So, we are working in a world where if you share a URL with somebody else in orders, or in invoices, or in finance, and from Trillium onwards in agreements and licenses. 214 00:25:28.130 --> 00:25:33.170 Owen Stephens: Oh, I think there are some others that implement access units as well, organizations. 215 00:25:33.520 --> 00:25:35.909 Owen Stephens: I can't remember the full list, but 216 00:25:36.410 --> 00:25:39.290 Owen Stephens: You won't be able to guarantee you're seeing the same result. 217 00:25:39.610 --> 00:25:43.689 Owen Stephens: of, you know, just because you share a URL doesn't mean you'll get the same… 218 00:25:43.840 --> 00:25:48.760 Owen Stephens: result list, which… You know, is… is… 219 00:25:48.890 --> 00:25:55.950 Owen Stephens: Not necessarily pertinent to exactly what we're discussing here, but we should be clear when we talk about same result set versus same filters applied. 220 00:25:56.560 --> 00:25:57.130 Zak Burke (EBSCO): Sure. 221 00:25:58.130 --> 00:26:04.389 Zak Burke (EBSCO): There's a second point that I think you wanted to make when I interrupted to see clarification. I'm sorry, do you remember what that was? 222 00:26:05.270 --> 00:26:07.770 Owen Stephens: No, I think that was it, and I've talked enough, so… 223 00:26:13.390 --> 00:26:19.460 Tara Barnett (Index Data): I think that, again, I feel like my perspective is maybe not… not a standard library. 224 00:26:19.800 --> 00:26:30.169 Tara Barnett (Index Data): user's perspective, but, like, the first thing I always check is, like, is it an acquisitions unit problem? So I feel like that's part of the, like, known issues and not necessarily, bad for… 225 00:26:30.360 --> 00:26:44.930 Tara Barnett (Index Data): For what we're talking about. But one of the questions I had was, like, if you have this scenario where you have incompatible filters from the URL and from storage, is there no indication on the facets themselves, like these little X's that we see? 226 00:26:44.930 --> 00:26:47.140 Zak Burke (EBSCO): So they… they do, and actually… 227 00:26:47.320 --> 00:26:52.300 Zak Burke (EBSCO): looking more closely at my example from, like, A to B to A to C, 228 00:26:52.780 --> 00:27:04.739 Zak Burke (EBSCO): the… when you paste into C, you're expecting to get B all over again, and what you get is this intersection of A and B, and so the URL actually updates. You copy the URL from B, you paste it into C, 229 00:27:04.930 --> 00:27:19.830 Zak Burke (EBSCO): But then when that page loads, it grabs the URL filters, it grabs the local storage filters, it sees that they're… that, you know, that's changed, and so it does update the URL, it does update the side navigation, or the filters, as you said, which is good. 230 00:27:20.460 --> 00:27:36.269 Zak Burke (EBSCO): But if you were expecting, like, I copied the URL, I opened it in another tab, I saw something completely different, to me, that's not the expected behavior, right? Like, if I go to the URL for tab B, and I copy it into tab C, I expect to see the same thing. 231 00:27:36.740 --> 00:27:44.399 Zak Burke (EBSCO): And I didn't. But again, like, that's my expectation as a developer. It might not be the expectation of… 232 00:27:44.960 --> 00:28:01.449 Zak Burke (EBSCO): an end user, and, you know, I might just be harping on an inconsistency that bugs me because, you know, I'm a little bit OCD, and that's part of what makes me good as a developer, but that I'm looking for consistency that isn't necessarily important. 233 00:28:02.020 --> 00:28:02.820 Zak Burke (EBSCO): Right? 234 00:28:03.110 --> 00:28:03.620 Zak Burke (EBSCO): So… 235 00:28:03.620 --> 00:28:07.990 Tara Barnett (Index Data): you're underestimating the number of OCD librarians on this call alone. 236 00:28:07.990 --> 00:28:16.600 Zak Burke (EBSCO): Well, I'm just… my point is merely, like, having a system that's completely perfect Isn't necessarily the best system. 237 00:28:16.950 --> 00:28:33.090 Zak Burke (EBSCO): Right? But that's all. Like, not every inconsistency needs to be resolved. This is one… I think the user experience would be better, but I'm not an end user here, and so it's probably more important to hear from folks who use orders every day to find out 238 00:28:33.440 --> 00:28:39.170 Zak Burke (EBSCO): is this a problem for you? As someone who uses lots of different applications. 239 00:28:39.360 --> 00:28:46.180 Zak Burke (EBSCO): and just because I'm, you know, I'm working on the framework that goes underneath all these applications, right? And so I'm always trying to make sure 240 00:28:46.390 --> 00:28:57.339 Zak Burke (EBSCO): my buttons look the same in every place, and my filters operate the same in every place, because I'm responsible for the things that get shared, and so I want those shared things to be performant and consistent. 241 00:28:57.560 --> 00:29:10.790 Zak Burke (EBSCO): if other people's use of Folio is, I mostly just work inside users, I mostly just work inside orders, I mostly just work inside inventory, or the collection of things that are related to inventory, or the collection of things that is related to acquisitions. 242 00:29:11.150 --> 00:29:15.090 Zak Burke (EBSCO): Maybe as long as those applications behave consistently. 243 00:29:15.310 --> 00:29:21.399 Zak Burke (EBSCO): That's okay, even if, you know, some group of applications is inconsistent with another's. I… 244 00:29:21.810 --> 00:29:23.900 Zak Burke (EBSCO): I can just tell you that right now they're not. 245 00:29:24.020 --> 00:29:26.820 Zak Burke (EBSCO): And so I see that as a rough edge. 246 00:29:27.260 --> 00:29:34.299 Zak Burke (EBSCO): But, you know, maybe it's not a rough edge that bothers other people because they tend to work in a particular domain. 247 00:29:34.360 --> 00:29:47.749 Zak Burke (EBSCO): I can just explain why that edge is there, and what kind of problems I potentially see, and help hopefully, you know, help folks like this group make informed decisions about 248 00:29:47.960 --> 00:29:56.849 Zak Burke (EBSCO): Do we want to file this edge off or not, or do we want to leave it present because it's helpful for the people in acquisitions to have this kind of persistence? 249 00:29:57.010 --> 00:30:00.160 Zak Burke (EBSCO): I can just tell you what's gonna happen, I can't tell you if it's the right decision or not. 250 00:30:03.080 --> 00:30:04.019 Tara Barnett (Index Data): Sorry, go ahead. 251 00:30:04.740 --> 00:30:10.109 Laura Daniels: I have a whole bunch of thoughts swirling around in my head, so I'll try to keep track of them. 252 00:30:11.970 --> 00:30:24.340 Laura Daniels: I think you are not the only mildly OCD person. And that is also what makes librarians often good at what we do. 253 00:30:24.820 --> 00:30:31.429 Laura Daniels: Earlier, I was thinking, I can see myself wanting one type of behavior for myself. 254 00:30:31.620 --> 00:30:47.599 Laura Daniels: as a user who understands what's going on, and another type of behavior for a lot of other people using Folio who I don't expect to have the same sort of overarching perspective of it, which I recognize is impossible. So, first of all, I'm seeing, okay. 255 00:30:47.600 --> 00:30:57.379 Laura Daniels: there are things that I want it to do for me, but I'm recognizing that if it can do that for me, it's going to screw everybody else up. And so, I think just… 256 00:30:57.580 --> 00:31:11.560 Laura Daniels: I think, first of all, it's impossible to assume that we won't have institutions where people are working across multiple domains, and it's impossible for us to predict which domains somebody might work across, because 257 00:31:11.700 --> 00:31:27.399 Laura Daniels: every library is organized differently, and things happen, and you have to do something else. And also, I often am going into an app I'm not very familiar with to try to troubleshoot, and then it's even harder for me, because I don't know what to expect. So I feel like… 258 00:31:28.200 --> 00:31:44.060 Laura Daniels: having shared… I feel like I want us to go around and find out how important is the shared URL, because my… my assumption, and I could be wrong, but I think that having a URL that 259 00:31:44.230 --> 00:32:01.200 Laura Daniels: You can… something you copy and paste, you send it to somebody else, and they can see that exact thing is really, really important. And even more so, I think, when you think you have that and you don't, it really, really confuses and frustrates people. And… 260 00:32:01.410 --> 00:32:07.419 Laura Daniels: when people are confused and frustrated, they are unhappy and ineffective staff. So. 261 00:32:07.420 --> 00:32:22.320 Laura Daniels: I feel like, to me, if… if my… I'd like to validate that my assumption is correct, but if it is, I feel like preserving that ability to share URLs should be the starting point, and then figuring out, okay, what… 262 00:32:23.470 --> 00:32:34.380 Laura Daniels: Are there… are there improvements we can make to the ability to save filters that don't interfere with that? And if so, what are those? 263 00:32:36.460 --> 00:32:39.410 Zak Burke (EBSCO): I think that's a great way to frame it, personally. 264 00:32:40.470 --> 00:32:43.050 Zak Burke (EBSCO): Yeah, everything you've said really resonates. 265 00:32:48.530 --> 00:32:56.480 Laura Daniels: And the, the behavior we had for a while when the default for inventory was to not display 266 00:32:56.510 --> 00:33:10.160 Laura Daniels: Staff suppressed is a great example of this, that people would search for a barcode, and they knew the item record existed, because somebody had reported a problem with it, but because that filter was on, they couldn't see it, and people were 267 00:33:10.220 --> 00:33:11.430 Laura Daniels: Live it. 268 00:33:21.320 --> 00:33:26.460 Tara Barnett (Index Data): I was also not personally a fan of that behavior, but, you know, like. 269 00:33:26.920 --> 00:33:39.830 Tara Barnett (Index Data): the scenario that I interact with folio, like, with a library user most often is, like, there's a problem, a library has sent me a URL, and I need to be able to see exactly what they're saying in order to fix the problem. So, again, I don't… 270 00:33:39.940 --> 00:33:40.880 Tara Barnett (Index Data): No. 271 00:33:41.010 --> 00:33:44.450 Tara Barnett (Index Data): Charlotte. Charlotte was, ahead of the game there. 272 00:33:45.210 --> 00:33:52.570 Tara Barnett (Index Data): I don't know that that is, like, every… every SIG's top desire, although it sounds like you are on the same team as me, Laura. 273 00:33:53.120 --> 00:33:55.819 Tara Barnett (Index Data): Okay, so… 274 00:33:58.880 --> 00:34:11.740 Tara Barnett (Index Data): I don't know, what's the… what's the next best thing to do? It sounds like we still need to understand what the SIGs want, and we need to create prompts and talking points so that we're all going to the SIGs with the same message. 275 00:34:12.750 --> 00:34:16.349 Tara Barnett (Index Data): But now I'm confused about what that message is, so I don't know how to do this. 276 00:34:16.350 --> 00:34:26.300 Laura Daniels: I feel like my first question is, how often do you share URLs? How important is it that you be able to copy what's in 277 00:34:26.550 --> 00:34:31.539 Laura Daniels: Your address bar, and paste that into a message to somebody. 278 00:34:31.850 --> 00:34:33.679 Laura Daniels: And have that resolve. 279 00:34:36.699 --> 00:34:38.949 Laura Daniels: Not the only question, but I… 280 00:34:41.130 --> 00:34:48.149 Kristin Martin: I think related to that question, it's how often do you share URLs for a search? 281 00:34:48.540 --> 00:35:03.320 Kristin Martin: I feel like I share URLs for individual records, and sometimes how I got there is irrelevant. It might be in the URL, but, like, I don't care, I just need somebody to look at this inventory record, this PO, this item record, whatever it is. 282 00:35:05.420 --> 00:35:13.009 Laura Daniels: And would that mean that a functionality like click here for persistent URL? 283 00:35:13.450 --> 00:35:17.980 Laura Daniels: would be what we were looking for? I mean, as one option. 284 00:35:18.860 --> 00:35:19.979 Kristin Martin: You got it? 285 00:35:20.340 --> 00:35:22.049 Kristin Martin: Well, go ahead, Zach. 286 00:35:22.050 --> 00:35:34.909 Zak Burke (EBSCO): I was just gonna say, you made an important distinction there between a list of filters and a link to a specific ID, and so the issues that I've been highlighting are when filters are present, not when a particular ID is present. 287 00:35:37.420 --> 00:35:40.590 Kristin Martin: Yeah, I mean, it's just, if I… 288 00:35:41.210 --> 00:35:46.880 Kristin Martin: And I think this is true, right? Like, if I do a filter, and I find a record. 289 00:35:47.130 --> 00:35:51.580 Kristin Martin: from the filters. That history's all in the URL. 290 00:35:51.720 --> 00:36:00.549 Kristin Martin: But it doesn't stop anybody from being able to view that record. It just kind of makes the URL longer than it really needs to be, because that's not, like, important. 291 00:36:01.710 --> 00:36:03.339 Kristin Martin: But that's kind of a separate issue. 292 00:36:03.470 --> 00:36:04.719 Zak Burke (EBSCO): Yes, yeah, right. 293 00:36:04.720 --> 00:36:05.220 Kristin Martin: stopping. 294 00:36:05.220 --> 00:36:06.220 Zak Burke (EBSCO): There… yeah. 295 00:36:09.210 --> 00:36:14.140 Tara Barnett (Index Data): So, like, you could chop off everything from here and be like, record. Okay. 296 00:36:14.340 --> 00:36:21.149 Zak Burke (EBSCO): Right, because there's… you can imagine lots of different collections of filters would result in, you know. 297 00:36:21.260 --> 00:36:39.459 Zak Burke (EBSCO): 101.127 being visible? And so, is it… is it there because you searched for pending things and then clicked on it, or is it because you searched for, you know, all of the USGS vendors' records and searched for it, or because you looked for order types of one time and then searched for it? Any one of those different collections of filters. 298 00:36:39.460 --> 00:36:48.300 Zak Burke (EBSCO): would give you a different results list, and then the thing you're interested in, the details pane. And so if the thing that's interesting to you about this page is the details pane. 299 00:36:48.300 --> 00:36:55.150 Zak Burke (EBSCO): the problem I'm describing isn't really a problem. If the thing that's interesting to you is the results pane. 300 00:36:55.670 --> 00:36:56.890 Zak Burke (EBSCO): then… 301 00:36:57.100 --> 00:37:04.069 Zak Burke (EBSCO): you know, all the problems I sort of described at the top of the hour are present, where, 302 00:37:04.460 --> 00:37:11.599 Zak Burke (EBSCO): you might have, you know, different results present, even though you think you got to a consistent URL. 303 00:37:11.840 --> 00:37:18.929 Zak Burke (EBSCO): But the… in this case, the ID is not changing, no matter how you got there, and so you'll always be able to get to the same details record. 304 00:37:19.350 --> 00:37:25.230 Tara Barnett (Index Data): But I don't know that we can assume that just because the UUIDs are appearing in the… 305 00:37:25.460 --> 00:37:37.250 Tara Barnett (Index Data): resulting URL that you're sending to someone else doesn't mean that the search itself was not the point of the URL, because, like, if you search for something that has only one result, you'll always have these UUIDs. 306 00:37:37.250 --> 00:37:37.610 Zak Burke (EBSCO): Yep. 307 00:37:38.290 --> 00:37:43.090 Zak Burke (EBSCO): Yeah, you're right, it's… you can't intuit what someone's desired behavior is. 308 00:37:43.290 --> 00:37:55.410 Zak Burke (EBSCO): you know, what it is that they're trying to show here, right? If somebody sends you this record, are they showing you the item details, or are they showing you that, oh, look, the… you know, all the other vendor codes were XYZ or something? Like, I… I don't know. 309 00:37:56.390 --> 00:38:02.640 Tara Barnett (Index Data): Or, like, if there's a change between when you sent the URL and then it's like, oh, and now there's a second result included in that. 310 00:38:02.640 --> 00:38:04.460 Zak Burke (EBSCO): Yeah, 311 00:38:06.000 --> 00:38:18.770 Zak Burke (EBSCO): And that's a fair point, right? I'm talking about, oh, we have to have URLs be consistently represented. If you… if I do a search on Monday when, you know, there's 3 open orders for vendor, and I send that URL to my colleague, and they… 312 00:38:18.790 --> 00:38:32.089 Zak Burke (EBSCO): click on that bookmark on Wednesday, when now there's 17 open URLs, or open orders for a particular vendor. Obviously, they're going to see different results. The thing that I was sort of getting at was, if I send them a link. 313 00:38:32.750 --> 00:38:45.860 Zak Burke (EBSCO): it's going to… that has, you know, two facets in the filter, and they have been using orders… like, say I have facets A and B, and they have facets B and C. If I send them a link to a result set. 314 00:38:46.380 --> 00:39:05.029 Zak Burke (EBSCO): and they click on it, what they're gonna get is A and B from my result set, plus C from theirs, because my result has B in common with theirs, so my B from the URL is going to overwrite their B from local storage, and I'm gonna get A plus B plus C, which is not what I was trying to send them. I was trying to send them a search result of 315 00:39:05.030 --> 00:39:09.030 Zak Burke (EBSCO): you know, the filter with A and B applied, not ABC. So, that's the kind of… 316 00:39:09.720 --> 00:39:16.990 Zak Burke (EBSCO): inconsistency that I'm talking about, not where the data changes, but where, when the data is the same. 317 00:39:17.680 --> 00:39:21.130 Zak Burke (EBSCO): the same URL does not show the same results, so… 318 00:39:21.130 --> 00:39:21.800 Tara Barnett (Index Data): Right. 319 00:39:23.260 --> 00:39:27.290 Tara Barnett (Index Data): I see Charlotte wants to say something, and I will say something after Charlotte, because I can't raise my hand. 320 00:39:27.290 --> 00:39:36.529 Charlotte Whitt: Because it sounds like, listening to this conversation, that we want the URL to do something more or less impossible. 321 00:39:36.580 --> 00:39:56.020 Charlotte Whitt: over time. So, especially the… what you mentioned, Zach, well, if I create the search on Friday, and then my colleague has a day off and watches it on Tuesday, things can have completely changed. So, what about that we simply, you know, rethink 322 00:39:56.020 --> 00:39:57.910 Charlotte Whitt: How to capture the search. 323 00:39:57.930 --> 00:40:07.019 Charlotte Whitt: in the search and filter pane, and capture the result in the second pane, the result list. And maybe… so… 324 00:40:07.460 --> 00:40:14.710 Charlotte Whitt: If I am to share something with a colleague, I decide, what is it I want to share with my colleague? Is it 325 00:40:14.890 --> 00:40:22.149 Charlotte Whitt: this… how this is set up in search and filters, I want to, or is it, the result? 326 00:40:22.320 --> 00:40:28.379 Charlotte Whitt: for my given Friday, I want to share with my colleague. So maybe it's, we need, 327 00:40:28.560 --> 00:40:35.100 Charlotte Whitt: Kimi to, do some UX mockups on how could we have, this, 328 00:40:35.460 --> 00:40:42.489 Charlotte Whitt: capture function, and then that is captured and then shared, because then it would be consistent. 329 00:40:42.730 --> 00:40:45.959 Charlotte Whitt: I don't know the technical solution, but . 330 00:40:47.060 --> 00:40:57.049 Zak Burke (EBSCO): Yeah, so again, I think that's a really good question, and you make a good point in that if the data behind something is changing, what's really happening when you share a URL? 331 00:40:57.100 --> 00:41:11.589 Zak Burke (EBSCO): That sort of gets at how mod lists works, right? Is that you actually share… what mod lists does is that you can a query, and it gets a particular result set that it shares under an individual ID, and that's the only thing that happens with a mod lists thing. 332 00:41:11.800 --> 00:41:17.319 Zak Burke (EBSCO): And then if you want that list to get refreshed, you have to say, hey, go refresh this thing. 333 00:41:17.530 --> 00:41:23.930 Zak Burke (EBSCO): That's… That is one way of doing this kind of thing, and it can make canned searches super fast. 334 00:41:24.110 --> 00:41:25.839 Zak Burke (EBSCO): Because it… it… 335 00:41:25.960 --> 00:41:33.200 Zak Burke (EBSCO): if you have, you know, a thousand things in your result set, it has those thousand UUIDs, and it can just retrieve them by ID, 336 00:41:33.470 --> 00:41:36.900 Zak Burke (EBSCO): Retrieval by ID is always very fast, because that's always an indexed field. 337 00:41:37.220 --> 00:41:42.510 Zak Burke (EBSCO): So… but it's a very different way… 338 00:41:43.120 --> 00:41:57.930 Zak Burke (EBSCO): of having things operate than most of the UI operates right now. Again, I'm not saying this is good or bad, it's just different, but I'm glad you asked the question, because it also sort of points out that the way that Lists is managing that data is a little bit different. So… 339 00:41:58.810 --> 00:42:14.960 Zak Burke (EBSCO): I don't know, I feel like I'm sort of throwing bombs into this meeting right now and saying, well, here's a way that if we do it this way, it explodes, and here's a way, if we do it that way, it explodes. And I'm not, again, I'm not trying to say that any one of these is good or bad, they just have different side effects, and… 340 00:42:15.870 --> 00:42:18.790 Zak Burke (EBSCO): From my point of view, right now. 341 00:42:19.170 --> 00:42:27.770 Zak Burke (EBSCO): Borders is more of an outlier in terms of how… It's… URLs, function. 342 00:42:28.010 --> 00:42:45.389 Zak Burke (EBSCO): compared to many of the other UI applications. And I guess I should also say, UiLists is a bit of an outlier in terms of how its result sets function compared to most other things. I think lists has sort of been presented as… 343 00:42:45.890 --> 00:43:04.740 Zak Burke (EBSCO): this is an app that is oriented toward reporting, and reporting is expensive computationally, and so we have to cache the results, and so I think of that as something that's a special case, but it's sort of known to be a special case. I hadn't thought of orders as something that was a special case, and so its behavior surprised me. 344 00:43:04.990 --> 00:43:18.519 Zak Burke (EBSCO): And so, again, to sort of get at what Laura, I think, identified early, is what would be good default behavior for applications, and how can we add, sort of. 345 00:43:18.650 --> 00:43:25.560 Zak Burke (EBSCO): customizability on top of that default behavior, so that if you want to, you know. 346 00:43:25.560 --> 00:43:39.720 Zak Burke (EBSCO): load your preferred orders filters, because, you know, you need to apply these 17 things to do your job. What's a way to do that? And could we have the same functionality inside users, inside inventory? Or as you said. 347 00:43:40.170 --> 00:43:46.010 Zak Burke (EBSCO): you know, do we want other applications to reflect lists? 348 00:43:46.970 --> 00:43:53.459 Zak Burke (EBSCO): My inclination is that we probably don't want to do, with most applications, what lists does. 349 00:43:53.600 --> 00:44:02.269 Zak Burke (EBSCO): But that's definitely not a developer question, that's a… get that feedback from users, and then… 350 00:44:02.590 --> 00:44:04.790 Zak Burke (EBSCO): Figure out what they want. 351 00:44:05.400 --> 00:44:11.340 Zak Burke (EBSCO): But based on how most applications are developed so far, I don't think that's the route we would end up going. 352 00:44:16.480 --> 00:44:17.320 Tara Barnett (Index Data): Krista? 353 00:44:18.930 --> 00:44:30.220 Kristin Martin: Yeah, I think you bring up an interesting point about how lists could be used for some of these things, too. I mean, this could be a question that we ask people. My assumption has always been, if you… 354 00:44:30.380 --> 00:44:35.459 Kristin Martin: share a URL that has filters on it, and somebody else goes and uses that. 355 00:44:35.890 --> 00:44:50.820 Kristin Martin: that that search is gonna have the most current data, and if you share it on a Friday, and they come in on a Monday, and things have changed, like, that would be my expectation. So if somebody's like, we need to see how many, you know, pending orders we still have. 356 00:44:51.220 --> 00:44:59.759 Kristin Martin: Or we need to see how much money we, you know, have left in this fund. Like, I wouldn't want to be, like, going there and, like, not have that be current. 357 00:44:59.760 --> 00:45:00.150 Zak Burke (EBSCO): Yeah. 358 00:45:01.060 --> 00:45:16.219 Kristin Martin: That would be contrary to what I would expect. So, you know, it could be if you are trying to provide a point-in-time application, you've got the list app to do that. And maybe there are ways, if you need to go in and check on things that are… 359 00:45:17.240 --> 00:45:30.460 Kristin Martin: difficult to set up as a query, because you're trying to provide a lot of filters or queries, you know, that's more of a… that does sound more reporting to me than, 360 00:45:31.070 --> 00:45:35.740 Kristin Martin: Some of the operations where you always want to have the most current data that's out there. 361 00:45:36.160 --> 00:45:36.740 Zak Burke (EBSCO): Yeah. 362 00:45:38.500 --> 00:45:45.950 Tara Barnett (Index Data): I will… I will just clarify my earlier point before I let Owen go, because I can't raise my hand, so I'm not cutting in line. 363 00:45:46.020 --> 00:45:55.660 Tara Barnett (Index Data): Which was that, like, in this scenario here, so, like, if you were trying to send someone, for some reason, a list of every order that starts with these numbers and then add a wildcard. 364 00:45:55.660 --> 00:46:08.210 Tara Barnett (Index Data): In this current, system, you would end up with a record in your URL, but on Monday, after one more is added, you would end up with a search URL that looks like this, so I'm just saying that we can't assume that, like. 365 00:46:08.270 --> 00:46:20.670 Tara Barnett (Index Data): even if you're expecting to get different results, you can't assume that just because there was a record in the URL that the intention was to send you a record if and sent… like, they were trying to send you a search, which is such a tiny point and not that important. 366 00:46:21.500 --> 00:46:22.870 Tara Barnett (Index Data): Owen, sorry. 367 00:46:24.680 --> 00:46:30.779 Owen Stephens: I think that's quite an interesting point, Tara. It isn't one that I'd considered, 368 00:46:31.610 --> 00:46:36.440 Owen Stephens: And yeah, it definitely… Definitely suggests to me that having… 369 00:46:37.060 --> 00:46:41.739 Owen Stephens: persistent URLs for searches and records, clearly. 370 00:46:41.860 --> 00:46:50.580 Owen Stephens: accessible in the UI that users can then reuse makes a lot of sense to me, I have to admit, like, rather than just relying on them. 371 00:46:50.890 --> 00:46:55.390 Owen Stephens: Copying and pasting from the address bar, which feels like it's always going to be dicey. 372 00:46:55.750 --> 00:47:04.890 Owen Stephens: But, now I probably remember what I was gonna say. So I… I think that… 373 00:47:05.870 --> 00:47:09.479 Owen Stephens: Tara, you said you weren't sure what we were asking. 374 00:47:11.000 --> 00:47:13.449 Owen Stephens: the SIGs, at this point. 375 00:47:14.870 --> 00:47:21.890 Owen Stephens: But I think that, like, This issue of, like, applying… 376 00:47:22.250 --> 00:47:34.060 Owen Stephens: Like, having a set of filters that are applied by default, or that persist between sessions, and highlighting the behavior that we've talked about today, and the, you know. 377 00:47:34.650 --> 00:47:41.420 Owen Stephens: When that can go wrong, or whether that is going wrong from their point of view when… when they… 378 00:47:41.530 --> 00:47:42.860 Owen Stephens: either use… 379 00:47:43.030 --> 00:47:50.049 Owen Stephens: sessions in multiple tabs, or they have a shared URL, somebody sends them a URL of this type. 380 00:47:50.930 --> 00:47:54.450 Owen Stephens: It kind of feels like highlighting that behaviour 381 00:47:54.570 --> 00:48:04.740 Owen Stephens: Because actually, most… I think most applications don't do this, right? So, we really are saying, actually, in orders, this is what happens. And… 382 00:48:05.280 --> 00:48:12.289 Owen Stephens: in, you know, whatever other application, this is what happens. And… Just trying to get… 383 00:48:12.420 --> 00:48:20.059 Owen Stephens: the different SIGs to say, well, you know, persistence would be good, but, you know, only if it works in this way, or… 384 00:48:20.200 --> 00:48:24.040 Owen Stephens: For orders, you know, for the acquisition sig to say. 385 00:48:24.750 --> 00:48:32.749 Owen Stephens: yes, but we, you know, we'd want to handle it in this way. So we understand. I think that at the moment, I think what Laura said maybe at the start, was it, or… 386 00:48:33.310 --> 00:48:39.739 Owen Stephens: that… You know, we should still try and understand… no, it wasn't Nora, I can't remember who said it. 387 00:48:39.860 --> 00:48:45.910 Owen Stephens: their requirements at this point, and, and… 388 00:48:46.100 --> 00:48:59.169 Owen Stephens: almost… not necessarily not worry about what's possible, but… but then have this discussion again once we kind of understand what are those things that they really would like to see. Because, yes, some things will be impossible, but… 389 00:48:59.740 --> 00:49:05.860 Owen Stephens: Or at least, you know, it's not easy necessarily to have things work in two different ways simultaneously. 390 00:49:05.980 --> 00:49:11.899 Owen Stephens: but, I think that ex… like, if we can… 391 00:49:12.530 --> 00:49:25.489 Owen Stephens: take this session and boil it down to, this is the behavior we currently see in, say, 3 different apps, and when you, you know, when you use them normally, as it were, when you use them in multiple tabs, when you use them to share URLs. 392 00:49:26.360 --> 00:49:31.739 Owen Stephens: like… and get their feedback on what's good and what's bad about those, then perhaps 393 00:49:31.970 --> 00:49:42.240 Owen Stephens: that would be a way of asking the question, I suppose, without necessarily kind of saying, you know, what is it you want, which is always difficult for people to answer, 394 00:49:42.600 --> 00:49:43.949 Owen Stephens: Directly, like that. 395 00:49:44.450 --> 00:49:47.530 Zak Burke (EBSCO): Yeah, that's part of what I was trying to get at with my… 396 00:49:47.920 --> 00:49:54.280 Zak Burke (EBSCO): somewhat convoluted example, but, you know, maybe if I can try to distill that, I guess, in a little bit more. 397 00:49:54.580 --> 00:50:02.590 Zak Burke (EBSCO): And so, what I was trying to present was, here's… here's what happens if you go through these steps. Is that behavior okay with you? Is sort of… 398 00:50:02.590 --> 00:50:18.919 Zak Burke (EBSCO): Or does it bother you? Because it bothered me as a developer, and what I was trying to find out was, you know, does this bother folks who use orders? And maybe the answer is no, because they get to, you know, log out and log in and still have their filters. And, you know, if no one has noticed this, except for a cranky developer. 399 00:50:19.470 --> 00:50:27.549 Zak Burke (EBSCO): you know, maybe it's no big deal. I think it came to my attention on Slack, where there was somebody who was brand new to Folio, and had, sort of. 400 00:50:27.660 --> 00:50:38.140 Zak Burke (EBSCO): you know, inadvertently gone through the same steps that I did, and I was like, oh, wow, I see how that happened. I see how you got yourself into this situation, here's what I think is happening. And so… 401 00:50:38.490 --> 00:50:58.330 Zak Burke (EBSCO): you know, is that just because, you know, somebody new was sort of, you know, drawing this huge, big trail around things and stumbled on this inconsistency? Whereas, again, maybe folks who use these apps day to day don't move around so much, but as Laura said, you know, we can't make any assumptions about what apps various people use or don't use. 402 00:50:58.650 --> 00:51:01.810 Zak Burke (EBSCO): So, again, it's, I… 403 00:51:02.190 --> 00:51:12.889 Zak Burke (EBSCO): I think what you just said, and what Hera's been saying, as far as, let's come up with some examples and find out how people react to them, might be a good way to… 404 00:51:16.050 --> 00:51:30.590 Zak Burke (EBSCO): pursue… to figure out what question it is that we're trying to ask, or what level of consistency we're trying to achieve. Because if we can prevent… present, you know, 3 or 4 examples, and say, when we do these things, we get this result. When we do those things, we get that result. 405 00:51:31.610 --> 00:51:41.249 Zak Burke (EBSCO): Find out what people think about those different situations, and maybe that'll lead toward, finding the common ground. 406 00:51:41.560 --> 00:51:57.650 Zak Burke (EBSCO): Across SIGs about what we want desired behavior to be. Because if everybody says, oh, I like A, B, and C, and I hate D, E, and F, well, then it's really clear what we should do. But if you get, oh, I like A and B, well, I like B and C, well, A is wrong, you know, then we know 407 00:51:57.730 --> 00:52:03.310 Zak Burke (EBSCO): That there's more to discuss, before we can pursue a particular solution. 408 00:52:06.870 --> 00:52:23.650 Laura Daniels: I think there is also a desire, in some cases, to explore the possibility of having more persistent filters in other apps, and so I think this is an opportunity to find out, is that something that's desired, but also at the same time. 409 00:52:23.740 --> 00:52:38.289 Laura Daniels: be very clear, okay, this is… these are side effects of persistent filters. If… so if, you know, if this is a deal breaker, then we know we can't do that. 410 00:52:38.770 --> 00:52:56.789 Laura Daniels: Or we know it would be a lot of work to do that. And I… for inventory, at least, it's almost always the case where one person wants A and B, somebody else wants C and D, somebody… you know, it… I… I really think people want a mind-reading app. 411 00:52:56.790 --> 00:53:07.049 Laura Daniels: Because I… I hear people say, well, I want it to do this when I'm doing this, and then when I'm doing this other thing, I want it to behave in this completely different way. 412 00:53:07.050 --> 00:53:13.059 Laura Daniels: But just surfacing that, you know, reminding people, we can have… that… that… 413 00:53:13.170 --> 00:53:26.789 Laura Daniels: a program can behave in one way. It can't change its mind when it knows you're working on something else, or… because, I mean, in a way, that's, to me, what being able to have these 414 00:53:26.790 --> 00:53:35.459 Laura Daniels: filters is one way of saying, okay, when I'm working in this capacity, I only want to see these things. Well, okay, here's the cost of that. 415 00:53:35.870 --> 00:53:47.850 Zak Burke (EBSCO): Yeah, that's well put, I think. Here's the cost. I think that's a different way of, I think, of what I've been saying in terms of, here's the trade-offs, if we do that, it's… you get to choose if that cost is acceptable to you or not. 416 00:53:48.320 --> 00:54:06.070 Zak Burke (EBSCO): And I see Tara is mentioning in chat, did we talk about filter shortcuts rather than defaults? And I've been sort of thinking about something like that in the back of my head as well, in terms of, you know, maybe when you apply… when you get a URL, you know, you read exactly what's present in the URL, and you ignore local storage, but there's some option of, you know. 417 00:54:06.260 --> 00:54:10.910 Zak Burke (EBSCO): Apply this filter shortcut to my current result set, and would that be a way of… 418 00:54:11.340 --> 00:54:23.240 Zak Burke (EBSCO): You know, allowing people to save filter collections and then apply them to result sets, or, you know, apply them to a brand new search to load different collections. 419 00:54:23.720 --> 00:54:30.070 Zak Burke (EBSCO): That's definitely, I think, something that would be interesting to explore, so that the shortcut is the thing that gets persisted. 420 00:54:30.250 --> 00:54:33.050 Zak Burke (EBSCO): Rather than… 421 00:54:33.270 --> 00:54:44.130 Zak Burke (EBSCO): any particular thing getting persisted to local storage. I also think it's worth thinking about whether local storage is the right place to do any of this persistence, as opposed to, 422 00:54:44.320 --> 00:54:47.890 Zak Burke (EBSCO): back-end storage in an API, because again, like, right now. 423 00:54:48.000 --> 00:54:56.700 Zak Burke (EBSCO): Maybe if you work at the same computer every day, you're not gonna notice a difference between those two things, but anybody who might rotate across workstations or something like that. 424 00:54:58.720 --> 00:55:05.880 Zak Burke (EBSCO): It could be advantage… advantageous to be able to log into any workstation and have your personal filters applied 425 00:55:06.010 --> 00:55:12.979 Zak Burke (EBSCO): to, the result sets. But I don't know how often that happens or not, and so… 426 00:55:13.090 --> 00:55:15.690 Zak Burke (EBSCO): It might be that I'm sort of inventing work there. 427 00:55:15.910 --> 00:55:18.049 Zak Burke (EBSCO): Local storage, to me, is just a… 428 00:55:20.710 --> 00:55:36.050 Zak Burke (EBSCO): The potential for misunderstanding, I think, is very high, because you can't really tell that you got… that that data only came from your browser on your computer, as opposed to that data came from the fact that 429 00:55:36.320 --> 00:55:41.489 Zak Burke (EBSCO): Folio recognized you as you, and would have loaded that same profile anywhere else. 430 00:55:43.740 --> 00:55:53.230 Zak Burke (EBSCO): Probably for most use cases, you never notice that, and so you don't even know that it's happening, until you get a new laptop and now all your filters are missing. 431 00:55:53.480 --> 00:56:03.050 Zak Burke (EBSCO): So, it… local storage, I think, just has a lot of those, sort of, gotcha moments. And… 432 00:56:03.310 --> 00:56:05.340 Zak Burke (EBSCO): That's what has, 433 00:56:05.660 --> 00:56:10.439 Zak Burke (EBSCO): If you hear me sort of, like, pushing back against it, that's where that's coming from. 434 00:56:13.130 --> 00:56:20.580 Tara Barnett (Index Data): Okay, we're getting towards the end of the hour, so Owen, and then I think I'm gonna call it, and I think I know what we'll be talking about on April 6th as well. 435 00:56:22.390 --> 00:56:37.109 Owen Stephens: Thanks, Sarah. I wanted to say, yeah, I agree with you and Zach on the filter shortcuts. I think it's a nice idea, and honestly makes more sense to me, but then I also see, like, for some users, that 436 00:56:37.190 --> 00:56:47.270 Owen Stephens: if that resulted for some users in them having to do that every time, or very often they hit the screen, then… then that would be uncomfortable for them, so I… I definitely… 437 00:56:47.430 --> 00:56:49.160 Owen Stephens: can see… 438 00:56:50.280 --> 00:56:58.820 Owen Stephens: that as a potential issue. I also want… I think, Zach's point about… I mean, we talked about this personalization 439 00:56:59.780 --> 00:57:05.989 Owen Stephens: The fact that local storage is used at the moment for some aspects of this personalization 440 00:57:06.400 --> 00:57:11.370 Owen Stephens: that includes, I think, the columns that are used in certain MCLs as well. 441 00:57:12.300 --> 00:57:14.640 Owen Stephens: It's definitely not great. 442 00:57:14.890 --> 00:57:17.950 Owen Stephens: from, like… I think… 443 00:57:19.900 --> 00:57:37.430 Owen Stephens: I think these are things, and I guess, you know, again, this is something we could ask users, but my impression is that when we talk about things like persistent filters, or, you know, filters that… default filters that users want to see, or which columns they want to see in the results, generally. 444 00:57:38.360 --> 00:57:46.100 Owen Stephens: it would be… they want that to follow them. They don't really care which computer they're working on, or which browser they're working in. 445 00:57:46.380 --> 00:58:02.539 Owen Stephens: those are still rational choices. They've not set it up, they're not generally working, like, oh, I use a Firefox session for this task because I've got one set of things set up and Chrome for another because I've got the other set up. They… they just want it to be consistent across 446 00:58:02.810 --> 00:58:08.220 Owen Stephens: what they do, and once they set it up, they don't really want to lose those settings, 447 00:58:08.440 --> 00:58:14.869 Owen Stephens: Except explicitly, you know, so, I do think that… 448 00:58:15.150 --> 00:58:20.570 Owen Stephens: Since we now have some profile stuff starting to creep into… 449 00:58:21.070 --> 00:58:25.839 Owen Stephens: Bolio, it's, you know, that discussion is worth having as well. 450 00:58:30.700 --> 00:58:48.670 Tara Barnett (Index Data): I'm sure someone has a response to that. However, it is, 12.58 where I am, and I have a meeting at 1. So I think I will say thank you for this great discussion today. We'll continue this on April 6th, and I'll post some notes, and possibly some homework, to the channel over the next couple of days, okay? 451 00:58:49.160 --> 00:59:01.829 Zak Burke (EBSCO): I'll try to post some more clear examples as well, in terms of, like, where inconsistencies can come from, because, like I said, I know that example is kind of convoluted, and folks had trouble following it, so I'll see if I can articulate that, 452 00:59:02.280 --> 00:59:07.399 Zak Burke (EBSCO): In a way that makes it easier to digest, so that we can see, what the trade-offs are. 453 00:59:08.390 --> 00:59:16.869 Tara Barnett (Index Data): I will definitely still need, like, the Sesame Street video version, but I would love to see your examples. Alright, have a great rest of your Monday, everyone, and we'll talk to you later. Bye! 454 00:59:16.870 --> 00:59:17.540 Laura Daniels: Bye!