Timing determines whether necessity is intelligible
Aliases: just-in-time permission · permission trigger · contextual request
What it is
Contextual permission timing requests access when a person has deliberately invoked the relevant function and can connect the protected capability to the active goal. A launch-time batch request for camera, location, and contacts precedes understanding; a prompt after access has begun loses prior control. The useful trigger sits after intention forms but before protected access.
Why it happens
Necessity is a causal relationship between capability and task, not an intrinsic property of a permission class. A camera request after “Scan document” has explanatory evidence; the same request at launch demands imagined future use. Requests that are early, late, or embedded in urgent completion pressure reduce meaningful comparison. Timing also changes refusal meaning: before trying a feature, “no” may mean not now rather than never.
Studying it
With copy held constant, a study can trigger at launch, feature entry, immediately before first access, or an interruption point, measuring purpose prediction, allowance, refusal recovery, discovery, and delayed revision. Sequence logs should retain the action preceding the prompt to establish whether user intent caused it. High allowance can reflect blocked progress rather than comprehension, so it must be interpreted with understanding, perceived control, and alternative-path success.
Where it stops holding
Continuous background functions lack a visible trigger for every event and may request once when the feature is enabled, with persistent state explained. Emergency, accessibility, and security contexts require attention to failure cost without leveraging urgency for unrelated permission. Where operating systems limit repeated requests, a mistimed first attempt has lasting consequences; confirm feature intent before invoking it.
Applying it
- Bind the request to an explicit user action requiring the capability and preview the functional outcome before the system call.
- Avoid launch-time batches for hypothetical future use; leave people who never enter the feature undecided.
- After refusal, support a limited alternative or later retry without loop-blocking unrelated work.
- Replay pre-trigger event sequences and require testers to infer necessity from context, also checking state after decline, deferral, and return from system settings.