DEV Community

Cover image for Four UI projects, four different jobs for the interface
Harshith Vaddiparthy
Harshith Vaddiparthy

Posted on

Four UI projects, four different jobs for the interface

I’ve brought four of my projects into a UI gallery: an image editor, a content dashboard, a video-workflow canvas and a CRM. Each study includes real application screens, design decisions and links to the implementation.

The gallery itself is open source. It is a small React application you can run locally. The four applications remain in their own repositories, with their own setup instructions and MIT licenses.

These are the decisions I wanted each interface to make easier.

Grain Studio: judge the image while changing it

Grain Studio texture editor with the included sample artwork

An image-effects tool needs a short feedback loop. Grain Studio keeps the image stage, texture dock and material controls in the same workspace. Its before-and-after scrubber lets you compare the effect while you tune it.

Export introduces a different set of decisions: format, dimensions and transparency. I gave those choices a dedicated flow with progress and cancellation states. The source uses Canvas 2D for the preview and a bounded OffscreenCanvas worker on supported browsers for export.

The reusable pattern is to keep comparison close to the adjustment and make output choices explicit at export time.

This capture uses the included sample artwork. The behavior was independently implemented after studying Textures; the dock’s proximity and tactile feedback are informed by ThreeUI Community, with its notice retained.

Inspect the case · Read the implementation

AI Content Dashboard: make content states easy to scan

AI Content Dashboard overview using fictional sample metrics

The working sequence is brief → draft → review → library. The overview helps someone understand the collection; the library provides type and status filters; the editor gives an individual piece a focused working area.

The same content model feeds summary metrics, activity charts and recent-content rows. Reusing type and status labels across these views keeps the navigation predictable. A person can move from an overview count to the actual pieces behind it.

This is built on shadcn/ui, Base UI and the tweakcn Caffeine theme. The screenshots use fictional sample content and illustrative metrics. The source README distinguishes the implemented writing workflow from planned video-rendering and database integrations.

Inspect the case · Read the sample-data model

UGC Genie: show where work is in the process

UGC Genie workflow detail in its credit-free local demo

UGC Genie connects product input, visual analysis, creative direction, generation, rendering and review. React Flow supplies the canvas; the application defines the stages and their state.

The source initializes every step explicitly:

export function createSteps(): WorkflowStep[] {
  return workflowDefinition.map((step) => ({ ...step, status: "pending", progress: 0 }));
}
Enter fullscreen mode Exit fullscreen mode

That gives the interface a clear vocabulary: pending, running, completed and failed. The canvas can show which stage is active while the input and output-review areas remain available alongside it.

The screenshot shows a simulated, credit-free local demo. Its displayed progress describes application stages. The visual foundations include shadcn/Base UI and tweakcn claymorphism; my work is the workflow composition, feedback and review experience.

Inspect the case · Read the stage definition

PulseCRM: bring context to the next action

PulseCRM overview with bundled demo records

Sales work needs the pipeline, a record’s history and a useful next step. PulseCRM brings pipeline health, priority deals, account activity and follow-up work into one navigation system.

I adapted shadcn’s sidebar-07 into the CRM shell. Sales Copilot suggestions remain review-required, so record summaries and follow-up drafts have a clear human review step.

Preparing this case also exposed a small implementation bug: --font-sans referred to itself. I corrected it to the Geist font variable supplied by the layout, rebuilt the application and recaptured the interface. The linked source includes that fix.

These screens use bundled demo records in an isolated environment. The source also includes a separately configured Supabase-backed path.

Inspect the case · Read the captured revision

Explore an interaction in the code

For each study, start with one control and follow it through the implementation:

  1. What decision is the person making?
  2. Which state changes when they act?
  3. What feedback makes that change clear?
  4. How does the screen handle loading, empty and failed states?

The gallery credits the component libraries and visual foundations used in each project. Keep the original copyright, license and third-party notices when reusing the source. Individual applications have their own runtime and provider requirements; the gallery itself needs no API key or database.

Browse the interface studies or run the gallery from GitHub.

Top comments (0)