OpenCreators in one minute
- Mobile uses dedicated page components and shell rules for public stores, products, discovery, chat, and building.
- Cards can form a two-column grid, so text size, line height, image crop, and button height need direct testing.
- Direct shared links need a Home fallback when there is no usable back history.
OpenCreators detects a mobile presentation and renders a dedicated mobile route set rather than merely shrinking every desktop component. Public creator pages, product details, Home, Discover, Chats, and the store builder each have mobile-specific layout behavior.
The goal is information parity with an appropriate hierarchy. A mobile visitor should still understand the creator, complete profile description, product title, description, price, and next action without relying on hover or desktop history.
Public store layout
A mobile creator page places navigation, profile identity, and a compact product grid within the viewport width. The selected storefront template controls background and card styling, but the card must preserve readable title, description, price, and action states.
Profile descriptions should show the complete intended copy where specified by the template, with the correct font size, letter spacing, and line height. Removing a character limit also requires checking how the product grid moves below longer content.
Cards and product pages
Two columns make image ratio and text wrapping sensitive. Test the longest product names, 14- and 18-pixel body line heights where the design calls for them, price currency strings, and both light and dark buttons. Loading media surfaces should use the designated loading background rather than the browser default.
On detail pages, use the product type to choose the content source. Game short descriptions belong in the game-specific area; service descriptions remain service content.
Mobile store building
The mobile builder includes direction, currency, planning, products, templates, and username. It can move back from products to currency and from later steps to the prior screen. Selected products and currency remain part of the same working state.
Expandable category details, recommendation loading, sticky Continue actions, image upload, theme preview, and username validation should be tested with the on-screen keyboard and small viewport height.
Navigation without hidden assumptions
A back arrow is correct when a real prior page exists. A person arriving from a shared external link may have no useful OpenCreators history, so the control should lead Home instead. This prevents a dead back action.
Authenticated state also matters. A signed-in user returning from the builder should see Home, not Join for free. Test both states in a clean mobile browser.
Frequently asked questions
Is the mobile site just a scaled desktop page?
No. The application selects dedicated mobile page components and presentation rules for important routes.
Why should direct-link navigation be tested separately?
A shared link can open without a meaningful previous page. In that state, Home is a safer destination than a back arrow with nowhere useful to go.