about using winboard

[hgm]

An unintended consequence: clearing the board is no longer useful, as there is no method left to create a piece from nothing. Only to clone an existing piece, possibly mutating its type afterwards. This is fine when starting from the palette, or making small modifications to an existing position.

But in variants like Chu Shogi, with 2x36 piece types, it would be very cumbersome to set up a late-end-game position with 3-5 piece by deleting all types you don't need from the palette. (Even though this now only takes a sigle right-click.) Even when the pomoted pieces are absent from the palette (pieces can be promoted after they are put on the board), you still would have 2x21 piece types.

It is hard to find a satisfactory solution to this. Sweep selecting also turns into a disaster with so many piece types: there is not enough room to perform the required sweep. Repeated clicking to step through all types becomes also quite tedious, even though you would have to span the full range only once: you could start from a 'cleared' board with only Kings, clone those through multi-drop, adjust the type of the clone by repeated clicking to the next type you need, clone that one, etc. Still up to 21 extra clicks for each side...

Perhaps it would be useful to have a partial board clear, which does not touch a 4x4 area in the center of the board. Then you could drag the pieces you need there, and clear the rest of the palette, leaving a custom 'mini palette' in the center from which you then can redistribute the pieces, if you only needed a small number of those.

[Ras]

This duplicates the board, so that it doesn't matter that the dialog covers the original one.

Exactly, that is the point. Since it's a new dialogue, and since it's modal, it will vanish after editing, so it doesn't have to be aligned to the rest of the GUI. It also circumvents the question how to open up another window with a "tool box" so that it doesn't open in an annoying place. Plus that it offers buttons to shift the whole position left, right, up and down, and to mirror it horizontally and vertically. Especially useful for endgames.

From a programming point of view, I guess it's also easier because you keep the actions within the same dialogue window. With a tool box, you'd have to interrelated windows, which is more effort to code, especially when avoiding spaghetti coding. The interaction of this modal with the rest of the program is limited to copying the position there and back. The dialogue is smaller, yes, but since it replicates the board position, it doesn't matter.

I guess the reason why it isn't just as large as the main window is to make it clear on the first sight that this is not the game board. The modal dialogue opens in front of the main window, and since you still see the main window, you know that both are different. Trying to activate the main window while editing in the position dialogue gives the MS-Windows reaction for "no, the foreground dialogue is modal" so that the user knows this dialogue has to be finished first. The MS-Windows reaction at least under Win7 is to make the frame and title bar of the modal dialogue blink several times.

So any dialog can pop up with the current variant in mind, leaving variant switches the exclusive domain of the New Variant dialog.

Makes sense. Especially that the user must have been using that variant dialogue before or else he would not see something other than chess, so the user must know how to do it.

The problem with variants is more that some variants have more pieces than others, and that a dialog like Shredder's don't look so nice anymore in Chu Shogi, where there would be 2 x 36 piece types next to the board.

At least not with two columns, that's right. But two 6x6 fields would work. Remember that we're on desktop, and horizontal space is cheap, especially since 16:9 monitors took over.

But wait a minute here. In the current implementation, this is a GUI, i.e. a visual interface, where the user shall use mouse gestures that lack any visual cue, in order to scroll through an invisible list of 36 (in words: thirty-six) different items?!

The clocks indeed serve no function in Edit Position mode, and the space they take up could thus be repurposed for other functions.

Violates the principle of the least surprise. Of course, at least styling that as buttons would not violate this principle as much as it does now, where text and graphic don't convey the same message. Then again, if you were to opt for some kind of tool box, these buttons would belong there anyway. Or in a dedicated editing modal as with Shredder.

[Ras]

The 'context popup' I had was this:

A context menu is for context related actions. It is not a mini-help to explain misdesigned, overcomplicated procedures.

The thing I am not sure of is how to best treat an attempt to drop on an occupied square.

Replace whatever is there. That is the simplest mental model for the user.

I can conceive a setup mode that uses 'select once, place many" for an internal palette too, however:
* right-click on a piece => piece disappears, and type gets selected
When a piece type is thus selected:
* left-click occupied or empty squares => selected type is put there
* right-click on empty square => deselect the current type
When no piece type is selected:
* left click on a piece grabs / selects the piece for moving
* right-click on an empty square pops up an explanatory note

Too many different things dependent on too many conditions. That is exactly the kind of convoluted thinking that makes for bad user interfaces.

[hgm]

The problem with variants is more that some variants have more pieces than others, and that a dialog like Shredder's don't look so nice anymore in Chu Shogi, where there would be 2 x 36 piece types next to the board.

At least not with two columns, that's right. But two 6x6 fields would work. Remember that we're on desktop, and horizontal space is cheap, especially since 16:9 monitors took over.

But wait a minute here. In the current implementation, this is a GUI, i.e. a visual interface, where the user shall use mouse gestures that lack any visual cue, in order to scroll through an invisible list of 36 (in words: thirty-six) different items?!

For the sweep selection that would be true, and I fully admit that for such a large number of pieces sweep selection fails miserably. (I already mentioned that in my previous posting; you cannot even make a large-enough sweep to get through the entire list unless you zig-zag downward at a very oblique angle).

This is why I implemented the 'palette board', which contains every piece type only once, in their standard initial location. Arbitrary 6x6 arrays of pieces do not work very well, because it becomes too difficult to locate the piece you need between all the images. But users can be expected to know the initial setup of the variant they are playing. But in general that does not produce a square array, and that would drive up the spece needed by an external palette even more.

Displaying two board side by side, one empty, the other in the initial position, could be a possible solution. The full board can be used to select the piece type, and this can then be dropped in one or two copies on the empty board. You would need to cover a lot of left-right distance, however. When the piece type to drop is set to that of a moved piece, so that type selection is doe on the board itself, everything starts much closer to its destination.

[Fulvio]

Displaying two board side by side, one empty, the other in the initial position, could be a possible solution.

Two boards? How much do you hate your users? Do you think they have two mouses and they need to click simultaneously on both boards?
Maybe it is better to look at how others have already solved similar problems? (I have a strange feeling, maybe I already said this before?)
https://support.apple.com/en-us/HT200290

[hgm]

Replace whatever is there. That is the simplest mental model for the user.

Well, I am not so sure. It is just a 'collision' between two behaviors, the universal one that clicking something is selecting it for moving (true in every mode), and the exceptional one that it means drop (only the case in Edit Position). I played a bit around with it, and it felt somewhat unexpected when cliking something would replace it by somethig else, rather than just grabbing it. Drops on non-empty squares strike me as weird. (But perhaps that is Crazyhouse/Shogi influence.)

It is a bit of a moot point, as normally it should not happen that during setup you want to put something where you first put something else. So it s usually a consequence of an error.

But I guess the most important thing is this: if you expect the piece you click to be replaced, but it is instead selected, little harm is done, because you can now move it aside by clicking a neignoring square, and then continue dropping the piece I was dropping on the now evacuated square. If OTOH I expected to select the clicked piece for moving, and it disappears, error recovery is much more cumbersome. The piece I presumably misplaced is now gone, and I have to select it again for dropping to get it back where it belonged. And then select the piece type I was dropping again to continue with that. I experienced it as really nice that I could move pieces without interfering the dropping, and could continue dropping the same type after moving stuff out of the way.

[hgm]

Two boards? How much do you hate your users? Do you think they have two mouses and they need to click simultaneously on both boards?

Two mouses? You make no sense at all. I guess the SCID board is just 1x1 rather than 8x8, because your users don't have 64 mouses?

[Fulvio]

Two mouses? You make no sense at all.

Add a "Select piece" button.
The user clicks on it and you display the initial board with a clear visual indicator that now clicking on a piece makes it the current-piece (apple display a cross in the top-right corner and makes the icons wobble).
The user clicks on a piece selecting the new current-piece and restoring the normal board: he can now add the piece where he likes.
It's not rocket science.
I can't imagine if you had to design the Photoshop or AutoCad interface.

[hgm]

This idea (the 'pseudo popup) was already discussed in this thread, (except that a right-click replaced the button), tried out, and found to be absolutely the most awful experience I ever head. I still get the shivers if I think about it. Evert was right: having to go click something that just appeared is at least an order of magnitude more inconvenient than clicking something that has already been visible before you decided you wanted to click it.

Have you tried it?

Judging how well something works is just not possible without actually trying it out. Things that look good on the drawing board might not be acceptable in practice at all.

[Fulvio]

I still get the shivers if I think about it. Evert was right: having to go click something that just appeared is at least an order of magnitude more inconvenient than clicking something that has already been visible before you decided you wanted to click it.

Have you tried it?

While I'm thinking if I ever tried it before, let me try to click on this strange thing "File": omg!! A strange thing that wasn't there before appeared! How can I cope with that? They must be insane! How can they expect me to click on something that wasn't visible before!
But maybe it is just a coincidence, let me try to click on this strange thing "Computer Chess Club: General Topics"... omg!! A lot of thing that weren't there before can now be clicked!! It is so scary and confusing!
It is so much better to not show things only when they are needed.

Anyway let me see if I understood your various statements correctly:
- ChessBase design is "pretty awful" (and they placed 12 piece-types on the right side of the board).
- "having an external palette is truly problematic when 72 (colored) piece types would have to be displayed next to the board."
- "Displaying two board side by side, one empty, the other in the initial position, could be a possible solution."
- Displaying the piece-types on request is "absolutely the most awful experience I ever head. I still get the shivers" because "having to go click something that just appeared is at least an order of magnitude more inconvenient than clicking something that has already been visible before you decided you wanted to click it"
- "Perhaps it would be useful to have a partial board clear, which does not touch a 4x4 area in the center of the board."
- "The thing I am not sure of is how to best treat an attempt to drop on an occupied square". The intention of the user when dragging a piece over is to achieve an "automatic termination of the multi-drop series, and select the clicked piece for moving"