Comments/Ratings for a Single Item

In my opinion, we should add a diagram with conventional graphics (could be Alfaerie SVG, HG's Interactive diagram, Musketeer C. board design tool, ...) every time there is a diagram with the abstract set. It can be afforded to have both, so everyone will be happy. And it will be clear for everyone :=)

I'm spinning off a discussion from Sac Chess around piece set images to a separate thread (moving the last two which didn't discuss Sac Chess at all, but leaving a couple that are split-subject).

what do you see as a disadvantage for using Interactive Diagrams as the main diagram? -- H.G. Muller

I see two minor downsides to the interactive diagram as the main/first/only setup display: it takes a little longer to load, and after making use of the interactivity it is no longer a setup diagram (requires a refresh, or is there a button for reset now?).

The interactive diagram has the benefit of also supplementing the Piece descriptions (position-specific and interaction-specific piece rules are needed in addition, and for accessibility a text move description should always appear) and giving some Playability.

What I think would be nice is to have buttons over the graphic which switch all page graphics between the options. -- Greg Strong

A graphics selection button would be nice, although of course it wouldn't apply to pages requiring (or otherwise using) custom images. Perhaps even better, we could take to setting some more user-specific configurations, and let a logged-in user automatically use their favored piece set when possible?

Fergus requested I use [abstract diagrams] Kevin Pacey

If I found the comments you're referring to, I wouldn't characterize it as a request, and I'm sorry if it came across as an editorial request. You should feel free to use whatever graphics you want. (I guess I should caveat that: we do strongly encourage using the site's tools when possible for consistency, and using piece graphics that are traditionally used for corresponding pieces.)

There is a 'Restart' button in the AI panel (which would start a new game, but shuffle the pieces in case of a shuffle variant), as well as a |< navigation button for getting back to the initial position of the current game (undoing all manipuations that were made so far). But you would have to open the AI panel to see those buttons. I never payed much attention to this, because the browser refresh seems an alternative that works just as well.

Slowless in loading is in a sense a self-inflicted problem: I let the Diagram script intentionally delay 1 second before executing the code that creates it. This was to solve the problem that comment pages contain multiple Diagrams, each of the comments referring to the script (because at the time they were posted the user assumed he would have the only comment with a Diagram on that page). If the first Diagram then immediately starts executing the script, the other Diagrams might not have been loaded yet. Ideally the script should only execute after the page has completely loaded. I tried to do that using onload="Init()", but that never was executed. Probably I was doing something wrong, but I have no idea what.

In principle generating the Diagram with the script should be very fast, probably faster than loading a dedicated image. Because the JavaScript and piece images should all come from the browser cache, if you have viewed other pages with Interactive Diagrams and the same pieces from the same set before. A dedicated image would be specific for the page you are loading, and you would most likely not have seen it before.

I see two minor downsides to the interactive diagram as the main/first/only setup display: it takes a little longer to load, and after making use of the interactivity it is no longer a setup diagram (requires a refresh, or is there a button for reset now?).

I tried to better address these points now. The Diagram can be reset to its original position by right-clicking on an empty square in it. Right-clicking on a piece summons its move diagram. (The latter is a feature I always wanted to have, but it was spoiled by that pesky context menu that the browser would pop up on using the right mouse button. I finally figured out how to suppress that for right clicks on the board.)

I altered the initial message displayed above the board to announce this possibility to the unwary user. I hope this does not make the message too long for very small boards. Perhaps I should make the font side dependent on the board width.

I also shortened the timeout used for initializing the Diagram from 1 sec to 100msec. I hope this doesn't lead to problems.

Very nice!  This has come a long way.  One small glitch I noticed is that if you click to move a piece and then right-click to reset, the banner still says "position after (half)move 0" rather than returning to its original state.

Sorry I didn't respond sooner to the question about why I don't use the interactive diagram as the main diagram.  I think it was primarily because I wanted complete control over how the board looked.  Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

First, I am assuming you cannot change the rank/file notations.  This is generally unimportant, but there are exceptions.  For example, in Brouhaha, the files have different names so that the main portion of the board still has the usual files a through h.

Second, to the right of the board, I was listing the pieces and locations using the long-standing format of the Chess Variant Pages.  I then started adding the array FEN (perhaps not useful to some, but very useful to others as the most compact descripton of all the pieces, their starting locations and notations.)  If it was possible to add text below the piece list for the optional specification of array FEN, or whatever the author wanted to write there, I think that would be sufficient.

Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

Well, the options to color the squares and use arbitrary sets of piece images has been there from the very beginning. What is a relatively recent addition is that you can also enable a rim with coordinates around the board, and specify the color and letter color of that.

About the coordinates: there already is an option 'firstRank' which you can use to specify how ranks are counted. (And then enables the display of the coordinate rim.) I don't have something like that for the files, as I couldn't imagine this would ever be needed. Bfore 1 comes 0, and indeed some variants count 0-9. But what comes before 'a'? Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

I did not quite understand the other request. You are referring to the 'satellite' that can be embedded in the text to display the pieces as clickable items in an 'unnumbered list'? Would the FEN have to appear as the last item in that list? The list would only be added if you embed the HTML <ul> directive with the proper satellite id in your text. I could easily make it such that items you already specified in that list remain at the bottom of it after the Diagram scripped has filled the table with the piece items. If you want the FEN to appear below the table, you could write it there yourself in the HTML. Or do you expect the Diagram script to generate the FEN? Not all sets of piece IDs would allow a position to be encoded as FEN, though. (There could be multi-letter IDs, of some pieces might have the same ID.)

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

The obvious remaining reason to favour static images over the interactive diagram is that the latter only works with Javascript enabled. I suppose the obvious(?) way around that would be to also have the design wizard generate a link to a Diagram‐Designer‐ or Scalable‐Diagram‐Editor‐generated (if the latter gets installed?) image and wrap it in <noscript> tags?

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

The same is true for the first two comments to be moved to this thread, when viewed through the main comments page (EDIT: and apparently this comment too; the comment editing form has the following warning above it: The ItemID 836609b4fd3c40eb no longer matches any item in the Item table.)

the options to color the squares and use arbitrary sets of piece images has been there from the very beginning

Ok, sorry.  Not surprising that my memory is inaccurate ...

Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

Yes, my post was a standard reply.  Don't know what happened here, but probably another glitch of the site move.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

There is a problem, though: I see that you are using 'x' and 'z' for the edge files on your Brouhaha page. But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator. There must be some restrictions on file labels to make notation work. If it was only a matter of choosing what to display in the margin of the board diagram it would not matter what labels you choose. (As long as they are not so large they would not fit in a cell the size of a square.) But the SAN generator and move parser must also be adapted to use those labels.

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

Well, the Interactive Diagram is just an element in the HTML page you would submit as an article or comment. It would be entirely up to you to design the rest of the page. You just embed the Diagram and its 'satellites' in the page you design by inserting a HTML tag pair with the proper id (or, for the board element, with class="idiagram") in the place where you want those to appear. The board element will contain the Diagram's specification, which will be deleted by the script, and then all the recognized elements (board diagram, piece table, piece list, piece descriptions) will be filled with the proper content according to the specs.

There only would be a problem if you would want to have extra text embedded in the elements that are filled by the script, because anything you write there would be replaced by what the script generates for that element. The reason for having the script generate those elements, rather than have the user write them, is usually that they contain clickable items that must invoke functions of the script. It would not be very hard even for an HTML-ignorant user to supply a list of pieces and their starting squares (by using the WYSIWYG mode of the editor), but clicking the pieces would then not summon the move diagrams.

[Edit] Perhaps we get away with the 'x' in Brouhaha: there are only Brouhaha squares on that file. They can never be destinations, and SAN would never mention a square of origin unless there is a need to disambiguate. And since the piece starting on this square is color-bound, and its Brouhaha squares for the same player are of different color, disambiguation for a Cleric move would never be needed. So the 'x' would never appear as a square coordinate in the move notation, and the fact that the move parser assumes it will never be a square coordinate will not hurt.

But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator.

This is an excellent point.  ChessV doesn't use SAN at all and I'm not really familiar with it so this didn't occur to me.  Probably best that I change the extra files to 'y' and 'z'.

Probably best that I change the extra files to 'y' and 'z'.

Well, if it is important for backward compatibility you could keep the 'x' for Brouhaha, as I explained in the edit of my previous posting. I suppose there aren't many other variants where simple a-... file IDs would not be satisfactory. Perhaps Omega Chess.

I think that there is very little reason to ever use anything else than consecutive letters to indicate the files, so a general way to define arbitrary individual names seems like overdoing it. A satisfactory solution would be to define 'w' as the letter preceding 'a' (to avoid xyz), and count backwards through the alphabet when more-'negative' letters are needed. So for Brouhaha we would use 'w' and 'i', and could describe the system by specifying a simple offset (e.g. firstFile=w). Another possible system would be to define the number of 'extra files', which would be assumed added to the board proper both left and right, and would have their own system of letter assignment from near the end of the alphabet. The first file of the proper board would then always be 'a'.

(I think I've fixed the subject title for comments in this thread; it wasn't an artifact of the site move, but rather of me not being thorough enough in database edits when I moved over the two first comments.)

I'm not really concerned about backwards compatibility, but on further consideration it is probably not worth modifying the program for this. It would make the program more complicated for very little gain. It is a very unusual use case, and there will always be some games that its not going to accommodate (Alice Chess, Backlash, Viking Chess, Marseillais, etc.) And since you mention Omega, yes, it has even stranger square naming. The four extra "Wizard squares" are annotated w1, w2, w3, and w4.

Well, as a compromise I introduced a parameter fileOffset (default value 0), which determines how much the normal file labeling is shifted to the right (white POV). Where the alphabet is treated as a cyclic set a-w. This means that for fileOffset=1 the left edge gets labeled 'w', and the right edge just gets the next character in the normal sequence (so 'i' for Brouhaha. This was easy to do, and offers at least some improvement for the rare case one would want this.

This would not allow pasting of Game-Courier notation into the Diagram for Brouhaha (assuming the preset there uses the labels x and y), as GC always mentions the square of origin, and the Diagram would not recognize those labels. But I guess GC notation would not be accepted anyway, as it has a space between piece ID and the coordinate move. (This could probably be solved by making the parser ignore all strings of length 1, though, as the piece ID is redundant.) But relatively simple pre-processing of a GC game with a text editor (globally replacing 'y' -> 'i' and ' x' -> ' w') could solve that.

For Omega Chess the wizard squares would become w0, w11, k0 and k11. As the Wizards starting there are also color bound these are not very likely to appear in game notation, unless you would actually move something to those.

The Interactive Diagram can now also generate the list of pieces and their starting square as lines of text, rather than as a table (like it was doing in the original posting of this Diagram). Whether one or the other method is chosen depends on how you embed the piece list on the page. In both cases the HTML tag pair that indicates the point where the list will be inserted will have to have id="pieceList". When the tag having this id is an unnumbered list (<ul>), the Diagram script will fill it with clickable list items for the pieces. When it is a paragraph (<p>) it will create text lines from clickable spans to describe the initial piece set up, like in the example below.

I am not sure whether the blue text for reminding people that the text can be clicked is optimally placed; there seems enough room to put it behind the 'White:' header on the same line.

Note that the starting squares of black pieces are now also mentioned. This is another improvement; only the white pieces used to have their starting squares mentioned. Because those are the only coordinates the user must supply when specifying the Diagram. For the black pieces one usually depends on the symmetry setting (mirror or rotate) to deduce the black starting squares from the white. The Diagram now converts the deduced starting squares to text form so that it can give them for the black pieces even in those cases (and for asymmetric setups displays those as given by the user).

The obvious remaining reason to favour static images over the interactive diagram is that the latter only works with Javascript enabled. I suppose the obvious(?) way around that would be to also have the design wizard generate a link to a Diagram‐Designer‐ or Scalable‐Diagram‐Editor‐generated (if the latter gets installed?) image and wrap it in <noscript> tags?

Indeed, this is what I have done in my own articles that use Interactive Diagrams as principal diagram. I don't think a special application would be needed to generate the static image; once people would have created an Interactive Diagram to their satisfaction, they can simply take a screenshot of it to obtain an identical static image, and upload that.

But there are two different issues here: (1) how we could streamline the submission process, and guide the user to submit articles in a form we like to have them, and (2) what we would like best, and whether we should make an effort to give the CVP website a facelift to cast existing articles authored by people that have left long ago in that form.

For the moment I would like to focus on (2). If we all agree that the Interactive Diagram at its current stage should be preferably used as principal image of the initial setup, I am in favor of starting working towards that goal, and replace the images there are now by Interactive Diagrams (with 'noscript' static backups). We can argue about how perfect the Diagram representation has to be in order to be superior to a static image. (E.g. should the AI work perfectly, work at all, or would it be sufficient to just use it for summoning move diagrams and highlighting piece moves?) Or how poor the image that there is now should be in order for replacement by anything whatsoever to be an improvement.

I would for instance be in favor of replacing all ASCII diagrams, even for games the Diagram cannot actually play (yet?), and even when some of the more quirky rules (such as turning a piece of choice into a King when you lost your old one) can not be implemented when the Diagram is operated by the user. Even a static screenshot of the Diagram would be an improvement there.

I have already started churning out Diagrams for all variants in the Alphabetical Index that are playable, and can be made to look like the static image the article is using now (if not ASCII). I think I worked my way all through 'a' now. A problem is that the CVP seem completely unorganized as to available piece graphics; some of the diagrams use piece images that are probably available, but I have no idea where to find those.