Welcome to pay attention to the rich way Web development team, PHP, front-end need you. Lack of people crowd
Where to begin? Let me get this straight. There’s a lot of stuff. I don’t want to take you to the ditch. So let’s cut to the chase and tell you what it is. As the title says, it is actually a mobile browser in the ipo subscription page for the user to enter the transaction password.
Just enter the transaction password, thinking it’s easy to look at, easy to do.
The following content has been futu securities ipo subscription module as the background.
Before into the pit
Very happy, and really want to the same. The ipo subscription line has no problem. The visual input of the transaction password should look like the picture below. The original copy of the subscription can not be found, find a bug single instead of it. Very simple, as long as the verification of the input transaction password is consistent with the verification logic after submission, no redundant operation. This design actually does not have much to do on the front end. Less.
Older versions of the WEB enter passwords for transactions
Well, that’s right. Today is the story of me and the inconspicuous input password box above.
Life is full of surprises. If it were that simple, it wouldn’t be so much.
Into the pit
It wasn’t long after the launch. Due to the development of ipo subscription business, the page needs to be embedded in the App. Thought should also be no problem, after all, the page has done mobile adaptation.
N days went by. One day, I was approached by a student in charge of App design specifications. It said that the operation of entering the trading password on the ipo subscription page does not meet the App design specifications and needs to be modified. Full of…? So I, like I said at the time, I was following the design code on the WEB side.
A bit of background: Well, the company App and WEB each have a different set of design specifications, and usually don’t have much overlap. But once a WEB page is embedded in the App, there is a problem. Because the pages made according to the WEB design specifications are embedded in the App, they may not conform to the design specifications of the App.
App input transaction password design draft, you can see that it is completely different from the WEB, this is the input box of the original App
Okay, so this specification design intersection I stepped on. So what do you do? Get the head of the front end, the head of the WEB design, the head of the App design, the head of the vision together.
Blah blah blah blah blah blah blah blah blah blah blah blah!!
After discussion, we finally decided to modify the specification on the WEB side, try to use popup window to enter the transaction password, and change the input transaction password on the WEB side to be consistent with the specification of the App. This is what the popover below looks like when you enter your trading password.
The transaction code is a six-digit combination
New in version 01 Enter a transaction password using the WEB
As you can see from the image above, clicking the “Subscribe now” button will bring up a popup window for entering the transaction password, and then clicking the popup window for typing (the soft keyboard version doesn’t pull up automatically). After entering the password, submit the password according to step 1 and step 2 in the picture on the right.
Part of the transaction password popup HTML:
<div class="ui-dialog-body ui-form">
<div class="ui-form-item" ng-class="{'ui-focus':focused}">
<ul class="pwdList ui-form-text">
<li ng-repeat="item in passwordList track by $index" ng-click="inputFocus()">
<span ng-class="{'dot':item}"></span>
</li>
</ul>
</div>
<input type="text" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
</div>
Copy the code
Show the length of the transaction password entered through Li
The idea is to put a transparent input box on top of ul, where li is used to show the length of the input password.
Shortly after the launch, there was feedback from users that they could not submit the transaction password. The reason is that clicking “Confirm” on the submit button on ios does not work when the soft keyboard is not hidden.
User feedback, click submit invalid, this is no solution… Please save
And just like that, I made it.
The first version of the online, summed up the above input transaction password box in the mobile terminal problems:
- Can’t automatically pull up the soft keyboard;
- [Fixed] The soft keyboard cannot be properly submitted when it is not hidden.
- Click enter transaction password to pull up not the numeric keypad;
- The password is incorrect and there is no chance to retry. You need to click Subscribe Now. The password box is displayed.
Dig a hole in the…
In view of the above problems, decide to deal with questions 2 and 4 first. Because it has affected the normal business process experience. And so the optimized version begins.
To solve problem 2, there was a discussion (again) about removing the “cancel” and “confirm” buttons in favor of auto-submit (that is, automatically making a back-end Ajax request when a user enters a password of six digits). This ensures that business is not affected. For question 4, the second pop-up window is provided to input the transaction password, making the whole business operation process more smooth.
New version -02 Click “Subscribe now”, the box for inputting the transaction password pops up, and the transaction will be automatically submitted after the input. After the submission, the password error is found and the message “Retry” is displayed.
The optimized version is more beautiful, more efficient, and most importantly, a better user experience. Trade password popup without “confirm” button
<div class="ui-dialog-box passwordBox" ng-class="{'ui-show': isShowPwd}" ng-show="isShowPwd">
<div class="ui-dialog ui-center">
<div class="ui-dialog-header">
<h3 class="ui-dialog-header-title">{{dtitle | | 'please enter the rich way trade password'}}</h3>
</div>
<div class="ui-dialog-body ui-form">
<div class="ui-form-item" ng-class="{'ui-focus':focused}">
<ul class="pwdList ui-form-text">
<li ng-repeat="item in passwordList track by $index" ng-click="inputFocus()">
<span ng-class="{'dot':item}"></span>
</li>
</ul>
</div>
<input type="text" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
</div>
<i class="ui-icon ui-dialog-close icon-close" ng-click="closeClick()"></i>
</div>
</div>
Copy the code
In this way, I filled up the 2 holes I buried. At the same time, he dug two holes for himself.
Not long after, customer service students feedback said that Android users click “subscribe now” button, the transaction password box pop up, click to enter the transaction password found (at this time, has not done automatic pull up the soft keyboard), the soft keyboard blocked the input box.
Click on input transaction password, the soft keyboard blocks the transaction password box, my god…
The second problem was that the soft keyboard was not hidden when the transaction password was submitted automatically. The tested students mentioned bugs.
Woo woo woo woo Bug. There’s so much shit going on on mobile.
Two problems solved, two more.
I can only blame myself for taking it for granted. To sum up, the existing problems:
- Can’t automatically pull up the soft keyboard;
- Android trading password box is blocked by the soft keyboard;
- Click enter transaction password to pull up not the numeric keypad;
- The soft keyboard is not automatically hidden after auto-submitting code.
All right, four more questions.
Fill in the pit…
Let’s prioritize the problems again, and again, question 2 and question 4 should be dealt with first.
Problem 2 The transaction password box of android is blocked by the soft keyboard
We all know that when we enter data on a page. When the general soft keyboard is pulled up, the corresponding input box will be moved up. Make sure the input box is visible to the page. The normal situation is shown in Figure 1 on the left, but some browsers block the input field when the soft keyboard is displayed, as shown in Figure 2 on the right.
One on the left is normal, two on the right is not
The solution is:
.pwd-wrapper{ position:fixed; // Top: 10px; / / the z - index: 999; }Copy the code
The popover originally was Fixed. By setting the top attribute of the popover, the transaction password popover was placed at the top of the page. This prevents the popover from being blocked by the soft keyboard.
You might think it’s incongruous that popovers aren’t centered up and down. Only a bad browser would be out of center, but it’s better than a soft keyboard blocking the password box for transactions. In addition, a normal browser, even though I wrote top:10px above it looks like it doesn’t have a center-aligned top and bottom, does have a normal center-aligned top and bottom.
This convinced me that, in a word, everything was okay; There’s a problem, there’s a problem.
Well, problem number two is happily solved.
Problem 4 The soft keyboard is not hidden automatically
This should be easy to solve. You just take the input field out of focus.
$('input[name="txtPassword"]').blur();
Copy the code
Isn’t that a free question? It’s so simple. Why didn’t I add it then? I remember I did.
“It is clear that the next door is arranging into popover password components JavaScript events did not add the correct location…” . >_> just kidding.
The advent of front-end black tech
Through a fierce tiger operation, the user experience has risen a lot. The refill…
You can breathe a sigh of relief. Then slowly solve the two remaining problems above.
- Can’t automatically pull up the soft keyboard;
- Click on the transaction password to pull up not the numeric keypad.
Thinking, or the first optimization pull up is not the number keyboard problem.
Fixed an issue where entering a transaction password did not pull up the numeric keypad
If no special type is set for input, the soft keyboard is typically displayed in the language chosen by the user’s Settings.
Input Sets type=”text” scheme
Always use the type=”text” input box. Therefore, you can input Chinese by clicking the soft keyboard pulled up by the popup window, which is obviously not in line with the numbers required by the transaction password.
Default popup input part of the code:
<div class="ui-dialog-body ui-form">
<div class="noticeInfo">{{notice}}</div>
<div class="ui-form-item" ng-class="{'ui-focus':focused}">
<ul class="pwdList ui-form-text">
<li ng-repeat="item in passwordList track by $index" ng-click="inputFocus()">
<span ng-class="{'dot':item}"></span>
</li>
</ul>
</div>
<input type="text" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
</div>
Copy the code
By adding pattern=”[0-9]*” on the basis of type=”text”, it can be found that ios can pull up the numeric keypad normally, and Android is not Chinese input method.
Happy, this plan is acceptable.
The code is modified as follows:
<input type="text" pattern="[0-9] *" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
Copy the code
With only a few minor changes, the soft keyboard is already showing up as expected. For example, as shown below.
Pattern =”[0-9]*” pattern=”[0-9]*”
Try using type=”number” and type=”password”.
The test code is as follows:
<! -- type = number -->
<input type="number" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
<! -- type= password -->
<input type="password" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
Copy the code
You can see that type=”number” brings up the numeric keypad; But it’s not a 9 grid, and type=”password” pops up letters, not to mention a mediocre effect.
Default type=”number” on the left, type=”password” on the right
Finally, after comparison, it is decided to use the format. At least ios pulls up the 9 grid, Android pulls up the numeric keypad.
Just like that, optimize go a wave…
The problem is usually the bosses’ phones
While I was drinking orange juice, listening to music, stroking code. The product sent us a picture.
When users set Sogou as the default input method
What ????????? Pull up the soft keyboard unexpectedly when sogou input method, this must be advertising.
I asked about the cause and effect, it turned out to be a VVIP customer ah, no wonder the input method has special treatment. This is embarrassing, I can’t ask the customer to change the system default input method.
This is mainly due to the risk of third-party input methods recording passwords.
Can’t wait, immediately pull a vote of people together to discuss, quack quack quack quack quack quack quack quack quack quack quack quack !!!!!
Through discussion, the following schemes are obtained:
- Instead of
<input type="password">
Format, so you can pull up the native input method, but not the numeric keypad - Ask the client to help see if you can limit the input method; This works fine in the App, but it still causes problems in the browser
- Their own password input keyboard, want to dig the scheme
But none of the above is good. And the product? The product boss didn’t agree. What to do??
Concerted efforts to get to the Internet search ah, see what websites are pulled up soft keyboard is native digital keyboard, finally picked up a.
The code is simple:
Labor, I almost sat on the floor when I saw this line of code. What!! And this kind of operation, black tech ah no. I bought it anyway. What are you waiting for? Give it a try.
Part of the code is as follows:
<div class="ui-dialog-body ui-form">
<div class="noticeInfo">{{notice}}</div>
<div class="ui-form-item" ng-class="{'ui-focus':focused}">
<ul class="pwdList ui-form-text">
<li ng-repeat="item in passwordList track by $index" ng-click="inputFocus()">
<span ng-class="{'dot':item}"></span>
</li>
</ul>
</div>
<input type="tel" pattern="[0-9] *" name="txtPassword" ng-trim="false" ng-model="pwdValue" ng-change="updatePassword();" ng-focus="onFocus();" ng-blur="onBlur()" autocomplete="off" autocorrect="off" maxlength="6">
</div>
Copy the code
I can actually do it. Is there. What you can really do with type=”tel” is the native 9 grid keyboard. Looks like the call was made by the real dad.
Set input field type=”tel”
Make sure you take a notebook to write this down.
git commit -a 'For user password security, pull native 9 grid keyboard by default'
Copy the code
Finished.
How to automatically pull up the soft keyboard
The original soft keyboard never pulled up automatically. The interaction logic looks like this: the user must manually click on the input box to pull up the soft keyboard.
Cannot automatically pull up the soft keyboard
Now it wants to be able to automatically pull up the soft keyboard after the user clicks the “Subscribe now” button. As shown in the figure below.
Automatically pull up the soft keyboard
The general approach is to add a click event on the “Subscribe Now” button. Once the “Subscribe Now” button is clicked, the focus event of the transaction password box will be triggered.
Try to achieve:
Modify subscription button HTML:
<button type="submit" class="ui-btn" ng-click="submitApply()">Subscription immediately</button>
Copy the code
Processing via JavaScript events.
$scope.submitApply = function(){
// Focus the password box
$input.focus();
$scope.focused = true;/ / set the flag
}
Copy the code
There are dozens of them on the Internet. While it works on PC, it doesn’t pull up the soft keyboard properly on mobile.
Conclusion: Direct focus() does not work and requires further research.
Use Input focus to pull up soft keyboard features
Since the soft keyboard only pops up when the user manually touches foucus. On the basis of the original, can we try to change the “Subscribe now” button into the input box and use the original button as the background?
The case goes through a wave and changes the button structure to the following format:
<div class="sub-container">
<button type="submit" class="ui-btn" ng-class="{'ui-btn-loading': ! isCanApplyNewStock}" ng-disabled=! "" render.agreement||! isCanApplyNewStock" ng-click="submitApply()">Subscription immediately</button>
<input type="tel" pattern="[0-9] *" class="trade-pwd" ng-click="submitApply()">
</div>
Copy the code
How to do it: put a transparent input box on top of the subscribe button, when the user clicks, it is actually clicking on the input box. Guess: At this point, since the input box is clicked, the soft keyboard will pull up and the submitApply() function above will focus the cursor on the transaction password box.
Button structure
Through the real machine test, found that can normally pull up the soft keyboard. The conjecture is true.
Pull up digital soft keyboard normally
Practice shows that through an input box, after pulling up the soft keyboard, you can execute focus() to other input boxes through JavaScript, and ensure that the soft keyboard will not collapse, and can normally input the focused input box.
Take a walk…
conclusion
In general, are some input box operation, know the principle, in fact, is very simple. What are you waiting for? Go optimize your input box.
If you have good suggestions, welcome to leave a message to exchange.
Original text: futu. Im/article/inp…
Author: Jin