As for building it right into the submission form, I would prefer to not do that, for I have a competing tool, and I don't want to leave the impression that we're expecting people to make Interactive Diagrams. Also, each requires a different skill set, and each has different capabilities. However, I did rewrite the text to include a link to your page for making Interactive Diagrams.
I think it would be helpful to contributors to put some assistance for diagram creation in the submission form, no matter what type of diagram is used. Especially when this is helpful in generating other standard sections of the article as well, such as a nice table with verbal descriptions of the piece moves, accompanied by the image of the piece in question. Not everyone would know how to make such a table, and even contributers that do know might consider it too much of a hassle.
If there are alternative tools, so much the better. The submission form should and could support all available tools. Just as the form provides a pull-down menu for selecting whether you want to use plain Text, HTML or Markdown, we could have a switch that enables the user to specify whether he wants to include an Interactive Diagram (ID) or an image link to the Diagram Designer (DD). In fact I think he would always have to use the DD: the site policy is such that we want the website to also be usable with JavaScript turned off, and under those conditions the ID would not work. In every article where I included an ID so far I have always done it such that a static image (or DD link) was present in noscript tags, and the ID started hidden, and would require JavaScript operation to make it visible.
The point is that we should mentally separate what will be included in the article from the interface that is used to specify it. The trial submission form I made could be made to generate a link to the DD, and place it in the Setup section, just as easily as it now does for an ID. In fact even when the user would specify he wants an ID it should do both: the DD link in noscript tags, plus a hidden ID and a small JavaScript section to make it visible. If the user selects a DD image for inclusion, it should only place the DD image link in the Setup section, without any noscript tags.
Note that the ID script as I normally use it actually does two independent things: it generates a diagram according to specifications when the user loads the page, as a HTML table with all kinds of event handlers attached to the table cells. And it contains the code for the event handlers, which is invoked when the user starts playing with the diagram. These functions can be separated: the HTML table could be generated at submission time, so it gets stored in the database and downloaded by the client used to view the page. Even with JavaScript off the Diagram would then always be visible; it would just not react to mouse clicks anymore. I never do that, because the ID definition is far smaller than the HTML code for the table that it will create. (But even that would probably be smaller than a whole-board PNG or GIF image of the initial setup.)
For the HTML elements that are not part of the ID per se the submission page already uses the 'create at submission time' strategy: it fills the Pieces section with HTML code for a table with piece descriptions, rather than just putting an empty HTML element (like div) there, and letting the script fill it after the user loads the page. Because we want that table of pieces to appear on the page even when JavaScript is switched off. But also because for really complex pieces the automatically generated verbal description might not be satisfactory, and to give the user a possibility to fix that by editing.
I think it would be helpful to contributors to put some assistance for diagram creation in the submission form, no matter what type of diagram is used. Especially when this is helpful in generating other standard sections of the article as well, such as a nice table with verbal descriptions of the piece moves, accompanied by the image of the piece in question. Not everyone would know how to make such a table, and even contributers that do know might consider it too much of a hassle.
If there are alternative tools, so much the better. The submission form should and could support all available tools. Just as the form provides a pull-down menu for selecting whether you want to use plain Text, HTML or Markdown, we could have a switch that enables the user to specify whether he wants to include an Interactive Diagram (ID) or an image link to the Diagram Designer (DD). In fact I think he would always have to use the DD: the site policy is such that we want the website to also be usable with JavaScript turned off, and under those conditions the ID would not work. In every article where I included an ID so far I have always done it such that a static image (or DD link) was present in noscript tags, and the ID started hidden, and would require JavaScript operation to make it visible.
The point is that we should mentally separate what will be included in the article from the interface that is used to specify it. The trial submission form I made could be made to generate a link to the DD, and place it in the Setup section, just as easily as it now does for an ID. In fact even when the user would specify he wants an ID it should do both: the DD link in noscript tags, plus a hidden ID and a small JavaScript section to make it visible. If the user selects a DD image for inclusion, it should only place the DD image link in the Setup section, without any noscript tags.
Note that the ID script as I normally use it actually does two independent things: it generates a diagram according to specifications when the user loads the page, as a HTML table with all kinds of event handlers attached to the table cells. And it contains the code for the event handlers, which is invoked when the user starts playing with the diagram. These functions can be separated: the HTML table could be generated at submission time, so it gets stored in the database and downloaded by the client used to view the page. Even with JavaScript off the Diagram would then always be visible; it would just not react to mouse clicks anymore. I never do that, because the ID definition is far smaller than the HTML code for the table that it will create. (But even that would probably be smaller than a whole-board PNG or GIF image of the initial setup.)
For the HTML elements that are not part of the ID per se the submission page already uses the 'create at submission time' strategy: it fills the Pieces section with HTML code for a table with piece descriptions, rather than just putting an empty HTML element (like div) there, and letting the script fill it after the user loads the page. Because we want that table of pieces to appear on the page even when JavaScript is switched off. But also because for really complex pieces the automatically generated verbal description might not be satisfactory, and to give the user a possibility to fix that by editing.