Make statement type list better accessible in FactoidBuilder

[GVogeler]

Gendering Maximilian: "Teile des Menüs sind leider nicht sichtbar - also auf der rechten Seite (z.B. “Anderes”)"

[GVogeler]

Gendering Maximilian: "Bei der Hierarchisierung von Statements: Das Menü ist jetzt schon sehr aufbläht und deshalb verwirrend (z.B. familiäre Verbindung ist ganz oben, später kommt noch Elternschaft, Geschwisterverhältnis etc., ich denke, damit die Daten wirklich sinnvoll strukturiert eingegeben werden, sollte das klarer geordnet sein.)"

[richardhadden]

There are some overflow problems in standard APIS menu — I can't really find a good way to fix this. But people should be using FactoidBuilder.

As for "logical structure"... I'd be interested to know if there was one! (Originally, I experimented with having everything in one menu, with the hierarchical structure represented, but it takes up so much space on the screen; so I went with this current "grouping"... which is subjective, I admit.)

[GVogeler]

On the logical structure:

1. sort order of the menus is currently not understandable by the user. Sorting them alphabetically by German display name? Adding an explicit "sort order/position" info to the type definition?
2. Introducing deeper hierarchy or grouping them by some additional logical flag could increase overview
3. having something autocomplete style (including the comments?) could improve handling of larger lists if types

[richardhadden]

1. Alphabetical order is a good idea (at least it will look a little nicer)
2. The hierarchy exists, but statement types are grouped by "Subject Group", so it's not really possible to show more than one hierarchy (as groups cut across hierarchy) — other option would be to have the hierarchy first, then group by "Subject Group" (maybe with some icon for each subject?). Tree diagrams type things waste a lot of screen space though
3. This is a nice idea. I can probably implement this without much work, in fact

[richardhadden]

Screen.Recording.2023-11-10.at.12.25.43.mov

Implements 1 and 3!

(Searching also looks at the help text as well as the name)

[richardhadden]

Screen.Recording.2023-11-10.at.15.25.08.mov

A couple more behaviours:

1. Right clicking on any Statement type shows the description
2. If there's only one Statement type found by filtering, it's automatically selected on just pressing Enter

[GVogeler]

As for tree style visualisations: if they are collapsed they don't need much space, do they?

[richardhadden]

True... I'll try to implement this, though I suspect arbitrarily hiding things wouldn't help usability.

Another possible idea is to allow users (or sub-projects?) to customise which statement-types they see. Most simply, this could just be done by hard-coding lists of "allowed types" for each subproject, and a selector menu somewhere. If we want users to be able to change this themselves, then we'd have to think about database models and interface to manage it (and then these lists would have to be dynamically loaded, instead of just being some interface configuration)

[GVogeler]

True... I'll try to implement this, though I suspect arbitrarily hiding things wouldn't help usability.

Before implementing this, I think it would be worth to deploy the two other changes.