Shorter table headers about structuralanalysisformat-doc HOT 6 CLOSED

https://sphinx-hoverxref.readthedocs.io/en/latest/

from structuralanalysisformat-doc.

internal reference number 5371

from structuralanalysisformat-doc.

As mentioned earlier, instead of putting the whole enum definition into the table, it might also be an option to have a separate page under annexes that lists the different enumerations available.

This will:

• Reduce the height of the row, making more of the table fit on the page
• Have the enum defined only once in the documentation
  • Less chance for errors, due to typo's or mismatches
  • Only 1 place to look for and update the enum definition if it ever changes.

The only "downside" to this would be that you wont have the enum definition in the table, but that might be solved by something like this I found on RTD docs:

If you hover over the link, it'll open a pop-up which presumably lists the content of another page in the docs.
Something worth investigating? @msalak-scia @sonkaste17

Secondly,

• "Column header" or "Row header" can just be replaced with "Header"?
• "Type of data" might just as well be "Type"?
• I'd propose the following order, so that the more important columns are up front:
  | Header | Type | Required | Description | Example |

from structuralanalysisformat-doc.

For that popup thing to work, we'd have to try something similar to this:

check out :ref:connected-accounts:permissions for connected accounts.

They have, in their doc root folder a file called "connected-accounts.rst" with a title in there "permissions for connected accounts"

Although this may only work with rst files and not such much markdown files?

from structuralanalysisformat-doc.

We discussed that it would be nice to have all the values of enums directly inside the table. Sometimes it is necessary for the orientation in tables. In case required value of something is 'yes if other enum = ...' then it is nice to look at the enum a see all the possible option, to get the idea how it works. What do you think? @dschuermans

from structuralanalysisformat-doc.

@msalak-scia Then why do it for most enums and not for all? 😅
You're free to do whatever you want with this, I just offered up a solution to keep the tables which define the columns that should/may be present on the sheet as concise as possible.

from structuralanalysisformat-doc.