1

I'm tasked to implement a code entry view which allows you to enter a 6-digit code. The UI runs in the browser (JS/HTML/CSS), mobile touch devices only.

I'm stuck on how to implement this, basically I came up with these two scenarios:

Use the native built-in keypad

  • (+) Built-in, accessibility
  • (-) Requires an initial tap to trigger the keypad
  • (-) Requires at least one "invisible" <input> tag
  • (-) Handle "zoom-in" on the input field so that all digits are visible
  • (-) Handle blinking cursor alignment with digits or use six separate input boxes with proper alignment and switch focus after each entered digit.
  • (-) Relies heavily on how device handles/renders input fields.

Use a custom HTML/JS keyboard, basically a grid of buttons

  • (-) Accessibility
  • (-) Keypad needs to fit on screen on every device
  • (+) No initial tap required to trigger a keypad
  • (+) Consistent look and feel

What are your thoughts about this?

Code entry view

  • I'm not convinced it needs the initial tap to trigger it; I've got several programs where the keypad automatically pops up when the entry is required - and somehow, the app knows whether to pop up a numeric pad or a typewriter pad. – Jeff Zeitlin Mar 27 '18 at 11:30
  • @JeffZeitlin I know this can be done on native apps, but for a website an initial user interaction is required to allow focusing a text field. – sled Mar 27 '18 at 12:04
  • Still not convinced; I'm pretty sure I've seen it where the web page has an onload() or ongotfocus() event defined. Or something like that; I'm not a web programmer, so I don't have the event method names memorized. – Jeff Zeitlin Mar 27 '18 at 12:15
  • @JeffZeitlin I made an example here: jsfiddle.net/st5dg76g/1/embedded/result it focuses on Desktop browsers, but on my iPhone it does not. – sled Mar 27 '18 at 12:23
  • Interesting, and duplicated on my job iPhone, and my personal Android phone. – Jeff Zeitlin Mar 27 '18 at 12:33
1

There's really three issues here...

  • Accessibility: Either approach can be just as accessible and just as easy to implement depending on who you plan on making the app accessible for. If this is only for mobile touch devices, what matters is that elements are scaled properly so people don't mistakenly press the wrong button.
  • Interaction Cost: Extra click? Is that click meaningful? If so, keep that click. However, is there anything else the user would do other than enter in numbers? If not, then build a screen that has those inputs there already. You create steps in a process to allow users to make meaningful decisions (or to inform them what just happened or is about to happen). If that decision is largely redundant, automate it. Design screens with a prominent call-to-action that are blatantly waiting for that crucial decision.
  • Cross-Device Support: Don't rely on an operating system or browser to do things precisely how you want them to. If you really want something to work just-so, you're rolling your own solution. With flexbox and vh/vw CSS units it's now very easy - and even without those it's still easy - to create a layout that adjusts to any screen. If you want to establish a brand, define interactions meticulously.

So, with that, I would say option 2 is the way to go. Native UIs are inconsistent and add interaction cost. Your own solution will behave exactly as you want it to, and if you do that right, your users will be delighted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.