Distance changes the interface
A dealership system is not always used by one person eighteen inches from a monitor. A manager may review a board from across the office. A salesperson may present options on a showroom TV or Surface Hub. Several people may be looking while only one person controls the screen. At that distance, the assumptions hidden inside mouse-first software become obvious: tiny targets, invisible focus, hover-only explanations, and navigation that requires pixel accuracy.
Building a separate ‘TV mode’ would solve only the most visible symptom. It would create another interface to maintain while leaving keyboard users and non-pointer navigation behind. LotPro’s direction is to make the real application structure navigable, then let density and presentation adapt to the room rather than fork into a demo product.
Focus has to become visible state
A controller does not have a cursor. The application must know which element owns focus, which neighboring element is reachable in each direction, and what should happen when a control disappears or a panel changes. LotPro’s foundation includes browser controller detection, a stored navigation preference, spatial focus management, ownership colors for multiple controllers, and shell-level actions such as opening navigation.
That foundation is intentionally selective. Only controls that declare themselves focusable should enter the spatial map. Otherwise a directional press can land on decorative icons or hidden elements that a mouse user would never encounter. Focus also needs a strong visual treatment that survives light and dark themes and can be understood from presentation distance. The highlight is not decoration; it is the controller’s pointer.
- Detect and describe the connected controller state
- Expose an explicit controller-navigation preference
- Move through a spatial map of eligible controls
- Keep current ownership and focus visible
Controller support should improve every input path
The useful discipline is not limited to gamepads. A screen that exposes semantic controls, predictable order, and visible focus also becomes easier to use with a keyboard and easier for an automation agent to inspect. Large touch targets help a shared display without forcing a sparse desktop layout. Escape and back behavior becomes explicit because there is no mouse pointer to rescue a trapped modal.
Touch and pointer input remain first-class. The controller layer should not steal ordinary key presses, invent inaccessible custom widgets, or make every dense grid behave like a console menu. Instead, each supported surface decides which decisions belong in the focus map and preserves the native behavior of text fields, dialogs, and scrolling regions.
The room-scale result
On a supported page, the person holding the controller should be able to open navigation, move through meaningful actions, see exactly where they are, and make a selection without walking back to the keyboard. The rest of the room can follow because focus is unambiguous. The same page remains useful at a desk; it has not been replaced by a presentation facade.
That matters most when the application is helping a group compare choices. A controller can keep the presenter facing the conversation instead of the laptop. The product benefit is not novelty. It is the ability to operate the same dealership context from the distance and posture the moment requires.
What remains unfinished
Controller and TV operation is an expanding pre-alpha direction, not a claim of universal parity. The diagnostic surface and core focus machinery exist, but module coverage varies. The Quote payment grid still lists controller integration and keyboard-first spatial navigation as explicit follow-up work. Complex editors require more than attaching arrow keys to buttons.
That limitation is why the site describes controller support as a product direction with demonstrable foundations. Preview testing should validate one room-scale workflow at a time, with keyboard and touch regression checks beside it, until the focus model earns broader language. The acceptance test is not whether a button reacts to a gamepad; it is whether someone can complete the real decision without losing focus, context, or another input method.