[Patternfly] Syntax hint wireframes

Tue Jan 17 20:38:10 UTC 2017

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 <jryhanyc at redhat.com>
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
> jryhanyc at redhat.com
>
> On Jan 17, 2017, at 1:39 PM, Matt Carrano <mcarrano at redhat.com> 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 <crobson at redhat.com>
> 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 <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-a
>>>> ctivated-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#t
>>>> ext-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
>>>
>>>
>>
>> _______________________________________________
>> 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
> <Mail Settings.png>
>
>
>

-- 
Matt Carrano
Sr. Interaction Designer
Red Hat, Inc.
mcarrano at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170117/2a546872/attachment.htm>