[Patternfly] Syntax hint wireframes

Tue Jan 17 14:32:03 UTC 2017

Yes, that's like what I saw. Chris found these other examples too -

http://littlebigdetails.com/post/82478225432/circleci-once-activated-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#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/eef2f804/attachment.htm>
-------------- 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/eef2f804/attachment.png>
-------------- 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/eef2f804/attachment-0001.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/eef2f804/attachment-0002.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/eef2f804/attachment-0003.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/eef2f804/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/eef2f804/attachment-0005.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/eef2f804/attachment-0006.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/eef2f804/attachment-0007.png>