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
