Design customizable UI for snaps "L2 Asset" use case

[danfinlay]

The snaps system can be big and daunting, but breaking it into smaller deliverables can help us reason about it. In this issue, I will list just the design tasks required to enable a basic layer-2 asset like Starkware, Counterfactual, Unipig, or Aztec protocol. These designs may also be sufficient for supporting some other blockchains!

This will probably be our first target for a snaps UI API, and so this should be the top priority target for plugin-related design.

For a more detailed technical exploration, please refer to MetaMask/metamask-snaps-beta#105

The specific design tasks are these:

• Plugin installation confirmation Design for Snap Installation Confirmation #176
• Custom asset list Design/finalize custom asset API metamask-snaps-beta#111
• Custom confirmations Allow Plugins to display custom confirmations metamask-snaps-beta#52
• Custom asset view Selecting a custom asset should allow displaying a custom asset view metamask-snaps-beta#103
• Plugin preferences page add settings page metamask-snaps-beta#50

These 3 design targets cover many use cases:

• Layer 2 scaling
• Other blockchains
• Other token standards
• New Collectible types
• Subscriptions
• Allowances
• More!

[rekmarks]

For all of these different views/pages, I want to emphasize that we should include "Display the associated network/protocol" as a feature/requirement. I believe all of these assume—correct me if I'm wrong—that we've removed the notion of a globally selected network. However, every instance of these usecases will be associated with a particular L1/L2 network and protocol, and the user should never be confused about which.

If we do that, I think the UI would basically be ready for other blockchains!

[danfinlay]

I want to emphasize that we should include "Display the associated network/protocol" as a feature/requirement.

If we allow custom views on selection, what would distinguish what you proposed from that?

I like that choice because it allows the asset to determine what is relevant when considering it, but is not coupled to any assumptions like "this asset is related to an associated network or protocol, which has some kind of home page that one could view".

But I may be missing some opportunity you're suggesting. Maybe you mean an easy way to open the settings page for a plugin from its assets?

[omnat]

https://workflowy.com/s/toms-requirements/a1DVM1HaixDcJgdp#/0547198e0995
^ Design requirements from Tom

Figma with first explorations: https://www.figma.com/file/R2miYY21nfaIOx4sdMyCjw/Quick-explorations?node-id=1%3A2

[omnat]

Let me know if you got questions on this @rachelcope @cjeria
@omnat to loop in RC, CJ with Tom on email

[omnat]

• Design for use-cases and test with different L2 protocols to make a universal / generalizable design that'd allow good integration (good UX) irrespective of the protocol/L2 plugin.