Icons and Connector Panes for Distributed APIs
- Updated2023-02-17
- 5 minute(s) read
Icons and Connector Panes for Distributed APIs
Refer to the following table for best practices for creating icons and connector panes.
| Guideline | Required or Recommended? | Details |
|---|---|---|
|
Make all VIs or as many VIs as possible the same size. |
Required |
The icon size is determined by the connector pane pattern that the subVI requires. Refer to the icon and connector pane guidelines in Icons and Connector Panes for G Web Development Software Projects for more information. |
|
When resizing a VI, expand it in one direction. |
Required |
The direction a VI can stretch depends on error input and output location on the connector pane.
|
| Guideline | Required or Recommended? | Details | Example(s) |
|---|---|---|---|
|
Make the node size big enough to communicate its functionality through an icon. |
Required |
The icon should communicate node behavior. |
N/A |
|
Make consistent iconography for all the VIs in your API. |
Required |
Default glyphs are in the G Web Development Software project on the Icon tab. You can use the default glyphs as a starting point in your VIs. |
N/A |
| Guideline | Required or Recommended? | Details | Example(s) |
|---|---|---|---|
| Include pass-through wires in the upper corners of a VI only if it is part of a reference-based API. | Required | A reference value is not modified during execution, so passing it through VIs in an API is convenient. A VI could potentially modify a data value, in other words, any wire that is not a reference or a cluster/class of references, if it is passing through. Pass data values through VIs only if the VI might modify the value of the wire. | Reference-based APIs in G Web Development Software include queue and HTTP. |
| Either coerce numeric inputs into a range that your code expects, or handle out-of-range values with an error condition or warning. | Required | Do not configure data limits for numeric controls. | If you specify the speed of a motor, and the motor can go only 0-100 mph, make sure you are either coercing the input value with an In Range and Coerce function to be within 0-100, or return an error if you specify a value outside that range. |
|
Use lower case for input and output names. |
Required |
N/A |
Use: exported waveform Do not use: Exported Waveform |
|
Use input and output names that are easy to understand. |
Required |
N/A |
Use: remainder Do not use: x-y*floor(x/y) |
|
Name inputs and outputs consistently. |
Required |
N/A |
For three inputs that have the same data type and source type, use: task in, task in, task in. Do not use: task in, myDAQ task in, myDAQ resource in |
|
Use simple words, not symbols. |
Required |
N/A |
Use: number of samples Do not use: # of samples |
|
Use a question mark (?) for input and output names when the data type is Boolean with an implied question. |
Required |
N/A |
Use: UTC? Do not use: is UTC |
|
Do not use a question mark (?) for Boolean inputs and outputs that are commands. |
Required |
N/A |
Use: reset Do not use: reset? |
|
Do not include default values in parentheses. |
Required |
Set default values in the configuration panel. G Web Development Software automatically appends the default values to the label. |
Use: max characters per row Do not use: max characters/row (no limit:0) |
|
Do not include units of measure in parentheses. |
Required |
Set units in the configuration panel. G Web Development Software automatically appends the units to the label. |
Use: delay time Do not use: delay time (s) |
|
Make sure the names of inputs and outputs of your VIs use complete English words, unless users worldwide know an abbreviation. |
Required |
N/A | N/A |
|
If you use the top or bottom inputs and outputs on the connector pane, make sure their wires never cross each other. |
Required |
N/A |
See the Avoid Crossing Wires section at the end of this table for a visual example. |
|
Assign the input and output terminals on the connector pane in a way that simplifies the wiring diagram. |
Required |
Consider how users might wire the VIs together when you assign terminals. Align the output terminals with the corresponding input terminals. |
N/A |
|
If multiple VIs in your API have the same input or output, place all similar inputs and outputs in the same location on the connector pane of all VIs. |
Required |
N/A |
See the Locate Inputs and Outputs Consistently section at the end of this table for a visual example. |
|
Do not leave any terminals of your public API VIs in the unplaced items tray. |
Recommended |
When all controls/indicators are on the panel, the user can open the panel of your VI and see input and output values during debugging. | N/A |
|
Set the display format of numeric controls and indicators to produce reasonable format settings for controls and indicators that users create from them. |
Recommended |
The display format settings of a source numeric control or indicator are passed on to any controls and indicators created from them. | N/A |
Avoid Crossing Wires
Locate Inputs and Outputs Consistently
Related Information
- Localization for LabVIEW NXG Projects
Refer to the following table for best practices for localization in LabVIEW NXG.
- File and Project Organization in G Web Development Software
Refer to the following table for best practices for organizing files and projects in G Web Development Software.
- Panel Design for G Web Development Software Projects
Refer to the following table for best practices for designing panels in LabVIEW NXG
- Diagram Design for G Web Development Software Projects
Refer to the following table for best practices for designing diagrams in G Web Development Software.
- Best Practices for Creating Projects in G Web Development Software
To develop projects that successfully serve your needs and the needs of your end users, refer to the following best practice guidelines:
- Best Practices for Designing and Developing an Application Programming Interface (API) in G Web Development Software
To develop an API to distribute to other users that is consistent with NI style recommendations for G content, refer to the following best practice guidelines:
- File Organization and Node Naming for Distributed APIs
Refer to the following table for best practices for organizing files and naming nodes.
- Component Organization for Distributed APIs
Refer to the following table for best practices for organizing components.
- Panel Design for Distributed APIs
Refer to the following table for best practices for designing panels.
- Data Type Selection for Distributed APIs
Refer to the following table for best practices for selecting data types.
- Palette Taxonomy for Distributed APIs
Refer to the following table for best practices for palette taxonomy.
- Documentation for Distributed APIs
Refer to the following table for best practices for documenting an API.
- Error Message Design for Distributed APIs
Refer to the following table for best practices for designing error messages.
- API Design for Distributed APIs
Refer to the following table for best practices for designing VIs.
- Icons and Connector Panes for G Web Development Software Projects
Refer to the following table for best practices for creating icons and connector panes in G Web Development Software.