Nova Tabs Laravel Package

Product Decisions This Supports

• Whether back-office admin UX deserves investment at all. This package makes a cheap, bounded experiment possible: put tabs on one genuinely overloaded Nova resource (25+ fields on the create/update form), define the success metric before the pilot (form completion time, validation-failure rate, or admin tickets per resource), and let the result decide whether further admin-polish work is justified. The cost of being wrong is a day or two of engineering, not a quarter.

• Roadmap slotting. Treat it as a candidate for an existing admin-polish sprint, not a project. Realistic effort is 1–2 engineering days for a proof of concept, shared conventions, and a regression pass on both create and detail views. That is small enough to fit in a sprint but needs a named owner — see risk acceptance below.

• Build vs. buy vs. defer. This is a tactical convenience layer, not a platform commitment. It is MIT-licensed and purely presentational: no migrations, no schema changes, no data model, no API surface. Rollback is deleting a few lines and a dependency. That reversibility is the core of the argument for saying yes — it is nothing like adopting a package that touches persistence or requires a backfill.

• Use-case fit. Strong fit where Nova is already the sanctioned admin surface and admins currently scroll through long forms. Grouping into task-oriented tabs ("General," "Content," "Relations," "Meta") matches how admins actually think about a record. Weak fit for public-facing UX, permission-aware or heavily conditional workflows, non-Nova admin stacks, or any resource with accessibility obligations we cannot verify are met.

• Buying down support and training cost. Dense forms generate admin tickets and onboarding friction; tabs are a low-cost lever on both. But the lever only works if we manage the one failure pattern tabs introduce: validation errors on required fields sitting in inactive tabs can make a form silently refuse to submit. That is a product requirement of the rollout — required fields in tab one, or a documented triage script — not an afterthought.

• Risk acceptance and ownership. Maturity signals are weak: 9 stars, 0 dependents, a single maintainer, last release November 2023, and Nova's extension APIs shift across majors. The real question is not "does it work today" but "who owns it when Nova ships a major." Adopting means explicitly funding a small amount of ongoing ownership, accepting the MIT fork path, or deferring. A PM should make that call rather than discover it during an upgrade.

• Standardizing admin conventions. Adoption forces a useful product conversation: canonical tab names, what belongs in tab one, where relation fields live, whether detail-only fields get their own "Meta" tab. Answering it once produces consistency across resources; skipping it produces five taxonomies and reintroduces the exact cognitive load the feature was meant to remove.

When to Consider This Package

Adopt when all of the following hold:

• Nova is already the sanctioned admin surface, and one or more resources carry 20–30+ fields on create/update.
• The pain is real and named — admins complain about scrolling, forms get abandoned, or tickets cluster around a specific resource.
• You have one overloaded but non-business-critical resource to pilot on, plus a named engineering owner for the dependency.
• You can pin the version exactly (shuvroroy/nova-tabs:1.1.1) and commit the lock file.
• Your team will commit to a thin internal wrapper (TabsField) so the package is one file away from being swapped or replaced in-house.

Look elsewhere or defer when:

• Nova version is in flux. If a Nova major upgrade is on the near roadmap, the packaged Vue bundle is a gated change, not a routine one. Validate or wait.
• Accessibility is a formal requirement. Keyboard tab navigation and screen-reader semantics are unverified. If a tabbed surface has obligations, test before rollout or leave that resource untabbed.
• Validation-error visibility is unacceptable. If "required field in tab three is empty and the form silently fails" cannot be mitigated by convention, budget a small fork that auto-selects the first tab containing an invalid field on a 422.
• You need nested grouping. Tabs inside Tab is unsupported; Nova's native Panel is the escape hatch inside a tab.
• The admin stack isn't Nova, or the surface is public-facing, or the workflow is dominated by conditional/permission-aware field visibility that would cross tab boundaries.
• Nobody will own it. With 9 stars, 0 dependents, and a single maintainer, an unowned adoption is a future incident, not a feature.

How to Pitch It (Stakeholders)

To executives: We have a low-cost, low-risk lever on back-office productivity: a small MIT-licensed package that groups Nova resource fields into tabs. Scope is one sprint-sized pilot on a single overloaded admin form, with a metric agreed up front. There is no schema change, no data migration, and no API impact — the change is cosmetic at the persistence layer, so it is reversible in an afternoon. The one caveat to accept consciously is maintenance: the package is a single-maintainer project last released in late 2023, so we pin the version, wrap it in a one-file adapter, and assign an owner. That bounds the downside to a contained engineering task, not a platform risk.

To engineering: This is a presentational wrapper around Nova fields — Tabs::make()->withTabs([Tab::make(...)]) — with no persistence, no domain logic, and no config file. Rules we will enforce in review: Tabs is the only top-level element in fields(), tab definitions are extracted into methods, relation fields get their own fullWidth() tab, detail-only fields get onlyOnDetail() inside a "Meta" tab, and tab taxonomy is standardized across resources. Known gotchas: validation errors on required fields in inactive tabs may be invisible (mitigate by convention or a small fork), v1.1.1 fixed a slug/relationship-name collision so we pin at or above it, and Nova major upgrades require regression-testing tabbed resources. Keep the usage inside resource classes so rollback is a config-only change.