Realizing the full potential of GUIs by coding data with position.
The action-packed sequel to Putting the G in GUI
It’s good to see that web apps have re-discovered the slider control. It represents an overdue move towards making our graphical user interfaces more graphical.
The slider control is one basic means of graphically coding data by position. You have a data attribute, in this case the ethical valence of magic, which has a value of -10 moral alignment units (mau). You also have a symbol on the display, in this case the graphic of a slider “handle,” where the position of the symbol, relative to some point or reference, indicates the value of the attribute. As is often the case, the reference for indicating the value is manifested to the user by additional graphics, such as slider gradations and a “track.” Text may also be provided to enhance understandability and redundancy, but by the position of a symbol indicating a value, you have position coding.
Overlord Graphic
The same attribute could also be represented by other graphic dimensions, either instead of position or in addition to position. Color from black through gray to white certainly would’ve been a good choice in this case. Other options include density, shape, size, and orientation. The previous post described when you should use each type of graphic code. However, position coding offers capabilities that other graphic codes lack, making it the overlord of graphic dimensions.
Ubiquitous
Firstly, position coding is implied by a couple other frequently used graphical dimensions. Size and orientation necessarily includes position coding since different sizes or orientations of the symbol requires that parts of the symbol occupy new positions. You can understate the implicit position coding if you want by omitting reference marks (and sometimes you may want to in order to minimize clutter), but you can’t completely escape position coding.
All Scales of Measurement
Secondly, position works well at all scales of measurement: numeric, ordinal, and categorical. The scale of measurement is typically implied by the symbol, reference marks, and text you provide and the attributes themselves. The slider above, for example, is at the numeric scale of measurement. However, we could “downgrade” it to an ordinal scale of measurement by relabeling and rescoring it to a scale of Angelic – Nice – Neutral – Nasty – Satanic.
Position can also indicate category membership, although for that you want to use option buttons rather than a slider, since the latter implies some kind of scale. When users spatially arrange their icons within a folder or on their desktop, they are often creating their own position coding on a categorical scale of measurement on some attribute (e.g., function, project), although they may also be using other scales of measurements (e.g., ordinal, if icons are ordered by frequency of use).
The only other graphic dimension that works well on all scales is size coding, which, as I mentioned, sneakily includes position coding.
Multi-Attribute
Thirdly, position coding is naturally multi-axis. You can represent one attribute on the X axis and another on the Y axis to show two attribute values by the position of the same symbol. This is great for not only showing the values of two attributes, but for showing the relation of two attributes to each other. A map is bi-axis position coding of geographic position in the real world with the virtual position on a computer screen. Typically, the east-west position (e.g., longitude) is coded by the X axis and north-south position (latitude) is coded on the Y. (Like the prequel, much of this post pulls from cartographic concepts). For example the map below represents the proximity of your user’s workstation at Tower Kraggor to supernatural sources of magic on two axes (which is important because, of course, east-west proximity to a source is better than north-south).
Maps generally encode geographic position on a numeric scale, operating through some kind of transformation function to project the curved planet surface onto two dimensions. However, a map may also use a ordinal scale, such as often seen in transit maps, where position on the screen represents only geographic order. Position coding can be used to produce “maps” that show any kind of relationship between objects, not just geographic relations. A graphic depiction of email can show the pattern of responses to a letter, for example.
Position coding can have as many as three axes, although this creates some user navigation and interpretation challenges related to depth cues, angle of view, and occlusion. If you need to show more than two attributes, you’re generally better off using a different graphic dimension such as brightness for the third attribute, rather than going from two to three axes. This is even the case for maps where you want to represent physical altitude. Certainly, it is poor usability to gratuitously have 3-D just because it looks cool, like those silly pie graphs shown at an oblique angle.
But in any case, position coding gives you at least two axes to work with, unlike other graphic dimensions. In a sense, color coding can be multi-axis, where separate attributes can be represented by the color components of hue, shade, and saturation. Pattern coding likewise, where separate attributes can be represented by the pattern components of shape, size, density, and crispness. However for both color and pattern, each component has its own strengths and weakness, and they’re better regarded as separate graphic dimensions rather than axes of the same dimension.
Multi-Value
Fourthly, position allows for the possibility of encoding multiple values for a single attribute. Rather than using a single point in space to represent a single value for each attribute, we can represent for a single attribute a set of values by using a symbol that occupies space on the available axes. A Gantt chart, for example, position codes duration along the X axis using a line. Here, for example, we see the impacts of the moon phase and various spells on transforming people into werewolves, as represented by thick lines of various positions.
Using a line’s position to code an attribute is different than size or shape coding, where only one value is represented. When using a position-coding line every point along the line symbol is a value of the attribute. In this example, the attribute is Being a Werewolf, and the values are all moments when that was the case. Of course in the database used to construct the lines, the data may be represented as separate fields or records (e.g., start and end timestamps). However, by presenting the user with the line symbol above you have created the experience of a single attribute with a set of values. The set of values may be discrete or continuous (infinite), depending on the attribute and how you choose to represent it.
A line is one kind of symbol to comprise multiple values for a single attribute. Contingent on the axes available, the set of values for an attribute may be graphically represented by an area symbol or a volume symbol, as well as a point symbol for a single value.
| Axes | 1 | 2 | 3 |
| Point |  |
 |
 |
| Line |  |
 |
 |
| Area | – |  |
 |
| Volume | – | – |  |
Of course, even a point symbol must visually span at least two dimensions on a display, having both a a width and height. Users wouldn’t be able to see the symbol otherwise, and besides even a single pixel has a physical width and height. What makes a symbol a point symbol for a given attribute is that only one point within it represents the attribute value irrespective of its height, width, size, or shape. Likewise, what makes a symbol a line symbol for a given attribute is that only the positions along its length represent the attribute values, irrespective of its thickness or other graphic appearances.
Emergent Features
Fifthly, multi-variate and multi-value position coding allow for the possibility of emergent visual features or patterns that can be meaningful to the user. In plotting a line graph for example, each point on the line is a particular value position coded on X and Y. From this plot emerges a slope that constitutes an orientation-coded representation of the rate of change of Y with respect to X. A scatterplot is composed of many individual position-coded point symbols from which a pattern emerges indicating the trends and cycles. Essentially, the trends and cycles are coded by orientation while the strength of relationship is coded by crispness (the degree the point symbols make a clear line). A topographic map uses line coding to represent each elevation value, but the emergent feature of line spacing yields density coding of physical slope. Position coding often means you get three or more attribute values for the price of two.
In addition to orientation, humans readily detect other visual features such as angles, intersections, symmetry (on various axes), and closure. In many cases, the appearance of such features is significant to the users’ tasks, either naturally or by design. Take for example a “stringline” display, where the X axis represents time and the Y axis represents geographic position along a single-dimension path. A line symbol represents an object’s position at every point in time. Here, for example is the projected and actual progress of several people (and one werewolf) along a road, with milepost on the Y axis and time of day on the X.
I think they call it a “stringline” because before users had computers, they used to construct these displays with physical strings and thumbtacks on a gridded bulletin board. I’ve also heard people call this kind of diagram “chicken scratches” and “waterfall displays.” Let’s standardize it and call it, “chickens on a string going over the waterfall.”
In any case, we once again have the emergent feature of line orientation which codes the speed of travel, with steeper slopes representing faster walking. We also have the intersections of lines in a stringline, an emergent feature easily spotted by the user. Such intersections represent significant events: they are points where two people are in the same place at the same time. It’s a “meet” in the context of railroads, or “snack time” in the context of werewolves.
Combinable
Sixthly, position coding is very well suited for being combined with other graphic dimensions to code other information. On the map above, for example, we used shape coding of the point symbols to categorically represent different kinds of geographic features (castles, palaces, villages, supernatural taps). In single line graph, the position of two line symbols may indicate the value of a couple different attributes, while the color or shape of the line symbol may distinguish the attributes (doing this usually means the two attributes use the same units). For example, here’s a line graph plotting time by population, showing the progress on three different attributes, where line color and point shape codes the attributes
Or instead of distinguishing attributes, the other graphic dimensions may be used to distinguish the class of the data object comprising the position-coded attributes. In the stringline display above, for example, shape (icons) is used to distinguish hapless peasants from hungry werewolves.
Position-coding as a Field Control
As with other graphic dimensions, position-coded attributes can be laid in the object image (the on-screen representation of a data object and its attributes) as a single field control, like a text box or dropdown list, where the graphic sits among other field controls in a page or table layout. A slider control, for example, often finds a home among text-displaying field controls. A multi-axis graphic for position-coded attributes can also be shown like it’s a single field control even though it represents multiple attributes and potentially multiple values. To fit in a table, a multi-axis graphic typically must be diminutive such as seen with Sparklines.
More often, a multi-axis graphic works best presented as a “heavy attribute,” one which takes up a substantial amount of space in two dimensions. Other heavy attributes include photographs, videos, and large “memo” text fields or certain blobs. Heavy attributes generally require page layouts. Sometimes a heavy attribute is best in a separate pane of its own, like shown in most of the examples above, ideally with resizing controls and scrollbars as needed. Often, the graphic should be a detail pane of a separate master pane, which shows one or more objects with various non-heavy attributes (perhaps in a table layout). Like any master-detail relation, the graphic shown in the detail pane depends on the current object in the master pane.
Displaying position-coded information as a single field control (heavy or not) is generally adequate when the graphic is just a picture, taking little interaction from the user, perhaps limited to changing one or two values. In the case of a heavy graphic attribute, there may also be some zooming and other adjustments to the presentation of the graphic. However, often you want to give the user the ability to extensively edit parts of the graphic, particularly when the graphic incorporates multiple records of a database. Often your users need to see some objects on a map or other graphic display, and manipulate those objects to perhaps change their relations to each other. The user will typically need to update multiple different fields of multiple data objects, and create, associate, copy, and remove entire objects, and “drill down” for more information. Furthermore, you want to provide such capabilities with an interface that is consistent with that used for text-based data, which will almost inevitably be included in your app.
Table Layout, Page Layout, …
The Third Type
In a pane with table or page layout, with or without graphic attributes, the position of each object image is determined by the sort order. For table layouts, objects are sorted along the Y axis on a default or user-selected attribute. For page layouts, objects are sorted along the Z axis (if you use a little imagination). Position coding, however, also offers the possibility of representing attribute values by the relative position of the object image within the entire pane. To do this, you include the appropriate symbols -point, line, area, or volume -in the object image and plot it relative to some reference in the pane. This represents a third kind of pane layout that is generally underused in database applications. I call it a graphic layout.
In a graphic layout, you map the points in a pane’s virtual space to the measurement units of one or more attributes. Generally, you’ll have two attributes represented since panes naturally have two axes. Each axis may (but doesn’t have to) use different units and different scales of measurement. Take, for example, an digital scheduling book displayed below, where the Y axis codes time on a numeric scale, the X axis codes the type of activity on a categorical scale.
A scheduling book could (an often do) code time in units of days on the X axis and in units of hours on the Y. Or it may be a calendar with days of the week on the X and weeks of the month on the Y. All are different ways of position-coding the times of an activities in a graphic layout pane.
A graphic layout pane by definition must have position coding. However, there will typically be other uses of graphic coding, so that is why I call it “graphic layout” rather than “position-coding layout.” Position coding is also closely tied to the concept of graphical user interfaces. Graphical user interfaces typically employ metaphors from the physical world where physical objects have a position and that position conveys information (think WYSIWYG document applications). Conveying information by position is what graphic layouts are all about. Also, position coding is necessary for drag and drop interactions, which are one of the central benefits of a graphical user interface. Thus, there is a connection between position coding and graphical user interfaces, so I call it a “graphic” layout.
To be consistent, all data objects of all classes that are represented in a graphic layout must have the appropriate attributes represented by the object image’s position. If the class lacks the appropriate attribute, display its objects outside the graphic layout pane.
Consistency with Other Layouts
You may recall that I made an impassioned effort to achieve consistency between table and page layouts, allowing the user to perform the same operations through the same user interface elements and idioms. Key to that consistency was use of “object controls” to serve as interactive handles for the object. In introducing a third layout type, I want to extend that consistency, and once again, the object control is key, providing the interactive commonality across all three layouts.
If you are using a point symbol to code one value per attribute in your graphic pane, then use the object control for the point symbol. If you are showing multi-value attributes, then you augment the object image with line, area, or volume symbols, but you still have an object image. You position the object control somewhere on the line or area symbol so it’s closely associated with the object image, but otherwise, its position in the object image is arbitrary. Just put it where the user can easily find it and where it won’t interfere with other graphics.
In any case, each object in a graphic-layout pane should have an object control just like each object in a table or page-layout pane. The object control provides the user the same services as it does in a page or table layout. For example, it announces the presence of a data object, identifying its class with its icon. As in table and page layouts, the user selects the object control to perform operations on the entire object (e.g., cutting, copying, deleting, and dragging and dropping the entire object, double-clicking or using the context menu for drill down and other actions). Like in table and page layout, the object control is a “handle” with which the user drags the object control to perform drag-and-drop operations with the object. Unlike in a table or page layout, when dragging and dropping an object within a graphic layout pane, the user changes the object’s value on the attributes represented by its position. (You can also have additional handles on the object image to change other attributes of the object, e.g., attributes coded by its size or orientation).
In the example below, both spells and individuals are represented with object controls position-coded on a tactical map. The user can cast spells to a specific physical location by dragging and dropping the spell from the library pane to a particular position on the map. Spells can be moved from place to place by additional dragging and dropping.
Object images in graphic layout are not limited to the object control and multi-value graphic symbols. The object image can include text or graphic field controls, each which may be either read-only or editable. At the very least, you probably want to provide the name of the object as text. Field controls should be placed to the right and below the object control in order to be consistent with page and table layouts and so the field controls appear visually subordinate to the object control. For graphic panes, compact presentation is necessary to minimize the degree the imagery of the field controls interferes with reference marks and multi-value symbols. For consistency, having a graphic pane implies you use compact presentation for all panes.
In this example, artifacts to cast a spell are position-coded on a categorical scale to indicate their feed into each other. Arrow-shaped reference marks clarify the feeds. Each object image includes key text fields, some which may be edited.
Thus, as in a table or page layout, the user of a graphic layout can select and edit text fields or select the object control for actions on the entire object. All this is done without requiring different modes or windows to differentiate actions on an attribute from actions on the whole object.
For clutter control, you may want to provide a means to hide and show the less important attributes, either selectively for each object or for all objects in the pane. In some cases, you may want to reduce clutter by putting text information about an object in a balloon or “infotip” that appears with mouse-over of the object control, but obviously such a technique precludes editing or even copying the attributes.
You can also reduce clutter in a graphic pane by moving secondary or heavy attributes out of the graphic pane and into a separate overflow pane. That is, like table and page layout panes, a pane with graphic layout can serve in master-detail relations. As on any master pane, the object control in a graphic pane is used to indicate the current object for the detail pane. Below is an example using a tree. A tree typically constitutes a graphic layout where the position on the X axis indicates an object’s ordinal depth in a hierarchy and the Y axis indicates the categorical relation of subordinate objects to their superordinate object. Expand/contract controls (+ and – buttons) provide clutter management. Typically, a detail pane shows the characteristics of the current object in the hierarchy.
Graphic panes may also be detail panes, often showing the relation among components of a current master object
Object controls and compact presentation provide a consistent grammar of interaction across the three pane types. In a sense, table and page layouts are special cases of graphic layout. Table layout is like a single-axis graphic layout with position representing ordinal-scale coding of each object on the attribute used for the sort order. Page layout may be thought of as graphic layout with object images as large as the pane, leaving a notional Z axis to code the object on sort order. Table and page layouts are not truly graphic layouts because moving an object in the pane does not change any attribute values, but they are similar enough that one can imagine graphic layout blending into either. For instance if you change the Spell Library pane in the above illustration to use an ordinal scale for mau, it becomes pretty close to an ordinary table. Or imagine a table of objects where moving an object does change an attribute value (e.g., priority for tasks, or order of steps of a process).
In any case, you now have three kinds of layouts in your design toolbox which may be used together in a single window. Each has it own usability advantages:
- Page Layout is best for providing interaction with a large number of attributes especially when the number of objects is few.
- Table Layout is best for scanning, surveying, or comparing objects on their attributes, or otherwise interacting with a large number of objects when relatively few attributes are relevant.
- Graphic Layout is best for assessing or interacting with the relations among objects or between objects and some attribute or reference.
Like graphic coding in general, graphic layouts are less common than table and page layouts, probably because of a lack of developer tools to make creating them economically feasible. To provide the greatest flexibility, developers need more than support for specific kinds of graphic panes like map APIs, tree and Gantt chart controls, calendars, and so forth. Developers also need general purpose graphic layout toolkits, where they can easily define the object images and associate the virtual space of a pane with any arbitrary attributes. We’ve always had page layout or at least single-page forms. Recently, decent grid controls have become available for web apps, allowing table layout and bringing web apps up to where database management systems were twenty years ago. Now it’s time we complete the triumvirate, and include graphic layout. So, go forth my code monkeys! Fly! Fly, and bring forth the graphics pane library!
Summary Checklist
Problem: Using position to code attribute values.
Potential Solution:
- Choose the number of axes: one, two, or maybe even three.
- Choose the attribute and scale of measurement for each axis.
- Choose the type of symbol for the values: point, line, area, or volume.
- Design such that emergent features, such as slopes, symmetry, and intersections, are meaningful to the user.
- Use reference marks to aid interpretation.
- Select graphic codes for other attributes.
- Display in a graphic-layout pane to provide a means to interact with the data.
- Use object controls to provide a handle for the data objects.
- Add text controls to the object image for redundancy or additional attributes.