Nova Pill Filter Laravel Package

Product Decisions This Supports

• Admin/ops tooling investment: Nova-backed internal tools are where support, ops, and finance teams spend their day. A pill filter is a small, visible UX upgrade that shortens the path from "open the resource index" to "see the 12 records I care about" — one click instead of open-dropdown → select → apply.
• Feature scoping for filter ergonomics: Use this as a concrete reference when deciding whether to invest in filter UX at all. Pills are strongest for low-cardinality, mutually-exclusive or frequently-toggled states (status, tier, region, owner, "needs review"), and weaker for high-cardinality or range-based filters. That distinction is a roadmap decision, not just a design one.
• Build vs. buy: The "buy" side is near-free — MIT-licensed, a single small filter class plus a Vue component. The real decision is adopt, fork, or reimplement. Given the maintenance signals, the defensible PM call is usually "fork or reimplement in-house, using this as the starting pattern," which converts an external dependency into ~a day of internal work you control.
• Use cases worth piloting: triage queues in a support admin, moderation backlogs, order/fulfillment state switching, any index view where operators repeatedly toggle between 2–5 states. Also useful as a lightweight "segment" control on reporting screens built on Nova metrics.
• Standardization decision: If multiple Nova resources exist, deciding once on a filter presentation pattern (pills for state, dropdowns for entity lookup, date pickers for ranges) prevents each squad from inventing its own — a small but real consistency win for internal users.

When to Consider This Package

Adopt (or fork) when:

• You are already on Laravel Nova — this package is worthless outside it, and Nova's license cost already gates the audience.
• Your filters are low-cardinality and state-like; pill rendering genuinely beats a dropdown for these.
• You can vendor or fork the code. At 0 stars, 0 dependents, and a last release in June 2023, treat this as unmaintained sample code, not a supported dependency. Pin it, fork it, or copy the pattern; do not assume upstream fixes.
• You need a quick internal demo to validate that filter discoverability is actually a user pain point before funding a larger admin redesign.

Look elsewhere (or build in-house) when:

• You are on Filament, Blade, or a custom SPA admin — the Nova coupling makes this irrelevant.
• You need anything beyond simple toggles: multi-select with AND/OR semantics, date ranges, saved/named filter sets, shareable filtered URLs, or filter combinations that need to persist across sessions. None of that is in scope here.
• You require accessibility guarantees (keyboard nav, ARIA state on toggles) or i18n — a 0-star package is unlikely to have been audited, and pills-as-buttons are a common a11y failure point.
• Your dependency policy requires active maintenance, security review, or a maintainer SLA. This package fails that bar on every signal available.
• You run a large resource index where filter state must be composable and debuggable — a bespoke, well-tested filter component is the better long-term asset.

How to Pitch It (Stakeholders)

To executives: A small, free, MIT-licensed UI component that makes our internal Nova admin faster to use — operators filter records with one click instead of three. The upside is low-cost and immediate; the caveat is that the package itself is effectively unmaintained (no meaningful adoption, last release mid-2023), so I'd recommend we fork it rather than depend on it. That keeps the UX benefit while capping the risk at roughly a day of engineering time and zero ongoing vendor exposure. Framed correctly, this is a cheap experiment in admin usability, not a platform commitment.

To engineering: This is a Nova filter class that renders its options as clickable pill toggles instead of a dropdown. It's tiny, MIT, and does one thing. It has no stars, no dependents, and no release since June 2023 — so please vendor or fork it into our codebase, add a test around the filter's query behavior, and treat the original repo as a reference implementation. Do not add it to composer.json as a live dependency. If we like it, the follow-on conversation is whether pills become our house pattern for state filters across Nova resources — and whether that pattern is worth carrying forward if we ever migrate off Nova.