Chess GUI Concept

[berdelyi]

Not long ago I started thinking about what I would like to see in a Chess GUI, I'd love to hear thoughts from others.

I started to design a Chess GUI concept (just out of interest, I'm not planning to develop it... though if any developers are here and wish to collaborate let me know). So far there are only buttons for preferences, add/create (database and game), toggle for views (game list, openings and analysis) and a search.

What do you like to see most in the user interface? Any preferred information or format you would want to see in the game header, game annotation analysis and game list?



I then tried streamlining the interface with tabs (do people really want to see all tabs in one view?)

[lucasart]

You're doing the typical mistake of newbies, or wannabe provrammers. Starting with the cosmetic and trivial things.

First, you need to solve the real problems of writing a GUI:
* spawning sub-processes and talking to them via standard IO
* asynchronous IO to be able to timeout and kill hanging engines
* boiler plate chess code, to generate legal moves, which you need to validate move legality
* PGN parsing, including SAN decoding

Come back to the cosmetic aspects once you've done that.

Trust me, no one is going to do the work for you, and just let you do the easy "drawing part". That's not open source dev works…

[H.G.Muller]

What do you like to see most in the user interface?

It completely depends on what applications you are designing the GUI for. I notice for instance that none of your designs shows clocks, which would make it unsuitable for playing against an engine (or remote opponent) or playing engines against each other. This suggests you are only designing for PGN editing, database access and analysis.

Personally I dislike designs where I do see all information all the time. As much of the information is of no interest to me, so it is merely a distraction, and eats away space for information I do want to see. If I am doing interactive analysis, I want to see as much analysis lines as possible, perhaps filling 60% of the display, next to a chess board of modest size that I can use to enter moves. A game list, opening specifications, game headers are totally irrelevant for me at that point. There might be no games to list, as I might just be analyzing a single game from a PGN file, or even copy-pasted into the GUI as a table of moves from some website. So I only want to have a game list in my display if I am actually working from a database with games.

Game annotation hardly ever interests me. (I guess this is because I rarely deal with commented games. In a PGN with many comments it would become important info. And in a game with many recursive variations it could become an important game-navigation aid.) So I would perceive its presence as an annoying wastage of display area. For 'random access' to a certain game position an 'evaluation graph' (present in the original PGN, or added by analysis with an engine) is much more meaningful to me. I can the use it to quickly focus on moves where the evaluation jumped (i.e. blunders).

Don't worry about the common "must have" stuff Lucasart mentions. This will not distinguish you from the many Chess GUIs that already exist. Making all that is simply work, often with standard solutions on which cannot be improved. The only reason for creating a new GUI would be to offer something in the user interaction that people experience as pleasant, and no other GUI offers.

[berdelyi]

@Lucasart I disagree with your comments. A lot of programming does start with designing the interface. What you described do not appear to be "the real problem" of designing a GUI. I am interested in designing a GUI, I'm not expecting others to do the coding. In fact, I don't think the drawing is the easy part as I think the UI is just as important and integral as other aspects.

[berdelyi]

Thank you for such a detailed response.

It completely depends on what applications you are designing the GUI for. I notice for instance that none of your designs shows clocks, which would make it unsuitable for playing against an engine (or remote opponent) or playing engines against each other. This suggests you are only designing for PGN editing, database access and analysis.

You're right. Features I care about most are as you describe and less about playing against an engine or a remote player. Doesn't mean these are the only features I would consider.

Are there any features you really like in any apps or think are missing?

Personally I dislike designs where I do see all information all the time.

This is what I'd like to solve. I know there are apps where specific features can be hidden or visible as well as resized. In apps like this its sometimes too flexible and then easy to get the whole display confusing.

Thanks for your use cases. I will think about those cases a bit more as well.

[H.G.Muller]

Well, I am used to XBoard, which uses separate windows for various pieces of information, which can be opened or closed at will. The Evaluation Graph certainly is an element that I consider useful, for some applications (e.g. analyzing given games). Also the possibility to add or edit comments to the moves can be useful; XBoard has a separate Edit Comment window for that. Of course these could be displayed and edited in the Game Annotation itself, but it might have some benefits to separate moves and comments, and only display the comment on the currently displayed position. As a feature, I like to be able to see the analysis lines spewed out by engines played out on a board (on user request). This doesn't necessarily require new screen elements; seeing it on the main board in reaction to clicks in the analysis lines would also be a possibility.