Adding a new table from a file import allows users to input data into Mathesar without populating tables manually. This feature is also convenient for users who need to import data for testing Mathesar’s functionality.
While data file import is a baseline feature for most applications in this category, additional functionality will be implemented in the future to enhance the data import process, such as automatic type detection, data cleansing, error detection, and others.
This feature will improve the user experience for users who need to input data into Mathesar by reducing the required effort when populating tables.
This feature will also support the experience of first-time users, as it is expected by users of similar applications and would cause dissatisfaction if missing.
The user starts the process of adding a table by clicking on any of the available options. The user can add a table from the sidebar menu(1) or the ‘New’ menu located on the top navigation bar in the main content area.
Once the add table process starts, the user is prompted to set a name, confirm, or select the schema that will hold the table.
Using the lookup field, the user could also add a new schema from this dialog.
Based on PostgreSQL Documentation, some naming conventions apply to objects, including tables, views, and columns. For most cases, we’ll handle any necessary quoting automatically and transparently and generate unique names when required by adding a number as the last character.
null
character in a name.After confirming the table name and schema, the user must select one of the methods available for adding a table.
Implementation Notes:
Once the new table is created, The system will prompt the user to start the import data process. There are various options to import data, whether from a local file, clipboard, or remote location.
By default, Upload File is the selected option.
The user then proceeds to upload a CSV file, and once it’s completed, the system will render the file along with an option to remove it and upload another file.
In most cases, when the file is large, processing will take longer. For that reason, a loading UI state is needed.
If any errors prevent the file from being uploaded, an error message will be displayed.
If the system successfully processed the file, it will prompt the user to confirm if a preview of their data looks correct. The user can also choose to ignore columns, rename them, and change data types from this view.
Interactions for adding a table via file import focus on guiding the users through multiple steps, providing cues to help the user make decisions, and preventing unwanted outcomes by incorporating confirmation steps in error-prone steps.
Wizards are series of screens that guide users through multi-step processes.
In adding a table via file import, wizards are used to accomplishing some required tasks, such as selecting the data source to use (e.g., upload a file, paste, URL), mapping columns, and confirming field types.
The wizard elements should provide users with information regarding the length of the process, i.e., the number of steps. It should also provide controls to cancel the operation.
When triggered from a particular context, actions like adding a new table will have pre-determined options, i.e., the target schema for a new table.
For example, if calling the add new table function from the sidebar menu, the context will determine that the system must add the table to that particular schema.
However, a user might choose to add a new table from a different context, where there’s no pre-determined option. In this case, a user would have to select the desired option.
Making pre-determined options visible and editable in the interface can be helpful for users when confirming outcomes where contextual cues are missing.
Input controls allow the user to enter or select different values needed to perform tasks within Mathesar. In file import, they will enable the user to specify column types and parameters required to map columns.
Buttons allow users to perform actions and obtain a result from the system.
There are different types of buttons, and their use depends on several factors, e.g., the type of task they are to perform and their context.
Primary buttons are used for actionable (e.g., submit content, apply a change) and some exceptional navigational purposes (e.g., continue to a next step). However, their use should be restricted to priority or practical actions, with the ideal number of primary buttons being one per view.
Secondary buttons are used alone or in combination with primary controls to complement priority actions.
Dialogs are a type of modal window that appears in front of content and is used when the system requires users to make decisions.
When active, dialogs will prevent other content from being interacted with. In most cases, they are driven by user action, and their unprompted use is discouraged.