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 <[email protected]> wrote: > Ah, right… sorry if i misinterpreted > > Thomas Maas > Designer > [email protected] > > > > > On 17 Jan 2017, at 17:58, Allie Jacobs <[email protected]> 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 <[email protected]> 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’, > [email protected]’) > > > > 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 ‘[email protected]’ and always render descriptive > hints outside the input field > > > > Thanks for creating all these wireframes Jessica, > > -Thomas > > > > Thomas Maas > > Designer > > [email protected] > > > > > > > > > > > On 17 Jan 2017, at 15:32, Sarah Rambacher <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 > > > [email protected] > > > [email protected] > > > > > > On Mon, Jan 16, 2017 at 3:18 PM, Matt Carrano <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > > > [email protected] > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > > > > -- > > > Greg Sheremeta, MBA > > > Red Hat, Inc. > > > Sr. Software Engineer > > > [email protected] > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > > > > -- > > > Matt Carrano > > > Sr. Interaction Designer > > > Red Hat, Inc. > > > [email protected] > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > > > > -- > > > > > > Allie Jacobs > > > UXD > > > calendar > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > > > > -- > > > Patrick Cox > > > Manager, User Experience Design > > > 919-264-3017 (mobile) > > > [email protected] > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > > > > > _______________________________________________ > > > Patternfly mailing list > > > [email protected] > > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > _______________________________________________ > > Patternfly mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/patternfly > > > > > > > > -- > > > > Allie Jacobs > > UXD > > calendar > > > > -- Allie Jacobs UXD calendar <https://www.google.com/calendar/b/1/[email protected]&ctz=America/New_York>
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
