Skip to content

UX: Files for Processing empty state lacks a clear next user action #87

Open

Description

@Fooftilly

Status: Candidate UX/UI finding — not approved implementation work.

Source: automated UX audit (Grok Bot)
Last verified: master@e96a3ea
Surface: other
Classification: UX-FRICTION / FEEDBACK
Confidence: medium

Security: Follow SECURITY.md. Do not expose real storage paths from production libraries in public issues; this audit used testing mode and observed UI copy only.

Finding

Files for Processing empty state explains a filesystem inbox path and offers Refresh folder scan, but does not connect to a clear next user action (upload / New File / copyable instructions). Global New File is not linked from this empty state.

Reproduction

  1. Open Files for Processing when empty.
  2. Read empty-state copy and available actions.

Deterministic empty-state observation this pass.

Current behavior

Backend-oriented empty copy + Refresh only; no primary “add a PDF” path tied to the route.

Expected / improved behavior

Primary Add PDF / Open New File CTA, plus clearer “where files come from” help. If filesystem-only ingestion is intentional, say so in user language and make the instruction/path actionable (copyable / open-instructions dialog) without requiring users to already know server layout.

User impact

Users who open Processing directly may not know how to get a first file into the queue.

Evidence

  • Tested commit: master@e96a3ea
  • Surface labeled other in taxonomy terms; UI name is Files for Processing.

Files for Processing empty state without clear next user action

Likely affected area

Hypothesis: Processing empty-state copy and actions.

Recommended direction

User-action-first empty state; keep Refresh as secondary. Non-goal: changing ingestion architecture in this finding.

Acceptance criteria

  • Empty Processing presents a clear next action for a first-time user.
  • Filesystem-only constraints, if any, are explained in plain language.

Existing issue / roadmap overlap

Related roadmap: #40 Processing Inbox V2. This finding is limited to empty-state next-action clarity in the current UI.

No overlapping ux-finding for Processing empty-state next action.

Assessment

  • Priority: P3
  • Areas: area:ux
  • Change risk: low

This issue records a UX/UI finding for review. It does not authorize implementation.


Found using Grok Bot

Activity

  1. added
    candidateFinding is recorded but not approved for implementation
    priority:P3Worthwhile cleanup, maintainability, tooling, or low-risk reliability improvement
    on Sep 20, 2026
  2. Fooftilly commented on Oct 6, 2026

    @Fooftilly
    OwnerAuthor

    Sequencing / roadmap overlap

    Strong overlap with #40 Processing Inbox V2. #40 adds a clearer ingestion queue and web-UI add/upload flow, which is likely to replace this current empty-state/Refresh-only interaction. Prefer using #87 as an acceptance criterion for the #40 empty state rather than implementing a temporary CTA on the current surface unless #40 is deliberately postponed.

  3. added
    roadmap-overlapIssue overlaps with a feature that will be implemented on the roadmap
    on Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:uxcandidateFinding is recorded but not approved for implementationpriority:P3Worthwhile cleanup, maintainability, tooling, or low-risk reliability improvementroadmap-overlapIssue overlaps with a feature that will be implemented on the roadmapux-finding

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions