Even though NNS-dapp got quite a boost - performance wise - when we completed its rewrite in Svelte, the least we can say is that the “Voting” experience remained a bit a slow process.
Context
As discussed on the forum (here or here), this was the result of a conservative UX approach to a technical limitation.
Because neurons are the source to determine the voting power, NNS-dapp has to reload their information in a secure way after each vote to determine their new power. While most of the time the dapp can perform first “query” (fast) calls and reconcile afterwards in the background “update” (slower) calls - to offer both a secure and smooth experience . this strategy is unfortunately not possible for this particular use case. Neurons have to be reloaded after vote with “update” calls (only) because “query” calls could not contain the updated information the dapp would need to prepare the next vote.
UX proposal
While we cannot overcome this technical constrain - at least on a short term - it does not mean that we cannot be creative on the UI/UX side.
That is why we would like to propose a new re-design of the “Voting” experience in NNS-dapp which would introduce a more optimistic approach and hopefully better user experience.
Instead of waiting for the completion of the votes, the dapp will optimistically display the votes as casted while processing the operations in parallel - i.e. effectively casting votes and reloading proposal and neurons. This will have for effect to shorten the act of voting, allowing the user to navigate elsewhere - e.g. to navigate to the next proposal.
While the logic remains the same, the fact that user would be able to do something else than waiting for vote completion shall give not just the feeling that the all process is faster but, also effectively shorten the time spent voting - particularly if user vote for many proposals one after the other.
Long story short
I did my best to try to describe our proposition but, nothing like a demo. That’s why we invite you to test this new feature on testnet
https://tzq7c-xqaaa-aaaaa-aaamq-cai.nnsdapp.dfinity.network
(do not use your regular anchor to sign-in, instead use anchor 10001, 1004 or create new test one)
Let us know what you think, looking forward to your feedback!
P.S.: this, in my personal opinion, super improvements (PR #1230) has been implemented by my colleague @mstrasinskis