add remote control interface

[aaronpk]

This adds a remote control interface which can be loaded on another device. This will close #14.

Instead of writing a server-side component, I decided to go with Pusher.com to handle the realtime parts. That makes hosting this simpler, and also means writing less code.

Pusher API keys are defined in js/pusher.php which are used by both the PHP and JS side of things. Unfortunately Pusher requires server-side code in order to use client messaging, so I've implemented this in PHP as it seemed to be the easiest option to deploy. This does now require enabling PHP to host this project if you want to enable remote control.

To link two devices, click the little "link/paperclip" icon and enter some unique identifier on both devices. This becomes the name of the channel that the devices use to communicate. Once linked, changing the text on either device will push it to the other, along with changing the font size or speed settings.

You can pull up the control interface with the new icon that appears after linking a device. The remote control interface is designed to be used on a mobile phone, but does work fine on any device.

The remote control interface can start/pause the prompter, scroll up and down (useful when you need to go back and redo a line quickly), and can also change the font size and speed.

I've left this backwards compatible, so that if you don't define your Pusher API keys, you won't see any of the control interface. Also if you don't enable PHP on your hosting, it will be fine as well. The only thing you need to do to enable the remote control is define your pusher API keys in js/pusher.php.

Please let me know if you have any questions or feedback!

[aaronpk]

1: Sure thing, I will work on updates to the README.

2: My thought was to leave the remote out of your public instance of the software. I didn't want to assume you'd want to be responsible for either additional infrastructure or for managing a Pusher account for everyone using the public site. Right now it's great because it's just a static web page so it's easy to host. If you are interested in providing the remote feature on your public instance, we'll have to think through things quite a bit more to make it work well.

3: Normally I'm not a huge fan of using third-party services either, but in this case I thought it actually made a lot of sense. Since the deployment model of this is to just drop it on a static web server anywhere, using Pusher means that doesn't change, it's still extremely easy for someone to set up themselves. Socket.io is great, but requires that you run a server-side component to make it work, which is exponentially more complicated to deploy.

I actually use a custom compiled nginx with an extension that handles realtime pubsub for most of my projects, and once that's compiled into the server it's trivial to use in both the frontend and backend. That would actually be my preferred way to self-host the streaming part, since I cry inside a little every time I have to deal with node.js. But in any case, I do think Pusher makes the most sense here since that means people can host it themselves on shared hosting or even github pages.

[manifestinteractive]

@aaronpk since this repository is specific to https://promptr.tv whatever code that gets added here will need to be able to be deployed to that website as well. Would you be down to work on a new branch with me to test this out? I have a background making socket.io apps, so I can certainly build a backend to manage this in a secure way. I also have a dedicated server setup for this project, so getting a CI deployment setup to handle the socket communication would be pretty straight forward.

Let me know what you think of this setup:

Current UI:

1. Add new REMOTE button
2. Clicking REMOTE button opens modal
3. New modal shows random generated remote key ( six digit alpha numeric ) with instruction on how to access remote control
4. Once connected, UI shows Connection Status ( and modal closes )
5. Should have the ability to disconnect remote

New Remote Page:

1. Initial screen requests the six digit pass code
2. Once entered, and correctly connected, show the remote
3. Remote should show connection status
4. Remote should have disconnect button

[aaronpk]

I like the workflow you've outlined here!

I made my PR only enable the remote feature if you've defined a pusher.com API key, expecting that you'd leave it out of your deployed instance at promptr.tv, so that you could merge this and not see any changes with your instance. But I like the version you've described better, and if you're willing to support the remote feature on promptr.tv then even better!

I'd be happy to work with you on a new branch for this!

[manifestinteractive]

@aaronpk yep, totally willing to support the remote branch, as I know some voice over people that would LOVE this feature to use external devices to manage what is on their monitor. It'll be a few weeks before I can wrap it up, but I would certainly love it if you could help test it out to make sure it at least covers your use case.

But ya, this way, we can deploy it to the production site, and everyone that wants access to manage the teleprompter with a remote device could just get a private access token and basically get a private / secure Socket channel to communicate between the remote and main site.

Brilliant feature idea, and thanks for suggesting it :)

[manifestinteractive]

@aaronpk this feature is now in production :)

New Remote Icon:

New Remote Modal:

New Remote Control:

[aaronpk]

Okay this is very slick! Much better than the version I hacked together! Thanks so much! 👏

[manifestinteractive]

Thanks for the idea :)

BTW, I did not add a remote feature for the font size, as that was something I talked to a few people about, and it was sounding like basically, one the primary screen was setup, you were really only ever going to be needing to control playback related stuff, so things like scroll speed, page position, restarting, etc, mattered more. Plus I added the timer as sometimes there are two people viewing this time ( the person doing the reading, and maybe someone else doing the remote work ). So made sense to put it in both places.

QR Code made it easy to use iOS to just take a picture, as that was something their native camera app could do, and it will just ask you if you want to go to that URL while trying to take a picture of the QR Code. Not sure how Android handles that, but should be similar. Code works for those that cannot use QR code... so should be pretty easy for everyone.

Did a LOT of testing to make sure each session stayed private. One thing I did leave in that I detected during testing, was you can technically use more than one remote at a time. Not sure that will ever be needed, but you can take as many mobile devices as you want, and they all sync up... so if you start / stop on one remote, the other remotes will update to show the current state. Each are bound to the unique remote session ID, so should be pretty cool for anyone that needs that specific use case ( possibly a studio that might need more than one person to manage the teleprompter ).