# Design Systems Documentation Tools **URL:** \ **Category:** General Discussion\ **Tags:** vision, perspective\ **Created:** [September 30, 2021, 6:34pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509 "2021-09-30T18:34:07Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [September 30, 2021, 6:34pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/1 "2021-09-30T18:34:07Z")
When creating company-wide guidelines for how UX components should look, what sort of tools do you use to keep this documentation up to date and easily accessible? Our current “standards” are kept in a Word document. There are so many different properties to try and document that this becomes very cumbersome and clunky very quickly, and I know there has to be a better solution out there. Most of our current documentation is for FTV, but we’ve got projects coming up that will be using Ignition, so we’ll be updating/adding to these soon. I’ve seen tools like Figma and [proto.io](http://proto.io). It seems like these are designed specifically for Web and Mobile development, but I’m not sure if these tools would be useful in this field as they may be web/mobile specific. My question is, has anybody adapted these tools for use with Ignition (or SCADA in general), or found similar tools to help keep everything organized? ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [September 30, 2021, 8:02pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/2 "2021-09-30T20:02:55Z")
Shameless plug: We’re working on a color management module that will allow for managing colors and tokens inside of Ignition’s project structure. It’ll allow for editing stored colors (yes, HSL is supported 😉), creating themes with unique color palettes, and assigning colors to tokens on a per-theme basis. All the data is stored in a version control compatible format, and based on initial results the client-side performance is much better than existing client tag/script module color storage methods. Hoping to have a public beta available sometime in the next month. ---
**Author:** ![Brandon\_Sieh](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@Brandon\_Sieh](https://forum.inductiveautomation.com/u/Brandon_Sieh)\ **Post date:** [January 17, 2022, 6:00pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/3 "2022-01-17T18:00:34Z")
Commenting to get notifications on any updates in this chain. I was about to post a similar question. My company just started using Ignition, so we’re still very much in the process of establishing our “standards”. I was wondering if anyone had found any good methods of documenting their Vision or Perspective applications. I’m looking to outline the page structure, tag and property bindings, etc. so that any future modifications/maintenance on the application would be quick and simple. As it stands, I’m just planning on writing up a Word document summarizing the application, and including details like “X tag corresponds to Y device”, “Z tag is calculated by function A” and so on. Was just curious if anyone had a better way. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [January 17, 2022, 6:12pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/4 "2022-01-17T18:12:29Z")
This was something when I first started with Ignition that I was concerned with - documenting each window and each component in each window etc. What I've found and what I think is more important is defining some general guidelines and coding patterns/GUI patterns. For instance, any window that requires a dataset to populate it's components - this should be done in exactly one spot on the root container, based on a parameter with the record ID. Then each component should have it's won custom property that I call `initialValue` that reads from the dataset with a fallback default value in the event that there is no record so of the form `try({Root Container.ReadData}[0, 'someColumn'], 'myFallBackValue')` - and then your components value is bound to this. Knowing that every window is setup the same way (or at least very close to the same way) gives me a lot of knowledge over the structure of the program while knowing very little about each individual component. Other pattern's I would heavily recommend - Put all business logic in scripting modules, never on a GUI component itself. Treat the GUI as just a means of getting parameters to feed to functions in the scripting module - the less I have to click on each component looking for business logic, and the more I can just look at the codebase, the easier debugging is. Try to come up with naming conventions for your components. Any component that ends up feeding data to the function called on the submit button of a window should have a `_out_` prefix to the name - thats what I use, you don't have to use it, but it makes finding where a certain value is coming from in a function from the GUI much easier. Regarding templates in vision - since providing inputs and getting outputs from a template are both in the template parameters part, this is even more useful - properties that have an `_in_` prefix I know must be provided to the template and then that the template will give me values in parameters that have an `_out_` prefix. > “X tag corresponds to Y device”, Stuff like this I think is best handled with proper folder structure of your tags. Everything being on the top level, even with documentation, I think would be harder to manage then well named folders and tags being in the appropriate folders. You could document the fact that you have a folder per PLC, or a folder per Machine, or per Line, or per whatever unit of "stuff" makes sense for the system you are making. > “Z tag is calculated by function A” Stuff like this I don't think it's necessary to document tbh. If I need to know how Z Tag is calculated, I'm going to open up designer and look at it directly, I'm not going to trust a potentially out of date document. Just my two cents. The big point I am trying to make - decide on what conventions you want to use in your project and document _those_. ---
**Author:** ![Haylee\_Hauser](https://avatars.discourse-cdn.com/v4/letter/h/4bbf92/32.png) [@Haylee\_Hauser](https://forum.inductiveautomation.com/u/Haylee_Hauser)\ **Post date:** [August 19, 2022, 4:25pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/5 "2022-08-19T16:25:55Z")
> [@Brandon\_Sieh](#): > > My company just started using Ignition, so we’re still very much in the process of establishing our “standards”. I was wondering if anyone had found any good methods of documenting their Vision or Perspective applications. I’m looking to outline the page structure, tag and property bindings, etc. so that any future modifications/maintenance on the application would be quick and simple. My company is looking to do the same thing. We are reviewing options for including system documentation inside of Ignition projects. What is the best method of keeping the system documentation in the vision/perspective project? ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [August 19, 2022, 4:42pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/6 "2022-08-19T16:42:44Z")
> [@Haylee\_Hauser](#): > > What is the best method of keeping the system documentation in the vision/perspective project? I'll mention this recent addition to Designer in Ignition 8.1.19 as one potentially valuable resource: > Expanded the concept of 'resource documentation' to apply to all resources. Right click any resource in the project browse tree to edit the **Documentation** describing that resource. Named query and report resources had a unique documentation field previously. This documentation will be upgraded to the new style once the resource is opened and saved in the designer. ---
**Author:** ![Nezar\_Mansour](https://avatars.discourse-cdn.com/v4/letter/n/e495f1/32.png) [@Nezar\_Mansour](https://forum.inductiveautomation.com/u/Nezar_Mansour)\ **Post date:** [February 28, 2024, 11:04am UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/7 "2024-02-28T11:04:46Z")
There are dedicated tools for documenting and managing design systems and your components. Check out [Supernova's Design System Documentation tool](https://supernova.io/) as an example. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [March 6, 2024, 10:02pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/8 "2024-03-06T22:02:35Z")
This is great! ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [March 7, 2024, 7:57pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/9 "2024-03-07T19:57:33Z")
While supernova is a cool tool, it's difficult to actually do anything with the documentation if you don't have a paid membership. For this reason I'm reverting back to Word, but I really like the stylization of supernova. I will be formatting my docs to match this. Use Web Layout to get a continuous page, set up headings that are more distinctive, and enable the navigation pane. Also include styles for inline code and property name callouts - all in this word template. [Ignition Word Template.zip](https://forum.inductiveautomation.com/uploads/short-url/p23JC11ZEF6zLsl0tZtVprj1Dev.zip) Use Notepad ++ with the languages feature and the NPP Export plugin to [copy formatted code into the doc](https://www.youtube.com/watch?v=oaaPUqmTP00). (I also use a centered 8" table, hidden borders, and [disabled spell check](https://www.youtube.com/watch?v=p0llBMdp320) to make them look nice.) I've created a language for Notepad++ for Ignition's Expression language. - Maybe someone (@paul-griffith) at IA can get on GitHub and get a complete version into the source. The one below is a work in progress and may change as I use it and find things I missed. [N++ Expression.txt](https://forum.inductiveautomation.com/uploads/short-url/szaQvjRlRSmIj91d9eyt2CxLBVW.txt) (change extension to XML and import into Language/User Defined Language/Define your language) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 7, 2024, 11:26pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/10 "2024-03-07T23:26:31Z")
It's not really feasible to generate a "master list" of expression functions, because each module can add new ones. If N++ supports it, you could just consider "every word character that isn't inside quotes or a curly brace" a function identifier. I think the only non-numeric literal supported is `null`. Also, for posterity, I'm about 85% sure expressions are case insensitive, at least the functions. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 8, 2024, 1:31am UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/11 "2024-03-08T01:31:36Z")
> [@paul-griffith](#): > > I think the only non-numeric literal supported is `null` `true` and `false`, too. I thinks that's it, though. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [March 8, 2024, 2:13pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/12 "2024-03-08T14:13:21Z")
Of course, modules would not be included. Just the native Ignition expressions. Is there somewhere in the Ignition folders where the functions are stored? - if so, there's also probably somewhere for the functions included within a module. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [March 8, 2024, 2:16pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/13 "2024-03-08T14:16:14Z")
And none of those are case-sensitive at that. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 8, 2024, 2:57pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/14 "2024-03-08T14:57:11Z")
> [@amarks](#): > > somewhere in the Ignition folders where the functions are stored? No, they are pure code. A module's hook class is handed a function factory during startup and is expected to register its implementations. [https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/gateway/model/GatewayModuleHook.html#configureFunctionFactory(com.inductiveautomation.ignition.common.expressions.ExpressionFunctionManager)](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/gateway/model/GatewayModuleHook.html#configureFunctionFactory(com.inductiveautomation.ignition.common.expressions.ExpressionFunctionManager)) But see also the JavaDoc comments here, especially for `.getFunctionNames()`: [https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/common/expressions/FunctionFactory.html](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/common/expressions/FunctionFactory.html) Note also that the factory can be retrieved from a module context, like that provided by `toolkitCtx()` in my Integration Toolkit: [https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/common/model/CommonContext.html#getExpressionFunctionFactory()](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.30/com/inductiveautomation/ignition/common/model/CommonContext.html#getExpressionFunctionFactory()) ---
**Author:** ![csjohnson](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@csjohnson](https://forum.inductiveautomation.com/u/csjohnson)\ **Post date:** [March 10, 2024, 2:58pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/15 "2024-03-10T14:58:14Z")
Just a thought, Could Ignition’s help/manual page framework be offered as a documentation tool? It could be included as an option for every project, offering sectional topics that we create to document the project. Might be a pipe dream as you could do the same with Markdown perspective components. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 20, 2024, 3:31pm UTC](https://forum.inductiveautomation.com/t/design-systems-documentation-tools/51509/16 "2024-03-20T15:31:23Z")
> [@pturmel](#): > > `true` and `false`, too. I thinks that's it, though. For posterity, since I went ahead and did the legwork for another post: `true`, `false`, `None`, `none`, `null`, `xor` and `like` are the only keywords accepted. Also, for fun, today I learned you can specify exponents in a double literal. So `1.0e5` is (should be) a valid expression.