Skip to content

Investigate and implement an in-app help and support submission system #255

Description

@ZFordDev

Problem

SnapDock already provides several external help and support routes through the application, including:

  • Documentation
  • SnapDock website
  • Report a Bug → GitHub Issues
  • View Source
  • Personal support email

These options should remain available, but they all ultimately redirect the user somewhere else.

This creates unnecessary friction for everyday users who encounter a problem and simply want to ask for help.

GitHub Issues in particular works well for developers and open-source contributors, but many SnapDock users do not have or use GitHub accounts.

Proposed direction

Investigate adding a simple in-app help request system that allows a user to submit a support request without leaving SnapDock.

The exact backend or service should not be decided as part of this issue until the available options have been investigated.

Possible approaches could include an embedded form service such as Google Forms, a lightweight hosted form/backend, or a small SnapDock-specific support endpoint.

The important requirement is the workflow:

Help → Request Help → fill in details → submit from SnapDock

rather than:

Help → external website → find form/page → fill in details → submit

Potential information

A support request could include user-entered fields such as:

  • Problem/question
  • Contact email (optional)
  • Steps to reproduce (where relevant)

SnapDock could also offer to attach useful application information automatically:

  • SnapDock version
  • Operating system
  • Installation type
  • Update channel
  • Relevant non-sensitive diagnostic information

Any automatically included information should be clearly shown to the user before submission.

No telemetry or automatic reporting should be introduced. Submission must always be explicitly initiated by the user.

Users should not be required to create an account or provide personal information to submit a request.

If contact information is optional, the implementation should make it clear that anonymous requests cannot receive a direct response. A ticket or reference system could potentially be considered during the investigation if appropriate.

Investigation required

Before implementation, determine the best tool/backend for this feature.

Consider:

  • Ability to embed cleanly within SnapDock
  • No account requirement for the user
  • Ability to submit anonymously
  • Spam protection
  • Privacy
  • Cost
  • Reliability
  • Maintenance burden
  • Ability to receive and respond to submissions where contact information is provided
  • Whether diagnostic information can be attached
  • Whether the service introduces unwanted tracking or telemetry
  • Whether a small first-party endpoint would be preferable to a third-party form provider

SnapDock is a free application. While the project has a small operating budget thanks to one ongoing supporters, implementing an expensive support system should be considered a last resort.

The preferred solution should be simple, inexpensive, privacy-respecting, and require minimal ongoing maintenance.

Goal

A SnapDock user experiencing a problem should be able to ask for help from SnapDock itself, without needing to understand GitHub, locate an email address, navigate through external support pages, create an account, or provide personal information.

The existing external support links should remain available for users who prefer them. The in-app help system would provide a simpler first-line support path for everyone else.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions