Inline Data Editor

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.

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?

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.

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?

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.

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?

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.

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?

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.

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

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.

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.

Speaker 2: Yep.

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?

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?

Speaker 1: And it can even differ,

Speaker 0: you know, from from to

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.

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.

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.

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.

Speaker 1: It's it's a presentation, presentation layer. Yeah. Yeah. Yeah.

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

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?

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.

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?

Speaker 0: Mhmm. Mhmm.

Speaker 1: So if we're just The same for page titles for the for for that matter or the calendar layout. Yeah. Yeah.

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.

Love it.

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

Speaker 2: up with that right now.

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.

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.

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.

Maybe, you know, I'm just, you know, throwing stuff in the room right now just to discuss a little bit. But Yeah.

Speaker 1: Because it does have the mute display thing. Yeah.

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.

Speaker 1: Stack a can.

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

Speaker 1: Like, I think expectations is the word I would say. Yeah.

Speaker 0: 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

Speaker 1: different feature requests for a different day. Yeah.

Speaker 0: Exactly. Exactly. Exactly. So spreadsheet seems to be a very big thing, for me personally. Yeah.

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?

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?

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.

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.

Speaker 1: There's also the the, the bigger question here, Which is

Speaker 0: As it always is?

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.

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.

Speaker 2: So depending on the interface type or the interface implementation, you could allow or disallow inline editing ongoing. Right? Right.

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.

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?

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?

Those are the, you know,

Speaker 1: the The the simple somebody in the the chat called it the simple

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.

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.

Speaker 1: Woah. Say say that again. So That last part,

Speaker 2: if you

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.

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.

Speaker 1: 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.

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.

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.

Speaker 0: Yeah.

Speaker 1: Because the,

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.

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.

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.

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.

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.

Speaker 1: Yeah.

Speaker 0: Wait. What did the doer say?

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.

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.

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.

Speaker 2: Yeah.

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.

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

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?

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.

Speaker 0: Right? Shot's fired.

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.

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.

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.

Speaker 1: What? Oh, man. This derails very quickly though. Next session, we'll spend, it's a full hour on the Imperial system.

Speaker 0: Oh, no. Somebody's actually this relates to the discussion. Yeah. Great. Okay.

Sure. Sure.

Speaker 1: Okay. Yeah. Yeah. Yeah. Yeah.

This yeah. At least take a bit of context.

Speaker 2: Everything should be millimeters. He's Google. The Australians got it right there.

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?

Or as as inches.

Speaker 2: Oh, don't do it. Don't do it. Just do millimeters.

Speaker 1: Well, yeah, that's not always appropriate.

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.

I actually flip all my stuff. I use Metrc on everything now.

Speaker 0: Good boy. Good boy.

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?

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.

Speaker 2: Drop down, you get your whatever.

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.

I think when you have a small, text input Drop downs.

Speaker 2: Drop downs, same thing.

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.

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.

Speaker 2: Very much agreed.

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?

Speaker 2: I like it.

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.

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.

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.

Where do we control what pops in, what doesn't pop in?

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.

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.

Speaker 0: Interface is all the way down.

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?

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.

Speaker 0: That sounds good to me.

Speaker 1: It'd be a gigantic rate and change, so don't worry about that.

Speaker 0: This is not something we can just

Speaker 1: in a little 10.1. Here you go. Bang.

Speaker 0: Looks good to me. Ship it.

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.

I think there's there's something to it.

Speaker 2: Very cool stuff.

Speaker 0: Good stuff, guys. Any last questions from the, audience? Your chance is now.

Speaker 1: Forever hold your peace. Winston.

Speaker 2: Final cue.

Speaker 0: Forever hold your peace.

Speaker 2: If you're if you're still awake.

Speaker 1: Yeah.

Speaker 2: Oh, let's see. Vincent.

Speaker 0: Someone type it. Well, then, thank you everybody.

Speaker 1: Thank you. Bored everybody to death.

Speaker 2: We've hard hard boiled a few eggs.

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.

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

Speaker 2: great day. Enjoy your week, folks. Have a good night. Good

Speaker 0: night. Strong feelings, please let us know. The discussion is open. The issues are open.

Speaker 1: That way.