Random Generator UX improvement suggestions.

[WinkelCode]

1. Don't close Random Generator after hitting the copy button

It's often necessary to see if a generated password conforms to password complexity requirements, so I need to paste the password without committing to it. I find that the current behavior is unintuitive, in fact, I believe I locked myself out of an account (nothing serious, had to reset via email) after changing the password, because I didn't realize that it actually hadn't updated the password field for the entry, which I had naturally assumed since it exited the generator window.

2. Button labels

For clarity, I believe the "Done" button should become "Apply".

3. Button location

Having the copy and regenerate button next to the password, instead of at the bottom of the page, would in my opinion make their purpose clearer.

4. Buttons at the bottom of the window

I think having "Cancel" (maybe in red), "Copy and Apply", and "Apply" buttons would make the use of the Random Generator UI more intuitive.

[keepassium]

Great points, thank you!

[keepassium]

After some thinking, I'm about to settle down on this:

• The Copy button moved next to the text, as suggested. That area becomes a little too busy for my liking and the button is harder to reach, but its placement is consistent with the rest of the app. Won't close the generator.
• The Regenerate button remained at the center of the bottom toolbar. This is consistent with the rest of the app, and is easy to reach (the button is likely to be used often). Moving it near the password would make the top of the dialog even more crowded and make the button harder to reach.
• The Done button became "Accept", right next to Regenerate, so the user won't have to travel far. Might be problematic for accidental palm touches on large phones, though…
  • I have contemplated "Apply", but that verb refers both to the generated password and a field in the previous screen. A screen which is currently hidden. So the user would have to think and trace back where they are applying the password to. Instead, "Accept" refers to the generated password only.
  • The top-right button is removed to avoid confusion (top-right Done is normally expected to close the current modal, which it does not do).

(The screenshot is a generator for an entry field. In standalone mode, the "Accept" button is gone, and there is a "Close" in top-right corner.)

Would this work for you?

[WinkelCode]

@keepassium Looks good to me 👍

Although, I believe there are at least two "copy" types in KeePassium:

• Entry fields: Tap anywhere, blue overlay w/ text, additional buttons for field reference, share, character "inspection" (idk what it's properly called).
• Ad-hoc Random Generator: Copy icon to the right, tap anywhere to copy, "Copied" bubble above.

What will the entry-specific random generator's copy UI be? Regarding your "busy area" concern, if the UI uniformly had the ability to copy field contents by tapping on them (with the blue overlay), I think the copy icons could be omitted entirely.

Edit: Will "Accept" close the Random Generator modal (Correction: Will "Accept" go back to the entry editor)? Or will I have to accept, then go back (top left)?

Edit 2: Also, if the app used the tap-anywhere-confirm-with-blue-overlay (like for entry fields) interaction type, maybe another button could be added to copy that text indefinitely?

Edit 3: That previous suggestion was more general, not specific to the random generator. It would be useful when faced with certain complex UIs on the corresponding website/service.

[keepassium]

What will the entry-specific random generator's copy UI be?

Exactly as shown in the screenshot, aka the second type you described.

Regarding your "busy area" concern, if the UI uniformly had the ability to copy field contents by tapping on them (with the blue overlay), I think the copy icons could be omitted entirely.

I wish it was :) In the entry viewer, tap-to-copy is easy to discover accidentally (even if only to see what a tap does). In Random Generator, very few people will reach to the top of the screen to try tapping something that looks very static. So a dedicated Copy button is necessary. This is even if tap-to-copy worked across the app (which would be too much trouble for little benefit: who needs quick copy from "What's new" or About/Credits?).

Fun fact: swipe-to-delete is a common system gesture and works pretty much everywhere in the app. One can swipe out files, groups, entries, custom fields. Yet in the entry editor there is a small red "trash can" button for custom fields. It did not exist at first. But many people don't know the swipe gesture, plus custom fields just don't look swipe-able…

Also, if the app used the tap-anywhere-confirm-with-blue-overlay (like for entry fields) interaction type, maybe another button could be added to copy that text indefinitely?

This is possible. But I'd like to change the interaction style there first: white icons on a blue outline look too cryptic and disappear too quickly. It needs some kind of "menu" to show text, more than 3 actions, and remaining on the screen long enough. This is already somewhere in the nice-to-have list :)

[keepassium]

After testing on device, I had to move the "Accept" button to the top. It kinda made sense at the bottom when tested in simulator with a mouse, but on device the lack of top-right confirmation button felt quite wrong.

So now it looks like this:

This is when generating a password for some field (so there is "Accept" button). In standalone mode, the "Accept" button becomes just "Close" icon: