A1-DavidPoll
From CS294-10 Visualization Fa08
Contents |
Good Visualization
Source: San Francisco Chronicle, 9/2/2008, E8
Why it's good: Chess visualizations have been around for a long time, and they exist today on computers as well as in print media. This chess puzzle uses a 2-d analog for a chess board that clearly displays where the pieces are relative to each other on the board, whose turn it is, and so on. My primary criticisms might be that the pieces are somewhat difficult to distinguish, but a very good job was done distinguishing black and white squares from each other (even though the visualization doesn't actually use black and white), as well as black and white pieces from each other. Furthermore, the shape of the pieces gives a fairly clear indication of which piece is intended to be represented.
An equivalent, but far less useful visualization would be a textual table of moves (or for that matter, a textual table of piece positions). While this would equally describe the board, it does not put the pieces and their relationships to each other in context.
Digital and interactive media one-ups this visualization with all sorts of tricks ranging from 3-d renderings to highlighting of threatened pieces and squares with potential moves. Each of these help the reader/user understand what's happening on the chess board and identify possible conclusions that they might draw for their next move.
Deconstruction
This visualization encodes data about a chess game. In this case, the x/y coordinates (ordinal) of each piece are encoded by position, the color of each piece (nominal) is encoded using value, as is the color of each square (nominal). Furthermore, each piece (nominal) is represented by a different symbol (shape). The primary thing left unencoded in the state of the game is which player is next to move (a nominal value). In this visualization, that information is left as plain text.
Bad Visualization
Terrible:
Better, but still not wonderful:
Source: San Francisco Chronicle, 9/2/2008, B6
Why it's bad: I apologize for the poor quality of the photos... I didn't have a scanner on hand. The issue with the first photo, which shows a table of weather conditions for various cities in the US, is that the cities are sorted lexicographically. This wouldn't be much of a problem if every city were listed, but because it uses a very limited selection of cities, finding the city nearest to the location you're looking for is hit-and-miss. The problem is that they sorted by name on Nominal values without promoting them to Ordinal ones appropriately. Rather, it would have been nice if these values were plotted on a map so that a reader could easily locate the data point nearest to them. Alternatively, the table might have been organized differently -- grouping data points by state, for example. The second photo, showing international weather, does this, sorting cities into countries and regions (ordinal values: Canada, Mexico, Caribbean, Europe, Latin America, Africa/Mideast, and Pacific), and then by name. This makes locating a city near your target much simpler, and vastly improves the visualization.
Deconstruction/Revision
Due to the poor quality of my original photo and my disposal of the original paper, I resorted to a second paper with a similarly poor visualization in the same vein. Please excuse the slight variation in the data presented.
Source: Oakland Tribune, 9/14/2008, B14
Deconstruction: The data set for the visualization includes the high and low temperatures for "today", "tomorrow", and "yesterday", as well as yesterday's precipitation measurement and the sky conditions for today and tomorrow. This data is provided on a per-city basis for a sampling of cities across the US. The data set thus implicitly includes a latitude/longitude for each city, as well as a State for each city. Unfortunately, this data is highly raw, and thus uses symbols to represent virtually all of the data. Even the cities are listed alphabetically, as though there were no relevant latitude/longitude associated with them. Part of the issue is that most of the data here is treated as nominal, even though most of it is quantitative. The one glaring exception is the choice of treating the city names as Ordinal (by lexicographic ordering of the city names). Position encodes this ordering, but virtually nothing else is encoded, leading to large amounts of text use.
The goal of this table is to provide lookup of this data, rather than to allow analysis. As such, the largest issue at hand is the encoding/ordering of the cities to provide better lookup.
Alternative Visualization 1
This alternative visualization has the exact same data as the original table, but explicitly calls out the states for each of the rows. This introduces a new set of nominal values which can be used to group the rows into sets that enable better retrieval. In this case, a "user" (or reader, be it as it may), is most likely to know in which state he's looking for weather information, but far less likely to know which city in the massive list of cities is closest to the one he's looking for. In order to find the closest city, in the original table, the reader would have to scan the entire alphabetized list. In this visualization, he need only scan a few (at most) city names in the state he's looking for. As a result, the data lookup is much faster, and the reader can find the information most suitable for him more rapidly.
This alternative visualization converts the nominal "State" to an ordinal using lexicographic ordering (and encoded using a symbol/abbreviation and position in the table), and then sorts the cities lexicographically within the state ordering. The boundaries between state groupings are redundantly encoded as the change in symbol and a change in color, aiding in state lookup.
Alternative Visualization 2
Source: Weather.com, 9/15/2008, 2:35 AM
This second alternative visualization comes from Weather.com, which already has a great visualization for most of this data. In this case, some of the original data is excluded, and some additional data is shown, but it's not difficult to imagine how, using a multi-visualization, all of the data can be displayed and how extraneous data might be removed.
In this case, data lookup is aided by using position to encode the latitude/longitude of each of the cities and a combination of Color/Value and text labels to encode high temperature data. In addition, sky conditions are indicated using symbols that give a pictoral representation of the sky at each city. The main advantage of my previous visualization are that it doesn't require a full scan if one doesn't know US Geography, nor does it require as much space to be legible (it's a more compact visualization). That said, a geographical/positional lookup, for those who are familiar with the general geography of the US, can be a much more effective means of lookup. Furthermore, this visualization makes seeing the temperature differences between locations much clearer by encoding them with color/value across the entire map.
