Skip to content

Desktop and Mobile Chat Experience

The widget uses a launcher and landing screen, supports a maximized desktop conversation, and switches to a full-screen experience at 768px and below.

The public experience changes with viewport size but retains the same conversation identity and server flow. Visitors can open the launcher, choose a suggestion, read Markdown and automatic links, copy an assistant message, move between landing and chat, and reload with locally cached history. At 768 pixels and below, the chat becomes full-screen to use the available touch area.

A reliable setup moves from open a permitted public page at desktop width and launch the widget to the point where you reload to check local/server conversation persistence, then test a separate private session. The controls below explain the decisions along that path, including settings that support the conversation without changing the model’s answer directly.

Use real-device testing to validate visitor behavior that the design preview cannot fully reproduce.

Use this feature in the following situations:

  • You are approving the complete visitor experience after changing content, design, or position.
  • You need to reproduce a problem that occurs only on touch devices or a specific viewport width.
  • You are checking how browser storage and a private session affect conversation continuity.
WordPress locationPublic website page where SmartSite Assistant is visible
  • SmartSite Assistant is installed and activated.
  • You are signed in with an account that can manage WordPress options.
  1. Open a permitted public page at desktop width and launch the widget.
  2. Check landing content, suggestions, channel link, avatar, and disclaimer.
  3. Start a conversation, send a question with Enter/click, and observe responding text.
  4. Test Markdown links and copying an assistant message.
  5. Maximize and return to the landing screen.
  6. Repeat at 768px and 576px widths on a touch device.
  7. Reload to check local/server conversation persistence, then test a separate private session.

These behaviors make the same conversation usable on phones and desktops. Full-screen layout, suggestions, copy controls, and history persistence do not teach the AI anything new, but they influence whether visitors can provide enough detail, keep context, and reuse an answer. Test real touch and keyboard behavior so interface friction is not mistaken for poor AI performance.

Fields, controls, and important values
Field, control, or statusWhat SmartSite Assistant does with itHow to use it and why it matters
Responsive mode Full-screen mobile chat at viewport width 768px or below. At 768 pixels or below, the full-screen layout gives the conversation room for the keyboard, messages, and controls. It changes usability rather than the generated answer, so test rotation, browser chrome, and the smallest supported phone.
Suggestions Clicking a suggestion sends its text through the normal message path. A tap sends the selected suggestion through the same path as a typed question. Useful suggestions can lead visitors toward well-supported topics; an untested one can repeatedly expose a weak answer or trigger an enabled tool.
Message rendering Assistant Markdown is rendered; URLs, email addresses, and phone numbers are auto-linked. Write “Message rendering” for the person or system that consumes it: a visitor, an administrator, or the model. Specific wording can guide better questions or tool selection; vague promises and mixed purposes make expectations—and sometimes responses—less reliable.
Copy Copies assistant message content. The Copy action lets visitors reuse assistant text without changing the conversation or model context. Check that copied Markdown and links remain understandable when pasted somewhere that does not preserve the widget’s visual formatting.
Persistence Browser localStorage holds user_token and chat_messages; server/OpenAI response-chain state also contributes to history. Saved browser messages and server-side response state help a visitor continue a conversation after reopening the widget. That continuity can improve follow-up answers, but stale history may also carry assumptions forward after knowledge or instructions change.
History limit The public messages endpoint returns at most 100 messages for the visitor token. Changing “History limit” only changes the administrator’s view. Keep the selection focused enough to compare similar conversations, and avoid treating a visible pattern as proof until individual rows support it.

The reliable proof for Desktop and Mobile Chat Experience is the observable result described above. Reproduce it with a realistic example; if only the admin screen changed, continue tracing the workflow until the visitor or connected system sees the intended effect.

Use a private browser to verify that a new anonymous visitor does not inherit the normal browser’s conversation.

  • Change one part of Desktop and Mobile Chat Experience at a time and keep a short record of the previous value and test result.
  • Check the public widget with keyboard, touch, light, dark, desktop, and mobile conditions relevant to the site.
Common problems and focused checks
ProblemWhat to check and what to do next
Desktop and Mobile Chat Experience is missing or does not match this guide. Confirm the plugin is active and the account can manage WordPress options. Compare the saved public widget with the preview and account for caching, theme CSS, and viewport width.
A change on Desktop and Mobile Chat Experience does not produce the expected result. Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Compare the saved public widget with the preview and account for caching, theme CSS, and viewport width.
Desktop and Mobile Chat Experience
Capture
Capture the full-screen chat at 390 × 844 with a fictional two-message conversation, input, back control, and disclaimer visible.
Show
Header/back, messages, copy, responding state, input/send, disclaimer
Viewport
Mobile, 390 × 844
Annotate
Use numbered callouts only for controls referenced in the procedure.
Redact
OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text