Closed cryptoBeliever closed 2 years ago
Looks good, @cryptoBeliever!
UX/UI
NEM address
should be NEM Address
. NEM opt-in transactions
and Symbol payout transactions
to 'Hash'. NEM Balance
and Symbol balance
can read 'Balance'.Total
text in the Address column, and instead add a border around the Total in the Balance column. Labelling
Hash
provides a link to the explorer. We will want to have an additional column that labels off-chain addresses (for example, Binance or Huobi) and known accounts (for example, the old NATRUST NEM account and its subsequent Symbol accounts would all be labeled NEM Group Trust).
@0x6861746366574, @gimre-xymcity commented on that- all exchanges are opt-in on-chain. That off-chain are Trust and some private devs' addresses. Do we want to label them? I think in such a case @gimre-xymcity has to add it too into DB or we can hardcode it to CSV export (since it will not change and it's only for pre-launch).
You will want an additional column for 'timestamp' - not as important for pre-launch transactions, but pretty critical for the postlaunch ones.
@0x6861746366574 Is this payment timestamp on Symbol chain or NEM opt-in chain timestamp?
@0x6861746366574, @gimre-xymcity commented on that- all exchanges are opt-in on-chain. That off-chain are Trust and some private devs' addresses. Do we want to label them? I think in such a case @gimre-xymcity has to add it too into DB or we can hardcode it to CSV export (since it will not change and it's only for pre-launch).
Yep, we'll want to label these.
@0x6861746366574 Is this payment timestamp on Symbol chain or NEM opt-in chain timestamp?
Ah, good point. You'll want to record both the request
timestamp (when the request was initiated on NEM), as well as the payout
timestamp (when funds were sent to the user on Symbol).
@0x6861746366574 What type of user wants to see the whole list? (Considering we have search and the CSV export functionalities in place)
For pagination, I'd not display tabs but instead allow for endless scrolling. Start with 1000 entries loaded, and then allow to scroll (sorted by timestamp).
@0x6861746366574 What type of user wants to see the whole list? (Considering we have search and the CSV export functionalities in place)
It's not a type of user, just a UX pattern to follow. Modern UI will have us scroll or pull down to load more results from large datasets. Think about how Twitter, TikTok, etc. all work.
Pages were very much a UX pattern in the 00's and 10's for large datasets, but have slowly been replaced by doomscrolling.
You'd typically want to load up 1000-5000 records and then when you scroll to the end of the page automatically load more (much like Twitter). This UX pattern should be consistent for our explorer, too (cc @AnthonyLaw).
For something like an NFT marketplace, pagination is more suitable: anytime you want a user to linger on an element or anytime you're looking to mimic an eCommerce store you would use pagination.
You're still showing users the same content (whether it's paginated vs infinite scroll there are still 1000 records on the first 'load' before a user has to do something to fetch more requests), the only difference is what UX pattern you're following.
For pagination, I'd not display tabs but instead allow for endless scrolling. Start with 1000 entries loaded, and then allow to scroll (sorted by timestamp).
http://post-launch-opt-in.symbolblockchain.io/completed.html is using endless scrolling. I thought it was difficult to find / track content, but pagination should work better when we looking for specific content.
You'd typically want to load up 1000-5000 records and then when you scroll to the end of the page automatically load more (much like Twitter). This UX pattern should be consistent for our explorer, too (cc @AnthonyLaw).
do you like upgrade Symbol Explorer to change to infinite scrolling as well?
Found issues (http://ec2-35-171-24-22.compute-1.amazonaws.com:5001/):
All done.
The opt-in reporting tool should present all completed (paid requests from pre-launch and post-launch) opt-ins.
I. The list of completed opt-ins should contain the following columns:
a) "Type" - "PRE" - for pre-launch, "POST" - for post-launch b) "Label" - additional info about NEM address "label" e.g. "Binance" c) "NEM Address" - in a single row can be multiple addresses for opt-in type 'merge' and 'multi'. Address should link to explorer https://explorer.nemtool.com. There should be an option to easy copy address. d) "Hash": NEM transaction hashes
On top of the screen should be an option to:
Pagination: 200 elements per page. Infinite scroll. Order: We should order descending by opt-in id
Wireframe:![Completed_list_view](https://user-images.githubusercontent.com/17684281/163791720-a20668e8-9eb1-449a-bd74-2d6e578335f5.png)
CSV columns: a) # - opt-in number e.g. "1" b) "Type" - Post-launch or Pre-launch c) "Label" - e.g. "Binance" d) "NEM Address" e.g. "NATRUSTUAB5LAWDSOWDUPQUFYRTGZTJZDGML2JKP" e) "Height" - NEM transaction height - if we have multiple opt-in tx for NEM address (multisig) we should export latests. f) "Hash" "18b358c9fb99469614e6b5f3114e911c0ec14e656126db55209daed59a9451a2" - if multiple then comma separated g) "Timestamp" e.g. "2010-12-11 12:02:53" - if we have multiple opt-in tx for NEM address (multisig) we should export latests. Timestamp in user local time. h) "Timestamp UTC" e.g. "2010-12-11 14:02:53" - UTC timestamp for NEM transaction i) "Balance" e.g. "99584654.050913" j) "Symbol Address" e.g. "NCIG65BEOUJPH2AP7ELHOPYIH7FANQEH5CCOBEI" k) "Height" - Symbol payout transaction height l) "Hash" Symbol hash e.g. "e24ed6ae1591353e2515940b18d1b0f5eb233f4544d2630d8fdd6a1923235a8b" m) "Timestamp" e.g. "2010-12-11 12:02:53" - timestamp for Symbol transaction. Timestamp in user local time. n) "Timestamp UTC" - UTC timestamp for Symbol transaction o) "Balance" - Symbol tx balance e.g. "9584654.150913"
Example CSV: optin-completed.csv
Completed DB: completed.zip