Design of Forms

Matt Wagner matt.wagner at redhat.com
Wed Aug 15 14:27:22 UTC 2012


On Wed, Aug 15, 2012 at 11:37:03AM +0200, Jaromír Coufal wrote:
> 
> >- I think the "?" for tooltips should be closer to the input. Maybe on
> >   the other side of the label? Or maybe on the right of the input? It's
> >   just where I would look for it.
> There are 3 types of tooltips (except error messages):
> * ?... for label (what this term/concept means - for hardly
> understandable terms)
> * i... for input (what and how to fill, restrictions, etc.)
> * note... always visible important note for this field
> 
> So I decided to move question mark on the left, because on the right
> it would break vertical alignment of labels and it is related to the
> content of the label (not input). Hovering label displays you this
> help information anyway (regardless the position of question mark).
> Moving it to the right of input would collide with input hint :-/

I think if I were doing this myself (with no UX experience, mind you!),
I'd have placed them either to the immediate left or immediate right of
the input. But I think you're right that putting them elsewhere would
cause problems with other information we display. So your way sounds
good with that explanation now. :)

> >- While using a "*" to mark required inputs has a lot of precedent, it's
> >   also sometimes used to denote fine print or a footnote. Would it be
> >   clearer if we used bold text for required fields, maybe?
> Yes, star symbol has lot of precedent, but I think that users are
> used to this type of marking required fields in forms.
> For me is star symbol clearer, but it's just personal opinion. Anyway
> it is really easy to change, so we can change it in the future if
> needed.
> 
> But I played a little bit and forked the form, so you can look for
> another examples how to display required fields:
> http://codepen.io/coufalj/pen/boBGa (bold label)
> http://codepen.io/coufalj/pen/ngpvc (input background) - in this case
> not usable for checkboxes, radios, files, ...

Oh, wow. Bold labels look a lot more strange than I expected. I've seen
them used effectively in the past, but instead of wondering if the stars
denote fine print, I find myself (in the shoes of a normal user)
wondering why some fields are bold and jumping out at me and others are
not. It looks kind of weird compared to *'s.

The input background is a neat idea, but I think your point about it not
working for all input types is a good one. Plus it's not quite as
intuitive to me.

So okay, you're right -- asterisks seem best here! (Maybe we can set a
title/alt text on them if we use an image, to say "Required Field" in
case people are really baffled?)

> >I wonder about the markup, though. Will a developer building a form need
> >to deal with creating a .control_group that contains a .left_column and a
> >.right_column? It seems like this could be error-prone. Or will the form
> >library we discussed automate this?
> As I remember, simple_form tool (which we were discussing before) can
> manage this easily (you can set up structure in initializer). I
> cooperate with Imre to ensure that it really does. But you are right
> in this and that's the main reason for using simple_form.
> I tried to use it without left/right columns but then it's hard to
> position tooltips and messages correctly :-/

Yeah, form helpers would go a long way here. My fear isn't necessarily
that developers might have to do a little extra work, but that if it's
not totally obvious how to do it correctly, we'll end up with forms by
different developers looking different -- which is kind of where we're
at today.

> >The Date input does not work in my browser.
> Yeah, some browsers still doesn't support HTML5 data types :(
> http://caniuse.com/ check support here, this is really useful page.
> --
> http://caniuse.com/#feat=input-number (number input)
> http://caniuse.com/#feat=input-datetime (date input)
> http://caniuse.com/#feat=input-placeholder (placeholder)
> 
> E.g. placeholder for IE we can fix by using javascript.
> For other special form types we need to figure out, how to deal with
> them in unsupported browsers. But if we don't, user is still able to
> fill them out in normal way (classic input) and complete form.

Oh, wow, I didn't know that support was _that_ bad right now. 5.29%, and
25.83% "partial" support for date/time inputs.

-- Matt



More information about the aeolus-devel mailing list