⏳ Lobby

[nickvergessen]

• Database and API
• Add UI option to set the lobby value
• Restrict the API to prevent lobbied useres from chatting, signaling, ....
• Keep left sidebar for normal users => use empty content message
• System messages
• Quicker kill when turn on lobby again => Don't retry signaling when the room was deleted or restricted #1928

Fix #382

[jancborchardt]

Working on mockups for both the toggle as well as the waiting screen before I leave for vacation, will post them in the next few hours. :)

[jancborchardt]

Here’s the mockups:

Toggle in Talk sidebar

2 versions. One just inserts more stuff in the sidebar, the other also modifies the way we show the share link.

Menu

• Initially there’s only the 3-dot menu icon next to the call button. We could also put a circle around it for better visibility.
• In the menu you have the "Share link" option, which if enabled also reveals the password protection.
• Below is the choice for "Conversation visibility" or however we call it. This is a pattern which we use for the notifications already, where you can set it to "All participants" or "Moderators only". The menu gives us the opportunity to also explain this more, just like we do for the federation privacy settings menu.
• When a conversation is shared, the "Copy link" button will show presently directly next to the calling button. This also gives an indicator whether the call is shared or not.
  

---

Direct toggle
This direct toggle is only a very quick fix and much too present. Here it is for the record anyway as it doesn’t touch anything else:

---

Lobby / waiting screen

• Essentially an enhanced emptycontent view
• "Icon": Faces of the moderators
• h2: Title of the call
• subline: "Waiting for moderators to start the call …"
• As soon as there’s scheduling, the subline of the lobby can instead say something like: "Scheduled for 15:00, in 4 minutes"
• Bottom right shows your video feed so you can check if it works and the image is ok.
• You can set your name already before you join the meeting.
  

What do you think @nickvergessen @karlitschek? cc @nextcloud/designers for review :)

[karlitschek]

looks good. there should also be a way to set a start time when the call automatically starts

[nickvergessen]

Mutliple issues with the mock up for the lobby

1. I think you assumed you will end up in the call directly? So chat webinary are not going to have a smooth transition. Also we currently don't plan to automatically start joining the call, because if everyone does it at the same time, it will be a huge performance hit, because all peers are done in the same moment.
2. This means we will consume and block the video/audio with your browser already.
3. It's a completly new scenary with UI components from all different sections. Doing this now and then switching to Vue.JS will mean a lot of duplicate work.

But other then that, I like how it looks.

[skjnldsv]

3. It's a completly new scenary with UI components from all different sections. Doing this now and then switching to Vue.JS will mean a lot of duplicate work.

Yes, it's not a good idea to duplicate your work :)
On the mokup itself, I think it looks nice!
I'm not so fond of the background though, we could maybe use the avatar with a really high blur to create a random pattern that matches the current colours (like iOS talk)
And the name input next to the avatar looks kinda out of place, but I don't have any idea currently ;)

[jancborchardt]

@nickvergessen good points. Easy fix for all:
Just use a white background with dark font instead (makes it look like class="emptycontent"), and cut the part with the local video. :)

[nickvergessen]

We decided to go for the dropdown, because I also implemented a datetime field as "end time" for the lobby now, after quick discussions with frank

[skjnldsv]

You mean the menu on the sidebar?

[nickvergessen]

#1926 (comment)
"Toggle in the sidebar" > "Menu"

[skjnldsv]

👍
And this is compatible with the new enhanced sidebar design we created.
So that will help any future transition ;)
nextcloud-libraries/nextcloud-vue#340 (comment)

[nickvergessen]

I think the backend is mostly done. For the Web UI the following changes are needed:

Enabling/disabling the lobby

• The current checkbox for "Share link" and the password option are moved into a dropdown
• A second section is added into the dropdown, allowing to limit the conversation to "moderators only" or "all participants"
• When "Moderators only" is selected an optional datetime input field pops up, allowing to set an automatic end to the lobby

Waiting in the lobby

• When a non-moderator opens the conversation they should see a waiting screen
• The single room endpoint is pinged regularly to check when the conversation is being opened. This also updates their last ping, so moderators can check the list to see who is waiting in the lobby.
• Once the lobby is disabled/opened up, the UI should start signaling and chat polling and allow to join the call like in any other conversation.

[nickvergessen]

Tried my best with the setting UI and at least there are buttons now to check the behaviour,
but it needs a bit of polishing and the date input is still missing.

[danxuliu]

I have removed all the previous UI related code (I have not added the new UI yet, as it depends on other pull request which are not merged yet), bumped the version to trigger the migration, added a notification to the external signaling server when the lobby state changes, added integration tests and cleaned a bit the commit history.

@nickvergessen The old "Actual lobby page" (3f54354) became "Get password from session if not given when joining room" after the clean up (the fix for a previous commit was merged with it, the dummy pages were removed and the signaling was made available when in the lobby for the initial version).

Why is that change needed? Is it needed for the lobby or is it a general fix that can be extracted to its own pull request? Or was it just needed for the dummy lobby page and no longer needed? Can you provide a test case that shows the issue that it solves?

The commit itself introduced a regression when joining a password protected conversation as a logged in user (I have added an acceptance test that shows it); I fixed it for logged in users following the change you made for guests... but please check it :-)

Besides that, as the signaling is now accessible while in the lobby, is pinging when getting a single room still needed?

Finally, it would be nice to have some integration tests when setting the start time of the lobby... but I do not know how to simulate specific times; an option would be to test with times N seconds in the future and add a sleep in the tests... but of course I would prefer something cleaner ;-)

[nickvergessen]

Why is that change needed? Is it needed for the lobby or is it a general fix that can be extracted to its own pull request? Or was it just needed for the dummy lobby page and no longer needed? Can you provide a test case that shows the issue that it solves?

It is needed because in the meantime the page reloaded the room every x seconds. But on the way it lost the password and also previously we removed the password everytime you loaded the room. Now we don't do that anymore.
I guess your UI will also not reload the pagecontroller anymore, but I guess the change makes sense to be kept. It could now also be moved out to a new PR depending on how your UI works. I wouldn't do it just to create conflicts and have multiple rebases needed.

But also it's been more than 2 months since I wrote the code, so I don't recall all details anymore.

[danxuliu]

It is needed because in the meantime the page reloaded the room every x seconds. But on the way it lost the password and also previously we removed the password everytime you loaded the room.

Ah, now I see, thanks.

Now we don't do that anymore. I guess your UI will also not reload the pagecontroller anymore, but I guess the change makes sense to be kept. It could now also be moved out to a new PR depending on how your UI works.

Yes, that change is not needed for the current lobby UI, so I have extracted it to #2121

I wouldn't do it just to create conflicts and have multiple rebases needed.

This pull request will have to be rebased anyway, so I will drop the commits related to the password and the ping when doing it. No need to wait for the other one to be merged nor anything, though.

But also it's been more than 2 months since I wrote the code, so I don't recall all details anymore.

Detailed commit messages help with that ;-)

[danxuliu]

What also helps is working on stuff in time, not 24h before the release.

Yeah, if I had time before that would have been great. Do you think that I have enjoyed overtiming for two months and also then crunching a few nights? Hint: no.

Also helping: not pushing 45 commits on the last day that were made more than a week ago.

I did not want to keep rebasing several drafts until the required previous work settled. But OK, I will try to do it next time.

Also several page monologs that are not read anytime ever again are not helpful, but what so ever.

I do. But yes, whatever.

Anyway, regarding the lobby UI the external signaling server does not send update messages to guests when a room changes. Due to this, when the lobby state is changed the UI for guests is not immediately updated, although it will be eventually updated due to the periodic forced synchronization (which was added to work around an issue in the UI of users, but ironically helps here too ;-) ). This issue is unrelated to the lobby itself, and a proper fix requires changes in both Talk and the external signaling server, so it is something for a different pull request (and the future).

Besides that, the UI when joining as a guest a room with the lobby enabled is not good; the problem is that the guest first receives the room data when she has not joined the room, but that is enough to set up the UI. Then, when the actual room data is received it is found that the user is in the lobby, so the UI changes to the lobby view. It is basically the same problem as in guest mentions with the external signaling server, and actually unrelated to the lobby; it will be (eventually) fixed in a different pull request.

Finally, note that if the lobby is enabled while a call is ongoing the regular users will not be expelled from the call. That is something that should be handled by the signaling more than the UI, though, so also something for later.

[nickvergessen]

As a guest open the conversation when the lobby is in place
As the moderator disable the lobby
After the guest is updating the UI the avatar on the chat input is massive:

[nickvergessen]

Finally, note that if the lobby is enabled while a call is ongoing the regular users will not be expelled from the call. That is something that should be handled by the signaling more than the UI, though, so also something for later.

Ah, so that happens because signaling continuous to work now. Yeah let's discuss a plan for that in a follow up issue

[danxuliu]

As a guest open the conversation when the lobby is in place
As the moderator disable the lobby
After the guest is updating the UI the avatar on the chat input is massive:

Weird; it slipped my tests because it only happens with newer Firefox and Chromium versions if the internal signaling server is used; in older Firefox versions or when the external signaling server it does not happen :-O

In any case, I do not think that this is related to the lobby, as I have seen that before in the past, but I never found a consistent way to reproduce it. Now with the lobby I have, so I will see what is going on ;-)

[danxuliu]

I do not think that this is related to the lobby, as I have seen that before in the past

It was indeed unrelated and needs to be backported, so here is the fix: #2124 (there is no need to rebase the lobby pull request once that one is merged).

[nickvergessen]

So, all checkboxes ticked, ready to go? Or still something missing before this?