Overview
One dashboard, viewed through different component libraries
UI Lab is a small personal experiment for comparing design systems without changing the product underneath them. Each implementation presents the same fictional operations dashboard, pages, mock data, and workflows so differences in components and visual language are easier to see.
The project currently compares a shadcn/ui baseline with OpenGlass UI. It is a hands-on reference rather than a benchmark, production application, or claim that one library is objectively better.
Approach
Keep behavior shared and presentation separate
Dashboard data, types, filtering, sorting, pagination, and in-memory device changes live outside either design-system implementation. The shadcn and OpenGlass views consume that shared behavior while owning their respective components and styling.
01
Shared dashboard model
Deterministic mock data and TypeScript types describe devices, locations, events, and form workflows without importing a UI library.
02
Reusable interaction state
React hooks own search, filters, sorting, pagination, validation, and temporary add or edit operations.
03
Design-specific views
Separate shadcn and OpenGlass presentations render the same pages and interactions with their own component primitives.
04
Static deployment
Vite builds browser assets that nginx serves from a small container behind Caddy.
What it demonstrates
Enough interface surface to make the comparison useful
Common dashboard patterns
Responsive navigation, KPI summaries, charts, status badges, tables, dropdowns, tabs, dialogs, and toast or alert feedback provide varied component examples.
Interactive tables and forms
Search, filters, sorting, page sizing, pagination, masked inputs, validation, and add or edit flows make the comparison more meaningful than static mockups.
Supporting pages
Device, location, calendar, event-workflow, and form pages exercise dense and detailed layouts beyond the overview screen.
Theme behavior
Light and dark modes expose how each system handles contrast, surfaces, controls, and status colors.
What I explored
A component swap still requires design work
Sharing data and workflows made the comparison repeatable, but the OpenGlass implementation could not be produced by applying a glass effect to the shadcn view. Inputs, dialogs, navigation, badges, menus, and responsive layouts each needed deliberate treatment with the components and visual rules of the selected system.
The experiment also reinforced the value of isolating library-specific CSS. A clear presentation boundary makes another implementation possible without duplicating dashboard behavior or allowing one library's global styles to quietly reshape another view.
Limits and next steps
Keep the project useful without making it larger than the idea
All application data is local and resets on reload. The login screen is only a demonstration, maps use bundled data, and there is no backend, real authentication, database, or monitoring integration.
A future iteration may add another genuine component-library implementation, such as Material UI or Bootstrap, while preserving the same information and workflows. The project will remain a lightweight visual experiment rather than grow into an administration product.