Operators TOC Structure

[cjsha]

Proposed TOC Structure

OpenEphys.Onix1
|
└─── Core Operators
│   │   createContext
│   │   startAcquisition
│   
└─── Configuration Operators
│   │   configureBreakoutBoard
│   │   configureHeadstageAbc
│   │   configureHeadstageXyz
│   │   ...
│
└─── Data I/O Operators
│   │   abcData
│   │   xyzData
│   │   ...
│
└─── Other
    |
    └─── Developer Operators (not recommended for Open Ephys hardware)
         |
         └─── Device Configuration Operators
            │   
            │   configureDeviceAbc
            │   configureDeviceXyz
            │   ...

Additional Information and Considerations

This is the current structure:

• The drop-down menu names should be more concise
• Device Configuration Operators shouldn't be first-class citizens and on the same level as the operators we actually want people to use
• Is "Infrastructural" the best way to categorize CreateContext and StartAcqusition operators? This is the sentence that comes to mind when I try to describe them: CreateContext and StartAcqusition form a motif that serves as the basis of every workflow that interfaces with ONIX hardware. I feel like it would be fair to consider them the "core" Onix operators.
• xyzDataFrame classes and enums pages still exist - they are just not listed in TOC. They are searchable if you know what you are looking for, and there are some hyperlinks that lead to them. Do we want people to able to easily navigate to them through the TOC? I don't think that's not necessary if dataframes and enums are properly incorporated into the operator's pages that utilizes them. For instance, the Bno055Data page shows the Bno055DataFrame and the Calibration row displays the enumerated type and its fields/values. I think this is sufficient, and removing Bno055DataFram and Bno055CalibrationFlags from the TOC declutters it. The pages become longer, but I appreciate the linearity of a self-contained Operator page instead of having to click back-and-forth.
• For a moment I thought of mirroring the Bonsai UI: and perhaps breaking it down further from there, but I don't think that's actually helpful
• Jon dislikes the word "node" in our documentation, but "node" require no additional knowledge whereas "operator" does. I like the word node for its beginner-friendliness. However, I understand at some point people should understand these things as operators.

[cjsha]

This is another idea. The Operator Inputs/Outputs is optional, if we want to put ContextTask, DataFrames, etc. in the TOC.

OpenEphys.Onix1
|
└─── Core Operators
│   │   createContext
│   │   startAcquisition
│   
└─── Configuration Operators
│   │   configureBreakoutBoard
│   │   configureHeadstageAbc
│   │   configureHeadstageXyz
│   │   ...
│
└─── Data I/O Operators
│   │   abcData
│   │   xyzData
│   │   ...
│
└─── Other
    │
    └─── Device Configuration Operators
    │   │   
    │   │   configureDeviceAbc
    │   │   configureDeviceXyz
    │   │   ...
    │
    └─── Operator Inputs/Outputs
        │   
        │   ContextTask
        │   AbcDataFrame
        │   XyzDataFrame