Yes, it may be a domain name like this or perhaps an IP address. It's basically the server address that the application will send email notifications through.
Matt On Tue, Jan 17, 2017 at 2:15 PM, Jessica Ryhanych <[email protected]> wrote: > 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” 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]> > wrote: > >> Here are some examples I had handy Jessica: >> >> https://redhat.invisionapp.com/share/8JA1Y1D7A#/214646965_Wi >> ldFly-EAP-Modal-Form >> https://redhat.invisionapp.com/share/8JA1Y1D7A#/214799830_Wi >> ldFly-EAP-Form >> https://redhat.invisionapp.com/share/6NA2FHPYX#/screens >> >> - Catherine >> >> >> On Tue, Jan 17, 2017 at 12:05 PM, Jessica Ryhanych <[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] >>> >>> On Jan 17, 2017, at 11:58 AM, 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-a >>>> ctivated-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#t >>>> ext-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 >>> <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 >>> >>> >>> >>> _______________________________________________ >>> Patternfly mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/patternfly >>> >>> >> >> _______________________________________________ >> Patternfly mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/patternfly >> >> > > > -- > Matt Carrano > Sr. Interaction Designer > Red Hat, Inc. > [email protected] > <Mail Settings.png> > > > -- Matt Carrano Sr. Interaction Designer Red Hat, Inc. [email protected]
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
