[Patternfly] Syntax hint wireframes

Tue Jan 17 18:39:14 UTC 2017

Here's a form that might be interesting (attached).  It's for mail server
configuration.  You'll see that there is an challenge here because there
are controls associated with the outgoing server address (to the right and
below), but we also wanted to have a hint.  We placed the hint in this case
below the label, but that may not be the best answer.

Matt

On Tue, Jan 17, 2017 at 12:27 PM, Catherine Robson <crobson at redhat.com>
wrote:

> Here are some examples I had handy Jessica:
>
> https://redhat.invisionapp.com/share/8JA1Y1D7A#/214646965_
> WildFly-EAP-Modal-Form
> https://redhat.invisionapp.com/share/8JA1Y1D7A#/214799830_WildFly-EAP-Form
> https://redhat.invisionapp.com/share/6NA2FHPYX#/screens
>
> - Catherine
>
>
> On Tue, Jan 17, 2017 at 12:05 PM, Jessica Ryhanych <jryhanyc at redhat.com>
> wrote:
>
>> Hey team,
>> Thanks for all the feedback and conversation! I’m going to do some
>> exploration / design iterations based on these ideas and share them back
>> with you all.
>>
>> One suggestion in the PF Demo meeting this morning was to work with a
>> real world form design that is more robust and complex to test these ideas
>> on – could anyone share files that I could work from? I’d specifically like
>> to test out solutions on forms with multiple inputs, drop downs, etc. on
>> desktop, mobile, and within modals.
>>
>> Greg, I think the wizard example you shared could be a good one to work
>> from. Could you share that with me?
>>
>> Thanks!
>> Jessica
>>
>> */ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / *
>>
>> *Jessica W. Ryhanych*
>> User Experience Design
>> Red Hat
>> jryhanyc at redhat.com
>>
>> On Jan 17, 2017, at 11:58 AM, Allie Jacobs <ajacobs at redhat.com> wrote:
>>
>> I interpreted Sarah's suggestion as using the same behavior in the
>> examples with labels but having the placeholder syntax hints shrink and
>> move below the input field as you type. It's an interesting idea.
>>
>> On Tue, Jan 17, 2017 at 11:05 AM, Thomas Maas <tmaas at redhat.com> wrote:
>>
>>> Looking at the previous examples, we have to be careful not to mix the
>>> semantics of placeholders and labels:
>>>
>>> - Labels tell you what (name, email, etc)
>>> - Placeholders/syntax hints give you hints on how (‘your full name’,
>>> you at yourdomain.com’)
>>>
>>> The examples in the last 2 emails are not placeholders but labels that
>>> sit where placeholders are normally rendered.
>>>
>>> As for the placeholder discussion:
>>>
>>> - I agree that having hints on the right side will give space problems
>>> in many cases
>>> - I don’t think we should worry too much about vertical space, people
>>> can scroll
>>> - Option 4 where the error message takes the place of the (syntax) hint
>>> works well in practice, sometimes that means that all you need to do is
>>> ‘color the syntax message red'.
>>> - I would suggest we use the placeholder attribute only for actual
>>> placeholders like ‘you at yourdomain.com’ and always render descriptive
>>> hints outside the input field
>>>
>>> Thanks for creating all these wireframes Jessica,
>>> -Thomas
>>>
>>> Thomas Maas
>>> Designer
>>> thomas.maas at redhat.com
>>>
>>>
>>>
>>>
>>> > On 17 Jan 2017, at 15:32, Sarah Rambacher <srambach at redhat.com> wrote:
>>> >
>>> > Yes, that's like what I saw. Chris found these other examples too -
>>> >
>>> > http://littlebigdetails.com/post/82478225432/circleci-once-a
>>> ctivated-the-input-placeholders
>>> >
>>> > https://github.com/jverdi/JVFloatLabeledTextField
>>> >
>>> > On Tue, Jan 17, 2017 at 9:07 AM, Leslie Hinson <lhinson at redhat.com>
>>> wrote:
>>> > Yes! I've seen this too Sarah. Check out the video [1] on material to
>>> see an example of this behavior (however they are using it for labels vs
>>> syntax hints).
>>> >
>>> > Option 1 can be tricky when you take responsiveness into
>>> consideration. This was a large discussion when discussing
>>> required/optional fields.
>>> >
>>> > [1] https://material.io/guidelines/components/text-fields.html#t
>>> ext-fields-search-filter
>>> >
>>> > -  Leslie
>>> >
>>> >
>>> > On Tue, Jan 17, 2017 at 8:22 AM, Sarah Rambacher <srambach at redhat.com>
>>> wrote:
>>> > I saw an interesting way of doing this on PayPal - if I remember
>>> correctly, there was placeholder text until you clicked into the field, and
>>> then the field enlarged slightly and the placeholder text was still shown
>>> within the field but in smaller text above where you were typing.
>>> >
>>> > I'm not sure how to find it again - it was from a site that linked me
>>> into PayPal for a one-time payment, and I remember thinking "hey, that's
>>> nice" but was focused on my task and didn't take the time to screenshot it
>>> ;-P
>>> >
>>> > On Mon, Jan 16, 2017 at 5:24 PM, Patrick Cox <pcox at redhat.com> wrote:
>>> > What is the typical length of a syntax hint? What is the max length?
>>> What about the length of text for corrective action?
>>> >
>>> > If they can get long, it seems like you'd want to put them below the
>>> field and allow them to wrap underneath it. If you have lengthy text,
>>> putting it out to the right side seems like it could look wonky and/or be
>>> hard to read if it wraps, or possibly force horizontal scrolling if it
>>> doesn't. Putting lengthy text inside the field could truncate it.
>>> >
>>> > It seems to me that you'd want as much flexibility as you can get to
>>> accommodate variability in this situation, and putting the text below the
>>> fields will afford that the most of any of the solutions.
>>> >
>>> > Pat
>>> >
>>> > On Mon, Jan 16, 2017 at 3:58 PM, Allie Jacobs <ajacobs at redhat.com>
>>> wrote:
>>> > My reasons for not liking 1&2 is because once you start typing, you
>>> lose the syntax help. If it's something complicated or if we generalize
>>> this to field level help, the user might need to reference it again. I
>>> prefer 3 for this reasons.
>>> > With #2 the user has to look further away (above the field) to find
>>> out what syntax rule was not met. With #4 that info is closer to the field.
>>> >
>>> > On Mon, Jan 16, 2017 at 3:43 PM, Jenny Haines <jhaines at redhat.com>
>>> wrote:
>>> > Option 1/2 seems like a great option because it would suit a variety
>>> of cases.
>>> >       • By having the specific details in the top error message box,
>>> the error message is freed up to mention any errors not dealing with just
>>> single form fields, but also dependencies between form fields.
>>> >       • If there are multiple errors, the error details will take up
>>> less vertical space when encased in the top error message box. Less
>>> vertical space is due to the error details having more horizontal real
>>> estate before needing to wrap to the next line. (This is especially
>>> important in form layouts like the one Greg has included, above. You'll
>>> notice in this case, there isn't a ton of horizontal real estate under the
>>> form fields.)
>>> >
>>> > Jenny Haines
>>> > UI/VISUAL DESIGNER
>>> > (m) 443-889-2881
>>> > jhaines at redhat.com
>>> > jennyhaines10 at gmail.com
>>> >
>>> > On Mon, Jan 16, 2017 at 3:18 PM, Matt Carrano <mcarrano at redhat.com>
>>> wrote:
>>> > It may be hard to have one answer that works in all cases.  It may be
>>> the 6/7 is the best default choice.  But for modals or other forms that
>>> must exist in a constrained space, placeholder text (1/2) is an acceptable
>>> alternative.
>>> >
>>> > Matt
>>> >
>>> > On Mon, Jan 16, 2017 at 3:14 PM, Catherine Robson <crobson at redhat.com>
>>> wrote:
>>> > Greg,
>>> >
>>> > Why would you use syntax hints with a selector/dropdown?  There are
>>> only limited options, so syntax shouldn't be a problem in those cases I
>>> would assume.
>>> >
>>> > - Catherine
>>> >
>>> > On Mon, Jan 16, 2017 at 2:59 PM, Greg Sheremeta <gshereme at redhat.com>
>>> wrote:
>>> > Check out this wizard we're implementing in oVirt. Option 6/7 simply
>>> won't work with this wizard at its current width.
>>> >
>>> > However, how would 1/2 work with select boxes?
>>> >
>>> > So -- I'm not sure :)
>>> >
>>> > Best wishes,
>>> > Greg
>>> >
>>> > <wizard.png>
>>> >
>>> > On Mon, Jan 16, 2017 at 2:53 PM, Catherine Robson <crobson at redhat.com>
>>> wrote:
>>> > Jessica,
>>> >
>>> > Thanks for so nicely laying out the options!  I lean towards #6,7,
>>> with #1,2 as a possible backup.  Reasoning:
>>> >
>>> > 1, 2.  The inline syntax hints keep the form concise and easy to scan
>>> without the syntax hints adding to the visual clutter of the page.  In
>>> *most* use cases, having the syntax hints overwritten by the user when they
>>> add a value shouldn't be much of a problem, but see why I prefer #6, 7
>>> below as a reason for when this is a problem.
>>> >
>>> > 3, 4, 5.  Below the field feels like it takes up too much vertical
>>> space on a form area where vertical space is usually the worst constraint.
>>> There are many forms where it feels like we're trying to come up with "more
>>> information" (wrap fields to two columns, show additional information or
>>> contextual information to the sides, etc etc) to show horizontally because
>>> the page is so horizontally skinny and there is a lot of whitespace to the
>>> right of the fields.  This is why I prefer 6, 7 that leans towards using
>>> that space over growing an already vertically long form even longer.  If
>>> users are doing two-column forms there might be a conflict with 6,7 though.
>>> >
>>> > 6, 7.  I prefer this one the most because the syntax always remains,
>>> is off to the right where it doesn't grow the form or distract users in
>>> most cases, but is reference when users need it.  There are use cases where
>>> there may be default values or existing values in a form (edit mode for an
>>> already created system for instance) so that the inline syntax hints (1, 2)
>>> would be invisible for a user who is changing those values.   This one
>>> feels like the best use of space and persistence.
>>> >
>>> > - Catherine
>>> >
>>> > On Mon, Jan 16, 2017 at 2:15 PM, Jessica Ryhanych <jryhanyc at redhat.com>
>>> wrote:
>>> > Hey PatternFlyers,
>>> > I’ve attached a few wireframes addressing the initial discovery work
>>> [1] on syntax hints. Please send your thoughts on which option we should
>>> move forward with as the recommendation and what issues you see with it, if
>>> any. Here we go:
>>> >
>>> > 1. Placeholder syntax hints – wireframe shows the form before user
>>> clicks or starts typing into the field
>>> >
>>> > <1. Placeholder syntax hint.png>
>>> >
>>> >
>>> > 2. Placeholder syntax hints – wireframe shows the form after user has
>>> typed data into field, submitted, and an error message is returned. The
>>> error message would need to specifically detail the problem with the syntax.
>>> >
>>> > <2. Placeholder syntax hint with error message.png>
>>> >
>>> >
>>> >
>>> > 3. Syntax hints below input field
>>> >
>>> > <3. Syntax below input field.png>
>>> >
>>> >
>>> > 4. Syntax hints below input field – Original syntax hint would be
>>> removed and replaced with red error message that reiterates syntax
>>> requirements below form field.
>>> >
>>> > <4. Syntax hint below input field, error message copy.png>
>>> >
>>> >
>>> > 5. Syntax hints below input field – Syntax hint stays on the page
>>> after user submits and error message appears below original hint.
>>> >
>>> > ***This option seems redundant IMO and could be confusing /
>>> overwhelming visually but I’m curious if anyone could see a scenario where
>>> this might be needed.
>>> >
>>> > <5. Syntax hint below input field, error message.png>
>>> >
>>> >
>>> >
>>> > 6. Syntax hints in-line with form field
>>> >
>>> > <6. Syntax inline with form field.png>
>>> >
>>> >
>>> > 7. Syntax hints in-line with form field – Syntax hint stays on screen
>>> after the user submits and receives an error message.
>>> >
>>> > ***This could have similar challenges as #5 above and if needed, a
>>> responsive / mobile page layout would need to be determined.
>>> >
>>> > <7. Syntax inline with form field, error message.png>
>>> >
>>> > Thoughts, ideas, suggestions? Thanks!
>>> > Jessica
>>> >
>>> >
>>> > [1] https://blog.patternfly.org/exploring-syntax-hints/
>>> >
>>> >
>>> > / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
>>> >
>>> > Jessica W. Ryhanych
>>> > User Experience Design
>>> > Red Hat
>>> > jryhanyc at redhat.com
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Greg Sheremeta, MBA
>>> > Red Hat, Inc.
>>> > Sr. Software Engineer
>>> > gshereme at redhat.com
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Allie Jacobs
>>> > UXD
>>> > calendar
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Patrick Cox
>>> > Manager, User Experience Design
>>> > 919-264-3017 (mobile)
>>> > patrick.cox at redhat.com
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Patternfly mailing list
>>> > Patternfly at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/patternfly
>>>
>>>
>>> _______________________________________________
>>> Patternfly mailing list
>>> Patternfly at redhat.com
>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>
>>
>>
>>
>> --
>>
>> Allie Jacobs
>> UXD
>>
>> calendar
>> <https://www.google.com/calendar/b/1/embed?src=ajacobs@redhat.com&ctz=America/New_York>
>> _______________________________________________
>> Patternfly mailing list
>> Patternfly at redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>>
>> _______________________________________________
>> Patternfly mailing list
>> Patternfly at redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
> _______________________________________________
> 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/20170117/635a8435/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail Settings.png
Type: image/png
Size: 70990 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/635a8435/attachment.png>