Token auth flow UX

[kousu]

This is some feedback around my Zulip integration :)

When joining a room with a token there are several flickery states the frontend UI goes through that feel messy. If they were streamlined, it would help reduce the friction for any organization that's looking to deploy Galène where the argument is usually going to be "vs Teams" or "vs Zoom" or "vs Slack". I would love for small non-profits and the like to have a practical alternative that they can fit within their IT budgets instead of defaulting to relying on the oligopolies, and I really believe Galène is a strong strong strong contender for that, but it's often stuff like this that makes or breaks a decision to switch.

1. "Galène" placeholder + "muted" ❌ + chat input box shown ❌

   Details

   

2. Room name 🟢 + "unmuted" ❌ + chat input box shown ❌

   Details

   

3. Play/Share buttons shown ❌

   Details

   

   This is the most jarring to me, because I'm sighted and this is a brightly coloured split-second flash.

4. Join prompt 🟢 + "unmuted" ❌

   Details

   

   This prompt is necessary and standard in video calling apps now, but why does the toolbar show at all? It should either always show everything (Video/Audio/Share) or be nothing while the prompt is asking for the same information.

   For inspiration, Zoom presents this as two orthogonal buttons, centered. After join they move down to the status bar, retaining the same icons.

   Zoom's join prompt

   .

5. After clicking connect, password input ❌ + options jump back to "Enable Nothing" ❌

   Details

   

   I imagine this creating the most user anxiety: "What password?!" "Is my camera not going to work??". Luckily it's brief, but it's a first impression.

6. Play button + chat input shown again ❌ + unmuted 🟢

   Details

   

7. In the call 🟢

   Details

   

Here's the full experiment using a token with a pre-filled named:

Screencast.From.2026-03-31.15-50-05.mp4

Even if there are internal states, the states exposed to the user would be nicer if slimmed down to:

1. A loading spinner
2. The Join prompt
3. The Call

Here are my suggestions:

• Everything in the UI can start out display: none and only display: block once it's actually known to be needed.
• The Enable/Display button (the green/red play/stop button) and the Mute buttons should set their state before becoming display: block.
  • they should have synced with the user's intent:
    • Nothing => (Enable, Muted)
    • Microphone => (Enable, Unmuted)
    • Microphone + Camera => (Disable, Unmuted).
  • Moreover, I wonder if you could replace the radio list with two buttons the way Zoom does it. The "Enable/Disable" button is equivalent to Zoom's "Video" toggle, and the "Mute/Unmute" is Zoom's "Audio" toggle. Instead of a radio list, you could directly reuse those widgets in the Connect prompt, centered just above the Connect button so it's clear they're part of the prompt.
    • This also allows joining in the (Enable, Muted) state which I often find myself in for medium-sized meetings of teams that know each other / are trying to maintain some human contact. It's a state available by joining with Nothing then turning on the camera, but it would feel cleaner if it could be done in one step; having to train people on the workarounds slows down their acceptance of any new app in their lives.
• The password field should not flicker onto screen after 'Connect', especially not during token auth.
• The chat (input/log/member list) should not show before connect at all.
• The chat, after connect, should only show by default on a large screen. On a small screen, it should not flicker into view momentarily.
  • I haven't looked at how you have this implemented now, but one possibility is to set a hidden form checkbox with the default state of off, and write the CSS to show the chat UI if in a large-screen media query OR if the checkbox is checked. Then the "show/hide? chat button that's shown in the small-screen case just toggles the checkbox.

What do you think of that general design?

[jech]

I would tend to agree with your assessment. I think this needs to be discussed with @valentt, since he will be working on the UI, and the two of you should make sure you're not working at cross purposes.