Jörn Zaefferer schrieb:
Hi folks,
what is your preferred approach to display messages? Think of validation
messages for a form.
I'm looking for an approach that would work for both client- and serverside
generated messages.
For example, a form is validated via JS and displays some
Jorn,
Here's an example that I've been playing around with:
http://beta.ksscholl.com/jquery/form2col.html
This offers the user a message as to the nature of the error, as well as
marking the label for the affected field. In this sample, the message(s) are
placed at the beginning of the
Hi folks,
what is your preferred approach to display messages? Think of validation
messages for a form.
I'm looking for an approach that would work for both client- and serverside
generated messages.
For example, a form is validated via JS and displays some messages. Now the
user disables
On your plazes page, the field highlighting doesn't seem to be correct. I
would need to press it twice to get the right field highlighted.
Klaus Hartl-3 wrote:
Jörn Zaefferer schrieb:
Hi folks,
what is your preferred approach to display messages? Think of validation
messages for a form.
On 11/14/06, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi folks,
what is your preferred approach to display messages? Think of validation
messages for a form.
I'm looking for an approach that would work for both client- and serverside
generated messages.
I always append a div with an
Hi Klaus!
Hi Jörn, I think both messages for a form submit with server roundtrip
and on-the-fly validation doesn't have to be the same necessarily...
Here's an example: http://beta.plazes.com/register/
* Submit the form and you will get error messages gathered on top of the
form, and
Brandon Aaron schrieb:
I always append a div with an unordered list of elements above the
form and then link each error message to an input.
That's nice and I do that too. Most browsers don't focus a field from a
link pointing to the field's id, so I usually add a click event to
explicitly
Jorn,One idea for form validation (don't know how practical it would be to code)...would be that the next/following input is only enabled if the current input is successfully filled with the correct data.So the scenario would be that on inputting data into input No1, if the input is not validated
Here's an example that I've been playing around with:
http://beta.ksscholl.com/jquery/form2col.html
This offers the user a message as to the nature of the error, as well as
marking the label for the affected field. In this sample, the message(s) are
placed at the beginning of the section
n Behalf Of Giuliano
MarcangeloSent: Tuesday, November 14, 2006 7:30 AMTo:
jQuery Discussion.Subject: Re: [jQuery] How to display
error/validation messages?
Jorn,One idea for form validation (don't know how
practical it would be to code)...would be that the next/following input is only
enabled
On Tuesday, November 14, 2006 7:35 AM Klaus Hartl said:
Most browsers don't focus a field from
a link pointing to the field's id, so I usually add a click event to
explicitly focus the form element. The field to focus is simply read
from the link's href...
Unless I'm misunderstanding your
http://glenlipka.kokopop.com/jQuery/inlineError.htm
This was an early prototype for what is now currently live on all of Intuit's websites.
From a UX design standpoint, here are some guidelines:
1. Bigger text fields. Many (most?) users have sketchy vision and flickering monitors. Make the text
]
[mailto:[EMAIL PROTECTED] On Behalf Of Glen
LipkaSent: Tuesday, November 14, 2006 9:49 AMTo: jQuery
Discussion.Subject: Re: [jQuery] How to display error/validation
messages?
http://glenlipka.kokopop.com/jQuery/inlineError.htm
This was an early prototype for what is now currently live on all of
] How to
display error/validation messages?
http://glenlipka.kokopop.com/jQuery/inlineError.htm
This was an early prototype for what is now currently live on all of
Intuit's websites.
From a UX design standpoint, here are some guidelines:
1. Bigger text fields. Many (most
Chris W. Parker schrieb:
On Tuesday, November 14, 2006 7:35 AM Klaus Hartl said:
Most browsers don't focus a field from
a link pointing to the field's id, so I usually add a click event to
explicitly focus the form element. The field to focus is simply read
from the link's href...
On Tuesday, November 14, 2006 10:33 AM Klaus Hartl said:
Hi Chris,
Hi Klaus,
I wonder how browser behave
when the field is out of the borders of the viewport... will they
scroll down? Not sure...
That is the behavior I have always experienced. Though I should say I
don't do any testing in
I organized the answers inline. This probably breaks email ettiquette. - Glen
1. Bigger text fields. Many (most?) users have sketchy vision and flickering monitors. Make the text boxes bigger and they will be happier. Same goes for the submit buttons.
2. Have a visual indication next to required
-- Original message --
From: Glen Lipka [EMAIL PROTECTED]
3. This is assuming that javascript is enabled right?
Yes. Although, at this date, I actually believe in forcing the user to have
javascript on. I am making alot of assumptions. Color monitor, screen
[EMAIL PROTECTED] schrieb:
-- Original message --
From: Glen Lipka [EMAIL PROTECTED]
3. This is assuming that javascript is enabled right?
Yes. Although, at this date, I actually believe in forcing the user to have
javascript on. I am making alot of
On 11/14/06, Glen Lipka [EMAIL PROTECTED] wrote:
but we looked at usability tests and concluded that the more power-user the person was, the more they found it annoying, and the more newbie the person was, the more they found it helpful. But power users don't get frustrated and quit, while newbies
On Tuesday, November 14, 2006 12:10 PM [EMAIL PROTECTED] said:
I am SO glad to see someone else mention this. In my mind, users who
do not have Javascript enabled in this day and age fall are missing
out on a LOT the Web has to offer. And why? Most often, because
someone has filled their
-- Original message --
From: Chris W. Parker [EMAIL PROTECTED]
This isn't to say that our sites should fail miserably if the user
DOES disabled Javascript.
Not only should it not fail miserably, it shouldn't fail at all. Search
engines don't understand js
find this strange. Do you have any publicstudies
you can cite?
Thanks,
Chris.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glen
LipkaSent: Tuesday, November 14, 2006 11:47 AMTo: jQuery
Discussion.Subject: Re: [jQuery] How to display error/validation
messages?
I organized
On Tuesday, November 14, 2006 1:10 PM [EMAIL PROTECTED] said:
Based on some other replies, I guess I wasn't clear in my
statement(s). I'm not advocating depending on Javascript, not at all.
However, I don't think we should do away with the bells and whistles
(read: enhancements) that it
[EMAIL PROTECTED] schrieb:
Based on some other replies, I guess I wasn't clear in my statement(s). I'm
not advocating depending on Javascript, not at all. However, I don't think we
should do away with the bells and whistles (read: enhancements) that it
offers, as some people in the industry
Don't rely on JavaScript, but use it as a tool for Progressive
Enhancement.
Hear, hear! You have no way of knowing why their brower can't use
JavaScript (or CSS, or Flash, etc.), so why should you penalize them for it?
Does that mean we agree about that? Maybe I wasn't clear...
-- Original message --
From: Chris W. Parker [EMAIL PROTECTED]
On Tuesday, November 14, 2006 1:10 PM [EMAIL PROTECTED] said:
Based on some other replies, I guess I wasn't clear in my
statement(s). I'm not advocating depending on Javascript, not at all.
On 11/14/06, Klaus Hartl [EMAIL PROTECTED] wrote:
Does that mean we agree about that? Maybe I wasn't clear...Yes, that means we agree. That question was directed at the people that seemed to advocating a reliance on _javascript_.
___
jQuery mailing list
On 11/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Based on some other replies, I guess I wasn't clear in my statement(s). I'm not advocating depending on _javascript_, not at all. However, I don't think we should do away with the bells and whistles (read: enhancements) that it offers, as
I didn't mean to open up a can of worms.
I agree with everyone. The best sites degrade gracefully. However, I also know that time is often not on my side and I don't have the time to do it right.
The key is Know Thy Audience. Each has to make up their own minds how to build.
Interesting tests I
2. Same for CSS. Hmm, not sure if this can be detected, Ideas?
Maybe use a CSS background image that serves as a logger and is invisible?
body {
background: url(/log.jsp);
}
Hm, not sure how to put that in relation to the non CSS users.
-- Klaus
On Tuesday, November 14, 2006 2:48 PM Klaus Hartl said:
body {
background: url(/log.jsp);
}
Hm, not sure how to put that in relation to the non CSS users.
Those that do make the request have CSS. Those that don't, don't?
Chris.
___
Chris W. Parker schrieb:
On Tuesday, November 14, 2006 2:48 PM Klaus Hartl said:
body {
background: url(/log.jsp);
}
Hm, not sure how to put that in relation to the non CSS users.
Those that do make the request have CSS. Those that don't, don't?
Yeah, but how do you tie the css
On Tuesday, November 14, 2006 3:17 PM Klaus Hartl said:
Yeah, but how do you tie the css request to the page request?
Err, it's getting late, I have to sleep (shutdown...)
Analytics falls in the category of dark arts in my opinion so here is my
idea:
Your .css files can be run through your
Dan Atkinson schrieb:
On your plazes page, the field highlighting doesn't seem to be correct. I
would need to press it twice to get the right field highlighted.
Hi Dan,
thanks for pointing out. I cannot exactly reproduce, but I think it was
because of some server delay (the validation is done
35 matches
Mail list logo
