[Patternfly] Share your thoughts: syntax hints used in forms
Jonathan Yu
jawnsy at redhat.com
Mon Nov 21 18:35:40 UTC 2016
I don't have any specific recommendations, but hoped that these questions
might help you refine the interaction design:
1. Is the syntax well-defined based on your problem domain? The same
phone number can be written as +1 (650) 555-5555, 6505555555,
650.555.5555, ...
- Would client-side parsing and formatting be better than showing an
example? If the user types "6505555555", format that for display "(650)
555-5555" either inline (tricky) or in an adjacent output text area.
This shows the user that we understood their input, allows them
to confirm
things were input correctly, and allows the user to enter the number in
whatever format they prefer.
- Are there secondary validations that would be useful? It looks
like a phone number, but is it a valid one that the user
controls? Twilio
specializes in this sort of stuff, and they have a useful Lookup
API [0, 1].
2. Is the syntax required to understand the contents of each field?
- The second link doesn't have any examples and seems pretty
understandable, so maybe the placeholder text is superfluous?
- If it's required, then how should it interact with assistive
devices like screen readers? And is the low contrast problematic for
visually-impaired users?
- The disappearing text trick looks cool (though it doesn't seem to
work in Firefox on my machine), but is it actually helpful for the user?
Additionally, it implies that only http:// links (not the https://
links that are more preferred nowadays) are accepted.
- I'm a fan of minimalism and Strunk/White's "omit needless words"
(perhaps more than this hastily-written email would seem to suggest)
3. Is the user interested in what needs to be put in the box (syntax),
or do they want to know how the information will be used (usage)? The
"this will be used to sign into your account" comment is helpful, as would
a "we won't spam you or share your email with anyone" promise.
4. Is your form interactive?
- Would progressive disclosure make the form less daunting at first?
The more explanatory text and fields that are on a form (whether
online or
on paper), the worse your conversion rates are likely to be. At
least for
me, seeing forms with lots of fields or legalese makes me go
"ugh, how much
do I *really* need whatever the form will grant me?"
- The business rules may vary based on some parts of the form input;
for example, in OpenShift Online, we need to collect your county (for tax
purposes) for the United States, but not for other countries, so we
progressively disclose that input according to the country (which is
completed "earlier" by virtue of being ordered first in the form, on the
underlying assumption that most people complete forms top-to-bottom)
5. Is there an intelligent default that can be automatically detected
or inferred? For example, if you have the user's address, you can likely
infer their timezone (which, as an aside, should be an IANA timezone [2]
like America/New_York to properly handle daylight savings and other
rules). Similar for currency, language, or other
internationalization-related things like preferred number formatting. Of
course, these should be overridable.
My general thought with respect to implementation difficulty is a simple
cost/benefit comparison:
- Is it a one-off? For example, a little web site to go along with an
ad campaign for a limited time wouldn't justify as much investment.
- Is it a problem shared by many applications? (phone number or email
fields - or any of the other special HTML5 form inputs
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Attributes>
- are a good indicator that the control is common across many different
types of applications)
PatternFly is great because we all benefit from the initial user research,
design, and development effort, amortizing that initial upfront investment
across all the users of it, so it's often worth spending a relatively long
time working on something, especially if it improves key metrics like
conversion rates (and general user/customer happiness). An example I
really like is this country selector: explanation [3] and demo [4]
Best of luck!
Jonathan
[0] https://www.twilio.com/lookup
[1] https://www.twilio.com/blog/2016/03/announcing-caller-id-
name-lookup.html
[2] https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
[3]
https://www.smashingmagazine.com/2011/11/redesigning-the-country-selector/
[4] http://baymard.com/labs/country-selector
On Thu, Nov 17, 2016 at 1:32 PM, Jessica Ryhanych <jryhanyc at redhat.com>
wrote:
> Hey Leslie,
> That is a great point – I found two examples of responsive forms that
> could be a workaround:
>
> 1. The syntax text stays visible when a user clicks, but only disappears
> as they start typing. See here <https://order.emporiumpies.com/>. (In
> step 1 of the form, pick Delivery to see a few examples.)
>
> 2. The syntax text gives the user an idea of the format needed and appears
> for about 1 second after clicking in the field. See here
> <https://stuffandnonsense.co.uk/contact>. (look for “Existing website
> address”)
>
> Thoughts from everyone? Would this be challenging to implement? Depending
> on the length of the form, I could see option 1 becoming visually
> distracting.
>
> Thanks,
> Jessica
>
> */ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / *
>
> *Jessica W. Ryhanych*
> Senior Designer, Employment Branding + Communications
> Red Hat
> jryhanyc at redhat.com
>
> On Nov 17, 2016, at 10:52 AM, Leslie Hinson <lhinson at redhat.com> wrote:
>
> Thanks for sending this out Jessica.
>
> One of the things that will be tricky if figuring out a solution for how
> this text behaves in the responsive states. That would be the advantage of
> putting syntax help inside the text box. However, I know that it's a
> usability issue when the syntax help disappears when the user clicks.
>
> Leslie
>
> On Tue, Nov 15, 2016 at 2:18 PM, Jessica Ryhanych <jryhanyc at redhat.com>
> wrote:
>
>> Hi PatternFly,
>>
>> I’m gathering information during this sprint on syntax hints used in
>> forms and need your feedback. What have you observed? What worked well?
>> What did you find distracting? What use cases need to be addressed?
>>
>> I’ve been reviewing an excerpt
>> <http://static.lukew.com/webforms_lukew.pdf> from Luke Wroblewski’s
>> book, Web Form Design, and found a few examples that might be food for
>> thought.
>>
>> *Examples:*
>>
>> - syntax hint is below input field, left aligned, font color & weight is
>> differentiated from label text
>> <Screen Shot 2016-11-15 at 1.51.13 PM.png>
>>
>>
>>
>> - syntax hint is left aligned to input field, font color & weight is
>> differentiated from label text
>> <Screen Shot 2016-11-15 at 1.25.31 PM.png>
>>
>> - syntax hint follows label text, font color is differentiated from
>> label, placement above input field
>> <Screen Shot 2016-11-15 at 1.25.39 PM.png>
>>
>> Please share any examples from your daily work and/or other
>> considerations I might have missed. Thanks!
>> Jessica
>>
>> */ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / *
>>
>> *Jessica W. Ryhanych*
>> Senior Designer, Employment Branding + Communications
>> 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
>
>
--
Jonathan Yu / Software Engineer, OpenShift by Red Hat / Follow me on
Twitter @jawnsy <https://twitter.com/jawnsy>
*“Restlessness is discontent — and discontent is the first necessity of
progress. Show me a thoroughly satisfied man — and I will show you a
failure.”* — Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20161121/3dbbcbab/attachment.htm>
More information about the PatternFly
mailing list