[Patternfly] Syntax hint wireframes

Tue Jan 17 17:27:38 UTC 2017

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-
>> 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
>> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/027d747a/attachment.htm>