Elements of the ULTIMATE Chess GUI?

[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.

[Ras]

It seems you are criticizing engines here, not the UI.

I'm astonished to learn that you have started agreeing with Postel's principle and the erosion of standards it causes.

But the problem with that is that the filenames in Windows can contain spaces

The obvious solution: quotation marks.

Which is extremely user-fiendish.

It isn't. Just automatically add the quotes when selecting the exe via the file selector box. Or already start it with a quotation mark and only add in the closing one from the file select, something like this.

Setting up positions from the 'pallette position' and using copy/move works very fast for me.

It works for you because you know how. Another key factor of GUI design is discoveribility, and Winboard completely fails here.

So how does the reverred Shredder GUI deal with WB v1 engines?

WB2UCI, and possible failings of that adaptor are completely irrelevant as I'm not talking about FEATURES. Yes, there are engines from crappy times that "need" this ugly INI file hell. This whole mess was one of the main reasons for UCI, after all.

Having to open dialog after dialog would be extremely annoying to me.

You don't open dialogue after dialogue. Once e.g. the WB/UCI dialogue closes, the one with the select box opens automatically.

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

*LOL* This is UI design with a big hammer applied in the user's face.

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?

Maybe it's different in tournament mode, but for the most basic usage of analysis and interactive play, there's only one engine at a time. I've not yet tested tournament mode because people do that with Arena, so that's my test environment.

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

Or Go, maybe. Or Poker. Who cares? It's about CHESS GUIs, see the title of this thread. If Winboard isn't about chess anymore, that's OK, but then Winboard is offtopic at least in this thread.

The whole point is that you can give the naturally stronger egines more time odds than the weaker ones.

Just another feature that I'm fine with as long as I can ignore it and it doesn't get in my way. Again, it is not about the amount of features. I'm under the impression that you simply have no clue at all what my criticism of lousy UI design is about. Which of course explains said design.

This sounds completely detached from reality.

Certainly completely detached from any reality where you'd regard Winboard as a good example of UI design. Taking a UI that was already bad under Linux and then expecting Windows users not to be put off seems really strange to me.

And the menus are organized in a task-oriented way.

The menus. *sigh*

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.

Anyway, Xboard already sucked under Linux.

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.

It isn't about how something looks. It's about usability issues. There is a reason why you don't see any, and it isn't their absence. It's pretty pointless to take that discussion further.

My conclusion: asking for a great GUI in a programmer forum where no designers and usability experts are present will only lead to a total UI desaster, but at least one that runs under Linux.

[hgm]

I'm astonished to learn that you have started agreeing with Postel's principle and the erosion of standards it causes.

That is unwarranted. We are talking about an older standard here. There are many engines that are no longer maintained that were written according to that standard.

It isn't. Just automatically add the quotes when selecting the exe via the file selector box. Or already start it with a quotation mark and only add in the closing one from the file select, something like this.

So what if they don't use the file-selector box and type the name?

It works for you because you know how. Another key factor of GUI design is discoveribility, and Winboard completely fails here.

Well, I admit that position setup has always been my greatest worry in WinBoard. But I am not prepared to make it infinitely cumbersome just to make it discoverable. Now that I am finally happy with a method through which it can be done, it is time to start worrying how to improve the discoverability of this method.

WB2UCI, and possible failings of that adaptor are completely irrelevant as I'm not talking about FEATURES. Yes, there are engines from crappy times that "need" this ugly INI file hell. This whole mess was one of the main reasons for UCI, after all.

As I understand it, this "INI hell" is the only method for running WB engines in Shredder GUI. If the GUI just delegates the entire task to an entity external to it, no wonder it can look very simple. The Load Engine dialog in WinBoard that strike you with so much horror did not exist at all originally. You could just use NotePad to edit an ini file. By your logic this would be the perfect UI, no distracting controls.

You don't open dialogue after dialogue. Once e.g. the WB/UCI dialogue closes, the one with the select box opens automatically.

Well, you have to do something to make it close, right?

*LOL* This is UI design with a big hammer applied in the user's face.

Well, as an expert user I would still prefer it VERY MUCH over what you describe of Shredder...

Maybe it's different in tournament mode, but for the most basic usage of analysis and interactive play, there's only one engine at a time. I've not yet tested tournament mode because people do that with Arena, so that's my test environment.

Well, so we can take this as another "can't do" for Shredder? It can be simple and intuitive because you actually have to use Arena instead?

Or Go, maybe. Or Poker. Who cares? It's about CHESS GUIs, see the title of this thread. If Winboard isn't about chess anymore, that's OK, but then Winboard is offtopic at least in this thread.

Japanese Chess and Chinese Chess are just as much Chess as the Mad Queen variant you seem to be hooked on. They need exactly the same from a GUI. And WinBoard would never be off-topic, because it also does Mad Queen, even if it is not the only thing it can do.

That you try to make a big issue of the existence of 3 of the hundreds of dialog controls / menu items (the "New Variant" menu item, and the "Force current variant with this engine" and "USI/UCCI" checkboxes) that are related to variant support totally undermines your credibility...

The whole point is that you can give the naturally stronger egines more time odds than the weaker ones.

Just another feature that I'm fine with as long as I can ignore it and it doesn't get in my way. Again, it is not about the amount of features. I'm under the impression that you simply have no clue at all what my criticism of lousy UI design is about. Which of course explains said design.

No, the problem is that "doesn't get in my way" thing, or your concept of "being able to ignore it". You seem to equate those to "as long as they are not there". Because it is easy enough to "ignore it" where it is now in the usual meaning of the word, yet you make a big fuss about it. I understand your criticism very well, but you just pick the wrong examples. Time odds is only one of the possible "Special WinBoard options". I have not added checkboxes or numeric entries for every conceivable WinBoard setting you might need to make a newly registered engine work as you intend, for the very reason that these are needed only rarely, and their presence would just confuse noob users. Less is always better, in my philosophy. But I must provide some way to allow expert users to activate those features. It is easy to claim you are not against features, but what good are features that can never be exercised??? So I managed to reduce the entire list of weird features that expert users might want to invoke to just a single "Special WinBoard options" text entry.

I can add that many of the controls were actually added on user request from non-programmer users.

Certainly completely detached from any reality where you'd regard Winboard as a good example of UI design. Taking a UI that was already bad under Linux and then expecting Windows users not to be put off seems really strange to me.

That is what I meant by "totally detached from reality". Nothing of the kind ever happened, except in your fantasies. The UI of WinBoard is completely separate from that of XBoard, and always has been. It is just the "business logic" for handling games and communicating with engines that they have in common.

The menus. *sigh*

Well, that is what we are talking about here, right? Or are you claiming now that this is about command-line options?

It isn't about how something looks. It's about usability issues. There is a reason why you don't see any, and it isn't their absence. It's pretty pointless to take that discussion further.

It must be about how things look, because in the end that is all the program does: show you something to look at on the screen. So it is all about which controls should be present, how they should be distributed over dialogs, and when those dialogs should be shown. There just is nothing else.

[Fulvio]

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.

Some things are not a matter of taste, they are just wrong.
For example he is right about the engine's parameter field: many engines do not need it and should not be showed by default (but it should be possible to set the parameters with an "advanced configuration" or with a "+/-" icon that show/hide the most uncommon options).