Skip to main content

View Mode Verification (Desktop / Mobile)

How to manually verify that a screen behaves correctly in both view modes. This walkthrough is the operational counterpart of the RV-VM-* rubric (repo rule angular-styles.mdc) — see the Platform, Identification & Kiosk Services page for how the mode is detected and published.

The mode is a decision, not a viewport size​

The app has exactly two view modes: desktop and mobile. The mode is decided once, at startup (device detection or a forced override), and does not change by resizing the browser window. If a layout changes when you drag the window edge without reloading, that is a residual CSS breakpoint, not mobile support — see RN-VM-02 / RV-VM-10.

Setting the mode​

#WayPersistsWhen to use it
1?mode=mobile / ?mode=desktop in the URLNoFastest way to alternate while verifying
2Place configuration → Devices → forced modeYes (reload)The operator-facing way
3Real device (automatic detection)—Remember: tablets are classified as desktop

Critical reminder: resizing the window does not change the mode. Use ?mode= (or the Devices tab) to switch, always with a reload.

Preparation​

Most of the rubric needs real data to exercise every branch. Minimum dataset:

  • A place with several tables and open tickets.
  • A catalog with nested categories and products with options.
  • At least one offer/menu.
  • Several waiters; a customer account; cash movements.
  • A month of activity (so report charts render).
  • A floor plan with more than one area.
  • A user account with at least one place (ideally several).
  • Kiosk mode available in Devices.
  • Email result routes at hand: /on-activate, /on-password, /on-mailchng (e.g. ?result=SUCCESS&lang=es).

Universal criteria (every screen)​

  1. Nothing is cut off or unreachable in mobile.
  2. Every action available in desktop exists in mobile, unless the screen's .mdc documents an explicit exclusion (RN-VM-06).
  3. The layout does not change when resizing the window within the same mode.

Walkthrough per screen​

For the screen under test:

  1. Load it with ?mode=desktop (maximized window). Check for console errors (RV-VM-01).
  2. Without reloading, shrink the window to ~500–700 px. The layout must not reflow to a mobile disposition (RV-VM-10). Horizontal scroll is acceptable in this state.
  3. Reload with ?mode=mobile (maximized window). Check for console errors and confirm there is no horizontal document scroll (RV-VM-02).
  4. Walk every interactive control in mobile: nothing is hidden behind the header, the tab bar, or the kiosk keyboard (RV-VM-03).
  5. Compare the actions available in desktop vs. mobile for the same screen (RV-VM-04).
  6. If the screen opens a full-screen panel in mobile, confirm it has a visible close/back action (RV-VM-05).
  7. Fill the screen with enough content to force scrolling: the header, action footer, and tab bar must stay clear of the content, and the action footer must remain reachable (RV-VM-06, RV-VM-07).
  8. Open every dialog/overlay reachable from the screen: bounded panel in desktop, full screen in mobile (RV-VM-08).
  9. With kiosk mode active, focus each field: it must stay visible above the virtual keyboard (RV-VM-09).

Reporting a failure​

FieldExample
Active mode?mode=desktop
Approximate window width~700 px
Screen / areaIncome report
ExpectedKeeps multiple columns
ObservedCollapsed to one column

The width matters: a failure that only appears at a specific width usually means a residual breakpoint.

Short regression walkthrough (shared surfaces)​

Run this subset — instead of the full walkthrough above — whenever a change touches the shell, a upp-wdgt widget, or styles/theme.scss (RN-VM-08). Run each item in both modes unless noted.

#ModeActionExpected
R01/R02BothInspect <body>Has exactly one of mobile / desktop
R03/R04BothLogin screenDesktop: centered, bounded width. Mobile: full width
R05/R06BothPlace pickerDesktop: multi-column grid. Mobile: single column, full width
R07/R08BothShell (menu drawer, tabs)Desktop: fixed-width drawer. Mobile: full-width drawer, no clock
R09BothBottom tabsSame set in both modes; not covered by scroll
R10/R11BothOpen a ticket panelDesktop: bounded side panel. Mobile: full screen with a way back
R12/R13BothProduct grid (cart)auto-fill columns; no empty gap; large touch targets in mobile
R14/R15BothTicket preview (place configuration)Desktop: two columns. Mobile: one column, or documented exclusion
R16/R17BothA reportDesktop: multi-column. Mobile: one column, actions wrap
R20/R21BothShort confirmation dialogDesktop: centered bounded panel. Mobile: near-full-screen
R22MobileA upp-select with many optionsList is scrollable, not clipped to a few rows
R23BothOffline bannerBounded card (~450 px), not full width

For every item above, also confirm the negative check: resizing the window inside the same mode must not change the layout (RV-VM-10).

Known verification gaps​

Some flows require live operator interaction and cannot be fully exercised from a script or from the checklist above in a single pass: kiosk keyboard with a real focused field, cash/card payment dialogs, floor-plan area editing, PDF export/print preview, and creating a ticket end-to-end in mobile. Treat these as normal exploratory testing surfaces going forward rather than a one-off signoff — report anything unexpected as it comes up rather than waiting for a full pass.

See also​