Information Design & Data Visualization
No more LittleDataGraphics
Small data sets should be shown directly...LittleDataGraphics (pie charts, bar charts) translate and encode data into areas and colors. Viewers must then mentally translate codes back into numbers. These codes are unique to the local sets of data graphics, and do not repay learning. Instead, just directly show numbers as numbers. No more LittleDataGraphics. Data visualizations are at their best when there is so much data that the only way to see it...is to see it.
The Visual Information Seeking Mantra
There are many visual design guidelines but the basic principle might be summarized as the Visual Information Seeking Mantra:
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demand
Overview first, zoom and filter, then details-on-demandEach line represents one project in which I found myself rediscovering this principle and therefore wrote it down it as a reminder. It proved to be only a starting point in trying to characterize the multiple information visualization innovations occurring at university, government, and industry research labs.
Envisioning Information
A Book by Edward TufteBeautiful Evidence
A Book by Edward TufteThe Visual Display of Quantitative Information
A Book by Edward TufteThe Elements of Graphing Data
A Book by William S. ClevelandVision Science
A Book by Stephen E. PalmerVisual Explanations
A Book by Edward TufteVisualizing Algorithms
An Article by Mike BostockInformation Visualization: Perception for Design
A Book by Colin WareThe Eyes Have It
A Research Paper by Ben ShneidermanVisualizing Data
A Book by William S. ClevelandExploratory Data Analysis
A Book by John TukeyPlus Equals #4
An Article by Rob WeychertOne of the seeds for Plus Equals was planted a few years ago with Incomplete Open Cubes Revisited, my extension of a Sol LeWitt work. I learned a lot about isometric projection from that project, but my affection for the concept didn’t begin there. Whether I’m looking at a Chris Ware illustration or an exploded-view technical drawing of a complex machine, an isometric rendering always stirs something in me.
In search of visual texture
An Article by Rachel PruddenI’m now more inclined to attribute Looseleaf’s power to its visual texture than to some cognitive media-style abstraction. And the visual texture owes more to the beauty (yes, beauty!) of the original pdfs from the Vasulka Archive. Perhaps the demo is best understood not as a prototype generic tool, but as a specific curated experience in its own right, with form and content claiming equal importance in its overall success.
Even so, I think there are some general lessons that can be drawn from this demo:
- Content is not inert
- Visual texture lets content breathe
- Visual texture lets the eye wander without losing itself
Chartwell
A FontThis set of tools for easily creating graphs is conveniently disguised as a set of fonts. OpenType features are used to interpret and visualize the data. The data remains as editable text, allowing for painless updates.
Windy
A WebsiteBetter colormaps?
An Article by Mark LibermanA modest sample of alternative ways of coloring the same type of 2-D density plots of rates of F0 change and amplitude change.
ImageQuilts
A Tool by Edward Tuftepress.stripe.com
A WebsiteStripe partners with millions of the world’s most innovative businesses. These businesses are the result of many different inputs. Perhaps the most important ingredient is “ideas.”
Stripe Press highlights ideas that we think can be broadly useful. Some books contain entirely new material, some are collections of existing work reimagined, and others are republications of previous works that have remained relevant over time or have renewed relevance today.
Between the Words
An Artwork by Nicholas RougeuxMoby Dick.
Between the Words is an exploration of visual rhythm of punctuation in well-known literary works. All letters, numbers, spaces, and line breaks were removed from entire texts of classic stories...leaving only the punctuation in one continuous line of symbols in the order they appear in texts. The remaining punctuation was arranged in a spiral starting at the top center with markings for each chapter and classic illustrations at the center.
SeriesHeat
A Website by Jim VallandinghamSearch for a TV Series to see a heatmap of average IMDb ratings for each episode.
Time-based analytics
An Article by Ryan SingerAnalytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they using to-dos once a week? Every day? Only signing into the app once a month but happily paying for years?
Time matters. You can't understand usage without time.
Cameras and lenses
An Article by Bartosz CiechanowskiPictures have always been a meaningful part of the human experience. From the first cave drawings, to sketches and paintings, to modern photography, we’ve mastered the art of recording what we see.
Cameras and the lenses inside them may seem a little mystifying. In this blog post I’d like to explain not only how they work, but also how adjusting a few tunable parameters can produce fairly different results.
The Subtleties of Color
A Series by Robert SimmonThe use of color to display data is a solved problem, right? Just pick a palette from a drop-down menu (probably either a grayscale ramp or a rainbow), set start and end points, press “apply,” and you’re done. Although we all know it’s not that simple, that’s often how colors are chosen in the real world. As a result, many visualizations fail to represent the underlying data as well as they could.
tixy.land
A Websitesin(t * x) * cos(t * y)
Creative code golfing.
Zipdecode
A Website by Ben FryA Library Demand List
A Website by Robin SloanThis visualization takes the current New York Times Best Sellers list for combined print and e-book fiction and scales each title according to the demand for its e-book edition at a collection of U.S. public libraries, selected for their size and geographic diversity.
MIT Student Hub
An Article by Alex HogrefeThe project is located on the MIT Campus and will be a “Student Hub” containing restaurants, large event spaces, and smaller study spaces.
V-RESAS
An ApplicationAll in & with the flow
An Article by Buster BensonInfoCrystal
A Research PaperThis paper introduces a novel representation, called the InfoCrystal, that can be used as a visualization tool as well as a visual query language to help users search for information. The InfoCrystal visualizes all the possible relationships among N concepts.
Readings in Information Visualization: Using Vision to Think
A Book by Ben Shneiderman
The Design of Design
What's Wrong With This Model?
A ChapterDesign process models: A summary argument
- A formal design process model is needed, to help organize design work, to aid communication in and about projects, and for teaching.
- Having a visual, geometric representation of a design process model is crucial, for designers are spatial thinkers. They will most easily learn, think about, share, and talk in terms of a model with a clear geometric picture.
- The Rational Model of design occurs naturally to engineers.
- The linear, step-by-step Rational Model is highly misleading. It does not reflect what real designers do, or what the best design thinkers identify as the essence of the design process.
- The bad model matters. It has led to the too-early binding of requirements, leading in turn to bloated products and schedule/budget/performance disasters.
- The Rational Model has persisted in practice despite its inadequacies and plenty of cogent critiques. This is because of its seductive logical simplicity, and because builders and clients needs “contracts."
- Several alternative models have been proposed. I find Boehm’s Spiral Model the most promising. We need to keep developing it.
The spiral model
The spiral shape certainly suggests progress. It associates successive repetitions of the same activity. The geometric shape is easily understood and memorable. The model emphasizes prototyping, starting with user-interface prototypes and user testing long before an operational prototype is possible.
Since a development model is principally used by developers, I believe having it designer-centered is entirely appropriate. With Boehm and against Denning and Dragon, I advocate frequent but not continuous interaction with representative users, with successive prototypes as the vehicles.
I strongly believe that way forward is to embrace and develop the Spiral Model.
A grossly obese set of requirements
Who advocates in the requirements process for the product itself—its conceptual integrity, its efficiency, its economy, it’s robustness? Often, no one. As often, an architect or engineer who can offer only opinion based on taste and instinct, unbuttressed as yet by facts. For in a classical Waterfall Model product process, requirements are set before design is begun.
The result, of course, is a grossly obese set of requirements, the union of many wish lists, assembled without constraints. Usually, the list is neither prioritized nor weighted. The social forces in the committee forbid the painful conflicts occasioned by even weighting, much less prioritizing.
Requirements proliferation
Any attempt to formulate all possible requirements at the start of a project will fail and would cause considerable delays. — Pahl and Beitz, Engineering Design
As Project Manager, I had to reject the requirements document as totally impractical, and have a quite small team of architects, marketers, and implementers extract the essence.
Requirements proliferation must be fought, by both birth control and infanticide.
The architectural contracting model
It is the necessity for contracts, whether within an organization or between organizations, that forces the too-early binding of goals, requirements, constraints. The pressure for a complete and agreed-upon set of requirements run into the hard fact, that it is essentially impossible to specify any complete and accurate set of requirements for any complex system except in iterative interaction with the design process.
How have the centuries-old building design disciplines handled this perplexity? Fundamentally, by a quite different contracting model.
- The client develops a program, not a specification, for the building.
- He contracts with an architect, usually on an hourly or percentage basis, for services, not for a specified product.
- The architect elicits from the client, the users, and other stakeholders a more complete program, which does not pretend to be a rigid contractable product specification.
- The architect does a conceptual design that approximates the reconciliation of program and the constraints of budget, schedule, and code. This serves as a first prototype, to be conceptually tested by the stakeholders.
- After iteration, the architect performs design development, often producing more detailed drawings, a 3-D scale model, mockups, and so on. After stakeholder iteration, the architect produces construction drawings and specifications.
- The client uses these drawings and specifications to enter into a fixed-price contract for the product.
Notice how this long-evolved model separates the contract for design from the contract for construction. Even when both are performed by the same organization, this separation clarifies many things.
The rational model of design
Engineers seem to have a clear, if usually implicit, model of the process of design. It is usually an orderly model of an orderly process as the engineer conceives it.
The notion that the design process should be modeled as a systematic step-by-step process seems to have first developed in the German mechanical engineering community.
Herbert Simon independently argues for design as a search process in The Sciences of the Artificial. He was motivated to lay out a strictly rational model of design precisely because such a model was a necessary precursor to automating design. His model remains influential even if today we recognize the "wicked problem" of original design as one of the least promising candidates for AI.
In software engineering, Winston Royce independently introduced a seven-step Waterfall Model to bring order to the process. In fact, Royce introduced his waterfall as a straw man that he then argued against, but many people have cited and followed the straw man rather than his more sophisticated models. Even if ironically, Royce's seven-step model must be considered one of the foundational statements of the Rational Model of Design.
Design process models
Any systematization of the design process is a great step forward compared to "Let's just start coding, or building." It:
- Provides clear steps for planning a design project
- Furnishes clearly definable milestones
- Suggests project organization and staffing
- Helps communication within the design team
- Is readily teachable to novices, and tells novices facing their first design assignments where to begin.
The Rational Model in particular brings yet more advantages. The early explicit statement of goals, secondary desiderata, and constraints helps a team avoid wandering, and it breeds team unification on purposes. Planning the whole design process before starting coding or formal drawings avoids many troubles and much wasted effort. Casting the process as a systematic search of a design space broadens the horizon of the individual designers and lifts their eyes far beyond their previous personal experiences.
But the rational model is much too simplistic, even in Simon's richly developed version.
The dual ladder
The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. It it easy to give corresponding salaries to corresponding rungs, but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.
Why does the dual ladder need special attention? Perhaps because managers, being human, are inherently inclined to consider their own tasks more difficult and important than design and need to deliberately assess what makes creativity and innovation happen.
A platonic ideal
As the architecture design progressed, I observed what at first seemed quite strange. For the architecture team, the real System/360 was the Design Concept itself, a Platonic ideal computer. Those physical and electrical Model 50, Model 60, Model 70, and Model 90 things under construction out on the engineering floors were but Plato’s shadows of the real System/360. The real System/360’s most complete and faithful embodiment was not in silicon, copper, and steel, but in the prose and diagrams of IBM System/360 Principles of Operation, the programmer’s machine language manual.
I had a similar experience with the View/360 beach house. Its Design Concept came to be real long before any construction began. It persisted through many versions of drawings and cardboard models.
The design concept
Is there positive value to recognizing an invisible Design Concept as a real entity in design conversations? I think so.
First, great designs have conceptual integrity—unity, economy, clarity. They not only work, they delight, as Vitruvius first articulated. We use terms such as elegant, clean, beautiful to talk about bridges, sonatas, circuits, bicycles, computers, and iPhones. Recognizing the Design Concept as an entity helps us to seek its integrity in our own solo designs, to work together for it in team designs, and to teach it to our youth.
Second, talking frequently about the Design Concept as such vastly aids communication within a design team. Unity of concept is the goal; it is achieved only by much conversation.
Thus, moviemakers use storyboards to keep their design conversations focused on the Design Concept, rather than on implementation details.
The Idea
The design is thus the mental formulation, which Sayers calls “the Idea,” and it can be complete before any realization is begun. Mozart’s response to his father’s inquiry about an opera due to the duke in three weeks both stuns us and clarifies the concept.
For most human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out,” are essential disciplines for the theoretician.
The boldest decisions
In retrospect, many of the case studies have a striking common attribute: the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome. These bold decisions were made due sometimes to vision, sometimes to desperation. They were always gambles, requiring extra investment in hopes of getting a much better result.
Intuition and systems
Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?