Open LucasHaines opened 5 years ago
Interesting idea. I like the idea of gaining form consistency especially for layout, accessibility, and navigation perspectives.
I'd be nice to have an option to make sections that can be collapsed/expanded for long forms or settings pages. That may need something like the Expander control from the Toolkit though too.
It does seem to align with the Grid efforts, but I could see this using that, especially if it's a data-bound list or object. It'd be nice to see it somehow could read/consume a set of properties from an object via reflection to show the form and data-bind to the object's properties. -- I believe @mrlacey was exploring something related with Rapid XAML Toolkit though slightly different, but I could see WindowsTemplateStudio using this for their settings page, eh @crutkas?
@michael-hawker Great feedback, really love the idea of having an expand/collapse behavior on form sections. I added it to the functional requirements. Will expand in the usage scenarios and code example. Thanks for the pointer.
Data binding is something we want to support in the long term. It's captured in the requirements as a "Should".
@LucasHaines yeah, I just implemented a setting page in my app and it was long and sprawling, adding the sections collapsed really made a big impact on navigability.
Look at the spec for #79 too, as the expand/collapse parts would overlap, especially if only one section should be open at a time (an option in their scenario). Would be nice to centralize those two code pieces to another control that can be used outside or for Accordion drawers. Could be cool to have an expander type control that can act like a radio grouping where only 1 can be open at a time.
Some thoughts/comments
Having Form
, FormSection
and FormGroup
would be beneficial even if for nothing more than increasing the semantics of the markup on a page. Adding additional functionality to each
The thought of (eventually) having a Form
control that can be bound to a single VM and have it generate "everything" makes me wonder if you'd end up needing to apply a lot of definition (possibly via attributes) to the properties of the VM. This risks leading to presentation logic being mixed with the VM. It would also be a very big, complex control. I'd rather see this functionality working without binding. It could be added later if really needed.
Having seen attempts to create similar controls on other platforms, there is a fine line to be drawn between flexibility and complexity of configuration. Beware building in too much functionality that needs to be specifically configured as it won't be used.
Auto-generating the contents of a Section (or whole form) would create localization challenges. The ability to support localization of the UI text MUST be considered as part of this proposal.
Is the FormActions
section for anything more than layout? Assuming, it just takes buttons, I can't think of scenarios where more than two options will be needed. Is it just a special version of a FormSection
that appears at the bottom?
I can imagine specific Header
and Footer
containers within the Form
as being useful for styling. Even if these just contain FormSection
s they could help with styling consistency where apps have multiple pages containing forms that should be styled the same way.
FormGroup
and FormSection
seem very similar. The only real difference seems to be that a Section has a Header. Do they need to be different? If they were the same it would avoid complexity over what can be can be nested within the other. (On the assumption that the current proposal doesn't nest sections but you can have multiple nested groups within a section.)
If any data input control (or any element--presumably) can be placed within a section/group, how will any styling applied directly to such a control interact with styling and positioning applied automatically by the section/group?
Will it be possible to disable the automatic layout capabilities of a section/group and add other layout containers?
What will the rules on automatic laying out of columns and wrapping be?
Will it be possible to have a section/group that uses multiple columns where there is space and puts everything in one column when the window is narrow?
Could "Draw a line under each section" just be part of the default styling and overridden by applying custom styling rather than being a boolean property? (Oh, I guess this is another difference between a section and a group.)
Having things like "line under each section" as part of the control seem very tied to a specific design style. I'd be wary of including this as it has a high risk of causing issues if a new default form layout style was wanted in the future. Try and avoid anything that may lead to the UI being tied to a specific visual look if future platform guidance changes.
@mrlacey Thanks for the feedback! We do want to strike a balance with this control of functionality and ease of use. We want to avoid bloating this control and really focus on a single consistent form experience that is great with no additional work but can support customization.
FormActions is about layout and readability for Narrator. It could take Button, Hyperlink, HyperlinkButton, and a few others. There are scenarios where you might want and "Accept", "Cancel", "Clear All", and maybe a link for more information.
Header and footer sections is an interesting idea we never considered. If the scenario is for the form to expand across pages, it seems that would best be suited as part of the page and not part of the Form. Is there another scenario these concepts might apply to?
Interesting thought about nesting sections and not using group. One thing that section gives us is the built in styling that can be customized. But as mentioned, we could use a boolean to help with this, Are there other difference we could use the semantics of Group?
Someone can still apply style overrides to the control and have it work with in the form. Such as color resources, the form control shouldn't override explicit items set on a specific control.
Adding custom is layout is a great scenario and something we should allow at a control level.
Yes, the intent is for the control to wrap columns determined by available space.
Yes, providing a different set of resource keys is a nice customization. Thanks for the warning, the idea is that we could build the control in a way that would allow for visual updates and customization. We don't want to be too heavy handed.
Might I suggest that if this control was to be built, that some consideration be made with those multi-column groups, so a narrow width will re-arrange the form elements.
Collapsible sections would make a lot of sense in these narrow windows/screens - perhaps with an auto-collapse behaviour, and some kind of indicator when a section with mandatory form elements have not been filled in.
Pagination or a flow of multiple forms which need to be completed before progressing could be useful, but making it simple and performant would need to be a must. Transitions between steps in the form should be in the best practice of Fluent Design, and the current step (Step 2 of 4) etc should be visible and clear.
Shared styles which would apply to all elements in a Form control, or per form group could be considered for consistency and to prevent re-templating.
I will update the feature request to call this our more detailed. I will also adda proposed list of resrouces for consistent styling. But all in all, your suggestions are spot on.
There is a UWP Doc page about best practice for Forms. https://docs.microsoft.com/en-gb/windows/uwp/design/controls-and-patterns/forms
Whatever happens with this proposal, there should be consistency with the Fluent, Windows, Office, and Docs teams to clearly define how to do it.
How would you envision this working with custom built input controls?
One of the projects I work on is an enterprise application which relies heavily on form-based views which have heavily customized in-house input controls to support data validation and unique input experiences.
Would this control also look to handle scenarios where certain sections or input fields should be visible based on the values of other fields? I know there would be other ways of achieving this outside of the control.
You could have a form content panel control, which would contain the custom control/third party control - but still supports the responsive reflow, sizing, tabbing, etc
The form control would ensure consistent spacing between items, handle flow, resize and possibly pagination and multi-step forms, whilst maintaining input values from multiple pages before submitting.
I'm removing the assignee field to indicate that this proposal is going to the freezer for us to take a look at later.
There does not appear to be a winui PropertyGrid control yet. However, this Form Control feature proposal would go some way to allow some kind of grouped PropertyGrid. They could almost be the same control with only the layout and spacing determine if Form Control 'looks' like a form or a propertygrid.
Love this proposal!
One small comment: how would we deal with inconsistent spacing between controls?
Example
In this example, all input controls (ToggleSwitch / NumberBox / ToggleSwitch) have the same Margin: 0, 12, 0, 0.
As you can see this results in a consistency, as a ToggleSwitch and CheckBox make use of additional whitepace. within their controls.
This control proposal should be considered alongside Aligning Control Headers to the Left (and Right) #4643 Allow on/off label placement on either side of ToggleSwitch #3696
A new Microsoft Teams UI kit has been added in Figma, and there is guidance for creating Forms, which could be useful for this discussion and proposal.
Since this has been called out for both data entry form layouts and setting page layouts, wanted to link to this twitter thread about the latter via @niels9001:
Also a mention of using Expander
to collapse form sections.
The Figma file for WinUI 2.6 has no guidance for the laying out of Forms or the best practice that is being implemented in the new Settings and Store apps.
I still think this control needs to happen, but it would be a good idea for the design teams to document best practices and redlines for spacing and positioning of these elements.
any update?
Proposal: Form Control
Summary
The Form control enables layout, alignment, and grouping of form elements. Form elements are different control types associated with data input.
Rationale
Creating a form is a very common scenario for Enterprise and LOB applications. Easily creating a form that is evenly spaced, appropriately sized, semantically grouped, accessible, and contains the needed actions is a manual process using Grid (or other layout controls). While this is not difficult, it can be time consuming and cumbersome.
When creating a form using any of the layout panels provided today, Narrator support is only provided at the control level. No context is provided to user. Example: if the field is required, how many, which section, etc. by creating a Form layout control this can be provided to user for free and allow developers to focus on functionality and not layout.
Functional Requirements
Usage Examples
Create a single column form with inline actions
At default the control will create a single column form respecting spacing rules with actions at the bottom.
Create a multi-column form with sections and groups
By providing a few properties the Form control can easily adapt to more complex data input scenarios. Without the need to define row and column definitions. The spacing rules are built into the Form control.
Detailed Feature Design
Visual Anatomy of a Form
The Form control contains a three different components.
Default Spacing
The Forms control will provide default spacing rules but these can be overwritten in markup.
Creating a Complex Form
The example below used FormSection and FormGroup to build a Form for a new patient.
Rendered version of markup
Accessibility
Up/Down Arrow: scroll the page up and down
Open Questions