[Patternfly] Syntax hint wireframes

Tue Jan 17 14:07:07 UTC 2017

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#text-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 <(443)%20889-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
>>>>>>>
>>>>>>> [image: Inline image 1]
>>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3. Syntax hints below input field
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 6. Syntax hints in-line with form field
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>> <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
>>>
>>>
>>
>>
>> --
>> *Patrick Cox*
>> Manager, User Experience Design
>> 919-264-3017 <(919)%20264-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5. Syntax hint below input field, error message.png
Type: image/png
Size: 42793 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wizard.png
Type: image/png
Size: 47044 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4. Syntax hint below input field, error message copy.png
Type: image/png
Size: 43660 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7. Syntax inline with form field, error message.png
Type: image/png
Size: 42646 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1. Placeholder syntax hint.png
Type: image/png
Size: 32894 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6. Syntax inline with form field.png
Type: image/png
Size: 32976 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3. Syntax below input field.png
Type: image/png
Size: 33138 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2. Placeholder syntax hint with error message.png
Type: image/png
Size: 41284 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/0d2f37b7/attachment-0007.png>