[MGNLUI-3682] Find a way to group form fields to properly structure forms Created: 27/Nov/15  Updated: 11/Mar/21  Resolved: 11/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: dialogs
Affects Version/s: 5.3.12, 5.4.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Andreas Weder Assignee: Unassigned
Resolution: Obsolete Votes: 0
Labels: devwl, estimate-with-uncertainty, forms, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MGNLUI-4909 Ship 2 alternative ways to layout forms Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Epic Link: AX: improve dialogs
Story Points: 13

 Description   

We currently lack any type of structuring element in dialogs apart from tabs. If you e.g. look at the "edit asset" dialog, we just have a large sequence, a "flood of fields". We can do better than that, e.g. by separating core asset properties (it's name, media blog) from meta data sections.

One of the basic things we need in order to properly design and structure forms is a way to group fields. Other useful structural elements would be accordions and tabs in forms. This issue, however, is only about a way to group fields.

Such a group of fields:

  • can be associated with a name and/or an id so that we refer to it
  • may feature an optional title

We should make sure that we don't simply introduce additional hierarchy levels in the already quite nested dialog definitions, unless we find no other meaningful way to group elemens.

Technically, this would properly be rendered using an HTML "fieldset" element, so that we can take advantage of built-in browser support such as a way to disable or hide the entire group, or to mark it as read-only. We have to discuss if we also want to allow such a group of fields to be used in lieu of a regular field, i.e. in switchable or multi-value fields.

This issue is part of an initiative to improve the author experience in forms by adding missing elements, which allow us to better structure forms. It also allows us to switch to better forms once we improve our content pool story further.



 Comments   
Comment by Christopher Zimmermann [ 07/Jun/16 ]

From the configuration side: would a fieldset contain the fields in the set, or be at the same depth?
I see the risk that this makes a dialog definition more complex by creating a deeper hierarchy (which may be worth the tradeoff).

Comment by Andreas Weder [ 07/Jun/16 ]

What you mention is exactly why this wasn't tackled so far. We had discussions already back with Philipp, where the same, valid concerns were raised.

What we need is a way to properly structure forms; I'm not so anxious to get actual fieldsets (I should change this issue accordingly). Currently, all we have is a flood of fields (e.g. in the "edit asset" dialog). In order to design and set up forms properly, improve their accessibility and legibility, we need a way to group fields, associate them with a title.

Probably this means that we'll use an HTML "fieldset" element to render such groups, so that we can also take advantage of built-in browser support for such elements (e.g. for defining a tab order, for disabling or for hiding an entire block of fields). But that doesn't mean that we have to configure this thing as actual fieldsets. Maybe there's a good way to keep the hierarchy as flat as it currently is. I'd expect a first step here to actually work out all the options we have.

Generated at Mon Feb 12 09:09:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.