Build screen sharing based on Live View

Hi there,
I’m starting a project with Phoenix, my first actually. One of the features I need is the ability for an administrator of the webapp to see the current rendered web page of any currently connected user.
I look at Live View with sweet eyes, hoping I can use it to do just that : the admin Live View would be able to hook into any user Live View render() function.
I know it is not trivial, but any of you ever heard of such feature already ?
The final usage is : the admin can help any user by seeing what he is doing upon it’s request, without installing any kind of screen sharing software. Of course, this would be limited to my webapp only, but I’m fine with such limitation.
Thanks for your help and excuse my english, not my mother language.

Jean-yves :slight_smile:

5 Likes

That should be possible, and it sounds like a really fantastic use case.

Hi,

I haven’t looked at Live View yet, but…

Have you considered web sockets? I guess it may depend on how you set up your front end.

I like to use Elm for the front end, which works well with web sockets and Phoenix Presences.

Your use case is something Ive considered (but not yet implemented). It should be possible for one screen to mimic another, and control it or interact with it, over web sockets.

Just a thought.

I’m currently using LiveView for a project and we have a feature that lets a person see where someone else is in the page. This is done with Phoenix Presences, as phollyer already suggested. From what I’ve seen I don’t think there is a way of making this work “out of the box”, however I there is a way that I believe could work.

You could add to a presence tracking everything that is mutable of the view and have the liveview update this everytime something changes, meanwhile on the administrator view you use the exactly that struct to render a very similar liveview that only consume the data with the presence subscription.

The big problem with this is that tracking would not be natural, but based on what you explicitly update, for example for an input you would need to update the presence with phx-change and would need to write that everywhere. Also this would not show the cursor/focus unless you somehow track that too.

I agree that the use case is great

The way I’ve implemented this in the past is to allow Admins to assume the role or login of a user, without sharing passwords etc.

It would depend on the application itself if this would be a valid approach. For instance, if you needed the Admin to help fill out a halfway filled out form, it probably wouldn’t work. Because that state would only exist on the clients browser.

In the end it really depends where the session state is stored. If it’s client-side, VNC is really the only valid approach. If it’s in a database, the admin can simply assume you he users role.

Where this could be cool with LiveView is pushing what would be traditionally client-side state to a long lived process on the server, and the admin syncing that state to their “view”.

Sounds like an interesting idea.

1 Like

I consider web sockets through Live View since it is how dynamic values are transported already. I try to stay away from front end development, and Live View may help me with that.
Front end dev has never been my cup of tea, I favor the X11 philosophy (I know I talk like an old fella, that I am) : keep the intelligence in the server, compress data and let the client render. It seems to me that Live View is going toward this direction.

Hi entone. Yes, my plan is to have the “user” server side Live View process push events to the “admin” server side Live View process. Either I put the hook on handle_event/3 or on render/1. Don’t know yet, have to try it. Then, I would let Live View engine do its diff/sync optimlization to send over data to the “admin” browser as usual.
I beleive the trick will be in filtering out actions on the admin rendered page, we don’t want the admin to interact, click, submit since we want him to feel he is in a view only mode.
To do so, either we patch the page (in render) to remove the actions, or we alter the admin handle_event:3 functions so that we ignore events. In the latter case, the rendered page would be the same in user and admin case, only the actions would be dead end when admin.

1 Like