lovasoa / whitebophir

Online collaborative Whiteboard that is simple, free, easy to use and to deploy
https://wbo.ophir.dev
GNU Affero General Public License v3.0
2.11k stars 409 forks source link

Mechanism to create a page that embeds read-only versions is several whiteboards #116

Open droundy opened 4 years ago

droundy commented 4 years ago

I'd love to hear your thoughts on a way to create a page that embeds several whiteboards. The idea is for an instructor to be able to monitor several groups of students and see who might be at a stage where they need help.

lovasoa commented 4 years ago

The easiest is probably to use a set of iframes representing the various boards. Here is a small example I put together quickly : https://svelte.dev/repl/06cb5086951146478e918de7684adcf0?version=3.24.1

Making the boards read-only would be much more difficult. There is currently no authentication system, and thus no way to prevent someone from writing to a board to which he has access.

droundy commented 4 years ago

The read-only idea isn't so much about preventing modification as about enabling the boards to be smaller by removing the editing tools...

lovasoa commented 4 years ago

I see... As a quick hack, if you are hosting the monitor and the whiteboards on the same domain, you can do the following :

my_iframe.contentWindow.document.getElementById("menu").style.display = "none"
droundy commented 4 years ago

I'll try that. (when I find time). On a related note, does the server know what the view ports of the clients are? It would be lovely to be able to see what students are looking at, and even to automatically follow their view.

lovasoa commented 4 years ago

No, at the moment, clients do not send their full viewport to the server. But they send their position via the cursor tool.

droundy commented 4 years ago

I've started hacking together a "view/boardid" path that allows just viewing a board. Would this be of interest to you? It basically works now, but doesn't have as much cleanliness as I'd like. Ideally it would use fewer browser resources to make it easier to show many of them.

lovasoa commented 4 years ago

Hello ! I don't think there would be a big resource consumption difference, since all the tools would have to be loaded anyhow. The easiest way to implement the view route is probably by putting the menu in board.html in a

{{#show_menu}}...{{/show_menu}}

Then you create a BoardView class in template.js on the server side to render the page with the right parameters.

What do you think about that ? Is that the way you started to do things ?

droundy commented 4 years ago

That sounds much better than what I started doing. I started basically copying files entirely to create a new BoardView, and then editing them. You can see what I've done so far at:

https://github.com/lovasoa/whitebophir/compare/master...droundy:master

Right now I'm looking into switching to your suggestion, which is far simpler.

droundy commented 4 years ago

Ah, looking more closely I see that the board.js fil also needed editing to cope with a different URL path, I had to change

    this.socket = io.connect('', {
-       "path": window.location.pathname.split("/boards/")[0] + "/socket.io",
+       "path": window.location.pathname.split("/view/")[0] + "/socket.io",
        "reconnection": true,
        "reconnectionDelay": 100, //Make the xhr connections as fast as possible

Also, I think I ran into trouble with just removing the menu, and ended up making it hidden instead, so that the javascript that dynamically adds tools to the menu won't fail.

drpetersen commented 3 years ago

This is really cool, thanks! One would also have to somehow dectivate the keyboard shortcuts, right? I just tried your approach by setting style="display: none" for the menu div (quick and dirty, via the browser's developer tools), and found that I could still switch to the pen tool (for instance) by pressing the P key and then paint on the canvas. I fear that ultimately, someone who shouldn't might discover this …