I think creating short helpful hubs is a good idea and I think the userinput system can help make sure the vids don't need to be recreated often

re: short, helpful hubs vids

To me these videos make a lot of sense as long as we are careful to leave specific information about bindings that are subject to change _out_ of them, so that updating the bindings does not require updating the videos. I think what is both desireable and feasible in the short term is implementing something like the Steam Controller API's GetDigitalActionOrigins() and GetAnalogActionOrigins(), which we can do because we build up the required data structure each time active devices change anyway, just to put them in order. (These apis essentially let you get device-specific glyphs to show the user how to do something in your app. See http://www.gamasutra.com/blogs/LarsDoucet/20161012/283057/Steam_Dev_Days_Steam_Controller.php or https://partner.steamgames.com/doc/api/ISteamController (search page for https://partner.steamgames.com/doc/api/ISteamController )

So what it _would_ take to display device-specific glyphs without needing to update the copy / face / video help system?

We can create a handful of these two-or-fewer-minute videos to show users how to do something in hubs and load them using the media tools. 
If the user asks, "How do I _foo_?" (e.g. foo = "teleport")
We search the action paths for _foo_.
We display some general help about hubs and how to find more information if we don't find something about the capability to "_foo_" when you're in hubs.* (*Or, for that matter to "_foo_ a _bar_ when _baz_" where _bar_ is something we currently call "pen", "interactable", or "camera" and _baz_ is what we call each frame's set of active action sets).
If we DO find the user's intent (or if they perform some equivalent gesture), displaying device-specific visual ought to be simple-ish to add given that we already know (on every frame) the following things:
- every device that is active
- whether it is possible to perform the action, given the current app state (you can't teleport while holding an object on some devices)
- in the case that performing an action is impossible, we can articulate the reason why (it looks like the touchpad _would_ teleport you, if you weren't holding that duck right now), which may give the user some intuition for what they need to do to accomplish what they want ( _thinking:_ oh, I have to drop the duck and then teleport... that's too bad... oh wait, "can I put the duck in my inventory?" ... "...sorry, action not found. displaying help...")
- in the case that performing an action is possible, we know all of the possible ways (given the active devices) the current user can perform the action, which is what we wanted at the beginning when I mentioned GetDigitalActionOrigins and GetAnalogActionOrigins.

I suggest we don't take this all on right away. We are still straightening out the userinput system and have devices that are not properly supported yet.
I think the short video clips is a good thing to do NOW because short clips can teach the user and give us an opportunity to showcase the app being used in an exciting setting. (I imagine that a video shows robots teleporting in a good looking environment with g o o d v i b e z is more interesting than teleporting around the empty space the user may find herself in for her first experience).
Adding the visual device-specific (or more accurately, registerBindings-specific ) bindings doesn't seem that far out and so ought to discourage us from putting device-specific information in the videos, but certainly shouldn't block us from creating and using the videos now.