Fulvio wrote: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!
Yes, remarkable, isn't it? That for pull-down menus it doesn't seem a problem, but that when you do it with a board with pieces it is disastrous. I have no real explanation for that. (Two dimensional?) I would not have believed it if I wouldn't have experienced myself. You obviously haven't.
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).
Correct. I guess my main gripe is that click-click moving does not work, while this is how I usually move pieces around.
- "having an external palette is truly problematic when 72 (colored) piece types would have to be displayed next to the board."
Correct. The average distance you would have to move to select a new one becomes rather large, and it becomes difficult to find the one you are looking for if they are just arbitrarily crammed into a square table (like 12x6 or 8x9)
- "Displaying two board side by side, one empty, the other in the initial position, could be a possible solution."
Indeed, by organizing the exteral palette like the initial position, people would know where to look for the piece they need, even if there are a lot. They would not have to examine all the images until they see the right one, but would know its locationn. Basically the difference between a O(N) linear search and O(1) hashing.
- 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"
Correct. If we would rate WinBoard's currently implemented method as 8, ChessBase as 5, I would say this one was -2. Surprising, but true.
- "Perhaps it would be useful to have a partial board clear, which does not touch a 4x4 area in the center of the board."
That specifically applies to a design using an internal palette. An alternative would be to have a 'Select all', and then a way to deselect a few pieces (e.g. by Shift + click) followed by 'Delete', to just keep a selected few. This is the more conventional method (e.g. for deleting files in a folder).
- "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"
I don't recall having exactly said that about "intention". The issue is whether moving a piece should then automatically select that type for dropping as well. After some experimenting things appear to work most smoothly if you don't, (just stick to the type you were dropping before, even when things get moved), and just leave the drop-type selection for a (destructive) right-click, i.e. a 'delete piece' rather than a 'move piece' action. Provided that you only allow drops on empty squares.
So in short, I get the most pleasant user experience from
* right-click on piece = delete it and select that type for dropping
* left-click on empty (when nothing selected for moving) = drop the selected type
* left-click on piece = select that piece for moving
* left-click when piece is selected for moving = move piece there (and deselect)
The latter two are "business as usual"; moving of pieces always works that way. The first two would be additions specific to Edit Position. The first one is the on-board alternative for selecting by a click on an off-board icon, and the second is how you then populate the board with it. In other modes clicking empty squares as 'from-click' is ignored. (Nothing there to grab.) Both empty and occupied squares are valid as 'to-clicks' for a move, depending on whether it is a capture or not. So the idea is that moving has priority over dropping, working exactly as usual, and that actions that would be ignored for ordinary moving would now be used for dropping.