WEBVTT 00:01:06.000 --> 00:01:10.000 Hello. 00:01:10.000 --> 00:01:16.000 Right. 00:01:16.000 --> 00:01:19.000 Sarah, apologies, I have to leave halfway through, so I'll just jump off then. 00:01:19.000 --> 00:01:21.000 Yeah. No problem. 00:01:21.000 --> 00:01:25.000 Thanks for joining. et al. 00:01:25.000 --> 00:01:26.000 Um, I was trying to read… 00:01:26.000 --> 00:01:28.000 Mm-hmm. 00:01:28.000 --> 00:01:33.000 Uh, Zach's note on the channel about how what we're asking for is… is not possible. 00:01:33.000 --> 00:01:35.000 I'm trying to decide if that impacts 00:01:35.000 --> 00:01:39.000 what we do today, apparently. 00:01:39.000 --> 00:01:40.000 I don't think so, because, like, 00:01:40.000 --> 00:01:41.000 was it possible? Was not. 00:01:41.000 --> 00:01:42.000 I think we should still… 00:01:42.000 --> 00:01:45.000 I think we should still outline 00:01:45.000 --> 00:01:47.000 what we would like. 00:01:47.000 --> 00:01:48.000 Okay. 00:01:48.000 --> 00:01:52.000 And then we can determine 00:01:52.000 --> 00:01:55.000 How much of what we want is feasible? 00:01:55.000 --> 00:02:00.000 I think? 00:02:00.000 --> 00:02:01.000 Because we still… 00:02:01.000 --> 00:02:03.000 Yeah, I'm curious. 00:02:03.000 --> 00:02:13.000 Even if a lot of what we want is not feasible, we still have the challenge that we were trying to address. 00:02:13.000 --> 00:02:14.000 With inconsistency. 00:02:14.000 --> 00:02:22.000 And so at the very least, we want to address that in a meaningful way. 00:02:22.000 --> 00:02:24.000 I think that makes sense. 00:02:24.000 --> 00:02:42.000 I wasn't entirely sure that… what the… What we were asking for was what he was describing, but… Maybe I've… I'm not getting… either I'm not understanding what he's posted, or I'm… 00:02:42.000 --> 00:02:45.000 getting confused about what it was we wanted. 00:02:45.000 --> 00:02:51.000 Yeah, okay, so maybe if we all look at this together, we'll, uh, we'll be able to figure this out. 00:02:51.000 --> 00:02:52.000 Um, so off. 00:02:52.000 --> 00:02:56.000 Is the Wookiee behaving for other people? 00:02:56.000 --> 00:02:59.000 I'm unable to… 00:02:59.000 --> 00:03:01.000 get to our meetings page. 00:03:01.000 --> 00:03:03.000 Mm-mm. 00:03:03.000 --> 00:03:05.000 And maybe it's just… 00:03:05.000 --> 00:03:09.000 My brows, okay. 00:03:09.000 --> 00:03:10.000 Okay… 00:03:10.000 --> 00:03:11.000 Yeah. 00:03:11.000 --> 00:03:15.000 Oh, it's been fine. 00:03:15.000 --> 00:03:21.000 hopefully it's okay. 00:03:21.000 --> 00:03:23.000 Okay, sorry, give me one more second. 00:03:23.000 --> 00:03:32.000 see if it likes that. 00:03:32.000 --> 00:03:39.000 All right. Sorry for all the frantic background clicking as I try and close things. 00:03:39.000 --> 00:03:41.000 Okay, uh… 00:03:41.000 --> 00:03:43.000 So… 00:03:43.000 --> 00:03:50.000 Today, we're continuing our discussion that we started on Wednesday, um, about bringing acquisitions behavior in line with folio defaults. 00:03:50.000 --> 00:03:55.000 For those who are joining us a little bit, uh, later, we had some… 00:03:55.000 --> 00:04:00.000 late-breaking news this morning about whether or not that's possible, so I think we're going to try and take a… 00:04:00.000 --> 00:04:03.000 look at that together and try to understand what Zach said. 00:04:03.000 --> 00:04:09.000 Um, Joe let us know that he wasn't able to join this meeting, but our goal for today, uh, was to… 00:04:09.000 --> 00:04:15.000 Um, create a short slide deck covering the behavior in question, um… 00:04:15.000 --> 00:04:21.000 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 00:04:21.000 --> 00:04:27.000 What we're asking for might not be possible changes the fact that it's desirable, um, either way, so, uh… 00:04:27.000 --> 00:04:32.000 I think that's still valid to do. But before we get into that, 00:04:32.000 --> 00:04:36.000 Um, upcoming sessions, uh, so… 00:04:36.000 --> 00:04:39.000 Our next session would be on… 00:04:39.000 --> 00:04:41.000 April 1st, April Fool's. 00:04:41.000 --> 00:04:53.000 Um, 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. 00:04:53.000 --> 00:04:57.000 The next thing on here is very exciting news. We have… 00:04:57.000 --> 00:05:00.000 found co-convengers for this SIG, so it will not… 00:05:00.000 --> 00:05:09.000 die with my, uh, with my departure, which is great. Um, so Alyssa and Laura have volunteered to step up. We will coordinate that, uh, later in April. 00:05:09.000 --> 00:05:16.000 Yay! So, thank you so much for that, I really appreciate it, um, and I'm sure everyone here does as well. 00:05:16.000 --> 00:05:26.000 Um, the last thing that I put on announcements and housekeeping is the Wolfgund presentation Laura went ahead and submitted that, so we have a working session that has been submitted. 00:05:26.000 --> 00:05:31.000 I don't think we talked about doing any other sessions, so I think we're good as far as WolfCon is concerned. 00:05:31.000 --> 00:05:34.000 I had a quick, um, just temperature check. 00:05:34.000 --> 00:05:37.000 about something else that I might propose. 00:05:37.000 --> 00:05:44.000 Um, since Tom and I are ostensibly working on moving forward with item state, 00:05:44.000 --> 00:05:48.000 I was thinking of doing, like, a 25-minute 00:05:48.000 --> 00:05:51.000 Um, item state… 00:05:51.000 --> 00:05:59.000 Where… where we are now, this would force me and Tom to go gather input from the community before that. 00:05:59.000 --> 00:06:05.000 And use… use the, uh, the WolfCon session as a sort of… 00:06:05.000 --> 00:06:07.000 Making sure everybody knows 00:06:07.000 --> 00:06:14.000 what… what the current functionality is, what the challenges are, and sort of determining 00:06:14.000 --> 00:06:23.000 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? 00:06:23.000 --> 00:06:25.000 virtually. 00:06:25.000 --> 00:06:44.000 And maybe just, you know, Slack… Slack… Slack, yes, sorry, because we 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. 00:06:44.000 --> 00:06:50.000 I'm gonna predict you get zero of the second option. Like, people directly messaging you to say that's a waste of time. 00:06:50.000 --> 00:06:54.000 I'm gonna go ahead and assume. Oh my god, Zach's here! We're safe. 00:06:54.000 --> 00:06:56.000 Okay. Um… 00:06:56.000 --> 00:06:59.000 That's… that's a terrifying thing to enter a meeting to. 00:06:59.000 --> 00:07:04.000 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. 00:07:04.000 --> 00:07:10.000 Um, but Laura, I'm sure you're not gonna get any, uh, detractors from your WolfCon session, for sure. 00:07:10.000 --> 00:07:12.000 Um, so… 00:07:12.000 --> 00:07:19.000 Okay, um, any other announcements, housekeeping, before we keep going? 00:07:19.000 --> 00:07:25.000 Okay, great. Um, so the main thing that we were hoping to talk about today is, um, the discussion we started last week. 00:07:25.000 --> 00:07:30.000 Uh, last week when we were, uh, talking, hopefully I actually put notes on here. 00:07:30.000 --> 00:07:37.000 Um, what we agreed on for personalized defaults was that 00:07:37.000 --> 00:07:42.000 URLs that you paste into the URL bar should always be obeyed, no matter what your personal defaults are. 00:07:42.000 --> 00:07:46.000 Hard refresh should always reset the filters, you shouldn't have to log out and in again. 00:07:46.000 --> 00:07:54.000 Um, 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. 00:07:54.000 --> 00:07:59.000 So that we understand when it's helpful and when it's not helpful within a session. 00:07:59.000 --> 00:08:08.000 Um, any defaults that we ask for, uh, that are retained between sessions should be set user by user, rather than by the entire tenant. 00:08:08.000 --> 00:08:15.000 And then, um, default should be set within the app rather than in settings. Um, so we talked about a few different ways that that could look, but 00:08:15.000 --> 00:08:17.000 Ultimately, it was… 00:08:17.000 --> 00:08:20.000 it sounded like people agreed that having a whole mirror 00:08:20.000 --> 00:08:23.000 interface in settings was not a good idea. 00:08:23.000 --> 00:08:31.000 Is there anything else relevant that we decided that I missed? 00:08:31.000 --> 00:08:37.000 Um, so, uh, as part of that, we realized that we needed to understand the behavior, uh, 00:08:37.000 --> 00:08:50.000 from the perspective of all of the SIGs, because we're talking about changing things across folio. So, uh, 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. 00:08:50.000 --> 00:08:54.000 Which was hard in the first place for us to understand. 00:08:54.000 --> 00:08:56.000 Um… 00:08:56.000 --> 00:09:00.000 So we can work on that here. 00:09:00.000 --> 00:09:03.000 But the first question is, are we asking for something impossible? 00:09:03.000 --> 00:09:07.000 In the first place. And that, I think, is… 00:09:07.000 --> 00:09:11.000 why I'm so glad that Zach is here, because I wasn't sure I understood. 00:09:11.000 --> 00:09:17.000 what you posted on Slack. 00:09:17.000 --> 00:09:22.000 Sure, so do you want to talk through that example a little bit? 00:09:22.000 --> 00:09:34.000 Uh, and maybe it'll explain… why things get dicey in terms of how… data in a URL is mixing with data that's in storage and causing those confusing results. 00:09:34.000 --> 00:09:56.000 Um… So the example that I gave is sort of messy in terms of stepping through a bunch of tabs. But what essentially happens is you do a search in tab A and… that the filters that you add values to get copied into your… the URL, and they get copied into storage. 00:09:56.000 --> 00:09:58.000 And then you open tab B, and you do another search. 00:09:58.000 --> 00:10:04.000 And those get copied into the URL for B, and then they overwrite what's in storage for tab A. 00:10:04.000 --> 00:10:12.000 You go back to tab A, you do another search. It's going to update your URL. It's going to update what's in storage. 00:10:12.000 --> 00:10:17.000 And now, if you look at tab B and you copy that URL. 00:10:17.000 --> 00:10:22.000 the URL is now out of sync with what's in storage. 00:10:22.000 --> 00:10:32.000 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. 00:10:32.000 --> 00:10:47.000 The URL values from B and the local storage, which is the same as the URL storage in A. And so when those 2 things merge, you know, now that there's just a much smaller set, because instead of it being this, it's this. And so you only get the intersection. 00:10:47.000 --> 00:11:11.000 And so that's what causes the glitch there. Um, so it's… Um, 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, um… 00:11:11.000 --> 00:11:24.000 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. 00:11:24.000 --> 00:11:49.000 Um, how storing those values in different places. Um, 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 writing stuff to local storage causes, you know, URLs to not be completely consistent because it's really important to us that people can. 00:11:49.000 --> 00:12:00.000 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. 00:12:00.000 --> 00:12:11.000 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. 00:12:11.000 --> 00:12:19.000 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. 00:12:19.000 --> 00:12:28.000 We just have to understand… how storing things in the URL, how storing things in session storage or local storage. 00:12:28.000 --> 00:12:38.000 affects those things. So that's what I was trying to illustrate, I guess, with that example is that data in the URL and. 00:12:38.000 --> 00:12:45.000 data in local storage can get out of sync, and that can be tricky. 00:12:45.000 --> 00:12:51.000 Maybe it would… if it would be helpful, I'm happy to talk about how different kinds of storage work. 00:12:51.000 --> 00:12:58.000 and interact, because again, you know, different tabs. I think it makes sense to folks that different tabs have different URLs. 00:12:58.000 --> 00:13:12.000 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. 00:13:12.000 --> 00:13:18.000 Um, and so that's where that discrepancy… comes in. 00:13:18.000 --> 00:13:32.000 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 and pipe up when you, you know, start asking for something impossible. 00:13:32.000 --> 00:13:33.000 Sorry, I see Owen's hand. Let's start with that. 00:13:33.000 --> 00:13:36.000 Whatever would be most helpful. 00:13:36.000 --> 00:13:41.000 Thanks, Zach. And can you just outline what… what's the… 00:13:41.000 --> 00:13:45.000 what… what is it that we get from the local storage? 00:13:45.000 --> 00:13:50.000 at the moment, why do we use local storage? 00:13:50.000 --> 00:13:56.000 I. So yeah, so my the I think the big feature that local storage. 00:13:56.000 --> 00:14:03.000 ads here is the ability for a filter to persist across sessions. So if you sign in. 00:14:03.000 --> 00:14:09.000 And you do a search and add some filters. 00:14:09.000 --> 00:14:11.000 And then you sign out. And then you sign back in. 00:14:11.000 --> 00:14:20.000 in the same browser, on the same machine. the search from your first session will persist. 00:14:20.000 --> 00:14:26.000 to your second session, right? So the local storage persists across logouts. 00:14:26.000 --> 00:14:27.000 It's permanent. 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. 00:14:27.000 --> 00:14:39.000 And what does it do for us? 00:14:39.000 --> 00:14:47.000 And then log in on your laptop. Those 2 sessions are not really connected because local storage is on your browser. 00:14:47.000 --> 00:14:48.000 And is it persistent? 00:14:48.000 --> 00:14:49.000 So. 00:14:49.000 --> 00:14:57.000 like, across browser sessions, or does the browser clear that if you close the browser down? 00:14:57.000 --> 00:14:58.000 Okay, so… 00:14:58.000 --> 00:15:00.000 It does not clear it if you close the browser down. It is persistent. It's completely persistent. 00:15:00.000 --> 00:15:05.000 Yeah, okay. 00:15:05.000 --> 00:15:06.000 And this might not be a question for you, Zach, I don't know, but, like, 00:15:06.000 --> 00:15:07.000 It's… it's there until it's cleared. 00:15:07.000 --> 00:15:10.000 Do we know, like… 00:15:10.000 --> 00:15:15.000 Is that used, like, universally across… 00:15:15.000 --> 00:15:18.000 apps in folio? Is it widely, like, that… that… 00:15:18.000 --> 00:15:19.000 Because he… 00:15:19.000 --> 00:15:38.000 No, so it… 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, uh, to have some sessions. 00:15:38.000 --> 00:15:39.000 So, yeah, I think… 00:15:39.000 --> 00:15:41.000 To have some of these searches be sticky across sessions. I… uh… I'd have to dig around in Jira to try to find it. 00:15:41.000 --> 00:15:45.000 Well, I think that's where we started this, right? Because… 00:15:45.000 --> 00:15:46.000 orders does do that, right? That's… 00:15:46.000 --> 00:15:49.000 Mm-hmm. Yes, exactly. 00:15:49.000 --> 00:15:52.000 Okay, so that… and that's… 00:15:52.000 --> 00:15:54.000 I think that's where this discussion 00:15:54.000 --> 00:15:56.000 started last week, Joe Reimer's, uh, came, uh, Reimer, sorry, came along and, uh… 00:15:56.000 --> 00:16:01.000 Right. Yes. 00:16:01.000 --> 00:16:05.000 talked about that, and so this… yeah, I think we… 00:16:05.000 --> 00:16:11.000 what we were looking for is a way forward that has 00:16:11.000 --> 00:16:16.000 consistent behavior, or the option of consistent behavior across apps. 00:16:16.000 --> 00:16:17.000 Um, and… 00:16:17.000 --> 00:16:20.000 Right. 00:16:20.000 --> 00:16:23.000 definitely, I think that… 00:16:23.000 --> 00:16:28.000 that idea of having persistence, like, we talked about 00:16:28.000 --> 00:16:31.000 Um… 00:16:31.000 --> 00:16:33.000 the possibility of having 00:16:33.000 --> 00:16:37.000 the user choose whether some… whether that behavior was on or off? 00:16:37.000 --> 00:16:39.000 But I get that, obviously, as soon as you say, well, that can be on or off, then you get the problem with 00:16:39.000 --> 00:16:43.000 Mm-hmm. 00:16:43.000 --> 00:16:45.000 the, um… the URLs. Would it be… 00:16:45.000 --> 00:16:48.000 Yeah. 00:16:48.000 --> 00:16:52.000 this may be being a bit too deep right now, I don't know, but… 00:16:52.000 --> 00:16:55.000 The other thing that occurs to me is, like, 00:16:55.000 --> 00:16:59.000 if we want shareable URLs, 00:16:59.000 --> 00:17:01.000 I mean, would it be possible to have 00:17:01.000 --> 00:17:04.000 URLs that shared… 00:17:04.000 --> 00:17:09.000 with a parameter that said, don't apply 00:17:09.000 --> 00:17:10.000 Yeah. 00:17:10.000 --> 00:17:18.000 like, could you… could you actually start, 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 00:17:18.000 --> 00:17:20.000 produce a persistent URL of some kind. 00:17:20.000 --> 00:17:36.000 Yeah, so the the last example that I gave sort of gets at why we have this problem where like the the current problem with URLs leading to inconsistent results is because URLs are unique per tab. 00:17:36.000 --> 00:17:55.000 But local storage is shared. 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. 00:17:55.000 --> 00:18:12.000 Well, let me take the color and shape from the URL, because the URL is definitive, and I'm going to throw away the color value that I have in storage, but I'll add the one for size. 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. 00:18:12.000 --> 00:18:26.000 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. Um, and so there's a couple of ways that you could work around that. One is having URLs that. 00:18:26.000 --> 00:18:43.000 include… 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. 00:18:43.000 --> 00:18:57.000 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. 00:18:57.000 --> 00:19:10.000 And so that's what allows… a different tab that does have a value for prefix, suffix, vendor. When that gets lodged in storage, and then you mix a URL. 00:19:10.000 --> 00:19:23.000 from a different tab, that's what causes that sort of… pollution of the results. And so one option would be for URLs to always include. 00:19:23.000 --> 00:19:39.000 empty values, but that could lead to really long URLs. But it would solve the problem. Another is something like you were saying, which is add a special value to the URL, which is something like. 00:19:39.000 --> 00:19:49.000 only use the filter values from my URL. Please ignore local storage equals true. Some kind of flag that basically says. 00:19:49.000 --> 00:20:08.000 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? 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? 00:20:08.000 --> 00:20:24.000 It would work, but it would be kind of messy, potentially, so… My… my inclination would be figure out how to include empty filters in the URL. But with something like orders, where there are so many facets. 00:20:24.000 --> 00:20:41.000 I don't know how plausible that is. 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. 00:20:41.000 --> 00:20:44.000 Okay. 00:20:44.000 --> 00:20:46.000 Yeah, I'll… I think this is my last 00:20:46.000 --> 00:20:50.000 comment. Thanks, Zach, again. Um, and then I'll stop, which is… 00:20:50.000 --> 00:20:52.000 One is… is just… 00:20:52.000 --> 00:20:55.000 like, in terms of our discussion right now, 00:20:55.000 --> 00:20:57.000 And… and… 00:20:57.000 --> 00:20:59.000 taking it to the SIGs. 00:20:59.000 --> 00:21:05.000 I… I think that understanding the desired behaviors from the SIGS is… 00:21:05.000 --> 00:21:09.000 is a good starting point still, like… 00:21:09.000 --> 00:21:12.000 it seems to me that Zach is outlining, like, 00:21:12.000 --> 00:21:16.000 If we were to currently… 00:21:16.000 --> 00:21:22.000 do something here, then we… there would be some significant challenges. 00:21:22.000 --> 00:21:23.000 with behavior, you know, 00:21:23.000 --> 00:21:30.000 wanting it both ways, and I get that. It doesn't sound like those are necessarily completely insurmountable in terms of, like, 00:21:30.000 --> 00:21:37.000 If both… if both behaviors are sometimes desirable, then there might be ways of… of working with that. 00:21:37.000 --> 00:21:39.000 Um, but it seems to me that unless we understand from the SIGs, 00:21:39.000 --> 00:21:42.000 Yeah. 00:21:42.000 --> 00:21:45.000 what kind of behaviours they actually see as desirable. 00:21:45.000 --> 00:21:51.000 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 00:21:51.000 --> 00:21:54.000 a long time ago, um, perhaps with particular… 00:21:54.000 --> 00:21:55.000 Mm-hmm. 00:21:55.000 --> 00:22:02.000 use cases in mind that either never got followed up or have been forgotten about, or just are no longer relevant. 00:22:02.000 --> 00:22:16.000 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. 00:22:16.000 --> 00:22:31.000 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. 00:22:31.000 --> 00:22:32.000 Yeah. 00:22:32.000 --> 00:22:40.000 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. 00:22:40.000 --> 00:22:44.000 And we… we… 00:22:44.000 --> 00:22:45.000 Yeah. And we did discuss… 00:22:45.000 --> 00:23:00.000 I think make the… can sort of, like, cause problems with, um, or just cause inconsistencies. And so what's the best way to manage those inconsistencies? 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. 00:23:00.000 --> 00:23:05.000 And now we're running into this other 20% and realizing, oh. 00:23:05.000 --> 00:23:08.000 That actually caused some side effects that weren't great. 00:23:08.000 --> 00:23:09.000 And I… and we did also just… I can't remember who suggested it now, but there was… 00:23:09.000 --> 00:23:14.000 Do we care about those side effects? 00:23:14.000 --> 00:23:16.000 Also, a suggestion that one and 00:23:16.000 --> 00:23:20.000 approach, or an approach you might want to look at was… 00:23:20.000 --> 00:23:23.000 having some signal to the user that 00:23:23.000 --> 00:23:28.000 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 00:23:28.000 --> 00:23:32.000 Mm-hmm. 00:23:32.000 --> 00:23:33.000 Um, that certain… that things… like, you know, 00:23:33.000 --> 00:23:36.000 Yeah. 00:23:36.000 --> 00:23:42.000 your current URL filters and your local storage filters are different, or these, you know, 00:23:42.000 --> 00:23:43.000 Mm-hmm. Yeah. 00:23:43.000 --> 00:23:48.000 being able to see what the totality of the filters being applied at any one time was. 00:23:48.000 --> 00:23:49.000 So, at least the user knows what's going on, you know, even if that… 00:23:49.000 --> 00:23:53.000 Mm-hmm. Yeah. 00:23:53.000 --> 00:23:54.000 leads to different behaviour in different cases, at least it's explicable. 00:23:54.000 --> 00:23:57.000 Yeah. 00:23:57.000 --> 00:23:59.000 I wanted to say one, kind of, 00:23:59.000 --> 00:24:01.000 Yeah. 00:24:01.000 --> 00:24:05.000 not… um… one other thing which is kind of not… 00:24:05.000 --> 00:24:08.000 pertinent directly to the discussion. 00:24:08.000 --> 00:24:17.000 But it did… does also occur to me that in order specifically, and in other modules that apply acquisition units, 00:24:17.000 --> 00:24:25.000 that actually… there's two things here. There's one that the results should always be the same, and that's not possible to guarantee 00:24:25.000 --> 00:24:31.000 once acquisition units are in play, because they can block certain users from seeing 00:24:31.000 --> 00:24:33.000 results. So… 00:24:33.000 --> 00:24:35.000 Um… 00:24:35.000 --> 00:24:38.000 result sets not being the same is different… 00:24:38.000 --> 00:24:45.000 and is with acquisition units, unachievable deliberately, right? That… that deliberately blocks you viewing 00:24:45.000 --> 00:24:48.000 particular things, versus… 00:24:48.000 --> 00:24:52.000 So you're talking about, like, if people with different permissions might see different things because of acquisition units? 00:24:52.000 --> 00:24:54.000 Well, people with… yeah, I mean, if we… 00:24:54.000 --> 00:25:01.000 pre-acquisition units as a kind of permission. This isn't… yeah. Yeah, so permission to view a particular order. 00:25:01.000 --> 00:25:02.000 Um, so… 00:25:02.000 --> 00:25:03.000 Right, yeah. Yes, that's understandable. 00:25:03.000 --> 00:25:08.000 You will not get the same results, just to be clear, even if you achieve the same filters. 00:25:08.000 --> 00:25:13.000 Um, or at least, no, you cannot guarantee the same results 00:25:13.000 --> 00:25:24.000 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, 00:25:24.000 --> 00:25:26.000 Mm-hmm. 00:25:26.000 --> 00:25:33.000 Um, I think there are some others that implement access units as well, organizations… 00:25:33.000 --> 00:25:35.000 Uh, I can't remember the full list, but um… 00:25:35.000 --> 00:25:38.000 you won't be able to guarantee you're seeing the same result. 00:25:38.000 --> 00:25:43.000 of, you know, just because you share a URL doesn't mean you'll get the same… 00:25:43.000 --> 00:25:44.000 Uh, uh, result list, um, which… 00:25:44.000 --> 00:25:45.000 Yeah. Mm-hmm. 00:25:45.000 --> 00:25:48.000 you know, is… is… 00:25:48.000 --> 00:25:53.000 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. 00:25:53.000 --> 00:25:59.000 Yeah. Sure. 00:25:59.000 --> 00:26:12.000 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? 00:26:12.000 --> 00:26:13.000 I think that, uh… 00:26:13.000 --> 00:26:14.000 Okay. 00:26:14.000 --> 00:26:18.000 Again, I feel like my perspective's maybe not… not a standard library. 00:26:18.000 --> 00:26:20.000 user's perspective, but, like, 00:26:20.000 --> 00:26:28.000 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, um, 00:26:28.000 --> 00:26:37.000 bad for… for what we're talking about. Um, but one of the questions I had was, like, if you have this scenario where you have incompatible 00:26:37.000 --> 00:26:45.000 filters from the URL and from storage. Is there no indication on the facets themselves, like these little Xs that we see? 00:26:45.000 --> 00:26:52.000 So they… they do, and actually, looking more closely at my example from, like, A to B to A to C. 00:26:52.000 --> 00:27:05.000 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. 00:27:05.000 --> 00:27:20.000 But then when that page loads, it grabs the URL filters, it grabs the local storage filters, it sees that 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. 00:27:20.000 --> 00:27:37.000 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 if I go to the URL for tab B, and I copy it into tab C, I expect to see the same thing. 00:27:37.000 --> 00:27:45.000 And I didn't. But again, like, that's that's my expectation as a developer. It might not be the expectation of. 00:27:45.000 --> 00:28:02.000 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. Um, but that I'm looking for consistency that isn't necessarily important. 00:28:02.000 --> 00:28:03.000 I think you're underestimating the number of OCD librarians on this call alone. 00:28:03.000 --> 00:28:13.000 Um, right? So… Well, I'm just… my point is merely like having a system that's completely perfect. 00:28:13.000 --> 00:28:32.000 isn't necessarily the best system. 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. 00:28:32.000 --> 00:28:39.000 to find out is this a problem for you? As someone who uses lots of different applications? 00:28:39.000 --> 00:28:46.000 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. 00:28:46.000 --> 00:28:57.000 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. 00:28:57.000 --> 00:29:11.000 If other people's use of Folio is, I'm mostly just work inside users, I'm 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. 00:29:11.000 --> 00:29:27.000 Maybe as long as those applications behave consistently, that's okay. Even if some group of applications is inconsistent with another's. I… I can just tell you that right now they're not. And so I see that as a rough edge. 00:29:27.000 --> 00:29:42.000 But you know, maybe it's not a rough edge that that bothers other people because they tend to work in a particular domain. I can just explain why that edge is there and what kind of problems I potentially see and help. 00:29:42.000 --> 00:29:48.000 Hopefully, you know, help folks like this group make informed decisions about. 00:29:48.000 --> 00:29:57.000 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? 00:29:57.000 --> 00:30:01.000 I can just tell you what's gonna happen, I can't tell you if it's the right decision or not. 00:30:01.000 --> 00:30:03.000 Laura, go ahead. 00:30:03.000 --> 00:30:10.000 I have a whole bunch of thoughts swirling around in my head, so I'll try to keep track of them. 00:30:10.000 --> 00:30:13.000 I think you are not the only… 00:30:13.000 --> 00:30:23.000 mildly OCD person. And that is also what makes librarians often good at what we do. 00:30:23.000 --> 00:30:30.000 Earlier, I was thinking, I can see myself wanting one type of behavior for myself, 00:30:30.000 --> 00:30:41.000 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 00:30:41.000 --> 00:30:46.000 perspective of it, which I recognize is impossible. So, first of all, I'm saying, okay, 00:30:46.000 --> 00:30:53.000 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. 00:30:53.000 --> 00:30:56.000 And so I think just… 00:30:56.000 --> 00:31:06.000 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 00:31:06.000 --> 00:31:10.000 Which domains somebody might work across, because 00:31:10.000 --> 00:31:26.000 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. Um, so I feel like 00:31:26.000 --> 00:31:27.000 Yeah. 00:31:27.000 --> 00:31:35.000 Having shared… I feel like I want us to go around and find out how important is the shared URL. 00:31:35.000 --> 00:31:43.000 Because my… my assumption, and I could be wrong, but I think that having a URL that 00:31:43.000 --> 00:31:48.000 You can… something you copy and paste, you send it to somebody else, and they can see that exact thing. 00:31:48.000 --> 00:31:50.000 is really, really important. 00:31:50.000 --> 00:31:55.000 And even more so, I think when you think you have that and you don't, 00:31:55.000 --> 00:31:59.000 It really, really confuses and frustrates people. 00:31:59.000 --> 00:32:05.000 And when people are confused and frustrated, they are unhappy and ineffective staff. 00:32:05.000 --> 00:32:09.000 So, um, I feel like 00:32:09.000 --> 00:32:10.000 Yeah. 00:32:10.000 --> 00:32:18.000 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. 00:32:18.000 --> 00:32:22.000 And then figuring out, okay, what… 00:32:22.000 --> 00:32:28.000 Are there… are there improvements we can make to the ability to… 00:32:28.000 --> 00:32:37.000 save filters that don't interfere with that? And if so, what are those? 00:32:37.000 --> 00:32:40.000 I think that's a great way to frame it personally. 00:32:40.000 --> 00:32:47.000 Yeah, everything you've said really resonates. 00:32:47.000 --> 00:32:55.000 And the, uh, the behavior we had for a while when the default for inventory was to not display 00:32:55.000 --> 00:33:05.000 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 00:33:05.000 --> 00:33:09.000 filter was on, they couldn't see it, and people were… 00:33:09.000 --> 00:33:20.000 Live it. 00:33:20.000 --> 00:33:24.000 I was also not personally a fan of that behavior, uh… 00:33:24.000 --> 00:33:26.000 But, you know, like… 00:33:26.000 --> 00:33:34.000 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, 00:33:34.000 --> 00:33:38.000 And I need to be able to see exactly what they're saying in order to fix the problem. So again, I don't… 00:33:38.000 --> 00:33:41.000 No. Charlotte, Charlotte was, uh… 00:33:41.000 --> 00:33:44.000 Ahead of the game there. Um… 00:33:44.000 --> 00:33:50.000 I don't know that that is, like, every… every SIG's top desire, although it sounds like you are. 00:33:50.000 --> 00:33:52.000 on the same team as me, Laura. 00:33:52.000 --> 00:33:57.000 Um, okay, so… 00:33:57.000 --> 00:34:05.000 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… 00:34:05.000 --> 00:34:11.000 create prompts and talking points so that we're all going to the SIGS with the same message. 00:34:11.000 --> 00:34:16.000 But now I'm confused about what that message is, so I don't know how to do this. 00:34:16.000 --> 00:34:20.000 I feel like my first question is, how often do you share URLs? 00:34:20.000 --> 00:34:25.000 How important is it that you be able to copy what's in 00:34:25.000 --> 00:34:27.000 your address bar, and… 00:34:27.000 --> 00:34:30.000 paste that into a message to somebody. 00:34:30.000 --> 00:34:35.000 And have that resolve. 00:34:35.000 --> 00:34:42.000 Not the only question, but I… 00:34:42.000 --> 00:34:48.000 The question is how often do you share URLs for a search? 00:34:48.000 --> 00:35:05.000 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. 00:35:05.000 --> 00:35:06.000 And would that mean that a… 00:35:06.000 --> 00:35:12.000 Functionality, like, click here for persistent URL. 00:35:12.000 --> 00:35:14.000 would be what we were looking for. 00:35:14.000 --> 00:35:18.000 I mean, as one option. 00:35:18.000 --> 00:35:19.000 Uh, yeah. Well, go ahead, Zach. 00:35:19.000 --> 00:35:36.000 No. 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 idea is present. 00:35:36.000 --> 00:35:37.000 is… 00:35:37.000 --> 00:35:47.000 Yeah, I mean, it's just, if I… And I think this is true, right? Like, if I do a filter and I find a record. 00:35:47.000 --> 00:35:59.000 from the filters. That history's all in the URL. 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 what's important. 00:35:59.000 --> 00:36:01.000 Yeah. 00:36:01.000 --> 00:36:03.000 But that's kind of a separate issue, and it's not, like, stopping. 00:36:03.000 --> 00:36:08.000 Yes, yeah, right, because they're… yeah. 00:36:08.000 --> 00:36:10.000 So, like, you could chop off everything… 00:36:10.000 --> 00:36:11.000 From here, and we would get a record. Okay. 00:36:11.000 --> 00:36:14.000 Right, is it… 00:36:14.000 --> 00:36:21.000 Right, because there's… you can imagine lots of different collections of filters would result in, you know. 00:36:21.000 --> 00:36:37.000 101127 being visible. And so, is it… is it there because you search 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? 00:36:37.000 --> 00:36:55.000 Any one of those different collections of filters 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, the problem I'm describing isn't really a problem. If the thing that's interesting to you is the results pane. 00:36:55.000 --> 00:37:04.000 Then you know all the problems I sort of described at the the top of the hour are are present where. 00:37:04.000 --> 00:37:11.000 You might have, you know, different results present, even though you think you got to a consistent URL. 00:37:11.000 --> 00:37:12.000 But… 00:37:12.000 --> 00:37:18.000 But 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. 00:37:18.000 --> 00:37:23.000 But I don't know that we can assume that just because the UUIDs are appearing in 00:37:23.000 --> 00:37:31.000 the resulting URL that you're sending to someone else doesn't mean that the search itself was not the point of the URL. 00:37:31.000 --> 00:37:32.000 Because, like, if you search for something that has only one result, you'll always have these UUIDs. 00:37:32.000 --> 00:37:36.000 Right. Yeah, there's no way to know. 00:37:36.000 --> 00:37:37.000 Right? 00:37:37.000 --> 00:37:43.000 Yep. Yeah, you're right. It's you can't intuit what someone's desired behavior is. 00:37:43.000 --> 00:37:55.000 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 don't know. 00:37:55.000 --> 00:37:58.000 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. 00:37:58.000 --> 00:38:19.000 Mm-hmm. Yeah, um… 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… 00:38:19.000 --> 00:38:32.000 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. 00:38:32.000 --> 00:38:46.000 It's going to… that has, you know, 2 facets in the filter. 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. 00:38:46.000 --> 00:39:01.000 and they click on it, what they're gonna get is A and B, from my results 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 going to get A plus B plus C. 00:39:01.000 --> 00:39:20.000 Which is not what I was trying to send them. I was trying to send them a search result of, you know, the filter with A and B applied, not A, B, C. So that's the kind of… inconsistency that I'm talking about, not where the data changes, but where, when the data is the same. 00:39:20.000 --> 00:39:22.000 Right. 00:39:22.000 --> 00:39:23.000 I see Charlotte wants to say something, and I will say something after Charlotte, because I can't raise my hand. 00:39:23.000 --> 00:39:25.000 the same URL does not show the same results. So… Um… 00:39:25.000 --> 00:39:50.000 Yeah. Okay, because it sounds like listening to this conversation that we want the URL to do something more or less impossible over time. So especially what you mentioned, Zach, if I create the search on Friday and then my colleague has the day off and watch it on Tuesday. 00:39:50.000 --> 00:39:51.000 Mm-hmm. 00:39:51.000 --> 00:40:00.000 Things can have completely changed. So what about that we simply, you know, rethink how to capture the search in the search and filter pane and capture the result in the second pane, the result list? 00:40:00.000 --> 00:40:05.000 Mm-hmm. 00:40:05.000 --> 00:40:15.000 And maybe… so… If I am to share something with a colleague, I decide what is it I want to share with my colleague? Is it. 00:40:15.000 --> 00:40:19.000 how this is set up in search and filters, I want to, or is it the result? 00:40:19.000 --> 00:40:23.000 Yeah. 00:40:23.000 --> 00:40:43.000 For my Given Friday, I want to share with my colleague. So maybe it's, uh, we need, um… came in to do some UX markups on how could we have this, um… capture function, and then that is captured and then shared, because then it would be consistent. 00:40:43.000 --> 00:40:44.000 I don't know the technical solution, but uh… Yeah. 00:40:44.000 --> 00:41:11.000 Yeah, I… Yeah, so I… 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? 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. 00:41:11.000 --> 00:41:24.000 Uh, and then if you want that list to get refreshed, you have to say, hey, go refresh this thing. That's… That is one way of doing this kind of thing, and it can make canned searches super fast. 00:41:24.000 --> 00:41:33.000 Um, because if you have, you know, a thousand things in your, in your results set, it has those thousand UUIDs and it can just retrieve them by ID. 00:41:33.000 --> 00:41:37.000 Retrieval by ID is always very fast, because that's always an indexed field. 00:41:37.000 --> 00:41:58.000 So, but it's a very different way. 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… 00:41:58.000 --> 00:42:19.000 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… From my point of view, right now. 00:42:19.000 --> 00:42:24.000 borders is more of an outlier in terms of how. 00:42:24.000 --> 00:42:39.000 It's URLs function. 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 it's result sets. 00:42:39.000 --> 00:43:06.000 function compared to most other things. I think lists has sort of been presented as… 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. 00:43:06.000 --> 00:43:18.000 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. 00:43:18.000 --> 00:43:37.000 customizability on top of that default behavior, so that if you want to, you know, 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. 00:43:37.000 --> 00:43:47.000 Um, or as you said, um… You know, do we want other applications to reflect lists? 00:43:47.000 --> 00:43:54.000 my inclination is that we probably don't want to do with most applications what lists does. 00:43:54.000 --> 00:44:02.000 But that's definitely not a developer question. That's a get get that feedback from users, and then. 00:44:02.000 --> 00:44:15.000 figure out what they want. Um… But based on how most applications are developed so far, I don't think that's the route we would end up going. 00:44:15.000 --> 00:44:19.000 Kristen? 00:44:19.000 --> 00:44:43.000 Yeah, I think you bring up an interesting point about how lists could be used for some of these things, too. Um, I mean, this could be a question that we ask people. My assumption has always been, if you… share a URL that has filters on it, and somebody else goes and uses that. 00:44:43.000 --> 00:44:44.000 Yeah. Mm-hmm. 00:44:44.000 --> 00:44:54.000 that that search is going to 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. Um, so if somebody's like, we need to see how many, you know, pending orders we still have. 00:44:54.000 --> 00:44:59.000 Right. 00:44:59.000 --> 00:45:04.000 Yeah. Yeah. 00:45:04.000 --> 00:45:05.000 Yeah. 00:45:05.000 --> 00:45:22.000 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, like, not have that be current. Like, that would be… Um, 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 LIS app to do that, and maybe there are ways, if you need to go in and check on things that are. 00:45:22.000 --> 00:45:23.000 Mm-hmm. 00:45:23.000 --> 00:45:35.000 difficult to set up as a query, because you're trying to provide a lot of filters, or… you know, that's more of a… that does sound more reporting to me than, um… some of the operations, where you always want to have the most current data that's out there. 00:45:35.000 --> 00:45:37.000 Yeah. 00:45:37.000 --> 00:45:43.000 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. 00:45:43.000 --> 00:45:54.000 Um, 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 wild card, 00:45:54.000 --> 00:46:00.000 In this current, uh, system, you would end up with a record in your URL. 00:46:00.000 --> 00:46:07.000 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, 00:46:07.000 --> 00:46:14.000 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. 00:46:14.000 --> 00:46:16.000 like, they were trying to send you a search, which is such a tiny point, and not that important. 00:46:16.000 --> 00:46:17.000 Mm-hmm. 00:46:17.000 --> 00:46:20.000 No, I think that was it, and I've talked enough, so… 00:46:20.000 --> 00:46:24.000 Oh, and sorry. 00:46:24.000 --> 00:46:25.000 I think that's quite an interesting 00:46:25.000 --> 00:46:30.000 point at Taro isn't one that I'd considered, um, 00:46:30.000 --> 00:46:32.000 And yeah, it definitely… 00:46:32.000 --> 00:46:34.000 definitely suggests to me that 00:46:34.000 --> 00:46:39.000 having persistent URLs for searches and records. 00:46:39.000 --> 00:46:44.000 Clearly accessible in the UI that users can then… 00:46:44.000 --> 00:46:49.000 use makes a lot of sense to me, I have to admit. Like, rather than just relying on them. 00:46:49.000 --> 00:46:54.000 copying and pasting from the address bar, which feels like it's always going to be dicey. 00:46:54.000 --> 00:46:57.000 Um… but, um… 00:46:57.000 --> 00:47:01.000 Now, if I remember what I was gonna say. Uh… 00:47:01.000 --> 00:47:03.000 So I… I think that… 00:47:03.000 --> 00:47:09.000 Tara, you said you weren't sure what we were asking. 00:47:09.000 --> 00:47:12.000 the SIGs at this point. 00:47:12.000 --> 00:47:14.000 And I… but I think that… 00:47:14.000 --> 00:47:17.000 like… 00:47:17.000 --> 00:47:19.000 this issue of, like, 00:47:19.000 --> 00:47:21.000 applying… 00:47:21.000 --> 00:47:27.000 Like, having a set of filters that are applied by default, or that persist between sessions, and… 00:47:27.000 --> 00:47:33.000 highlighting the behavior that we've talked about today, and the, you know, 00:47:33.000 --> 00:47:38.000 when that can go wrong, or whether that is going wrong from their point of view, when 00:47:38.000 --> 00:47:41.000 when they either use 00:47:41.000 --> 00:47:44.000 sessions in multiple tabs, or they… 00:47:44.000 --> 00:47:46.000 have a shared URL. 00:47:46.000 --> 00:47:49.000 somebody sends me a URL of this type, 00:47:49.000 --> 00:47:53.000 it kind of feels like highlighting that behaviour 00:47:53.000 --> 00:47:57.000 Because, actually, most… I think most applications don't do this, right? So… 00:47:57.000 --> 00:48:02.000 We really are saying, actually, in orders, this is what happens. Um… 00:48:02.000 --> 00:48:08.000 And in, you know, whatever other application, this is what happens. 00:48:08.000 --> 00:48:11.000 And… just trying to get… 00:48:11.000 --> 00:48:14.000 the different SIGs to say, well, 00:48:14.000 --> 00:48:18.000 you know, persistence would be good, but, you know, only if it works in this way, or… 00:48:18.000 --> 00:48:23.000 Um, for orders, you know, for the acquisition SIG to say, 00:48:23.000 --> 00:48:32.000 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… 00:48:32.000 --> 00:48:34.000 that… 00:48:34.000 --> 00:48:38.000 you know, we should still try and understand… no, it wasn't Nora, I can't remember who said it. 00:48:38.000 --> 00:48:41.000 their requirements at this point, and… 00:48:41.000 --> 00:48:43.000 Um… 00:48:43.000 --> 00:48:45.000 And… almost… 00:48:45.000 --> 00:48:48.000 not necessarily not worry about what's possible, but 00:48:48.000 --> 00:48:51.000 But then have this discussion again once we kind of understand… 00:48:51.000 --> 00:48:55.000 what are those things that they really would like to see? Because… 00:48:55.000 --> 00:48:58.000 Yes, some things will be impossible, but… 00:48:58.000 --> 00:49:04.000 Um, or at least, you know, it's not easy necessarily to have things work in two different ways simultaneously. 00:49:04.000 --> 00:49:07.000 Um, but um… 00:49:07.000 --> 00:49:11.000 I think that, like, if we can… 00:49:11.000 --> 00:49:18.000 take this session and boil it down to, this is the behaviour we currently see in, say, 3 different apps, and when you, you know, 00:49:18.000 --> 00:49:25.000 When you use them normally, as it were, when you use them in multiple tabs, when you use them to share URLs, 00:49:25.000 --> 00:49:29.000 like, and get their feedback on what's good and what's bad about those. 00:49:29.000 --> 00:49:32.000 then perhaps that would be a way of 00:49:32.000 --> 00:49:35.000 asking the question, I suppose, without necessarily kind of saying… 00:49:35.000 --> 00:49:38.000 you know, what is it you want, which is always… 00:49:38.000 --> 00:49:41.000 difficult for people to answer. 00:49:41.000 --> 00:49:45.000 Um, directly like that. 00:49:45.000 --> 00:49:55.000 Yeah, that's part of what I was trying to get at with my… somewhat convoluted example, but you know, maybe if I can try to distill that, I guess, in a little bit more. 00:49:55.000 --> 00:50:09.000 And so what I was trying to present was, here's what happens if you go through these steps. Is that behavior okay with you? 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? 00:50:09.000 --> 00:50:20.000 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. 00:50:20.000 --> 00:50:36.000 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, you know, inadvertently gone through the same steps that I did. 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. 00:50:36.000 --> 00:50:53.000 Um, and so… 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. 00:50:53.000 --> 00:51:13.000 Apps various people use or don't use. Um… So again, it's I… I think what you just said, and what what Hera has 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… 00:51:13.000 --> 00:51:31.000 Um… 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. 00:51:31.000 --> 00:51:57.000 find out what people think about those different situations, and maybe that'll lead toward, um… finding the common ground 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. 00:51:57.000 --> 00:52:06.000 That there's more to discuss, um, before we can pursue a particular solution. 00:52:06.000 --> 00:52:07.000 I think there… 00:52:07.000 --> 00:52:16.000 is also a desire, in some cases, to explore the possibility of having more persistent filters in other apps. 00:52:16.000 --> 00:52:22.000 And so I think this is an opportunity to find out, is that something that's desired, but also, at the same time, 00:52:22.000 --> 00:52:30.000 be very clear, okay, this is… these are side effects of persistent filters. 00:52:30.000 --> 00:52:33.000 If… so, if… 00:52:33.000 --> 00:52:36.000 you know, if this is a deal-breaker, then we know we can't… 00:52:36.000 --> 00:52:51.000 do that. Um, or we know it would be a lot of work to do that. Um, and I… 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… 00:52:51.000 --> 00:52:55.000 I really think people want a mind-reading app. 00:52:55.000 --> 00:53:06.000 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. 00:53:06.000 --> 00:53:07.000 Um, but just surfacing the, you know, reminding people, we can have… that… that… 00:53:07.000 --> 00:53:12.000 Yeah. 00:53:12.000 --> 00:53:16.000 a program can behave in one way. It can't… 00:53:16.000 --> 00:53:21.000 change its mind when… when it knows you working on something else, or… because, I mean, in a way, that's, to me, what a… what 00:53:21.000 --> 00:53:23.000 Mm-hmm. 00:53:23.000 --> 00:53:31.000 being able to have these filters is one way of, okay, when I'm working in this capacity, I only want to see these things. 00:53:31.000 --> 00:53:32.000 Well, okay, here's the cost of that. 00:53:32.000 --> 00:53:48.000 Mm-hmm. 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. 00:53:48.000 --> 00:54:06.000 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. 00:54:06.000 --> 00:54:23.000 apply this filter shortcut to my current result set, and would that be a way of… 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 to load different collections. 00:54:23.000 --> 00:54:30.000 That's definitely, I think, something that would be interesting to explore, so that the shortcut is the thing that gets persisted. 00:54:30.000 --> 00:54:58.000 Um, rather than… 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, um… back-end storage in an API, because again, like, right now. Maybe if you work at the same computer every day you're not going to notice a difference between those 2 things. But anybody who might rotate across workstations or something like that. 00:54:58.000 --> 00:55:06.000 It could be advantage… advantageous to be able to log into any workstation and have your personal filters applied. 00:55:06.000 --> 00:55:17.000 to the result sets, but I don't know how often that happens or not, and so it might be that I'm sort of inventing work there. 00:55:17.000 --> 00:55:36.000 Local storage to me is just a… 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. 00:55:36.000 --> 00:55:41.000 Folio recognized you as you, and would have loaded that same profile anywhere else. 00:55:41.000 --> 00:55:53.000 Um… 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. 00:55:53.000 --> 00:56:11.000 Um, so it… local storage, I think, just has a lot of those sort of gotcha moments. Um… And that's what has, uh… If you hear me sort of, like, pushing back against it, that's where that's coming from. 00:56:11.000 --> 00:56:21.000 Um, okay, uh, 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. 00:56:21.000 --> 00:56:23.000 Hi, Sarah, I want to say… 00:56:23.000 --> 00:56:27.000 Yeah, I agree with you and Zach on the filter shortcuts. 00:56:27.000 --> 00:56:29.000 I think it's a nice idea. 00:56:29.000 --> 00:56:34.000 And honesty makes more sense to me, but then I also see, like, 00:56:34.000 --> 00:56:40.000 For some users, that… if that resulted for some users in them having to do that every time, or… 00:56:40.000 --> 00:56:45.000 very often they hit the screen, then… then that would be uncomfortable for them, so I… 00:56:45.000 --> 00:56:49.000 I definitely, um, can see 00:56:49.000 --> 00:56:51.000 that is a potential issue. 00:56:51.000 --> 00:56:58.000 I also want… I think Zach's point about… I mean, we talked about this personalization, 00:56:58.000 --> 00:57:03.000 the fact that local storage is used at the moment for some aspects of this 00:57:03.000 --> 00:57:05.000 Personalization, 00:57:05.000 --> 00:57:09.000 That includes, I think, the columns that 00:57:09.000 --> 00:57:10.000 are used in certain MCLs as well. 00:57:10.000 --> 00:57:14.000 it's definitely not great. 00:57:14.000 --> 00:57:15.000 from, like… 00:57:15.000 --> 00:57:16.000 Yeah. Yeah. 00:57:16.000 --> 00:57:18.000 I think… 00:57:18.000 --> 00:57:25.000 I think these are things, and I guess, you know, again, this is something we could ask users, but I… my impression is that 00:57:25.000 --> 00:57:29.000 When we talk about things like persistent filters or, you know, 00:57:29.000 --> 00:57:35.000 filters that… default filters that users want to see, or which columns they want to see in the results, 00:57:35.000 --> 00:57:37.000 Generally, 00:57:37.000 --> 00:57:40.000 it would be… they want that to follow them. 00:57:40.000 --> 00:57:45.000 They don't really care which computer they're working on, or which browser they're working in. 00:57:45.000 --> 00:57:46.000 Yeah. 00:57:46.000 --> 00:57:55.000 those are still rational choices. They've not set it up, they've not generally working, like, oh, I use a Firefox session for this task because I've got one set of things set up, and 00:57:55.000 --> 00:57:59.000 crime for another, because I've got the other set up. They… they just wanted to… 00:57:59.000 --> 00:58:00.000 be consistent across 00:58:00.000 --> 00:58:01.000 Mm-hmm. 00:58:01.000 --> 00:58:06.000 what they do, and once they set it up, they don't really want to lose those settings. 00:58:06.000 --> 00:58:09.000 Um, except explicitly, you know, 00:58:09.000 --> 00:58:11.000 Um, so… 00:58:11.000 --> 00:58:14.000 I do think that… 00:58:14.000 --> 00:58:17.000 Since we now have some profile stuff, 00:58:17.000 --> 00:58:19.000 Starting to creep into… 00:58:19.000 --> 00:58:29.000 folio, it… it's, you know, that discussion is worth having as well. 00:58:29.000 --> 00:58:33.000 I'm sure someone has a response to that. However, uh, it is 00:58:33.000 --> 00:58:43.000 1258, where I am, and I have a meeting, uh, 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, um, 00:58:43.000 --> 00:58:49.000 And possibly some… some homework, uh, to the channel over the next couple of days, okay? 00:58:49.000 --> 00:58:50.000 Awesome. 00:58:50.000 --> 00:59:03.000 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. 00:59:03.000 --> 00:59:07.000 In a way that makes it easier to digest, so that we can see what the trade-offs are. 00:59:07.000 --> 00:59:16.000 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, um, and we'll talk to you later. 00:59:16.000 --> 00:59:17.000 Bye! 00:59:17.000 --> 00:59:20.000 Bye