Elements of the ULTIMATE Chess GUI?

[hgm]

I am naturally very interested in what GUI features people would appreciate. So I compiled the following list, giving an overview of what people mentioned in this trhead so far. With a comment of my own indicating whether this feature is already implemented in WinBoard/XBoard, or how far we are away from that:

Code: Select all

- Winboard and UCI compatibility
  CHECK
- Attractive design, board and piece set/s ( and including attractive multi-PV analysis display - unlike Arena)
  CHECK (although 'attractive' is a subjective qualification)
- Round Robin, Gauntlet and Swiss Tournaments
  CHECK
- Custom Opening Books (hopefully with ability to import/convert other books)
  CHECK
- Ability to clearly display UCI options for engines with a LOT of options (Rodent, Texel, Pro Deo, Gambit Fruit etc)
  CHECK? (Might benefit from an extra scroll bar or paging?)
- TB usage/adjudication
  CHECK
- Openings study features
  ? (Variaion trees: CHECK)
- Open EPD and PGN files
  CHECK
- Game user-adjudications
  CHECK
- Attractive Engine logo and rating display during matches
  CHECK, no ratings
- Rodent and Pro Deo built-in (assuming permission from Pawel and Ed Wink )
  YEGH! :-(
- Beautiful engine tournament crosstables and engine rating changes on-the-fly (like Arena, but with beautiful visuals)
  Not implemented (relies on external dedicated tool, which seems preferable)

- Cross platform.
  CHECK (available as WinBoard fro Windows, and as XBoard for Liux / Mac)
- Lite on hardware resources.
  CHECK
- Highly customizable
  CHECK
- Vector images
  Only in XBoard (SVG); WinBoard has scalable font-based piece rendering, though

- Very flexible adjudication options. That is an area where ChessGUI is ahead of anything else.
  Pretty basic (But should be trivial to add)
- For a repeating time control, allow it to be specified in minutes and seconds and not just minutes
  CHECK

- A "Guess the Move" feature like in this prog: https://sites.google.com/site/fredm/. Scroll a little bit down.
  CHECK? (Is't this what 'training mode' does? I never used that.)

- It is important to turn off all the features not wanted, and to make sure that blank features do not continue to be displayed.
  CHECK

- Knockout Tournaments
  Not implemented
- Ability to run TLCV broadcasts.
  CHECK
- Adjustable adjudication settings.
  Not so many

1. Wilhelm would show the hot squares for winning endgames graphically. A fabulous teaching tool.
  No
2. Arena has a setting that shows every attack square for the side to move. Truly ingenious. It could be improved on by drawing arrows from the attacking pieces.
  No
3. There should be a feature to play the pv like a movie. If there are two engines, pick a pv and play it. Then pick the other pv and play it.
  CHECK
3b.And the third option would be to play the combined pv to the point where they differ, if the first move or some of the first moves are the same.
  No
4. Be able to store game logs as a collection of EPD records (that's for me).
  No
5. Heat maps from a collection of games would be nice.
  No

- don't lag and don't cause losses on time, like Arena does
  CHECK
- don't force user to work on text files, hand-type engine paths etc. like Winboard does
  CHECK
- exit gracefully, killing the engine processes (problems with Arena again)
  This could be a fundamental Windows problem
- extend both Winboard and UCI protocols by adding "chat" command, by which engine can display something in a separate window (comments, evaluation details, trash talk, whatever). Rodent would gladly talk to its opponents, but unfortunately it cannot rely on "info string" UCI command, which is often ignored
  CHECK (both in the Engine Output window and as separate popup notice)
- if the engine supports either UCI_Elo or some kind of level command (Stockfish style), implement usage mode that increases level when user wins and decreases it when user loses
  ot implemented
- integrate PolyGlot book creator, so that it can be used from the GUI level (Scid allows editing existing books by changing move probabilities, but I'd like to be able to pick several pgn files for white and for black, and then create a book at one go)
  CHECK
- integrate stuff like ChessArtist by Ferdinand Mosca (it is a Python script that returns game analysis)
  ?
- Winboard is great with its time odds implementation
  CHECK
- automatically create web pages with a pgn of a current game/current collection of games
  Uses external tool for that

- support for all the current standards of Chess960.
  CHECK
- swiss tournaments with 5000 engines or more.
  CHECK (?) (Not sure whether there is currently a limit to the number of players, but if there is, increasig it should be trivial)
- rated tournaments/matches
  ? (Seems better to leave that to an external tool of choice?)
- swiss tournaments with initial bonus points so that strong engines never face much weaker ones even in first round.
  Not implemented (McMahon system)
- swiss tournaments with scaled Time Controls so that weak engines play faster than strong engines.
  ?

- Supporting two computer match via wireless Wi-Fi and not causing connection issues (game stop midgame). Alternatively Null-Modem USB works fine.
  Doesn't seem a GUI task
- 6-men syzygy adjudication.
  No. (But EGT-based adjudication is a perverse feature...)
- Draw adjudication (like cutechess)
  Not implemented
- Resign adjudication
  CHECK

- The possibility to perform interacrtive analysis a la 'IDEA' in Aquarium.
  No

- When there is an engine/engine contest, show the first place the pv's disagree. TCEC uses an @ sign by default, but you can also configure it to use color.
  Not implemented

- I also like the graphs for depth/time/speed/tb hits.
  Not implemented

- Open source
  CHECK
- Work on Windows,Linux,Mac OS...
  CHECK
- Customizable
  CHECK (?)
- Possibility to use a scripting language to make plugins : best way for users to add new features to the program
  ?

- Ability to run multiple instances of the GUI at the same time, either each running totally different matches/tournaments, or all working on the same one.
  CHECK

- great "New game" screen. Select Human/Engine for each of Black and White and specify (possibly) different time controls for each. It's really easy to set up a new human/human or engine/engine or human/engine game, whereas I don't find this at all intuitive in Arena or Winboard.
  Not sure what your gripe is with how WB does it now 
- Time controls for black and white can be different (ideally even using different systems).
  Only time odds

- While playing or analysing a game takebacks give a nice choice of Overwrite or New Variation.
  CHECK (?)
- DGT board support is good (via DGTDBDLL file), including takebacks, and I can quickly turn on/off DGT support from a button.
  No. (Better through pseudo-engine?)
- Starting a game from a set position or PGN file is easy.
  CHECK
- List of installed engines and their settings is in an easily accessed (and modified) text file 
  CHECK
- Has option to set a tournament to pause after current game has finished or when a particular engine/person is about to play.
  Not implemented
- In engine tournaments can specify how many games are in each pairing
  CHECK
- Ability to hold a tournament where openings are automatically replayed when white/black swap
  CHECK
- Ability to swap view between full display (e.g. including engine thinking lines, scores and history etc) and game mode display (just the board, clocks and move list) without losing any settings for each.
  Could be better

I put a question mark for features I did not understand what they should do.

[jdart]

Arena's engine setup screens are nice, and they make it easy to modify the engine settings after you have set them up, or do a one-time modification when you are setting up a tournament. Better than Fritz in this area IMO.

I use ChessBase extensively. It has a lot of features for game editing, and has publishing features. Of course integration with databases, both local and cloud-based. I use the "Novelty Annotation" feature a lot: this will go through the online database and highlight where the game's first novelty appeared, as well as key variations. Chessbase can create and edit book files (.CTG format only I think) and classify openings. It is a great program, but somewhat quirky, buggy and inconsistent in how it does things. The integration with Fritz is somewhat awkward: the two programs are different and have overlapping features. ChessBase also can be slow sometimes, even on a fast system.

None of the UIs I have have really sophisticated opening book features, such as handling multiple book formats, using backsolving (as in Bookup), support for learning via dropout expansion, etc. There is some room for innovation here I think.

--Jon

[gbtami]

- integrate stuff like ChessArtist by Ferdinand Mosca (it is a Python script that returns game analysis)

See https://github.com/fsmosca/chess-artist

- Possibility to use a scripting language to make plugins : best way for users to add new features to the program

You can see an example for this at Geany (editor) here https://plugins.geany.org/index.php?site=1.24/geanypy

[Ras]

Uh? Some engines need command-line options, e.g. to specify you want to run them in a GUI, rather than in stand-alone (ASCII) mode.

The first command is "uci" resp. "xboard". Problem solved, except with really stupid engines, of course.

How do you run a JavaScript UCI engine in Shredder GUI? (Or a Java engine? Or a Haskell engine?) In WinBoard you select Node.js as engine, and the .js file as command-line option.

I'd expect I'd just append some stuff after the filename for these corner cases.

What is bad there? You just select the engine from a combo-box...

This ugly startup dialogue shouldn't even exist. It's right in line with the whole list stuff and how to edit these lists. That is so 1990's XWindow stone age. But wait until you try to set up a board position, that's even worse, though that's hard to believe it's possible.

In contrast to what you think, WB v1 and UCI are NOT mutually exclusive. 'UCI' invokes the protocol adapter. This could conceivably use WB v1 protocol.

You know you have a serious design problem when you have to expose such details to the user. Especially because nothing here even tells anything about an adaptor.

Engine->Load 1st Engine in WinBoard is only 2 menu levels deep

Even if it was only one level deep, it wouldn't be better.

I WinBoard you could click that button straight away, without first selecting something to make something else open (5-3.5).

I wrote about the sequential process which is a feature and not a bug.

- You want to make the engine use the opening book

That's a GUI setting, not an engine setting. Therefore, there's a corresponding GUI option.

- The engine can only play Crazyhouse, and you want Shredder to switch to Crazyhouse whenever you load it. (Ouch... OK, replace Crazyhouse by Chess960.)

I don't know a single engine that can only play FRC. It's an academic corner case without any relevance. However, the Shredder GUI can deal with FRC, just as Shredder can, so that should also work somehow. Dunno how because I'm not into chess variants, just as 99.9% of the users, and I'm glad I don't have to cope with GUI bloat because of the other 0.1%. Maybe there are additional options in this case that are hidden otherwise.

- The engine is Java or JavaScript.

See above.

- Need to run an engine that requires "POS --io-mode xboard" as start command.

Oh yes, instead of just waiting whether the first command is "xboard", like all WB engines do. But well, there may be esoteric engines. That's the point, if you cram anything into a GUI so that the 0.1% of totally non-compliant and stupid engines may run, this overall approach will enerve the 99.9% of the other users. Enervation by a totally overloaded user interface.

Command line parameters shouldn't be necessary in the vast majority of the cases, and for the small percentage where it is, you can type after the filename.

- You want to handicap the engine by a time-odds factor.

Usually, the GUI is in charge of timing, that has nothing to do with the engine. Even IF the engine supports something like that, it should be one of the customisable uci or xboard commands.

So by objective measure WinBoard is 25% more user-friendly than Shredder. Your comment seems to lack any kind of objectivity. In fact it is close to the worst bullshit I ever saw...

I always appreciate your comments when it's about engines. But user interface design is a bit different, and Winboard is one of the absolutely worst chess GUIs I've ever seen. That's because it is an xboard port, but xboard was decades ago and in the XWindow stone age.

Winboard doesn't even remotely play in the class of the Shredder GUI. SMK wouldn't be able to actually sell Shredder with a GUI like Winboard because you can't slap paying customers in their face with something like Winboard. If you really think that user friendliness is about how easy the most esoteric corner cases are, this is so off the mark that it's not even funny.

Arena is a bit buggy, but guess why people prefer Arena to Winboard - although Winboard isn't buggy (or the bugs are fixed very quickly). And Arena isn't even exactly good GUI design, it's just not as bad.

If you want to understand why, just read my previous post. Feature oriented vs. task oriented, guiding a user through the tasks instead of bombarding him with features.. but that is only where it starts. UI design is way more than cramming features into a GUI. It's harder for you to even understand what it's about because you are a programmer, and programmers do not think like 95% of the users.

From what I get from this thread here, the probable overall result (if made real) would be a completely bloated and overloaded beast where average users would have no hope of even setting the time mode, but I'm sure it would have 2,000 cool features. None of them interacting, no kind of user interface design, no thought about user tasks - no, just cramming everything and the kitchen sink into as few dialogues as possible. This usability meltdown would probably be euphemised as "for power users".

[hgm]

None of the UIs I have have really sophisticated opening book features, such as handling multiple book formats,

Well, that is kind of hard, if most book formats are kept as proprietary secrets. It is also questionable whether it is a good thing to have this. It seems in geenral more useful to simply convert the books to the one format you want to support.

[giovanni]

From what I get from this thread here, the probable overall result (if made real) would be a completely bloated and overloaded beast where average users would have no hope of even setting the time mode, but I'm sure it would have 2,000 cool features. None of them interacting, no kind of user interface design, no thought about user tasks - no, just cramming everything and the kitchen sink into as few dialogues as possible. This usability meltdown would probably be euphemised as "for power users".

I want to really take this opportunity to thank all the people here that are developing the open source / free GUIs we are talking about. Personally, I use (and find useful) programs like Xboard, Arena, SCID and so on. Of course, I see the point raised by Rasmus, but I think that, instead of whining, we should be more constructive toward authors. For instance, many people could contribute code. Other people, like me, could provide tutorial or "how to" do specific tasks. Many people are not using all these features just because often users don't share their knowledge or don't provide motivating examples of what can be achieved with just a little effort. Let's not put everything on the author's shoulders.

[Ras]

but I think that, instead of whining, we should be more constructive toward authors. For instance, many people could contribute code.

Which would make things only worse. UI design does not work by compromise, you need one and only one consistent philosophy.

http://timothyblee.com/2010/11/15/open- ... aces-suck/

[hgm]

The first command is "uci" resp. "xboard". Problem solved, except with really stupid engines, of course.

It seems you are criticizing engines here, not the UI. Fact is that engines that need this do exist (by the hundreds...), and that a UI has the choice between being grossly incompetent or dealing with them. Complaining about them gets you nowhere.

I'd expect I'd just append some stuff after the filename for these corner cases.

Of course this is how I organized it initially too, in older versions. But the problem with that is that the filenames in Windows can contain spaces, (and in fact often do, due to the dreaded C:\Program Files) so that the UI cannot know what is the executable, and what are the arguments. So it would require the user to engage in tricky quoting in the command. Which is extremely user-fiendish. It gave rise to never-ending complaints of user who could not get certain engines to run because of spaces in their (path-)names. This is why I separated them. In XBoard there still is a single text entry "Engine command", where you can type both name of the binary and any necessary arguments. (Unfortunately there the browsing is cumbersome, as Linux tends to hide the binaries in directories like /usr/bin, /usr/games or /usr/local/bin.)

This ugly startup dialogue shouldn't even exist.

No argument there. XBoard doesn't have anything like it, and usually I just click it away in WinBoard immediatel by pressing 'OK'. (Not always, though; and it comes in very handy in software packages like the Shogi Variants bundle, where the user can then select the combination of engine / variant / board theme in a single stroke.) Doubting the usefulness of its existence is not at all the same as judging its design.

But wait until you try to set up a board position, that's even worse, though that's hard to believe it's possible.

I don't see how that reflects badly on the startup dialog. Setting up positions from the 'pallette position' and using copy/move works very fast for me.

You know you have a serious design problem when you have to expose such details to the user. Especially because nothing here even tells anything about an adaptor.

Well, rule number one for the noob when using any kind of software is "if you don't know what it is for, don't touch it!". I am also not happy that WB v1 even exists. But it does... So how does the reverred Shredder GUI deal with WB v1 engines? (Oops, wrong question! Of course it doesn't even know there is anything like WB v2, and cannot deal with it at all. And wasn't this the GUI for which WB support does not work at all, not even for v1, so that you have to resort to third-party adapters that have to be configured by editing cryptic configuration files?)

I wrote about the sequential process which is a feature and not a bug.

Features ca be helpful or they can be annoying. What could be helpful for people that do something for the first time, or are idiots incapable of learning, can become extremely annoying after the 10th time. Having to open dialog after dialog would be extremely annoying to me. Which fraction of the engine installs a user ever does on a particular UI would be the first time he ever installed an engine in it? If guidance is required for a first-time user, just printing fat numbers (1), (2), (3)... in front of the input controls he has to operate; these are more easy to ignore by the expert user.

- You want to make the engine use the opening book

That's a GUI setting, not an engine setting. Therefore, there's a corresponding GUI option.

You mean that you cannot specify which engines should use book, and which should not? That there is just a single GUI setting that makes either all engines use book, or none at all?

I don't know a single engine that can only play FRC.

There are plenty of engines that play only Crazyhouse, though. Or Shogi.

and I'm glad I don't have to cope with GUI bloat because of the other 0.1%.

Wow! 'GUI bloat' because of a single checkbox, which you can easily ignore if you are not into variants...

Oh yes, instead of just waiting whether the first command is "xboard", like all WB engines do. But well, there may be esoteric engines. That's the point, if you cram anything into a GUI so that the 0.1% of totally non-compliant and stupid engines may run, this overall approach will enerve the 99.9% of the other users. Enervation by a totally overloaded user interface.

Command line parameters shouldn't be necessary in the vast majority of the cases, and for the small percentage where it is, you can type after the filename.

You seem to live in a parallel universe. There are hundreds of engines that need this.

- You want to handicap the engine by a time-odds factor.

Usually, the GUI is in charge of timing, that has nothing to do with the engine. Even IF the engine supports something like that, it should be one of the customisable uci or xboard commands.

Of course it is a GUI option and not something supported by the engine. The point is that you want the GUI setting for it to depend on the engine instance. If all engines had the same time odds, they would just play at a faster TC, when you play them against each other. The whole point is that you can give the naturally stronger egines more time odds than the weaker ones.

'Installing' (more accurately: registering) an engine to the GUI is a GUI matter anyway; the engine would know nothing of this.

I always appreciate your comments when it's about engines. But user interface design is a bit different, and Winboard is one of the absolutely worst chess GUIs I've ever seen. That's because it is an xboard port, but xboard was decades ago and in the XWindow stone age.

Winboard doesn't even remotely play in the class of the Shredder GUI. SMK wouldn't be able to actually sell Shredder with a GUI like Winboard because you can't slap paying customers in their face with something like Winboard. If you really think that user friendliness is about how easy the most esoteric corner cases are, this is so off the mark that it's not even funny.

Arena is a bit buggy, but guess why people prefer Arena to Winboard - although Winboard isn't buggy (or the bugs are fixed very quickly). And Arena isn't even exactly good GUI design, it's just not as bad.

If you want to understand why, just read my previous post. Feature oriented vs. task oriented, guiding a user through the tasks instead of bombarding him with features.. but that is only where it starts. UI design is way more than cramming features into a GUI. It's harder for you to even understand what it's about because you are a programmer, and programmers do not think like 95% of the users.

From what I get from this thread here, the probable overall result (if made real) would be a completely bloated and overloaded beast where average users would have no hope of even setting the time mode, but I'm sure it would have 2,000 cool features. None of them interacting, no kind of user interface design, no thought about user tasks - no, just cramming everything and the kitchen sink into as few dialogues as possible. This usability meltdown would probably be euphemised as "for power users".

This sounds completely detached from reality. Yes, WinBoard might have 2000 features, controllable from the command line. But only a quite small fraction of those can also be controlled from the menus. There isn't anything in the menus that I don't regularly use. This is why things like "Edit Engine List" are still necessary to give power users access to all features.

And the menus are organized in a task-oriented way. It seems you just don't understand what the task encompasses. Most of what you say is plain nonsense. Like that having separate dialogs for entering the engine executable and the nickname would need 'guidance', rather than just side-by-side completion in the same dialog. Like the order in which the user does it would matter.

Being able whether the GUI book should be allowed to substitute for a given engine for me is an integral part of the task of registering a new engine, which I consider on a case by case basis. Claiming that the presence of a (pre-ticked) checkbox "Must not use GUI book" is so confusing to the user that it would cause a 'usability meltdown' just sounds like pure paranoia.

I am not saying that the WinBoard dialogs cannot possibly be improved. But I certainly don't want to make it as awful as what you describe for Shredder. I would be thinking more in the lines of putting the Nickname, Command-line Options, Special WinBoard options and Directory text entries in a group box labelled "optional / exceptional". And perhaps it is true that WB v1 is so uncommon nowadays that it would be better to delete that checkbox, and let expert users that would have needed it just type "/protocolVersion 1" in the "Special WinBoard options" text entry. (And have non-expert users just wait 5 sec for the feature timeout every time they load that engine.)

You recount of history is also off the mark. It is true that WinBoard is an XBoard port, but XBoard at that time had none of the menu dialogs. These were all designed from scratch, to make it easy to interactively perform the most common tasks.

Note also that this whole business of 'registering' an engine is not necessary in XBoard at all, for compliantly packaged engines. People would just install the engine in the package-management system of their choice (I always use "apt-get install" from the command line), and the engine would have automagically appeared in their engine list, so they can load it by just double-clicking on its name in the listbox in the left half of the dialog.

[hgm]

but I think that, instead of whining, we should be more constructive toward authors. For instance, many people could contribute code.

Which would make things only worse. UI design does not work by compromise, you need one and only one consistent philosophy.

http://timothyblee.com/2010/11/15/open- ... aces-suck/

For clarity, this is not really a coding issue. It is not like there are any barriers that require menu controls to be present in one place, and not in others. Chaging how dialogs look, or moving controls from one dialog to another is often just a matter of minutes. Adding new dialogs and menu items to pop them up perhaps only a matter of 15 minutes.

It shouldn't be difficult at all to make the menu interface look anyway you want it to look. It seems more a matter of taste; what one person thinks is great, makes the other puke.

[gbtami]

but I think that, instead of whining, we should be more constructive toward authors. For instance, many people could contribute code.

Which would make things only worse. UI design does not work by compromise, you need one and only one consistent philosophy.

http://timothyblee.com/2010/11/15/open- ... aces-suck/

Thx! This was an interesting reading. And https://daringfireball.net/2004/04/spray_on_usability also. And http://web.archive.org/web/200511251838 ... Reader$173.

Telling the truth UI/UX design is hard. Last year I talked about this with a professional UX designer, and hes first suggestion was to do some usability tests with PyChess. I think this will be an interesting experiment if I can find some time to organize it.