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, [email protected] == == 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
