[Galene] Potential improvements to subgroups (breakout rooms)

[Juliusz Chroboczek <jch@irif.fr>]

Hi,

I've just had an extended e-mail discussion with a high-school teacher.
She's been using subgroups extensively, and found the interface lacking.
She's making some interesting points, which I'll write down here for
posterity.

Apparently, she starts her session with all students in a single Galene
group, then splits them into subgroups to work on their own.

1. She finds it difficult to join a subgroup.  I've fixed that by making
   the output of /subgroups clickable (already in master).

2. She wants to streamline the process of splitting the group.  With
   clickable subgroups, it is possible to right-click the link, choose
   « Copy URL », then send a PM.  In order to make this easier, I've make
   the /subgroups output include empty subgroups (they used to be filtered
   out), and added an (undocumented) /touchsubgroup command to create an
   empty subgroup.  (Recall that automatically created subgroups remain
   maxHistoryAge seconds (default 4h).)

3. She makes the following suggestions.

   3.1 She suggests that there should be a way to forcibly move a user to
       a subgroup.  That's a good idea, but it needs to be done carefully:
       Galene should ask for consent from the user before moving them.

   3.2 If moving a subgroup is too forceful for Galene, she suggests that,
       instead, there could be a command that sends a private message with
       the URL of the group to join.  I think that's an excellent idea.

   It would be easy enough to add a chat command, say "/move user subgroup",
   but doing that with a contextual menu is problematic.  The client does
   not maintain the list of subgropus, it requests it from the server when
   you type /subgroups.  The result is that you would need to fetch the
   list from the server between the click and displaying the menu, which
   would need strict timeouts in order to keep the interface responsive.

   There's another issue: Galene's protocol is fully asynchronous, and
   does not have a notion of replies and requests.  With hindsight, this
   is a mistake, we should add a "request-id" field to pair replies with
   requests.  Not difficult to implement, just requires explicitly
   categorising all protocol messages into requests, replies, and
   notifications.

4. When keeping track of multiple groups of students in multiple browser
   tabs, she finds it bothersome to have to mute/unmute the tabs.  She
   suggests a mode where all tabs are muted, and only the active tab is
   unmuted.  I think it's a good idea, I'll have to look carefully at the
   browser API's to see if that's implementable.

-- Juliusz