On 05/16/2014 05:08 AM, CrÃstian Viana wrote:
On 15-05-2014 03:51, Hongliang Wang wrote:
> There's some problem with this new function. And there is no need to
> replace the current validateNonEmpty() function.
> In the current validateNonEmpty() function, several checks are
> processed:
Those checks don't make sense if the submit button is disabled while
some of the required fields are still empty:
> 1)
> If user name field is empty, then
> put cursor in user name box
If the user name field is empty, the user won't be able to click the
log in button; no need to take them back to the user name field.
> Else if password field is empty, then
> put cursor in password box
If the password field is empty, the user still won't be able to click
the log in button; no need to take them back to the password field.
> Else
> put cursor on log in button
>
> 2)
> If some field is empty, a message will show to tell user the field
> is required.
If some field is empty, the user won't be able to click the log in
button; no need to display a message on the screen.
Again, I'm trying to make the Kimchi forms consistent. Some forms
leave the submit button enabled all the time and when the user clicks
it, the entire form is validated; other forms leave the submit button
disabled and enable it only when the required fields are filled; some
forms highlight the required fields when they're empty; some forms
remove automatically the text entered by the user if it thinks the
data is invalid (!!); some forms don't even have a submit button
visible all the time...
I'd like to see a single behavior regarding form validation across
Kimchi. We can use a combination of those features I mentioned above
(most of them are nice), but we must decide and use the same approach
everywhere. Which is not the case right now. I chose one of them to
create this patch (i.e. keeping the submit button disabled until all
required fields are filled) so we can start discussing about
consistency, but I agree we should decide something else better. As
long as it's applied everywhere and the user always knows what to
expect when browsing the application.
OK. I understand your point and it's
good, please go ahead to make it
consistent.
Though another aspect is that you need remain the consideration for
user experience. Maybe there is misunderstanding for my "put cursor"
lines. Let me explain it in more details.
Case#1 New user visits Kimchi for the first time
There's no cookie set so the user name text box will not be filled by
cookie value. So we are to place focus cursor into user name box to
provide the convenience that allows user quickly press keys without use
mouse to click the cursor into the box first and then start pressing
keyboard.
Case#2 User logged out Kimchi and visits Kimchi again later
If user allows browser to save cookie, his user name was save into
cookie and Kimchi code will load it automatically and fill it into user
name box. So it's probably the user will use this same user name and he
only wants to input his password. So we place focus cursor into password
box.
Case#3 User saved his user name and password
In this case, the user only wants to press Enter key or click log-in
button to log in. So we focus the log-in button by default to allow user
log in by simply entering Enter key.
Hopefully I explained it clearly.