UL&S: Spike to research anchoring the Continue button to the keyboard

[mindgraffiti]

Ref. pbArwn-Al-p2

@mattmiklic asked what options are available from a technical standpoint to handle the Continue button and the keyboard. This is the Proof of Concept for anchoring the button to the keyboard.

The request was for small / compact devices to scroll the Continue button and the larger devices to anchor the Continue button to the keyboard.

The pieces of content chosen for the mocked up displays are representative of each tableviewcell we'll be building in the future - error labels, textfields, image + email (profile), large titles, secondary help buttons, etc.

Findings

Requesting technical verification that these things are possible / not possible.

1. It's not possible to create a scrolling Continue button (think button in a tableviewcell) for the iPhone SE without also targeting all devices classified as compact.
2. It's not possible to create a scrolling Continue button without extra time spent refactoring the existing code, due to the inheritance levels and behavior of the submitButton found in the NUXViewController, LoginViewController, and LoginSiteAddressViewController (lots of code + UI dependencies).
3. There can only be 1 solution implemented at a time: all devices have a scrolling Continue button or all devices have the Continue button anchored to the keyboard, because writing code for both would be error-prone and require extra overhead for the current and future devs.
4. Alternative implementations I may have missed?

Proposal

1. (original implementation plan). Anchor all Continue buttons to the bottom of the screen and let the keyboard overlay them. Keyboard "return" button can be configured to say "next" so that tapping the keyboard button moves the user to the next view. Keyboards are easily dismiss-able so users can tap the large Continue button instead if they want. (or)
2. Anchor the Continue button to the keyboard on all devices rather than attempt a combination scrolling button + anchored button that depends on a specific device or size class. Mocked up proof of concept for iPhone SE, iPhone 11 Pro Max, and an iPad Pro 12.9".

iPhone SE

iPhone 11 Pro Max

iPad Pro 12.9" 4th generation (iOS 13.x)

[ScoutHarris]

Hey @mindgraffiti . I agree 100% with everything you've stated.

Findings:

It's not possible to create a scrolling Continue button for the iPhone SE without also targeting all devices classified as compact.

👍

It's not possible to create a scrolling Continue button without extra time spent refactoring the existing code

👍

There can only be 1 solution implemented at a time

Preferably. Because of the issues you noted.

Alternative implementations I may have missed?

Theoretically, anything is possible. But I think you nailed it with: writing code for both would be error-prone and require extra overhead for the current and future devs. This trickery would just be painful.

Proposal: I think those are both acceptable solutions. FWIW, I would vote for the first one. It is more straightforward, less error-prone, and (I believe) most common. I'm not sure why the need to "float" the button if the keyboard accomplishes the same thing.