Configuring groov View for Stand-Alone Kiosk Navigation

James Nishida5 min read
HMI ProgrammingOther ManufacturerTutorial / How-to
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

groov View exposes three fixed kiosk behaviors that must be included in the commissioning plan: the caption bar stays visible above every page, Events opens on Current Status, and the Switch user menu item remains available because the project always contains an Admin user. Page graphics cannot override these interface elements. Treat them as navigation boundaries and build the operator and service workflows around them.

Project access plan

Before anything else, confirm who operates the stand-alone unit and who needs administrative access. Separate the everyday kiosk workflow from the service workflow before laying out pages or writing operating instructions.

  1. Assign normal operation to the kiosk user workflow.
  2. Reserve the Admin account for project administration and service access.
  3. Document that service personnel enter through Menu and Switch user when administrative access is required.
  4. Keep administrator credentials under the customer's credential-control procedure rather than displaying them on an operator page.
User path Intended purpose Commissioning decision
Kiosk workflow Normal unit operation Build pages for routine tasks without relying on caption-bar customization
Admin workflow Administration and service work Retain a controlled handoff procedure for authorized personnel

Do not move on until a tester can identify which workflow applies without treating Switch user as an operator function.

Caption-bar layout boundary

The caption bar cannot be removed, disabled, or hidden. A same-color rectangular gadget on a View page cannot cover any part of it. The page renders beneath the bar, while the bar renders at a higher Z-index and therefore remains on top. Scrolling or positioning page content toward the bar does not change that stacking order.

  1. Open the target page at the display size and orientation used by the stand-alone unit.
  2. Identify the lower edge of the caption bar as the top boundary for application graphics.
  3. Place controls, status indicators, instructions, and touch targets fully inside the page area below that boundary.
  4. Remove any decorative rectangle intended to mask the caption bar. It cannot conceal the higher-layer interface and may instead create a misleading visual edge.
  5. Exercise page scrolling, if the page uses it, and watch the boundary throughout the movement.

This is a rendering constraint, not a color-matching problem. No page-level gadget can move ahead of the caption bar in the display stack. Confirm the page at runtime: every application control must remain usable while the complete caption bar stays visible above it.

Events opening behavior

Selecting Events opens Current Status; Message Logs cannot be configured as the default view. This matters when project events are useful to View pages but are not meaningful to the end user.

  1. Open Events using the kiosk workflow.
  2. Confirm that Current Status appears first.
  3. Select Message Logs when historical messages are the required destination.
  4. Add that navigation step to the operator or service procedure instead of describing Message Logs as the opening screen.
  5. Review the event names and messages that an operator can encounter. Use application terminology that makes sense at the unit rather than internal engineering shorthand.
Events choice Observed role Configuration limit
Current Status Opening view for Events Remains the default
Message Logs Message-history destination Cannot become the default opening view

Do not move on until a first-time tester can open Events, recognize Current Status, and reach Message Logs using the documented path.

Kiosk menu and user switching

The Switch user entry cannot be removed from the kiosk menu on the basis that no other routine operator accounts exist. Every project retains an Admin user, so another user is available for switching even when the deployment has only one everyday kiosk identity.

  1. Open Menu while operating as the kiosk user.
  2. Confirm that Switch user is present.
  3. Test the handoff procedure intended for an authorized service technician who needs administrative access.
  4. Return the unit to the kiosk workflow after the service check.
  5. Write the customer instruction so that Switch user is identified as a service-access path, not as a fault or unused option.

Do not promise customers that this item can be disabled. Its presence follows from the permanent Admin account, not from the number of additional operator accounts created for the unit. Confirm that the service procedure reaches the intended administrative workflow and then returns the display to normal kiosk operation.

Operator-facing navigation controls

Because the fixed caption bar, Events landing view, and user-switching entry remain exposed, commissioning must control interpretation rather than visibility. This is especially relevant for shipped units where the operator may not have immediate access to the integrator.

  1. Keep routine controls on the application page and away from the caption-bar boundary.
  2. Use concise page labels that distinguish normal operation from service functions.
  3. Document Events as a two-stage path when the required destination is Message Logs.
  4. Document Switch user as restricted to authorized service or administrative work.
  5. Test instructions with the kiosk identity rather than an administrator session; otherwise the review does not represent the delivered operating state.

A visible menu item is not removed by omitting it from training. The operating procedure must state what it does, who uses it, and how the unit returns to the kiosk workflow. Confirm that a tester following only the delivered instructions can complete normal operation without entering the service path.

End-to-end commissioning verification

  1. Start the unit in the intended kiosk workflow and confirm that the caption bar is visible.
  2. Open every application page and exercise any scrolling. Confirm that no control depends on covering or rendering above the caption bar.
  3. Open Events and confirm that Current Status appears first.
  4. Navigate to Message Logs using the documented operator or service instruction.
  5. Open Menu and confirm that Switch user remains present.
  6. Perform the authorized service handoff to the Admin workflow, then restore the kiosk workflow.
  7. Repeat the sequence using only the material supplied with the unit. Record a failure if any step depends on a hidden caption bar, a different Events default, or removal of Switch user.

Acceptance requires the delivered workflow to operate with all three fixed interface behaviors present.

FAQ

Can I hide the groov View caption bar with a rectangle?

No. Page gadgets render beneath the caption bar, which has the higher Z-index and remains visible even when page content is scrolled or positioned behind it.

Can I disable the groov View caption bar in kiosk operation?

No. The caption bar cannot be removed, disabled, or hidden. Lay out every control below its runtime boundary.

Can I make Message Logs open first in groov View Events?

No. Events opens on Current Status; the user must then select Message Logs.

Does Switch user disappear when there is only one kiosk user?

No. The project always contains an Admin user, so Switch user remains available from Menu.

Can I verify the kiosk before shipping the unit?

Yes. Run the delivered kiosk identity through every page, open Events and then Message Logs, confirm Switch user, test the authorized Admin handoff, and finish by restoring the kiosk workflow.

Back to blog