GUI change workflow toolbar
This file is also (converted with pandoc from .md to .html) at http://www.maths.lse.ac.uk/Personal/stengel/NEWGUI/index.html
The current GUI for building game trees is not sufficiently intuitive for newcomers, and not systematically structured.
I experienced this when creating a game tree not just for algorithmic examples, but for a specific game that I had in mind.
I propose a new arrangement of the "mode" buttons here, and
a workflow to create a new tree from scratch.
The ideas are best seen in the pictures that I drew and
that I include here as single-page PDF files (perhaps in a
later "user guide" to be replaced by pictures directly in
this text).
A single file
(onefile.pdf)
contains all these PDFs and can be used for clicking
through, which is useful for the later "workflow" example
and maybe to avoid having all those PDFs around.
Identifying terms (terms.pdf) for the toolbar buttons and the game window of the browser.
The current toolbar has two rows, with the
-
top row having "file" buttons (new, load, save, png export, fig export), running and choosing the algorithm, undo/redo, and zoom buttons.
-
a second row of "mode" buttons choosing what kind of actions takes place on the canvas.
-
"file" buttons (new, load, save, png export, fig export): excellent, in particular the use of the current name and easy replacement (this might also be the naturally good behaviour of firefox)
-
running and choosing the algorithm: works well, suggest other location on toolbar with re-design (at "equilibrium" stage)
-
undo/redo: seems to work, not fully tested
-
zoom buttons: used rarely, only as a backup to
CTRL-Lwhich does not seem to work everywhere. Thepanelbutton I do not understand.
Second row:
-
EF/SF buttons: fine so far
-
tree-directions: almost never used, should be part of settings. Some drawing functionality needs improvement, namely: Black-comma-separated payoffs in horizontal mode. In nonstandard direction (growing from bottom or from right): player 1's (and not player 2's) payoff at top / left.
-
"mode" buttons: re-group them as below; discard
addinfobutton - generating large game trees quickly via large information sets is too unintuitive.
There should be more guidance how to generate a game tree from scratch: The top row should indicate a workflow like when booking an airline ticket (workflow.pdf)
as in the stages tree > players > infosets > moves > payoffs > equilibria
The following .pdf files show how these stages should look like. To get a first idea, click through the last 9 pages of the above single file (onefile.pdf).
In terms of programming, most of the functionality for the canvas operations is already there, so it is mostly about the arrangement of the "mode" buttons. However, some things change, for example how to set players.
The toolbar has two rows, with the top having the list
tree > players > infosets > moves > payoffs > equilibria
where each of these 5 stages can be clicked on to highlight the current stage of creating a tree.
When starting with a new game (as with the "new" file button, or when starting the program), the first stage "tree" is highlighted, and underneath it two mode buttons "add" and "delete" appear - below each other, with an explanation on the right, as in this example: how the tree looks when constructing a new game (tree.pdf).
That is, we start by constructing only a tree, with unassigned players, moves, or information sets for each node. Hence, we need a new status for such a node, which before was only nonterminal or terminal; or we keep this distinction but have an undefined player instead. I think undefined status is preferable because a game tree that has such nodes cannot yet be solved. When using the "add" functionality ("addnode" before), the newly created child nodes should have this undefined status, and may either become nodes that have players or payoffs. All these nodes are black and round.
The "add" mode is default in the tree stage, which is a radio button. In the picture, I have shown this with a black border rectangle surrounding it, which is only for demonstration. The current mode should just be sufficiently clear visually.
On the canvas in "add" mode, clicking on a single node creates two children if there were none before, or an extra child if the node has already children: click on single node (tree-single.pdf).
Before, with the "addinfo" mode, we could create all children to belong to a new information set, which allowed to grow trees rapidly. However, I came to the conclusion that this is confusing - growing a tree rapidly and information sets are not the same thing. I think there should be a separate way of growing a tree rapidly at this stage, as in the next picture: adding children to all nodes on one level (tree-level.pdf).
I imagine that behaviour to be as follows:
When the mouse pointer hovers roughly at the vertical height
(when drawing the tree top-down) of a node but not directly
on a node, a dashed horizontal line appears (which may also
extend to the left of the leftmost node); if this "hovering"
is too complicated, maybe the line itself is discreetly
displayed (in grey perhaps) all the time.
Then clicking on that line applies the "add" (or in fact
"delete", depending on the mode) operation to all nodes on
that level.
In principle, clicking on that line for "apply to all nodes
on that level" just means performing the "add" operation to
each single node.
However, I think this would be confusing in the following
scenario:
Suppose the user has first generated children by clicking on
individual nodes, and is now on the fourth level with 8
nodes and is getting bored.
After giving individual children to the first two of those 8
nodes, he discovers the "level" functionality and clicks on
the line.
Now, simply applying "add" to all children would result in
the first two getting an extra child (now having 3 nodes),
with the remaining 6 getting 2 children, which is most
certainly not the intention.
I think the effect (number of children) should be
uniform for all nodes on that level.
This would be implemented as follows:
- find the node with the fewest number of children on that level
- for all nodes that have that same (lowest) number of children, apply the "add" operation. In particular, nodes that have already several children (e.g., three), are untouched.
- the effect is that if all nodes have the same number of children, they are all treated the same way.
- if the result is not as desired, the user can simply
use the
undobutton.
=> Where should we place the undo button?
This stage replaces the old "change player" and "chance" mode buttons.
When the raw tree is constructed, the "players" stage is
clicked on next, which just offers a radio button for each
player, default player 1, chance shown last.
With that radio button on, clicking on a node assigns that
player to the nodes that is clicked on.
Example:
setting a chance move
(players.pdf).
A chance node is indicated by a black square.
When a chance node is created, its children are assigned
equal probabilities.
It is already possible to change those probabilities by
clicking on them, by using the general edit mode for all
clicks on canvas items where the current mode does not apply
(see below).
=> Please use Times-Roman as standard font for chance probabilities. Numbers should not be in italics.
It would be good to have the same functionality "apply to
all nodes on one level" as in the "tree" stage here:
setting all nodes on one level to player 1
(players-1.pdf).
This would apply to all non-terminal nodes on that
level.
Note that at the "players" stage, terminal nodes are no longer shown with dots - they cannot be clicked on to define a player. A player can only be assigned to a non-terminal node.
Besides the "mode" buttons - one for each player - it may also be useful to offer settings buttons here:
- player names (so far hard-wired as "1" and "2")
- player colours (black forbidden, small choice please)
- adding a player ("drawing only, no equilibria")
The game tree as created so far has perfect information. If that is intended, this stage can be skipped immediately.
Information sets can be created by joining nodes.
The offered mode buttons are join, cut, dissolve, in their
existing functionality.
Default is "join":
creating info sets (infosets.pdf)
If an "apply to all nodes at this level" functionality is to be offered, it would join all nodes on that level (separately for each non-chance player) into a single information set. Not clear we want this; it should imply perfect recall, see next.
The "perfect recall" button makes sense here, which was the lightbulb icon before (which I don't like, but I am not sure what alternative there is). This could be a tick-button for "assert perfect recall" which implies that any information set, even after it is created, is automatically partitioned further according to the perfect recall property (which is not hard to implement).
As settings buttons for this stage could be offered:
- tickbox for "ovals for singleton information sets" (default off), we might not have that option yet
- ovals or dashed lines to indicate information sets.
=> If information sets necessarily use different levels, the current dashed-line display sometimes coincides with game tree lines and is not visible. Use a thicker, curved dashed line instead.
When this stage is reached, the game tree is complete with the exeption of the payoffs.
The player's moves of the game tree do not have names, and they should be named only now because otherwise there is a lot of messy re-naming at the infosets stage.
Moves are now, breadth-first, automatically named from the standard list
-
A B C D E F ... for player 1
-
a b c d e f ... for player 2
=> a possible but not very important possible "settings" feature could be editing that standard list, e.g. to
- L R S T A B C D E F ... for player 1
The important thing is not to prescribe standard names, but to allow editing them easily.
For each non-chance player, a click-on button (so this is
not a "mode" radio button) is offered, which creates a
pop-up window, as in
pop-up with list of all moves of player 1
(moves.pdf).
The pop-up window is pre-populated with the move
names, separated by single blanks, and can be easily
edited for the entire game.
In particular, existing move names can be copied over
from another game with copy and paste.
=> the pop-up window is closed with the return key or with
the OK button in that window.
"Undo" applies to the entire popup operation.
=> desired feature: background colour of that pop-window in the player colour.
=> standard font for move names on canvas: Times-Bold-Italic
(as it is now).
I think the font for the pre-populated window could be
either that font, or a standard font we use for filling in
data.
=> the window should allow to scroll when move names become longer (or the entire list is too long), with some extra blank space given initially to insert longer names without scrolling.
This pop-up window replaces the entire "sequence column" on the right of the canvas, which is never used for re-naming moves anyhow.
Clicking on an individual move name still allows to change
that name with the general edit button.
At this stage, two columns of buttons are offered:
-
click-on for each player with a pop-up window to change all payoffs at leaves for the game in one go, as for the "moves" stage.
Example: popup with list of all payoffs of player 2 (payoffs.pdf) -
mode button (formerly "pay-type") that toggles between "nonzerosum" (default) and "zerosum".
=> If more than 2 players are ever allowed, that mode button disappears, and only "general" payoffs are considered.
-
button "random pay"
-
button "reset" (this is started when payoffs are undefined) which numbers all payoffs of player 1 from left to right with 0 1 2 3 ... which has the purpose of identifying the terminal node for easy editing.
The last two buttons have major changes and should allow
undo in one go.
Behaviour when the zero-sum option is set:
-
if this was not a zero-sum game before, all payoffs of player 2 are set to be the negative of player 1's payoff
-
when changing a player's (either player 1 or player 2) entire set of payoffs with the pop-up window, the other player's payoffs become the negative of those. So it is good that only one player's payoff can be changed at a time.
-
When using single-edit on a terminal node, all payoffs (2 for 2 players, separated by blanks, comma input allowed) pop up in "non-zero-sum payoff" mode, but only the payoff for player 1 in "zero-sum" mode.
The replaces the payoff columns so we ditch that entire feature of the current GUI. That is, only the canvas is shown now, no separate table on the right.
Copying/entering a single line of text for the payoffs or move names for each player seems much more straightforward to me. Letting consecutive numbers represent payoffs also seems much easier to identify them. The yellow path to identify a leaf of the game tree is nice but too indirect.
Except for the first two "tree" and "players" stages, each stage has a default behaviour that allows to skip that stage, to repeat:
- perfect information (all information sets singletons)
- autoname moves
- 0 1 2 3 ... for payoffs, both players; not an interesting game.
For the stage that is not currently highlighted, the possible mode or click-on-popup (for the players in the "moves" and "payoffs" stage) should be displayed in a single row below the respective stage name: all buttons (allbuttons.pdf).
In particular, if none of the stages is highlighted, the corresponding mode buttons just appear in the row below, rather than in a longer display (which may extend like a pull-down menu down into the canvas) with explanations and further "settings" buttons.
When the game tree is incomplete (up to the beginning of the "infosets" stage), the buttons for the later stages should not yet be shown (or be "greyed" or "fuzzed" out).
If none of the mode buttons is chosen, the default edit
icon applies, which is also the default behaviour.
=> The standard behaviour should be that a window pops up
which is pre-populated with the existing value which can
then be edited.
Edit terminates with return or the OK button.
After return, it should be checked if anything changed,
because if not, this action need not be put on the undo
stack (dangerous if "nothing changed" is mistakenly
recorded).
Here is a possible edit icon from the "silk" icon set:
I am not sure how this should be part of the workflow, and have not worked on this.
Once the game has been created, it should first be saved which should be a default action before starting solvers.
=> We should also find out how much space the new toolbars take, and where to put the following buttons:
- undo/redo (important)
- tree-directions (to settings)
- zoom buttons; these typically belong to a "view" pulldown menu
- if we are short of space, the current "file" buttons (new, save, etc.) typically belong to a "file" pulldown menu.