EXPERIMENTS

#059 Style Trial
    Design
by Cam, 03/22/23

Preface

A few weeks ago, Pavan posted Polished Wallet UX, a wonderful experiment highlighting potential solutions to some of the core UX challenges we have been facing as we design and build Dub. This experiment expands on that work, focusing on iterations of interface design that follows the UX outlined in that previous experiment.

Realization

Styled Wallets View Full Resolution Image This week, I’m most excited to share work in-progress from our wallet component design work.

Feature Overview

A key component of the Polished Wallet UX was consolidating and simplifying the various potential wallet views. While each of your wallets can contain many things and can do many more things, we wanted to aim for as few layers and layouts as possible (we hate the idea of a modal in a modal in a modal - nobody should get lost in their wallet).

Where The Wallets Are

With Dub, each browser Space can contain many different wallets. One of the core technological unlocks of Dub is the ability to simultaneously use different wallets - so we wanted to keep the ability to have and switch between wallets in the same space, but we also wanted to make it incredibly clear what your active wallet is at all times (your active wallet is the wallet attached to the your currently selected tab).

/images/cam/59/where-the-wallets.png Your active wallet lives prominently in the top left of Dub (alongside your wallet switcher - we’re playing with merging the wallet switcher with the active wallet to simplify the interface, more there in the coming weeks).

Two Sizes (Hopefully) Fit All

Your active wallet has two potential sizes:

  1. Condensed

    The standard size for the wallet component. For the sidebar, our base ‘unit’ is 40px (for the search bar, tabs, etc.). Because your active wallet should be the highlight of your experience with Dub, even the condensed view is three base units tall (120px). This gives us a decent amount of surface area to experiment with. When your active wallet is in this standard, condensed view, your browsing experience is also standard.

  2. Expanded

    The expanded wallet component size is intended for ‘detail’ views - request details, token details, collectible details, and core actions like buying, swapping, and sending tokens. For the expanded view, we want to keep the height as minimal as possible while still allowing space for all of the information that detail / action views require. Currently this is nine base units (360px) but we’re flexible on scaling this up / down as we go deeper on designing various expanded size views. When your active wallet is in this expanded, detail view, your browsing experience becomes focused on tabs where your active wallet is connected (other tabs connected to other wallets fade out with the exception of your current tab which will always be visible, regardless of whether or not it’s connected to your active wallet).

Dynamic Islandism (but for your wallet)

Dynamic Island

Back when Apple first announced the Dynamic Island ‘feature’ for the iPhone 14 Pro line, we were instantly inspired and excited by the prospect of leveraging the Dynamic Island when building a mobile wallet app. The very nature of a wallet is dynamic, information / actions are highly contextual. The key information and action items when you are passively browsing NFTs is incredibly different than the key information and action items when you are actively signing a transaction.

While Dub isn’t a mobile app (yet) and thus we do not have a Dynamic Island to play with, we are toying with the concept of the Dynamic Wallet: a wallet component that changes fluidly depending on the context. For instance, the condensed wallet size could have a standard view that simply contains identifying information for your active wallet (icon, name, native token balance, currently connected network). More excitingly, that same condensed wallet size could morph into a request view to display real-time wallet requests (like account access / connections, personal signatures, and transaction signatures). (see below)

condensed

Similarly, the expanded wallet size could accommodate a more detailed request view with all available information. It could also host a detailed tokens view that lists all available tokens. (see below)

condensed

Simplicity and Consistency

Even with a potentially dynamic wallet area, we must always balance utility with simplicity. For instance, the base case (see ‘simple’ below) that fittingly contains just simple wallet identifying information (icon, name, balance) and basic state information (balance, network). This is a great base case (and covers all core identifying + state information, though let me know if I missed something you think might be helpful). However, I wanted to explore adding key action items (like buying, swapping, and sending tokens) so that user’s could jump directly to their desired action as opposed to first jumping into an expanded wallet overview.

simple

I don’t quite know which I prefer yet - we’ll definitely build and test both, but as we test we’ll be biased towards simplicity and consistency, trying our best to add utility without visual clutter and subsequent cognitive overwhelm.

Paging… you

pager In line with the Dynamic Wallet concept and in an attempt to explore statement styles, I explored the idea of a pager styled wallet component. Above is the most pager-y pager style I created (based off a super fun Motorola pager): moto

I’m quite fond to the pager style because pagers - while decades old - accomplish many of the same things we are aiming for through our wallet component:

pagers

While it was super fun to experiment with these strong, pager-based styles, the pros of the pager model and aesthetic can also manifest as cons. Internal feedback was that the style might be too strong and might hinder the product experience more than help it.

Thus, when building out these designs, I plan to start with the simplest base case and add style and complexity as a bonus. I’d love any feedback y’all have for unique product interfaces that you love and use daily, especially those that leverage a stronger theme.

Process

Primary Challenges

Overwhelm

Wallets are tricky as heck. At the surface, it’s literally just a key-pair. It couldn’t be much simpler. However, this key-pair is so revolutionary and powerful, there are so many layers of complexity. What makes this deep ocean even harder to navigate are the poorly defined and hardly followed ‘standards’ - I’m learning more and more there usually is a ‘best practice’ however most wallet clients either a) are ignorant of these standards or b) are aware, but choose to ignore these standards to embrace simplicity or c) adopt these standards and end up with a clunky experience. I think we don’t have to take any of those paths. I think we can have first-class support of standards while also creating a first-class user experience. The multitude of choices, each with dozens of nuances, can be quite overwhelming. We just need to prioritize these choices and craft masterful answers to them one by one.

Learnings

Sometimes less is more

As highlighted above where I lean into simplicity and consistency, I’ve found that sometimes the best addition to a product is deletion. When struggling to choose between options, the answer can be neither in which case it’s worth exploring simply removing the troubled options entirely.

Next Steps

Prototyping

These redesigned wallet widgets are critical to the next build of Dub which should follow the improved UX standards laid out in Polished Wallet UX. Thus, I will continue to iterate on the design of these wallet widgets and move from Figma to Xcode to begin prototyping and polishing the interface. Dark mode coming soon. Much coming soon. So much coming soon. Until then, cheers.