A1-ScottMurray
From CS294-10 Visualization Fa08
Contents |
Great Visualization
Explanation
The iPhone's touch-based interface has inspired a number of innovative data visualizations and new user interface designs. iDrum, a live music performance application for iPhone, visualizes musical compositions in a new form that is appropriate and successful for the touch interface.
Watch a video of the user interface here.
The user first selects a pre-made composition. I've selected "Shuffle the Deck" here:
A 4-by-4 grid fills the display. Each square represents one measure of the composition. This particular composition is only 8 measures in length. The music begins playing immediately, and a green outline indicates the measure currently being heard. Tapping on a measure zooms in to reveal its composition details:
Now each square in the 4-by-4 grid represents a sound sample. Different colors represent different kinds of samples (e.g. electronic, bass, beat). Tapping on a sample zooms in further:
Each square in the grid now represents one-eighth of a beat, for a total of 16 eighths, or 4 beats total, per measure. (iDrum uses only 4/4 time.) So we can see (and hear) that the "Resonant Kick" sample is played on every beat in this measure—at 1, 2, 3, and 4.
Sliding a finger across the second row (second beat) activates the sample for additional eighths following the second beat:
Note that the volume level of each playback is reflected in the interface as well. Fewer bars equals quieter playback.
Zooming out, we see our changes reflected within the context of the whole measure. (Note the second square from left in the top row.)
Zooming out again, our changes are reflected within the context of the entire composition. (Note the blue squares in the top-left box.)
At this scale, we lose the ability to see volume, but the overall composition can be perceived clearly and individual measures can be differentiated visually.
iDrum provides not only a visualization that represents music (data), but the ability to modify the music (data) by directly manipulating the visualization. The score is not just a record of the piece, but the means by which the piece is adjusted and re-composed on the fly, even during a live performance. The UI emphasizes some elements (rhythm, structure) at the expense of others (key, metre), which are omitted completely.
Aside from a few limitations—primarily that no piece may extend beyond 16 measures or be set in any metre other than 4/4—this interface is an elegant way to visualize and manipulate music data on a small, touch-based device.
Deconstruction
The interface's conceptual model is highly structured. Nearly all data about the composition is organized within the 4-by-4 grid, which maintains consistency throughout the interface, even when zooming in and out changes the scale of the grid being shown. All data (except for tempo and stereo balance) can be placed within this hierarchy:
- Composition > Measure (Pattern) > Audio Sample > Beat & Volume
The structure of this conceptual model is reinforced by both the audio output—which reflects only what is being visualized on-screen—and the scaling of the grid, which, at the compositional level ("zoomed out"), represents all the data needed to play the piece, except volume. Aside from volume, though, all compositional data is encoded, meaning that a screen capture of the "zoomed out" view could be used as a score to decode the data and reproduce the piece with eighth-note accuracy.
Note that although the timing of the sounds could be decoded from the visual interface, the actual audio samples themselves could not be inferred. The audio waveforms are not visually encoded, so access to the application itself (or its audio sample data) would be needed in order to recreate a piece.
Poor Visualization
Source: Lysyanskaya, Anna. "How to Keep Secrets Safe." Scientific American, September 2008, p. 91. Illustration by Matt Collins.
Explanation
This illustration fails to clearly explain the differences between traditional ("secret-key") and public-key encryption.
The text begins to explain the the two methods, but the visuals offer no assistance. Note that the two illustrations (top and bottom) appear almost exactly the same. If you look closely, you may be able to find some minor differences: the keys and locks are green in the bottom illustration, and the user on the left has no physical key in hand. The differences are too subtle to be noticed easily, and in any case do not help explain the fundamentally different process behind public-key encryption, which is much more involved than simply using green-colored keys.
Deconstruction
The data represented here is all nominal, as it pertains to the explanation of a process. The elements appear to include:
- Two people
- Two points of encryption and decryption (the computers)
- Two keys (one secret, one private)
- One message sent from person A to person B
- The message's visibility, i.e. either encrypted or plaintext
- The network space between A and B
At least one piece of data is missing: The third key which should be present, B's public key.
Great amounts of superfluous "data" about the users is also represented in the visualization: their genders, skin tones, hairstyles, clothing selections, preferred computers, work surfaces, and even chairs, none of which bear any relevance to the encryption processes being illustrated, and all of which include colors and shapes that distract from the intended communication.
Instead of labeling visual elements constructively, the text, which accurately describes encryption processes, is dissociated from the image, requiring the viewer to move back and forth between image and text.
Redesign
High-res PDF available here: Image:Encryption Illustration.pdf
The redesigned illustration removes irrelevant visual elements and clearly represents all four stages of the process:
- Key exchange
- Encryption
- Transmission
- Decryption
Explanatory text labels each step of the process, and icons represent key data elements. Light shading associates related elements and indicates the direction of action. Prominent numbering of each of the four steps also guides the viewer in the right order, which reads naturally from top left to bottom right.
The repetition of some elements—such as steps 2 and 3—helps the viewer distinguish what differs between the two processes. Variations on line weights and key forms (1, 2, or 3 teeth) also help distinguish how the two processes use keys differently.
