23 May
2014
23 May
'14
11:32 a.m.
On 05/23/2014 02:00 AM, CrÃstian Viana wrote: > On 16-05-2014 00:05, Hongliang Wang wrote: >> 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. > Thanks for the clear explanation! > > But I think we're talking about different things. I am trying to > update the form validation behaviour here (i.e. when the submit will > become enabled so it can be clicked, based on the user's input). You > are talking about form initialization (i.e. how the form will be in > its initial state, taking into account which fields are filled so the > correct element is focused). I don't mean to change that now (even > though it's a nice topic to discuss for future patches...), your > explanation makes sense. What's important to me now is what will > happen if the users types something / deletes something after the form > is loaded. Yes I knew that. In fact, the UX of cursor functionality is partially broken. Let's take a specific example. 1. User logged in with kimchi/kimchi credential and let browser save the password. 2. Next time he logs in, browser will automatically fill the fields with saved credential. The cursor should be placed at log-in button and user can press enter to log in. Though with this patch applied, log-in button is disabled and it's confused for the user: everything is OK why I'm not allowed to log in? In current implementation, validateNonEmpty() has a call to placeCursor() so cursor will be taken into account every time we do validation. So in this patch, similar actions should be taken according to cursor.