New buttons result in crowded navigation bar.

[pixelzoom]

PhET has recently added 3 buttons to the navigation bar. And based on recently decisions about which features will now be "standard", and what features will be included in https://github.com/orgs/phetsims/projects/44, all 3 of those buttons will now be visible. Consequently, the navigation bar ihas gotten very crowded.

The worst case is (probably?) Equality Explorer, which has 5 screens:

Even a 3-screen sim like Fourier feels crowded to my eye:

Has PhET considered whether this navigation bar layout is generally acceptable? Could/should any of these features be moved to the PhET menu?

High priorty, since it's my understanding that this layout is soon to be published.

FYI @jessegreenberg @jbphet @zepumph @jonathanolson @amanda-phet @arouinfar @kathy-phet.

[pixelzoom]

By the way... If I run with ?locales=*, it adds a 4th button (globe) for testing layout of dynamic locale. In the case of Equality Explorer, that looks like trouble.

[pixelzoom]

Things are even worse in PhET-iO brand, because the logo (for the PhET menu button) is considerably wider. I'm not sure if that will cause overlap in Equality Explorer -- and I can't test, because it's not a PhET-iO sim yet. But Fourier looks considerably more cramped:

[pixelzoom]

Here's what the PhET-iO version of Equality Explorer will look like:

And with locales=* for testing dynamic locale:

[arouinfar]

@pixelzoom I don't have time to fully respond to this issue right now (will come back later today), but just so you know the globe icon that appears with locales=* is a temporary measure and will never be part of production. It was introduced as a short-term measure until we added Localization controls to the Preferences dialog.

[pixelzoom]

Yes thanks, I realize that the globe button is temporary -- or even if it's permanent, it's for debugging, and not user facing. But even without the globe button, usability of the navigation bar for Equality Explorer seems compromised. So I don't think that the current plan/layout is scalable.

[zepumph]

FYI: Globe was removed in https://github.com/phetsims/joist/commit/7ff277e39051e24ba7902c8a9d0c8623bdffdd16

[arouinfar]

I worked on the mockups for the Preferences button and dialog, but I don't consider myself the lead/responsible designer for this feature set. It was really a collaboration between many parties including @jessegreenberg @samreid @emily-phet @terracoda @amanda-phet @kathy-phet. (Apologies to anyone else I may have forgotten.)

First and foremost, these buttons are in the navbar for discoverability and convenience. Users rarely, if ever, explore the PhET menu. The presence of the navbar buttons is also a quick way of indicating the support of at least some of the inclusive features. At a glance, it's clear that a sim supports alternative input. While these features are now becoming standard, it will be a very long time before all PhET sims support sound/alt input.

During the design process, the team recognized that we were reaching the maximum capacity of the navbar, and made sure to mock things up using the worst-case scenario. In this case, it was Equality Explorer with stringTest=long. Here's one set of mockups:

I agree that the navbar can become a bit crowded looking, but it is still functional. I think the ease of access to the features in the button group is more important than a more minimal (and perhaps aesthetically pleasing) navbar.

[arouinfar]

Notes from the 8/25/22 design meeting:

• The Preferences, Audio, and Keyboard Help buttons all provide meaningful quick access and should be kept in their current location next to the PhET logo.
• The PhET menu could be restructured to fit some of these purposes but is not ideal for discoverability. Similarly, the toolbar used for Voicing could be more general and contain audio controls, etc. These are not ideas we are currently interested in pursuing.
• We could remove the Home button and instead click on the sim name to get back to the Home Screen. Anecdotally, this isn't a button we see students using much in interviews. This would be a large-scale change, so not something we are considering currently.

We decided to make a few changes to reduce visual weight:

• [x] Reduce size of the icons on the Home button, Preferences button, Audio toggle button, and Keyboard Help button by 15%. (The button size should remain the same.)
• [x] Reduce the size of the PhET-iO logo by 15%. Do not make any changes to the size of the regular PhET logo.
• [x] Reduce the padding between the Preferences, Audio, and Keyboard Help buttons to be more like this:

I'm really not sure who is best to assign here, but I'll go with @zepumph since he's the responsible dev for joist.

[samreid]

I addressed the requests in the preceding comment. Things mostly look good, but I wanted to raise a few minor misalignments after this change:

First, after this change, the bottom edge of the home icon almost but not quite aligns with the bottom of the screen buttons, should that be adjusted?

Second, the dot in the "i" almost but not quite matches with the top dot in the shish-ke-bob menu:

Should we adjust either of those cases? Who should review these changes?

[zepumph]

From PhET-iO design meeting:

@arouinfar and @kathy-phet reviewed this this morning. @jessegreenberg will be the reviewer, but first @arouinfar will post a couple of pixel polishes to do.

[arouinfar]

First, after this change, the bottom edge of the home icon almost but not quite aligns with the bottom of the screen buttons, should that be adjusted?

Previously, the home button was vertically centered in the navbar, and that is still the case, so no further changes are needed.

Second, the dot in the "i" almost but not quite matches with the top dot in the shish-ke-bob menu:

I think the issue here is that the kebab menu should also be reduced in size by the same proportion.

but first @arouinfar will post a couple of pixel polishes to do.

Here are the pixel polishes:

• [x] Reduce the size of the PhET logo by 15% in all brands, not just PhET-iO.
• [x] Reduce the size of the kebab menu dots by 15%.
• [x] Vertically center the PhET logo, a11y buttons, and kebab menu dots in the navbar.
• [x] Maintain the previous pointerAreas for the a11y buttons. It seems like they` were reduced proportionally with the buttons.

[samreid]

Centering the kebab dots on the bounds of the PhET-iO logo image looks lopsided because the image has asymmetrical bounds (bounds includes the dot of the i)

Instead, I centered it on the PhET-iO logo but without the letter "i":

[samreid]

After the changes, the pointer areas are looking like this:

It seems the request is to expand them by 15% or so?

[samreid]

After adjusting the pointer areas:

[samreid]

All requests complete, wasn't 100% sure about the vertical centering since the PhET icons are asymmetrical as described a few comments back. The picture in the previous comment is zoomed in. Ready for review.

[arouinfar]

Thanks @samreid everything looks good in master, including the pointerAreas.

Here's a comparison of the original scaling (top) to master (all brands).

I think this is ready for review by @jessegreenberg, so assigning to him.

[zepumph]

Pinging @jessegreenberg here, we got here during PhET-iO design meeting

[jessegreenberg]

Thanks @samreid, I reviewed commits referenced here and comments. Looking good.

Only one question, is this pickOptional necessary? Those new JoistButtonOptions are already optional on the parent options.

https://github.com/phetsims/joist/blob/b4dcd697d6e9da35254485a4eadec8fbd95d9f00/js/KeyboardHelpButton.ts#L32

Same for NavigationBarAudioToggleButton and NavigationBarPreferencesButton.

[samreid]

Thanks, I converted from PickOptional to Pick. Is that what you had in mind? Please close if all is well.

[jessegreenberg]

I'm sorry, I misunderstood the ProvidedOptions of these subclasses. I was actually thinking get rid of Pick for

export type KeyboardHelpButtonOptions = SelfOptions & PickRequired<JoistButtonOptions, 'tandem'> & StrictOmit<JoistButtonOptions, 'listener'>;

But I see now from the implementation of these JoistButton subclasses that it is best to exclude most of the JoistButton options.

Otherwise I don't feel too strongly between Pick and PickOptional here.

Good to close then.

[kathy-phet]

@samreid - Just want to confirm whether this should this go back to PickOptional? Or stay as Pick?

[samreid]

Pick works well because the option is already optional so doesn't need to be marked optional twice, this issue seems OK to close. Thanks everyone!