Design specs for the desktop top bar component

[GBKS]

In yesterday's call, we reviewed the current draft of the updated nav structure for when we have all the wallet features. An important element of this is the top bar on the desktop. Let's spec out all the different states in detail.

From the current design draft:

Older designs which show a lot of different states, but have a dedicated wallet page which we don't want anymore.

Jarol had also asked us to mock-up the hover, selected, disabled, focus and any other states needed. Those should be pretty straightforward now since we have our standard treatments defined.

[stackingsaunter]

Let me work on this one

[stackingsaunter]

Here's what I've done so far - Figma file

I think I covered them all, next steps would be to do wallet selector and it's states.
Not sure if wallet selector "active" should be white or orange.

I added "Yellow" (light/dark) color to use for node indicator.

I also used layout for the component and it's responsive (although for condesed state I had to change autolayout settings).

[yashrajd]

Regarding nav item states discussed today – below are screenshots from v1.0:

• back button: icon, label are white in active state
• (see cursor) Hovering changes label to Orange from white

Also currently, Hover state for the Back button puts it in a grey box (see below). We could also try something like that here.

[stackingsaunter]

Did some updates.

Two layouts of wallet selector/balance and 2 types of color states. But I just realised the one with grey box @yashrajd proposed can be also nice, I can try this one as well.

You can try the prototype here

I also added "pressed" state. Another idea for hover could perhaps be similar but darker

[stackingsaunter]

Haven't spend much time on mobile, but sketched out some initial ideas

[yashrajd]

Prototype's cool & very helpful @stackingsaunter.

I'm conflicted about Hover state: grey box will maintain consistency with existing behaviour (like Back button already implemented) but orange is fine too.

I'm agnostic about a Pressed state, but if implemented I prefer it as implemented in the prototype (orange + grey box, which makes sense since you need to hover before pressing) instead of the white in grey box as in your image above.

So here's my view (for dark mode) so far:

• inactive: white

• hover: grey box

• pressed: orange + grey box (orange signifies it will become active when action is completed)

• active: Orange with underline (as Christoph proposed)

• disabled: grey/dark grey

---

For wallet selector/balance, I prefer white labels instead of grey. Unsure about icon since it means we have to provide options + extra UI to choose but perhaps we could do it in the future. Emoji set might be an easy way to go.

[GBKS]

Thank you for all the work on this, makes it super easy to compare options. I prefer the more subtle one with light grey text. It uses our color palette in a nicer way, IMHO. Having a very light transition duration of 100-150ms will also make it just a little bit nicer.

For toggling between balance display, we could also rely on the shift key. So shift-click to switch between full bitcoin (0.01 000 000), trimmed bitcoin (0.01), sats (10,000,000), and maybe even hidden balance. That would be in addition to having a toggle elsewhere, like the application menu bar and settings.

I looked into the wallet icon a bit more. It would be cool if those could represent different types, so here are some ideas.

If we have a good hover state, maybe we don't need the small arrow to indicate the switcher?

[GBKS]

For mobile, I'd keep send and receive as tabs since those are primary options (compared to block clock and settings) and tabs are easy to reach on mobile. It also solves the privacy issue of exposing your balance when you want to just do a quick send/receive.

[GBKS]

Brief note to also design a state for then the application is built without wallet features. The simplest approach is to remove the wallet icon/balance on the left and the tabs in the center, and only keep the block clock and settings buttons on the right.

[stackingsaunter]

Components are ready to review - Figma file

Current mobile design oscillates around those 4 ideas. More work to be done here

[stackingsaunter]

@GBKS did you end up deciding on mobile direction while I was gone?

[GBKS]

Here's the latest (if I remember correctly.

It might be nice to put together a web prototype for some of this stuff, so we can quickly feel it out and iterate.

[stackingsaunter]

After some thought, I propose this screen as main mobile nav:

My reasoning:

• "Settings" on desktop is not equal item to Activity, Send and Receive, so I think it's more consistent if it's not on mobile as well
• (Assumption) In most cases, especially on mobile, users will not visit "Settings" often so it does not need to be as handy in the bottom nav as other options
• As for wallet list dropdown, I chose this as it's exactly the same as on desktop, so to keep things simple and consistent

Alternitavely, wallet selector could be wider for easier selection

[stackingsaunter]

I think this can be closed, as we agreed on the layout and you @GBKS updated the main file already. This is the mobile design we ended up with:

[GBKS]

Looks like I need to update a few minor things on the design docs still.

Also spoke with @johnny9 yesterday about the wallet list. He's going to look into what information we have about closed wallets. Might be easiest for now to just design three options where we just have the name, name + type, and name + type + balance, and then use whichever one we can make work technically.

[johnny9]

Also spoke with @johnny9 yesterday about the wallet list. He's going to look into what information we have about closed wallets.

It looks like you only know the name of the wallet folder if the wallet is closed. When the wallet is open you know all of the other values. From my understanding, I think the UX can be modified for the new UI and attempt to load the wallets for these values unless they were previously closed. If they are closed, persist that in the settings. Regardless, we do need to have a clear "closed" state for the wallet selector.