Investigate simplifying collaboration session workflow
See original GitHub issueThere are two main pain points:
- Too much text.
- User having to manually start the sharing session.
@vjeux suggests that we should remove the start session
button in favor of automatically starting it when user clicks on the menu 👥 button.
His proposal (as I understand it) would be as such:
- Click on the menu button starts the session, updates URL, and opens the dialog with the link to be shared with others.
- When you close the dialog, and later click on the menu button again, it would stop the session, effectively making the menu button into a start/stop button.
I have a problem with this workflow for these reasons:
-
Users may just want to check what the button is, or how it works, and decide they don’t want to start a session. Thus, after reading through the dialog, they’ll close it, possibly not realizing the session is already in progress.
Note that currently the behavior of a scene that’s singleplayer/multiplayer is different. When you refresh in multiplayer, you loose the scene data. There may be other differences. For this reason alone, I don’t think we can go forward with this until at least https://github.com/excalidraw/excalidraw/issues/910 is resolved.
Another consideration: we’ve heard some voices that wanted to ensure absolute privacy (despite our E2E encryption), going as far as to express desire to be able to run excalidraw without support for creating shareable links. If we make it this easy to start a collaborative session, and automatically start sending data to a server, this will move us further away from achieving that goal.
-
Overloading the menu button to also stop the server is not intuitive. Users may want to open the dialog while a session is in progress for several reasons (while not wanting to stop the session):
- To re-read the instructions.
- To copy the link to send to others (note that many users won’t be aware they can simply copy the link from the URL, as it’s not obvious it’s the same link we show in the dialog).
Moreover, if they inadvertently stop the session in this way and want to start it again (e.g. to reconnect to the room where they colleagues are), they’ll generate a new link for a different room).
Counter-proposal
- Clicking on the menu button will open the dialog, start the session automatically, and update the URL, and show the link in the modal. But, we’ll also show a
stop session
button in the dialog so they can manually stop it. - Clicking on the menu button again won’t do anything except show the same dialog.
This proposal has the same benefit of removing one extra step, but makes it more obvious how to stop the server, and doesn’t have the disadvantage of users mistakenly stopping the server just by clicking on the menu button.
That said, I’m still not certain even my counter-proposal is a good way to go, for some of the aforementioned reasons (mainly, starting a session automatically is not how these things usually work — you want to warn the users, first).
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:5 (4 by maintainers)
Top GitHub Comments
Counter counter proposal:
What we could (and should) do is to only broadcast things to the server if there are more than 1 user. So when we create the room, it just creates the socket but doesn’t actually send any data. I think it’s a fine middle-ground.
/cc @vjeux written up
Personally, I’m for simplifying the text, and keeping start/stop buttons explicit.