[Patternfly] Form field relationships

[Matt Carrano]

Hi Harald,

Agree that using the progressive disclosure approach is the way to go.
Jonathan outlined this pretty well.  If you have alternative attributes
that are mutually exclusive, the classic way to handle that would be with a
radio button group if there are a small number or a dropdown otherwise.
This would expose or enable only one attribute at a time.

If you mock something up and want some feedback, I'd be glad to take a look.

Regards,

Matt

On Sun, Jan 29, 2017 at 4:01 PM, Jonathan Yu <jawnsy at redhat.com> wrote:

>
> On Sun, Jan 29, 2017 at 12:27 PM, Harald Pehl <hpehl at redhat.com> wrote:
>
>>
>> Some attributes have relationships to other attributes. Basically
>> there are two different kind oif relationships:
>>
>
> This is a pretty common requirement, but sadly I haven't found anything
> sophisticated enough to handle these sorts of multi-field validations -
> most libraries focus on individual fields (this field is required, this
> must be an email address, etc) but not constraints between them (this field
> is required only if another optional field is set).
>
> If you're using traditional forms (that is, submitting to server side as a
> POST), I'd suggest using something like this:
>
> 1. Requires: One attribute requires another one
>>
>
> Add an input handler to the first input, and on every change, determine
> whether to show/hide the corresponding field. For example, if you are
> collecting a State for addresses in the United States, but only country
> otherwise, then you can add an oninput handler to the country field and
> show/hide the corresponding field by adding/removing the "hidden" class and
> "disabled" attribute (to prevent it from being submitted with your form).
> For best results, you'll also need to replicate the logic on the server
> side (or figure out a way to share them, since I see you're using GWT).
>
> If you have multiple fields, which are optional (if all are left blank) or
> required (if any one of them are filled in), I suggest hiding them behind a
> checkbox control that corresponds to a condition like "my billing address
> and contact address are different", where checking the box should unhide
> several controls and mark them all as required.
>
>>
>> 2. Alternatives: Alternative attributes are mutually exclusive. Only
>> one attribute can be set.
>>
>
> If you start typing in one field, either disable or hide the other field,
> to make it clear that only one of them can be modified at a time. You can
> also use a dropdown or radio input for this.
>
> I think you hit on the right thing in your design doc about progressive
> disclosure, and ideally you have someone versed in interaction design to
> help you design the right workflow for your use case, as I don't think
> there's any one-size-fits-all approach. In my opinion, there's no
> substitute for user research.
>
> Jonathan
>
> _______________________________________________
> Patternfly mailing list
> Patternfly at redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
>
>


-- 
Matt Carrano
Sr. Interaction Designer
Red Hat, Inc.
mcarrano at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170130/92f1673d/attachment.htm>