UI - form fields nits (umbrella) - new version

[goldsteinsveta]

• Home Screen: if there are no keys - don't show camera on "home" screen, rather start with Create New Seed flow
• User Input: let's use enter key ("Next", "Done" etc) on keyboard to interact with the app, not only to un-focus field and hide keyboard, i.g. in Create Seed when tapping "Done" I'd like to go to the next step of the flow
• User Input: focus the "Seed Name" field when user lands in Create New Seed screen, same for other "form" screens
• Layout: no need to vertically center "forms", keyboard will hide its parts
• "Back" button: don't need it on screens that are accessible via footer directly
• "Back" button: Create Seed > "Back" should lead to Keys screen, not Scanner

[Slesarew]

The enter/return/done key on keyboard purpose in ambiguous:

1. Seed creation - should the user select "seed recovery" before or after typing in name? Should "submit" happen after pressing return in seed name or in recovery phrase?
2. Key creation - fast workflow would be to create key on accepting the derivation path; but that will require user to do much more actions if name should be changed from default suggestion or password added. Which field should submit?
3. Transaction parsing - user might want to just close the keyboard and read the transaction once more.
4. Key filtering - no action is possible, just remove focus.

I think these are all places where keyboard is present. Frustration when the form just gets submitted on enter without another chance to review different field is something that bothers me personally a lot (unless there was just 1 field to fill). But if there is a way to make the flow logical, let's do it.

[Slesarew]

Vertical alignment: this is default behavior for native composing frameworks; what kind of alignment would you recommend?

[goldsteinsveta]

Here's what I think:

1. Seed creation - focus on display name > type seed display name > return = next (like "tab" key) > type seedphrase > return = done*
2. Derive Key - let's think something smart about it.
3. Transaction parsing - let's not focus by default now. And then we had this idea on Transaction screen: blurry signature > tap "confirm transaction and generate signature" on blurry signature > popover: Log (aka History) input field, focused > return = done* > signature is not blurry

* I get the annoyance when form is submitted on keyboard "enter" key. How about a rule, when there're more than N fields "return" will remove the focus and hide keyboard; if less – "return" submits the input. (N could be just 1; N == 1 at new seed's display name, device PIN, hypothetical log popover).

[Slesarew]

Hmm, so here is what I've implemented in f19f6ff

1. Seed creation - screen is focused on seed name by default; "return" dismisses keyboard and user should decide whether there will be custom seedphrase or create seed right away. Pressing enter on seed phrase input does nothing good for now, we need to come up with better design for that element anyway - some custom autosuggest and individual words as clickables, maybe even with drag/drop eventually?
2. By default focus is on path; "return" hides keyboard - at this moment user could create key or proceed with other fields. "return" on seed name hides keyboard. "return" on password moves focus to "repeat password". "return" on "repeat password" attempts to create key - as re-typing password is commonly perceived as "signing and accepting" whatever is there.
3. Sounds nice; although I think that adding another screen (blurred signature with menu) just increases the path for workflow while adding little; maybe we could add blurred QR to password entry screen? But then anyway, on screens with text entries nothing remains visible except for the text entry.
4. There is actually one more field - password on transaction signing. I've just added default focus there.
5. And I planned to add "just a comment" field to history screen, but I have no plans on how that would work yet.

I think somebody should just get a feel for these now.

[goldsteinsveta]

1. i. Keyboard - cool
   ii. Seedphrase input - goes to design tasks
2. I think it makes sense to just hide keyboard on "return" in "repeat password"? I think we will want to inform the person about what this password is, and friction won't hurt, at least.
   It's also almost like it's a form composed from two different forms: path + display name and password + repeat password. And you submit the mega-form, not one of them..
3. Password, do you mean ///? Or PIN? (If PIN, then I forgot it. Does the flow looks like this then? Scanner > Parced Tx > PIN > Signature?)
4. Merged with 3. :P
5. Log input - goes to design tasks

[Slesarew]

2. I was thinking about splitting it in 2 forms, but then most users apparently do not use the password; at the same time, the easiest way to add it was just to include input field to key creation form. I'm hiding "repeat password" field if the password is empty. Just hiding the keyboard on repeat password "return" is trivial, so maybe somebody should try both and tell which feels better? Or I can just do it if you are sure.
3. I'm talking about /// password. The pin is out of our control - it's the operating system's screen entirely, so that there is no way to fake it and the hardware-encrypted material is as secure as the phone itself allows. So there is no need to discuss this pin entry, only when it happens - which is now just before the secret material is needed (I would prefer to keep it that way for security).

Signing flow is Scanner > ParsedTx > (optional password if it's not empty) > PIN > Signature