Design of Forms

Hugh Brock hbrock at redhat.com
Wed Aug 15 14:32:49 UTC 2012


On Wed, Aug 15, 2012 at 10:27:22AM -0400, Matt Wagner wrote:
> 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.

Might be worth looking at Chronic to give users a helping hand on the
dates. Chronic will correctly interpret things like "Last Tuesday" in
addition to all the regular date formats.

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list