[Patternfly] Syntax hint wireframes

Tue Jan 17 17:09:09 UTC 2017

No good point to bring up Thomas! It's possible this pattern could be
confusing. We'll see what Jessica comes up with...

On Tue, Jan 17, 2017 at 12:06 PM, Thomas Maas <tmaas at redhat.com> wrote:

> Ah, right… sorry if i misinterpreted
>
> Thomas Maas
> Designer
> thomas.maas at redhat.com
>
>
>
> > On 17 Jan 2017, at 17:58, 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
> >
>
>

-- 

Allie Jacobs
UXD

calendar
<https://www.google.com/calendar/b/1/embed?src=ajacobs@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/81c3b03e/attachment.htm>