[{"data":1,"prerenderedAt":439},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"request-review-inline-data-editor":121,"request-review-inline-data-editor-next":166,"sales-reps":187},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":8,"people":128,"episode_number":138,"published":139,"title":140,"video_transcript_html":141,"video_transcript_text":142,"content":8,"status":143,"episode_people":144,"recommendations":145,"season":146,"seo":8},"b63afbe1-6418-4e9e-b1da-4890979789f0","inline-data-editor","926603960","In this recording of our live event on March 21 2024, Rijk, Jonathan, and Daniel discuss inline editing.","db868174-6a9e-4823-9962-382f5bd55cb1",52,[129,132,135],{"name":130,"url":131},"Rijk van Zanten","https://directus.io/team/rijk-van-zanten",{"name":133,"url":134},"Jonathan Wagner","https://directus.io/team/jonathan-wagner",{"name":136,"url":137},"Daniel Biegler","https://directus.io/team/daniel-biegler",5,"2024-03-28","Inline Data Editor","\u003Cp>Speaker 0: Hello, everybody. Welcome to feature request review with me as a host today, joined by the good old Reich, Van Zanten himself and Jonathan Wagner. Hello. Hello, everybody. Thank you for coming.\u003C/p>\u003Cp>Very exciting to see you all. Quite quite the quite the collection of people we have here from Algeria, Japan, everywhere. Germany, Austria. No. No.\u003C/p>\u003Cp>No. I nearly said it. But, yeah, today today, everybody's, apparently favorite topic because there's so much demand here in the channel right now. Inline editing, which can mean a lot of things. So let's just take a look at what a small example could look like.\u003C/p>\u003Cp>If you take a look at the screen shared footage of Jonathan, you'll see this is our feature request that got in, which you can vote on, by the way, in case, some people are not aware of this feature in our discussions in the director's repository. You may vote on stuff that gets implemented into the software, which is pretty cool. And, today's topic is about inline editing. If we scroll up a little bit to the top to the screenshot, you might have seen this in other interfaces online, you know, when you use Notion or whatever, like, many many sites implement this a little bit differently. You know, on Trello boards, you can click into the title, then you can change the title right then and there without a pop up or something.\u003C/p>\u003Cp>And, yeah, why why doesn't have direct as this yet? It's a good question. I mean, there are many, many different things that we could talk about. And, in case you have any questions or stuff that you want to share, please feel free to use the chat. We're excited to engage with you guys.\u003C/p>\u003Cp>It would be fun, a sign of life like previously. That would be nice. And how about how about we jump in right into a couple of questions? Let me quickly, give one second. Alright.\u003C/p>\u003Cp>So by looking at this, you know, basic example with the with the input field, I mean, the the first question to me is, alright. Like, how how much can we blow this up to, because Directus is very, very versatile, and, people build the craziest displays and interfaces and very, very customizable different pieces. How do they fit into this, and if we just target, like, simple inputs, for example, like in these simple example with, like toggles or text inputs. What about relations? Because those tend to be very nice to deal with.\u003C/p>\u003Cp>And, how about we go over to give over to Rijk for this one? How do you feel about different types of inputs for inline editing? Do you think we should, like, aim to be able to do everything in in in line editing? Should we reduce it down? Should we only support a sub set?\u003C/p>\u003Cp>How do you feel about inline editing in itself?\u003C/p>\u003Cp>Speaker 1: I mean, when it comes to inline editing, I think the first question that we gotta ask ourselves and everybody watching is like, what does that even mean in the first place? Is it kinda like a spreadsheet where everything is just a cell where you can change whatever you see? Is it more like, a table view by default where everything looks pretty through those displays, And then you have some sort of edit state. Is it like, an edit state where we render a whole interface in line? Or is there some sort of dialogue overlay that we're seeing when you click on one of the cells, so to speak, to to stay in spreadsheet terms.\u003C/p>\u003Cp>So I think the first question really is what is what is inline editing? What does it even mean? Right? Because we do have a different feature request for a spreadsheet view, which I think very closely overlaps, but there's definitely differences. And then I think the other question, of course, I mean, relationships, we'll dive into that in 5 minutes.\u003C/p>\u003Cp>But, if you think about the basics, I think one of the thing that we're doing with direct is with all the interfaces is to make sure that you can edit the data in a way that makes sense for what the data is. Right? So, a very basic example, you know, a slider could be a better representation for a numeric value that you're using for whatever it is that you're building. Right? But You wanna use a slider to control the value.\u003C/p>\u003Cp>When it comes to inline editing, you know, if we're looking at this screenshot where the reserve column right now presumably is in this edit state, you know, if we're dealing with inline editing in its sort of truest form, does that mean that it just turns into a sort of raw value input? Or do we include interfaces kinda like we are with a regular form? Right. So when it comes to a date value to name something, the technical value is always gonna be that that what's the exact spec, the, ISO 8601. Is that the thing that you wanna be editing?\u003C/p>\u003Cp>I would argue, probably not. You probably wanna have, you know, the data interface that you have configured for that field, which then leads to the question, does that even fit wherever we're doing this inline editing presumably in this table layout. Right? And I think we're we're quickly reaching the question then is like, okay, do interfaces even fit? And if they don't, how do we present it otherwise?\u003C/p>\u003Cp>Speaker 0: Right? Yeah. To your example, like, even even a simple slider, which is a nice way to input, like, a specific value inside of a range, which could be, you know, like, relevant to the use case, you know, where you want to restrict. You maybe you don't allow, like, negative numbers or something. But if if we allow, like, editing via raw values, then somebody might put in, you know, minus 1 or something, and then you very quickly run into the issue that you mentioned.\u003C/p>\u003Cp>We want to give people the tools to, like, input stuff as as as comfortably as possible with using, like, nice interfaces and displaying like, even displaying, you know, with with the value that you see inside of the table might, like, might not actually be the wrong value just like you described with the, like, date time, for example. So there's a disconnect there and, like, for, like, nontechnical users, for example. No. It could be it could feel bad, you know, from a user experience standpoint where they like if if marketing salespeople, what what was the thing that's, somebody said I won't name any names, but somebody said, like, the scariest thing that marketing people see is, like, a UUID somewhere. So we're dealing with UUIDs.\u003C/p>\u003Cp>Yeah. It is, is a scary endeavor, so you have to be quite careful with the display. So yeah. Yeah. Speaking to that, we have why don't we explain a little bit about the difference between our interfaces and displays?\u003C/p>\u003Cp>Because, you know, indirect is also 2 different things. What are those? How do I use those? What can they do?\u003C/p>\u003Cp>Speaker 1: Good question. So so from I'll I'll prefixes was sort of the theoretical idea behind it while Jonathan here pulls up the actual difference and how you configure them. So the basic idea is that a display, controls how a raw value is displayed in line, importantly. So it's really meant to be part of a sentence or one of the cells in a table or, you know, part of a description or something. So if you think about a, labels display, it can be configured to render it as a small color dot with a tooltip, with the idea being you can then render that in the title of a page, or in the description of a card or inside of a table.\u003C/p>\u003Cp>Right? The interface is really the the way you edit the value. So if you go and you open an item, it's basically the form field, section of of how you interact with that data. So it's really the difference between sort of block level, in CSS terms, editing of the data versus inline displaying of that same data. Importantly, those 2 can be very different representations of the same data.\u003C/p>\u003Cp>Right? So the image display will just be a tiny thumbnail where an image interface is like a bigger box where you can drag and drop stuff in and you have, like, preview and some more metadata available. They are at present a different thing. And the display is then Yeah. So so Jonathan right now is, you know, adding, a related values you know, those displays, and compose them all together to really control how an individual item is presented.\u003C/p>\u003Cp>Right? So on the collection detail page 2, there is a display template setting where, again, you can render individual fields as part of one title string. And then that's how it displays the individual pieces of data. So when it comes to editing them in line, one of the interesting, challenges that we're gonna be facing when it comes to the table layout specifically is that the value that you're seeing in here, it's very likely that that's not the value that you're gonna be editing. Right?\u003C/p>\u003Cp>Speaker 2: And is it a toggle? Is it something that you enable or disable? If you haven't enabled, what happens? If you don't have an enabled or how do I access the record? Because currently, you know, I just know that I can just click anywhere on the row, and it will open the item for me, and I can edit the item.\u003C/p>\u003Cp>How do we trigger, you know, you start to get into that. So we've got the whole interfacing aspect, relational content, allowed or not allowed. It feels like at least maybe you could almost do it in, like, an iterative. So start with the normal input fields, date fields, the the simpler interfaces and things to deal with versus relational. Relational gets complicated, right, depending on how deep or how complex that relational is.\u003C/p>\u003Cp>Now in order to edit this translation, well, that requires now that I get the full translational split toggle side by side translations kinds of things, and is that beneficial in this kind of a in this kind of utility? Yeah. Toggles, drop downs, you know, some of this, some of the more string text slash\u003C/p>\u003Cp>Speaker 1: Is this is there there is a a another additional question when it comes to how do we then render an interface to change the data, which is that there's gonna be a couple of them where the interaction would be way nicer if it's, like, truly in line. Like, so if we, if you think about a toggle, like a checkbox. Right? Kinda like the default checkboxes for selecting items. But let's say you have, you know, an on or off state on your own custom item.\u003C/p>\u003Cp>In your display, ideally, I just wanna click it and it flips. I I don't wanna click it then open a dialogue that shows me just one toggle anyways, and then close it, and then change it that way. You know what I mean? And I think the same goes for basic text values or basic numbers where I just wanna be able to click the text, edit it, and then that's it. Right?\u003C/p>\u003Cp>I don't wanna have to deal with clicking it, seeing a popover, drop down dialog, whatever it may be, then change it there because it's just another step away for something that feels like it could have been a spreadsheet, basically.\u003C/p>\u003Cp>Speaker 2: Yep.\u003C/p>\u003Cp>Speaker 0: With that example, you know, with just clicking in and changing something, Tim also brought up a nice point because, with nullable values, like, even such a simple thing as a, like, togglable checkbox, if that is even a word, you know, we already run into, like, a small little, thing, like, okay, what if you want to set it to null? You know? Like, if you uncheck the thing, it's false, but you want it to be null. Do we do we, you know, do we, like, enable triple, like, stateful checkboxes that support 3 values? Do we want to have, like, a ellipse that gives you, like, a setting for that?\u003C/p>\u003Cp>Like, similar to our v form where, you know, you're allowed to enter a raw value, but that's another piece of UI that would have to be somewhere some at some point. Yeah. Exactly. For strings, similar in that vein, you know, for strings, do you want a, empty string, or do you want a null value? Alright?\u003C/p>\u003Cp>How do you differentiate between those?\u003C/p>\u003Cp>Speaker 1: And it can even differ,\u003C/p>\u003Cp>Speaker 0: you know, from from to\u003C/p>\u003Cp>Speaker 1: Yeah. All of those are problems that we have solved in the form context. Right? Because even in the form, there's just the field label drop down that says empty this value, which is effectively nullifying it. So the question is also how much of that do we wanna pull a level up in here versus how much of that do we just say oh well if you explicitly wanna change a boolean back to a null, you can always go to the page detail thing and then do it there.\u003C/p>\u003Cp>Right? There is an escape hatch, and we could make the call to say, well, you know, the toggle display goes between true and false. And if you need to reset it back to that null state for whatever specific reason, you can always go to the detail page, and do it there. Right? And I think similarly for the string empty update, empty string, null, that that question is a question that we've currently solved on the interface settings, I believe.\u003C/p>\u003Cp>Therefore, an input interface, you can say empty string becomes null, and then that's just the value it, you know, stages, it emits. So if we go the route where we use the exact same interface you have already configured as the way to edit it in line, that problem should sort of automatically be solved. Right? Because we're using the same interface with the same settings, and then that should be fine as is. Where that part gets super interesting though, is how do we deal with conditional fields within the context of that row?\u003C/p>\u003Cp>So the way conditional fields currently work is, you know, you have the whole form of on the field, you have the whole form on the page, and then we can use the values of the form and sort of connect the dots. Right? And use it that way. On a row in a table though, the fields that are displayed might be completely different. The second piece to that is gonna be for conditional fields.\u003C/p>\u003Cp>They're now react reactive in real time where if you make a change to one field, sort of real life like, real time updates it elsewhere. When you're in the context of an individual row, and I think this is just a bigger question overall, is, like, does it auto save every time you sort of blur the input that you change something in? Or is there gonna be a save button that is like, okay. Now you've made all the changes and you hit save once.\u003C/p>\u003Cp>Speaker 0: That's a very good question. Like, especially for, like, the togglable checkboxes or whatever because, like, if you just miss click somewhere and all of a sudden, that could be a big change, you know, like with flows and automations and other stuff that runs or update events, fire something. If you hit publish on something, that should be, there should be a mechanism, you know, to stop making mistakes, you know, like, accidentally, if you have, like, you know, is active or is published field on some type of blog post or whatever, and you don't want to accidentally just oops. Oops. It's live now.\u003C/p>\u003Cp>Oopsie. Would would be nice if we could avoid that, but, yeah, that opens up another can of worms. You know? Like, how do we do you configure this on a field level? Do you configure this on a column level, on a, preset level?\u003C/p>\u003Cp>Like, where where do you where would you like to do that? That's also the thing. Because very good point from the chat also from the, is currently, for example, the displays do not know, like, which item they belong to. They are very stupid in that way with quotation marks where they just Yeah. Display a value.\u003C/p>\u003Cp>This is why they're called displays.\u003C/p>\u003Cp>Speaker 1: It's it's a presentation, presentation layer. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 0: So if if we would like to have the, you know, like, mutable, displays or whatever, you know, if we decide to go that down that road. So, we would have to provide the displays with the item ID in the collection, like, in every place because there's not not only displays only in the table view, in the tabular layout, but also in, like, titles and drop downs or whatever. Like, any and they could be at any place at any time, which makes this a little bit, dangerously spaghettty like, which\u003C/p>\u003Cp>Speaker 1: which which also, kind of bleeds into a similar yet different question, which is where do we allow inline editing in the first place? Because we're assuming we're sort of assuming the table layout right now because that's the most commonly seen elsewhere. I mean, I'm I'm sure that people that have ever seen Airtable are like, that's that's the way. But at the same time, the the question is, do we inline edit elsewhere? Like, if you have a status icon in your page title, does that become an inline editable thing?\u003C/p>\u003Cp>Right? In the chat somebody says we'd appreciate it for the card layout, maybe even the calendar. I would agree. So on the card layout, if you have in your description of an individual card, you have a a text display. If you click the description, can you now edit the description of a card in line, which opens up a big can of worms, especially from a UX design perspective.\u003C/p>\u003Cp>Speaker 2: I I guess because because we're we're concatenating that into a string in the display right now for a card. Right?\u003C/p>\u003Cp>Speaker 0: Mhmm. Mhmm.\u003C/p>\u003Cp>Speaker 1: So if we're just The same for page titles for the for for that matter or the calendar layout. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 0: And Tim, Tim, another fun, fun little thing that could happen if you're already editing something and you have auto refresh enabled. Somebody updated your stuff in between the edits, and now you have another edge case. Love it. Love it. Love it.\u003C/p>\u003Cp>Love it.\u003C/p>\u003Cp>Speaker 1: Which is gonna be the same issue that you have with, you know, the regular form. So I'm hopeful that whatever solution we come\u003C/p>\u003Cp>Speaker 2: up with that right now.\u003C/p>\u003Cp>Speaker 1: Yeah. Exactly. Whatever solution we come up with for that, I'm sure the same solution should also then work here. But Yeah. For this So this is a good example in the cars layout.\u003C/p>\u003Cp>Right? So in that right side bar, you see title, subtitle, and you can configure any combination of the different fields with any sort of additional strings in between, for like adding a dollar sign in front of price. That kind of stuff. Right? So in this particular case, it becomes extra interesting.\u003C/p>\u003Cp>Because if you now were to click on the number of the price in that description line, do you expect it to be editable? Right? And how do you determine that? Yes or no? Because making every editable globally at all times feels like a UX nightmare waiting to happen, but it also unlocks a lot of flexibility.\u003C/p>\u003Cp>Right? So it's a tricky one as many things are.\u003C/p>\u003Cp>Speaker 0: Of course. So how about how about then we take a different look? So now we thought about tables and the current layout and whatever. Technically, there's also another option of adding a new layout, like you mentioned earlier, with the spreadsheet layout, which could be the point where you do that type of stuff. I don't know.\u003C/p>\u003Cp>Maybe, you know, I'm just, you know, throwing stuff in the room right now just to discuss a little bit. But Yeah.\u003C/p>\u003Cp>Speaker 1: Because it does have the mute display thing. Yeah.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. So maybe if it turns out to be better or easier or whatever, the spreadsheet layout could be an interesting point where we could tackle this, but, then we have new, cans of worms and cans and of worms stacked upon each other, you know, till this evening.\u003C/p>\u003Cp>Speaker 1: Stack a can.\u003C/p>\u003Cp>Speaker 0: Which which is fun. Yeah. Because, you know, a spreadsheet layout people come into a spreadsheet layout with lots of preconceived notions. Is that the is that the word? And\u003C/p>\u003Cp>Speaker 1: Like, I think expectations is the word I would say. Yeah.\u003C/p>\u003Cp>Speaker 0: Expectations. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Expectations and and stuff that they would like to have or that they expect to be there because it's, you know, spreadsheets are, daily used by billions of people. So they do want to have, like, conventions and keyboard navigation and different stuff that they already, you know, introduced to the day to day life with bulk renaming, whatever formulas. Maybe they think that this is then an actual spreadsheet that they can do calculations in, which is another cool feature that we would like to have probably from\u003C/p>\u003Cp>Speaker 1: different feature requests for a different day. Yeah.\u003C/p>\u003Cp>Speaker 0: Exactly. Exactly. Exactly. So spreadsheet seems to be a very big thing, for me personally. Yeah.\u003C/p>\u003Cp>Speaker 1: I think to me it's just a very different thing, isn't it, than than this inline editing approach that we're talking about? Because I fully agree with what you're saying. If you close your eyes and you think spreadsheet, there's a whole set of rules that come with that. That if you miss one of them, you have a bad spreadsheet. Right?\u003C/p>\u003Cp>Because if you look at Excel versus Google Sheets versus Excel on the web or even Apple's, what they call it, numbers, they are all effectively identical in the exact same settings, exact same thing you can do. It's a right or wrong approach. So, funnily enough, for a session like this, it would be a very short call because it's like spreadsheet. It's basically a known entity at that point. Right?\u003C/p>\u003Cp>I think where it gets interesting to me, and this is sort of the the the Airtable spreadsheet equivalent. It's like, you're not dealing with the spreadsheets. You're dealing with a table that you can edit in line. But it's not a pure spreadsheet in the technical term, right, where you're dealing with cells with raw values, so to speak, rather than UI elements where you edit the values. Yeah.\u003C/p>\u003Cp>Same thing in the chat was was coined there. The reason why I immediately started thinking about okay. So our display is now editable as a concept is basically from that modular fashion. Right? Because making one new layout that does inline editing sure.\u003C/p>\u003Cp>We could totally make that happen. We could also make it an option of the regular table layout and then that's it. Right? To me the interesting question for this is really like, is there a way to make it work for any display anywhere? And is that something that we wanna do or not?\u003C/p>\u003Cp>Because by doing so, you get the tabular layout feature out of the box but you also unlock it elsewhere. Like, if you have, a list of one to many items on, a record, each of those one to many items now also has inline editing because they are using displays to render those values. Right? So it it just, like, it transforms this discussion from an inline table editor to a bigger sort of, like, what does that editing in situ look like across the board?\u003C/p>\u003Cp>Speaker 0: Very, very good question. I wish I would have the answer to it, but, yeah, like you said, I mean, for for for example, for the, like, relational stuff, I could see, you know, reusing the existing drawer that pops up in different places, which could be a nice experience. You know, if you let's say you have a, a website collection with blog posts or something, articles, whatever. And as the drawer opens and you can use the currently already existing, like, relations go through the list, it it's it's with pagination and stuff. That could be nice.\u003C/p>\u003Cp>But like you said earlier, if for smaller fields, it feels like add UX if you, you know, just want to change one text and then the drawer opens or, like, a pop up opens with just one input. That's, like, at that point, it just feels very not thought through, which I would like to avoid. Yeah. We got correlate with this PR. Yeah.\u003C/p>\u003Cp>Yeah. Yeah. The the batch editing is also a nice thing. So slightly different.\u003C/p>\u003Cp>Speaker 1: There's also the the, the bigger question here, Which is\u003C/p>\u003Cp>Speaker 0: As it always is?\u003C/p>\u003Cp>Speaker 1: As it always is. But it's that's that's what these sessions are. For those who are new, in these sessions, we always go find all of the edges and then take it back into what is actually realistic in the next step. But so think about it. If if we're now dealing so so you we explained it before that the displays were meant as a presentational only unit and interfaces are meant as an editable unit of the same value.\u003C/p>\u003Cp>Right? But now we're saying: What if displays are editable, but only at sometimes? So some displays like a string we wanna make inline editable, Some displays like a checkbox inline editable. And some like a relational related values or something we wanna have a click with some sort of dialogue to to have the space to make it a proper editing experience. Right?\u003C/p>\u003Cp>The question could also be, should those still be 2 separate entities or should they all be interfaces? And based on how we where we're rendering an interface, it can display in different ways. Right? So if you have an interface on a form where it has enough space to grow, it can show as a proper big input. But if you try to squash it into a cell of a table, it just drops the visual representation of an input and becomes one of those underline only in inputs for example.\u003C/p>\u003Cp>Right? Because then with a read only prop, yes or no, you can toggle between a string that's just rendered as a string. Or when you click it, it switches into this inline interface version, basically. Know what I mean? Because then for a display one, it can always just be interactive for an input, you can just click to start typing for, a related values one or a relation when you can click it and it would just do it in a pop over or dialogue or something along those lines.\u003C/p>\u003Cp>Speaker 2: So depending on the interface type or the interface implementation, you could allow or disallow inline editing ongoing. Right? Right.\u003C/p>\u003Cp>Speaker 1: It it would basically mean that the interface is always the thing that controls how it's displayed, because therefore you can have the interface control how that interactivity works in that display context. Now, that does, of course, come with the the side effect that you can no longer have a different display per interface like we currently allow. So theoretically, you could use, you know, a text input interface, and then an icon display if you wanted to. Or, you know, you can have a rating input that is a slider and then a display that's that's rendered as stars. I don't have the stats on how popular that is.\u003C/p>\u003Cp>Like, that would be a breaking change where we remove that. At the same time it also makes it easier to configure. Right? Because you can have, okay, I'm using the icon this, icon interface, and at smaller scales, it turns into an icon display. Right?\u003C/p>\u003Cp>Speaker 2: So I guess another option could be that if you toggle the, you know, inline capability here, then the display gets turned off. Right? You don't have display capability. So you don't have a breaking change, you have the ability to come in and edit an existing interface, keep the existing display capabilities where I don't know what the overhead looks like for that, but something that we could think about instead of just outright ripping this out because I I still think, again, this is gonna be, I think, the most common case where I would want the ability to do, like, inline editing is on strings and numbers and dates. Right?\u003C/p>\u003Cp>Those are the, you know,\u003C/p>\u003Cp>Speaker 1: the The the simple somebody in the the chat called it the simple\u003C/p>\u003Cp>Speaker 2: stuff. Yeah. If I'm dealing with relational, you know, now you're dealing with complex, you know, you're you're just as easily popping into the item at that point to edit a relational setup potentially. Now down the line, that could change, but I think the most common things, you know, based on the ticket that we got inbound was around I just wanna be able to update some numbers, and I'll be able to quickly go through and adjust some numbers. I wanna adjust some text, and it's not a bulk edit because I'm not making them all the same, but I wanna be able to quickly edit things in line.\u003C/p>\u003Cp>Relational's I don't know. My brain my brain, I can see the nicety of it to be able to quickly just pop an interface and make a change without having to open the entire work, you know, in and out of a record to do that, but I think short term initial implementation. But if we added a toggle here or a function that says, you know, disable the display, if you go to inline, then you get the interface, and that is the display.\u003C/p>\u003Cp>Speaker 1: Woah. Say say that again. So That last part,\u003C/p>\u003Cp>Speaker 2: if you\u003C/p>\u003Cp>Speaker 1: have a display but you use an interface and you toggle it, you now have a display. You lost me in that last part.\u003C/p>\u003Cp>Speaker 2: No. No. So I'm saying that if we add a new if we add the feature for inline on the interface so if specific interface designed to support inline, and you just say, I wanna use the inline or I don't know where we would set that.\u003C/p>\u003Cp>Speaker 1: I think it's set up based on the type. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Yeah. I think somebody in the chat mentioned that it's too. It might have been the derp. Yeah.\u003C/p>\u003Cp>Speaker 2: It gives you the, you know, if I make c one in here, it overrides display. Right? Display is essentially either disabled, right, becomes grayed out here, or it's just ignored, and with a note here that says if I check-in line, then boom display is no longer utilized. We're gonna utilize the interface spec for that.\u003C/p>\u003Cp>Speaker 1: So so, you know, in the chat, mentioned a similar idea in that we could also have and this is a direct quote. We could also have multiple optional components for a single interface, like an inline version and a block version of the same interface. And then when the inline interface version exists, that can be used instead of the display, and then gray out the display to you your point.\u003C/p>\u003Cp>Speaker 0: Yeah.\u003C/p>\u003Cp>Speaker 1: Because the,\u003C/p>\u003Cp>Speaker 2: this gets ignored. As long as there's a note or a warning, you know, even if someone does set it here, it's just ignored. If in line is enabled here, then it just gets ignored.\u003C/p>\u003Cp>Speaker 1: Because the reason to then ignore the displays is because you kinda want the display itself to be editable at all times at that point. Like a checkbox, interface in the an inline checkbox interface would just be a toggle that's always active for you to click on. Because the comment that was just made in the chat too is like, you say you're loading a nested relational simple column in a table. You need simple editing. But in terms of toggling, you know, you can use the display by default.\u003C/p>\u003Cp>And then when you turn on an edit mode, maybe all of those in line ones are displayed so you still have displays. It gets tricky. So so the reason I'm saying that is we have things like the, formatted value display which is basically, a very configurable string. Right? You can make it bold, italic.\u003C/p>\u003Cp>You can make it, a different font if you wanted to. If you wanna go crazy with themes, you can make it Comic Sans. Would would highly recommend doing that. Ben's gonna kill me. Then, so those displays are and and you can have a text prefix.\u003C/p>\u003Cp>Right? That's where it gets a little tricky. So the display can show additional data that's not the, like, present in the value. So if we wanted to keep that level of flexibility, like, a rating display being stars. If you have an inline number input, now you kinda kill the usefulness of this rating display.\u003C/p>\u003Cp>Speaker 0: Yeah. The the drawing drawing the line, what is considered simple, is also very hard. Like, for me, for example, like, a many to one relation, for example, I mean, that's basically a drop down. No. A drop down doesn't seem to me to be, like, a complicated change, so to speak, like, a complex update.\u003C/p>\u003Cp>Yeah. But from a user standpoint, not from the implementation detail standpoint, but from a, like, oh, I just want to change the user. That's like one, you know, one click, select the user, select another user, be done. That seems like a simple thing, technically, you know, but it's still a relational change.\u003C/p>\u003Cp>Speaker 1: Yeah.\u003C/p>\u003Cp>Speaker 0: Wait. What did the doer say?\u003C/p>\u003Cp>Speaker 1: I mean, it's you kinda wanna what they're saying is you want the way that you're editing the value to to look the same after you're done editing it. So if you're looking at I think the obvious ones are, the toggle again. You wanna click it and you just edit it in the way it's presented. If you have a rating display, you wanna just click on the number of stars and that's the way you edit the value that you're seeing. When it comes to, like, a related values thing where it shows x number of items, it gets a little finicky.\u003C/p>\u003Cp>Right? If you're talking about the formatted value display where you might have, you know, a dollar sign prefix or something, Now it also gets tricky because now the moment you edit the value, it shows something completely different than you have displayed. Right? I think with dates, there's a different expectation, but if you think about the raw value underneath, it's just a string. It's an ISO 8601 string.\u003C/p>\u003Cp>So if you were to click a nicely formatted in your local language date, and you click it, and now all of a sudden it turns into a technical string, that'd be a bad experience. Right? Even though you could inline edit it as a string, which is not probably not what you want.\u003C/p>\u003Cp>Speaker 0: But what's also funny about like the ISO strings is that, you know, often are like, usually they're stored in like UTC universal time. So, like, people Right.\u003C/p>\u003Cp>Speaker 2: Yeah.\u003C/p>\u003Cp>Speaker 0: In other time zones, might not even know what to actually put in there because, you know, they want to select, alright. This should happen every day at, you know, 8 in the morning or something like some some whatever date. And, then all all of a sudden, the UTC time is completely different. And then you're like, oh, no. This this field's not good.\u003C/p>\u003Cp>What is it? I don't know. And again, yeah, it it really depends on the time zone of the server itself of your database or whatever. And then\u003C/p>\u003Cp>Speaker 1: I mean, at that point, it's it's game over. You really need to have some sort of proper data interface that handles that under the hood and then those presentational side of it. There is this is this is where the discussion is is interesting to me though, because it's like we're basically saying, do we have a small interface or do we have an editable display? And what's the difference? Right?\u003C/p>\u003Cp>Because when it comes to the date the date time specifically, the the basic of the date display is that it basically just takes the raw value and then shows it in whatever is appropriate for your locale. Right? So in the USA, it does the, objectively ridiculous thing. And I moved here by choice, mind you, of month slash day slash year. Right?\u003C/p>\u003Cp>And then elsewhere, it'll just do the proper thing of day, month, year.\u003C/p>\u003Cp>Speaker 0: Right? Shot's fired.\u003C/p>\u003Cp>Speaker 1: But I can imagine that if you have an inline editable date interface, you can just, you know, just like the system native one, basically, you can click on any of those parts and just type in what you want. Right? It doesn't have to be a whole selection, UI, and all that kind of stuff. So sorry for air format.\u003C/p>\u003Cp>Speaker 0: Yeah. The the American people go to great, great, great lengths to not actually use some type of normal measurement. Like, how long is something? Yeah. I don't know.\u003C/p>\u003Cp>2 2 and a half elbows or something. That's something how high how high is this building? I don't know. It's at 20 1,000 feet. I don't know how big is a feet.\u003C/p>\u003Cp>Speaker 1: What? Oh, man. This derails very quickly though. Next session, we'll spend, it's a full hour on the Imperial system.\u003C/p>\u003Cp>Speaker 0: Oh, no. Somebody's actually this relates to the discussion. Yeah. Great. Okay.\u003C/p>\u003Cp>Sure. Sure.\u003C/p>\u003Cp>Speaker 1: Okay. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>This yeah. At least take a bit of context.\u003C/p>\u003Cp>Speaker 2: Everything should be millimeters. He's Google. The Australians got it right there.\u003C/p>\u003Cp>Speaker 1: There there's a good point in the chat though. Let's say you're storing a height value in millimeters or centimeters or meters or something, but then you wanna display it with a display, you know, in feet or inches or that kind of stuff. If you then inline edit it, what are you now inline editing? Because if it would be an interface where you're doing the value, you're now editing, I suppose, the millimeters, but you're showing it as foot. You know what I mean?\u003C/p>\u003Cp>Or as as inches.\u003C/p>\u003Cp>Speaker 2: Oh, don't do it. Don't do it. Just do millimeters.\u003C/p>\u003Cp>Speaker 1: Well, yeah, that's not always appropriate.\u003C/p>\u003Cp>Speaker 2: We're we're not that dumb. We we figure it out. Mhmm. We're we're slowly being converted to metric by the by the global corporate infrastructure. We're getting there.\u003C/p>\u003Cp>I actually flip all my stuff. I use Metrc on everything now.\u003C/p>\u003Cp>Speaker 0: Good boy. Good boy.\u003C/p>\u003Cp>Speaker 1: From FCW comes in with the question, you know, what if we click on a cell, which is one of the displays, and then the field whatever that field's interface appears, just like it does in the form, and I could pop over and it will be prefocused or something. That is very close to basically where we started the discussion. So I'm glad that we're coming full circle, in in converging it back down. Because that would be, in terms of implementation, by far the simplest way for us to build this. Right?\u003C/p>\u003Cp>It's like, don't care about any of this stuff. You click it, you open a little pop over and then you change it and it's done. I also like simple things.\u003C/p>\u003Cp>Speaker 2: Drop down, you get your whatever.\u003C/p>\u003Cp>Speaker 1: You get effectively everything. Now there is. One major downside with that, that we've sort of hinted at, but not explicitly called out like this, Which is I believe that there's a lot of data types where you wanna edit it truly inline and not in a popover. So you have a checkbox, if you click it, you wanna have it change. You don't wanna have it open a popover with an inline toggle that you then click to change the other thing.\u003C/p>\u003Cp>I think when you have a small, text input Drop downs.\u003C/p>\u003Cp>Speaker 2: Drop downs, same thing.\u003C/p>\u003Cp>Speaker 1: Change the change the drop downs, same thing. Right? Both data entry gets frustrating in that model and I would agree. Like, I think for a drop down, you just wanna click it. It needs to show the drop down section.\u003C/p>\u003Cp>It'd be a bit of an annoying UX if it then opens a pop over with the same dropdown again that you then click to to have a nested popover down, I guess, which would also be a bit annoying.\u003C/p>\u003Cp>Speaker 2: Very much agreed.\u003C/p>\u003Cp>Speaker 1: I do think that for me, one of the requirements from a UX design perspective is that we have some sort of truly in line flavor for some of those, and then use the pop over for the interfaces where it doesn't make sense. Right?\u003C/p>\u003Cp>Speaker 2: I like it.\u003C/p>\u003Cp>Speaker 1: Picky stuff. But it's it's also hard to it's also difficult to decide which ones make sense and which ones don't. Because I'm thinking about our color display, which is just a tiny dot in its smallest form. If you click that, do we really have to show the full color interface? Because again, it's more like a a select.\u003C/p>\u003Cp>Right? It's more like a drop down. You could just click the tiny preview and then edit the drop down items directly. But how do we how do you control that, right? Which is, I think, what we're getting at is sort of the suggestion from the DIRF earlier, which kinda says, it's up to the interface to communicate somehow whether or not it is, inline editable.\u003C/p>\u003Cp>Yeah. So I think this is a good example, John. Jonathan. Exactly. It's like this whole drop down, we could just render that the moment you click on the little preview in line, right?\u003C/p>\u003Cp>It doesn't have to have this whole interface again because the only real thing that you care about for the interface is the part in the drop down, right? So from the chat, if interfaces have an inline variant those could be used inline and then fall back to popover if the interface doesn't have an inline variant. I think that is basically what I'm suggesting then. Yeah. Because then for the color in line variant, it can just render it, you know, nice and in line.\u003C/p>\u003Cp>For, a one to many interface where we know it's like there's there's no way to do the whole UI in a table row, it would use a pop over and just render whatever needs in there. I don't know though if interfaces should always have an inline variant, and it is then in charge of what goes in the popover because I can also imagine that the UX of how you wanna deal with an interface itself within the constraints of a pop over smaller window can be different. So if you think about the pagination for a one to many, for example, if you have that configured to, paginate at 50 and the individual rows of a once many are pretty big. You know, they're the regular size of an interface or, input height is what we call it. For a consistent view on the form, it looks nice.\u003C/p>\u003Cp>But if you cram that into a small popover, there's gonna be a lot of overflow scrolling now in that tiny little, in that tiny little pop over. We could go full modal. This is from the chat. Let me mind you. We could go full modal and make people suffer, which we could, but I I kinda to me, it's no longer in line editing then.\u003C/p>\u003Cp>Right? You just have a short cord to open a single field. But I could imagine that yeah. John, thanks for pulling this up. Like that left column section you're seeing there.\u003C/p>\u003Cp>I could imagine that the interface itself has an alternative rendering mode where it can just compress it down a hell of a lot more to be a better experience in a sort of pop over context. Popovers on mobile would be particularly a pain in the neck. Another one from the chat. Yeah. Yeah.\u003C/p>\u003Cp>Absolutely true. Which, in that case, you know, there is the opportunity to say for mobile, if we're rendering a popover, we're just rendering it as a dialogue or it might take over the full screen. There there's ways to responsibly handle that responsibly, responsibly.\u003C/p>\u003Cp>Speaker 0: Okay. So just looking at the time, real quick since we are approaching the hour mark. I think yeah. But I I think we landed on a quite the nice, let's say, idea on how to tackle this because, you know, nothing is, you know, struck in stone, but I I do think I do think I like the approach of, you know, you can have interfaces, you can have displays, and you can have inline interfaces, which sounds very reasonable to me. But then, like you said, alright.\u003C/p>\u003Cp>Where do we control what pops in, what doesn't pop in?\u003C/p>\u003Cp>Speaker 1: And I think it will have to be the interface, honestly. Because I could, an input interface, it knows that it could be handled in line. There's no way real way for us to to see that from the outside in. Right? I mean, we could always have, like, a lookup table somewhere, but it would only work for the stuff we the stuff we ship in core, not for extensions, which is a big part of this, of course.\u003C/p>\u003Cp>I I I think that the the question that I'm struggling with now is really what is the difference displays and interfaces in this paradigm. Right? Because now we're rendering interfaces in the place of a display, sometimes. And I'm I'm now just starting to think with this whole in line editing idea, maybe a display is just a read only inline version of the interface. It it does remove that flexibility that we talked about earlier where you could have a different display value for a input value.\u003C/p>\u003Cp>But to me, it would sort of solve for some of the complexity in configuration and some of these questions that when is it when is it a display? When is it an inline interface? How do you control between the 2? How do you toggle? Etcetera etcetera.\u003C/p>\u003Cp>Because that way we could say, well, in every interface needs an inline and a block version. The block version is what we use on forms and bigger pages. The inline version is what we use in title cards and table rows and that kinda stuff. And then it is read only or it's not. Like we currently already have.\u003C/p>\u003Cp>You know, we have read only forms, for permissions and all that kind of stuff. And a display is effectively just a read only inline version of the interface. And then if you have the editable table layout which is just a toggle. Maybe it's always on tbd. The inline version of the interface now controls if it's a pop over or not.\u003C/p>\u003Cp>So the inline version of a die, of a checkbox. Just click it. It immediately interactive. In line version of a text input. Click it.\u003C/p>\u003Cp>You can type in line version of a relational, one to many or something. By default, it'll just show 6 items. But then when you click it, the popover has the actual editable part. Right? But I think it could be the same the same interface.\u003C/p>\u003Cp>It's all interfaces at that point.\u003C/p>\u003Cp>Speaker 0: Interface is all the way down.\u003C/p>\u003Cp>Speaker 1: I mean, it would reduce it. So so one of the other parts is, like, there is a bit of confusion around the difference between interface and display. And I feel like a lot of people configure an interface by setting up a new field and then don't know that displays even exist. Cause if you configure a new field, it's very easy to skip over it and never know it's there. Right?\u003C/p>\u003Cp>So I also think there is a case to be made that it would improve the experience for a lot of the people that normally don't, really take the time to go over every single option that exists because it can be a bit overwhelming, you know, arguably. There's a lot of stuff you can configure.\u003C/p>\u003Cp>Speaker 0: That sounds good to me.\u003C/p>\u003Cp>Speaker 1: It'd be a gigantic rate and change, so don't worry about that.\u003C/p>\u003Cp>Speaker 0: This is not something we can just\u003C/p>\u003Cp>Speaker 1: in a little 10.1. Here you go. Bang.\u003C/p>\u003Cp>Speaker 0: Looks good to me. Ship it.\u003C/p>\u003Cp>Speaker 1: But I I think to me, that would sort of solve it because then for the table layout, you can have a toggle somewhere that says make it editable. Yes or no. For and for any of the layouts, really. For the tabular layout, we can make it editable by default. For the cards layout, we could say it's probably not a good idea to do it for some but for others because now the layout's in control.\u003C/p>\u003Cp>I think there's there's something to it.\u003C/p>\u003Cp>Speaker 2: Very cool stuff.\u003C/p>\u003Cp>Speaker 0: Good stuff, guys. Any last questions from the, audience? Your chance is now.\u003C/p>\u003Cp>Speaker 1: Forever hold your peace. Winston.\u003C/p>\u003Cp>Speaker 2: Final cue.\u003C/p>\u003Cp>Speaker 0: Forever hold your peace.\u003C/p>\u003Cp>Speaker 2: If you're if you're still awake.\u003C/p>\u003Cp>Speaker 1: Yeah.\u003C/p>\u003Cp>Speaker 2: Oh, let's see. Vincent.\u003C/p>\u003Cp>Speaker 0: Someone type it. Well, then, thank you everybody.\u003C/p>\u003Cp>Speaker 1: Thank you. Bored everybody to death.\u003C/p>\u003Cp>Speaker 2: We've hard hard boiled a few eggs.\u003C/p>\u003Cp>Speaker 0: Lovely. Thanks for tuning in. In case you enjoyed this, there's much more of this on directors.io/tv. If you want to go there, there's lots and lots of interesting shows for you. Lots of good, great entertainment.\u003C/p>\u003Cp>And, feel free to join us next time for another very interesting topic. Thank you for linking the show, Kevin. Oh, yeah. Fire emojis. Yes.\u003C/p>\u003Cp>Very good. Thank you everyone for tuning in. We hope you have a\u003C/p>\u003Cp>Speaker 2: great day. Enjoy your week, folks. Have a good night. Good\u003C/p>\u003Cp>Speaker 0: night. Strong feelings, please let us know. The discussion is open. The issues are open.\u003C/p>\u003Cp>Speaker 1: That way.\u003C/p>","Hello, everybody. Welcome to feature request review with me as a host today, joined by the good old Reich, Van Zanten himself and Jonathan Wagner. Hello. Hello, everybody. Thank you for coming. Very exciting to see you all. Quite quite the quite the collection of people we have here from Algeria, Japan, everywhere. Germany, Austria. No. No. No. I nearly said it. But, yeah, today today, everybody's, apparently favorite topic because there's so much demand here in the channel right now. Inline editing, which can mean a lot of things. So let's just take a look at what a small example could look like. If you take a look at the screen shared footage of Jonathan, you'll see this is our feature request that got in, which you can vote on, by the way, in case, some people are not aware of this feature in our discussions in the director's repository. You may vote on stuff that gets implemented into the software, which is pretty cool. And, today's topic is about inline editing. If we scroll up a little bit to the top to the screenshot, you might have seen this in other interfaces online, you know, when you use Notion or whatever, like, many many sites implement this a little bit differently. You know, on Trello boards, you can click into the title, then you can change the title right then and there without a pop up or something. And, yeah, why why doesn't have direct as this yet? It's a good question. I mean, there are many, many different things that we could talk about. And, in case you have any questions or stuff that you want to share, please feel free to use the chat. We're excited to engage with you guys. It would be fun, a sign of life like previously. That would be nice. And how about how about we jump in right into a couple of questions? Let me quickly, give one second. Alright. So by looking at this, you know, basic example with the with the input field, I mean, the the first question to me is, alright. Like, how how much can we blow this up to, because Directus is very, very versatile, and, people build the craziest displays and interfaces and very, very customizable different pieces. How do they fit into this, and if we just target, like, simple inputs, for example, like in these simple example with, like toggles or text inputs. What about relations? Because those tend to be very nice to deal with. And, how about we go over to give over to Rijk for this one? How do you feel about different types of inputs for inline editing? Do you think we should, like, aim to be able to do everything in in in line editing? Should we reduce it down? Should we only support a sub set? How do you feel about inline editing in itself? I mean, when it comes to inline editing, I think the first question that we gotta ask ourselves and everybody watching is like, what does that even mean in the first place? Is it kinda like a spreadsheet where everything is just a cell where you can change whatever you see? Is it more like, a table view by default where everything looks pretty through those displays, And then you have some sort of edit state. Is it like, an edit state where we render a whole interface in line? Or is there some sort of dialogue overlay that we're seeing when you click on one of the cells, so to speak, to to stay in spreadsheet terms. So I think the first question really is what is what is inline editing? What does it even mean? Right? Because we do have a different feature request for a spreadsheet view, which I think very closely overlaps, but there's definitely differences. And then I think the other question, of course, I mean, relationships, we'll dive into that in 5 minutes. But, if you think about the basics, I think one of the thing that we're doing with direct is with all the interfaces is to make sure that you can edit the data in a way that makes sense for what the data is. Right? So, a very basic example, you know, a slider could be a better representation for a numeric value that you're using for whatever it is that you're building. Right? But You wanna use a slider to control the value. When it comes to inline editing, you know, if we're looking at this screenshot where the reserve column right now presumably is in this edit state, you know, if we're dealing with inline editing in its sort of truest form, does that mean that it just turns into a sort of raw value input? Or do we include interfaces kinda like we are with a regular form? Right. So when it comes to a date value to name something, the technical value is always gonna be that that what's the exact spec, the, ISO 8601. Is that the thing that you wanna be editing? I would argue, probably not. You probably wanna have, you know, the data interface that you have configured for that field, which then leads to the question, does that even fit wherever we're doing this inline editing presumably in this table layout. Right? And I think we're we're quickly reaching the question then is like, okay, do interfaces even fit? And if they don't, how do we present it otherwise? Right? Yeah. To your example, like, even even a simple slider, which is a nice way to input, like, a specific value inside of a range, which could be, you know, like, relevant to the use case, you know, where you want to restrict. You maybe you don't allow, like, negative numbers or something. But if if we allow, like, editing via raw values, then somebody might put in, you know, minus 1 or something, and then you very quickly run into the issue that you mentioned. We want to give people the tools to, like, input stuff as as as comfortably as possible with using, like, nice interfaces and displaying like, even displaying, you know, with with the value that you see inside of the table might, like, might not actually be the wrong value just like you described with the, like, date time, for example. So there's a disconnect there and, like, for, like, nontechnical users, for example. No. It could be it could feel bad, you know, from a user experience standpoint where they like if if marketing salespeople, what what was the thing that's, somebody said I won't name any names, but somebody said, like, the scariest thing that marketing people see is, like, a UUID somewhere. So we're dealing with UUIDs. Yeah. It is, is a scary endeavor, so you have to be quite careful with the display. So yeah. Yeah. Speaking to that, we have why don't we explain a little bit about the difference between our interfaces and displays? Because, you know, indirect is also 2 different things. What are those? How do I use those? What can they do? Good question. So so from I'll I'll prefixes was sort of the theoretical idea behind it while Jonathan here pulls up the actual difference and how you configure them. So the basic idea is that a display, controls how a raw value is displayed in line, importantly. So it's really meant to be part of a sentence or one of the cells in a table or, you know, part of a description or something. So if you think about a, labels display, it can be configured to render it as a small color dot with a tooltip, with the idea being you can then render that in the title of a page, or in the description of a card or inside of a table. Right? The interface is really the the way you edit the value. So if you go and you open an item, it's basically the form field, section of of how you interact with that data. So it's really the difference between sort of block level, in CSS terms, editing of the data versus inline displaying of that same data. Importantly, those 2 can be very different representations of the same data. Right? So the image display will just be a tiny thumbnail where an image interface is like a bigger box where you can drag and drop stuff in and you have, like, preview and some more metadata available. They are at present a different thing. And the display is then Yeah. So so Jonathan right now is, you know, adding, a related values you know, those displays, and compose them all together to really control how an individual item is presented. Right? So on the collection detail page 2, there is a display template setting where, again, you can render individual fields as part of one title string. And then that's how it displays the individual pieces of data. So when it comes to editing them in line, one of the interesting, challenges that we're gonna be facing when it comes to the table layout specifically is that the value that you're seeing in here, it's very likely that that's not the value that you're gonna be editing. Right? And is it a toggle? Is it something that you enable or disable? If you haven't enabled, what happens? If you don't have an enabled or how do I access the record? Because currently, you know, I just know that I can just click anywhere on the row, and it will open the item for me, and I can edit the item. How do we trigger, you know, you start to get into that. So we've got the whole interfacing aspect, relational content, allowed or not allowed. It feels like at least maybe you could almost do it in, like, an iterative. So start with the normal input fields, date fields, the the simpler interfaces and things to deal with versus relational. Relational gets complicated, right, depending on how deep or how complex that relational is. Now in order to edit this translation, well, that requires now that I get the full translational split toggle side by side translations kinds of things, and is that beneficial in this kind of a in this kind of utility? Yeah. Toggles, drop downs, you know, some of this, some of the more string text slash Is this is there there is a a another additional question when it comes to how do we then render an interface to change the data, which is that there's gonna be a couple of them where the interaction would be way nicer if it's, like, truly in line. Like, so if we, if you think about a toggle, like a checkbox. Right? Kinda like the default checkboxes for selecting items. But let's say you have, you know, an on or off state on your own custom item. In your display, ideally, I just wanna click it and it flips. I I don't wanna click it then open a dialogue that shows me just one toggle anyways, and then close it, and then change it that way. You know what I mean? And I think the same goes for basic text values or basic numbers where I just wanna be able to click the text, edit it, and then that's it. Right? I don't wanna have to deal with clicking it, seeing a popover, drop down dialog, whatever it may be, then change it there because it's just another step away for something that feels like it could have been a spreadsheet, basically. Yep. With that example, you know, with just clicking in and changing something, Tim also brought up a nice point because, with nullable values, like, even such a simple thing as a, like, togglable checkbox, if that is even a word, you know, we already run into, like, a small little, thing, like, okay, what if you want to set it to null? You know? Like, if you uncheck the thing, it's false, but you want it to be null. Do we do we, you know, do we, like, enable triple, like, stateful checkboxes that support 3 values? Do we want to have, like, a ellipse that gives you, like, a setting for that? Like, similar to our v form where, you know, you're allowed to enter a raw value, but that's another piece of UI that would have to be somewhere some at some point. Yeah. Exactly. For strings, similar in that vein, you know, for strings, do you want a, empty string, or do you want a null value? Alright? How do you differentiate between those? And it can even differ, you know, from from to Yeah. All of those are problems that we have solved in the form context. Right? Because even in the form, there's just the field label drop down that says empty this value, which is effectively nullifying it. So the question is also how much of that do we wanna pull a level up in here versus how much of that do we just say oh well if you explicitly wanna change a boolean back to a null, you can always go to the page detail thing and then do it there. Right? There is an escape hatch, and we could make the call to say, well, you know, the toggle display goes between true and false. And if you need to reset it back to that null state for whatever specific reason, you can always go to the detail page, and do it there. Right? And I think similarly for the string empty update, empty string, null, that that question is a question that we've currently solved on the interface settings, I believe. Therefore, an input interface, you can say empty string becomes null, and then that's just the value it, you know, stages, it emits. So if we go the route where we use the exact same interface you have already configured as the way to edit it in line, that problem should sort of automatically be solved. Right? Because we're using the same interface with the same settings, and then that should be fine as is. Where that part gets super interesting though, is how do we deal with conditional fields within the context of that row? So the way conditional fields currently work is, you know, you have the whole form of on the field, you have the whole form on the page, and then we can use the values of the form and sort of connect the dots. Right? And use it that way. On a row in a table though, the fields that are displayed might be completely different. The second piece to that is gonna be for conditional fields. They're now react reactive in real time where if you make a change to one field, sort of real life like, real time updates it elsewhere. When you're in the context of an individual row, and I think this is just a bigger question overall, is, like, does it auto save every time you sort of blur the input that you change something in? Or is there gonna be a save button that is like, okay. Now you've made all the changes and you hit save once. That's a very good question. Like, especially for, like, the togglable checkboxes or whatever because, like, if you just miss click somewhere and all of a sudden, that could be a big change, you know, like with flows and automations and other stuff that runs or update events, fire something. If you hit publish on something, that should be, there should be a mechanism, you know, to stop making mistakes, you know, like, accidentally, if you have, like, you know, is active or is published field on some type of blog post or whatever, and you don't want to accidentally just oops. Oops. It's live now. Oopsie. Would would be nice if we could avoid that, but, yeah, that opens up another can of worms. You know? Like, how do we do you configure this on a field level? Do you configure this on a column level, on a, preset level? Like, where where do you where would you like to do that? That's also the thing. Because very good point from the chat also from the, is currently, for example, the displays do not know, like, which item they belong to. They are very stupid in that way with quotation marks where they just Yeah. Display a value. This is why they're called displays. It's it's a presentation, presentation layer. Yeah. Yeah. Yeah. So if if we would like to have the, you know, like, mutable, displays or whatever, you know, if we decide to go that down that road. So, we would have to provide the displays with the item ID in the collection, like, in every place because there's not not only displays only in the table view, in the tabular layout, but also in, like, titles and drop downs or whatever. Like, any and they could be at any place at any time, which makes this a little bit, dangerously spaghettty like, which which which also, kind of bleeds into a similar yet different question, which is where do we allow inline editing in the first place? Because we're assuming we're sort of assuming the table layout right now because that's the most commonly seen elsewhere. I mean, I'm I'm sure that people that have ever seen Airtable are like, that's that's the way. But at the same time, the the question is, do we inline edit elsewhere? Like, if you have a status icon in your page title, does that become an inline editable thing? Right? In the chat somebody says we'd appreciate it for the card layout, maybe even the calendar. I would agree. So on the card layout, if you have in your description of an individual card, you have a a text display. If you click the description, can you now edit the description of a card in line, which opens up a big can of worms, especially from a UX design perspective. I I guess because because we're we're concatenating that into a string in the display right now for a card. Right? Mhmm. Mhmm. So if we're just The same for page titles for the for for that matter or the calendar layout. Yeah. Yeah. And Tim, Tim, another fun, fun little thing that could happen if you're already editing something and you have auto refresh enabled. Somebody updated your stuff in between the edits, and now you have another edge case. Love it. Love it. Love it. Love it. Which is gonna be the same issue that you have with, you know, the regular form. So I'm hopeful that whatever solution we come up with that right now. Yeah. Exactly. Whatever solution we come up with for that, I'm sure the same solution should also then work here. But Yeah. For this So this is a good example in the cars layout. Right? So in that right side bar, you see title, subtitle, and you can configure any combination of the different fields with any sort of additional strings in between, for like adding a dollar sign in front of price. That kind of stuff. Right? So in this particular case, it becomes extra interesting. Because if you now were to click on the number of the price in that description line, do you expect it to be editable? Right? And how do you determine that? Yes or no? Because making every editable globally at all times feels like a UX nightmare waiting to happen, but it also unlocks a lot of flexibility. Right? So it's a tricky one as many things are. Of course. So how about how about then we take a different look? So now we thought about tables and the current layout and whatever. Technically, there's also another option of adding a new layout, like you mentioned earlier, with the spreadsheet layout, which could be the point where you do that type of stuff. I don't know. Maybe, you know, I'm just, you know, throwing stuff in the room right now just to discuss a little bit. But Yeah. Because it does have the mute display thing. Yeah. Yeah. Yeah. So maybe if it turns out to be better or easier or whatever, the spreadsheet layout could be an interesting point where we could tackle this, but, then we have new, cans of worms and cans and of worms stacked upon each other, you know, till this evening. Stack a can. Which which is fun. Yeah. Because, you know, a spreadsheet layout people come into a spreadsheet layout with lots of preconceived notions. Is that the is that the word? And Like, I think expectations is the word I would say. Yeah. Expectations. Yeah. Yeah. Yeah. Yeah. Expectations and and stuff that they would like to have or that they expect to be there because it's, you know, spreadsheets are, daily used by billions of people. So they do want to have, like, conventions and keyboard navigation and different stuff that they already, you know, introduced to the day to day life with bulk renaming, whatever formulas. Maybe they think that this is then an actual spreadsheet that they can do calculations in, which is another cool feature that we would like to have probably from different feature requests for a different day. Yeah. Exactly. Exactly. Exactly. So spreadsheet seems to be a very big thing, for me personally. Yeah. I think to me it's just a very different thing, isn't it, than than this inline editing approach that we're talking about? Because I fully agree with what you're saying. If you close your eyes and you think spreadsheet, there's a whole set of rules that come with that. That if you miss one of them, you have a bad spreadsheet. Right? Because if you look at Excel versus Google Sheets versus Excel on the web or even Apple's, what they call it, numbers, they are all effectively identical in the exact same settings, exact same thing you can do. It's a right or wrong approach. So, funnily enough, for a session like this, it would be a very short call because it's like spreadsheet. It's basically a known entity at that point. Right? I think where it gets interesting to me, and this is sort of the the the Airtable spreadsheet equivalent. It's like, you're not dealing with the spreadsheets. You're dealing with a table that you can edit in line. But it's not a pure spreadsheet in the technical term, right, where you're dealing with cells with raw values, so to speak, rather than UI elements where you edit the values. Yeah. Same thing in the chat was was coined there. The reason why I immediately started thinking about okay. So our display is now editable as a concept is basically from that modular fashion. Right? Because making one new layout that does inline editing sure. We could totally make that happen. We could also make it an option of the regular table layout and then that's it. Right? To me the interesting question for this is really like, is there a way to make it work for any display anywhere? And is that something that we wanna do or not? Because by doing so, you get the tabular layout feature out of the box but you also unlock it elsewhere. Like, if you have, a list of one to many items on, a record, each of those one to many items now also has inline editing because they are using displays to render those values. Right? So it it just, like, it transforms this discussion from an inline table editor to a bigger sort of, like, what does that editing in situ look like across the board? Very, very good question. I wish I would have the answer to it, but, yeah, like you said, I mean, for for for example, for the, like, relational stuff, I could see, you know, reusing the existing drawer that pops up in different places, which could be a nice experience. You know, if you let's say you have a, a website collection with blog posts or something, articles, whatever. And as the drawer opens and you can use the currently already existing, like, relations go through the list, it it's it's with pagination and stuff. That could be nice. But like you said earlier, if for smaller fields, it feels like add UX if you, you know, just want to change one text and then the drawer opens or, like, a pop up opens with just one input. That's, like, at that point, it just feels very not thought through, which I would like to avoid. Yeah. We got correlate with this PR. Yeah. Yeah. Yeah. The the batch editing is also a nice thing. So slightly different. There's also the the, the bigger question here, Which is As it always is? As it always is. But it's that's that's what these sessions are. For those who are new, in these sessions, we always go find all of the edges and then take it back into what is actually realistic in the next step. But so think about it. If if we're now dealing so so you we explained it before that the displays were meant as a presentational only unit and interfaces are meant as an editable unit of the same value. Right? But now we're saying: What if displays are editable, but only at sometimes? So some displays like a string we wanna make inline editable, Some displays like a checkbox inline editable. And some like a relational related values or something we wanna have a click with some sort of dialogue to to have the space to make it a proper editing experience. Right? The question could also be, should those still be 2 separate entities or should they all be interfaces? And based on how we where we're rendering an interface, it can display in different ways. Right? So if you have an interface on a form where it has enough space to grow, it can show as a proper big input. But if you try to squash it into a cell of a table, it just drops the visual representation of an input and becomes one of those underline only in inputs for example. Right? Because then with a read only prop, yes or no, you can toggle between a string that's just rendered as a string. Or when you click it, it switches into this inline interface version, basically. Know what I mean? Because then for a display one, it can always just be interactive for an input, you can just click to start typing for, a related values one or a relation when you can click it and it would just do it in a pop over or dialogue or something along those lines. So depending on the interface type or the interface implementation, you could allow or disallow inline editing ongoing. Right? Right. It it would basically mean that the interface is always the thing that controls how it's displayed, because therefore you can have the interface control how that interactivity works in that display context. Now, that does, of course, come with the the side effect that you can no longer have a different display per interface like we currently allow. So theoretically, you could use, you know, a text input interface, and then an icon display if you wanted to. Or, you know, you can have a rating input that is a slider and then a display that's that's rendered as stars. I don't have the stats on how popular that is. Like, that would be a breaking change where we remove that. At the same time it also makes it easier to configure. Right? Because you can have, okay, I'm using the icon this, icon interface, and at smaller scales, it turns into an icon display. Right? So I guess another option could be that if you toggle the, you know, inline capability here, then the display gets turned off. Right? You don't have display capability. So you don't have a breaking change, you have the ability to come in and edit an existing interface, keep the existing display capabilities where I don't know what the overhead looks like for that, but something that we could think about instead of just outright ripping this out because I I still think, again, this is gonna be, I think, the most common case where I would want the ability to do, like, inline editing is on strings and numbers and dates. Right? Those are the, you know, the The the simple somebody in the the chat called it the simple stuff. Yeah. If I'm dealing with relational, you know, now you're dealing with complex, you know, you're you're just as easily popping into the item at that point to edit a relational setup potentially. Now down the line, that could change, but I think the most common things, you know, based on the ticket that we got inbound was around I just wanna be able to update some numbers, and I'll be able to quickly go through and adjust some numbers. I wanna adjust some text, and it's not a bulk edit because I'm not making them all the same, but I wanna be able to quickly edit things in line. Relational's I don't know. My brain my brain, I can see the nicety of it to be able to quickly just pop an interface and make a change without having to open the entire work, you know, in and out of a record to do that, but I think short term initial implementation. But if we added a toggle here or a function that says, you know, disable the display, if you go to inline, then you get the interface, and that is the display. Woah. Say say that again. So That last part, if you have a display but you use an interface and you toggle it, you now have a display. You lost me in that last part. No. No. So I'm saying that if we add a new if we add the feature for inline on the interface so if specific interface designed to support inline, and you just say, I wanna use the inline or I don't know where we would set that. I think it's set up based on the type. Yeah. Yeah. Yeah. Yeah. Yeah. I think somebody in the chat mentioned that it's too. It might have been the derp. Yeah. It gives you the, you know, if I make c one in here, it overrides display. Right? Display is essentially either disabled, right, becomes grayed out here, or it's just ignored, and with a note here that says if I check-in line, then boom display is no longer utilized. We're gonna utilize the interface spec for that. So so, you know, in the chat, mentioned a similar idea in that we could also have and this is a direct quote. We could also have multiple optional components for a single interface, like an inline version and a block version of the same interface. And then when the inline interface version exists, that can be used instead of the display, and then gray out the display to you your point. Yeah. Because the, this gets ignored. As long as there's a note or a warning, you know, even if someone does set it here, it's just ignored. If in line is enabled here, then it just gets ignored. Because the reason to then ignore the displays is because you kinda want the display itself to be editable at all times at that point. Like a checkbox, interface in the an inline checkbox interface would just be a toggle that's always active for you to click on. Because the comment that was just made in the chat too is like, you say you're loading a nested relational simple column in a table. You need simple editing. But in terms of toggling, you know, you can use the display by default. And then when you turn on an edit mode, maybe all of those in line ones are displayed so you still have displays. It gets tricky. So so the reason I'm saying that is we have things like the, formatted value display which is basically, a very configurable string. Right? You can make it bold, italic. You can make it, a different font if you wanted to. If you wanna go crazy with themes, you can make it Comic Sans. Would would highly recommend doing that. Ben's gonna kill me. Then, so those displays are and and you can have a text prefix. Right? That's where it gets a little tricky. So the display can show additional data that's not the, like, present in the value. So if we wanted to keep that level of flexibility, like, a rating display being stars. If you have an inline number input, now you kinda kill the usefulness of this rating display. Yeah. The the drawing drawing the line, what is considered simple, is also very hard. Like, for me, for example, like, a many to one relation, for example, I mean, that's basically a drop down. No. A drop down doesn't seem to me to be, like, a complicated change, so to speak, like, a complex update. Yeah. But from a user standpoint, not from the implementation detail standpoint, but from a, like, oh, I just want to change the user. That's like one, you know, one click, select the user, select another user, be done. That seems like a simple thing, technically, you know, but it's still a relational change. Yeah. Wait. What did the doer say? I mean, it's you kinda wanna what they're saying is you want the way that you're editing the value to to look the same after you're done editing it. So if you're looking at I think the obvious ones are, the toggle again. You wanna click it and you just edit it in the way it's presented. If you have a rating display, you wanna just click on the number of stars and that's the way you edit the value that you're seeing. When it comes to, like, a related values thing where it shows x number of items, it gets a little finicky. Right? If you're talking about the formatted value display where you might have, you know, a dollar sign prefix or something, Now it also gets tricky because now the moment you edit the value, it shows something completely different than you have displayed. Right? I think with dates, there's a different expectation, but if you think about the raw value underneath, it's just a string. It's an ISO 8601 string. So if you were to click a nicely formatted in your local language date, and you click it, and now all of a sudden it turns into a technical string, that'd be a bad experience. Right? Even though you could inline edit it as a string, which is not probably not what you want. But what's also funny about like the ISO strings is that, you know, often are like, usually they're stored in like UTC universal time. So, like, people Right. Yeah. In other time zones, might not even know what to actually put in there because, you know, they want to select, alright. This should happen every day at, you know, 8 in the morning or something like some some whatever date. And, then all all of a sudden, the UTC time is completely different. And then you're like, oh, no. This this field's not good. What is it? I don't know. And again, yeah, it it really depends on the time zone of the server itself of your database or whatever. And then I mean, at that point, it's it's game over. You really need to have some sort of proper data interface that handles that under the hood and then those presentational side of it. There is this is this is where the discussion is is interesting to me though, because it's like we're basically saying, do we have a small interface or do we have an editable display? And what's the difference? Right? Because when it comes to the date the date time specifically, the the basic of the date display is that it basically just takes the raw value and then shows it in whatever is appropriate for your locale. Right? So in the USA, it does the, objectively ridiculous thing. And I moved here by choice, mind you, of month slash day slash year. Right? And then elsewhere, it'll just do the proper thing of day, month, year. Right? Shot's fired. But I can imagine that if you have an inline editable date interface, you can just, you know, just like the system native one, basically, you can click on any of those parts and just type in what you want. Right? It doesn't have to be a whole selection, UI, and all that kind of stuff. So sorry for air format. Yeah. The the American people go to great, great, great lengths to not actually use some type of normal measurement. Like, how long is something? Yeah. I don't know. 2 2 and a half elbows or something. That's something how high how high is this building? I don't know. It's at 20 1,000 feet. I don't know how big is a feet. What? Oh, man. This derails very quickly though. Next session, we'll spend, it's a full hour on the Imperial system. Oh, no. Somebody's actually this relates to the discussion. Yeah. Great. Okay. Sure. Sure. Okay. Yeah. Yeah. Yeah. Yeah. This yeah. At least take a bit of context. Everything should be millimeters. He's Google. The Australians got it right there. There there's a good point in the chat though. Let's say you're storing a height value in millimeters or centimeters or meters or something, but then you wanna display it with a display, you know, in feet or inches or that kind of stuff. If you then inline edit it, what are you now inline editing? Because if it would be an interface where you're doing the value, you're now editing, I suppose, the millimeters, but you're showing it as foot. You know what I mean? Or as as inches. Oh, don't do it. Don't do it. Just do millimeters. Well, yeah, that's not always appropriate. We're we're not that dumb. We we figure it out. Mhmm. We're we're slowly being converted to metric by the by the global corporate infrastructure. We're getting there. I actually flip all my stuff. I use Metrc on everything now. Good boy. Good boy. From FCW comes in with the question, you know, what if we click on a cell, which is one of the displays, and then the field whatever that field's interface appears, just like it does in the form, and I could pop over and it will be prefocused or something. That is very close to basically where we started the discussion. So I'm glad that we're coming full circle, in in converging it back down. Because that would be, in terms of implementation, by far the simplest way for us to build this. Right? It's like, don't care about any of this stuff. You click it, you open a little pop over and then you change it and it's done. I also like simple things. Drop down, you get your whatever. You get effectively everything. Now there is. One major downside with that, that we've sort of hinted at, but not explicitly called out like this, Which is I believe that there's a lot of data types where you wanna edit it truly inline and not in a popover. So you have a checkbox, if you click it, you wanna have it change. You don't wanna have it open a popover with an inline toggle that you then click to change the other thing. I think when you have a small, text input Drop downs. Drop downs, same thing. Change the change the drop downs, same thing. Right? Both data entry gets frustrating in that model and I would agree. Like, I think for a drop down, you just wanna click it. It needs to show the drop down section. It'd be a bit of an annoying UX if it then opens a pop over with the same dropdown again that you then click to to have a nested popover down, I guess, which would also be a bit annoying. Very much agreed. I do think that for me, one of the requirements from a UX design perspective is that we have some sort of truly in line flavor for some of those, and then use the pop over for the interfaces where it doesn't make sense. Right? I like it. Picky stuff. But it's it's also hard to it's also difficult to decide which ones make sense and which ones don't. Because I'm thinking about our color display, which is just a tiny dot in its smallest form. If you click that, do we really have to show the full color interface? Because again, it's more like a a select. Right? It's more like a drop down. You could just click the tiny preview and then edit the drop down items directly. But how do we how do you control that, right? Which is, I think, what we're getting at is sort of the suggestion from the DIRF earlier, which kinda says, it's up to the interface to communicate somehow whether or not it is, inline editable. Yeah. So I think this is a good example, John. Jonathan. Exactly. It's like this whole drop down, we could just render that the moment you click on the little preview in line, right? It doesn't have to have this whole interface again because the only real thing that you care about for the interface is the part in the drop down, right? So from the chat, if interfaces have an inline variant those could be used inline and then fall back to popover if the interface doesn't have an inline variant. I think that is basically what I'm suggesting then. Yeah. Because then for the color in line variant, it can just render it, you know, nice and in line. For, a one to many interface where we know it's like there's there's no way to do the whole UI in a table row, it would use a pop over and just render whatever needs in there. I don't know though if interfaces should always have an inline variant, and it is then in charge of what goes in the popover because I can also imagine that the UX of how you wanna deal with an interface itself within the constraints of a pop over smaller window can be different. So if you think about the pagination for a one to many, for example, if you have that configured to, paginate at 50 and the individual rows of a once many are pretty big. You know, they're the regular size of an interface or, input height is what we call it. For a consistent view on the form, it looks nice. But if you cram that into a small popover, there's gonna be a lot of overflow scrolling now in that tiny little, in that tiny little pop over. We could go full modal. This is from the chat. Let me mind you. We could go full modal and make people suffer, which we could, but I I kinda to me, it's no longer in line editing then. Right? You just have a short cord to open a single field. But I could imagine that yeah. John, thanks for pulling this up. Like that left column section you're seeing there. I could imagine that the interface itself has an alternative rendering mode where it can just compress it down a hell of a lot more to be a better experience in a sort of pop over context. Popovers on mobile would be particularly a pain in the neck. Another one from the chat. Yeah. Yeah. Absolutely true. Which, in that case, you know, there is the opportunity to say for mobile, if we're rendering a popover, we're just rendering it as a dialogue or it might take over the full screen. There there's ways to responsibly handle that responsibly, responsibly. Okay. So just looking at the time, real quick since we are approaching the hour mark. I think yeah. But I I think we landed on a quite the nice, let's say, idea on how to tackle this because, you know, nothing is, you know, struck in stone, but I I do think I do think I like the approach of, you know, you can have interfaces, you can have displays, and you can have inline interfaces, which sounds very reasonable to me. But then, like you said, alright. Where do we control what pops in, what doesn't pop in? And I think it will have to be the interface, honestly. Because I could, an input interface, it knows that it could be handled in line. There's no way real way for us to to see that from the outside in. Right? I mean, we could always have, like, a lookup table somewhere, but it would only work for the stuff we the stuff we ship in core, not for extensions, which is a big part of this, of course. I I I think that the the question that I'm struggling with now is really what is the difference displays and interfaces in this paradigm. Right? Because now we're rendering interfaces in the place of a display, sometimes. And I'm I'm now just starting to think with this whole in line editing idea, maybe a display is just a read only inline version of the interface. It it does remove that flexibility that we talked about earlier where you could have a different display value for a input value. But to me, it would sort of solve for some of the complexity in configuration and some of these questions that when is it when is it a display? When is it an inline interface? How do you control between the 2? How do you toggle? Etcetera etcetera. Because that way we could say, well, in every interface needs an inline and a block version. The block version is what we use on forms and bigger pages. The inline version is what we use in title cards and table rows and that kinda stuff. And then it is read only or it's not. Like we currently already have. You know, we have read only forms, for permissions and all that kind of stuff. And a display is effectively just a read only inline version of the interface. And then if you have the editable table layout which is just a toggle. Maybe it's always on tbd. The inline version of the interface now controls if it's a pop over or not. So the inline version of a die, of a checkbox. Just click it. It immediately interactive. In line version of a text input. Click it. You can type in line version of a relational, one to many or something. By default, it'll just show 6 items. But then when you click it, the popover has the actual editable part. Right? But I think it could be the same the same interface. It's all interfaces at that point. Interface is all the way down. I mean, it would reduce it. So so one of the other parts is, like, there is a bit of confusion around the difference between interface and display. And I feel like a lot of people configure an interface by setting up a new field and then don't know that displays even exist. Cause if you configure a new field, it's very easy to skip over it and never know it's there. Right? So I also think there is a case to be made that it would improve the experience for a lot of the people that normally don't, really take the time to go over every single option that exists because it can be a bit overwhelming, you know, arguably. There's a lot of stuff you can configure. That sounds good to me. It'd be a gigantic rate and change, so don't worry about that. This is not something we can just in a little 10.1. Here you go. Bang. Looks good to me. Ship it. But I I think to me, that would sort of solve it because then for the table layout, you can have a toggle somewhere that says make it editable. Yes or no. For and for any of the layouts, really. For the tabular layout, we can make it editable by default. For the cards layout, we could say it's probably not a good idea to do it for some but for others because now the layout's in control. I think there's there's something to it. Very cool stuff. Good stuff, guys. Any last questions from the, audience? Your chance is now. Forever hold your peace. Winston. Final cue. Forever hold your peace. If you're if you're still awake. Yeah. Oh, let's see. Vincent. Someone type it. Well, then, thank you everybody. Thank you. Bored everybody to death. We've hard hard boiled a few eggs. Lovely. Thanks for tuning in. In case you enjoyed this, there's much more of this on directors.io/tv. If you want to go there, there's lots and lots of interesting shows for you. Lots of good, great entertainment. And, feel free to join us next time for another very interesting topic. Thank you for linking the show, Kevin. Oh, yeah. Fire emojis. Yes. Very good. Thank you everyone for tuning in. We hope you have a great day. Enjoy your week, folks. Have a good night. Good night. Strong feelings, please let us know. The discussion is open. The issues are open. That way.","published",[],[],{"id":147,"number":148,"year":149,"episodes":150,"show":163},"6aa046f1-bd53-4510-9af0-c0f3daaf4415",1,"2024",[151,152,153,154,122,155,156,157,158,159,160,161,162],"daed2c08-703a-43d6-ac97-aacac61be4c0","86fa152b-6a8b-477e-94b5-bd91e1202d21","0b5f4343-1494-455b-b41a-25811c151242","b2b01569-d8c6-49a7-adaa-429fe84f204f","69ad81e8-5e1d-4b85-9fa9-3b767a3a3478","5c9c888c-f527-4608-a2f7-56f156d00980","243daa59-3772-4ebe-b212-c2a09a4a0b71","d66c1e46-cc57-49fe-a914-2e440bbc1576","12c8f72d-22fa-4ffa-a9d1-57047216fd1a","8896c934-aa2c-43b6-9342-8275682ab8b2","84c7b3ac-fd85-4539-8f39-3247118bcbf2","044b7c89-aaec-43b2-9d6d-6743a0fb5afd",{"title":164,"tile":165},"Request Review","73687d01-3734-4c28-aef7-e6fa8db4cf1e",{"id":155,"slug":167,"season":147,"vimeo_id":168,"description":169,"tile":170,"length":171,"resources":172,"people":8,"episode_number":176,"published":177,"title":178,"video_transcript_html":179,"video_transcript_text":180,"content":8,"seo":181,"status":143,"episode_people":182,"recommendations":186},"public-forms","932168576","In this recording of our live event on April 4 2024, Rijk, Jonathan, and Daniel discuss sharable forms for adding content to collections.","5e3ff428-f8d8-49a9-9c0f-34d2f0b0c4ca",56,[173],{"name":174,"url":175},"Github Discussion","https://github.com/directus/directus/discussions/18807",6,"2024-04-11","Public Forms","\u003Cp>Speaker 0: Hello. Hello, everyone. Welcome to another exciting episode of, request review, where we go over your guys' hopes, wishes, and dreams, and potentially crush them because software is not easy. Joking aside though, we're here to give we're here to go over your discussions inside of our repository. So if you're interested in a few feature or future features, please let us know.\u003C/p>\n\u003Cp>We have an existing, discussion template that you can use inside of our, repository or, extend existing ones. We also love to see that. And, today's topic, as you might have guessed with the title, is public forms or in other words shareable forms. So just, judging by the amount of people that I hear, I assume that this is pretty exciting for you guys. So give us a sign of life in the chat, please.\u003C/p>\n\u003Cp>Oh, that's what I future.\u003C/p>\n\u003Cp>Speaker 1: Like the people at home applauding. That's that's\u003C/p>\n\u003Cp>Speaker 0: that's Yes. Totally. Oh, yeah. We gotta oh, Oh, it's not French, it's Spanish for Noah. Okay.\u003C/p>\n\u003Cp>Okay. Okay. It's nice nice to see some interaction going. So public forms, shareable forms. Let's do a quick let's do a quick poll.\u003C/p>\n\u003Cp>So, how many of you guys used the current already existing feature of sharing forms or entries or however you would like to call it, share items. Because, I guess, public forms are very, very similar to that. It's, Brian says, I do not like sharing my forms. I do not like them then. I am.\u003C/p>\n\u003Cp>Yeah. Isn't that the the author's name? What is his name? Like a children's book author? Oh my god.\u003C/p>\n\u003Cp>Like, I'm blanking so hard right now. Doctor Seuss. Yes. Yes. Yes.\u003C/p>\n\u003Cp>Okay. Okay. Okay. Anyway, let's, let's go over some examples. So public forums, I think everybody has a mental image of what public forums are in their mind.\u003C/p>\n\u003Cp>But, let's make a very, very The most simple example that you could think of is just a contact form for me, basically. So you have a text input, and you want to put it on your website, and people reach out, fill it out, you get an entry, and you have an item in your database. Alright. Fair enough. But as you might have guessed, this is Directus after all, so this is not as easy in every single case.\u003C/p>\n\u003Cp>So, I I would I would love to quote, let give me give me one second to quote the person who opened the discussion, because there's such an amazing quote in there. I hope I did not oh my god. I think I closed the tab. I'm very sorry. Because the quote in there is just too good.\u003C/p>\n\u003Cp>Yeah. Very, very professional. Oh, my god. Maybe in the meantime, you could also think of a couple other examples, while I search for the thing because we're we're doing a show up.\u003C/p>\n\u003Cp>Speaker 1: Yeah. For sure. I think I mean, one thing that is probably, a good bit of context to kick off this discussion is just to go through what the current sharing thing looks like and what it does, and some of the requirements that we know exist around sharing things in general. And then sort of take it from there and elevate. Okay.\u003C/p>\n\u003Cp>What do we do to then unlock, you know, create and update and delete access next to just read access. Right? Because there's a reason we just started with reads and not the other ones. And that's that's sort of the complexity that I like to extract in in this session.\u003C/p>\n\u003Cp>Speaker 0: Speaking of complexity, I found the quote that I was looking for. And the quote is in the discussion itself is, the feature itself could start very small, but it could be very complicated if we wanted to cover more use cases. That's, like, literally every single every single feature that we could ever do.\u003C/p>\n\u003Cp>Speaker 1: That's the request review format for you, isn't it? So for those who are new in this session, one on good bit of context for what these live streams are all about. We just wanna take, you know, the discussion as it exists. Divergently think about, okay, what are all of the edge cases? Find sort of the use case, find all of the unknowns, and then take it back down.\u003C/p>\n\u003Cp>So, like, what is that MVP? What is the minimum viable product that we wanna ship for this to be a success? Right? What are the must haves? What could we add in the future?\u003C/p>\n\u003Cp>Where do we wanna start with this? Right? It's easy to say, oh, the the forms that you're sharing, just make them create access. Right? Done.\u003C/p>\n\u003Cp>But there's a lot more stuff going on into the hood as per usual. And also for the first time in days, we're getting some sun in here. So excuse my exposure.\u003C/p>\n\u003Cp>Speaker 0: Oh, we got some interaction. But, let me let me give let me give another example because there's many, many different use cases for public forms. So it's not just about, like, let's say, you put an email in there and a text box or something. It could also be more involved, for example, inside of your organization because directors is often used as a, like, enterprise tool inside of your company, for example, in the Internet even. So you could build a support ticket system in Directus, and we know that people do that.\u003C/p>\n\u003Cp>So, a public forum could be you visit a site inside of your Internet with an extensive, like, public forum describing what issue do I have, what department is this in, when did this happen, is this critical or not, other descriptions, related persons, or whatever. I mean there's also like very often for marketplaces or adding data to a validation queue because this is, like, very, very often the case. For example, if you have a marketplace and you want to open it up to new, merchants, they have to apply somewhere. Right? They they have to they have to ask, hey.\u003C/p>\n\u003Cp>I am this merchant. Can you please add me to your, shop? Or there was another example inside of the discussion itself regarding, let's say you have, like, a lunch app or whatever where you can off order food. So you want to get more restaurants or or bistros or whatever, and they can apply at your place. So you give them a public form.\u003C/p>\n\u003Cp>They can enter their information, and then you have, like, inside of your validation queue, all of the people or entries that you could go over and then, make sure that they get applied to your public to your service. Alright. Sounds like one of\u003C/p>\n\u003Cp>Speaker 1: the the initial requirements that you're sort of sneaking in with these examples is that this form can live both as a public website page in your direct instance or as an embedded form somewhere on\u003C/p>\n\u003Cp>Speaker 0: your website. Exactly. This is We're\u003C/p>\n\u003Cp>Speaker 1: we're immediately diving in, and we're off.\u003C/p>\n\u003Cp>Speaker 0: That that is that is literally I I wrote this down. This is exactly what I was, coming up with now because, like, the first the first requirement that kinda diverges, like you said, is, okay, so I have this public form. Where is it? Where where where can I find it? Because, like, it really depends.\u003C/p>\n\u003Cp>If I send somebody a link via email for example, it could be sufficient if the link is directly to your directors instance and you get served up like a complete page. And, there's the whole thing with the logo or whatever. And then you have an entire dedicated page for it. But very often also, you would like to embed your form into your existing website. Let's say with the with the, contact form example.\u003C/p>\n\u003Cp>Right? You just want to have a little contact form and on the bottom of your website. But, yeah, then then it starts then it starts. Okay. So you can have 2 different ways.\u003C/p>\n\u003Cp>Speaker 1: Yeah. I was gonna say, let's start let's start with what we have today. Right? So we don't have, writable forms. Let's call it that forms you can change stuff in.\u003C/p>\n\u003Cp>But we do have sort of the shared form where if you open a single item in a collection, you can share share that item. And what that does for the folk who've never tried it, which I believe is most, is that it will create sort of a temporary role, so to speak, a temporary access token that has access to just that one item with the role permissions that you associate to the share. So that sounds a little confusing, but that basically means you can give away a link that contains, you know, basically a long obfuscated URL that gives read access to just that one item and the relations that it has based on the rule that you associate for read permissions, Then that public link, it's, a directus page. So you will be navigated to your directus instance slash admin or slash shares, what we call it then for the public ones. And then, if you open that up, you basically get a read only state of the form that you just shared.\u003C/p>\n\u003Cp>Right? And there's some additional options on that share. You have you can set a password on it. You can set a maximum time, start, and end date that it's available to the public. Those those are the main ones.\u003C/p>\n\u003Cp>I think there's some other options. But long story short, the first step there is, like, if we were to just just enable a share on, the collection level, we can use that as a starting point, but that is only for forms that are then within that sort of share context of directors itself. Right? So you'd be able to use it as an alternative to something like Google forms or, type form or something where you create a form, you share it, you have a public page that you can share it, that you can, link people to. To me, the the fun complexity of this is really when it comes to, a, spam protection, and b, embedding it elsewhere.\u003C/p>\n\u003Cp>Right? Because somebody in the chat, our very own team just now, just half joking said just iframe it into your front end, which, sure, you can do that. But at the same time, somebody else in the chat also mentioned, you know, it would be great if there's a contact form on each of the products in my sort of web shop or or, renting, vending vending thing. At which point, you need to be able to dynamically inject some sort of default value into this form before you submit it. Now if we're talking about embeddable forms, it's almost like a different feature request.\u003C/p>\n\u003Cp>Because if you think about it, you could open up, write access to the public role and just build a form. Right? You can build a query you can build a form in your website and just post a request that straight out to, you know, your direct this instance. So, I think we wanna split this discussion up in, a, the shareable form, which is more sort of the Google form alternative versus embeddable forms, which is, like, what can we do to sort of make it easier to request or build a form indirect and then request it and display it just like that on your website?\u003C/p>\n\u003Cp>Speaker 0: Because, also, how much control do you want to have regarding the styling, for example, with, like, branding? Do your inputs look different? Because, you know, it looks out of place. It could look out of place if, you use our design guidelines, but your brand uses, like, way smaller inputs. It just looks very weird then.\u003C/p>\n\u003Cp>So we also had a nice, suggestion for, by Tim that I like. Where is it? Oh, no. No. By by by Brian.\u003C/p>\n\u003Cp>By a nice, by Brian. Pre filling fields by query parameters could be very cool. And hidden fields, of course. Like, there are many, many, there are so many things that you could do because there's so many different use cases. Like you said, for example, if you want to embed it, do we want to a do we want to be able to also restrict, like, how many different links there are to that form, for example?\u003C/p>\n\u003Cp>So, if I have a email list and I want to contact all of my contacts and I I give them each a personalized input field because I want to avoid the spam issue that you just mentioned, you know? So let's, say, okay, I only want people to be able to answer the form once, at least, you know, on that link, for example. But can they be different? Should they be the same all the time?\u003C/p>\n\u003Cp>Speaker 1: So using the form once, that's the part that we do currently support with the read only share. Right? Where there is a setting for how many times can this item be opened. And every time somebody opens that that item, it just, you know, it decreases the number by 1. And then once the number hit 0s, the link, you know, goes goes this disabled.\u003C/p>\n\u003Cp>Now for creates, how do you confirm that it was done by 1 person? Right? If you associate it to an email address or something, are we gonna do email validation? Do do does there have to be a confirm step? Which is sort of like I'm I'm thinking about other forms I've seen in the wild.\u003C/p>\n\u003Cp>Right? Where it's like you wanna sign up to a raffle or something and you leave an email address and that's your that's your ticket, so to speak. But you can only use it once. Yeah. Somebody in the chat rightfully now at that point, aren't you just logged in to the app anyways?\u003C/p>\n\u003Cp>Because now you have some sort of an account or a verified account within that direct to this instance. Maybe. Maybe. Right? Hard to tell.\u003C/p>\n\u003Cp>Well, I think the other the the question that closely ties into this as well around things like CAPTCHA. How do you prevent robots? How do you prevent AI from just pulling up the form and spamming it to death? Right? Of course, an obvious one for a lot of folks like, oh, just smack a a Google recap on that and you're done.\u003C/p>\n\u003Cp>But, of course, this wouldn't be a direct this request review chat if it was that simple. Because there's a lot of sort of like wrecking and accessibility concerns around, CAPTCHA as a whole When it comes to Google CAPTCHA specifically, I I I'm a little fuzzy on the details, but I'm pretty sure there were some GDPR concerns around embedding Google services as a whole, that already requiring, you know, cookie notices and whatnot because almost every Google service will track you to bits, if you embed stuff on your page. So that's a concern. It also relies on a third party service, which is something that historically we have to be a little bit careful with, because we wanna support multiple different options. Right?\u003C/p>\n\u003Cp>But now here we go. This is the point where now we need to think about how do we have a standardized CAPTCHA system that can work with providers that works across form, right, for both shared forms and into and, like, in internal forms. Another question from the chat. To add some more complexity, who creates the public form? Is it an administrator or a nontechnical CMS user for whom setting up a form with the data model interface might be overwhelmed?\u003C/p>\n\u003Cp>Another great question. Right? So in in the direct to this model form is basically tied to your data model. So if you share an item, you share the item that you're seeing with somebody else. Right?\u003C/p>\n\u003Cp>So in its simplest form, you would share the form that you're currently seeing with the world. Is that what you want? Maybe not. Probably not. In Daniel's example from earlier, if you wanna do a simple tech form with just an email and some text, it's very likely that in your data model, you end up with a status field that says has been responded yes or no or metadata that you wanna have in your system.\u003C/p>\n\u003Cp>But how do you differentiate between the 2? Are we gonna ask the user who is sharing the form to then pick and choose fields to share specifically? Are we gonna attach it to another role soon to be policy? Or are we gonna, or or plan c is, are we gonna strip public forms from the regular content model altogether and just have a whole different section somewhere that says, here is public forms. And then perform, you just have to configure where the responses are saved.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Regarding your point of configuring specific fields like the status, for example. Like, if somebody submits the form, should it be, you know, active, reviewed, tool review, draft, or whatever? So that that really sounds to me like a field preset sign type of thing, but that exact same vein. Okay?\u003C/p>\n\u003Cp>Let's say you have a form with a user created field that automatically adds the user that created that row. Okay. What do we put in there? Who who who created that? I mean, the user could, you know, make their own public user, so to speak, and link them via a field preset, but then also kind of fields just not quite thought through.\u003C/p>\n\u003Cp>Like, to me at least, like, just thinking about it right now, like, it feels, like, so hacky that people would need to do that themselves, that it feels like this is not really thought through. But on the other hand, like, do we want to have, like, a global invisible user that we could reference? Maybe.\u003C/p>\n\u003Cp>Speaker 1: I mean, we do have the concept of a public role. So with the user created example, it would be null because there's no user indirect because that created the thing. So if we if we zoom back out just a little bit, I think the first question that we sort of had this session hey, Jonathan. Welcome to join you, Just to catch you up. The first question was, shareable forms versus embeddable forms.\u003C/p>\n\u003Cp>Right? Which is a shared form is basically the way I see it now as a page within Directus that you'll to, and they just get, you know, a nice looking Directus connected to stuff. It's safe. Done. Little you know, think about Google Forms sort of mentally, that style.\u003C/p>\n\u003Cp>Right? The second thing is some sort of UI component or some sort of auto generated API endpoint or maybe just a public post could be, to render a configured form and direct us on your own app or website in whatever way is appropriate for your tool. Right? To me, those are 2 separate discussions. I think we start with the shareable forms because then the embeddable forms could use the same permission system and shared, configuration from the shareable form to then embed one of the shared forms.\u003C/p>\n\u003Cp>Right? That's kind of what I think that that would be a 2 step 2 step approach.\u003C/p>\n\u003Cp>Speaker 2: Nope. I like that. So that's what you're seeing here. Right? So this is the current it's read only at the moment.\u003C/p>\n\u003Cp>Hard coded is read only. Even though we allow we've kind of plumbed this for role support in the future, it's currently read only. It's hard coded read only. So you get a read only form that looks like this, and it is to a degree, there are some permissionings. So the role does give access to the fields that are available and the relational content that's technically available and visible in the form.\u003C/p>\n\u003Cp>So you can see here my image isn't showing because I don't allow I haven't allowed the permissions correctly on that particular role. So you could have that kind of capability, And I believe we should I haven't tested this, actually. I because I'm logged in as an admin right now, but I think we can restrict the role list here based on the so the the allowed roles and permissions for the user.\u003C/p>\n\u003Cp>Speaker 1: Permissions again? Yep. Exactly.\u003C/p>\n\u003Cp>Speaker 2: So permissioning should control what's available in this list. So I think, again, I think the general plumbing is there for a shareable, editable form? The question becomes, what is it that we're sharing? You know, are you allowing them to create a an item from the form? What does that look like?\u003C/p>\n\u003Cp>Because right now, we are sharing an existing record. So there'd be work to be done around that, I think. Absolutely. As an embeddable I like the embeddable idea. Technically, you can kinda do that already.\u003C/p>\n\u003Cp>You know, we we see examples of that in the structures that, our good friend, Bryant, has set up where, you know, he set up these kinds of forms where\u003C/p>\n\u003Cp>Speaker 1: Right.\u003C/p>\n\u003Cp>Speaker 2: He's almost replicating our schema management capabilities of being able to create an editable form. So he's made it so that you can create a schema field, add whatever, you know, value type. This is a And as we're\u003C/p>\n\u003Cp>Speaker 1: talking segue into, the second question I wanted to bring up, which is for shareable forms, are we sharing an existing form and you will still limit it down. Limit it down. Or is it effectively a separate form builder where you can create one of forms that you then connect the dots between that and your actual data model?\u003C/p>\n\u003Cp>Speaker 2: Yeah. Similar to I think our our CRM has that kind of capability where you can build a form. Right? And then behind the scenes, the data gets stored wherever you direct those fields to store. Exactly.\u003C/p>\n\u003Cp>But you've got an and it's embeddable as a you know, you can get it as a link or you can direct them straight to the form or you can embed it as an embeddable link underneath the hood.\u003C/p>\n\u003Cp>Speaker 1: Because the one thing I do recognize about the current share system is that it's a little bit a little very opaque. What's the right word? It's a little opaque to to know what you're sharing. I mean, by default, you're sharing what you're seeing. Right?\u003C/p>\n\u003Cp>It's like you're sharing the item that you're currently seeing. Yep. But what's actually gonna\u003C/p>\n\u003Cp>Speaker 2: be shown to the user is different. Right? So you have to go check the link and see what it's gonna\u003C/p>\n\u003Cp>Speaker 1: look\u003C/p>\n\u003Cp>Speaker 2: like versus\u003C/p>\n\u003Cp>Speaker 1: It's because it's based on the role that you then associate with the share. So if you use your own role, it's what you see is what you get. But other than that, it's a bit of a, you know, to your point, you have to create the share, pull it up, double check. If you're creating a dedicated form to share, be it read or write, that confusion is taken away immediately because it's the form that you created. It's the form that you're seeing.\u003C/p>\n\u003Cp>Right? I think the big question then becomes, how do we handle permissions if at all? Do we auto generate the permissions based on the stuff you put in the form? And therefore, you make it very explicit. Like, you put, an email address field, so therefore, you can see an email address.\u003C/p>\n\u003Cp>Or do we make it a little more opaque again by associating a role or multiple policies to TM to control the permissions for that shared item. Right? That's that's where it's a little finicky. So when when I meant that permissions, for example, if, where permissions become really important is for nested relationships. Right?\u003C/p>\n\u003Cp>So if you have a read item with a many to one field to a related category or something, what part of the category are you also supposed to be able to read from this entry point of the top level item? So having some sort of permission set there is gonna be required. Because otherwise, theoretically, if your relationships are a little complicated, you could pose a hell of a lot of data. Right? Because if we were to say, auto generate all of them, if you have a user created field because you just wanna show somebody's name, avatar, you could now theoretically go to that user record and you go to a direct to files record because you now have that connection through the user.\u003C/p>\n\u003Cp>Right? So that also, makes me wonder, there's another feature request that is completely unrelated to this, but it might actually directly be related now. One that I opened, I feel like 20 years. It's configuring access control permissions based on a parent child. So instead of saying, you have access to direct these files, you have access to direct these users.\u003C/p>\n\u003Cp>It's saying the permission, you can read a file if it's attached to a user if you're coming through the user and only then.\u003C/p>\n\u003Cp>Speaker 0: Oh. Oh, yeah. Yeah. Yeah. Yeah.\u003C/p>\n\u003Cp>Yeah. That's, that would be very cool. That would be very cool.\u003C/p>\n\u003Cp>Speaker 1: Top the clock. I think we need to need to start a new game. It's like, at what point do we get Jonathan to do that?\u003C/p>\n\u003Cp>Speaker 2: It doesn't take much.\u003C/p>\n\u003Cp>Speaker 1: It doesn't take much. Because because that would that would also potentially solve for this. Because then you could say, okay. If you have many to 1 on the record that you're sharing, you now have access to read just that one record from the related table, but nothing else from the related. Right?\u003C/p>\n\u003Cp>And for the record, that is how the current share system works actually under the hood. It is a hell of a lot more complicated, because what it does is it looks at the item that you're sharing and it checks what items are related, and then it makes a new permission set that says you can read just that one item from the related table. Right? But all of the other API ends work the same, which is interesting. But that's that's the way it does it right now.\u003C/p>\n\u003Cp>So it does actually, you know, specifically look up which items are related, which items are shared as per the role, but then lock it down to only allow you to ex that one particular item that is associated to the shared thing to make sure that we don't overexpose data in your system. Food for thought. But it it, you know, we're getting real quick into the weeds here again. Just from the question, is it sharing the existing form from your data model or are we sharing new one off forms? It sounds like and I've I've it it sounds like we probably wanna look into some sort of system.\u003C/p>\n\u003Cp>You can create individual forms and associate them back to your data model. Just in those cases where you wanna have multiple different forms with different fields that go to the same item.\u003C/p>\n\u003Cp>Speaker 2: Commonly the case. Right? So if I was setting up a, you know, a a newsletter subscription, I might have very simple, but I still wanna register the contact. I still wanna be able to, you know, track their compliance or other things that I may wanna track or need to track versus the same contact information I would collect for a you know, you're signing up for a meeting or a webinar or something else. So the the forms can be storing data to the same places or to additional places.\u003C/p>\n\u003Cp>Speaker 1: Follow-up question. What is that? One of these public forms, and I'll I'll get to Tim's question in the chat very soon because that's another level of complexity. But should we allow one of custom forms to save to multiple tables at the same time?\u003C/p>\n\u003Cp>Speaker 2: Yes. Technically, yes.\u003C/p>\n\u003Cp>Speaker 1: Form can one form create 5 different records in 5 different tables?\u003C/p>\n\u003Cp>Speaker 0: Oh, I think it must. Right? Because of relations?\u003C/p>\n\u003Cp>Speaker 2: Well, not even relations.\u003C/p>\n\u003Cp>Speaker 1: Go Independent of relations. Right? Yeah.\u003C/p>\n\u003Cp>Speaker 2: So if I'm if I'm setting up a form to collect, medical data, you know, to sign you up or set you up or do something or I'm collecting a survey, I might have survey information that I'm storing in the survey table, contact information I'm storing in the contact table. Just simple example. Right? Just 2 tables. But the contact information is in one place, the survey data is somewhere else.\u003C/p>\n\u003Cp>And I may from a from a compliance perspective, I may not be associating the user. I'm just tracking that the user responded, but the survey data has to be independent. Right? No relation at all.\u003C/p>\n\u003Cp>Speaker 1: Here's one quick question.\u003C/p>\n\u003Cp>Speaker 0: Good point, but Tim, wait beef before we go further further down the rabbit hole, there's another good point by Tim. It it it really sounds like a job for a flow or hook. And I think I agree, actually, because, like, the complexity then of setting it up and then the UI that has to be added for that and, stuff that could go wrong and stuff. Like, maybe, you know, just as a as a simple example. Okay.\u003C/p>\n\u003Cp>You have you just make one row in one table. That would that could be the cutoff that we decide on, maybe. I don't know. But it it really sounds like maybe a hook or a flow would then should be responsible for, you know, taking the the depending on the status, it takes the user's email and puts them also into the contacts table or the whatever table. I think I agree with that take.\u003C/p>\n\u003Cp>How do you guys feel about that?\u003C/p>\n\u003Cp>Speaker 1: It's both ways because you could say you'd save all the data to a table and then run the flow based on that change or you save the form to a flow and then handle it yourself. I and I think there's a case to be made for both because for a simple contact us form that is always going through the same table in the same format and it matches your data model, it feels like flows could be a lot of, you know, complexity to configure just for that simple use case. But for everything else, I fully agree. Once you go, I wanna touch 5 different tables and I wanna submit to a different web, and all that kind of stuff. Yeah.\u003C/p>\n\u003Cp>Form to a flow, makes a lot of sense. Right?\u003C/p>\n\u003Cp>Speaker 0: Right. So let's blow up this, let's blow up this discussion further because Tim also said, alright. How about, should public forms be able to save to a specific content version as well.\u003C/p>\n\u003Cp>Speaker 1: If you call the first deal with the safety of a specific content version. Well, the nice thing is if we're going with this whole form safe to flow as idea, then sure do whatever you want. Right? That's that's kind of the beauty of the escape hatch that could be flows as the back end forms. Because at that point, if you wanna save it to a conversion, go for it.\u003C/p>\n\u003Cp>Right? What do we care? What when how when would you use that, though? Let's think about that for a second. So you have draft state basis for an item.\u003C/p>\n\u003Cp>Speaker 2: I guess if you were updating existing content, you may wanna do that as a version, possibly. Typically, in shareable forms, I don't see it as a version necessarily. But if you were allowing someone, say, to update but even then revisions would track the the content changes over time if you were inclined.\u003C/p>\n\u003Cp>Speaker 1: I I think yeah. What I was just about to say is what Tim again just put in the chat. Let's say you want to review and approve the changes that were made in pub. Right? So if you're running a sort of Wikipedia style, Wiki style, page Mhmm.\u003C/p>\n\u003Cp>And you wanna allow people to suggest edits, you could have a public form to update that one particular page, and then those updates go into a version that then can be reviewed and approved by the old person in charter, which is an interesting an\u003C/p>\n\u003Cp>Speaker 0: interesting use\u003C/p>\n\u003Cp>Speaker 2: case. That's a cool that's a cool freaking use case.\u003C/p>\n\u003Cp>Speaker 1: Which actually would be very convenient for our own docs for that record.\u003C/p>\n\u003Cp>Speaker 0: For example, that's what I was thinking about. I have the little button on the bottom here. Edit this page. Edit\u003C/p>\n\u003Cp>Speaker 1: this line. That would be very cool.\u003C/p>\n\u003Cp>Speaker 0: Hang on.\u003C/p>\n\u003Cp>Speaker 1: Another use case from the audience in, in that updating existing thing from, Jay Shue says, another use case is a business directory and the users being able to suggest changes. Agreed. And the Durb saying we could actually use that fairly well as well. That's it. It could be implemented in flows.\u003C/p>\n\u003Cp>Right? Which is where it gets interesting again. Right? Because flows really become that sort of escape hatch for this type of stuff that, like, oh, you wanna save it to a version instead of to a table? You wanna save it to a different whatever you wanna do.\u003C/p>\n\u003Cp>Just use a flow. It it does also answer the question, is this just for create or is this also for update? And I think we've just concluded that also updates are important. Click updates. That's when you can do you can update an existing submission that you've already done, or you could, you know, the Wiki example or the business directory example or some of those.\u003C/p>\n\u003Cp>Speaker 2: Yep. I think about, in particular, things like, you know, some of these online forms could be fairly complex. Right? I've I've done this. I've I've got you know, you're filling out something for a financial thing and you, you know, it's gonna take you an hour to do the form while you may be saving and coming back later.\u003C/p>\n\u003Cp>You can come and go from it. We do a lot with secured online security forms, you know, where we're filling out answers to complex questions that take hours or days to finish. And so, essentially, saving state and coming back and making updates and, oh, I mean, I I wanna fix that answer that I did, you know, 3 pages back in the form, and I wanna go make that adjustment.\u003C/p>\n\u003Cp>Speaker 1: I think we found another use case for the saving it to a version.\u003C/p>\n\u003Cp>Speaker 0: Mhmm.\u003C/p>\n\u003Cp>Speaker 1: Because if you save it to a version, the validation of the database doesn't have yet because it only needs the saves to the database rather than to your stage to changes. Right? So the, what would you call it, plausible forms where you can enter a bunch of stuff, hit save as draft basically, and then come back later. That would be relying on content versioning.\u003C/p>\n\u003Cp>Speaker 2: Good. Yep. Good very well. Doesn't have to, but it could. Right?\u003C/p>\n\u003Cp>You can manage that via state or status or other things as well. But,\u003C/p>\n\u003Cp>Speaker 1: yeah. Unless you're thinking about validation in that case. Right? If you have data integrity rules that say the column cannot be So in your form, it has to be filled out. But you don't want the force to use the whole form once, you need to have an in been safe, which would be, you know, a version conversion version.\u003C/p>\n\u003Cp>Speaker 2: I like it.\u003C/p>\n\u003Cp>Speaker 0: It's Okay. Let's\u003C/p>\n\u003Cp>Speaker 1: I need to switch to a slightly simpler question. Otherwise, my brain is gonna go What about deletes? Is Is that a thing you do publicly?\u003C/p>\n\u003Cp>Speaker 0: My first gut reaction was no. Hell no. But, let's give it a little more thought.\u003C/p>\n\u003Cp>Speaker 2: But I guess if it's user data, I don't know. I could see a use case for it. I don't I don't think from our side of things, if depending on how it's implemented, If you got compliance issues, GDPR, other kinds of things where the user has the right and choice to do that, that's that's gonna it's gonna be very use case specific.\u003C/p>\n\u003Cp>Speaker 1: Because for the case\u003C/p>\n\u003Cp>Speaker 2: we we try not to delete data in general. We put it in the soft archival state. You know, we use status or other things to handle that. But where you have compliance requirements where you must delete, But I don't know if that's a form. That that could be flows driven.\u003C/p>\n\u003Cp>That can be log business logic driven at that point as opposed to something to do with the form itself. I think you'd have to have a form that says I wanna I want my data to later. I wanna unsubscribe. And by doing that behind the scenes, the flows and data data management happen the way that you need them to happen.\u003C/p>\n\u003Cp>Speaker 1: Right. Because I I could imagine that the because because deletes blank at least sound kind of insane. Because you would have what? You would show the user, here's all the records and go whichever delete whichever one you want. It that that feels like not something that you'd realistically want.\u003C/p>\n\u003Cp>But I could imagine that if we connect it to an account again, not not so much a a direct as app account, but, like, the moment you create a form submission, I could imagine that you maybe wanna do a public read of a layout. Here's a new question that we're gonna discuss in 5 minutes. Where you can just as a user as a temporary user all the submissions that you've done in the past and then delete a previous submission.\u003C/p>\n\u003Cp>Speaker 2: To me, again, business logic. Right? That that tends to be not so much I I think you'd I think someone suggested it here. I think you'd do it as a delete request. You'd submit a request to delete and then confirm whatever mechanisms.\u003C/p>\n\u003Cp>Your your business logic, your flows, your your any additional code processing that you're doing on top of that would handle those things and send notifications accordingly. Feels very much like you would submit that as a specific form request to remove data, not the ability to delete data from the form. I think I agree in general that that shouldn't be allowed. You'd have to submit that as a separate form, maybe. I don't know.\u003C/p>\n\u003Cp>I'm sure there's a use case that I'm not thinking of. But\u003C/p>\n\u003Cp>Speaker 1: Yeah. But to your point, if you create a new form that triggers a flow rather than saves to a table, that flow then just deletes it, whatever, based on your business logic, then prop solved. Right? You you don't necessarily go the mile to\u003C/p>\n\u003Cp>Speaker 2: Yep.\u003C/p>\n\u003Cp>Speaker 1: Have native victim delete support for that specific of a use case. Okay. Interesting. Interesting. Interesting.\u003C/p>\n\u003Cp>Interesting. Tricky. Tricky. Tricky questions. Tricky questions.\u003C/p>\n\u003Cp>Another another question in the chat here from user. So what about editable forms or relational data where items can be deleted after it's been saved and the user edits the data?\u003C/p>\n\u003Cp>Speaker 0: We got it. Ladies and gentlemen, we got it.\u003C/p>\n\u003Cp>Speaker 2: That's the real goal. If we can get right to do it, then we're then we're successful.\u003C/p>\n\u003Cp>Speaker 1: What about editable foreign situational data where items can be deleted as it's been saved and use it as the data? I mean, I guess that kinda goes for any editable forms that it's like, user creates it, admin changes it, user tries to edit it, and that looks different. Which, yes, it will look different because you changed it. You changed somebody's submission. Right?\u003C/p>\n\u003Cp>I think that becomes becomes more of a workflow or a business process, thing where tell your staff don't touch, you know, don't go changing somebody submission. That's bad mojo. But I guess yes.\u003C/p>\n\u003Cp>Speaker 0: What about resubmitting of shareable forms? We're kind of in the midst of thinking this through because, in the beginning, we said, okay. If you have a fixed link that you can send somebody and then they submit the thing, we could restrict that you can only submit once with that link. Or you can have a general link where, like, every single submission results in a new row every time. But then it's very use case dependent, I think.\u003C/p>\n\u003Cp>No. Like, that should be just configurable. Okay. Is this, will this result then in a on on my second visit to that link, will it show me the actual item, or is the form empty again, and can I resubmit it? I mean, that's, like, very dependent on on on the configuration, I think.\u003C/p>\n\u003Cp>Speaker 2: Yeah. I think it should be doable, though. Some additional configurations here, potential validation checks. So, again, if it's an embeddable form or it's a shareable, editable form from our side, then this is gonna need some updating as well. Right?\u003C/p>\n\u003Cp>We'll need some additional parameters and things here. You'd have to potentially check the data, validate the data on save. Flows, again, can handle some of that, but to give the user feedback of you've already submitted or disabling the form because they've already made a submission. How do we check that? What does what does that look like?\u003C/p>\n\u003Cp>Because now you actually have to have something, you know, activity wise that says your device or whatever has been registered. We know that it was you, and you've already submitted the form. Yeah. That gets that's where I I don't know. It almost feels like that should just be front end dev work and get managed from that side of things.\u003C/p>\n\u003Cp>But Oh, here's here's\u003C/p>\n\u003Cp>Speaker 1: the problem though, Jonathan, when it comes to the form that we're sharing, who's the front end dev doing the work?\u003C/p>\n\u003Cp>Speaker 2: It's it's us.\u003C/p>\n\u003Cp>Speaker 1: It's us.\u003C/p>\n\u003Cp>Speaker 2: It's us. I know. So this needs more complex kinds of things because now max 5 uses, well, is that 5 users, or is that 5 you know, one person could submit all 5 or use all 5\u003C/p>\n\u003Cp>Speaker 1: values. Right? Is a user?\u003C/p>\n\u003Cp>Speaker 2: What is a user? Right? What is the\u003C/p>\n\u003Cp>Speaker 0: Are we getting deep? What am I I mean,\u003C/p>\n\u003Cp>Speaker 1: that's that's kinda the question\u003C/p>\n\u003Cp>Speaker 2: right now. I think about like same thing. We we track this on, you know, AppSight anyway, but now we've got this floating thing out there that would also have to track an activity record of who the IP and device and things are and be able to validate against that as part of this form configuration or this shareable form configuration. Now it's, you know, one time per user or per IP or, you know, whatever we consider that to be. There'd be something here, you know, max uses.\u003C/p>\n\u003Cp>So I want a 1,000 submissions, but then I wanna be able to also say per something.\u003C/p>\n\u003Cp>Speaker 1: The the problem of the the how do you confirm the per something? Because you could say you could you could I mean, you could get away with it by just having a unique column. Right? That it's like you can only have one submission with this email address, and that's it. Done.\u003C/p>\n\u003Cp>It could be unique. Already exists. Can save it. Done. Right?\u003C/p>\n\u003Cp>But how do you prevent somebody, you know, with a Gmail account, for example, you can do the plus something something and it will come back to you anyways. You prevent somebody from submitting times with the same, you know, plus 1, plus 2, plus 3, that will work. And I can use all information still. Because there's no way for us to validate that. And then, you know, for email specifically, you can start thinking about, maybe we have some sort of email validation or we send an email and you have to click confirm or all that kind of stuff.\u003C/p>\n\u003Cp>But then what happens if you wanna use something else as the unique identifier? What if you're doing some of the phone numbers? Right? Where it's like, enter your phone number, we'll send you a text when it's your turn to to for for like reservations. Right?\u003C/p>\n\u003Cp>If you're doing a reservation at and it's it's that's that's very common around here. I don't know. Over in your parts of the world. But, you know, if you go to a restaurant here and it's full and it's like, oh, your your table's gonna be about 40 minutes and you your phone number, they'll send you a text when it's ready. Right?\u003C/p>\n\u003Cp>Mhmm. Or about 10 minutes before it's ready. So in that case, you wanna duplicate it on the phone number, but how can you confirm that? Right? You you can't really, there's no way for us to know that.\u003C/p>\n\u003Cp>Speaker 0: A simpler a simple example would be if if you have first sorry, the delay delay is giving us. No, but but a simple example for, limiting that kind of, use would be, let's say you have a form that you can resubmit with, let's say, you have an online shop and then you want to use this for functionality for giving out promotion codes, and you only want to give out a 100 promotion codes, okay, Then it's just a matter of counting the rows, you know, so so we don't have to have a unique field or whatever. We just say, okay. This form can be submitted 100 times. That's it.\u003C/p>\n\u003Cp>I think there's like, it's a little different to your guys' use case, what you just described with the email and and phone and whatever. But, I mean, this is also a valid use case, I think. You know? I I want this form to just be usable for 100 submissions. Okay?\u003C/p>\n\u003Cp>Then it's just a matter of counting.\u003C/p>\n\u003Cp>Speaker 1: Mhmm.\u003C/p>\n\u003Cp>Speaker 2: Well, that's our that's already built in. Right? So we already support that max five uses. So and we keep track. Similarly, if we want this to be 1 per or 2 per source, right, then we have to actually track from a and, I guess, because it's an embeddable form or it's a, you know, we we have information and knowledge about the browser.\u003C/p>\n\u003Cp>Right? We we can track that. It just requires that we store the activity information and utilize that as part of the additional values here in a sense. There's still ways around. Right?\u003C/p>\n\u003Cp>There's always a way around. I've got 5 devices, and I wanna submit 5 submissions. You know, I can I can do that, but and and, you know, we can do things like enforcement of uniqueness on the values coming in and those things? That's already there. It's more about can I at least track to know that this user has already submitted a form because of their IP address slash device ID, that we track anyway from the browser cookie side of things?\u003C/p>\n\u003Cp>Speaker 1: I think, I think I'm reaching the same conclusion as Tim. It's like we're going down the bot detection rabbit hole, which is like, can we fingerprint an individual user? No. There's no way. There's there's no way because IP address is shared with the location.\u003C/p>\n\u003Cp>So, therefore, everybody in the same household or the same business is gonna have a similar bound IP address. So that that doesn't work. I mean, this this fingerprint in question has been a cat and mouse between browser makers and, you know, back end implementers. It doesn't exist. The only way to do that is to require a sign through some sort of secondary authentication method, like send you an email with a magic link.\u003C/p>\n\u003Cp>So therefore, you prove you have access to the email, and that's it. Right? Before it submits or text with a phone number, that kind of stuff. Or log in through an SSO provide to confirm your, you know, your identity there, which actually is a different question I didn't even think about. But it would be kinda nice if you could sort of, like, connect the dots between what is your GitHub account click here to to o auth your way in to confirm, but that's not gonna be a 5 minute conversation, I don't think.\u003C/p>\n\u003Cp>Another question from the chat here, from from user and I'm gonna butcher your name. Sorry about that. Mama. That's what I'm gonna go with. How about the ability to show already submitted values to the user when filling out a form?\u003C/p>\n\u003Cp>Thinking about a sign up form for a party, and showing what food others already bring with them. Which is so this is an interesting question, which I think is not so much, the shareable, writable form. This is the question of readable lists of items. So right now, the share that we offer is just for a single item. You share that one.\u003C/p>\n\u003Cp>Right? What we don't allow you to do yet though, you can go to a layout and share the whole in a simple fashion. I could imagine that for this particular use case, what you would do is you would basically make a public share for your record of foodstuffs people bring to the party, long collection name, and then you can give people that link. Right? And then when they go there, they just see a layout like you would expect from directives with all of the stuff that has been previously entered with a click to to open an individual, I imagine, and then a, you know, a plug or something to go to the create page if you have create permissions through that public share.\u003C/p>\n\u003Cp>Speaker 2: I think this is actually related to Hannes' question as well. More so because the food items being brought can be a many to many or a relational junction that's already there. So we'd show that in the current form. Right? Just like we did, you know, I only have translations in here right now, but equivalent kinds of things where you've got a a relational structure.\u003C/p>\n\u003Cp>The real question becomes when you're adding or removing relational items, this is considered potentially a delete operation under the hood. Right? So there there's there's a little bit of a tie between the delete conversation we were having and this ability to show or allow or not allow you to you know, you might be able to see what other people have brought, but you can't remove their food item. You can only add your own food item. Right?\u003C/p>\n\u003Cp>And or remove your own food item. I think role permissions generally work correctly for that, but it becomes a question of making sure that you test and set those things correctly. But is that considered a delete? Right? If you've got a cascade operation on, you know, removing a a relational item, well, that's potentially gonna cascade and cause a delete down the line.\u003C/p>\n\u003Cp>Speaker 1: I think that would always be a deselect from the relational perspective. The\u003C/p>\n\u003Cp>Speaker 2: Well, that depends on what you set your permissions for. Right?\u003C/p>\n\u003Cp>Speaker 1: Oh, it's what you do. It's not permissions. The field\u003C/p>\n\u003Cp>Speaker 2: oh, I guess it's what you set your field settings for. Right? If you set by default, yes, we set it to nullify so we don't actually delete any data. But if they've got cascade delete permissions, you know, if the cascade delete is turned on, that's going to actually delete data or contact.\u003C/p>\n\u003Cp>Speaker 1: Point. Yeah. So the that's here's the security vulnerability way to happen. If you have an edit access to a simple item with a many the one many the one is configured to delete on select. If the user edit the field and they deselect, they now can theoretically delete stuff in your database, which is fun.\u003C/p>\n\u003Cp>Alright. Oh, jeez. It's already we're very we're already on on the dot here almost at 11. Oh, yeah. 11 for me.\u003C/p>\n\u003Cp>Times for everybody else. Just to to summarize all of this, because we went very much like this, but not a lot like that yet. We're running out of time. I think some some initial conclusions as far as I sort of take it now from this session. Right?\u003C/p>\n\u003Cp>It's like there's definitely a difference between shareable forms and embeddable forms. Shareable forms is part 1. Embeddable forms can then reuse whatever configuration that has for embedding stuff. I think that's conclusion number 1. I think to me, conclusion number 2, it's ideally you can create forms separately from the data model.\u003C/p>\n\u003Cp>Model. Although, that is quite a bit, you know, more involved to build and experiment with and etcetera etcetera. I think starting with create access is the most straightforward as you don't have problems with who can read what, how do you update previous submissions, how do people know what submissions they've previously done, etcetera. So in order of operations, shareable pages create first, then, read access for a listing would be very useful because then you have a way to click into an update item there. And then I think as a sort of your v 2, we should think about what do we form creation to look like in the first place and how does that tie into sharing?\u003C/p>\n\u003Cp>And a different question is, should sharing even be tied to collections and items, or is it just pages in the app altogether? Because I can also imagine that there's other places, like, folder in your file library that you might wanna share. Don't know. Like, another feature request for a different day, because I got skipped is, what about shareable dashboards from Insights? That'd be cool.\u003C/p>\n\u003Cp>But let's not do that right now. We'll save that for a different session. For now, Daniel, back to you to close it out.\u003C/p>\n\u003Cp>Speaker 0: Thanks everybody for coming. If you enjoyed this discussion or are interested in other discussions, you can head over to directors. Iotv where you can find lots of other interesting shows and also this one. And, we hope to have you to see you again.\u003C/p>","Hello. Hello, everyone. Welcome to another exciting episode of, request review, where we go over your guys' hopes, wishes, and dreams, and potentially crush them because software is not easy. Joking aside though, we're here to give we're here to go over your discussions inside of our repository. So if you're interested in a few feature or future features, please let us know. We have an existing, discussion template that you can use inside of our, repository or, extend existing ones. We also love to see that. And, today's topic, as you might have guessed with the title, is public forms or in other words shareable forms. So just, judging by the amount of people that I hear, I assume that this is pretty exciting for you guys. So give us a sign of life in the chat, please. Oh, that's what I future. Like the people at home applauding. That's that's that's Yes. Totally. Oh, yeah. We gotta oh, Oh, it's not French, it's Spanish for Noah. Okay. Okay. Okay. It's nice nice to see some interaction going. So public forms, shareable forms. Let's do a quick let's do a quick poll. So, how many of you guys used the current already existing feature of sharing forms or entries or however you would like to call it, share items. Because, I guess, public forms are very, very similar to that. It's, Brian says, I do not like sharing my forms. I do not like them then. I am. Yeah. Isn't that the the author's name? What is his name? Like a children's book author? Oh my god. Like, I'm blanking so hard right now. Doctor Seuss. Yes. Yes. Yes. Okay. Okay. Okay. Anyway, let's, let's go over some examples. So public forums, I think everybody has a mental image of what public forums are in their mind. But, let's make a very, very The most simple example that you could think of is just a contact form for me, basically. So you have a text input, and you want to put it on your website, and people reach out, fill it out, you get an entry, and you have an item in your database. Alright. Fair enough. But as you might have guessed, this is Directus after all, so this is not as easy in every single case. So, I I would I would love to quote, let give me give me one second to quote the person who opened the discussion, because there's such an amazing quote in there. I hope I did not oh my god. I think I closed the tab. I'm very sorry. Because the quote in there is just too good. Yeah. Very, very professional. Oh, my god. Maybe in the meantime, you could also think of a couple other examples, while I search for the thing because we're we're doing a show up. Yeah. For sure. I think I mean, one thing that is probably, a good bit of context to kick off this discussion is just to go through what the current sharing thing looks like and what it does, and some of the requirements that we know exist around sharing things in general. And then sort of take it from there and elevate. Okay. What do we do to then unlock, you know, create and update and delete access next to just read access. Right? Because there's a reason we just started with reads and not the other ones. And that's that's sort of the complexity that I like to extract in in this session. Speaking of complexity, I found the quote that I was looking for. And the quote is in the discussion itself is, the feature itself could start very small, but it could be very complicated if we wanted to cover more use cases. That's, like, literally every single every single feature that we could ever do. That's the request review format for you, isn't it? So for those who are new in this session, one on good bit of context for what these live streams are all about. We just wanna take, you know, the discussion as it exists. Divergently think about, okay, what are all of the edge cases? Find sort of the use case, find all of the unknowns, and then take it back down. So, like, what is that MVP? What is the minimum viable product that we wanna ship for this to be a success? Right? What are the must haves? What could we add in the future? Where do we wanna start with this? Right? It's easy to say, oh, the the forms that you're sharing, just make them create access. Right? Done. But there's a lot more stuff going on into the hood as per usual. And also for the first time in days, we're getting some sun in here. So excuse my exposure. Oh, we got some interaction. But, let me let me give let me give another example because there's many, many different use cases for public forms. So it's not just about, like, let's say, you put an email in there and a text box or something. It could also be more involved, for example, inside of your organization because directors is often used as a, like, enterprise tool inside of your company, for example, in the Internet even. So you could build a support ticket system in Directus, and we know that people do that. So, a public forum could be you visit a site inside of your Internet with an extensive, like, public forum describing what issue do I have, what department is this in, when did this happen, is this critical or not, other descriptions, related persons, or whatever. I mean there's also like very often for marketplaces or adding data to a validation queue because this is, like, very, very often the case. For example, if you have a marketplace and you want to open it up to new, merchants, they have to apply somewhere. Right? They they have to they have to ask, hey. I am this merchant. Can you please add me to your, shop? Or there was another example inside of the discussion itself regarding, let's say you have, like, a lunch app or whatever where you can off order food. So you want to get more restaurants or or bistros or whatever, and they can apply at your place. So you give them a public form. They can enter their information, and then you have, like, inside of your validation queue, all of the people or entries that you could go over and then, make sure that they get applied to your public to your service. Alright. Sounds like one of the the initial requirements that you're sort of sneaking in with these examples is that this form can live both as a public website page in your direct instance or as an embedded form somewhere on your website. Exactly. This is We're we're immediately diving in, and we're off. That that is that is literally I I wrote this down. This is exactly what I was, coming up with now because, like, the first the first requirement that kinda diverges, like you said, is, okay, so I have this public form. Where is it? Where where where can I find it? Because, like, it really depends. If I send somebody a link via email for example, it could be sufficient if the link is directly to your directors instance and you get served up like a complete page. And, there's the whole thing with the logo or whatever. And then you have an entire dedicated page for it. But very often also, you would like to embed your form into your existing website. Let's say with the with the, contact form example. Right? You just want to have a little contact form and on the bottom of your website. But, yeah, then then it starts then it starts. Okay. So you can have 2 different ways. Yeah. I was gonna say, let's start let's start with what we have today. Right? So we don't have, writable forms. Let's call it that forms you can change stuff in. But we do have sort of the shared form where if you open a single item in a collection, you can share share that item. And what that does for the folk who've never tried it, which I believe is most, is that it will create sort of a temporary role, so to speak, a temporary access token that has access to just that one item with the role permissions that you associate to the share. So that sounds a little confusing, but that basically means you can give away a link that contains, you know, basically a long obfuscated URL that gives read access to just that one item and the relations that it has based on the rule that you associate for read permissions, Then that public link, it's, a directus page. So you will be navigated to your directus instance slash admin or slash shares, what we call it then for the public ones. And then, if you open that up, you basically get a read only state of the form that you just shared. Right? And there's some additional options on that share. You have you can set a password on it. You can set a maximum time, start, and end date that it's available to the public. Those those are the main ones. I think there's some other options. But long story short, the first step there is, like, if we were to just just enable a share on, the collection level, we can use that as a starting point, but that is only for forms that are then within that sort of share context of directors itself. Right? So you'd be able to use it as an alternative to something like Google forms or, type form or something where you create a form, you share it, you have a public page that you can share it, that you can, link people to. To me, the the fun complexity of this is really when it comes to, a, spam protection, and b, embedding it elsewhere. Right? Because somebody in the chat, our very own team just now, just half joking said just iframe it into your front end, which, sure, you can do that. But at the same time, somebody else in the chat also mentioned, you know, it would be great if there's a contact form on each of the products in my sort of web shop or or, renting, vending vending thing. At which point, you need to be able to dynamically inject some sort of default value into this form before you submit it. Now if we're talking about embeddable forms, it's almost like a different feature request. Because if you think about it, you could open up, write access to the public role and just build a form. Right? You can build a query you can build a form in your website and just post a request that straight out to, you know, your direct this instance. So, I think we wanna split this discussion up in, a, the shareable form, which is more sort of the Google form alternative versus embeddable forms, which is, like, what can we do to sort of make it easier to request or build a form indirect and then request it and display it just like that on your website? Because, also, how much control do you want to have regarding the styling, for example, with, like, branding? Do your inputs look different? Because, you know, it looks out of place. It could look out of place if, you use our design guidelines, but your brand uses, like, way smaller inputs. It just looks very weird then. So we also had a nice, suggestion for, by Tim that I like. Where is it? Oh, no. No. By by by Brian. By a nice, by Brian. Pre filling fields by query parameters could be very cool. And hidden fields, of course. Like, there are many, many, there are so many things that you could do because there's so many different use cases. Like you said, for example, if you want to embed it, do we want to a do we want to be able to also restrict, like, how many different links there are to that form, for example? So, if I have a email list and I want to contact all of my contacts and I I give them each a personalized input field because I want to avoid the spam issue that you just mentioned, you know? So let's, say, okay, I only want people to be able to answer the form once, at least, you know, on that link, for example. But can they be different? Should they be the same all the time? So using the form once, that's the part that we do currently support with the read only share. Right? Where there is a setting for how many times can this item be opened. And every time somebody opens that that item, it just, you know, it decreases the number by 1. And then once the number hit 0s, the link, you know, goes goes this disabled. Now for creates, how do you confirm that it was done by 1 person? Right? If you associate it to an email address or something, are we gonna do email validation? Do do does there have to be a confirm step? Which is sort of like I'm I'm thinking about other forms I've seen in the wild. Right? Where it's like you wanna sign up to a raffle or something and you leave an email address and that's your that's your ticket, so to speak. But you can only use it once. Yeah. Somebody in the chat rightfully now at that point, aren't you just logged in to the app anyways? Because now you have some sort of an account or a verified account within that direct to this instance. Maybe. Maybe. Right? Hard to tell. Well, I think the other the the question that closely ties into this as well around things like CAPTCHA. How do you prevent robots? How do you prevent AI from just pulling up the form and spamming it to death? Right? Of course, an obvious one for a lot of folks like, oh, just smack a a Google recap on that and you're done. But, of course, this wouldn't be a direct this request review chat if it was that simple. Because there's a lot of sort of like wrecking and accessibility concerns around, CAPTCHA as a whole When it comes to Google CAPTCHA specifically, I I I'm a little fuzzy on the details, but I'm pretty sure there were some GDPR concerns around embedding Google services as a whole, that already requiring, you know, cookie notices and whatnot because almost every Google service will track you to bits, if you embed stuff on your page. So that's a concern. It also relies on a third party service, which is something that historically we have to be a little bit careful with, because we wanna support multiple different options. Right? But now here we go. This is the point where now we need to think about how do we have a standardized CAPTCHA system that can work with providers that works across form, right, for both shared forms and into and, like, in internal forms. Another question from the chat. To add some more complexity, who creates the public form? Is it an administrator or a nontechnical CMS user for whom setting up a form with the data model interface might be overwhelmed? Another great question. Right? So in in the direct to this model form is basically tied to your data model. So if you share an item, you share the item that you're seeing with somebody else. Right? So in its simplest form, you would share the form that you're currently seeing with the world. Is that what you want? Maybe not. Probably not. In Daniel's example from earlier, if you wanna do a simple tech form with just an email and some text, it's very likely that in your data model, you end up with a status field that says has been responded yes or no or metadata that you wanna have in your system. But how do you differentiate between the 2? Are we gonna ask the user who is sharing the form to then pick and choose fields to share specifically? Are we gonna attach it to another role soon to be policy? Or are we gonna, or or plan c is, are we gonna strip public forms from the regular content model altogether and just have a whole different section somewhere that says, here is public forms. And then perform, you just have to configure where the responses are saved. Yeah. Regarding your point of configuring specific fields like the status, for example. Like, if somebody submits the form, should it be, you know, active, reviewed, tool review, draft, or whatever? So that that really sounds to me like a field preset sign type of thing, but that exact same vein. Okay? Let's say you have a form with a user created field that automatically adds the user that created that row. Okay. What do we put in there? Who who who created that? I mean, the user could, you know, make their own public user, so to speak, and link them via a field preset, but then also kind of fields just not quite thought through. Like, to me at least, like, just thinking about it right now, like, it feels, like, so hacky that people would need to do that themselves, that it feels like this is not really thought through. But on the other hand, like, do we want to have, like, a global invisible user that we could reference? Maybe. I mean, we do have the concept of a public role. So with the user created example, it would be null because there's no user indirect because that created the thing. So if we if we zoom back out just a little bit, I think the first question that we sort of had this session hey, Jonathan. Welcome to join you, Just to catch you up. The first question was, shareable forms versus embeddable forms. Right? Which is a shared form is basically the way I see it now as a page within Directus that you'll to, and they just get, you know, a nice looking Directus connected to stuff. It's safe. Done. Little you know, think about Google Forms sort of mentally, that style. Right? The second thing is some sort of UI component or some sort of auto generated API endpoint or maybe just a public post could be, to render a configured form and direct us on your own app or website in whatever way is appropriate for your tool. Right? To me, those are 2 separate discussions. I think we start with the shareable forms because then the embeddable forms could use the same permission system and shared, configuration from the shareable form to then embed one of the shared forms. Right? That's kind of what I think that that would be a 2 step 2 step approach. Nope. I like that. So that's what you're seeing here. Right? So this is the current it's read only at the moment. Hard coded is read only. Even though we allow we've kind of plumbed this for role support in the future, it's currently read only. It's hard coded read only. So you get a read only form that looks like this, and it is to a degree, there are some permissionings. So the role does give access to the fields that are available and the relational content that's technically available and visible in the form. So you can see here my image isn't showing because I don't allow I haven't allowed the permissions correctly on that particular role. So you could have that kind of capability, And I believe we should I haven't tested this, actually. I because I'm logged in as an admin right now, but I think we can restrict the role list here based on the so the the allowed roles and permissions for the user. Permissions again? Yep. Exactly. So permissioning should control what's available in this list. So I think, again, I think the general plumbing is there for a shareable, editable form? The question becomes, what is it that we're sharing? You know, are you allowing them to create a an item from the form? What does that look like? Because right now, we are sharing an existing record. So there'd be work to be done around that, I think. Absolutely. As an embeddable I like the embeddable idea. Technically, you can kinda do that already. You know, we we see examples of that in the structures that, our good friend, Bryant, has set up where, you know, he set up these kinds of forms where Right. He's almost replicating our schema management capabilities of being able to create an editable form. So he's made it so that you can create a schema field, add whatever, you know, value type. This is a And as we're talking segue into, the second question I wanted to bring up, which is for shareable forms, are we sharing an existing form and you will still limit it down. Limit it down. Or is it effectively a separate form builder where you can create one of forms that you then connect the dots between that and your actual data model? Yeah. Similar to I think our our CRM has that kind of capability where you can build a form. Right? And then behind the scenes, the data gets stored wherever you direct those fields to store. Exactly. But you've got an and it's embeddable as a you know, you can get it as a link or you can direct them straight to the form or you can embed it as an embeddable link underneath the hood. Because the one thing I do recognize about the current share system is that it's a little bit a little very opaque. What's the right word? It's a little opaque to to know what you're sharing. I mean, by default, you're sharing what you're seeing. Right? It's like you're sharing the item that you're currently seeing. Yep. But what's actually gonna be shown to the user is different. Right? So you have to go check the link and see what it's gonna look like versus It's because it's based on the role that you then associate with the share. So if you use your own role, it's what you see is what you get. But other than that, it's a bit of a, you know, to your point, you have to create the share, pull it up, double check. If you're creating a dedicated form to share, be it read or write, that confusion is taken away immediately because it's the form that you created. It's the form that you're seeing. Right? I think the big question then becomes, how do we handle permissions if at all? Do we auto generate the permissions based on the stuff you put in the form? And therefore, you make it very explicit. Like, you put, an email address field, so therefore, you can see an email address. Or do we make it a little more opaque again by associating a role or multiple policies to TM to control the permissions for that shared item. Right? That's that's where it's a little finicky. So when when I meant that permissions, for example, if, where permissions become really important is for nested relationships. Right? So if you have a read item with a many to one field to a related category or something, what part of the category are you also supposed to be able to read from this entry point of the top level item? So having some sort of permission set there is gonna be required. Because otherwise, theoretically, if your relationships are a little complicated, you could pose a hell of a lot of data. Right? Because if we were to say, auto generate all of them, if you have a user created field because you just wanna show somebody's name, avatar, you could now theoretically go to that user record and you go to a direct to files record because you now have that connection through the user. Right? So that also, makes me wonder, there's another feature request that is completely unrelated to this, but it might actually directly be related now. One that I opened, I feel like 20 years. It's configuring access control permissions based on a parent child. So instead of saying, you have access to direct these files, you have access to direct these users. It's saying the permission, you can read a file if it's attached to a user if you're coming through the user and only then. Oh. Oh, yeah. Yeah. Yeah. Yeah. Yeah. That's, that would be very cool. That would be very cool. Top the clock. I think we need to need to start a new game. It's like, at what point do we get Jonathan to do that? It doesn't take much. It doesn't take much. Because because that would that would also potentially solve for this. Because then you could say, okay. If you have many to 1 on the record that you're sharing, you now have access to read just that one record from the related table, but nothing else from the related. Right? And for the record, that is how the current share system works actually under the hood. It is a hell of a lot more complicated, because what it does is it looks at the item that you're sharing and it checks what items are related, and then it makes a new permission set that says you can read just that one item from the related table. Right? But all of the other API ends work the same, which is interesting. But that's that's the way it does it right now. So it does actually, you know, specifically look up which items are related, which items are shared as per the role, but then lock it down to only allow you to ex that one particular item that is associated to the shared thing to make sure that we don't overexpose data in your system. Food for thought. But it it, you know, we're getting real quick into the weeds here again. Just from the question, is it sharing the existing form from your data model or are we sharing new one off forms? It sounds like and I've I've it it sounds like we probably wanna look into some sort of system. You can create individual forms and associate them back to your data model. Just in those cases where you wanna have multiple different forms with different fields that go to the same item. Commonly the case. Right? So if I was setting up a, you know, a a newsletter subscription, I might have very simple, but I still wanna register the contact. I still wanna be able to, you know, track their compliance or other things that I may wanna track or need to track versus the same contact information I would collect for a you know, you're signing up for a meeting or a webinar or something else. So the the forms can be storing data to the same places or to additional places. Follow-up question. What is that? One of these public forms, and I'll I'll get to Tim's question in the chat very soon because that's another level of complexity. But should we allow one of custom forms to save to multiple tables at the same time? Yes. Technically, yes. Form can one form create 5 different records in 5 different tables? Oh, I think it must. Right? Because of relations? Well, not even relations. Go Independent of relations. Right? Yeah. So if I'm if I'm setting up a form to collect, medical data, you know, to sign you up or set you up or do something or I'm collecting a survey, I might have survey information that I'm storing in the survey table, contact information I'm storing in the contact table. Just simple example. Right? Just 2 tables. But the contact information is in one place, the survey data is somewhere else. And I may from a from a compliance perspective, I may not be associating the user. I'm just tracking that the user responded, but the survey data has to be independent. Right? No relation at all. Here's one quick question. Good point, but Tim, wait beef before we go further further down the rabbit hole, there's another good point by Tim. It it it really sounds like a job for a flow or hook. And I think I agree, actually, because, like, the complexity then of setting it up and then the UI that has to be added for that and, stuff that could go wrong and stuff. Like, maybe, you know, just as a as a simple example. Okay. You have you just make one row in one table. That would that could be the cutoff that we decide on, maybe. I don't know. But it it really sounds like maybe a hook or a flow would then should be responsible for, you know, taking the the depending on the status, it takes the user's email and puts them also into the contacts table or the whatever table. I think I agree with that take. How do you guys feel about that? It's both ways because you could say you'd save all the data to a table and then run the flow based on that change or you save the form to a flow and then handle it yourself. I and I think there's a case to be made for both because for a simple contact us form that is always going through the same table in the same format and it matches your data model, it feels like flows could be a lot of, you know, complexity to configure just for that simple use case. But for everything else, I fully agree. Once you go, I wanna touch 5 different tables and I wanna submit to a different web, and all that kind of stuff. Yeah. Form to a flow, makes a lot of sense. Right? Right. So let's blow up this, let's blow up this discussion further because Tim also said, alright. How about, should public forms be able to save to a specific content version as well. If you call the first deal with the safety of a specific content version. Well, the nice thing is if we're going with this whole form safe to flow as idea, then sure do whatever you want. Right? That's that's kind of the beauty of the escape hatch that could be flows as the back end forms. Because at that point, if you wanna save it to a conversion, go for it. Right? What do we care? What when how when would you use that, though? Let's think about that for a second. So you have draft state basis for an item. I guess if you were updating existing content, you may wanna do that as a version, possibly. Typically, in shareable forms, I don't see it as a version necessarily. But if you were allowing someone, say, to update but even then revisions would track the the content changes over time if you were inclined. I I think yeah. What I was just about to say is what Tim again just put in the chat. Let's say you want to review and approve the changes that were made in pub. Right? So if you're running a sort of Wikipedia style, Wiki style, page Mhmm. And you wanna allow people to suggest edits, you could have a public form to update that one particular page, and then those updates go into a version that then can be reviewed and approved by the old person in charter, which is an interesting an interesting use case. That's a cool that's a cool freaking use case. Which actually would be very convenient for our own docs for that record. For example, that's what I was thinking about. I have the little button on the bottom here. Edit this page. Edit this line. That would be very cool. Hang on. Another use case from the audience in, in that updating existing thing from, Jay Shue says, another use case is a business directory and the users being able to suggest changes. Agreed. And the Durb saying we could actually use that fairly well as well. That's it. It could be implemented in flows. Right? Which is where it gets interesting again. Right? Because flows really become that sort of escape hatch for this type of stuff that, like, oh, you wanna save it to a version instead of to a table? You wanna save it to a different whatever you wanna do. Just use a flow. It it does also answer the question, is this just for create or is this also for update? And I think we've just concluded that also updates are important. Click updates. That's when you can do you can update an existing submission that you've already done, or you could, you know, the Wiki example or the business directory example or some of those. Yep. I think about, in particular, things like, you know, some of these online forms could be fairly complex. Right? I've I've done this. I've I've got you know, you're filling out something for a financial thing and you, you know, it's gonna take you an hour to do the form while you may be saving and coming back later. You can come and go from it. We do a lot with secured online security forms, you know, where we're filling out answers to complex questions that take hours or days to finish. And so, essentially, saving state and coming back and making updates and, oh, I mean, I I wanna fix that answer that I did, you know, 3 pages back in the form, and I wanna go make that adjustment. I think we found another use case for the saving it to a version. Mhmm. Because if you save it to a version, the validation of the database doesn't have yet because it only needs the saves to the database rather than to your stage to changes. Right? So the, what would you call it, plausible forms where you can enter a bunch of stuff, hit save as draft basically, and then come back later. That would be relying on content versioning. Good. Yep. Good very well. Doesn't have to, but it could. Right? You can manage that via state or status or other things as well. But, yeah. Unless you're thinking about validation in that case. Right? If you have data integrity rules that say the column cannot be So in your form, it has to be filled out. But you don't want the force to use the whole form once, you need to have an in been safe, which would be, you know, a version conversion version. I like it. It's Okay. Let's I need to switch to a slightly simpler question. Otherwise, my brain is gonna go What about deletes? Is Is that a thing you do publicly? My first gut reaction was no. Hell no. But, let's give it a little more thought. But I guess if it's user data, I don't know. I could see a use case for it. I don't I don't think from our side of things, if depending on how it's implemented, If you got compliance issues, GDPR, other kinds of things where the user has the right and choice to do that, that's that's gonna it's gonna be very use case specific. Because for the case we we try not to delete data in general. We put it in the soft archival state. You know, we use status or other things to handle that. But where you have compliance requirements where you must delete, But I don't know if that's a form. That that could be flows driven. That can be log business logic driven at that point as opposed to something to do with the form itself. I think you'd have to have a form that says I wanna I want my data to later. I wanna unsubscribe. And by doing that behind the scenes, the flows and data data management happen the way that you need them to happen. Right. Because I I could imagine that the because because deletes blank at least sound kind of insane. Because you would have what? You would show the user, here's all the records and go whichever delete whichever one you want. It that that feels like not something that you'd realistically want. But I could imagine that if we connect it to an account again, not not so much a a direct as app account, but, like, the moment you create a form submission, I could imagine that you maybe wanna do a public read of a layout. Here's a new question that we're gonna discuss in 5 minutes. Where you can just as a user as a temporary user all the submissions that you've done in the past and then delete a previous submission. To me, again, business logic. Right? That that tends to be not so much I I think you'd I think someone suggested it here. I think you'd do it as a delete request. You'd submit a request to delete and then confirm whatever mechanisms. Your your business logic, your flows, your your any additional code processing that you're doing on top of that would handle those things and send notifications accordingly. Feels very much like you would submit that as a specific form request to remove data, not the ability to delete data from the form. I think I agree in general that that shouldn't be allowed. You'd have to submit that as a separate form, maybe. I don't know. I'm sure there's a use case that I'm not thinking of. But Yeah. But to your point, if you create a new form that triggers a flow rather than saves to a table, that flow then just deletes it, whatever, based on your business logic, then prop solved. Right? You you don't necessarily go the mile to Yep. Have native victim delete support for that specific of a use case. Okay. Interesting. Interesting. Interesting. Interesting. Tricky. Tricky. Tricky questions. Tricky questions. Another another question in the chat here from user. So what about editable forms or relational data where items can be deleted after it's been saved and the user edits the data? We got it. Ladies and gentlemen, we got it. That's the real goal. If we can get right to do it, then we're then we're successful. What about editable foreign situational data where items can be deleted as it's been saved and use it as the data? I mean, I guess that kinda goes for any editable forms that it's like, user creates it, admin changes it, user tries to edit it, and that looks different. Which, yes, it will look different because you changed it. You changed somebody's submission. Right? I think that becomes becomes more of a workflow or a business process, thing where tell your staff don't touch, you know, don't go changing somebody submission. That's bad mojo. But I guess yes. What about resubmitting of shareable forms? We're kind of in the midst of thinking this through because, in the beginning, we said, okay. If you have a fixed link that you can send somebody and then they submit the thing, we could restrict that you can only submit once with that link. Or you can have a general link where, like, every single submission results in a new row every time. But then it's very use case dependent, I think. No. Like, that should be just configurable. Okay. Is this, will this result then in a on on my second visit to that link, will it show me the actual item, or is the form empty again, and can I resubmit it? I mean, that's, like, very dependent on on on the configuration, I think. Yeah. I think it should be doable, though. Some additional configurations here, potential validation checks. So, again, if it's an embeddable form or it's a shareable, editable form from our side, then this is gonna need some updating as well. Right? We'll need some additional parameters and things here. You'd have to potentially check the data, validate the data on save. Flows, again, can handle some of that, but to give the user feedback of you've already submitted or disabling the form because they've already made a submission. How do we check that? What does what does that look like? Because now you actually have to have something, you know, activity wise that says your device or whatever has been registered. We know that it was you, and you've already submitted the form. Yeah. That gets that's where I I don't know. It almost feels like that should just be front end dev work and get managed from that side of things. But Oh, here's here's the problem though, Jonathan, when it comes to the form that we're sharing, who's the front end dev doing the work? It's it's us. It's us. It's us. I know. So this needs more complex kinds of things because now max 5 uses, well, is that 5 users, or is that 5 you know, one person could submit all 5 or use all 5 values. Right? Is a user? What is a user? Right? What is the Are we getting deep? What am I I mean, that's that's kinda the question right now. I think about like same thing. We we track this on, you know, AppSight anyway, but now we've got this floating thing out there that would also have to track an activity record of who the IP and device and things are and be able to validate against that as part of this form configuration or this shareable form configuration. Now it's, you know, one time per user or per IP or, you know, whatever we consider that to be. There'd be something here, you know, max uses. So I want a 1,000 submissions, but then I wanna be able to also say per something. The the problem of the the how do you confirm the per something? Because you could say you could you could I mean, you could get away with it by just having a unique column. Right? That it's like you can only have one submission with this email address, and that's it. Done. It could be unique. Already exists. Can save it. Done. Right? But how do you prevent somebody, you know, with a Gmail account, for example, you can do the plus something something and it will come back to you anyways. You prevent somebody from submitting times with the same, you know, plus 1, plus 2, plus 3, that will work. And I can use all information still. Because there's no way for us to validate that. And then, you know, for email specifically, you can start thinking about, maybe we have some sort of email validation or we send an email and you have to click confirm or all that kind of stuff. But then what happens if you wanna use something else as the unique identifier? What if you're doing some of the phone numbers? Right? Where it's like, enter your phone number, we'll send you a text when it's your turn to to for for like reservations. Right? If you're doing a reservation at and it's it's that's that's very common around here. I don't know. Over in your parts of the world. But, you know, if you go to a restaurant here and it's full and it's like, oh, your your table's gonna be about 40 minutes and you your phone number, they'll send you a text when it's ready. Right? Mhmm. Or about 10 minutes before it's ready. So in that case, you wanna duplicate it on the phone number, but how can you confirm that? Right? You you can't really, there's no way for us to know that. A simpler a simple example would be if if you have first sorry, the delay delay is giving us. No, but but a simple example for, limiting that kind of, use would be, let's say you have a form that you can resubmit with, let's say, you have an online shop and then you want to use this for functionality for giving out promotion codes, and you only want to give out a 100 promotion codes, okay, Then it's just a matter of counting the rows, you know, so so we don't have to have a unique field or whatever. We just say, okay. This form can be submitted 100 times. That's it. I think there's like, it's a little different to your guys' use case, what you just described with the email and and phone and whatever. But, I mean, this is also a valid use case, I think. You know? I I want this form to just be usable for 100 submissions. Okay? Then it's just a matter of counting. Mhmm. Well, that's our that's already built in. Right? So we already support that max five uses. So and we keep track. Similarly, if we want this to be 1 per or 2 per source, right, then we have to actually track from a and, I guess, because it's an embeddable form or it's a, you know, we we have information and knowledge about the browser. Right? We we can track that. It just requires that we store the activity information and utilize that as part of the additional values here in a sense. There's still ways around. Right? There's always a way around. I've got 5 devices, and I wanna submit 5 submissions. You know, I can I can do that, but and and, you know, we can do things like enforcement of uniqueness on the values coming in and those things? That's already there. It's more about can I at least track to know that this user has already submitted a form because of their IP address slash device ID, that we track anyway from the browser cookie side of things? I think, I think I'm reaching the same conclusion as Tim. It's like we're going down the bot detection rabbit hole, which is like, can we fingerprint an individual user? No. There's no way. There's there's no way because IP address is shared with the location. So, therefore, everybody in the same household or the same business is gonna have a similar bound IP address. So that that doesn't work. I mean, this this fingerprint in question has been a cat and mouse between browser makers and, you know, back end implementers. It doesn't exist. The only way to do that is to require a sign through some sort of secondary authentication method, like send you an email with a magic link. So therefore, you prove you have access to the email, and that's it. Right? Before it submits or text with a phone number, that kind of stuff. Or log in through an SSO provide to confirm your, you know, your identity there, which actually is a different question I didn't even think about. But it would be kinda nice if you could sort of, like, connect the dots between what is your GitHub account click here to to o auth your way in to confirm, but that's not gonna be a 5 minute conversation, I don't think. Another question from the chat here, from from user and I'm gonna butcher your name. Sorry about that. Mama. That's what I'm gonna go with. How about the ability to show already submitted values to the user when filling out a form? Thinking about a sign up form for a party, and showing what food others already bring with them. Which is so this is an interesting question, which I think is not so much, the shareable, writable form. This is the question of readable lists of items. So right now, the share that we offer is just for a single item. You share that one. Right? What we don't allow you to do yet though, you can go to a layout and share the whole in a simple fashion. I could imagine that for this particular use case, what you would do is you would basically make a public share for your record of foodstuffs people bring to the party, long collection name, and then you can give people that link. Right? And then when they go there, they just see a layout like you would expect from directives with all of the stuff that has been previously entered with a click to to open an individual, I imagine, and then a, you know, a plug or something to go to the create page if you have create permissions through that public share. I think this is actually related to Hannes' question as well. More so because the food items being brought can be a many to many or a relational junction that's already there. So we'd show that in the current form. Right? Just like we did, you know, I only have translations in here right now, but equivalent kinds of things where you've got a a relational structure. The real question becomes when you're adding or removing relational items, this is considered potentially a delete operation under the hood. Right? So there there's there's a little bit of a tie between the delete conversation we were having and this ability to show or allow or not allow you to you know, you might be able to see what other people have brought, but you can't remove their food item. You can only add your own food item. Right? And or remove your own food item. I think role permissions generally work correctly for that, but it becomes a question of making sure that you test and set those things correctly. But is that considered a delete? Right? If you've got a cascade operation on, you know, removing a a relational item, well, that's potentially gonna cascade and cause a delete down the line. I think that would always be a deselect from the relational perspective. The Well, that depends on what you set your permissions for. Right? Oh, it's what you do. It's not permissions. The field oh, I guess it's what you set your field settings for. Right? If you set by default, yes, we set it to nullify so we don't actually delete any data. But if they've got cascade delete permissions, you know, if the cascade delete is turned on, that's going to actually delete data or contact. Point. Yeah. So the that's here's the security vulnerability way to happen. If you have an edit access to a simple item with a many the one many the one is configured to delete on select. If the user edit the field and they deselect, they now can theoretically delete stuff in your database, which is fun. Alright. Oh, jeez. It's already we're very we're already on on the dot here almost at 11. Oh, yeah. 11 for me. Times for everybody else. Just to to summarize all of this, because we went very much like this, but not a lot like that yet. We're running out of time. I think some some initial conclusions as far as I sort of take it now from this session. Right? It's like there's definitely a difference between shareable forms and embeddable forms. Shareable forms is part 1. Embeddable forms can then reuse whatever configuration that has for embedding stuff. I think that's conclusion number 1. I think to me, conclusion number 2, it's ideally you can create forms separately from the data model. Model. Although, that is quite a bit, you know, more involved to build and experiment with and etcetera etcetera. I think starting with create access is the most straightforward as you don't have problems with who can read what, how do you update previous submissions, how do people know what submissions they've previously done, etcetera. So in order of operations, shareable pages create first, then, read access for a listing would be very useful because then you have a way to click into an update item there. And then I think as a sort of your v 2, we should think about what do we form creation to look like in the first place and how does that tie into sharing? And a different question is, should sharing even be tied to collections and items, or is it just pages in the app altogether? Because I can also imagine that there's other places, like, folder in your file library that you might wanna share. Don't know. Like, another feature request for a different day, because I got skipped is, what about shareable dashboards from Insights? That'd be cool. But let's not do that right now. We'll save that for a different session. For now, Daniel, back to you to close it out. Thanks everybody for coming. If you enjoyed this discussion or are interested in other discussions, you can head over to directors. Iotv where you can find lots of other interesting shows and also this one. And, we hope to have you to see you again.","51185b87-e60a-4d5d-bf15-e09c4755ddd1",[183,184,185],"3eb120ac-4151-41d7-912b-e93b6568e197","93e88d6a-6f8d-4006-8efe-b1297a350658","901b7577-4fbf-48e6-84bd-f18438989693",[],{"reps":188},[189,245],{"name":190,"sdr":8,"link":191,"countries":192,"states":194},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[193],"United States",[195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":246,"link":247,"countries":248},"Michelle Riber","https://meetings.hubspot.com/mriber",[249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,226,437,438],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850442497]