Chess Board User Interface

I'm sure this idea has a real name, but I don't know what it is. So I call it the "chess board" approach to UserInterface design.

On a chess board:

The pieces are different colours, so that you can easily tell which pieces belong to which side.
The pieces are different shapes, so that you can easily tell which pieces are of which type.
The squares are arranged in rows and columns, so that you can easily see, for example, which squares this rook can move to.
The squares are different colours, so that you can easily see which squares each bishop can move to.

What I'm trying to get at is: there's a lot of information packed into a chess board, but it doesn't get overwhelming. When I look at the board, if I ask myself, "Where are the kings?" my brain instantly picks them out. If I ask myself, "Where can this bishop move to?" my brain instantly focuses on those particular diagonals. If I ask myself, "Where can this rook move to?" I instantly see that, too - the differently-coloured squares (which help me with the bishop) don't distract me when I'm thinking about the rook. My brain just... focuses on the right thing.

I don't need any "tools" to accomplish these feats. I don't need a BlackPieceViewer tool or a BishopMovementViewer tool. The information is just all laid out for me, right there on the chess board, all at the same time, and my brain just picks out the things that it wants to focus on.

I want more user interfaces to work this way. :) In particular, since I'm a programmer, I'd like to have a programming environment that works this way. Yes, it's cool that I can ask Smalltalk to call up a class hierarchy browser so that I can think about the system from that point of view - but I think it would be even cooler if the system was just all laid out for me, right there on the screen, and when I want to think of it in terms of inheritance my brain could just instantly pick out the inheritance tree, the same way it can instantly pick out the kings on a chess board.

Problem is, I don't know how to accomplish it yet. ;) I learned these ideas from DavidUngar, and the environment for the SelfLanguage does a decent job of chess boarding a few different points of view, but there's still a long way to go.

-- AdamSpitz

Reasons we don't have a chess board interface for software development:

Most software projects are much more complicated than a chess board. Any chess board contains at most 32 pieces, each occupying one of 64 locations by itself. A software project can have millions of pieces occupying millions of locations.
Every chess game uses the same rules as every other chess game. Each software projects has its own rules.
Chess boards aren't really that easy to understand without years of experience. We rarely have that luxury with any given software project.

-- EricHodges

Sure, every program is different. So I'd like to be able to teach my programming environment new points of view. ;) --adam

But do you want to make programmers learn a new "point of view" for each project? Or would they be better off learning a few "points of view" that can be applied to every project?

I'm not just trying to rain on your parade to be a jerk. I'm sharing the rain that has fallen on my own parade. -- EricHodges

(moved to SelfAssembly)

Another problem is that although the basic information is there on a chess board to see, you'll never be any good at chess without inferring broader patterns from that data. Does either side control the center squares? Is your king vulnerable? Are your bishops, rooks, and queen trapped behind a wall of pawns, or are they free to move around?

Players learn to make these analyses and hold them all in their heads, which is why high-level chess is such an intensive, deliberative, and bloody slow sport. A programmer can make a lot of similar analyses of code in her head, but if software development moved as slowly as chess we'd all be fired. So development environments & tools are supposed to make all this smarty-pants analysis obvious to a programmer of any ability, and the work gets done more quickly. In theory. -- francis

Francis, I agree with everything you say about chess, but I'm drawing completely the opposite conclusions. Yes, a good chess player thinks about higher-level abstractions, but I don't see this as a "problem". You're not seriously arguing that a good chess player would play with the same quality and speed on a poorly-designed chess set, are you ? I think we both agree that writing down comments about a chunk of code makes development much faster than trying to hold everything in our heads. Currently I can finish a game of chess *much* faster than I "finish" a program, so I don't understand the "slowly" comment. -- DavidCary

I think a good chess player will play with the same quality and and almost the same speed on a poorly designed chess set. Good chess players can play with coins in the sand. The representation of the board and pieces has very little to do with how they play. -- EricHodges

I don't want to start an argument about semiotics, but: Chess pieces on a board are not a representation of the game. They are the game. There is no underlying meaning of the pieces that can be expressed in another form. Certainly chess journalists use a notation to describe the moves of a game in a newspaper column, and any computer program that plays chess has its own internal data structures to store the locations of pieces, but chess started centuries ago as a physical, spatial thing. It's only later that we added other ways to represent it.

This matters because in software it's quite difficult to locate a similar level of "realness". What's the most essential form of a computer program? The machine instructions that make up the compiled binary? The source code? (The UnitTests?)

It's all made up anyhow. We program with IDEs written by other programmers in the 90s in languages spec'd out by other programmers in the 80s which compile into machine instructions invented by other programmers in the 70s. Once the thing you do is that ethereal, and that non-physical, you might as well have a proliferation of views. Hell, you could call high-level languages just another view if you want; this sort of thinking peeks through in a pattern like AlternateHardAndSoftLayers. It's all machine instructions, in the end. How many programmers have enough geek-fu to program in machine instruction? -- francis

Too late, you started an argument about semiotics. Since the board can be made of lots of things, can look lots of different ways, can be paper or bits or words vibrating through air, it seems to me that the the pieces on a board are not the game. Pieces and boards are one way players communicate during the game. The game is going on in their nervous systems. -- EricHodges

When I saw the word ChessBoardUserInterface, I thought we would be talking about GlyphChess? by Jeff Breidenbach http://www2.parc.com/asd/members/jbreiden/glyphchess.html . I've already asked Breidenbach about making a open-source version, and he told me that as long as I use public-domain bar codes (rather than the proprietary, patented DataGlyph?), that should be fine. Now I need to write some code and come up with a catchy name. ChessOnaScanner? ? -- DavidCary

Here's an example of the kind of thing I'm talking about.

In Smalltalk, there's a tool called a Class Browser, which is where we do most of our coding. There's also a tool called an Inspector, which shows you the instance variables of a single object (and lets you play with that object by sending messages to it and stuff).

In Self, on the other hand, the main coding tool is called an Outliner. An Outliner is a lot like a Smalltalk Inspector, in that it shows you a single object, but it's different because it lets you see and edit the method slots and data slots of that object.

Do you see what happened here? In Smalltalk, when you want to switch between those two particular points of view ("looking at this object" and "writing code for this object") you have to switch tools (from an Inspector over to a Class Browser). In Self, because we use Outliners for both of those points of view, switching between those points of view really is as simple as switching your focus between the rook's moves and the bishop's moves.

That's what I'm trying to get at here. I'm not trying to figure out which points of view we want to see (though that's an interesting question too). I'm saying that instead of creating a new "tool" for each point of view, it's useful to try to put lots of points of view on the screen at the same time, in such a way that our brains can switch between them as easily as they can pick out the white bishops on a chessboard.

--AdamSpitz

The information is just all laid out for me, right there on the chess board, all at the same time

Well, except that it isn't. As simple as chess is, the board can't handle it. Can that pawn there capture en passant? Can you castle? The board won't tell you. Heck, the board doesn't even tell you which sides you and your opponent are supposed to sit on. --AnonymousDonor

That's exactly the issue that started me thinking about these ideas. :) A friend of mine was complaining that a chess program was showing him "too much" information - where each piece could move, whether a pawn could capture en passant, stuff like that. "It's like cheating," he said. "The player should have to figure that stuff out in his head." So we asked him, "Why are the squares different colours?" --AdamSpitz

While it's true that the rules of the game are not written on the chess board, and there is no attempt to record all the possible openings and endings on the board, everything relating to the game's current state is exposed. Compare most card games. Not only is the opponents thinking not visible, the game's state is hidden. Chess is among what I like to call "pure games" in that all state information is right in front of both players. Othello, Abalone, checkers (Chinese and Western), and so on all share this attribute. When I'm developing, I really prefer environments that expose all state info (or at least as much as I want) so I don't have to engage ESP mode. -- GarryHamilton

Which software development environments don't expose all state info? I can't think of any. -- EricHodges

Then I envy you. I spent all too much time putting in printf() statements to figure out the state of the program at a particular time, then taking them back out again (or surrounding them with "if debug" switches). I far prefer debuggers that let me single-step the program, and display the state of all the local variables, especially the ones I forgot to print out. -- DavidCary

The representation of the board and pieces has very little to do with how they play.

Demonstrated by the existence of simultaneous blindfold exhibitions.

There's a patently false claim about chess made on this page, namely that a good chess player will play the same quality chess regardless of how bad the chess board is. It is very easy to find out empirical data that disproves the claim. The standard of games played in blindfold tournaments (google for Amber blind chess) is below that of normal tournaments; mistakes and very poor strategical decision are abounding as opposed to regular tournaments. In a regular tournament, any self-respecting grandmaster will refuse to play with a board and pieces that are sub-standard quality, and as a matter of fact the international federation standardized minimum requirements in this respect. Good chess players can play with coins in the sand or with no pieces at all, but their game will be an order of magnitude below their real value.

While playing chess, the visual help you get from a good chess board is extremely important. -- CostinCozianu (accidentally having in-depth knowledge of the subject)

Costin is right; not even a serious amateur player will agree to play a game with e.g. those cute little decorative figurines they sell in gift shops. Pieces must follow the classic standardized Staunton style for good pattern recognition. Corollary: don't buy those decorative sets with gnomes/unicorns as gifts for anyone who actually plays chess. -- dm

And to bring it closer to home, the pattern is obvious in the importance of mathematical notation. No mathematician would consider reasonable to write formulas and proofs entirely in prose like they did from old greeks up to and including Newton. Likewise no one can argue that machine code is just as easy to program in as assembly language (although for all intents and purposes machine code and assembly are almost the same thing. A bad notation will cripple even a good mathematician or a good programmer.

"Developing a UI Design from a UML Color Model: Chessboard Layout Pattern Revisited" (Who wrote this?) http://www.uidesign.net/1999/papers/UML_UI.html mentions "The Chessboard Layout Navigation Model" for user interfaces.

Perhaps some alternatives to the standard chess board interface could help us imagine analogous alternative user interfaces to "the same" program.

Somewhere (?) I saw an unusual chess board. One could play a standard game of chess on it. However, the chess "board" was solid white with black lines -- so all squares were the same color. Also, the pieces were placed on the intersection of lines (like go) rather than in the squares between lines. Also, the lines were diagonal, which made seeing "to where could this bishop move?" easier than on a standard chess board.

The "Noble Celts Board" http://www.thegamesjournal.com/articles/GameSystems3.shtml seems to be topologically equivalent to a standard 8x8 chess board.

CategoryUserInterface