Overall Impressions and Vision for StrictDoc

[rkfrf2607]

From a recent office hours agenda (2026/07/07), one of the topics was "Discuss the next steps as we are deciding which tickets should go into development". While my discussion here is not intended to be a ticket or a direct reply to that request, I believe the intent behind the discussion item was to collect feedback from users and developers what should be the focus or vision for the coming year(s).

To that end, my organization has evaluated StrictDoc across several trial projects and wanted to share feedback on how the current implementation fits those needs, how we hope to use it within our organization, and a few capabilities that would significantly improve usability for us and hopefully a broader range of users. These points are intended as constructive suggestions that we believe could make StrictDoc indispensable in our workflows.

I recognize that many of these are already acknowledged in the backlog, so much of what is below might be considered a "vote" for the features that are likely to be the most impactful for our desired use cases.

Web Interface Improvements (helpful for technical folks but critically important for non‑technical user adoption)

• Concurrent editing isn’t currently possible (nor planned, as I understand). A basic locking mechanism could help prevent accidental conflicts instead
• The web UI can unintentionally introduce malformed SDoc syntax during simple edits (e.g., adding sections), which creates confusion for less technical users.
• Images cannot be added via the UI, limiting web UI usability.
• A table‑based requirement editor would greatly improve usability. The ability to reorder rows, populate columns across many rows, and perform bulk edits is important. If implementing this directly in the web UI isn’t planned, seamless import/export to Excel (or open source equivalent) would be a helpful alternative.

Diff Views and Change Review Workflow

• Large files produce extremely large diffs that are difficult to parse.
• There is no structured workflow or tooling that could enable reviewing and accepting individual changes within the UI.
• Full integration with Git/GitLab/GitHub (commits, branches, merge requests) would enable a more robust review and acceptance process.

Communication With External Stakeholders
(All of our vendors and customers rely on spreadsheets or Word/PDFs/PowerPoint and cannot use SDoc or ReqIF)

• Exporting Excel files directly from the web UI is not currently possible but would be very valuable.
• Defining report export stylesheets (templates, boilerplate content, cover pages) from the web UI would help produce documents consistently and efficiently.

Traceability Matrix

• An exportable traceability matrix is essential for demonstrating compliance during formal reviews.

To be clear, the core functionality of StrictDoc is excellent; there are but a few gaps that limit consistent source‑control workflows, structured review and approval processes, universal sharing with external stakeholders, and overall user‑friendliness for mixed technical skill levels. Solving these details would enable the workflow we would want to implement with StrictDoc as our primary requirements management tool.

[rkfrf2607]

I should have also added here that I appreciate the immense amount of work and consideration that has gone into this project. It is very obviously a project for which the team cares deeply. It shows with the consistent improvements, continual requests for feedback, and regular engagement with the community. Thank you for sharing all of your hard work with the world!

[stanislaw]

Here is what we discussed just now at the office hours:

Concurrent editing isn’t currently possible (nor planned, as I understand). A basic locking mechanism could help prevent accidental conflicts instead

StrictDoc doesn't have user accounts yet. They are still to be implemented but the concurrent editing by multiple users working on the same StrictDoc server instance (for example, deployed in a company intranet) is ensured through locking.

The web UI can unintentionally introduce malformed SDoc syntax during simple edits (e.g., adding sections), which creates confusion for less technical users.

Let us know about these edge cases. We thought that we fixed them all.

Images cannot be added via the UI, limiting web UI usability.

This is being worked on (slowly): #2742. We will also add a feature of moving SDoc nodes between documents which will also take care of updating the image paths automatically.

A table‑based requirement editor would greatly improve usability. The ability to reorder rows, populate columns across many rows, and perform bulk edits is important. If implementing this directly in the web UI isn’t planned, seamless import/export to Excel (or open source equivalent) would be a helpful alternative.

Take a look at the latest release, switch your document to the TABLE mode. We still don't have "The ability to reorder rows, populate columns across many rows, and perform bulk edits is important." but it should be doable. Please open a ticket.

Diff Views and Change Review Workflow Large files produce extremely large diffs that are difficult to parse. There is no structured workflow or tooling that could enable reviewing and accepting individual changes within the UI.

Take a look at this ticket, it seems to be quite close to what you are asking for:
#2989
Any feedback to how this feature should ideally look like is appreciated.

Full integration with Git/GitLab/GitHub (commits, branches, merge requests) would enable a more robust review and acceptance process.

This feature is something that we want to have until the end of this year.

Communication With External Stakeholders
(All of our vendors and customers rely on spreadsheets or Word/PDFs/PowerPoint and cannot use SDoc or ReqIF)
Exporting Excel files directly from the web UI is not currently possible but would be very valuable.

With the new Format abstraction it is now possible for a user to define their own formats. For example, it is possible to define a project-specific or a company-specific Excel format that can be read from and written to.
See an example of a custom CSV format: https://github.com/strictdoc-project/strictdoc/tree/main/tests/integration/examples/python_api/custom_format_example_csv.

Defining report export stylesheets (templates, boilerplate content, cover pages) from the web UI would help produce documents consistently and efficiently.

This we didn't consider before. Please open a dedicated for this.

Traceability Matrix
An exportable traceability matrix is essential for demonstrating compliance during formal reviews.

Please open a ticket. We would be interested in what is missing in the existing TRACEABILITY_MATRIX feature implementation.
See also this ticket: #964.