strictdoc server should present "TITLE" at the top of the edit fields

[MartyLake]

Hello,

It seems that the edit fields are sorted alphabetically. I expect however that it displays "TITLE" as the first parameter in edit mode, to mimic how it will be displayed afterward.

Best,

[haxtibal]

Hi @MartyLake,

It seems that the edit fields are sorted alphabetically.

it's not alphabetically. It's single line fields ordered as in sdoc first, then multiline fields as ordered in sdoc. But both views make different hardcoded exceptions in the top level structure. Title is one such exception.

See strictdoc/export/html/templates/components/requirement/index.jinja for the rendered HTML view, and strictdoc/export/html/templates/screens/document/document/frame_requirement_form.jinja for the edit view.

I expect however that it displays "TITLE" as the first parameter in edit mode, to mimic how it will be displayed afterward.

I could do a PR to add an optional filter= or exclude= arg to RequirementFormField.enumerate_fields, and then use it to hardcode the title exception in frame_requirement_form.jinja as you suggested. But maybe @stanislaw and @mettta have different plans with the edit form, would like to hear from them first.

[stanislaw]

The original idea was that the order of the fields in the UI would match their order in the SDoc grammar. A the same time, like @haxtibal said, TITLE is one of a few exceptions when it comes to viewing the requirements because we want the title to stand out.

Also, there are requirements documents that only provide requirements without titles, so the UI must not make an assumption that the title is always there. Also, there can potentially be SDoc grammars that use some other field instead of a title, and that has to be covered as well.

@MartyLake I considered this a low-priority item until now but I would not mind if someone implemented a fix.

[MartyLake]

Right, I always forget that the grammar itself can be configured. I always though meta software like this would be very powerful for advanced users because it could be adapted to any existing workflow or practice, but for pure noobs like me (I still struggle to self-learn that topic and put it into practice), it is very hard to establish a practice because I expect tools to guide me and help me acquire best practices by following their default or tutorial behavior.

I guess trying to serve too many different users may not be very productive, so I understand why you consider my request low priority.

Thanks for your message !

[stanislaw]

By saying a lower priority I, of course, don't mean it will not be implemented but rather that it will take some time.

it is very hard to establish a practice because I expect tools to guide me and help me acquire best practices by following their default or tutorial behavior.

I wish we had more time to implement a good UI experience comparable to that of the commercial tools. It is a spare-time project where we can only dedicate as much free time as we can because it is outside of our day jobs. Note that the amount of open GitHub issues is 100+, and we need to prioritize 😄

The focus of 2024 Q3 and Q4 has been more on the backend side but we might revisit this ticket when we come back to the UI enhancements.

[MartyLake]

It is a spare-time project where we can only dedicate as much free time as we can because it is outside of our day jobs.

Yes, please don’t burnout, I have no rush on my side and I understand that priority needs to happen.