Design Views for Multiple Keychains

Nobody has claimed this yet.

This is a design-centric version of #328

We are planning to refactor a core piece of MetaMask, allowing it to support multiple key signing types, and this has some pretty big UX implications, so we want designer input to keep it as simple and user-friendly as possible.

Right now MetaMask is entirely based around the idea of these "HD-Wallets", where a 12-word seed phrase is where all the accounts come from.


This makes the account list fairly simple, since we have a list of accounts, and you can only add them, and they are always added in the same order, like this:


In the future, there are other types of account we want to support:
- Import Geth account .json files
- Simple key pairs (maybe allowing vanity account generation, like 0xbad0dab0...)
- [uPort](https://uport.me/#home) accounts
- Hardware wallets, like [Trezor](https://bitcointrezor.com/) or [Ledger](https://www.ledgerwallet.com/)

We had an idea for what this might look like in the account list, where vault types might include sections, like this:


However, we are open to other solutions.
## Key Terms

Before resuming, here are some terms we should clarify. We haven't really picked solid words, so feel free to propose the words we use as part of the design.
### Keychain

A way of grouping accounts together. A keychain can be a simple set of key pairs, or an HD wallet series of wallets, or a uPort identity.

Right now, MetaMask only has one Keychain, a seed word keychain, but the purpose of this design is to allow multiple keychains.
### Vault

The encrypted storage of MetaMask.

In the past, the Keychain has been the same thing as the vault.

Going forwards, we're thinking we'll encrypt all the keychains together, so they are all unlocked at once, so a user doesn't have to manage multiple passwords for different keychains, but that is a design decision, and up for discussion.
### Wallet / Account / Key Pair

These terms are basically interchangable. They represent a single Ethereum identity.

This can be a simple key-pair, or an identity contract, but to MetaMask, it represents a discrete, selectable identity that is injected into a web dapp as **a public address**.

Long term, one of these might be a uPort persona, so a uPort Keychain manages many uPort persona accounts, but that's beyond our current scope.
## Our current thinking

There are several views that might be affected, so let's step through them one by one.
### First Time Screen


Now that we are supporting several wallet types, we are now discussing what the optimal first-time user flow would be like. Since we are no longer constricted to just one wallet, should we make a certain type of wallet the 'default' wallet type for first-time users, or give them the option up-front to decide on their first wallet type?

Another option is to have a single Keychain be the default, but include a small `Advanced` option, that opens up Keychain selection.
### Vault Creation Screen


This screen may become mandatory on first-time use, because the password is used to encrypt all the Keychains. Otherwise, it may remain identical.
### Keychain Creation Screen

Since we would not be offering many keychain types, we might not want to automatically show a seed phrase after the password screen.


The options we have come up with so far (not exhaustive) are:
- Defaulting to a specific wallet for first-time users
- Giving users a dropdown list of supported keychain choices
- A hybrid, where users have an advanced option to select a specific keychain, but otherwise will use a default keychain.

Once this keychain has been selected, there are other requirements in mind:
- Redirect users to a new view after keychain selection. This can either be through a new tab, window, or within the popup (or some other method).
- Creating accounts in a new tab has the advantage that it is much easier for different keychains to render custom wallet creation views.
- If creating accounts in a new tab, we still should indicate that MetaMask received the new account. Maybe via a notification.
### Keychain Restore Screen


With multiple Keychains in mind, we have to consider what the account restoration should look like. Instead of requesting the seed phrase right away, users will be required to select a wallet type to restore.

Keychains may require different information to restore.
### Account List Screen

As we discussed above, this screen is going to have to be different if there are different account types within MetaMask.


It is worth noting that a single account type, like an HD seed-phrase wallet, may have many accounts under it. For this reason we are calling these account-types "Keychains", because they can have many keys.

This is why I initially suggested having sectioned Keychains, but I understand the `+` signs also become a little confusing then.


We had one thought that maybe instead of a `+` on the Keychain header, we have a settings gear icon, which would take the user to a custom view for that Keychain, maybe in a new tab.

This would make some sense since each keychain may have its own way of generating and managing keys, and a simple web view is the most flexible interface we could offer a Keychain developer.

You would not have to design the view for every type of keychain, but it would be nice to design basic views for HD wallets (the current type), and normal keypairs with geth wallet importing. I think the uPort team will want to design their own views.

This view may be split up into multiple views, but the goals for replacing it would be:
- Allow adding new Keychains
- Allow Keychains to dictate if/how to add new accounts with them.
- Allow keychains to define custome interfaces for account creation.
## Conclusion

None of our suggested designs are hard requirements, they're just our ideas so far on the issue. Feel free to borrow or discard whatever ideas you'd like, to make the best UX possible.

Our goal is to simply give MetaMask a way forward for the many types of accounts users may choose to use in the future, making it easier for a user to choose their account type, and making it easier for us to add new types in the future.

Start by reviewing the related #328 issue and the proposed First Time, Vault Creation, Keychain Creation, Restore, and Account List screens. Define designs for choosing, creating, restoring, and managing multiple keychains, including terminology and account-creation navigation. Done means a coherent UX proposal that supports future keychain types while keeping the flows understandable.

Written by the indexing model from the issue text.