Setting up Table Preferences

[ghislaineguerin]

As part of the design for 'Foreign Key Usage' and as described in the specs PR we need to define a way for users to set up table specific preferences.

Table preferences

This new component should be part of the 'Table Options' dropdown and contain all the preferences for a table.
Preferences would then be any setting that only affects the table in the context of Mathesar, and does not alter the table object in the database. As an example, 'Table Constraints' couldn't be a preference, since it actually creates a constraint in the database.

Using a panel view with side tab navigation for preferences

For the layout, a paneled view with a side navigation could be ideal for the following reasons:

• It provides visibility for many options at the time, and scrolling if needed
• It can be helpful if we want to direct users to a specific option
• It can scale well if we allow users to extend its options at some point
• Easy to navigate across all preferences for users getting acquainted with the system

Setting up 'Search Columns' for a table

For the actual settings, I think the general idea is to have a way for users to select and decide the order of the 5 columns used to search and retrieve records.

The flow would have the following steps:

• The user goes to 'Search Columns' option
• The user sees a list of 5 column selected by the system, these are prioritized by constraints (primary key or unique columns) and then by type (text)
• If the user has less than 5 columns, all will be included, the order will be determined by the same criteria
• If the user wants to remove a column, they can click on the delete icon and the column will be removed
• If the user wants to add another column they can select it and add it to the list. If 5 columns are already listed, they will have to remove one

Feedback

This is a very rough design and the type of feedback I'm looking for is a high-level one.

• Does the concept of table preferences make sense?
• Do you think grouping preferences the best approach? Do we want instead to have specific menu options for each?
• Do you see any problems in adopting the panel view layout for presenting grouped options of any kind across the entire product?
• Do you think the steps described above are clear and solve the users problem? Do you envision any scenarios where this might be confusing?

[kgodey]

For the actual settings, I think the general idea is to have a way for users to select and decide the order of the 5 columns used to search and retrieve records.

I don't think we should support ordering the columns, that will add a lot of additional complexity to the implementation.

Does the concept of table preferences make sense?
Do you think the steps described above are clear and solve the users problem? Do you envision any scenarios where this might be confusing?

Yes, but I don't think it solves the problem completely. I think we also need to show the user these preferences in context. e.g. imagine a user searching for a foreign key and not finding what they're looking for because the right columns are not selected. We need a way to point the users to where to set their search columns.

[silentninja]

From the wordings order to be used when searching I thought it meant giving more weight(preference) to a certain field during the search, but what it actually does is order the fields when the results are displayed, is that correct?

[kgodey]

@ghislaineguerin Since it's only five fields, I'm not sure the order will matter and it increases complexity for implementation (we have to store the preferences somewhere and the frontend has to obey them).In addition, the ordering could refer to different concepts (display order vs. search preferences) and it might cause confusion to the user. I'm not sure that ordering solves a major enough problem for users to be worth the extra time for implementation.

[pavish]

I assume @ghislaineguerin is referring to the order of the columns shown in the search result cards when the user is searching. I don't think this order means the order of search itself.

[ghislaineguerin]

@silentninja @kgodey I was referring to the order in which the fields are displayed. Similar to how Airtable lets users define the order of the fields to be displayed in the card view. And yes, @pavish is right, it does not impact the search, it was simply a display setting.

[kgodey]

@ghislaineguerin Yes, I understand, but it will still increase the complexity of implementation to support different orders. I'm not sure it's worth it.

[seancolsen]

Generally this looks great to me, @ghislaineguerin

We'll have smaller details to work out as the design becomes more specific, but I think this is a great direction to head.

[mathemancer]

I think this makes sense overall. I'll defer talking too much about the search column setting, other than to note that we should try to encourage and promote using columns involved in unique constraints for this. We should probably strongly discourage using non-unique columns for this, both because they aren't as useful, and because they would introduce a serious performance cost.

As for the idea of the "preferences" interface you've set up, I think it makes sense and would be what many will sort of expect for that. I wonder if there's some way to help a user navigate smoothly from overall table preferences to preferences for a given column. Maybe that's not wort the trouble, though.

[pavish]

@ghislaineguerin This discussion seems to touch 2 areas.

• Using a panel based view and grouping settings
  • UX wise, I think it looks good to have grouped settings in a panel view throughout the product.
• Configuring Search columns.
  • This sounds good to me. However, it is only mentioned on how the configuration of search columns is done but not how searching itself is done on the referred tables. It would be better if we had it both on a single discussion with the whole flow.

Configuring search columns while searching

• Users are only concerned about the searchable columns when they are trying to search from a different table/view.
• Based on this UX,
  • User has to open up the referenced table in a different tab
  • Then user has to click preferences, and choose the searchable columns list
  • User then has to save, come back to the table they want to work on and continue
• This is too much redirection. The argument is that the user would not have to go through this again but even after saving these settings, the user sometimes might temporarily want to search with just one column or a known set of column or want to provide different values for different columns to search. We don't want them to come back and keep updating the settings for such cases.
• I think it would be better if the user can also configure the search columns while they are searching without redirection. This will not be saved and only used temporarily. We could open up a different modal with a tag based search input for this.