All posts · VBCS Applications

VBCS Layout Strategies for Enterprise Applications

How to structure page layouts in VBCS applications that remain usable as complexity grows — covering responsive grids, shell patterns, and multi-panel navigation.

Anurag Jangra · January 27, 2026 · 6 min read · ... views

Layout decisions made early in a VBCS project are some of the hardest to change later. Here’s how to structure pages that scale with complexity and remain usable on different screen sizes.

The shell pattern

For any application with more than a handful of screens, use a shell layout: a top-level component (typically a Flow or Shell template) that contains the navigation, header, and a content area where individual pages render.

VBCS’s built-in Shell template implements this pattern. Use it. Building navigation into every page individually is a maintenance problem — changing the nav means touching every page.

Grid vs Flex layout

VBCS uses Oracle JET’s responsive grid system. The core choice:

Grid (oj-flex) — for page-level layout. Use for the main content structure: sidebar + content, header + body, multi-column forms. Grid is predictable and responsive by default.

Flex — for component-level layout within grid cells. Use for aligning buttons, labels with inputs, and horizontal groupings within a section.

Mixing grid and flex inconsistently across pages is the most common cause of visual inconsistency in larger VBCS apps.

Responsive breakpoints

VBCS supports 6 breakpoints (sm, md, lg, xl, 2xl). For enterprise internal tools (primarily desktop usage), focus on lg and xl and verify at md for laptop users. Don’t optimise for mobile unless the app has a genuine mobile use case.

oj-sm-12 oj-lg-6 = full width on small, half width on large
oj-sm-12 oj-lg-4 = full width on small, third on large (3-column grid)

Form layout patterns

Single column — always works, never wrong. Use for short forms or where field labels are long.

Two-column grid — efficient for medium-length forms (10–20 fields). Group related fields together in the same column.

Label-value pairs in table — for read-only detail views. More scannable than a form layout for display-only data.

Tabbed form — for forms with more than 25 fields. Divide into logical tab groups. Don’t use tabs just to hide complexity — they make validation harder.

Panel and drawer patterns

For actions that don’t warrant a full page navigation (quick edits, record previews, filter panels), use drawers or side panels. VBCS’s oj-drawer-layout component handles this. It avoids the context-loss of navigating to a new page for a minor action.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp