I had a similar idea for talk iOS a while back, because we don’t have a speaker view there.

Also I think we should take into account the permissions, eg in webinar scenarios only some participants have publishing rights, these should move to the front and everyone without any publishing rights should be always at the end f the grid.

But also need to make sure that the grid is not constantly moving I guess …

Yeah, I agree that we should consider "resorting", but it should not be "fluid" but with some delay sensitivity.

At the moment e.g. also the speaker view changes on "coughing" and that should not happen. There should be like a ~500+ms active time required or even multiple seconds.

cc @jancborchardt for design input

@nickvergessen For a large grid size with more than 19 streams, the server and the client can work hand in hand to downsample the videos for grid view and a dynamic stream for speaker view (depending on the bandwidth). Does the downsampling consume lots of resources? I would assume this can be done at the transcoding step when the streams are sent out to the clients.

@SystemKeeper

Also I think we should take into account the permissions, eg in webinar scenarios only some participants have publishing rights, these should move to the front and everyone without any publishing rights should be always at the end f the grid.

I had a naive idea how the structure could look like. It could be two windows: the first grid array and the complete grid array (array term used to demarcate the area, does not have to be a nested array). Something like this:

[[_ _ _ _ _ _] _ _ _ _ _ _ _ _ _ _]

All the elements can have a metadata last_spoken_at and the first grid is filled with publishing rights participants at the start of the call.
If there is a person speaking and the person is in the larger array and not in the first grid, we can move the element to the inner array at the beginning pushing all other elements back by 1 until the original position of this element. The thing to note here is that the grid would only pick up the changes and replace the participant out of the inner array with the new one in its place without affecting the whole grid.
It looks a bit complex in retrospection but I can't think of any other way.

Agree with all the points said already. Se additions:

• People we know to be "important" or likely speaking, like moderators, should be sorted first
• The re-sorting only needs to happen if there are multiple pages
• The re-sorting also only needs to happen if the speaker is not on the page you are looking at right now
• We don't need to constantly update the order to have whoever talked most recently to be first in the list, as long as they are still on the current grid page