This page contains an ongoing list of notes for potential improvements in the PIVX Qt Wallet:
MAJOR. If a user has the wallet unlocked for staking, and makes a spend, the wallet is then fully unlocked with no warning to the user. Speaking with someone, I learned that there is actually an indication of this, in a visual change of state of the lock icon. But that icon is tiny, and a change is easy to miss. Also, the unlock state of the lock isn’t standard. The standard unlock state of a lock icon, the top is rotated 180 degrees, but here it’s “detached” from the base. I think the app should definitely prompt the user that they’ve completely unlocked the wallet, and then perhaps with that icon, they could use color to additionally differentiate state, as is done with the staking icon (green when staking). Maybe the lock could be green when safe, and red when unlocked.
It would be good to have a first-launch walkthrough, introducing concepts and options that may later cause confusion. For example, introducing the idea that the wallet can auto-mint zPIV, giving the user the possibility initially set those parameters, and point them to help if needed. This would alleviate the common report of “I launched the app, and later discovered 10% of my PIV have changed into something else!”
If the user’s wallet is unencrypted, it may be good to persistently highlight that in the UI.
When backing up the wallet, pre-fill the save modal with “wallet.dat”, rather than just leaving it blank. Most users won’t know what to call it, leading to potential friction when later needing to restore.
Change use of the label “Zerocoin” in the UI to “zPIV” where possible. “zPIV Actions” should lead to less confusion than “Zerocoin Actions” (since all our comms are around “zPIV”) and reduce the number of terms a user has to understand, by one.
To avoid confusion around orphans, it might be good to only show zPIV staking rewards after a certain number of confirmations, so the frequency with which users experience this friction is greatly reduced.
It would be better to move zPIV spending from the Privacy tab to within the Send tab, so that the fundamental action of spending happens in one place in the UI hierarchy, and eliminates the possibility that the user isn’t aware they have a choice. (zPIV management could still take place within Privacy.)
On the Send screen, change “Remove this entry” to “Clear”, and maybe use an “X” icon (which people have commonly understood to mean clear). A potential confusion of “Remove this entry” is that you may be deleting it permanently from the address book.
On the Send screen, “Paste from clipboard” should only be available if the clipboard actually contains an PIVX address. And even better, if the button is removed completely, and when switching into the Send tab (or into the application if Send is active) prompts the user “Would you like to use the address we detected on your clipboard?”
Reporting the transaction fee in “PIV/kb” won’t be useful to the majority of users, as nobody has ad idea of the data size of a transaction. (And no normal user should have to know that.) If it’s possible, just showing the transaction fee in PIV may be more useful.
Spending zPIV. How much of a real downside would it be to remove the Security control, and replace it with a checkbox like, “[x] Extra secure (takes longer)”. Nobody needs 1 to 100 granularity on this control, and leads to paradox of choice type issues.
Receive screen. A button labeled “Request payment” can create the concern that something unwanted might happen. (Is this going to send an email or something?) Maybe change to “Create New Receive Address”.
Transaction screen. If you see a transaction type “zPIV Stake” in the list, under a header column filter control, your expectation is that within that control, you’re going to find an item labeled, “zPIV Stake”. It’s jarring not to find that. In all the communications, we currently refer to “Staking Rewards”, so perhaps change “Minted” to “Staking Rewards”.
If a user sends zPIV to themselves, prompt them with the option to disable auto mint (since presumably they need the PIV they are creating.)