New UI / UX Framework

[aitp-john]

💡 Proposal: "New UI" Mode — Homepage Starters, Agent Discovery, Full-Screen Builder, and Config-Driven Theming

Category: Feature Discussion / UX
Affects: Homepage, Agent Builder, Right Panel, Navigation, Theming
Related discussions: #6698 (right panel → menu), #4370 (conversation starters), #6288 (UI customization guide)

---

Summary

I'd like to propose a "New UI" mode for LibreChat — a user-switchable experience that redistributes the functions of the right side panel into better-suited locations, adds a guided homepage with configurable starter cards, introduces a full-screen agent builder, and lays the groundwork for config-driven client branding.

This directly maps to the direction called out in the 2026 roadmap: "streamlined for business users, fully open for power users." The proposal is to make that a concrete, user-controlled toggle — Classic (current experience, right panel intact) vs. New UI (streamlined, right panel hidden, functions redistributed).

The Classic mode stays fully supported. Nothing is removed. Users and admins choose.

---

The Problem

LibreChat is a powerful platform — but it's optimized for users who already know what it can do. For enterprise deployments serving broad, non-technical populations (ops, HR, sales, managers), a few consistent friction points emerge:

• Blank homepage gives no indication of what's available or where to start
• Agents are hard to discover — the Marketplace exists, but it's a sidebar nav item, not a prominent entry point
• The right panel competes with the chat canvas — the agent builder surface is persistently visible, which is useful for power users but makes the interface feel like a configuration tool for everyone else
• The builder presents everything at once — appropriate for technical users, but discourages non-technical builders who just want to create something simple
• Per-client branding requires source code changes — there's no config-only path to make a deployment feel like the organization's own tool

Discussion #6698 identified the right panel problem well: most modern AI UIs (ChatGPT, Notion, VS Code) don't use a persistent right panel, and the current design causes the artifacts panel collision documented in #3886. This proposal builds on that thread with a concrete alternative.

---

Proposed: A "New UI" Mode Toggle

The core mechanism is a settings toggle — Classic vs. New UI — that switches between two experience layers without removing any functionality:

	Classic (current)	New UI (proposed)
Right panel	Visible / collapsible	Hidden
Agent builder	Right panel	Full-screen route /agents/:id/edit
Homepage	Blank canvas	Starter cards
Agent discovery	Sidebar nav link	Full-page /agents view
Branding	Code-only	Config-driven

The toggle lives in Settings > General, and can also be set as a deployment default via librechat.yaml — so admins deploying for non-technical users can default to New UI while still letting power users switch back.

---

What Changes in New UI Mode

1. Homepage Starter Cards

Replace the blank canvas with a configurable grid of starter cards — each representing a common use case, with an optional binding to a specific agent.

Clicking a starter card opens a chat pre-loaded with the bound agent (or a suggested prompt for unbound cards).

# librechat.yaml
interface:
  homepage:
    starters:
      - title: "Summarize my email"
        description: "Digest unread messages and surface what needs action"
        icon: "📧"
        agentId: "agent_email_assistant"
      - title: "Find a contract"
        description: "Search SharePoint for agreements by vendor or topic"
        icon: "📄"
        agentId: "agent_contracts"
      - title: "Review sprint tickets"
        description: "Pull current tasks and flag blockers"
        icon: "🎫"
        agentId: "agent_jira"

This is adjacent to the ConvoStarter component that already exists for Assistants (see #4370) — the proposal extends that pattern to agents and promotes it to the homepage level.

Empty state: If no starters are configured, the homepage renders the current blank canvas. Fully backward compatible.

---

2. Full-Page Agent Discovery (/agents)

Promote the Agent Marketplace from a nav link to a dedicated discovery view with:

• Filterable card grid (by category, data source, or keyword)
• Each card: name, description, connected sources/tools, live status
• One-click "Use →" that opens a chat with the agent pre-loaded
• "Edit" action visible to creators/admins

This is a new view over existing agent data — no changes to the underlying agent model needed.

---

3. Full-Screen Agent Builder

In New UI mode, the agent builder becomes a dedicated full-screen route (/agents/new, /agents/:id/edit) with:

Simple mode (default):

• Agent name
• Plain-language instructions ("What does this agent do?")
• Knowledge source selector (cards, not dropdowns)
• Model selector

Advanced mode (collapsed behind "Show advanced options"):

• All current fields: temperature, tools, variables, capabilities, code interpreter, etc.

A live preview panel on the right side of the builder lets users test as they configure — the same interaction model as Gemini Gem Builder or ChatGPT's GPT builder.

The existing builder in the right panel remains fully available in Classic mode. In New UI mode, the builder route replaces it — but all the same capabilities are there, just reorganized.

---

4. Config-Driven Theming

A theme block in librechat.yaml that controls per-deployment branding without source code changes:

# librechat.yaml
interface:
  theme:
    logo: "/assets/client-logo.png"
    appName: "Maisy"
    primaryColor: "#1A56DB"
    fontFamily: "Inter"
    favicon: "/assets/favicon.ico"

This cascades through the UI via CSS custom properties. It's not white-labeling — LibreChat attribution stays visible. It's about making a deployment feel like the organization's own tool, which materially affects adoption.

Currently, this requires editing source code and rebuilding (per #6288). A config-only path would make this accessible to non-developer deployers.

---

5. UI Style Packs (Longer Term / Community Contribution Opportunity)

As an extension of the theming layer: pluggable visual themes selectable by users or set as a deployment default:

• default — current LibreChat aesthetic
• light-clean — Google Gemini-inspired
• minimal-dark — Claude-inspired

Community-contributed, config-selectable. Lower priority than items 1–4, included here for early discussion.

---

Design Principles

• Guide, don't expose — New UI surfaces lead users toward value; Classic mode keeps full capability visible
• Progressive disclosure — Advanced options exist but aren't the first thing you see
• Configuration over code — Client branding and homepage customization require no per-deployment code changes
• Additive, not replacing — Classic mode is preserved and fully supported; New UI is opt-in
• Upstream-first architecture — Changes built with clean separation of concerns, AITP/deployer-specific logic in config or namespaced extension points, with the intent to contribute back

---

Questions for the Community

1. UI mode toggle — Is there existing work on a Classic/New UI switch that I've missed? The 2026 roadmap language about "streamlined for business users" suggests this direction is already being considered.

2. Right panel redistribution — Building on #6698: what's the maintainer's appetite for making this switch official rather than just hiding the panel? The artifacts collision issue alone seems worth resolving.

3. Homepage starters — #4370 indicated starters were planned for Agents. Is that still in scope, and would a librechat.yaml-configurable version be the right approach?

4. Theming via config — Is there a planned path to make the customizations in #6288 config-driven? Or is the intent to keep visual customization at the source-code level for now?

5. Builder UX — Would a simple/advanced mode split be welcome? Concern about hiding capabilities from new users is valid — happy to discuss how to balance discoverability with simplicity.

---

Suggested Sequencing

1. Theming layer — most contained, fewest UX opinions, enables all client customization work
2. Homepage starters — high visibility, backward compatible, strong first-run impact
3. UI mode toggle + right panel redistribution — architectural, benefits from alignment upfront
4. Full-screen agent builder — highest effort, most dependent on prior alignment
5. Style packs — community contribution opportunity once theming foundation exists

Happy to open scoped discussions per track once there's alignment on direction. Wireframes and working prototypes available on request.

---

This proposal is informed by deploying LibreChat in enterprise environments for non-technical business user populations. The "streamlined for business users" framing in the 2026 roadmap is exactly the direction we're pushing toward — this is an attempt to make that concrete.

# 💡 Proposal: "New UI" Mode — Homepage Starters, Agent Discovery, Full-Screen Builder, and Config-Driven Theming

Category: Feature Discussion / UX
Affects: Homepage, Agent Builder, Right Panel, Navigation, Theming
Related discussions: #6698 (right panel → menu), #4370 (conversation starters), #6288 (UI customization guide)

---

Summary

I'd like to propose a "New UI" mode for LibreChat — a user-switchable experience that redistributes the functions of the right side panel into better-suited locations, adds a guided homepage with configurable starter cards, introduces a full-screen agent builder, and lays the groundwork for config-driven client branding.

This directly maps to the direction called out in the [2026 roadmap](https://www.librechat.ai/blog/2026-02-18_2026_roadmap): "streamlined for business users, fully open for power users." The proposal is to make that a concrete, user-controlled toggle — Classic (current experience, right panel intact) vs. New UI (streamlined, right panel hidden, functions redistributed).

The Classic mode stays fully supported. Nothing is removed. Users and admins choose.

---

The Problem

LibreChat is a powerful platform — but it's optimized for users who already know what it can do. For enterprise deployments serving broad, non-technical populations (ops, HR, sales, managers), a few consistent friction points emerge:

• Blank homepage gives no indication of what's available or where to start
• Agents are hard to discover — the Marketplace exists, but it's a sidebar nav item, not a prominent entry point
• The right panel competes with the chat canvas — the agent builder surface is persistently visible, which is useful for power users but makes the interface feel like a configuration tool for everyone else
• The builder presents everything at once — appropriate for technical users, but discourages non-technical builders who just want to create something simple
• Per-client branding requires source code changes — there's no config-only path to make a deployment feel like the organization's own tool

Discussion [#6698](#6698) identified the right panel problem well: most modern AI UIs (ChatGPT, Notion, VS Code) don't use a persistent right panel, and the current design causes the artifacts panel collision documented in [#3886](#3886). This proposal builds on that thread with a concrete alternative.

---

Proposed: A "New UI" Mode Toggle

The core mechanism is a settings toggle — Classic vs. New UI — that switches between two experience layers without removing any functionality:

	Classic (current)	New UI (proposed)
Right panel	Visible / collapsible	Hidden
Agent builder	Right panel	Full-screen route /agents/:id/edit
Homepage	Blank canvas	Starter cards
Agent discovery	Sidebar nav link	Full-page /agents view
Branding	Code-only	Config-driven

The toggle lives in Settings > General, and can also be set as a deployment default via librechat.yaml — so admins deploying for non-technical users can default to New UI while still letting power users switch back.

---

What Changes in New UI Mode

1. Homepage Starter Cards

Replace the blank canvas with a configurable grid of starter cards — each representing a common use case, with an optional binding to a specific agent.

Clicking a starter card opens a chat pre-loaded with the bound agent (or a suggested prompt for unbound cards).

# librechat.yaml
interface:
  homepage:
    starters:
      - title: "Summarize my email"
        description: "Digest unread messages and surface what needs action"
        icon: "📧"
        agentId: "agent_email_assistant"
      - title: "Find a contract"
        description: "Search SharePoint for agreements by vendor or topic"
        icon: "📄"
        agentId: "agent_contracts"
      - title: "Review sprint tickets"
        description: "Pull current tasks and flag blockers"
        icon: "🎫"
        agentId: "agent_jira"

This is adjacent to the ConvoStarter component that already exists for Assistants (see [#4370](#4370)) — the proposal extends that pattern to agents and promotes it to the homepage level.

Empty state: If no starters are configured, the homepage renders the current blank canvas. Fully backward compatible.

---

2. Full-Page Agent Discovery (/agents)

Promote the Agent Marketplace from a nav link to a dedicated discovery view with:

• Filterable card grid (by category, data source, or keyword)
• Each card: name, description, connected sources/tools, live status
• One-click "Use →" that opens a chat with the agent pre-loaded
• "Edit" action visible to creators/admins

This is a new view over existing agent data — no changes to the underlying agent model needed.

---

3. Full-Screen Agent Builder

In New UI mode, the agent builder becomes a dedicated full-screen route (/agents/new, /agents/:id/edit) with:

Simple mode (default):

• Agent name
• Plain-language instructions ("What does this agent do?")
• Knowledge source selector (cards, not dropdowns)
• Model selector

Advanced mode (collapsed behind "Show advanced options"):

• All current fields: temperature, tools, variables, capabilities, code interpreter, etc.

A live preview panel on the right side of the builder lets users test as they configure — the same interaction model as Gemini Gem Builder or ChatGPT's GPT builder.

The existing builder in the right panel remains fully available in Classic mode. In New UI mode, the builder route replaces it — but all the same capabilities are there, just reorganized.

---

4. Config-Driven Theming

A theme block in librechat.yaml that controls per-deployment branding without source code changes:

# librechat.yaml
interface:
  theme:
    logo: "/assets/client-logo.png"
    appName: "Maisy"
    primaryColor: "#1A56DB"
    fontFamily: "Inter"
    favicon: "/assets/favicon.ico"

This cascades through the UI via CSS custom properties. It's not white-labeling — LibreChat attribution stays visible. It's about making a deployment feel like the organization's own tool, which materially affects adoption.

Currently, this requires editing source code and rebuilding (per [#6288](#6288)). A config-only path would make this accessible to non-developer deployers.

---

5. UI Style Packs (Longer Term / Community Contribution Opportunity)

As an extension of the theming layer: pluggable visual themes selectable by users or set as a deployment default:

• default — current LibreChat aesthetic
• light-clean — Google Gemini-inspired
• minimal-dark — Claude-inspired

Community-contributed, config-selectable. Lower priority than items 1–4, included here for early discussion.

---

Design Principles

• Guide, don't expose — New UI surfaces lead users toward value; Classic mode keeps full capability visible
• Progressive disclosure — Advanced options exist but aren't the first thing you see
• Configuration over code — Client branding and homepage customization require no per-deployment code changes
• Additive, not replacing — Classic mode is preserved and fully supported; New UI is opt-in
• Upstream-first architecture — Changes built with clean separation of concerns, AITP/deployer-specific logic in config or namespaced extension points, with the intent to contribute back

---

Questions for the Community

1. UI mode toggle — Is there existing work on a Classic/New UI switch that I've missed? The 2026 roadmap language about "streamlined for business users" suggests this direction is already being considered.

2. Right panel redistribution — Building on [#6698](Enhancement: Switch right-side panel to menu #6698): what's the maintainer's appetite for making this switch official rather than just hiding the panel? The artifacts collision issue alone seems worth resolving.

3. Homepage starters — [#4370]([Question] conversation starter #4370) indicated starters were planned for Agents. Is that still in scope, and would a librechat.yaml-configurable version be the right approach?

4. Theming via config — Is there a planned path to make the customizations in [#6288](GUIDE: Customising the LibreChat user interface (UI) #6288) config-driven? Or is the intent to keep visual customization at the source-code level for now?

5. Builder UX — Would a simple/advanced mode split be welcome? Concern about hiding capabilities from new users is valid — happy to discuss how to balance discoverability with simplicity.

---

Suggested Sequencing

1. Theming layer — most contained, fewest UX opinions, enables all client customization work
2. Homepage starters — high visibility, backward compatible, strong first-run impact
3. UI mode toggle + right panel redistribution — architectural, benefits from alignment upfront
4. Full-screen agent builder — highest effort, most dependent on prior alignment
5. Style packs — community contribution opportunity once theming foundation exists

Happy to open scoped discussions per track once there's alignment on direction. Wireframes and working prototypes available on request.

Here are a couple of examples of some Claude Code versions I djinned up. Just for help understanding what I mean.

Classic/New UX toggle

New agent builder concept

This one below references Maisy (that's just our internal chat name) but it shows branding and the starter cards and is a bit over-designed by Claude ...

This proposal is informed by deploying LibreChat in enterprise environments for non-technical business user populations. The "streamlined for business users" framing in the 2026 roadmap is exactly the direction we're pushing toward — this is an attempt to make that concrete.