Editing Linked Records

[ghislaineguerin]

Description

Currently, users can't edit the properties of a linked record directly from the table view. To make any changes, they have to navigate to the specific record in the other table. We need a more efficient way to interact with these linked records without leaving the main table view.

Expected behavior

Users should be able to click on a linked record within the table view and edit its properties in a popup or inline editor. Changes should be saved and reflected immediately both in the linked record and the main table view.

Design Spec

https://hackmd.io/@mathesar/ry3ce4D86?type=view

[seancolsen]

@ghislaineguerin I don't think this ticket requires any design work because I think the design for this is straightforward enough. We'd have a context menu option on FK cells titled "Edit Linked Record". It would open a modal containing the form that we current display at the top of the record page. Unless you have other design considerations to work on, I suggest moving forward with this design by changing the "work" label on this ticket from "design" to "frontend" and changing the "status" label from "draft" to "ready".

[ghislaineguerin]

@seancolsen I did had some considerations for the design of this functionality.

Currently, when you click on a linked record, it offers the option to replace it. This replacement can be with a new or an existing record. However, this new record isn't created through a form; instead, the search criteria are used to locate the record.

I believe that if we were to incorporate a form, the user should be able to access it directly from the cell by clicking on the record badge, rather than through the contextual menu. I aim to prioritize this workflow as it likely occurs more frequently than replacing a record with a new one.

Additionally, I want to provide users with a direct way to use the form to add a new record from the record selector when a search hasn't been performed yet. It could be as simple as clicking directly in the cell to initiate the process of creating a new record.

For these reasons, I have contemplated a change at the cell level with three different states:

1. Empty, with the option to link (add) a record (including adding new via the record selector and form)
2. Linked, with the option to replace the record (requiring deletion of existing record and then addition of a new one via the record selector)
3. Linked, with the option to edit the record (opening the form directly from the cell)

For Option 2, the user would need to delete the existing link before pressing the link button to add a new one. Option 3 allows the user to access the record form directly from the cell.

[seancolsen]

@ghislaineguerin I'm confused by the cell having "three different states" your message above.

To me this seems very simple.

• Any FK cell containing a value gets a context menu entry titled "Edit Linked Record" like this:

  

• Clicking on that context menu would open a modal with a form like this:

  

Does my proposal make sense? Does this sound good? If so, this will be very easy to implement.

[ghislaineguerin]

Thanks @seancolsen. I agree that it is easier to implement. My point was to prioritize access to the form, from clicking on the record element instead of opening record selector. That's why I proposed a different set of interactions. I believe that will be a more frequent interaction than replacing records.

If you think we can discuss that in a future iteration then I'm fine with implementing the form as you've described for now. If not I'd like to know what your position is on prioritizing replace vs. edit.

[seancolsen]

Types of edits

We are discussing two kinds of editing:

• (A) Editing FK cell values

  We currently use the record selector for this.

• (B) Editing values within the records linked through FK cells

  We currently have no way to do this, aside from opening the linked record in its own page (potentially in a new tab).

You seem to be suggesting that (B) will be more common than (A). I think (A) will be more common than (B), but it's hard to know for sure.

It might be interesting to get some other team members to weigh in on this prediction and see whether they prefer your design which encourages (B) or my design which encourages (A). @pavish @kgodey would you care to voice an opinion here?

Ghislaine's proposal

@ghislaineguerin I understand that you'd like to prioritize (B), but the precise behavior that you're proposing is not clear to me. Let me take a stab at summarizing it to see if I understand:

• If I click anywhere within the orange pill, you want to do (B), right?
• And if I click on the downwards-facing chevron at the right of the cell, you want to do (A), right?

I'm still not clear on the behavior that you'd prefer when clicking in empty white space within a non-null FK cell. And I'm still confused by the "three different states" you mention. In one part of your message you refer to them as "states", but then later you seem to be calling them "options". I don't understand. I'm also confused by the fact that your mockup has a + button that we don't currently have, and it is missing the downwards-facing chevron that we do have. Perhaps this discrepancy is due to the level of fidelity of the mockup, but I'm not sure.

Overall, I'm open to a design heading this direction, but I have a slight preference for my design and I want to make sure we think through the consequences and get some other opinions.

Existing patterns

I wanted to see what other products are doing, especially since it may inform user's expectations of what Mathesar might do.

• In Google Sheets, clicking on a pill within a cell that has data validation edits the value of that cell.

  

  While Google Sheets doesn't exactly have FK cells, this behavior is analogous to our (A) behavior. By contrast, something like (B) would be akin to modifying the source cell used for the data validation (in the fruits sheet) and modifying all cells within the log sheet which reference that value.

• In Airtable, clicking on the pill does (B).

  

  Clicking on white space does nothing. And the only way to do (A) is to click on the X (effectively setting the cell to null) and then click on the + button that appears when the cell is null

  

  After seeing how Airtable works, I'm guessing that this is probably the behavior that @ghislaineguerin is proposing. Is that right @ghislaineguerin?

Preventing mistakes

Here's another angle to consider as we weigh our various design options: how can we prevent unintended actions? Specifically...

• How can we prevent users from doing (A), when they intend to do (B)?

  If a user wants to edit a linked linked record, they might click on the pill to edit it (especially if they are familiar with Airtable). Then, if we go with my design, they might be confused to see the record selector UI.

  But it's hard for me to imagine anyone submitting the record selector while incorrectly assuming they are editing an existing linked record. After all, fields will all be blank initially. Unintended consequences here would be limited to UX annoyances instead of actual data errors.

• How can we prevent users from doing (B), when they intend to do (A)?

  If a user wants to edit an FK cell value, they might click on the pill to edit it (especially if they are familiar with Google Sheets). Then, if we go with Ghislaine's design, they might be confused to see the Linked Record editor, like this:

  

  This is the point which concerns me. If we go with Ghislaine's design, we'll need to make it very clear to users that their edit is modifying the linked record their changes will be seen in all FK cells which link to that same record. I'm worried that this may not be intuitive to some people. They may unintentionally submit the form thinking that they're modifying a value which pertains only to that specific FK cell.

My design requires an additional step to do (B) — opening the context menu. To me, that additional step serves to represent the indirection present at the database layer. You need to sort tof "jump through a small hoop" in order to edit a record in a different table from the one you're currently viewing, and I think that hoop is a helpful way to give users a clear understanding of relational database principles.

To reiterate: I'm open to Ghislaine's design (following Airtable's pattern) but I want to think through ways that can adjust the UI in order to give users an accurate understanding of their actions.

[ghislaineguerin]

@seancolsen yes, what I’m proposing is a design similar to Airtable's. The reason is that it allows not only for editing but also for a quick overview of all the contents in that linked record with a single click. This would enable a wider range of workflows than just changing the FK cell's value, something that can be done directly when the cell is empty.

I also like that with this design, all actions can be done without relying on the contextual menu. It's usually good practice to provide users with alternative ways of performing actions available in contextual menus. I'm assuming that if we go with your option we'd add a button somewhere in the inspector panel for this purpose.

[seancolsen]

@ghislaineguerin

it allows not only for editing but also for a quick overview of all the contents in that linked record with a single click

Very good point! I like that!

I'm open to going with your design. I'd like to see what others think. The change you're proposing would be more work to implement than mine.

Some follow-up questions to clarify your design...

• Your design (like Airtable's) requires that I first set the FK cell value to NULL before I can select a different record. What happens if the FK column has a NOT NULL constraint? How do we allow the user to select a different record in that case? Should we use the downward-facing chevron as a button to open the record selector, like we currently have at the right of the cell? If so, then should we retain that button within the cell in all cases (i.e. even when the cell allows NULL values)?

• We designed our FK cell UX in conjunction with our FK input UX. Here's an example of an FK input:

  

  In the FK input, the pill is currently a hyperlink to the linked record. If we go with your design for FK cells, users might be surprised by the behavior of FK inputs unless we make some changes. If you click the pill on an FK input, should it open a modal, like it does when clicking the pill within an FK cell? If so, then how can we provide a means to navigate to the linked record? Do we put that hyperlink within a context menu?

[pavish]

@ghislaineguerin @seancolsen This issue currently focuses only editing the linked record. However, the suggested UX modifies existing behaviour and needs to take the entire FK cell behaviour into account, before we can proceed with it. As Sean has already pointed out, there are a number of things to take into consideration here.

Ghislaine said:

My point was to prioritize access to the form, from clicking on the record element instead of opening record selector. That's why I proposed a different set of interactions. I believe that will be a more frequent interaction than replacing records.

Sean responded:

You seem to be suggesting that (B) will be more common than (A). I think (A) will be more common than (B), but it's hard to know for sure. It might be interesting to get some other team members to weigh in on this prediction and see whether they prefer your design which encourages (B) or my design which encourages (A).

My thoughts:

While I think (A) would be more common, I also think that any opinion on this would depend on individual usecases and it's hard to say for sure.

I agree with Ghislaine's concerns on providing a quick overview of all the contents in that linked record and allowing editing it. However, I don't think it should come with the cost of replacing records.

I would encourage trying to find a solution that does not prefer one over the other and rethink the entire FK cell behaviour from a holistic perspective. We may want to do more research before coming to a conclusion on the UX. For eg., We can show the form in the Table inspector, and we could add keyboard shortcuts and additional icons in the cell, to open up the form or the selector, as the user prefers.

[kgodey]

I'm with @pavish. I don't think it's possible for us to make a determination on whether (A) or (B) is more common – my personal inclination is (B), FWIW. I think the solution is to to make both things easy, even if that means a more holistic UX overhaul (on both the table page and the record page).

[ghislaineguerin]

@seancolsen

Your design (like Airtable's) requires that I first set the FK cell value to NULL before I can select a different record. What happens if the FK column has a NOT NULL constraint? How do we allow the user to select a different record in that case?

We'd have an option to "replace record" in both the contextual menu and cell panel in the inspector.

Should we use the downward-facing chevron as a button to open the record selector, like we currently have at the right of the cell? If so, then should we retain that button within the cell in all cases (i.e. even when the cell allows NULL values)?

I think we'd get rid of the downward-facing chevron.

In the FK input, the pill is currently a hyperlink to the linked record. If we go with your design for FK cells, users might be surprised by the behavior of FK inputs unless we make some changes. If you click the pill on an FK input, should it open a modal, like it does when clicking the pill within an FK cell? If so, then how can we provide a means to navigate to the linked record? Do we put that hyperlink within a context menu?

From the record page, we'd still open the edit modal. The edit modal should have an option to go to the record page for that record if the user wants to. The same should apply to the table view. There should also be a contextual menu in both cases.

[kgodey]

@ghislaineguerin How will the UX you've outlined above work with keyboard based navigation?

[seancolsen]

I made this graphic to help understand the changes we're proposing. Perhaps it's useful to others too:

[seancolsen]

To put @kgodey's question into context with the above graphic, I think we have the following more specific open questions:

• For a filled, focused cell:
  • (A) Is there a keyboard interaction to open the record selector?
  • (B) Is there a keyboard interaction to open the linked record edit modal?

My responses:

• I think we should not use keyboard interactions here — at least not until we implement a more robust keyboard shortcut system (i.e. one that is fully discoverable, configurable, and documented). In Airtable, Enter does nothing for a filled focused cell, which seems okay.

[seancolsen]

Thanks for your responses, @ghislaineguerin. I'm on board with moving in this direction.

A added benefit of this design is that it brings the linked record cell into perfect consistency with the linked record input (which is not currently the case).

[ghislaineguerin]

@kgodey @seancolsen I've only responded to questions posted here. But I'm working on a full spec: https://hackmd.io/A3SJ887MRtC_YYZfGMwvpA I will incorporate your comments.