Mechanism to expose some ophyd device methods directly?

As a GUI developer, I am interested in at least three main kinds of interactions between an experimental GUI and the hardware

1. Running an experiment, where a form is used to specify all the parameters and a button is used to trigger
2. Making small "adjustments" like "move sample x by 10 um", "rotate the sample 45 degrees", set the backlight brightness on a slider... That is, "live" control of the beamline hardware
3. Get a passive update of some value, like an OAV image, the current position, etc.

Is there an agreed-upon way of handling 2 and 3?

For 2, you could:
- (a) wrap these in a tiny plan to be run by the RE, so *everything* has to go through the RE. For the simplest cases you can use things like `bps.abs_set()` or `rel_set()` directly.
- this seems like a lot of layers of indirection and boilerplate to do something really simple
- on the other hand you get some stuff for free like not being able to move things while a plan is running
- but you also can't change the backlight brightness while a plan is running...
- (b) directly expose specifically chosen `set()` and similar methods through `BlueAPI`
- basically the opposite pros and cons of above
- status information is more easily propagated to the UI

For 3, a plan is probably really not an option, so it's:
- expose some `read()`/`get_value()`s, etc.
- interact directly with EPICS
- IMO this is bad and we shouldn't do it
- reuse components from the technical GUI - probably the best option where the information we want comes from PVs

Would appreciate any comments from @callumforrester @DominicOram @stan-dot @DiamondJoseph and anyone else relevant any of you can think of. We would like to be in a position where we can start doing some preliminary prototyping of web GUIs fairly soon, so it would be nice to have some kind of agreement on what we want and don't want to support, even if we don't fully implement it yet.