Hey Matt, This one is really interesting. Just to confirm, the SMTP Address hint – is instructing the user to input a version of “smtp.name.com <http://smtp.name.com/>” into the form field?
Thanks for sharing! / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / Jessica W. Ryhanych User Experience Design Red Hat [email protected] > On Jan 17, 2017, at 1:39 PM, Matt Carrano <[email protected]> wrote: > > Here's a form that might be interesting (attached). It's for mail server > configuration. You'll see that there is an challenge here because there are > controls associated with the outgoing server address (to the right and > below), but we also wanted to have a hint. We placed the hint in this case > below the label, but that may not be the best answer. > > Matt > > On Tue, Jan 17, 2017 at 12:27 PM, Catherine Robson <[email protected] > <mailto:[email protected]>> wrote: > 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#/214646965_WildFly-EAP-Modal-Form> > https://redhat.invisionapp.com/share/8JA1Y1D7A#/214799830_WildFly-EAP-Form > <https://redhat.invisionapp.com/share/8JA1Y1D7A#/214799830_WildFly-EAP-Form> > https://redhat.invisionapp.com/share/6NA2FHPYX#/screens > <https://redhat.invisionapp.com/share/6NA2FHPYX#/screens> > > - Catherine > > > On Tue, Jan 17, 2017 at 12:05 PM, Jessica Ryhanych <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> >> On Jan 17, 2017, at 11:58 AM, Allie Jacobs <[email protected] >> <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[email protected]>’ and >> always render descriptive hints outside the input field >> >> Thanks for creating all these wireframes Jessica, >> -Thomas >> >> Thomas Maas >> Designer >> [email protected] <mailto:[email protected]> >> >> >> >> >> > On 17 Jan 2017, at 15:32, Sarah Rambacher <[email protected] >> > <mailto:[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 >> > >> > <http://littlebigdetails.com/post/82478225432/circleci-once-activated-the-input-placeholders> >> > >> > https://github.com/jverdi/JVFloatLabeledTextField >> > <https://github.com/jverdi/JVFloatLabeledTextField> >> > >> > On Tue, Jan 17, 2017 at 9:07 AM, Leslie Hinson <[email protected] >> > <mailto:[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 >> > >> > <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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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 <tel:443-889-2881> >> > [email protected] <mailto:[email protected]> >> > [email protected] <mailto:[email protected]> >> > >> > On Mon, Jan 16, 2017 at 3:18 PM, Matt Carrano <[email protected] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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/ >> > <https://blog.patternfly.org/exploring-syntax-hints/> >> > >> > >> > / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / >> > >> > Jessica W. Ryhanych >> > User Experience Design >> > Red Hat >> > [email protected] <mailto:[email protected]> >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > >> > -- >> > Greg Sheremeta, MBA >> > Red Hat, Inc. >> > Sr. Software Engineer >> > [email protected] <mailto:[email protected]> >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > >> > -- >> > Matt Carrano >> > Sr. Interaction Designer >> > Red Hat, Inc. >> > [email protected] <mailto:[email protected]> >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > >> > -- >> > >> > Allie Jacobs >> > UXD >> > calendar >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > >> > -- >> > Patrick Cox >> > Manager, User Experience Design >> > 919-264-3017 <tel:919-264-3017> (mobile) >> > [email protected] <mailto:[email protected]> >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> > >> > >> > >> > _______________________________________________ >> > Patternfly mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.redhat.com/mailman/listinfo/patternfly >> > <https://www.redhat.com/mailman/listinfo/patternfly> >> >> >> _______________________________________________ >> Patternfly mailing list >> [email protected] <mailto:[email protected]> >> https://www.redhat.com/mailman/listinfo/patternfly >> <https://www.redhat.com/mailman/listinfo/patternfly> >> >> >> >> -- >> >> Allie Jacobs >> UXD >> calendar >> <https://www.google.com/calendar/b/1/[email protected]&ctz=America/New_York>_______________________________________________ >> Patternfly mailing list >> [email protected] <mailto:[email protected]> >> https://www.redhat.com/mailman/listinfo/patternfly >> <https://www.redhat.com/mailman/listinfo/patternfly> > > > _______________________________________________ > Patternfly mailing list > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/patternfly > <https://www.redhat.com/mailman/listinfo/patternfly> > > > > _______________________________________________ > Patternfly mailing list > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/patternfly > <https://www.redhat.com/mailman/listinfo/patternfly> > > > > > -- > Matt Carrano > Sr. Interaction Designer > Red Hat, Inc. > [email protected] <mailto:[email protected]> > <Mail Settings.png>
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
