> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dapta-forms/respondent-experience.md). # What respondents see What a respondent sees when they open your public form: Slides vs one page, the cover, progress styles, keyboard shortcuts, the Back button, validation errors, reveal screens, booking, the ending and This page walks through the public form from the respondent's side, so you know exactly what your visitors experience before you share a link. Everything here is the live behavior of a published form; the screenshots come from two demo forms, one in the **Slides** layout and one in the **One page** layout. *** ## Slides: one question per screen In the **Slides** layout the respondent sees a card with the form title, a progress indicator, one question and its input. Answering moves them to the next step.

A published Slides form showing the form title, a progress bar and a single choice question with four options — Step 1 of a Slides form: title, progress bar and one question. Tapping an option moves on automatically.

How each input advances: | Question type | How the respondent continues | | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Single choice**, **Dropdown** | Tapping an option advances automatically. No button needed. | | **Multiple choice** | Pick several, then press **Next** (or **Enter**). | | **Short text**, **Email**, **Phone**, **Website**, **Slider** | Type or slide, then press **Enter** or the button. | | **Long text** | Press the button (Enter adds a new line). | | **Name** | Two inputs on one screen. **Enter** hops from **First name** to **Last name**, then submits the step. | | **Message** | Text with no input; a **Continue** button moves on. | | **Reveal screen** | Plays for a set time and advances by itself. | | **Scheduler** | The respondent picks a time in the embedded calendar; booking counts as the answer. | The button label is whatever you typed on the canvas (**Next** by default, **Submit** on the last question). *** ## Back button From the second step on, a **Back** arrow appears in the top-left corner of the card. It returns to the previous question with the answer still filled in. On the first question, **Back** returns to the cover screen when the form has one. *** ## Validation errors If the respondent tries to continue without a valid answer, the input is outlined in red and a message appears under it. The form does not move on until the problem is fixed.

An email step with the Back arrow highlighted in the top-left corner and the error This field is required shown under the empty input — The **Back** arrow (top left) and a validation error under the input.

| Message | When it appears | | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **This field is required.** | A required question was left empty. | | **Enter a valid email address.** | The Email question got something that is not an email. | | **Please use your work email address.** | **Require work email** is on and the address is from a personal domain (Gmail, Hotmail, Yahoo and similar). | | **Enter a valid phone number.** | The number is too short for the minimum digits or not a real number for the selected country. | | **Enter a valid website address.** | The Website question could not be read as a URL. (Typing `acme.com` is fine: it becomes `https://acme.com` on blur.) | | **Enter a number.** / **Value is too low.** / **Value is too high.** | Slider or numeric input outside its range. | | **Choose one of the available options.** | A choice or dropdown value is not one of the options. | | **Could not submit. Please try again.** | The final submission did not reach the server. The answers stay on screen so the respondent can retry. | | **Upload a file to continue.** | A required **File upload** question has no file yet. | *** ## Attaching a file A **File upload** question shows an upload area reading **Choose a file**, with the accepted types and the size limit on the line below. Respondents click it to pick a file, watch **Uploading 42%**, and end up with the file's name and a **Remove** link. One file per question. A file that breaks a rule never uploads: the message sits under the control with a **Try again** link, and the respondent stays on the question. See [File upload](/dapta-forms/builder/question-types/file-upload.md). *** ## One page: every question on one screen In the **One page** layout the respondent sees all questions at once and one **Submit** button at the bottom. Logic still runs live, so questions appear and disappear as answers change.

A one-page form with the cover rendered as a header (eyebrow, headline, subheadline) and the counter 0 of 3 answered in the top-right corner — A one-page form. The cover becomes a header at the top and the progress reads **0 of 3 answered**.

* **Cover:** when the form has a cover screen, it renders as a hero header at the top (eyebrow, badge, headline, subheadline). There is no **Start** button; the questions follow immediately. * **Progress:** the top bar shows **{answered} of {total} answered** and fills as the respondent answers. * **Submit** validates every question at once. Invalid ones are outlined in red with their own message, the page scrolls to the first problem, and a summary reads **Check the highlighted questions above.**

A one-page form after pressing Submit with empty fields: each field shows This field is required and a summary reads Check the highlighted questions above — Submitting a one-page form with empty required questions: every field gets its own error plus a summary above **Submit**.

*** ## Cover screen In the **Slides** layout, a form with **Show a cover screen** on starts with an intro screen: optional banner, eyebrow, badge, headline, subheadline, a **Start** button (you choose its text), an optional trust line and, if you added client logos, a "trusted by" marquee. The cover is off on new forms; turn it on in **Design → Cover screen**. In the **One page** layout the same content renders as the header shown above. ## Progress styles You choose how progress is shown in **Design → Shape and controls → Progress**: | Style | What the respondent sees | | ----------- | ---------------------------------------------------------------------------- | | **Bar** | A thin bar under the title that fills step by step (the default). | | **Dots** | One dot per step, the current one highlighted. | | **Counter** | The text **Step 2 of 3**. | | **Hidden** | Nothing visible (a progress indicator is still announced to screen readers). | Progress is computed over visible steps only: questions hidden by logic or by a hidden-field setting do not count, so the count never jumps unexpectedly. *** ## Reveal screens A **Reveal screen** is a short, timed interstitial: a loader, a headline and a subtitle, playing for the duration you set (2.2 seconds by default) before advancing on its own. Use it to build a pause before a result, a booking step or the ending. In the Slides layout it is a step you drop anywhere in the question list; in the One page layout it plays once after **Submit** when **Reveal screen before results** is on.

A reveal screen with a spinner, the headline Reviewing your answers and the subtitle One moment while we match you with the best next step — The default reveal screen. Headline, subtitle, loader style and duration are all editable.

*** ## Booking step When your form includes a **Scheduler** question (connected to Calendly in **Integrations**), the respondent sees **Pick a time** and the embedded calendar for the event type you chose. Answers from earlier questions (name, email and any mapped fields) are filled in for them. While the calendar loads they see **Loading the calendar…**; if the embed cannot load there is an **Open the scheduling page** link, and you can allow **Skip for now**. Once a time is booked, the form continues, submits, or jumps to a later step depending on the **After booking** setting. Booking details are stored with the submission. *** ## Ending and redirect After the last step (and any reveal or booking), the respondent sees the ending screen: a check mark, a heading and a message. By default they read **Thank you!** and **Your answers were recorded.**; you can replace them in **Design → When the form ends** and insert answers with `[field]` placeholders (for example `Thanks, [firstname]!`). Outcomes (score ranges) can override the heading, message and redirect for the people who land in them.

The ending screen with a check mark, the heading Thanks, Grace! and the message Your answers were recorded — An ending with a personalized heading. The name comes from the respondent's own answer.

If you set a **Redirect URL**, the respondent is sent there either immediately or after the delay you set in **Show the thank-you first (ms)**. When the form includes a booking, the redirect only happens after the booking is made, so nobody is pulled away from the calendar. > **💡 Tip:** Refreshing the ending screen does not create a second submission. One submission is kept per form and browser tab. *** ## Mobile Public forms are built mobile-first: one column, large 44 px tap targets, a sticky progress bar and the same keyboard behavior. There is nothing extra to configure. The **Preview** in the editor lets you check any step on **Mobile**, **Tablet** and **Desktop** before you publish.

The Slides form on a phone screen: title, progress bar and four stacked options — The Slides layout on a phone.

The one-page form on a phone screen with the cover header, the counter 0 of 3 answered and the first questions — The One page layout on a phone: cover header, counter, then every question.

*** ## Language auto-detect The form's chrome (buttons such as **Next** and **Submit**, error messages, the default reveal and ending copy) follows the visitor's browser language: Spanish browsers see Spanish, everyone else sees English. You can force a language by adding `?lang=es` or `?lang=en` to the link. Your own question text is shown exactly as you wrote it, so write the questions in the language of your audience.

The same email step with Spanish chrome: the error Este campo es obligatorio and the button Siguiente — The same form opened with `?lang=es`: the button reads **Siguiente** and the error is in Spanish. The question itself stays as written.

*** ## Prefilled answers and campaign data If the link carries a parameter that matches a field key (for example `?email=ana@acme.com`), that question arrives already filled in; hidden questions are answered silently from the URL. Any `utm_*` parameters are captured separately as campaign data on the submission. See [Hidden fields & URL prefill](/dapta-forms/builder/hidden-fields-and-url-prefill.md). ## Privacy A public form makes no third-party requests unless you add tracking IDs in **Connect → Tracking & pixels**, and it stores answers, score, timestamps and UTMs only: no IP address, device or location. ## No resume after closing the tab A respondent's session lives in the browser tab. Refreshing the page keeps the same session (a partial submission is updated in place rather than duplicated), but the typed answers are not restored: the form starts again from the first step. Closing the tab and opening the link later is a brand new session. If you want to keep what people typed before they finish, add a **Partial submit point** so the answers are saved as they go. ## What's next * [Cover screen & banner](/dapta-forms/design/cover-screen-and-banner.md) * [Reveal screens](/dapta-forms/logic/reveal-screens.md) and [Ending screen](/dapta-forms/logic/ending-screen.md) * [Scheduler step & Calendly](/dapta-forms/connect/scheduler-and-calendly.md) * [Partial submissions](/dapta-forms/builder/partial-submissions.md) * [One-page layout](/dapta-forms/builder/one-page-layout.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.dapta.ai/dapta-forms/respondent-experience.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.