Coder Legion - Recent posts tagged ui

Kavro.Pro Stop writing your UI by hand.

Mon, 19 Oct 2026 21:28:35 +0000

Design Dear ImGui menus visually, then build a real .exe

Kavro is a drag-and-drop designer for Dear ImGui windows, tool menus and launchers. Stop nudging SetCursorPos values and recompiling: drop widgets on a canvas, style them, test the window, and export clean code in C++, C# or Rust.

What you can do

Drag & drop 23 widgets: text, buttons, checkboxes, switches, sliders,
dropdowns, color pickers, hotkeys, tabs, lists, progress bars,
spinners and more
Themes & styles: one-click presets (Kavro Dark,
Midnight Violet, Ocean, Sakura, Ember…) or per-widget colors, fonts
and rounding
13 animated backgrounds and 12 built-in actions (switch
pages, toasts, loading screens…)
Test mode (F6): use your window right inside the editor
Live code: your UI is plain kv::Button(...) /
kv::Slider(...) calls. Edit the code and the canvas updates, or the
other way round
Build & Run (F5): compiles a native Windows .exe in
seconds C++: Dear ImGui + DX11/Vulkan/DX9/DX12/OpenGL (MSVC) Rust: imgui-rs + glium
(Cargo) C#: ImGui.NET + Silk.NET (.NET 8)
Kavro AI tab: describe a
change and let the AI edit your menu

Free and Pro

Free: design and test everything.
Pro ($10/month or $108/year): Build & Run, source export, all languages, all templates and the AI tab.
Get Pro at https://kavro.pro

Requirements

Windows 10 or 11 (64-bit)
A free kavro.pro account (you sign in when Kavro starts)
To build: Visual Studio with the C++ workload (C++), Rust/Cargo (Rust) or the .NET 8 SDK (C#)

Designing overlapped / cascaded UI with overlapui

Tue, 06 Oct 2026 09:44:22 +0000

Build avatar stacks, notification piles, image strips, and radial menus with a token-driven CSS architecture—rest vs open states, no JavaScript for the interaction—using the overlapui FSCSS module.

Reference: overlapui.fscss

Stacked faces in a members column, cards that peek under each other, photos that share one edge, or a center control that fans into actions: that look is usually a pile of one-off rules. overlapui treats it as a small architecture—shared --ou-* tokens, four cascade patterns, hover and focus-within open states—and compiles to plain CSS.

This article is description- and code-based: how the layers fit, with copy-paste examples. The only project reference is the module itself.

What “cascaded UI” means here

A cascade has two densities:

Rest — children share space (negative margin, peek, or stacked under a hub).
Open — :hover or :focus-within restores gap, full card height, or a radial orbit.

Tokens describe density and chrome. Mixins encode the rest/open contract. Markup stays light lists, card roots, or a center-plus-satellites control.

Pattern	Rest	Open
Avatar	horizontal pull-in	sibling gap
Card	vertical peek	expanded margins
Image	overlap + tilt	align + gap
Circle	satellites hidden under center	polar fan-out

Setup

Use FSCSS 1.2.3+ (1.2.5+ recommended). Load the runtime with defer or async when prototyping.

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.5/runtime.min.js" defer></script>

@import((*) from overlapui)

@ou-root()
@avatar-overlap(.avatar-overlap)
@card-overlap(.card-overlap)
@img-overlap(.img-overlap)
@circle-overlap(.circle-overlap)
@ou-reduced-motion()

One-shot install (default class names):

@import((*) from overlapui)
@overlapui()

Selective import:

@import((ou-root, ou-avatar-colors avatar-overlap, circle-overlap, ou-reduced-motion) from overlapui)

@ou-root()
@avatar-overlap(.team)
@circle-overlap(.fab)
@ou-reduced-motion()

Layer 1 — tokens (`--ou-*`)

Theme the product by overriding tokens after @ou-root(), not by forking mixin internals.

@ou-root()

:root {
  --ou-ring: #0f172a;
  --ou-time: 0.35s;
  --ou-ease: cubic-bezier(0.3, 1.3, 0.5, 1);
  --ou-center-bg: #6366f1;

  @ou-avatar-size(44px, -14px)
  @ou-card-size(34px, 76px)
  @ou-img-size(96px, -52px)
  @ou-circle-size(48px, 80px)
}

Token area	Variables (examples)
Motion / chrome	`--ou-time`, `--ou-ease`, `--ou-ring`, `--ou-ring-width`
Avatar	`--ou-size`, `--ou-overlap`, `--ou-gap`, `--ou-c`, `--ou-letter`
Card	`--ou-peek`, `--ou-card-h`, `--ou-card-gap`, `--ou-card-bg`, `--ou-card-title`
Image	`--ou-img`, `--ou-img-overlap`, `--ou-img-gap`, `--ou-img-tilt`
Circle	`--ou-item`, `--ou-r`, `--ou-center-bg`, `--n`

Dense UI (tables, toolbars): smaller size, stronger overlap.

:root {
  @ou-avatar-size(28px, -10px)
}

Layer 2 — avatar cascade

Role: presence clusters—members, assignees, “also on this thread.”

<ul class="avatar-overlap" tabindex="0">
  <li data-alph="g">Gina Park</li>
  <li data-alph="h">
    <img src="https://i.pravatar.cc/80?img=12" alt="">
    Hank Lee
  </li>
  <li data-alph="5">5001</li>
</ul>

@ou-root()
@avatar-overlap(.avatar-overlap)

Behavior encoded by the module:

Rest: each face after the first uses margin-left: var(--ou-overlap).
Open: li + li uses var(--ou-gap).
Letter from data-alph via ::before; font-size: 0 on the face keeps names in the DOM for assistive tech.
Optional img covers the letter; letter remains fallback.
A–Z / 0–9 map to a palette through FSCSS arrays at compile time.

Custom selector:

@avatar-overlap(.members)

<ul class="members" tabindex="0">
  <li data-alph="a">Ada</li>
  <li data-alph="n">Nia</li>
</ul>

Layer 3 — card cascade

Role: notification piles, activity stacks, ticket previews without a drawer component.

<div class="card-overlap" tabindex="0">
  <div>
    <img src="https://picsum.photos/96?random=1" alt="">
    <h3>Invoice paid</h3>
    Acme Corp · $2,400
  </div>
  <div>
    <img src="https://picsum.photos/96?random=2" alt="">
    <h3>Seat added</h3>
    workspace update
  </div>
  <div>
    <img src="https://picsum.photos/96?random=3" alt="">
    <h3>Comment</h3>
    “Ship the cascade”
  </div>
</div>

@card-overlap(.card-overlap)

:root {
  --ou-peek: 34px;
  --ou-card-h: 76px;
  --ou-card-gap: 10px;
  --ou-card-bg: #1f2a48;
  --ou-card-title: #fff;
}

Rest uses a negative top margin derived from peek and card height so only a band of each card shows. Open restores var(--ou-card-gap) between siblings. Prefer animating margin/transform over toggling display.

Layer 4 — image cascade

Role: editorial strips, gallery teasers, “recent media.”

<div class="img-overlap" tabindex="0">
  <img src="https://picsum.photos/120?random=4" alt="">
  <img src="https://picsum.photos/120?random=5" alt="">
  <img src="https://picsum.photos/120?random=6" alt="">
</div>

@img-overlap(.img-overlap)

:root {
  @ou-img-size(96px, -48px)
  --ou-img-tilt: -5deg;
  --ou-img-tilt-even: 4deg;
}

Rest: overlap plus alternating tilt. Open: rotate(0) and gap between images.

Layer 5 — circle cascade

Role: settings hub, FAB-style actions, compact toolbars.

<div class="circle-overlap" style="--n:5" tabindex="0">
  <button type="button" aria-label="Settings menu">+</button>
  <a href="#profile" aria-label="Profile">P</a>
  <a href="#billing" aria-label="Billing">B</a>
  <a href="#team" aria-label="Team">T</a>
  <a href="#api" aria-label="API keys">K</a>
  <a href="#logout" aria-label="Sign out">×</a>
</div>

@circle-overlap(.circle-overlap)

:root {
  @ou-circle-size(48px, 80px)
  --ou-center-bg: #6366f1;
}

Rules of the pattern:

First child is the center control (background --ou-center-bg).
--n is the number of satellites (exclude the center).
Satellites sit under the center at rest (opacity: 0, scaled down), then fan with angle 360deg / var(--n) * var(--i).
Built-in --i / --c defaults apply per :nth-child; override --c when needed.

Topbar-friendly footprint:

.settings-wrap {
  position: relative;
  width: 40px;
  height: 40px;
  display: flex;
  align-items: center;
  justify-content: center;
}

.settings-orbit {
  --n: 5;
  --ou-item: 40px;
  --ou-r: 70px;
  margin: 0;
  width: var(--ou-item);
  height: var(--ou-item);
}

<div class="settings-wrap">
  <div class="settings-orbit circle-overlap" style="--n:5" tabindex="0">
    <button type="button" aria-label="Settings">+</button>
    <a href="#profile" aria-label="Profile">P</a>
    <a href="#billing" aria-label="Billing">B</a>
    <a href="#team" aria-label="Team">T</a>
    <a href="#api" aria-label="API">K</a>
    <a href="#out" aria-label="Sign out">×</a>
  </div>
</div>

Minimal full page (all four patterns)

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>overlapui cascades</title>
  <script src="https://cdn.jsdelivr.net/npm/fscss@1.2.5/runtime.min.js" defer></script>
  <style>
    @import((*) from overlapui)

    @ou-root()
    @avatar-overlap(.avatar-overlap)
    @card-overlap(.card-overlap)
    @img-overlap(.img-overlap)
    @circle-overlap(.circle-overlap)
    @ou-reduced-motion()

    :root {
      --ou-ring: #0f172a;
      --ou-center-bg: #6366f1;
      @ou-avatar-size(44px, -14px)
      @ou-circle-size(48px, 80px)
    }

    body {
      margin: 0;
      min-height: 100vh;
      display: grid;
      gap: 48px;
      place-content: center;
      padding: 32px 16px;
      background: #0b1220;
      font-family: system-ui, sans-serif;
      color: #e2e8f0;
    }
  </style>
</head>
<body>
  <ul class="avatar-overlap" tabindex="0">
    <li data-alph="g">G</li>
    <li data-alph="h">H</li>
    <li data-alph="i">I</li>
    <li data-alph="j">J</li>
  </ul>

  <div class="card-overlap" tabindex="0">
    <div>
      <img src="https://picsum.photos/96?random=1" alt="">
      <h3>Title</h3>
      subtitle
    </div>
    <div>
      <img src="https://picsum.photos/96?random=2" alt="">
      <h3>Title</h3>
      subtitle
    </div>
  </div>

  <div class="img-overlap" tabindex="0">
    <img src="https://picsum.photos/96?random=4" alt="">
    <img src="https://picsum.photos/96?random=5" alt="">
    <img src="https://picsum.photos/96?random=6" alt="">
  </div>

  <div class="circle-overlap" style="--n:4" tabindex="0">
    <button type="button" aria-label="Menu">+</button>
    <a href="#a" aria-label="A">A</a>
    <a href="#b" aria-label="B">B</a>
    <a href="#c" aria-label="C">C</a>
    <a href="#d" aria-label="D">D</a>
  </div>
</body>
</html>

Responsive behavior (tokens, not new markup)

Scale density at breakpoints:

@media (max-width: 520px) {
  :root {
    @ou-avatar-size(36px, -11px)
    @ou-img-size(72px, -36px)
    @ou-circle-size(40px, 64px)
  }
}

Keep horizontal stacks from breaking the page:

body { overflow-x: hidden; }

.center-block {
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
  max-width: 100%;
}

Accessibility (part of the contract)

Keep real labels or names in the DOM for avatars; faces may hide the decorative letter with font-size: 0.
Put aria-label on the circle center and on each satellite control.
Add tabindex="0" on stack roots so :focus-within matches hover.
Call @ou-reduced-motion() so transitions drop out when the user prefers reduced motion.

How the pieces fit (checklist)

Choose a cascade: avatar, card, image, or circle.
Set density with --ou-* / size helpers.
Mark the stack root for keyboard open when needed.
Theme only through tokens.
Compile with FSCSS or use the runtime; the browser runs CSS.

Overlapped UI is a rest/open contract plus a token layer. overlapui is that contract as an FSCSS module.

Reference

overlapui.fscss — module source, mixins, and tokens

Guys I need your feedback for logo

Tue, 29 Sep 2026 11:45:22 +0000

Hey guys ;)
This post is a bit unusual, but I really need your help and opinion. So right now I’m working on a new logo for Aster. And I really need to know is it good? And if it isn’t, then what’s wrong with it? I'll be glad to hear from all of you, thanks.
Here it is

More about idea of logo and other I'll tell in next post. So, yep bye bye and thanks for all of you.
Oops, here is second version of logo. So, which is better?

Smart multifacet filters in JS using Bitmaps

Wed, 10 Jun 2026 09:18:41 +0000

Introduction

Modern frontend applications are starting to look less like simple view layers and more like small databases running directly in the browser.

Think about an e-commerce catalog, an analytics dashboard, or an admin panel. In all of these cases, the UI isn’t just rendering data—it’s constantly slicing it, recombining it, and reacting to user input in real time. Filtering becomes one of the most common operations, and the most natural way to express it in JavaScript is still the familiar chain of Array.filter() calls:

const filtered = products  
 .filter(p => p.category === selectedCategory)  
 .filter(p => p.inStock)  
 .filter(p => p.price < maxPrice);

It reads well and does exactly what you expect: take a list, narrow it down step by step. For small datasets, there’s nothing wrong with this approach. The problem starts when the data grows or when filtering becomes part of a tight interaction loop—every checkbox toggle, every slider movement, every keystroke.

The point is that filters are rarely applied once: they are run over and over again, often across tens or hundreds of thousands of items, and each step in that chain quietly walks the entire array again.

This is not a new problem on the backend: databases ran into it decades ago and solved it with a different mental model by replacing scanning records with precomputed indexes, turning the filtering into fast set operations. One of the most effective techniques they use is bitmap indexing, where filters become simple bitwise combinations rather than repeated object traversal.

In this article, we’ll bring that idea into JavaScript and see what happens when you treat your frontend data layer a bit more like a database engine. You can find the fully working code on the GitHub repository. The interactive example on the repository contains a time comparison of traditional array filtering and the techniques described here.

The core idea behind bitmap indexes

Bitmap indexes work by precomputing binary representations for attributes.

Imagine this dataset:

Product	Red	Blue	Size M	In Stock	Description
P1	1	0	1	1	P1 is Red, Size M and in stock
P2	0	1	1	0	P2 is Blue, Size M and is not in stock
P3	1	0	0	1	P3 is Red, and is in stock
P4	1	0	1	0	P4 is Red, Size M and is not in stock

Each attribute becomes a bitmap:

red      = 1000  
blue     = 0100  
sizeM    = 0010  
inStock  = 0001

Filtering becomes a bitwise operation:

red AND sizeM AND inStock

1000  
0010  
0001  
----  
1011

Only the first product matches all filters.

Instead of repeatedly scanning arrays, we combine compact binary structures using highly optimized CPU operations.

This is one of the reasons bitmap indexes are widely used in analytical databases and search engines.

Example of use

Generating a realistic dataset

The demo starts by constructing a synthetic—but stable—product catalog. Instead of hardcoding data or relying on an API, the implementation uses a seeded pseudo-random generator to ensure reproducibility across page loads:

let _seed = 42;

function rng() {  
 _seed = (_seed * 9301 + 49297) % 233280;  
 return _seed / 233280;  
}

This small detail matters more than it seems. Because the dataset is deterministic, performance comparisons between runs are consistent—something you don’t get with Math.random().

The dataset itself is built via Array.from, producing 10,000 products (you can vary this by modifying the PRODUCT_COUNT constant) with attributes like color, size, inStock, and price:

const products = Array.from({ length: PRODUCT\_COUNT }, (\_, i) \=\> ({  
 id:      i,  
 name:    `${pick(ADJS)} ${pick(NOUNS)}`,  
 color:   pick(COLORS),  
 size:    pick(SIZES),  
 inStock: rng() > 0.38,  
 price:   Math.floor(rng() * 90) + 9,  
}));

Each product is intentionally simple and categorical. That’s not a limitation—it’s exactly what makes this dataset ideal for bitmap indexing. Faceted search systems (like e-commerce filters) are dominated by discrete attributes, and this structure mirrors that reality.

From `Array.filter` to bitmap filtering

At a glance, the traditional approach uses chained Array.filter calls:

let arr = products;  
if (colors.length > 0) arr = arr.filter(p => colors.includes(p.color));  
if (sizes.length > 0) arr = arr.filter(p => sizes.includes(p.size));  
if (inStockOnly) arr = arr.filter(p => p.inStock);

This is intuitive and expressive: each filter step narrows down the dataset. But under the hood, it repeatedly scans the array—O(n) per filter—leading to cumulative cost as filters stack.

The bitmap approach flips the perspective entirely. Instead of filtering objects, it filters indices using precomputed bitsets.

First, we build indexes:

const idx = {  
 color: Object.fromEntries(COLORS.map(c => [c, new FastBitSet()])),  
 size: Object.fromEntries(SIZES.map(s => [s, new FastBitSet()])),  
 inStock: new FastBitSet(),  
};

products.forEach((p, i) => {  
 idx.color[p.color].add(i);  
 idx.size[p.size].add(i);  
 if (p.inStock) idx.inStock.add(i);  
});

Each bitset represents a subset of product indices. For example:

idx.color.red → all indices of red products
idx.size.M → all medium-sized products
idx.inStock → all available products

This transforms filtering into set algebra.

The core logic starts from a “universe” of all indices and then refines it by applying intersection and union operations:

let result = universe.clone();

Then applies constraints using bitwise operations. In the following code, we map the logical “or” operator by using the .union operation:

const colorSet = new FastBitSet();  
colors.forEach(c => colorSet.union(idx.color[c]));

This corresponds to:

color = red OR blue OR green

In the same way multiple selections within the same facet are merged via union, we map the logical “and” operator by using the .intersection operation:

result.intersection(colorSet);

This corresponds to:

(color condition) AND (size condition) AND (stock condition)

Each additional filter reduces the result set via intersection.

Putting it together:

if (sizes.length \> 0\) {  
 const sizeSet = new FastBitSet();  
 sizes.forEach(s => sizeSet.union(idx.size[s]));  
 result.intersection(sizeSet);  
}

if (inStockOnly) {  
 result.intersection(idx.inStock);  
}

Conceptually, this translates the array pipeline:

products  
 .filter(color condition)  
 .filter(size condition)  
 .filter(stock condition)

into:

universe  
 ∩ (color.red ∪ color.blue)  
 ∩ (size.M ∪ size.L)  
 ∩ inStock

The key shift is that instead of iterating over objects repeatedly (this happens with the filter function on arrays), we manipulate compact bitmaps where each operation is vectorized and CPU-efficient.

Finally, the matching indices are materialized:

const matchedIds = result.array();

and mapped back to actual product objects only at the end:

matchedIds.map(i => products[i])

This last operation maps the remaining matchedIds to the products to update the UI, and that is another subtle but important optimization by pushing back this operation just on the final set of matched identifiers.

Production considerations

In production, bitmap-based filtering is typically implemented as an index-first strategy: instead of repeatedly scanning objects, you precompute compact index structures and combine them efficiently at query time. On the server, this pattern is often handled by specialized libraries or search engines—using structures like compressed bitmaps (e.g., RoaringBitmap) that allow fast unions and intersections at scale, even across millions of records. On the client, the same idea can be applied to moderate in-memory datasets to deliver instant, zero-latency filtering for common facets, while delegating heavier or high-cardinality queries back to the backend. The main tradeoffs to manage are index maintenance (keeping bitmaps in sync with data updates) and memory usage, but when filters are frequent and latency matters, this approach provides a significant and predictable performance advantage.

Conclusion

Bitmap indexes are a good example of how ideas traditionally associated with database engines are increasingly relevant in frontend engineering.

Instead of repeatedly scanning arrays of objects, we can transform filtering operations into compact bitwise computations that scale much more efficiently as datasets grow.

For small applications, standard filtering techniques are usually simpler and perfectly sufficient. But for large client-side datasets, analytics dashboards, faceted search interfaces, and local-first applications, bitmap indexes can dramatically improve responsiveness while keeping implementation complexity relatively manageable.

Modern frontend applications increasingly resemble miniature data systems running directly in the browser. Techniques like bitmap indexing show that many optimizations once reserved for databases can now directly improve frontend user experiences as well.

⚡ Creating Custom Functions in FSCSS (Yes, CSS Can Do This)

Sat, 28 Mar 2026 11:33:44 +0000

One thing about FSCSS is that you can define your own functions… inside your styles. Here’s a simple example of how that works.

Custom randint Function

@define randint(array){
@random(@use(array)) 
}

What this function does:

Takes an array as an argument.
Returns a random value directly from that array.

Step 1: Defining Arrays
First, we set up our possible values:

@arr sizes[ 100px, 150px, 200px ]

Step 2: Using the Function
We call our custom function and assign it to a variable:

$height: @randint(@arr.sizes);

Now $height dynamically becomes either 100px, 150px, or 200px (randomly selected at compile).

Why This Is Interesting

Reusable Logic: You can create complex logic once and use it across your entire design system.
Dynamic Design Systems: Build layouts that feel organic and varied rather than static and repetitive.

Example Usage

Applying that logic to a class is straightforward:

.box { 
  height: $height; 
  width: $height; 
  background: #2c5364; 
}

Every compile can produce a slightly different UI!

https://www.npmjs.com/package/fscss

Agents Aren't Apps: Why Your UI Strategy Just Changed

Wed, 31 Dec 2025 16:22:53 +0000

You've spent years building interfaces. Forms with validation. Dashboards with charts. Navigation menus that make sense. Responsive layouts that work on every device.

That skillset is becoming less relevant.

Not because the work wasn't good. But because the fundamental assumption behind it just changed.

The assumption was this: humans navigate software by clicking through menus, filling out forms, and reading screens.

That assumption is breaking down fast.

The Interface Is Moving

Traditional applications put a user interface between humans and business logic. You open the CRM. You navigate to the customer record. You click edit. You change a field. You save.

Every action requires you to know where things are and how to get there.

Agents eliminate most of that. You tell the agent what you want. It figures out where to find the information, what to change, and how to execute the task.

The interface isn't a collection of screens anymore. It's a conversation.

This changes what developers build.

Dynamic Interfaces Generated at Runtime

Some agents still need visual interfaces. But these interfaces don't look like traditional applications.

Instead of pre-built forms with fixed fields, agents generate interfaces on demand based on what's needed for the specific task.

Need to approve a purchase order? The agent creates a form showing relevant vendor history, budget impact, and comparison to similar purchases. Different context, different form. Same agent.

Traditional development means building every possible screen in advance. Agent-based development means building systems that can generate appropriate interfaces based on context.

The shift is fundamental. You're not designing screens anymore. You're designing the logic that determines what interfaces should exist.

Headless Agents: No UI at All

Some agents don't need interfaces. They just make decisions and take actions.

A fraud detection agent monitors transactions, applies rules, and flags suspicious activity. No one interacts with it directly. No dashboard. No forms. Just decisions happening in the background.

An inventory management agent tracks stock levels, predicts demand, and triggers reorders when thresholds are hit. It doesn't need a UI. It needs good decision logic and reliable integrations.

This pattern is spreading. Agents handle routine decisions autonomously. Humans only get involved when something requires judgment that the agent can't provide.

For developers, this means building systems where the primary user is another system, not a person.

Why CRM and ERP Interfaces Are Becoming Obsolete

Consider how people actually use CRM systems today. They don't enjoy navigating through Salesforce. They do it because that's where the customer data lives.

Agents change this. Instead of opening Salesforce, finding the account, and reading through notes, you ask: "What's the status of the Acme deal?"

The agent accesses Salesforce, finds the account, reads the notes, checks recent emails, reviews the opportunity stage, and tells you what you need to know.

The Salesforce interface still exists. But you're not using it. The agent is.

This pattern applies across enterprise applications. ERP systems. HR platforms. Project management tools. The interfaces were built for human navigation. But humans increasingly interact through agents instead.

The underlying systems still matter. The data models matter. The business logic matters. But the interfaces? They're becoming legacy artifacts.

What This Means for Frontend Developers

If you build user interfaces, this creates an uncomfortable question: what do you build now?

The answer isn't that frontend development disappears. It's that it changes focus.

Instead of building comprehensive interfaces that expose every feature, you build targeted interfaces for specific contexts where visual interaction adds value.

Instead of designing navigation systems, you design conversation flows.

Instead of optimizing for ease of finding features, you optimize for clarity when agents need human input.

The skills that matter shift from information architecture and navigation design to conversation design and context-aware interface generation.

Building for Agent Consumption

When agents become the primary consumers of your APIs and data, different things matter.

Traditional APIs often assume a human will interpret the response. Documentation explains what fields mean. Error messages describe what went wrong. The API design prioritizes flexibility for different human use cases.

Agent-first APIs need different characteristics. Clear, consistent structure. Predictable error handling. Good semantic descriptions that agents can parse. Support for bulk operations and batch processing.

The difference shows up in details. A human-focused API might return a customer record with 50 fields. An agent-focused API returns the same data but includes metadata describing what each field represents, its valid values, and its business meaning.

Agents can work with either. But they work better with APIs designed for programmatic consumption at scale.

The New Skill: Designing Conversations

The interface design skill that matters now is conversation design.

How do you structure a conversation between a human and an agent to accomplish a goal? What information needs to be exchanged? When should the agent ask for clarification versus making assumptions? How do you handle ambiguity?

These questions aren't new. But they're becoming central to interface design in ways they weren't before.

A good form makes data entry clear and prevents errors. A good conversation does the same thing but through natural language exchange instead of structured fields.

The underlying principles transfer. But the implementation is completely different.

What Still Needs Traditional Interfaces

Some things still work better with traditional interfaces. Data visualization. Complex spatial relationships. Reviewing large amounts of information quickly. Creative work that benefits from direct manipulation.

Agents handle extraction, summarization, and decision-making well. They don't handle visual pattern recognition or creative layout well.

The future probably isn't all-agent or all-traditional. It's knowing which interface makes sense for which task.

But the default is shifting. Ten years ago, the default was "build an interface for it." Now the default is becoming "let the agent handle it, unless there's a specific reason humans need direct visual access."

The Purchase Order Example

Here's how this plays out in practice.

Traditional system: You log into the procurement platform. Navigate to purchase orders. Click "create new." Fill out vendor, items, quantities, delivery date, budget code. Click through approval workflow. Submit.

Agent-based system: You tell the agent "Order 50 laptops from Dell, standard spec, for the Q1 new hires." The agent finds the standard spec, gets Dell pricing, checks budget availability, generates the PO, routes it to the right approver, and confirms when it's done.

No interface. No navigation. No form filling.

The agent might generate a visual summary for the approver showing cost comparison and delivery timeline. But that's dynamic, context-specific, and temporary. Not a permanent interface someone had to build.

The Transition Challenge

The difficult part isn't technical. It's organizational.

Your company has invested years building comprehensive interfaces. Those interfaces represent thousands of hours of design, development, and refinement. They work. People know how to use them.

Now agents are making those interfaces less necessary. But you can't just shut them down. People still use them. Some tasks still need them. And building the agent layer takes time.

The transition period is messy. You're maintaining legacy interfaces while building agent capabilities. You're supporting both patterns simultaneously. And you're trying to figure out which features need interface rebuilds versus agent implementations.

There's no clean answer. But the direction is clear.

Stop Building Forms

The provocative version of this argument: if you're still building forms, you're building the wrong thing.

The nuanced version: forms made sense when humans needed to navigate complex data entry. But if an agent can gather the information through conversation and validation logic, the form is unnecessary overhead.

Not every form disappears overnight. But the default assumption should shift from "we need a form for this" to "can an agent handle this workflow?"

That shift changes what developers build and how they think about interface design.

The Skills That Transfer

Good interface design was always about understanding user goals and removing friction. That principle doesn't change.

What changes is the implementation. You're removing friction through conversation instead of navigation. You're designing for context-aware generation instead of comprehensive coverage. You're building for agent interpretation instead of human comprehension.

The core skill, understanding what users need and making it easy to accomplish, transfers directly.

The implementation techniques? Those need updating.

What Developers Should Do Now

Start building for agent consumption. Even if your organization isn't deploying agents yet, your APIs and data structures should work well for programmatic access at scale.

Learn conversation design. Understand how to structure natural language interactions that accomplish goals efficiently.

Experiment with agent-based interfaces. Build a simple agent that handles a workflow your team currently does through forms. See where it works well and where it breaks down.

Pay attention to which interfaces in your applications are becoming less used because people found agent-based alternatives. That tells you where the shift is happening.

The interface revolution isn't coming. It's here. And it's changing what developers build, how they build it, and what skills matter.

If you're still thinking in terms of screens and navigation, you're already behind.