You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
If the user types in 0xHelloWorld or 0x1234 or even 0xabc456789012345678901234567890123456789Z, this should not generate an identityicon but show clearly that this is not a valid address.
I propose the following:
valid address w/ checksum => identityicon
valid address w/o checksum => identityicon
invalid address => big red X
I am not sure yet what would be the best option to provide user feedback about checksums but I think it would be nice to have a way to display it without much clutter.
We have the following cases:
no checksum 0xabbb6bebfa05aa13e908eaa492bd7a8343760477
check OK 0xaBbb6bEbFA05aA13e908EaA492Bd7a8343760477
checksum NOK 0xaBBB6bEbFA05aA13e908EaA492Bd7a8343760477
For those 3 cases, I would display the identityicon in any case but add a little symbol in a corner or a coloured border around it.
Feedback wanted (but not about my drawing skills 😄 obviously some CSS will do a better job )! Note that I did not regenerate the identityicon to match the following, in a real case, the icons below would differ.
I kinda prefer the outline option best, it can also be disabled very quickly from the CSS by setting the border width to 0...
The drawback I can think of regarding the 'color only' solution is for color blind people who may not distinguish some of the state. For the 'no checksum' case, we could use a dashed line. To differentiate between OK and NOT OK, we may need an extra visual clue.
The text was updated successfully, but these errors were encountered:
I kinda prefer the outline option best, it can also be disabled very quickly from the CSS by setting the border width to 0...
The drawback I can think of regarding the 'color only' solution is for color blind people who may not distinguish some of the state. For the 'no checksum' case, we could use a dashed line. To differentiate between OK and NOT OK, we may need an extra visual clue.
Prefer the icon option, as the outline option seems to colourful. 😄
We currently don't have the fine-grained capabilities to determine for the 3 cases of failures - it is all-or-nothing. (There is an issue logged to address this at the API level, which includes the actual errors as displayed on the UI, https://github.com/ethcore/parity/issues/2152).
jacogr
changed the title
UI: Address input component should not generate identityicon unless the address is valid
Address input component should not generate identityicon unless the address is valid
Nov 2, 2016
Discussed (partlyx) with @derhuerst
If the user types in
0xHelloWorld
or0x1234
or even0xabc456789012345678901234567890123456789Z
, this should not generate an identityicon but show clearly that this is not a valid address.I propose the following:
I am not sure yet what would be the best option to provide user feedback about checksums but I think it would be nice to have a way to display it without much clutter.
We have the following cases:
0xabbb6bebfa05aa13e908eaa492bd7a8343760477
0xaBbb6bEbFA05aA13e908EaA492Bd7a8343760477
0xaBBB6bEbFA05aA13e908EaA492Bd7a8343760477
For those 3 cases, I would display the identityicon in any case but add a little symbol in a corner or a coloured border around it.
Feedback wanted (but not about my drawing skills 😄 obviously some CSS will do a better job )! Note that I did not regenerate the identityicon to match the following, in a real case, the icons below would differ.
I kinda prefer the outline option best, it can also be disabled very quickly from the CSS by setting the border width to 0...
The drawback I can think of regarding the 'color only' solution is for color blind people who may not distinguish some of the state. For the 'no checksum' case, we could use a dashed line. To differentiate between OK and NOT OK, we may need an extra visual clue.
The text was updated successfully, but these errors were encountered: