Enquiry States: Labels, Confirmation and Recovery

Match the action to the reader’s readiness.

Begin with the reader’s task: ask a question, request a quote, obtain support or start an application. Name the destination and expected next step before asking for information. A vague “Continue” can conceal a different action from the one the reader expects.

Choose the component for its purpose and data shape. A definition helps a beginner; a comparison table helps someone weighing options; evidence and limits help a skeptical reader; requirements and a clear next action help someone ready to enquire. A user-state label is a planning hypothesis until supported by research, not a fact inferred from one keyword.

This page specifies an enquiry path in ordinary text. It has no deployed form, submission endpoint or send button. Reading the example, copying its text or opening an email draft would not establish that any message was sent or received.

Give each requested field a reason and a label.

A minimal fictional enquiry needs a reply address and a description of the question. A name may help personalize a reply but need not be required in this example. A topic selector is useful only if it changes routing; do not require a phone number or budget merely because a template contains those fields.

Visible labels should identify purpose, required status and any format restriction. A placeholder disappearing after entry is not the whole instruction. If an entry is rejected, identify the field, explain the problem and preserve valid information so the reader can correct it.

Ask only for information needed for the task. Describe the recipient, purpose, handling and applicable privacy route before collection. Do not invent a retention period, response deadline, security certification or permission for unrelated marketing. A real service must supply its own confirmed policy.

Separate validation, transmission and acknowledgement.

Initial state explains the purpose and required information. Incomplete or invalid state names what needs correction and does not claim transmission. A processing state belongs only to an action genuinely in progress; repeating an animation without a request is misleading.

A success acknowledgement should follow evidence that the receiving system accepted the request. Its wording must match that event: accepted into a queue is different from delivered to a human, read, resolved or answered. A reference can help recovery when a real system actually supplies one.

Failure and uncertainty need different wording. A definite rejection can say the request was not accepted. A timeout after sending may leave acceptance unknown; saying “not sent” could cause duplicate submissions, while saying “received” would invent success. Preserve the known state and offer a way to check it.

Worked enquiry: an unsent draft and possible outcomes.

The following fictional enquiry asks for help understanding a source-record lesson. No real person submitted it, and no real email or server acknowledgement was generated. The draft is ordinary text the learner could adapt elsewhere, not an operative contact control.

Draft subject: “Question about a source-record example”. Draft message: “I am reading the source-record lesson. Please clarify how to record an undated source without implying it is current.” The learner would add their own reply address in the chosen email application, check the intended recipient and decide if they want to send it.

The draft-state wording is: “Not sent. This text is a draft; review the recipient and content in your email application before sending.” Opening or preparing that draft does not transmit it. An email application’s Sent folder records the application’s action, not proof that the recipient read or answered the message.

For a hypothetical real web form, suppose a response from the receiving system explicitly accepts request EXAMPLE-104. Its acknowledgement could say “Your enquiry was accepted. Reference EXAMPLE-104. Keep this reference if you contact support.” That sentence is conditional example copy, not a status notice about a current request.

If the request times out with no reliable acknowledgement, the appropriate example is “We could not confirm receipt. Keep your enquiry text and check for a confirmation or contact the responsible support route before sending again.” A real design should use its confirmed status or duplicate-handling method.

Review the required paths and preserve access.

Walk through initial, empty, partial, invalid, processing, accepted, rejected and unknown outcomes in the specification. Check cancellation, repeated action and recovery where applicable. These are expected-state cases for a future deployment; this page has not sent a request to test an endpoint.

Use text alongside colour or icons to identify state. W 3C’s input instruction guidance, error identification guidance and status-message guidance address different parts of this task. A real form also needs correct label relationships, keyboard operation and observed assistive-technology checks.

Keep the required information and next step available at narrow widths. Do not hide error detail in hover-only text, discard the enquiry after a timeout or make a confirmation look like a new required payment. A real fallback destination must be checked before it is promised.

Keep the handoff bounded and maintainable.

Record the action purpose, required fields, destination owner, data-use explanation, state messages, confirmation evidence, duplicate handling, failure route and review trigger. MIRENA’s component-planning method uses need, passage role, data shape, evidence, behavior and fallback; those fields help explain why a component belongs.

An operational service must supply current policies and evidence for its commitments. The static teaching example creates no response-time promise and stores no enquiry. Changes to the endpoint, policy, required fields or acknowledgement logic should reopen the relevant review.

Choose the next route from the confirmed state.

Return to visual meaning and usable pages or the learning overview. Use calculator inputs, rules and result states when the promised action is a calculation rather than a message.

Keep the final record explicit about what was specified, what was actually tested and what remains unknown. A convincing confirmation design is not evidence that a message was received.