959525 - Revisit Pin Entry UX and reconsider if using real inputs is preferable.

Status: VERIFIED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P4)

Description

[Stuart Colville [:muffinresearch]]

The pin entry currently looks like 4 inputs. However under the hood what really what happens is there is a hidden input into which the pin characters are entered and as each character is filled there the UI updates to show each character has been entered by filling an input lookalike with a circle character.

This can be deceptive when there are bugs because users expect something that looks like an input to behave like one.

Once issue I can see is that using real inputs means you have to have a caret in each input. This feels clunky however that might just be a result of being used to the caret-free look and feel currently have.

This bug is to reconsider if we should move to using real inputs for this in tghe Single Page App, e.g. either 4 separate password inputs or a single password input.

The original interface was built before my time so maybe there were good reasons for the approach taken. If so can they be detailed here?

Comment 1

[Kumar McMillan [:kumar]]

potch might be able to answer questions about why the PIN interface uses a single hidden input under the hood

Comment 2

[Tony Santos [:tsmuse]]

I didn't design the existing PIN UI, but I can speculate a bit about it and make a recommendation. 

Speculation part: The PIN UI is four separate boxes to quickly read that a PIN is a 4 character value and not require a "return" keypress to kick off validation. This is a fairly standard UI pattern for this kind of data entry on mobile devices [1][2][3], although it looks like Google has stepped away from this pattern in recent versions and gone to a single field to collect a pin or a password (although their implementation is a bit confusing because it breaks the pattern, you have to hit the return key), and iOS has redesigned the boxes to be little circles that start out empty an fill in as you enter digits. Most importantly though, the PIN entry UI for payments matches the PIN entry UI of the FFOS lock screen if you choose to use a PIN to lock your phone [4]. Which one came first, I'm not sure, but I assume they are the same by design.

Recommendation part: PIN entry for payments (and anything else, really but we have less control over that) should mirror PIN entry for unlocking the phone. One data type, one entry method is easier to remember. I don't know if this is confusing (or bug prone) or not, but if we want to discuss changing it, we should also discuss changing it on the lock screen. 

Hope that helped. 

[1]http://taybridgeconsulting.com/wp-content/uploads/2013/06/ios4.png
[2]http://i.stack.imgur.com/kS2eA.png
[3]http://cdn7.staztic.com/app/a/2932/2932982/trick-lock-4-digits-11001-2-s-307x512.jpg
[4]https://www.dropbox.com/s/5k74f09t1q11aim/ffoslockscreen.png

Comment 3

[Stuart Colville [:muffinresearch]]

Having discussed this with Tony at the recent Q1 Marketplace work week I propose the following:

I'll look at Gaia and try to follow the implementation there as much as possible. This way should provide both consistency in terms of L&F plus it might help avoid as many platform bugs as we have.

I'm going to mark this as resolved as I think we have a clear direction. If anything else comes up we can always re-open or raise a new bug.