You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The tabbed forms on classic UI, have some usability issues. This PLIP aims to improve the user experience by fixing then and proposes some improvements to enhance the user experience.
Motivation
I see some issues on the current form tabbed forms in Classic UI.
1. The tab markup is not compatible with bootstrap
There is no way other than switching to a tab to know if it has a required field. This can be annoying: a user can post the form and get an unexpected validation error. See also next point. It would be more convenient to see a marker in the tab to spot immediately that it contains a required field.
3. Validation errors on secondary fields
If I have a validation happens on a secondary tab (not only if it is related to a required field), the user has to open the tab to see it. It would be more convenient to see a marker in the tab to spot immediately where the error happens.
4. Warnings
There is no way to have non-blocking warnings in the form. It would be nice to have a way to show a warning in the tab, to let the user know that there is something to check/improve.
This would cover several use cases, like:
a warning about a field that is not mandatory but it is recommended to fill
a warning about a field with a default value that should be changed
a warning about a field that is filled with a value that is not recommended
E.g.:
you are writing a blog post and the title is too long and tags are not set. You do not want to prevent the editor from saving the form, but you would like to suggest that, before publishing the post, some adjustment should be made.
some customer have really complex forms bound to processes. Some field values might not be available in the initial phases of the process. You cannot set them as required, but you really want them to be filled before the process is completed.
Add your own use case here.
Assumptions
The form is rendered using the plone.app.z3cform macros.
The form is rendered in the classic UI.
The "warnings feature" can be implemented at a later stage (see the "Risks" section).
Proposal & Implementation
If form tabbing is used, we will have:
one tab for the fields not assigned to any fieldset
one tab for each fieldset
The tabbed form should be rendered using the bootstrap tabs markup.
We should have a warnings attribute to widgets and groups (currently we just have the errors attribute).
This attribute will contain a list of WarningWhatever objects that have a render method that spits out the markup for the warning message.
Something similar already happens with the error instances in errors attribute.
If a form contains warnings, the form element will be marked by a class has-warnings-or-whatever. A message/visual marker will be shown at the top of the form about the fact that we have warnings.
If a tab contains warnings, the tab element will be marked by a class has-warnings-or-whatever. A message/visual marker will be shown at the top of the tab about the fact that we have warnings.
If a field contains warnings, the widget wrapper will be marked by a class has-warnings-or-whatever. A warning message will be shown in the widget about the fact that we have warnings.
Deliverables
A PR in plone/plone.app.z3cform to render the form using the bootstrap tabs markup.
A PR in plone/plone.staticresources to provide the required CSS and JavaScript pattern.
A PR in zopefoundation/z3c.form to implement the concept of warnings.
A PR in plone/documentation to document the feature.
Risks
Adding the warning feature to z3c.form may not be accepted. In that case some other solution should be found.
Notes
The warning feature is not strictly related to the tabbed forms.
It is a general feature that can be used in any form.
It is proposed here because it is a feature that can be useful in the context of tabbed forms and touches the same page templates.
If needed, it can go in its own PLIP.
The @plone/volto-team might be interested in this feature
Participants
...
The text was updated successfully, but these errors were encountered:
Have you considered using an accordion UI instead of tabs? It avoids some problems (i.e. you don't have to fit lots of tabs horizontally on a narrow device, and you can avoid hiding errors by expanding those sections). But there is the cost of making it less obvious that there are multiple sections until you scroll.
Here is an example from a site I worked on some time ago:
Responsible Persons
Proposer:
Seconder:
Abstract
The tabbed forms on classic UI, have some usability issues. This PLIP aims to improve the user experience by fixing then and proposes some improvements to enhance the user experience.
Motivation
I see some issues on the current form tabbed forms in Classic UI.
1. The tab markup is not compatible with bootstrap
Compare:
with:
2. Tabs with required fields are not highlighted
There is no way other than switching to a tab to know if it has a required field. This can be annoying: a user can post the form and get an unexpected validation error. See also next point. It would be more convenient to see a marker in the tab to spot immediately that it contains a required field.
3. Validation errors on secondary fields
If I have a validation happens on a secondary tab (not only if it is related to a required field), the user has to open the tab to see it. It would be more convenient to see a marker in the tab to spot immediately where the error happens.
4. Warnings
There is no way to have non-blocking warnings in the form. It would be nice to have a way to show a warning in the tab, to let the user know that there is something to check/improve.
This would cover several use cases, like:
E.g.:
you are writing a blog post and the title is too long and tags are not set. You do not want to prevent the editor from saving the form, but you would like to suggest that, before publishing the post, some adjustment should be made.
some customer have really complex forms bound to processes. Some field values might not be available in the initial phases of the process. You cannot set them as required, but you really want them to be filled before the process is completed.
Add your own use case here.
Assumptions
plone.app.z3cform
macros.Proposal & Implementation
If form tabbing is used, we will have:
The tabbed form should be rendered using the bootstrap tabs markup.
An example is shown here:
We should have a
warnings
attribute to widgets and groups (currently we just have theerrors
attribute).This attribute will contain a list of
WarningWhatever
objects that have arender
method that spits out the markup for the warning message.Something similar already happens with the error instances in
errors
attribute.If a form contains warnings, the form element will be marked by a class
has-warnings-or-whatever
. A message/visual marker will be shown at the top of the form about the fact that we have warnings.If a tab contains warnings, the tab element will be marked by a class
has-warnings-or-whatever
. A message/visual marker will be shown at the top of the tab about the fact that we have warnings.If a field contains warnings, the widget wrapper will be marked by a class
has-warnings-or-whatever
. A warning message will be shown in the widget about the fact that we have warnings.Deliverables
plone/plone.app.z3cform
to render the form using the bootstrap tabs markup.plone/plone.staticresources
to provide the requiredCSS
and JavaScript pattern.zopefoundation/z3c.form
to implement the concept of warnings.plone/documentation
to document the feature.Risks
z3c.form
may not be accepted. In that case some other solution should be found.Notes
The warning feature is not strictly related to the tabbed forms.
It is a general feature that can be used in any form.
It is proposed here because it is a feature that can be useful in the context of tabbed forms and touches the same page templates.
If needed, it can go in its own PLIP.
The @plone/volto-team might be interested in this feature
Participants
The text was updated successfully, but these errors were encountered: