screen-annotation

Drawing on the screen the user is showing you, so they can go and do the thing themselves. This is the opposite errand from computer use. Nothing here clicks, types or drives anything: the marks are a way of pointing while you talk, for someone who wants to learn where a control is rather than have it operated for them. A mark is drawn clear of what it indicates and never takes the mouse, so what you point at stays visible and clickable the whole time. ## Requires a screen share Marks are drawn on the frame around the surface the user is sharing with the call. With nothing shared there is nowhere to draw, and `screen_point_at` fails saying so. Ask them to share their screen from the call, then point. ## Say what to point at **Name the thing.** `{"target": "color balance", "caption": "Click this"}`. The name is looked up on the surface itself, which knows where its controls actually are, and an arrow is drawn at it. **The label, not a description of it.** What is matched is the control's own name. Casing, spacing and punctuation are forgiven, so `Color Balance` finds `color balance`; nothing beyond that is, so "the stabilization button" finds nothing, because no control is called that. Give the label on its own: `stabilization`, `Send`, `Search`. The arrow points at the middle of the control and stops just short, so what you are sending someone to stays visible the whole time. You are answered with what was drawn and the name it resolved to, which is not always the nam...