Skip to content

Improve non-technical export success and failure guidance #41

@needsofmany

Description

@needsofmany

Goal

Improve the guidance regular users see after running an export so they can understand whether the export appears successful, incomplete, or failed.

The guidance should be plain-language and suitable for users who are trying to preserve their data but may not be comfortable inspecting folders, JSON files, command output, or logs.

Why this matters

PluralBridge is trying to help users preserve their own data while time still matters. A user who runs an export needs to know what happened next.

The current project already documents the export path, but users still need clearer success/failure signals and next actions.

Suggested scope

Improve user-facing guidance for cases such as:

  • export folder was created
  • expected JSON files were created
  • members file exists
  • member images were downloaded
  • notes were exported, if supported by the current workflow
  • token is missing
  • token is invalid
  • network request failed
  • output folder is missing
  • export appears partial
  • user is unsure what to save or back up

This can be documentation, launcher output text, validation output text, or a combination.

Safety requirements

Do not ask users to post private exports.

Do not ask users to send API tokens.

Do not ask users to attach screenshots containing private System data.

Do not print or expose private notes, messages, friend data, fronting history, member details, authorization headers, logs, screenshots, or database files.

Use synthetic examples only.

Suggested user-facing language

The guidance should help answer:

  • Did PluralBridge create output?
  • Where is the output?
  • What files or folders should I see?
  • What warning signs matter?
  • What should I back up?
  • What should I avoid sharing publicly?
  • What should I try next if something failed?

Possible follow-up work

Later Issues can add:

  • validation summary integration
  • guided launcher improvements
  • screenshots or diagrams using synthetic data only
  • OS-specific troubleshooting
  • FAQ entries

Acceptance criteria

  • Non-technical users get clearer success/failure guidance after export.
  • The guidance explains what output to look for.
  • The guidance explains what not to share publicly.
  • Failure cases have plain-language next steps.
  • Examples use synthetic data only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationgood first issueGood for newcomershelp wantedExtra attention is needed

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions