Lookup Field Component Specs #233
Replies: 3 comments 11 replies
-
|
No loss of data, but with option two, they might have a typo resulting in failure to find the schema, and inadvertently create the new schema if they're not paying attention. They might end up with some tables in I.e., an extra step for safety might be warranted in this case. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @mathemancer here, creating a new schema involves a major change to the structure of our database, so I think it makes sense to confirm with the user that that's what they want to do. |
Beta Was this translation helpful? Give feedback.
-
|
I agree to this as well. However, I do not think that it is a component level decision. For the component, I prefer option 2, as it is more ARIA friendly. For the schema creation flow, I would prefer having an explicit message before creation, showcasing a list of all the changes that will happen on the DB, and asking for confirmation from the user. Thoughts? Also, for the Import flow, I think having the table name and schema lookup field within the content pane, instead of a modal, since that will allow the user to edit it even after the file is uploaded. This was mentioned earlier on hackmd, just an additional reminder. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we need to showcase a list of changes happening in the DB, that sounds like it would be intimidating to non-technical users. I think making it clear that they're creating a new schema should be enough. @pavish I might be misunderstanding what you mean, though, so maybe you could do a quick sketch of what you mean? |
Beta Was this translation helpful? Give feedback.
-
|
@kgodey I was thinking of something like this, after the upload completes, and before the table gets created:
I understand that it might be intimidating for non-technical users, especially those not using their own databases. In that case, we could only show an additional explanatory text below the lookup field mentioning that the schema will get created. |
Beta Was this translation helpful? Give feedback.
-
|
@kgodey @mathemancer I've been thinking about the requirement of creating schema from the lookup field and the potential consequences of errors, at it seems to me that the benefits of adding a new schema in this way, aren't necessarily strong. Should we allow users to only select existing schemas and have to create them instead in a different context that provides a better experience? |
Beta Was this translation helpful? Give feedback.
-
|
@ghislaineguerin I think moving schema creation to a different context makes sense. I created a design issue for this already: #170, we can figure the design out when we get to it. For the file import step, we can assume that we are picking only from existing schemas. |
Beta Was this translation helpful? Give feedback.
-
|
I also agree with moving it outside of the modal, I thought we had already decided to do that. |
Beta Was this translation helpful? Give feedback.
-
|
I am still not convinced of moving the creation to a whole different context. We could move the schema selection and table name input from out of the modal to the import content pane, as discussed. As a user, I would really appreciate being able to create the schema on the same page itself. I wouldn't want to move to a different page and get back here (Although I do understand that schema creation is a relatively rare operation). However, I do not have a strong opinion, I'm inclined to go with your recommendations. |
Beta Was this translation helpful? Give feedback.
-
|
I do think we should try not to interrupt the user's flow when they're creating the database objects they want (people may want to create schemas while creating tables). However, part of our goal with Mathesar is to guide users into good ways of setting up databases, and we don't necessarily want people to think they need a new schema for every table. One way to think about schemas is as equivalent to Airtable Bases (not entirely accurate, but I think it works in this context) – all related tables should be in a single schema. So it seems like a good idea to me to get the users used to the idea of operating within a schema, rather than picking a schema for every table. @ghislaineguerin you probably have enough feedback to make a recommendation here. |
Beta Was this translation helpful? Give feedback.
-
|
@kgodey @mathemancer @pavish |
Beta Was this translation helpful? Give feedback.
-
|
I've read it; looks good. |
Beta Was this translation helpful? Give feedback.
-
|
Looks good. |
Beta Was this translation helpful? Give feedback.
-
|
Looks good to me! |
Beta Was this translation helpful? Give feedback.
-
The lookup field specs add more detail to a component included in the design of Add table from import
Please follow the Review Guidelines
Two alternatives are listed in the document, and I wanted to include both as I considered the two options during the design process. However, I feel that the second alternative has very few drawbacks. The feedback I'm looking for is potential scenarios that I might have missed or improvements that could increase usability or user experience in general.
Feedback Questions:
Document
https://hackmd.io/@mathesar/rJzSXoxou
@kgodey @pavish @mathemancer
Beta Was this translation helpful? Give feedback.
All reactions