cryptag / leapchat

Ephemeral, encrypted, in-browser chat rooms
https://www.leapchat.org/
Other
184 stars 32 forks source link

Add toolbar control for toggling audio, persist preference between sessions #287

Closed jimmcgaw closed 1 year ago

jimmcgaw commented 1 year ago

This PR introduces an option to mute the audio in the LeapChat browser window.

We haven't discussed audio design; perhaps this should be configurable in settings at a more granular level, ie "play sound for all new message", "play sound only when I am mentioned in a message", etc.) But at a minimum, the user should be able to turn it off.

What this PR does:

  1. When the user first loads the window and is presented with the "Set Username" dialog, don't play the audio in the background. This triggers a JS console error.
  2. Once the Username modal is dismissed, check if the user has previously set an audio-enabled preference. If so, default to that, else just enable it by default.
  3. An icon on the chat toolbar that allows for toggling the audio-enabled preference. This is persisted to the App state so it affects the session immediately and is persisted to localStorage to be used in future visits / sessions.
  4. Also, there are some React annotations, like prop types for components, blah blah.

toggle-audio

elimisteve commented 1 year ago

@jimmcgaw Rough UX thoughts; feel free to act on whichever parts you want, or hold off till we get user feedback, or have me to them, or suggest different solutions, or suggest things stay as they are:

  1. Having the button where it is makes it easy to get to, but arguably it's more intuitive for it to be in the Settings modal.

  2. Let's at least have equal horizontal spacing of the icons in this bar just above the textarea, including equal spacing between the left-most icon and the left edge of the bar, methinks.

  3. Having the speaker jump right when muted feels a little off? Maybe force it to stay to the left so the spacing between icons remains constant? (If this is the only icon that changes its width when clicked then in the future maybe it should remain the right-most icon in the bar. Or maybe it's more weird for it to move as new features are added. Could put a vertical separator bar to its left to help solve that? Then the mute/enable audio button will always be to the right of the separator.)

jimmcgaw commented 1 year ago

@jimmcgaw Rough UX thoughts; feel free to act on whichever parts you want, or hold off till we get user feedback, or have me to them, or suggest different solutions, or suggest things stay as they are:

  1. Having the button where it is makes it easy to get to, but arguably it's more intuitive for it to be in the Settings modal.

This won't be the last time I rearrange the UI, including figuring out what goes in the Settings modal. My thoughts: if we need to show max progress at the end of these couple of weeks, let's leave it visible for now.

  1. Let's at least have equal horizontal spacing of the icons in this bar just above the textarea, including equal spacing between the left-most icon and the left edge of the bar, methinks.

I'll add some padding to the left of the emoji picker. Sound good?

  1. Having the speaker jump right when muted feels a little off? Maybe force it to stay to the left so the spacing between icons remains constant? (If this is the only icon that changes its width when clicked then in the future maybe it should remain the right-most icon in the bar. Or maybe it's more weird for it to move as new features are added. Could put a vertical separator bar to its left to help solve that? Then the mute/enable audio button will always be to the right of the separator.)

It doesn't actually change widths, the "off" icon is just narrower than the "on" one, so it seems to jump. If there were another icon to the right of the speaker, it wouldn't shift. For now, I think the visual is helpful because it clearly lets the user know something has changed.

In the long term: the most recent font-awesome icons version has many speakers, and the mute / unmute icon possibilities are much richer, and they wouldn't shift if changed. I'd like to get us to using those instead, so would rather not mess with this too much.

In generally, happy to discuss design or UX stuff more generally so I have a sense of how to make these decisions, instead of ad-hoc. Or if you have a style guide... :)

elimisteve commented 1 year ago

Sounds good! Pun intended... And nice work 🤠.