Elements of the ULTIMATE Chess GUI?

[hgm]

That happened with me the day before when I tried to add stockfish to xboard 4.9.1

I was referring to the "strong words". And yes, it happened to me the other day as well, when I wanted to check how many options Rodent actually had (as it was mentioned here as an example of an engine with many options, and I happened to have Rodent III on my disk), and I forgot to tick 'USI'. Did't cause my blood pressure to raise, though.

OK. Here I am. I'm complaining.

Well, your complaint is duly noted. Protocol auto-detection is at the top of the list of possible features to add now.

I'v not praised Shredder here,

Sure, but others did here, and I heard such sentiments voiced many times before. I just mentioned it as an indication that apparently leaving the protocol choice entirely to the user is not such a big deal with users.

[Fulvio]

The sequence

> xboard
> protover 2
< unknown command: xboard ? => UCI
< feature ... ? => WB v2
< Error (unknown command); protover ? => WB v1
wait 1 sec
> uci
< uciok ? => UCI
wait 1 sec
WB v1

seems a reasonably reliable protocol determination, and could be made default.

Please don't.
We are at the end of year 2017, and my computer have 4 core.
Your first thought should be to start 2 different sub-process in parallel, one for UCI and one for xboard, and just kill the one that do not respond (or the one that you think is inferior for multi-protocol engines).
This way you do not have to wait 1 sec (wtf) and it works 100% of the times.

[gbtami]

And yes, it happened to me the other day as well, when I wanted to check how many options Rodent actually had (as it was mentioned here as an example of an engine with many options, and I happened to have Rodent III on my disk), and I forgot to tick 'USI'.

Then you can imagine how often this can occur with users knowing nothing about protocols at all.

Well, your complaint is duly noted. Protocol auto-detection is at the top of the list of possible features to add now.

Great, thx!

I'v not praised Shredder here,

Sure, but others did here, and I heard such sentiments voiced many times before. I just mentioned it as an indication that apparently leaving the protocol choice entirely to the user is not such a big deal with users.

UX is a big deal IMO.

[Fulvio]

'Extra here means nothing else than "what they don't happen to need, for their limited interests". If that is not what you understood from it.

Let me quote myself again, maybe you'll learn to think about different points of view before replying:

but the program should "ask" only the necessary information

[hgm]

Your first thought should be to start 2 different sub-process in parallel, one for UCI and one for xboard, and just kill the one that do not respond (or the one that you think is inferior for multi-protocol engines).

This certainly is an idea worth consideration (thx), but I also see some dangers. E.g. if the engine you try to launch by default tries to grab almost your entire machine's memory. Cores are not the only thing to consider (starting up a program is usually not CPU-intensive anyway, it is more a disk-i/o thing).

Because I run non-WB engines through a protocol adapter, it would certainly make life a lot easier to launch one process with adapter, and the other without, and then kill one. If an engine started directly would turn out to respond to 'uci' I could not use it anyway, but would have quit it, and start the adapter instead. The adapter should detect non-response to 'uci' in that case, and communicate that to the GUI (e.g. through "telluser this does not seem to be a UCI engine"), which in the auto-detect phase would prompt the GUI to send it a 'quit' command, and continue with the other process.

When the egine that got the 'protover 2' command responds with features, the proces with the adapter can get a 'quit' immediately. (Do UCI engines reliably accept 'quit', or are there that hang when they do not receive an 'isready' first?)

When 'feature done=1' is received from the UCI adapter, and there is no response within a reasonable time (say 1 sec) to 'protover 2' in the direct process, the engine can be assumed to be UCI only. A 'quit' can then be sent to the direct process, and the I/O channel for the adapter process would somehow have to be transferred to that of the direct process (i.e. what used to be considered engine #3 should now be considered engine #1 or 2).

[hgm]

Let me quote myself again, maybe you'll learn to think about different points of view before replying:

but the program should "ask" only the necessary information

That is a completely useless statement, when the GUI cannot possibly know what is necessary and what not, in the case at hand...

Or, in another view, it is simply not true. The program should ask for everything that might be necessary to do the job. Otherwise there will be cases where it fails to do the job.

Another problem is that you seem to have a funny notion for what "asking" means in the context of a UI. Which leads to these false restaurant analogies. When you deal with waiters, there is a profound difference between them 'asking' you stuff, and them 'listening' to information you might volunteer. 'Asking' compells you to give an answer, 'listening' doesn't compell you to say anything, but will take note of it when you do.

That is not different in a UI. There are things you must obligatorily do in order to proceed (such as clicking 'OK' or 'cancel'), and there are things you can completely ignore and it would only speed up progress, but the UI is still paying attention if you volunteer something. This is what makes your restaurant analogy of the Load Engine dialog so silly. In practice the waiter is not asking anything at all, other than "that's it?" ('OK') at the end. One could argue that it should at least compell you to provide an engine name, (i.e. ask "what would you like to order?"), by disabling the OK button as long as that text entry is empty. But that is a bit of a moot point, as in practice not even an idiot would try that.

[Ferdy]

Here is the page and some entries so far.
https://docs.google.com/spreadsheets/d/ ... r4/pubhtml

Of course I am very pleased that you rate WinBoard/XBoard so well on most counts. At the risk of seeming greedy, though: I am a bit puzzled that you rate the piece and board graphics only 6 out of 10. Because these are nearly infiitely configurable. E.g. for XBoard several dozens of piece themes are available, from the very conventional (like Alpha or Meridia) to the extreme. There also is the choice of nearly 100 square textures. Some examples:


Condal


Leipzig


Kilfiger


Fantasy


Freak

What I had in mind for attactive design - board and pieces is about the overall look of the GUI. Right I change the rating of this feature to 10.

Added Graphic category: Attractive design - overall view
Not sure about its exact name, but something like below image. I rate Fritz as the highest at 10.

[hgm]

This is extremely subjective. The image you show above looks absolutely awful to me, to the point where it hurts my eyes to look at it. I would probably rate it one of the worst. Way too crowded.

I do see a lot of red squares with crosses in the various sub-windows, so I suppose these can be closed to ameliorate matters. Which is good, as I see a lot of stuff that would not be relevant to me, while other stuff (clocks, engine logos) seems to be missing. So perhaps it is a consequece of opening too much at the same time, so that my opinion would be more favorable if it was configured for a particular application, say an engine - engine game. What I consider attractive is a quiet, minimalistic design with as few distracting elements as possible. Something like:



It has what I want to see, (board & clocks, engine ID, analysis and game navigation) and nothing else.

Specific things that for me count as a big minus are:
* The 'ribbon' along the top, which seems to have the function of a main menu, but selectable by tab rather than as a pull-down menu. It is cluttered with totally non-informative pictograms (of very inhomogeneous size). Just listing the explanative text in a small table, as a conventional pop-down menu would do, would already be enormously better.
* Much space wasted around the board, seemingly for no other purpose than fitting the bar of navigation buttons. That it can look nice to have a rim around the board (where you could for instance write the board coordinates), OK. WinBoard you can optionally do that too. But this doesn't look like a board rim at all, just like a board asymmetrically nailed to a wall. And it doesn't even seem room to show square coordinates.
* The buttens in the navigation bar are too conspicuous, and the pictograms on them non stadard. I have no idea what the blue curved arrow could mean.
* The engine names in the kibitz windows are written both in the window title bar and in the window directly below it. What's the point of that? Depth, score and move are written both at the top and at the bottom within the window. The way it is written at the top is ugly; it makes the window look inhomogeeous/irregular.
* The Notation - Openings Book window also has such an inhomogeneous header inside it; this seems a general design theme of this GUI that I don't like. It seems that the info there could have been easily put in the title bar, which seems now just to contain a fixed text. (Which, incidentally, doesn't see much to the point.)

[Evert]

This is extremely subjective. The image you show above looks absolutely awful to me, to the point where it hurts my eyes to look at it. I would probably rate it one of the worst. Way too crowded.

I do see a lot of red squares with crosses in the various sub-windows, so I suppose these can be closed to ameliorate matters. Which is good, as I see a lot of stuff that would not be relevant to me, while other stuff (clocks, engine logos) seems to be missing. So perhaps it is a consequece of opening too much at the same time, so that my opinion would be more favorable if it was configured for a particular application, say an engine - engine game. What I consider attractive is a quiet, minimalistic design with as few distracting elements as possible. Something like:



It has what I want to see, (board & clocks, engine ID, analysis and game navigation) and nothing else.

Specific things that for me count as a big minus are:
* The 'ribbon' along the top, which seems to have the function of a main menu, but selectable by tab rather than as a pull-down menu. It is cluttered with totally non-informative pictograms (of very inhomogeneous size). Just listing the explanative text in a small table, as a conventional pop-down menu would do, would already be enormously better.
* Much space wasted around the board, seemingly for no other purpose than fitting the bar of navigation buttons. That it can look nice to have a rim around the board (where you could for instance write the board coordinates), OK. WinBoard you can optionally do that too. But this doesn't look like a board rim at all, just like a board asymmetrically nailed to a wall. And it doesn't even seem room to show square coordinates.
* The buttens in the navigation bar are too conspicuous, and the pictograms on them non stadard. I have no idea what the blue curved arrow could mean.
* The engine names in the kibitz windows are written both in the window title bar and in the window directly below it. What's the point of that? Depth, score and move are written both at the top and at the bottom within the window. The way it is written at the top is ugly; it makes the window look inhomogeeous/irregular.
* The Notation - Openings Book window also has such an inhomogeneous header inside it; this seems a general design theme of this GUI that I don't like. It seems that the info there could have been easily put in the title bar, which seems now just to contain a fixed text. (Which, incidentally, doesn't see much to the point.)

+1
(I would guess that the blue arrow is an "undo"/"take back" button, which I sometimes miss in XBoard).

Of course it depends very much on what you want to do. If you're looking into different variations in an analysed position, you want the variations to be prominent and the board can be smaller (in fact you may want several). Normally, I want the board to be the most prominent, which means as large as possible.

[Ferdy]

This is extremely subjective. The image you show above looks absolutely awful to me, to the point where it hurts my eyes to look at it. I would probably rate it one of the worst. Way too crowded.

I do see a lot of red squares with crosses in the various sub-windows, so I suppose these can be closed to ameliorate matters. Which is good, as I see a lot of stuff that would not be relevant to me, while other stuff (clocks, engine logos) seems to be missing. So perhaps it is a consequece of opening too much at the same time, so that my opinion would be more favorable if it was configured for a particular application, say an engine - engine game. What I consider attractive is a quiet, minimalistic design with as few distracting elements as possible. Something like:



It has what I want to see, (board & clocks, engine ID, analysis and game navigation) and nothing else.

Specific things that for me count as a big minus are:
* The 'ribbon' along the top, which seems to have the function of a main menu, but selectable by tab rather than as a pull-down menu. It is cluttered with totally non-informative pictograms (of very inhomogeneous size). Just listing the explanative text in a small table, as a conventional pop-down menu would do, would already be enormously better.
* Much space wasted around the board, seemingly for no other purpose than fitting the bar of navigation buttons. That it can look nice to have a rim around the board (where you could for instance write the board coordinates), OK. WinBoard you can optionally do that too. But this doesn't look like a board rim at all, just like a board asymmetrically nailed to a wall. And it doesn't even seem room to show square coordinates.
* The buttens in the navigation bar are too conspicuous, and the pictograms on them non stadard. I have no idea what the blue curved arrow could mean.
* The engine names in the kibitz windows are written both in the window title bar and in the window directly below it. What's the point of that? Depth, score and move are written both at the top and at the bottom within the window. The way it is written at the top is ugly; it makes the window look inhomogeeous/irregular.
* The Notation - Openings Book window also has such an inhomogeneous header inside it; this seems a general design theme of this GUI that I don't like. It seems that the info there could have been easily put in the title bar, which seems now just to contain a fixed text. (Which, incidentally, doesn't see much to the point.)

Fritz GUI can be customized. You can remove/add boxes, logos, clock etc. according to your needs.