Replies: 3 comments
-
Nice considerations! I just think we could stick for KISS principle first and then do experiment things! (We don't need to rework all the UI at first, but some screens and see how it goes). For example the "Settings where you define default" I think it is a lot of changes at once. First I would change the UI and test and share to others! Then if it is all ok, think about it, it is really necessary to add defaults? Maybe the better UI reduced the steps to a few and customization's/defaults may be no longer necessary. Also nice idea about infoboxes (telling which menu/page the user is), but I don't like titles (Wallet: / Native Segwit / Singlesig / No Passphrase), we could use icons (or create our ones like we did with the battery). See for example the green "test" on top when you are on testnet (we don't need to write "Network: testnet", it is too much for the UI and less is usually better) |
Beta Was this translation helpful? Give feedback.
-
I like these ideas, especially if incrementally evolving new ui elements so that feedback can be had from users of different devices, with the expectation that it will be some time before the ui-apis will become stable. It certainly seems useful to have info and menu choices on the same screen, maybe even more elements eventually. Disclaimer: I've never considered myself as having expertise in ui, because I'm biased toward more power/control for the user. It might be useful to have some expert ui opinions on what to prioritize so that we're all following the same rules or so that we know that there exists a 'best practices / ui conventions' to look for when we're not sure which direction to go: ie:
As for long sequences of steps, as Odudex mentions, I'd like the series of steps to be fewer and I can see a previous submenu reducing that, but I don't always know where it's best to draw the line. I only have an Amigo at this time for testing, so I'll have expectations that aren't realistic/possible on the m5stickv. I think it would be a big mistake to break the codebase into many different ui's that would have to be maintained at this point in time; the ui changes that work cleanly on all devices are the obvious wins and the ones that are difficult to maintain or feel like kludges are the changes to avoid... at least in my opinion (because Im biased toward power-user control over optimized ui on a particular device). As for "a fingerprint glyph", are you thinking of a single symbol/icon which hints that the hex characters which follow are a bip32 wallet fingerprint? or are you thinking some fingerprint algo that colorizes the hex or creates an image which can be identified with a particular fingerprint? If it's the latter, I'm a big fan of training users to pay special attention to the fingerprint hex value because it's such a useful checksum and is commonly available in other devices/wallets... I wouldn't want to train them to look for a colored algo/image that will always be the same on krux but won't help them identify the wallet elsewhere. |
Beta Was this translation helpful? Give feedback.
-
I think we're aligned in the goals and what we think are the best practices. Subtleties will show up and will need to be refined along the way. But we can do this gradually, as you suggested. |
Beta Was this translation helpful? Give feedback.
-
Based on users demands, I've been brainstorming some UI enhancements ideas and would like to share so you already can participate on this.
The "problems" I see:
Those characteristics are OK for devices like M5stickV, but with Amigo, and even Dock we have possibilities to improve, so I think we could optimize UI for Amigo, of course, keeping the best possible compatibility with others.
What could be done? I have some propositions for new UI elements:
These elements could be used for things like this, that would replace the loading sequence.
For the example above, other settings should be added:
Users could define the defaults and use them to quickly load a wallet, or when eventually loading different setups could "customize" these parameters via secondary menu on the go.
Export options could be added in standard menus, instead of sequences.
And load options could be smart: If SD is present, create a menu with "scan" and "load from SD options", if there's no SD, directly runs scanner.
Beta Was this translation helpful? Give feedback.
All reactions