UI: observed failure of user to connect due to obscured button about jitsi-meet HOT 13 OPEN

Can you share a screenshot?

from jitsi-meet.

Platform was iphone/safari. I'll try to reproduce it next time I have one of those at hand.

from jitsi-meet.

...I tried with android/fennec and it scrolled the background down behind the keyboard so that the button was still visible. Although it seems to me that this UI still makes it too hard to know whether you are connected. It should be obvious from a distance and not require reading text. A giant red border around the entire screen maybe that flashes green during connection attempts, turns solid during connection, then you can have it fade out with the menu. I am just coming up with random ideas here. The problem can be solved in as many ways as you can skin a cat.

It seems to me the most correct solution is to join the room automatically and then immediately start forwarding information to the user via the speaker and video display. So that the user does not miss any information. Allowing the user to be timely. Concurrent with the timely audio/video display of precious remote-originating information, the user can be prompted for information about their username and to connect local information streams -- i.e. the user can be given separate options to reveal (1) a name they type locally (2) audio they record locally (3) video they record locally. The user can expose and unexpose their own local name information through a separate menu or option field on top of the remote video display just like exposing and unexposing their mic and camera. None of these need to hold closed the remote video display or the audio stream. The menu (a submenu, etc) could still be forced "always-on" on the display to capture required user input, without closing these streams.

The user shouldn't be prevented from timely access to remotely broadcast streams, just because they haven't interacted with the system (yet). The system is losing information while waiting for a user interaction that isn't logically required. The system is bleeding data.

Just my thoughts since I came back here, and thought about this some more!

from jitsi-meet.

To start getting and transmitting video/audio user interaction is needed. This is coming from protection implemented in webrtc itself, in the browsers.

from jitsi-meet.

I don't think that you are correct about user interaction needed after the self-view camera is already started?

from jitsi-meet.

We have recently updated the pre-join page to be enabled by default. We had many reports in the past few years people having problems with meetings because of that and after enabling pre-join screen where there is a user interaction before starting the webrtc session, those problems disappear. We have been running all our deployments like that for many years now.

from jitsi-meet.

You can read more about it here: https://webrtchacks.com/autoplay-restrictions-and-webrtc/

from jitsi-meet.