Forms QA

[Sean Colsen]

Hi team. Here is my QA of forms.

For the sake of follow-up discussion, I’m separating distinct points of critique by sections with snake_case titles.

Blockers

(I think we should fix these before releasing forms, even if it means delaying the release.)

description_layout_overflow_in_builder

A long form “description” value causes layout overflow on the form builder page after the form has been saved. This makes the page unusable. The form’s Save button becomes off screen, making it hard for the user to recover the form. To fix this, we should remove the description from the top of the page since it already appears in two other places on the page.

description_content_overflow_in_fill_out_page

Writing a long paragraph as a form “description” leads to content that does not render well on the form fill-out page. The line overflows the form container, truncating text with no way for the user to read all of it.

fill_out_field_tab_order

The tab order of fields when filling out the form is messed up, making it harder to fill out the form.

Pages and navigation

(The way the various pages fit together does not exactly match the behavior that I was expecting from Forms. I find it a bit confusing. There are a number of small points of critique I have on this topic, which are all somewhat related, so I’m grouping them together here. There’s a good deal of nuance to this topic too. So it could be a good one to revisit on a call.)

• I was not expecting us to have a page for authenticated users to fill out a form. I was expecting this feature to be only for anonymous forms. I can certainly see forms are useful beyond anonymous users! But this extra use-case adds extra complexity and design considerations — especially concerning navigation.

• If we have an authenticated form fill-out page, I would expect that the role used when submitting the form would the the collaborator’s configured role, not the form’s “associated role”. I think the form’s associated role should only be used for anonymous form fill-out. As such, I think the associated role should be part of the form’s “share” settings. If you don’t configure a public share link, then you don’t configure an associated role.

  I’ll note that this behavior is potentially challenging to change later on, because it has the potential to break users’ workflows. So it would be good to make sure we’re considering this before the release.

• Navigating the various forms pages currently feels awkward. The authenticated fill-out page is accessible from the schema page but not from the form builder, whereas the anonymous fill-out page is accessible from the form builder page but not from the schema page. I think we need better linking across many of the various pages.

  Here’s a diagram. Solid lines represent current navigation paths. Dotted lines represent missing navigation paths that I think we need.

  So I think we need to add ways for the user to navigate:

  • From the form card on the schema page to the anonymous fill-out page
  • From the builder page to the authenticated fill-out page
  • From the authenticated fill-out page to the builder page
  • From the authenticated post-submit page, back to the authenticated fill-out page

• Given that we have an authenticated form fill-out page… and with some work to improve navigation from the authenticated fill-out page to the builder page, I think that internal links “to the form” could potentially point to the authenticated fill-out page (instead of the form-builder). For example, the links in in the nav menu — and perhaps even the form card links in the schema page — could go to the authenticated form fill-out page. Then the user could click an “Edit Form” button to go to the builder page. This would feel a bit more intuitive to me. And we could replace the “Edit Form” menu item on the form card with a hyperlink to the form builder page.

High priority

(These are things that I think we ought to try fixing before the release if possible.)

empty_submission_error_message

When a backend error is encountered during form submission (e.g. unique constraint violation) the error message (in the toast) displays as blank. We should display some text.

semantic_field_labels

Form labels should be semantically tied to inputs. This way, clicking on the label focuses the input.

submission_error_display_format

When a backend error prevents form submission, currently we display an error toast. I think we should display a (persistent) error box below the submission button instead.

associated_role_help_text

I think we need some help content to explain what “Associated Role” is. This could be a hover question mark or a more persistent blue box.

field_nesting_formatting

On the fill-out page, it’s a little hard to visually understand the field nesting. I’d like to see some additional visual cuing here to make this clearer.

Lower priority

(These would be nice to do, and are also fairly easy.)

auto_suggest_form_name

When creating a new form, it would be nice to auto-suggest a name for the form after the user has selected a table. I think using the name of the table would be best, so long as a form does not already exist with that name.

fk_column_field_name

For FK columns, I think it would make more sense to title the form field using the column name instead of the name of the related table.

dynamic_defaults

You seem to have logic which prevents columns from being added to the form if they have dynamic defaults

And you said (at 2:40):

The end user cannot actually fill values in columns that have dynamic defaults

But Mathesar does allow the user to fill values into these columns. For example, in the Service Milestones table, if you make the notes field NOT NULL and insert a record, then you can choose your own value for the update_time column whin the draft record row.

To me, a form is very similar to a draft record row. So I think we should allow users to manually add these columns to the form.

Perhaps we still don’t automatically add them though. I think it would be reasonable to say that any time a column has any default value (dynamic or static) then the column does not get automatically added to the form.

logo_on_authenticated_pages

I don’t think the Mathesar logo should display within any of the authenticated forms pages

logo_formatting

On the anonymous form fill-out page, I think the logo should be smaller and part of some text that says “This form was created with [logo]“

builder_page_padding

There is some padding on the padding on the form builder page that I think looks weird. Instead, I think the area with the lighter background should behave the same as with the table page. Aside from a small gap, its left edge should extend all the way to the left edge of the viewport, and its right edge should extend all the way to the left edge of the inspector.

selected_field_hover_bg

When a field is selected, I don’t think it should get the red background on hover.

selected_field_label_input_style

When ia field is selected, the inputs for the label and help text do not have padding, border radius, or top/left/right borders. This style is inconsistent with other text inputs, and (to me) is somewhat aesthetically displeasing. I would be inclined to keep the standard padding on these inputs but shift their alignment to the left in order to obtain the desired text content alignment with the form input.

responsive_field_building

The form building behavior could use some minor improvement on narrow viewports. In particular, a selected required FK field has some UI that doesn’t wrap very nicely.

For future consideration

(These would take more work and aren’t pressing, so I don’t expect us to get to them soon)

full_stack_required_field_validation

When a field is nullable at the DB level but marked as required in the form, the validation is only implemented on the front end. This is bad because it’s still possible that empty values can end up being submitted. For example:

1. Mathesar user creates the form
2. End user loads the fill-out page
3. Mathesar user updates the form to mark a field required
4. End user submits the form

table_page_navigation

It would be nice to incorporate some way for the user to easily navigate from the table page to any forms built from the table, plus create a new form from the table.

column_dropped_after_form_created

Handling of dropped columns within the form definition is not great. There are a number of things we could improve in the form builder, form fill-out page, and form submissions process. Overall, this seems to need more thought, design, and implementation.

required_nested_in_optional

The UX of the form builder and fill-out page makes it awkward to handle the case where an optional FK is is marked “Must add new” but the referenced table contains a required field. It works okay when the user filling out the form wants to add the related record. But it’s impossible to fill out the form without adding the related record, even though the top-level FK field in the form is optional. The overall design does not allow for a top-level FK field being NULL without also giving the form fill-out user the option to select an existing record.

​

[Zack Krida]

Thanks for putting this together Sean! I verified the blockers (description_layout_overflow_in_builder, description_content_overflow_in_fill_out_page, fill_out_field_tab_order), to start, and I agree with the necessity of fixing these. They're all presentational/CSS changes and don't interfere with business logic. @Pavish Kumar Ramani Gopal, is there any reason @Sean Colsen shouldn't work on these immediately tomorrow? 

I'll connect with both of you on the rest tomorrow. A quick note that I'm out this Wednesday. 

Talk soon,

Zack

--

Zack Krida

Product & Community Lead | Mathesar

za...@mathesar.org | Schedule a call

[Pavish Kumar Ramani Gopal]

Thanks @Sean Colsen and @Zack Krida.

> @Pavish Kumar Ramani Gopal, is there any reason @Sean Colsen shouldn't work on these immediately tomorrow? 

The PRs I'm working on would fix the following from the list above:

• fill_out_field_tab_order (From the blockers)
• empty_submission_error_message
• semantic_field_labels
• submission_error_display_format
• fk_column_field_name
• column_dropped_after_form_created
  

Sean could work on the other issues. I don't think there'd be any merge conflicts, most of these are self-contained.

Regarding Pages and navigation:

I do think we can discuss this over a quick call.

> If we have an authenticated form fill-out page, I would expect that the role used when submitting the form would the the collaborator’s configured role, not the form’s “associated role”. I think the form’s associated role should only be used for anonymous form fill-out. As such, I think the associated role should be part of the form’s “share” settings. If you don’t configure a public share link, then you don’t configure an associated role.

This behaviour of having an "associated_role" is intentional. I initially specced the role to be "submission_role", however, it made more sense to associate the role with the form because we currently lack a permissions system for Mathesar objects. Brent and I also went over this quite a bit.

I can go over this in more detail over call if needed.

Here's a gist:

- Whenever a form is edited and saved, we validate if the user saving the form has access to the associated role. It essentially serves as a permission check on the entire form.

- Any user can edit the form, and if they do not have access to the associated role, they could change it and then save the form. This ensures that the role is not an "owner".

- Security wise, assume a scenario where the role is tied only to submission, and the form is already shared publicly using an elevated role.

    - A user can edit the form structure and add fields they don't have insert privileges on, and save the form.

    - Validating the submission_role in this scenario would make the UX more complicated since sharing settings are not part of the form structure.

    - If we do not validate the submission_role, a user can then insert data into tables they don't have access to, by using the publicly shared link.

- Keeping the role tied to the form would allow the user to submit the form using the elevated role associated with it, but the tables & columns included in the form are controlled only by those that have access to the associated_role.

- I wanted to have a separate setting for `published` and `published_publicly`, which we did not include for the first release. In this case, a form would need to be explicitly published inorder for it to be accessed internally. It can then be shared via a public link, optionally.

[Pavish Kumar Ramani Gopal]

Zack, Sean, and I had a discussion and we decided to remove the "Internal form fill-out page" for the initial release, and come back to it as a separate project when needed.

This simplifies the permission and navigation related issues mentioned above.

[Zack Krida]

Thanks Pavish! For those following along, we discussed two other small enhancements: 

1. Add the form 'share modal' to the schema page falafel menu. Example:

2. Change "Edit {form|table|exploration}" to "Rename {form|table|exploration}" for clarity. Examples: