Widget Position and Live Preview

The trigger uses X spacing from the right and Y spacing from the bottom. Default offsets are 35px and 30px, each clamped from 0 to 500px.

The trigger is the floating button that opens the widget. SmartSite positions it by pixel distance from the right and bottom edges, with optional cascading overrides for smaller widths. An override that is disabled inherits the last active values, so a single base setting can cover every device unless a site-specific fixed element creates an overlap.

A reliable setup moves from set default x/y for large screens to the point where you confirm the mobile full-screen chat at 768px and below remains usable. The controls below explain the decisions along that path, including settings that support the conversation without changing the model’s answer directly.

What this feature does and when to use it

Use viewport overrides when the trigger overlaps navigation, consent controls, or other fixed interface elements.

Use this feature in the following situations:

The launcher overlaps a cookie control, bottom navigation, accessibility widget, or another fixed button.
Desktop placement is correct but a tablet or phone needs different edge spacing.
You need to understand which values a disabled responsive card inherits.

Where to find it

WordPress locationWordPress Dashboard → AI Website Chat → Design → Trigger position

Before you begin

SmartSite Assistant is installed and activated.
You are signed in with an account that can manage WordPress options.

Set it up step by step

Set Default X/Y for large screens.
Enable Smaller screens (up to 991px) only if it needs different values.
Optionally enable Tablets (up to 786px) and Mobile (up to 576px).
Understand that a disabled size inherits the previous effective size.
Use the preview for fast iteration.
Save Changes and test at the exact breakpoints plus nearby widths.
Confirm the mobile full-screen chat at 768px and below remains usable.

Fields, controls, and important values

Position settings do not alter the AI’s response, but they determine whether visitors can find and open the assistant without the launcher covering another important control. Breakpoint overrides let the button fit different layouts. The preview is useful for quick comparison, while a real page test is needed because the site theme and fixed elements are not reproduced there.

Fields, controls, and important values
Field, control, or status	What SmartSite Assistant does with it	How to use it and why it matters
Default X — From right	Base horizontal spacing from the right edge. Default 35 pixels; values are clamped to 0–500.	Set the launcher’s normal horizontal distance from the right edge. Increase it when the launcher overlaps a fixed site control; then check that it still remains fully visible on wide and narrow desktop pages.
Default Y — From bottom	Base vertical spacing from the bottom edge. Default 30 pixels; values are clamped to 0–500.	Set the launcher’s normal vertical distance from the bottom edge. Increase it to clear cookie, accessibility, or navigation controls, but verify that the button remains easy to reach without covering page content.
Smaller screens — Enable	Turns on a separate position for viewports up to 991 pixels wide. When off, this range inherits Default.	Turn this on only when pages at 991 pixels or narrower need a different launcher position. When it is off, these screens deliberately inherit the Default offsets, which keeps the configuration simpler.
Smaller screens — X / Y	Right and bottom offsets for the ≤991px range. Each accepts 0–500 pixels and is used only when its override is enabled.	Set right and bottom offsets for the up-to-991-pixel range after enabling that override. Test just below and above 991 pixels so the launcher does not jump into an overlapping position at the breakpoint.
Tablets — Enable	Turns on a separate position for viewports up to 786 pixels wide. When off, this range inherits the previous effective setting.	Turn this on when the inherited desktop or smaller-screen position does not suit layouts at 786 pixels or narrower. When off, tablets use the last effective wider-screen offsets.
Tablets — X / Y	Right and bottom offsets for the ≤786px range. Each accepts 0–500 pixels and is used only when its override is enabled.	Choose the horizontal and vertical spacing used at 786 pixels or narrower once the Tablet override is active. Check portrait and landscape layouts, including fixed bottom navigation.
Mobile — Enable	Turns on a separate trigger position for viewports up to 576 pixels wide. When off, Mobile inherits the previous effective setting.	Turn this on when phones at 576 pixels or narrower need their own launcher location. If it remains off, phones inherit the previous active offsets rather than the values shown in the disabled Mobile fields.
Mobile — X / Y	Right and bottom offsets for the ≤576px range. Each accepts 0–500 pixels and is used only when Mobile is enabled.	Set the phone launcher’s right and bottom offsets after enabling Mobile. Test a 320-pixel-wide viewport and a real phone so the trigger clears safe areas, browser chrome, consent controls, and site navigation.
Live Frontend Preview	Displays design-only sample messages and applies unsaved design changes in the embedded preview; it does not call OpenAI.	Use the embedded preview to compare unsaved positioning and design changes quickly. It shows design-only sample content and does not test OpenAI, permissions, the live page theme, or actual visitor messages.
Reset Preview	Returns the embedded preview to its saved/initial preview state. It is not the documented control for deleting saved Design Settings.	Use this to discard the preview’s temporary visual state and return it to its saved or initial presentation. It is not a factory reset and does not document deletion of the saved Design Settings option.
Save Changes	Saves the design option so WordPress can output the position and visual CSS on permitted public pages.	Use this after checking all enabled breakpoints in the preview. WordPress then stores the design option used to output public CSS; reload a permitted live page to confirm the site theme and caches use it.

How to confirm it is working

The reliable proof for Widget Position and Live Preview 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.

Practical example

Move the mobile trigger upward when a site has a fixed bottom navigation bar.

Recommended practice

Change one part of Widget Position and Live Preview 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.

Important warnings

Common problems and focused checks

Common problems and focused checks
Problem	What to check and what to do next
Widget Position and Live Preview 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 Widget Position and Live Preview 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.

Screen reference

Screenshot capture pending /images/screenshots/appearance/position-preview.webp

Widget Position and Live Preview

Capture: Show Trigger position cards with Default values 35/30, one enabled Mobile override, and inherited values visible for another size.
Show: Default, Smaller screens, Tablets, Mobile, enable switches, X/Y inputs, preview
Viewport: Desktop, 1440 × 900
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