Define reusable AI interaction patterns for LibreSign #9059

Goal

Research and document reusable UX patterns for future AI-assisted LibreSign features.

This is a research, UX-specification and prototyping task. It does not implement shared Vue components or downstream AI screens.

The output must give future implementation issues enough guidance to avoid inventing unrelated AI buttons, disclosures, review states and confirmation patterns.

Research sources

Review:

• current LibreSign document, signing, editor and settings flows;
• official Nextcloud Vue AI components such as Assistant buttons, icons and content containers;
• AI interaction patterns in current Nextcloud apps;
• public document/signature-assistant experiences where they clarify established user expectations.

External product screens are references for interaction problems and possible patterns. Do not copy them mechanically.

When referencing external GitHub issues/PRs only as research, use literal non-autolinked URLs and do not interact with the upstream item.

Required output

Produce a reviewable UX specification with concrete wireframes/mockups or annotated screen proposals.

At minimum cover these states:

Entry point

• where optional AI assistance appears;
• how it remains secondary to the primary signing/document task;
• how unavailable and policy-denied states differ.

Running state

• loading/progress;
• cancellation where supported;
• retry after a recoverable failure;
• provider/capability unavailable state.

Informational output

For summaries, explanations or answers that do not mutate LibreSign:

• clearly identify AI-assisted content;
• keep the source document authoritative;
• provide source/provenance navigation when the platform can support it;
• show concise limitations without overwhelming the workflow.

Draft/review/apply

For AI output that proposes persistent changes:

• distinguish generated draft from saved state;
• allow review before persistence;
• provide explicit Apply/Accept;
• provide reject/cancel/retry/refine behavior;
• preserve a manual path when the underlying functionality supports one.

Consequential actions

For actions such as sending, notifying, changing participants or cancelling:

• show exactly what action will occur;
• use normal LibreSign confirmation conventions;
• never imply that the AI itself authorizes the action.

Contextual documentation

Define where a help/documentation affordance should appear for AI-specific prerequisites, limitations or policy information.

Accessibility and usability

The specification must address:

• keyboard operation;
• screen-reader naming/status announcements;
• responsive behavior alongside PDF/document views;
• wording that does not require provider/LLM knowledge;
• error recovery;
• status communication that does not rely only on color.

Screenshots and prototypes

For every proposed LibreSign screen or materially changed state:

• include a screenshot, wireframe or mockup;
• show enough surrounding UI context to understand placement;
• annotate the purpose of the AI affordance and the primary user action;
• avoid real personal/customer data.

If the proposal references an existing Nextcloud/product screen, include the reference and explain which interaction principle is relevant.

Writing requirements

Write the UX specification as guidance for future implementation:

• explain the user goal first;
• explain the state/interaction rule second;
• use component names only when they help implementation;
• do not narrate the research process;
• do not present speculative product behavior as already implemented.

Out of scope

Do not:

• implement Vue components;
• add AI buttons to production screens;
• add Task Processing calls;
• define backend authorization;
• define Policy Workbench keys;
• build downstream feature-specific screens beyond the prototype/specification needed to illustrate the reusable pattern.

Done when

• Reusable AI interaction states are documented.
• Informational, draft/review and consequential-action patterns are distinct.
• Concrete wireframes/mockups exist for materially different states.
• Nextcloud-native patterns/components are identified where appropriate.
• Accessibility and failure/recovery states are covered.
• Contextual documentation/help behavior is specified.
• Downstream epics can reuse the guidance without treating it as an implemented UI.