This is not a detailed instruction manual on the operation of the program. Though it is intended primarily just to give an idea of what the program can do, all features are mentioned. However, there is no attempt to introduce all the terminology or specify detailed operation methods. For those, see the Concepts page and the Operations page. Nevertheless, for someone familiar with other simulations of Rubik's cube, there is probably enough here to enable that person to fully exploit the program. This description will make much more sense if you are checking things on a running copy of the program.
In the following, all the elements of the operator interface are discussed in the order they appear on the menus.
These are on a pulldown menu and can also be accessed using control keys from the keyboard. These all have accelerator keys that you can use to invoke the command by holding down the Control modifier key and typing the key. The accelerator keys are noted on the Menu. On this menu they frequently differ from the mnemonic keys you can use relative to the names on the Command Menu when it is open. The idea for the accelerator control-key combinations is for them to be easy to type with the left hand.
The Scramble command does 100 random twists without drawing. It does not reorient the puzzle in the MCS.
The Initialize command puts the puzzle back in initial state with all colors on a given face the same. After initialization the FCS and the MCS are equivalent. Initialization does not change the viewing transformation, so the point of view for the cube is not modified.
It is not just twists that are undoable. Undo also applies optionally to changes in the 3D viewing transformation and to changes of rover parameters. Also undoable are moving centers, scrambling, and initializing. The stacks for undoing holds 100 operations.
If you use the mouse-control-of-animation feature to produce a 180 degree twist, it will be treated as two 90 degree twists for the purpose of undoing.
When you undo an action, an action which will reverse the undo is pushed onto the redo stack, which behaves in a manner similar to the undo stack. You can bounce back and forth between doing something and undoing it by alternately hitting Control-Z and Control-A.
Undone operations remain on the redo stack even when new operations are performed. Thus if you forgot something 2 steps back, you can go undo, undo, what-you-missed, redo, redo. This does not apply exactly for anything but twists, as redoing a non-twist puts state back to the state that existed before the undo of a previous operation, as opposed to performing some operation relative to the current state.
The Cancel Undo command is a variation on the Redo command. The difference is that nothing is pushed onto the undo stack to undo whatever the redo does. This is useful if an undoing action for something you really don't want done is pushed onto the undo stack. Then, when you undo it, you can immediately reverse the effect of the undo in such a way that you will not see it again.
The current state of the program can be saved using the \"Save State\" command. A saved state includes the settings of all the parameters, the states of the checkboxes on the View and Toggles menus, the colors, the size of the frame, the positions of the centers, and the current permutation of the stickers.
Saved states are represented by disk files with extension .mc3. By default they are expected in and placed in the directory in which the executable for the program resides. Any such saved state can be recovered using the Recall State command. When specifying a file name, you do not need to specify the .mc3 extension. If your file name lacks such an extension, one will be appended.
If the directory from which the program executes contains a saved state file with name "default.mc3", then that state will be set when the program first starts. After you have found a configuration for the program which you like, you will probably want to save that as your default. For your default, you probably do not want to save state when the cube is in a scrambled state. You can also specify a file argument on the command line which will supercede "default.mc3" as the state-file for the initial settings. (".mc3" still optional on command line argument, but the filename itself must end in ".mc3".)
The program allows you to specify any sticker colors you like using the Adjust Color command. This is hardly worth the trouble with the Applet version of the program. However, the colors are saved with a saved state in the application version; so, if you are running the application, you can save your color modifying efforts.
If you change sticker colors, the defaults for face labels may become inappropriate, so you can also adjust the label colors. You may also change the background and foreground colors and the colors used for sticker edges in the 2D display and the sticker separators in the 1D projections.
The program extends the concept of a "twist" of a slice to include the possibility of performing a mirroring transformation. To achieve such a reflection, invoke the Mirror Prefix command (Control-Q), before commanding the twist by any of the available methods. If you command the twist by clicking on an sticker, then the orientation of the mirror will be chosen so that that sticker remains stationary.
If you precede a scrambling command with the Mirror Prefix, the scrambling will include mirroring twists.
(The obvious control key to have used for this would be Control-M; but that is awkward to type with one hand; so the not-so-mnemonic Control-Q has been substituted. "M" is still the mnemonic key when you have opened the Commands Menu.)
This command closes the main window and, if it exists, the Layered-View window.
The ConfigSelect Menu allows you to easily invoke the various configurations mentioned below. The program is highly configurable, and we will mention here the significance of a number of built-in configurations. Not all the built-in configurations are discussed here. For more detailed discussion of the configurations and their significance, see the commentary, which also includes images to illustrate the configurations.
The only thing that the program draws is representations of the stickers on the cube. I.e., there is no attempt to represent the cubies themselves. The stickers 'float' freely in space, but geometric relationships are still imposed as if they were stuck on cubies.
With Configuration #1, the eyepoint is on the z-axis. Face and sticker shrink allows some ability to see between faces and/or stickers. For a 3D observer viewing this 2D projection, the shrink does not really help and such an observer could just as well use something like Configuration #2, which may be described as a box with the lid set aside. The nice thing with this projection is that the images of no pair of stickers on the box overlap.
Note, in Configuration #1, that the program draws the out-facing stickers of the 'top' (the face nearest the eyepoint) relative to a cube center which is displaced away from the center used for all the other in-facing stickers. Thus the projection of the near face does not fall on top of and obscure the stickers of the other faces. A pleasant surprise with the program is Configuration #3, in which the 'top' is in place on top of the 'box'; but you can still see (almost) all the stickers through the spaces between the stickers of the 'top' (or up-face). The one sticker you cannot see is that opposite the up-facing face sticker. However, that can only be the one face sticker which is complementary to that on top, so there is no real loss of information due to the fact that the down-facing face sticker is occluded.
The program does not require that the eyepoint be on the any of the axes. The eye can be moved all around the cube. When the eyepoint is on an axis, there is only one face for which the visible sides of its stickers are out-facing. When the eyepoint is not on an axis, then there can be up to three faces the stickers of which we see from the outside. The program maintains two distinct centers relative to which it draws stickers depending on whether they are in- or out-facing. However, the two centers can be made to coincide, in which case the puzzle simlator can look fairly normal.
Abandoning the requirement of axis-alignment for the 3D to 2D projection, we get possibilities like Configuration #4 in which all stickers are drawn relative to same center and all are visible all the time. For me, this is the most appealing configuration for working with the cube, as it allows the cube to be manipulated easily without the necessity of ever reorienting it. Of all the attempts I have seen to make a cube display that shows the complete state without any reorienting, this one seems the simplest and most intuitive to me.
Configuration #5 is closest to a classic sort of Rubik's Cube simulation. Since reorienting the displayed cube is so easy, I find that I can work this configuration quite effectively in a manner very similar to the way I work a physical cube.
Configuration #6 is a demonstration of the transparency effect. Try a few scrambles. You can tumble the display slightly to get a better idea of what's going on. Turning on highlighting for stickers may give you a little more feel for what is going on here.
Configuration #7 harkens back to #3 in the sense that the centers coincide and all the stickers are visible. What is special about this one is that there is no face-shrink. There is no nice regularity to the orientation of this one. The stickers are rather small so that you can see everything looking between them; but all the stickers on a given cubie remained closely situated with respect to one another, unlike the situation when face size is substantially less than one.
There are some binary configuration parameters on the Toggles Menu. These enable or disable certain behaviours of the program.
This determines whether or not the program sets the Scale Limit (for image size) automatically. Such automatic scaling occurs when the window size changes, when you change a parameter which affects it (3D Viewing Distance, Face Size, or Sticker Size), and at the instant this option makes a transition to enabled. By default, it is enabled.
This determines whether or not the program chooses automatically where to place the in- and out-centers in the display, which decision (if made by the program) occurs any time the window size is changed and at the instant this option makes a transition to enabled. By default, automatic positioning is enabled.
By default, the direction of a twist is defined in terms of how it appears in the 2D projection. If this check box is selected, it causes twist direction to be defined in terms of how it would appear to a 3D observer looking from outside the cube. Its effect is to reverse the direction of twist for in-facing faces.
By default, changes to the 3D viewing transformation (by tumbling, rotating, or direct modification of the viewing parameters) are undoable. If you don't want this, you can disable the behaviour.
If you want to be able to undo changes to the rover, you can enable this behaviour.
You can disable the drive mode feature for the rover.
If you want to be able to move both centers together, you can select this option. If the centers are separated when you select it, they will be moved to coincide.
When you undo or redo a twist, the program animates the twists by default. You can make them occur instantaneously by unselecting this option.
By default, keyboard twist commands are specified in terms of the FCS. Selecting this check box causes them to be for the MCS.
By default, the labels that appear on face stickers in the 2D display are based on the FCS - i.e., they name the face (and the associated slice) on which they appear by specifying the name of the color of the face sticker on which they are plotted. This toggle will switch those labels to specifying the MCS direction in which the face currently faces. Such MCS directions, not being the names of anything, appear in lower case.
Direction Indicators appear under the sticker names on the cells of the Text Display on the Layered-View Window. By default these Direction Indicators use the Face Coordinate System. You can select MCS coordinates with this toggle.
Selecting this check box enables highlighting of stickers when you hover the mouse over one. Not only is the sticker over which the cursor sits highlighted, so are any other stickers which are attached to the same cubie. The highlighting is accomplished by drawing the borders of the stickers in white (instead of the usual black or nothing). Because this border is drawn on top of all stickers without regard to the actual visibility of the sticker it outlines, this gives sort of an X-ray wireframe view of where the stickers for the cubie are even when they are not all visible in the regular display. (Try it on Configuration #5.)
Highlighting also works with respect to the 1D projections, both in terms of being displayed and the effect of hovering. This is very useful when you are trying to learn what you are seeing in one of the 1D projections. The highlights indicate the extent of the highlighted sticker independent of whether you can actually see it or not.
Highlighting also works with respect to the Layered-View presentations, again both ways. For these, it suffices to highlight just the cell for the corresponding cubie rather the representations of its individual stickers. Again, it is handy for learning how things correspond in the various views.
Checkboxes on the View Menu control what elements appear in the display.
There are three primary displays the program can make in the main window: a relatively familiar 2D rendering of the 3D model of the puzzle, an orthographic 1D projection of the 2D image along the y-axis, and a perspective 1D projection from a roving eyepoint which can be placed anywhere within the 2D scene with adjustable pan and zoom. Each of these three displays may be enabled independently. (A serious attempt at Flatlander solving requires disabling the 2D display.) The appearance of the orientation tattles for the Model Coordinate System, or MCS, and the Face Coordinate System, or FCS, can also be enabled and disabled separately.
The program can draw a pair of lines in the 2D projection area to indicate the state of the roving eye projection. The lines are rays which emanate from the current roving eyepoint location. The angle between them is the View Angle (specifying zoom). The bisector of that angle points in the heading direction. The wedge thus defined is referred to as the "Rover View Field". You can control whether or not it is drawn in the 2D view. It can appear even when the 2D image is disabled.
When you use the tumble feature to reorient your view of the cube, a representation of the axis about which the cube has been turned can be drawn in the 2D area. It gets longer the farther you drag.
The program can write text labels at the locations of the face stickers. When labels are enabled, face labels also appear in the other displays.
The appearance of the MCS and FCS tattles in the lower corners of the 2D projection area (left and right, respectively) is optional.
There is a separate section on this, as it involves a whole other display window. Its existence can be manipulated by using the checkbox on the View Menu.
All the parameters presented below may be adjusted continuously using the slider. Furthermore, excepting the last three, the effects of such adjustments are applied immediately and continuously in the rendered image so that one can get a better feel for how these parameters affect the display. For such observation and direct interaction, each parameter has a radio button on a pulldown menu that allows you to select it. Then, for the selected parameter, there is a numeric field and a slider both of which reflect its value and allow it to be modified. You can type a new value in the numeric field or manipulate the slider using the mouse or the arrow keys.
This affects the extent of the perspective effect in the projection. Its units are those of the MCS. It specifies the distance, in MCS units, of the eyepoint from the origin (through which the projection plane passes).
These parameters determine the direction in which the eyepoint for the 3D to 2D projection is displaced from the origin in the MCS. The cube can be viewed from any direction. By controlling these parameters plus the rotation (below), it is possible to make the rendered cube appear to tumble or rotate on the screen. Normally, these parameters are adjusted using the mouse in the 2D display area in an intuitive and interactive manner; but the effects on these parameter values may be observed, and the parameters can also be altered directly in the GUI (but the effects are not intuitive without considerable experience). The units of both are degrees.
This moves the stickers by turning them in a circular path about their respective centers. Considering an image to consist of the set of stickers associated with a given center, dragging the slider 'feels' like you are dragging on the projection plane itself and it is turning about a pivot point at the relevant center. The sign of this rotation angle is chosen so that it 'feels' like you are grabbing below the center, as the slider itself is below the projection.
Cube faces always remain at distance 1.5 from the cube center in the MCS. However, the faces can be shrunk in the sense that the centers of the non-face stickers move closer to that of the face sticker and the stickers become correspondingly smaller. Though Face Size affects the size of stickers, stickers may be further shrunk to allow there to be space between them. These sizes are unitless, referring to a fraction of full size. Both factors apply to sticker size.
This parameter affects how big the image will be. By default, the program updates it whenever the window size changes or when you modify any parameter which can affect the required scale. However, there is a checkbox on the View Menu which allows automatic adjustment to be disabled so that the parameter can be set directly. Roughly speaking, the units of the Scale Limit parameter are pixels per unit of distance in the Model Coordinate System, but you may as well regard them as arbitrary.
Internally the program also determines a maximum scale which assures that no sticker will plot outside the window. If that is smaller than a Scale Limit set manually in the GUI, the maximum scale will override the Scale Limit. It produces an interesting effect as you drag a center close to the edge of the window. (If you mess up the configuration so badly that you lose it completely, invoke a new built-in configuration.)
For the 2D to 1D projection associated with the roving eye, the program allows the eyepoint to be placed arbitrarily. Unlike the 3D to 2D projection, the eyepoint can be inside the (projection of the) cube. The roving eye can effectively wander about between the images of the stickers in the 2D projection plane.
Rover Heading and View Angle correspond to pan and zoom functions. The units for position are fractional position with respect to the width and height of 2D rendering window and relative to its lower left hand corner. For Heading and View Angle, the units are degrees.
2D Sticker-Edge Line-Width controls how heavy a black line the program draws for the boundary of a sticker. These lines actually obscure the polygons for the stickers themselves somewhat. This effect is most obvious when a face of the puzzle is seen nearly edge-on. Drawing the edges is not particularly important when sticker size is any significant amount less than 1. Some may consider it to matter when the drawing of an out-facing sticker overlaps that of an in-facing one, as it displays the edge explicitly. However, lack of the edge is really only a problem if the stickers are the same color, and, even then, a fairly minor one. A setting of this parameter which is less than .4 turns the edge lines off completely. (They look ugly if the program permits any smaller value.) Configuration #5 shows an example of using a very heavy line for sticker edges.
1D Sticker Separator Width controls how heavy a black line the program draws at the visible left and right extremes of a sticker in either 1D projection. It is similar to Sticker-Edge Line Width except that an 'edge' of a sticker projected to 1D is just a point. The threshold for turning this one off is .1. Aesthetically speaking, the 1D projections look better without the separator lines. However, the picture can be more difficult to interpret without them. The default is about as narrow an apparent line as the Java graphics system can produce.
Brightness of In-Faces can be used to reduce the apparent brightness of faces which are seen from the inside. An example of a situation in which this is useful occurs when sticker edges are not being drawn at all, as it will still provide some contrast for an out-facing sticker which overlaps an in-facing one of the same color. Configuration #7 is an example in which the edges are not being drawn and the in-facing stickers are dimmed somewhat.
Out-Face Alpha controls transparency of outward facing stickers. This is illustrated in Configuration #6. It is possible to make the stickers, for which the outside is what is 'seen' in the rendering, be semitransparent so that you can see what is happening on hidden in-facing faces even in the absence of face or sticker shrink. (This turns out to be not very useful, but it does create some cool looking pictures.) The unitless "alpha" number varies from 0. to 1. with the extremes corresponding to completely transparent and opaque respectively.
These two parameters affect twist animation - both for speed and granularity. The units for both are seconds. If the specified step size is so small that the program cannot keep up, it will automatically start taking larger steps in order to honor the duration for the complete twist. Specifying step size is a compromise between the smoothness of the animation and the load you are putting on your computer. Setting the duration to a value less than the step size (e.g., 0.) effectively turns off animation.
This is similar to the Twist-Animation Step Size. It appears that somewhat coarser granularity is sufficient for animating the appearance of the rover's view field.
Orientation of the displayed cube is managed by dragging with the mouse. By default, such drags must be performed with two mouse buttons depressed. It is also possible to do the drag with one button (any). However, if one is a bit sloppy with his clicking, an attempt at a mouse click may occasionally be seen as a drag, with undesirable consequences. (The program actually encourages sloppy clicking for manipulating the cube quickly because there is such a large area in which you can click to command the twist of any particular face.) Whether or not mouse movement with one button down is regarded as a drag is determined by this parameter. The units are pixels. The mouse cursor must move at least this far from its initial down place before the movement is regarded as a drag.
The default for this is a large number, which effectively disables one-button drags. There are reasons why someone might still wish to be able to do the drags with a single button. (E.g., she has only a one-button mouse.) In such case, it is necessary to set this number to something reasonable - like 4.0.
Two button drags are recognized as drags immediately. (So are the center-moving drags which are done with the Control and Alt modifier keys depressed.) With a one button drag, there will be a delay in the start of the adjustment corresponding to how long it takes you to move the cursor far enough to cross the drag threshold. Specifying the threshold is a compromise between the magnitude of this delay and the likelihood of accidental drags.
The displayed image of the cube can be rotated about its center or tumbled - turning it about an arbitrary axis in the projection plane. This is done by dragging with the mouse, having initiated the drag with two mouse buttons depressed. The effect is as if you are grabbing onto a gimballed cube and turning it with mouse movement. Drags from the center tumble it, while drags starting from the outside rotate it.
(Note that, with these orientation drags, you are not altering the orientation of the cube (as determined by the colors of its face stickers) within the MCS. You are altering the way the MCS is being projected to 2D by moving the eyepoint for the projection (and appropriately adjusting rotation). In contrast, when you twist a center slice (either by itself or by twisting the entire cube) you are altering the orientation of the cube within the MCS (but not with respect to the FCS).)
Since the Model Coordinate System can be projected to 2D in an arbitrary manner, it is possible to lose one's feel for how it is currently being projected. The program draws a little figure, called a "tattle", showing how vectors on the three MCS axes would map onto the display. A similar tattle is also drawn with the naming of the axes based on the Face Coordinate System. Display of the tattles and their associated "BFUDLR" strings (See below.) can be enabled individually.
The "BFUDLR" string corresponds to the words for the directions Back, Front, Up, Down, Left, and Right. BFUDLR notation is commonly used in discussions of theory for Rubik's Cube. Under each of the orientation tattles is printed the string "bfudlr" or "BFUDLR". The lower case ones presented under the MCS tattle are direction indicators. The upper case ones under the FCS tattle are face names. The characters are color coded. For those associated with the MCS, the color of a character is that of the face sticker which is currently facing in the MCS direction specified by the character. For those associated with the FCS, the character is the name of the color in which it is displayed and that color is the color on the face sticker on the named face.
The program allows the cube to be reoriented in the MCS, so the MCS colors change when you do center slice or whole cube twists. The colors of the BFUDLR characters under the FCS tattle never change, as the directions in which the R, B, and U face stickers are displaced from the origin determine the orientation of the FCS.
Twists can be initiated by a variety of means. Most popular will probably be mouse clicks. Virtually any click in the 2D projection area will be associated with some face, and that face is turned counterclockwise or clockwise depending on whether you use button 1 or some other button. The BFUDLR alphabetic keys on the keyboard can be used to command twists of the corresponding faces. (By default, this is relative to the FCS; but there is a checkbox on the Toggles menu which will make it work relative to the MCS.) The shift key reverses the direction of a commanded twist (most relevant for keyboard- commanded twists, but applicable to all). Very similarly, you can click on the characters of the "bfudlr" string associated with the MCS tattle - with direction determined by which button. You can also command twists relative to the FCS, by clicking on characters of the "BFUDLR" string associated with the FCS tattle. With the FCS BFUDLR characters, this is virtually the same as typing the characters except that you no longer need the Shift modifier for counterclockwise twists.
Center slice twists are permitted and are obtained by holding down the Control key when commanding the twist (by whatever means). Similarly, all slices are turned together when you hold down the Alt key. In either case, you are changing the orientation of the cube within the MCS. (E.g., the face sticker displaced from the center in the positive x direction does not have to remain one of color R.) The existence of the FCS tattle helps for thinking in FCS terms.
There is one more combination of slices that can be selected through the modifier keys. If you hold down both Control and Alt while commanding a twist, both of the external slices will turn. This is a feature of marginal value and it does not work with the mouse if you click on a sticker, as that initiates a drag of the corresponding center. For clicking, you must indicate the correct face without clicking on one of its stickers. (Not difficult.)
To facilitate turning a hidden face in a configuration like Configuration #5, clicks well away from the center (e.g., outside the cube) are only associated with an in-facing face (the one whose center is nearest the click). You can always turn an out-facing face by clicking on any sticker on it (all of which are necessarily visible). It is only when the click is not directly on any sticker and outside the periphery that it is restricted to apply to an in-facing face.
If you just command a twist, the animation of that twist will proceed at a (parameterized) fixed rate. However, if, once a twist begins, you depress a mouse button before the animation ends, you can take over the animation and control the angle of twist continuously by dragging the mouse. When you release the mouse, the turned slice(s) will settle in to the nearest multiple of 90 degree twists.
By default, the program places the virtual cube centers (out-center and in-center) relative to which the stickers are drawn (depending on whether they are out-facing or in-facing relative to the eyepoint). It does so whenever the window size changes. If the window for the 2D display is near square, the two centers will coincide. If it is oblong, they are separated so that out-facing stickers will not occlude in-facing ones. The separation can be vertical or horizontal depending on the aspect ratio of the window. Thus altering window shape is a way to affect the behaviour of the program.
At any time, the user can move either center by dragging (any sticker associated with the center) with the mouse. For some purposes, it is desirable to suppress the automatic placement of centers when the window size changes. There is a checkbox on the Toggles Menu which you can uncheck to do this. Since it is objectionable to accidentally drag a center when the centers are supposed to coincide, this operation has been made somewhat difficult to do. You must hold down both the Control and the Alt keys while initiating this drag.
There is a feature, which can be enabled via the Toggles Menu, which will cause to be highlighted all the stickers stuck on the cubie to which is stuck the sticker over which the mouse is currently hovering.
The position of the roving eyepoint for the perspective 2D to 1D projection can be adjusted using the arrow keys with the Control modifier. Heading and view angle are adjusted similarly, but using the Alt modifier. Because of the visual feedback, adjustment of roving eye position, heading, and view angle with the arrow keys is more intuitive than using the Rover parameters, but you can see the effect on any of those by selecting them and you can also modify them directly.
There also exist drag-based methods for modifying the rover parameters and a rather different method called "Drive Mode" which is analogous to driving a vehicle.
If you select the Layered-View Window checkbox on the View Menu, the program will produce a different kind of representation of the state of the cube. It may be thought of as layered or flat. The presentation in the main window is focussed on stickers. That in the layered presentation is focussed on cubies. There are two different presentations. The one on the left is referred to as the Colored Tiles presentation, while that on the right is referred to as the Text Display. They both present the same information. Each little square corresponds to a cubie. Each 3x3 'board' corresponds to the cubies in one of the 3 slices perpendicular to the z-axis. The U-slice is at the top.
You can do twists by clicking in the layered view window. Clicks are resolved to the nearest face cubie. The turning in the layered window is always in terms of the 3D turning direction. I.e., defined as if you were looking face-on at the turned face from the outside of the cube. This is most surprising for the D face.
All keyboard commands (pure ones, as opposed to those that work via the menus) are valid in the Layered-View Window. So, BFUDLR characters command twists, and the control keys work for the commands on the Commands Menu.
In the Colored Tiles presentation, the colored areas of each square are arranged to indicate in which directions the corresponding cubie's stickers are facing. The color for an up or down facing sticker which lies on a corner cubie is shown in the quarter-size square next the tile for the face cubie in the slice. For up or down facing stickers on edge cubies in the U or D slice, the color is shown on the inside half of the tile. For all other stickers, the corresponding color will extend to the edge of the tile which faces in the corresponding direction. No 3D interpretation is intended for the face of the tile.
Compare to Configuration #2. The three rings of laterally facing (not up or down) stickers surrounding the D face match up with the outsides of the 3 3x3 arrays of cubie squares. Try clicking on the U and D faces, with and without the Control modifier.
In the Text Display, each cubie has a name in upper case, corresponding to the names of the colors of its stickers. The relative position in which the sticker color name is displayed corresponds to the axis (xyz) which is perpendicular to the sticker. Blank columns correspond to axes for which the coordinate value of the cubie's location is zero - i.e., no sticker for that axis.
Under each sticker name is a lower case letter which indicates in which direction the corresponding sticker currently faces. These lower case characters are called Direction Indicators. By default they use the Face Coordinate System; so reorienting the whole cube does not change them. However, if you do reorient the cube, you have to interpret them relative to the current orientation of the faces. There is a toggle which will switch the Direction Indicators to use the MCS. As long as you leave the cube in its default orientation, there is no difference.
In the text display, all the information is in the text. The color coding of the character backgrounds is just a bonus. However, what is relevant, color-wise, is the color of the background, not the color of the label which appears there. Think of the background for the character as the sticker. (With the default color scheme, the color of a label for a sticker is the color of the opposite face. This is just to achieve good contrast. Beware of attaching any directional significance to the color of the label itself.)
Different cube programs seem to use different color schemes. This one uses all bright colors. Red, Green, and Blue correspond to the positive facing x, y, and z axes; while Cyan, Magenta, and Yellow correspond to the negative directions. The RGB and CMY triples are familiar to most computer-literate folks and matching them up with xyz in this way seems like the most obvious possible arrangement and one which is very easy to remember. There is some naturalness in having colors on opposite faces be complementary relative the Color Wheel. For graphics purposes, it is also desirable to have all the colors be bright. (On a physical Rubik's cube, the use of some dark colors for contrast is viable; but that is not such a great thing with a computer display.)
If the default color scheme is not to your liking, you can set up different color schemes with the Adjust Colors command; and, if you are running the application version of the program, you can save those colors as your personal default using the Save State command.