What we’ve learned

A “deep” tree of nested screens is definitely not the way to go. Some features of Scatter version 10 were three or four screens deep and users simply weren’t finding them. Because of this we developed a more “flat” user interface which exposed more of the settings directly to the end-user. Unfortunately we defaulted to a collapsed sidebar by default and users had a hard time finding things like “Networks”. Version 11.0.1 was in the wild a long time and many users complained (legitimately!) about things like

- how to manage app permissions

- how to exchange tokens.

- users not understanding how to update keys for their accounts. In version 12 we strove to continue our streamlining approach.

- It is now fully responsive (because mobile!)

- The menu is open by default, and it is more obvious how to collapse it.

- In wallets, accounts are more clearly grouped under their keys

- The app explorer is cleaner and it is now clear which are promoted apps and which are not

- and of course most of the real work went into making Scatter Embed, our secure update mechanism. You can read more about that in another article we’ll be releasing soon.

We think that on the whole it has gotten easier than ever to use Scatter, and easier for us to maintain. That being said, there is still a ton of technical functionality that caters to “advanced” users with dozens of keys and potentially hundreds of accounts across multiple blockchains.

The key takeaway here is that at some point we have to ask ourselves who our target audience is. Is it for advanced, technical users or is it for more mainstream users who just want to play a game, gamble securely, or edit a page on Everipedia? We think you know what the answer to that is.

You have to hide complexity

Part of what I like about working at Scatter is the open nature of the design discussion. Since it is an open-source project and developed for a very specific community I have the opportunity to directly engage with the community and get feedback on what works for them and what (sometimes really) doesn’t.

For the most part our users are on EOSIO blockchains, with some small amount of Bitcoin, Ethereum, and Tron users sprinkled in there. EOSIO itself is really cool technology that is just now getting its feet under it. There are some stability and governance issues that need working out, but it is very cool to watch decentralized networks with hundreds of smart contracts on them doing almost 45 million operations a day. There are hundreds of thousands of people around the world using this stuff and it feels like touching the future when you log on to the new, advanced networks with your shiny, new account. Like the internet in the early 90s, it is small, colloquial, and generally unknown to the wider world. It is also not well connected, as in each of the networks is largely silo-ed off on its own. Inter-blockchain network communication is still a ways off, but making good progress.

However, EOSIO is kind of an odd-duck blockchain technology when it comes to user-experience, and that makes for a headache when designing software for accessing it.

It has an accounts system that is permissioned, and feels more akin to an account system on Unix than something like Ethereum where you just have a keypair that uses a formatted public key as the address. EOS accounts are easier to interface with as a user as you don’t have to type in long strings of alphanumerics to do transfers, but managing them is more complicated and prone to user-error.

You generally have an account permissioned like this:

But in principle you could have something like this, too:

Where each set of key pairs has functionality that it has access to through your account. It’s wonderfully flexible, but I’m never going to be able to expose this kind of tech to “regular” people because they just don’t care and don’t need it.

This is us creating UX for doing uncommon tasks, and I think that for mainstream acceptance, we need to change how we look at blockchain technologies like EOSIO.

We think of everything we have been building so far as “for developers, by developers”.

It is time to make a cognitive switch and build for mass appeal.

Scatter Simple basically provides the user an EOS account without any of the complexity exposed. No account permissions, no confusing keys, no resource management, etc. Just the basics. Just go play your game.

To get there we had to walk a certain path that taught us what works and what doesn’t.

What we are encountering as we go through the process of building out these technologies is that we still don’t know what the right way to do things really is because, frankly, nobody has every tried to do it before.

Experience is defining the design of the future.

An example of our process

We’d like to keep Scatter Simple as easy to use as we can, while not painting ourselves and the end-user into a corner when it comes to functionality.

One of the places this has hit us is in the case of an “advanced user” who wants to use Simple mode in Scatter 12. Scatter Simple’s UX and UI is based around the concept of “just one account” to remove a lot of the UX complexity. But what happens if the user actually has multiple keys and accounts that they want to switch through easily?

We have to support advanced functionality, but make it as easy to use as possible.

Currently in Scatter 12 you see this in your “Wallet”:

It’s complex, but it tries to be organized and allow the user to understand the concept of accounts being tied to keys without being too complex.

Scatter Simple has a simpler approach

People still find this really hard to understand so in Scatter Simple we are going a step further and making this interface more intuitive.