Archive for the ‘Design’ Category

Using Simulation

Sherry Turkle’s Simulation and its Discontents takes a disapproving stance towards software that mimics the real world. She surveys many fields of science and engineering, where simulation takes many forms, including protein folding, architectural drawings, and physical phenomena. She highlights how older practitioners miss having their hands on their workpiece, while younger ones are anxious about knowledge they may never have. In the 1980s, simulation drove a wedge between MIT faculty and students; more recently it has been begrudgingly accepted by all.

There is certainly a generation gap here, but it exists as much in the technology itself as in the minds of the scientists. Turkle repeatedly emphasizes the “black box” nature of software, and how its users cannot examine the code themselves. She conveniently ignores the open source movement, which creates software that can be understood, modified, and redistributed by its users. True, much of science and engineering software is still proprietary, and open source offerings are frequently inferior to the paid versions, but she doesn’t even have that discussion.

Secondly, even if we users could see the source, understanding it is not trivial. Her book predates the “learn to code” movement by a few years, but the same objections apply: computer science is an engineering field in its own right, and software should be developed and maintained by specialized practitioners rather than done “on the side” by all engineers. Yes, domain knowledge experts should be brought in when necessary. Research into more advanced programming languages will likely only make the situation worse, as they typically rely on an ever-larger and more abstract body of knowledge in order to work in them, thus catering to the expert over the beginner.

Any simulation that performs calculations that could be done by hand is really an automation. A true simulation, arguably by definition, cannot be fully understood. I agree that all engineers should be able to dash off a few lines to automate a menial task, but simulations are harder. In particular, there are languages (Python and Ruby) that are easy to learn well enough to automate simple tasks. But most simulations aren’t written in these languages. The need for performance drives simulations to be written in C or C++, frequently incorporating many libraries (shared code written by someone else; even programmers don’t understand all of their program). Unlike the command line utilities of yore, graphical user interfaces and high-performance graphics rendering require specialized and complex programming techniques. Integrating with the internet or a database makes programs more complicated still. Finally the size of programs has ballooned. There is so much code in a typical piece of software, and it is so complex, that I find it naive when non-programmers to insist that if only they could see the code, they could understand it.

Programs and programming today are far more complicated than in the 1980s. The most advanced climate models consist of a million lines of FORTRAN code, simulating equations from many disparate fields of natural science. They are beyond the understanding of any single individual. And indeed, understanding is no longer the goal. Just as technology has allowed us to see things invisible to our eyes, and hear things inaudible to our ears, simulation allows us to think things incomprehensible to our brains.

Turkle certainly grasps that deep, full understanding is imperiled, but only in her conclusion does she so much as entertain the notion that this may be necessary or good. Simulation may open up new possibilities more than it closes them. Science has surpassed the point of what can be understood by crystaline thought; the future is noisier and approximate. Robert Browning wrote that “a man’s reach should exceed his grasp”. A fictionalized Nikola Tesla ponders this quote in The Prestige, with the context that what man can affect, he cannot always control. Turkle would do well to heed his next remark: “It’s a lie. Man’s grasp exceeds his nerve.”

How do we get the nerve to embrace the new future of simulation? In part, by addressing specific concerns raised by Turkle’s interviewees. Defaults are too tempting, so we shouldn’t provide them. A design can appear finalized before it actually is, preventing further iteration, so displays can mimic physical imprecision. High-level summaries should allow the user to see examples, to jump between layers, to see why the computer has classified or calculated the way that it did. Nevertheless I expect changes in simulation to come primarily from software engineering and culture rather than the technology itself.

Turkle gives an example of a protein folding simulation devising a molecule that is clearly wrong to the biologist, because it defies her understanding of how proteins work. But what is her thought process if not another simulation? Perhaps it is more correct than the software in this case, but in general, thinking and outlining should be considered the cheapest, fastest, and lowest-fidelity of many simulation tools available to us. Intuition can be powerful, but it can also be wrong, and any claim in science or engineering requires more than intuition to support it. More formalized methods of thinking (how did they build skyscrapers in the 1920s?) are just following algorithms that the machine can do today, faster and with (potentially!) fewer errors. If the biologist can articulate her thought process, it can be automated, and if the cannot, it’s mere intuition.

With regards to creativity, simulation  and I include the word processor here — is a double-edged sword. When the barrier to creation is low, we can get our thoughts out quickly, and complete the dreaded first draft. Ideas and structure form and reflow on the fly.  The work is crafted interactively, iteratively, in a continuous and tight feedback loop. Human and simulation play off each other. This is clearly better than the computer working in isolation, such as the protein folding program that merely produced the “right” answer. What I propose is that it may also be superior to humans working “blind”, creating ideas fully in their heads, attempting to simulate them there, in discrete drafts. This model is a relic of hand- or typewritten pages, technologies where copying wasn’t instant. The downside is that it’s easy to do less thought before writing, and the end product may lack a harmonious global structure as a result. The compromise is to work with many tools of increasing fidelity and expense. When an idea does not work, we desire to “fail fast”  in the least expressive medium in which the flaw is manifest.

Frequently ideas we think are brilliant fall over when confronted, and a simulation can fail fast, can confront them quickly. In user interface design, paper prototypes are created not for the designer but for a test subject, and all the intellectualized beauty in the world means nothing if the user can’t operate the interface. This echoes a fundamental tenant of engineering across the board: you are not designing for yourself. What you think doesn’t matter unless validated by a ruthlessly objective third party. Writing now forms the exception: to reify human thought itself without the consent of the external world shifts the burden onto the author. Yet even though the writer struggles to crystalize his ideas as much as possible prior to composing them, he knows the value of trusted readers to provide feedback.

This leads us to the notion of software testing, which is all but absent from Turkle’s book. Provably correct software is an active area of research, so those shipping software today verify its correctness empirically. Testing exists on many scales, from system-wide routines of many actions to “unit tests” that cover as small a functionality as possible. Although typically written by the developers, a user can also benefit from writing unit tests, as they force her think about and articulate how the simulation would act in a very controlled instance. She will build confidence that the simulation matches her ideas. When a test fails, either the simulation, her understanding, or her ability to articulate her understanding, is incomplete.

Testing software is a philosophical shift from understanding it, moving programming away from science and towards engineering. Scientists will protest that experimenting on a designed thing is less effective than understanding the design directly, to which I respond by challenging the notion that software is designed. I have already discussed the staggering complexity of some software, and this should lead us to treat it as discovered rather than invented, and therefore investigated by experimentation rather than reverse-engineering. We explore simulation as an image of the real world: highly accurate but imperfect, yet faster, cheaper, and more versatile.

George Box, the statistician (what are statistics if not a simulation?), wrote that “all models are wrong, but some are useful”. He diffuses Turkle’s claim that simulations mislead by agreeing with it, and then salvages utility. He deconstructs and reconstructs simulation as a practice in a sentence. It is certainly worthwhile to make our models less wrong or more transparent when possible (these are often competing aims), and to supplement simulations with the real. Still, as in all discussions on culture-shaping technology, we must conclude that the main approach must be to use the technology more prudently, rather than ban it or hope that it will go away. Whether simulation acts as a magnifying glass or a funhouse mirror depend on how you look at it.

Type:Rider and Flappy Bird

I wouldn’t have thought typography could be the subject of a video game, but Type:Rider does just that. The levels are a tour of Western history from the middle ages onward, each corresponding to a different typeface in the context of its era. The Gothic type’s levels take cues from medieval churches while the 1920’s Futura feels like a modern art museum. The player’s avatar is a colon, two rolling dots bound together by some magnetic-seeming attraction. Gameplay consists of navigating through terrain including each letter of the alphabet rendered in the that typeface. The letters are arranged to create interesting geometrical puzzles that make them memorable. The player also navigates through oversized versions of the printing technologies of the day, meanwhile collecting asterisks that unlock brief passages about the key figures and inventions of the time period.

There are a number of features that make Type:Rider stand out. It is highly polished, with beautiful visual environments and suitable thematic music. (Surprisingly the typesetting of the informative passages is often found wanting; perhaps the English translation wasn’t proofed by the original European developers?) The controls are relatively expressive, in that with a few taps the skilled player can move the colon in one of many possible ways. The game has value: it took a team of experienced designers and developers time and money to create it, and the user must expend time and money to enjoy it. But yet, the game has a deeper message. Yes, it’s about typography, but mere type is the means by which we transfer knowledge; typography is the beatification of knowledge. Typography rewards diligence, attention to detail, graphical density, and knowledge of prior work. Typography is the wings on which intellectualism is borne.

Contrast this with the maddeningly weak and imprecise wings of Flappy Bird. Wired does a good job recounting the saga of the infamous iOS game and its creator, Dong Nguyen. Anyone can pick up the game and play it immediately, but playing well is exceedingly difficult: mastery and skill-building are sacrificed on the alter of ease-of-use. Play happens in all-too-brief bouts, which provide instant gratification with no time commitment. No depth of knowledge, skill, or artistic message is ever accumulated.

Papert distinguishes between children programming computers and computers programming children, and this is certainly the latter. Flappy bird conditions one exact response, with no room for exploration or creativity. No justification is given as to why the world must be the way it so firmly is. More concretely, flappy bird is fake difficulty, riding on an artificially narrow method of control. It perniciously makes the smart phone, and the human, less smart.

Dong Nguyen made (and is likely still making) fifty thousand dollars a day off advertising shown to the game’s users. I highly doubt the users (largely teens) are spending anywhere close to that amount of money on the advertised products. Flappy bird generates money but not wealth; like doomed financial products it is built on value that simply isn’t there. Sooner or later, this bubble must burst.

But despite the attention directed towards Flappy bird, it is hardly unique. Only four of the top fifty grossing apps (as of when I checked) are not games (Pandora, Skype, and two dating apps). The rest are games, targeted at the under-20 crowd, driven by ads and in-app purchases (which include the removal of ads). The app store has become Western kids in a gigantic candy store, and this has pushed adults and their fine intellectual cuisine off to the margins. The market has spoken: mass-produced low-quality ad-ridden software for entitled children is what sells, adults and society be damned.

I will quote (again) from Jaron Lanier, You Are Not A Gadget: “Rooms full of MIT PhD engineers [are] not seeking cancer cures or sources of safe drinking water for the underdeveloped world but schemes to send little digital pictures of teddy bears and dragons between adult members of social networks. At the end of the road of the pursuit of technological sophistication appears to lie a playhouse in which human kind regresses to nursery school.”

Even Type:Rider is not immune. It has the requisite Facebook and Twitter integration, though they are less prominent. It is also available as a Facebook game. What is offers, then, is not a completely pure solitary experience but rather a compromise given the nature of the market.

It is said that technology changes quickly and people change slowly, but the reality is more complex. People have shown a remarkable ability to adapt to new technologies, without fundamentally altering how they think or what goals they have. Meanwhile, the face of technology changes, but many ideas remain timeless and fixed, old wine repackaged into new bottles. Furthermore standards and protocols by which devices communicate with each other, once set, become incredibly difficult to change. We are in danger of not changing with technology, and then creating technology that prevents us from changing.

Of Signs, Skyscrapers, and Software

I was looking for a book on data visualization. Having gone through Edward Tufte’s classics, I browsed the Tufts library catalog by “visualization”. The two keepers were only tangentially related, but I’ve learned that I sometimes attack problems too directly, so I checked out Signage and Wayfinding Design by Chris Calori and The Heights: Anatomy of a Skyscraper by Kate Ascher. Both have involve service through the built environment. That is, unlike the social justice programs that many of my classmates engage in that serve interpersonally, these books see service conducted through the proxy of a created object. This model appeals to me because the object can serve many more people than I could personally interact with. The object endures to serve in the future, as opposed to the many charitable acts that have vanishingly immediate returns. That is, service through objects is more efficient.

In the case of signage, it is intellectual service. Wayfinding provides empowering knowledge much the way that software can (should). Signage also serves a secondary placemaking role. Signs not only describe the built environment; they are part of it; they should embody emotions, preferring to lend character to its environment over abstract minimalism. Therefore, signs walk the same tightrope that infographics do, between information clarity and contextual aesthetics.

Chris Calori leaves no stone unturned as she documents the full process of signage production. On one hand, it is ruthlessly physical, with details such as mounting, dimensions, lighting, materials, and finishes to be specified prior to fabrication. Much of the waterfall-like process is principled on preventing the full construction of a faulty signage program, by using detailed plans, miniatures, prototypes, and renderings. On the other hand, signage is a great example of the divide between art and design. Art attempts to communicate non-obvious truths through subtety that takes time to absorb. Signage (and design) is just the opposite: communicate rather mundane information quickly and unambiguously. Calori defines the pyramid model of signage, which encompasses the information content, the graphics, and the hardware. Design subdivides into the abstract information, concerned with hierarchies and placement, and graphics, concerned with symbols, diagrams, and typefaces. The book thoroughly addresses each of these, as well as the regulatory and legal concerns one is likely to encounter along the way. It also includes thirty-two pages of color photographs of finished signage programs, which are not to be missed.

As for The Heights, the book itself is intellectual service. Printed in full color, it’s a surprisingly detailed-yet-accessible look at the engineering and planning behind tall buildings. Want to know about cranes, air handlers, curtain walls, elevator safety, green roofs, fire sprinklers, floor plates, pile drivers, and window washers? It’s all there, with helpful illustrations. Section titles are printed in a 3D extruded typeface that resembles a building (for once, a justified use case) and the table of contents is done delightfully as an elevator directory, reading from bottom to top. Wayfinding is not mentioned in the text, but its principles are applied to the presentation itself.

Of course, the very act of creating a well-designed skyscraper contributes tremendously to the built environment. Such a building can provide living and working space for thousands of people for a century. Design decisions can become crucially important or confining decades after they were made. Unlike Calori’s laser-focus, the skyscrapers involve thousands of people of diverse education and wealth backgrounds, from construction workers to financiers, tenants to janitors. Construction on this scale is an act with huge societal ramifications. Engineering is not neutral, politically, socially, or ethically.

But the authors are undaunted. They strive to make objects, whether signs or skyscrapers, that make life more enjoyable, more comprehensible, and more fair for all who come into contact with them. Through technical competence, goal-oriented design, hard work, and luck, objects large and small come to enrich our lives. What kind of object do you want to make?

Infographics and Data Graphics

I’d like to set the record straight about two types of graphical documents floating around the internet. Most people don’t make a distinction between infographics and data graphics. Here are some of each – open them in new tabs and see if you can tell them apart.

No peeking!

No, really, stop reading and do it. I can wait.

Okay, had a look and made your categorizations? As I see it, dog food, energy, and job titles are infographics, and Chicago buildings, movie earnings, and gay rights are data graphics. Why? Here are some distinctions to look for, which will make much more sense now that you’ve seen some examples. Naturally these are generalizations and some documents will be hard to classify, but not as often as you might think.

Infographics emphasize typography, aesthetic color choice, and gratuitous illustration.
Data graphics are pictorially muted and focused; color is used to convey data.

Infographics have many small paragraphs of text communicate the information.
Data graphics are largely wordless except for labels and an explanation of the visual encoding.

In infographics, numeric data is scant, sparse, and piecemeal.
In data graphics, numeric data is plentiful, dense, and multivariate.

Infographics have many components that relate different datasets; sectioning is used.
Data graphics have single detailed image, or less commonly multiple windows into the same data.

An infographic is meant to be read through sequentially.
A data graphic is meant to be scrutinized for several minutes.

In infographics, the visual encoding of numeric information is either concrete (e.g. world map, human body), common (e.g. bar or pie charts), or nonexistent (e.g. tables).
In data graphics, the visual encoding is abstract, bespoke, and must be learned.

Infographics tell a story and have a message.
Data graphics show patterns and anomalies; readers form their own conclusions.

You may have heard the related term visualization – a data graphic is a visualization on steroids. (An infographic is a visualization on coffee and artificial sweetener.) A single bar, line, or pie chart is most likely a visualization but not a data graphic, unless it takes several minutes to absorb. However, visualizations and infographics are both generated automatically, usually by code. It should be fairly easy to add new data to a visualization or data graphic; not so for infographics.

If you look at sites like which collects visualizations of all stripes, you’ll see that infographics far outnumber data graphics. Selection bias is partially at fault. Data graphics require large amounts of data that companies likely want to keep private. Infographics are far better suited to marketing and social campaigns, so they tend to be more visible. Some datasets are better suited to infographics than data graphics. However, even accounting for those facts, I think we have too many infographics and too few data graphics. This is a shame, because the two have fundamentally different worldviews.

An infographic is meant to persuade or inspire action. Infographics drive an argument or relate a story in a way that happens to use data, rather than allowing the user to infer more subtle and multifaceted meanings. A well-designed data graphic can be an encounter with the sublime. It is visceral, non-verbal, profound; a harmony of knowledge and wonder.

Infographics already have all the answers, and serve only to communicate them to the reader. A data graphic has no obvious answers, and in fact no obvious questions. It may seem that infographics convey knowledge, and data graphics convey only the scale of our ignorance, but in fact the opposite is true. An infographic offers shallow justifications and phony authority; it presents that facts as they are. (“Facts” as they “are”.) A data graphic does not foster any conclusion upon its reader, but at one level of remove, provides its readers with tools to draw conclusions. Pedagogically, infographics embrace the fundamentally flawed idea that learning is simply copying knowledge from one mind to another. Data graphics accept that learning is a process, which moves from mystery to complexity to familiarity to intuition. Epistemologically, infographics ask that knowledge be accepted on little to no evidence, while data graphics encourage using evidence to synthesize knowledge, with no prior conception of what this knowledge will be. It is akin to memorizing a fact about the world, or accepting the validity of the scientific method.

However, many of the design features that impart data graphics with these superior qualities can be exported back to infographics, with compelling results. Let’s take this example about ivory poaching. First off, it takes itself seriously: there’s no ostentatious typography and the colors are muted and harmonious. Second, subject matter is not a single unified dataset but multiple datasets that describe a unified subject matter. They are supplemented with non-numeric diagrams and illustrations, embracing their eclectic nature. Unlike most infographics, this specimen makes excellent use of layout to achieve density of information. Related pieces are placed in close proximity rather than relying on sections; the reader is free to explore in any order. This is what an infographic should be, or perhaps it’s worthy of a different and more dignified name, information graphic. It may even approach what Tufte calls “beautiful evidence”.

It’s also possible to implement a data graphic poorly. Usually this comes down to a poor choice of visual encoding, although criticism is somewhat subjective. Take this example of hurricanes since 1960. The circular arrangement is best used for months or other cyclical data. Time proceeds unintuitively counterclockwise. The strength of hurricanes is not depicted, only the number of them (presumably – the radial axis is not labeled!). The stacked bars make it difficult to compare hurricanes from particular regions. If one wants to compare the total number of hurricanes, one is again stymied by the polar layout. Finally, the legend is placed at the bottom, where it will be read last. Data graphics need to explain their encoding first; even better is to explain the encoding on the diagram itself rather than in a separate legend. For example, if the data were rendered as a line chart (in Cartesian coordinates), labels could be placed alongside the lines themselves. (Here is a proper data graphic on hurricane history.)

An infographic typically starts with a message to tell, but designers intent on honesty must allow the data to support their message. This is a leap of faith, that their message will survive first contact with the data. The ivory poaching information graphic never says that poaching is bad and should be stopped, in such simple words. Rather it guides us to that conclusion without us even realizing it. Detecting bias in such a document becomes much more difficult, but it also becomes much more persuasive (for sufficiently educated and skeptical readers). Similarly, poor data graphics obscure the data, either intentionally because they don’t support the predecided message, or unintentionally because of poor visual encoding. In information visualization, as in any field, we must be open to the hard process of understanding the truth, rather than blithely accepting what someone else wants us to believe.

I know which type of document I want to spend my life making.

As We May Have Thought

Vannevar Bush wanted to build machines that made people smarter. His 1945 paper, As We May Think, described analog computers that captured and stored information, the earliest vision of today’s internet. All of Bush’s hopes for chemical photography have been surpasses by today’s digital cameras, and digital storage media are more compact than the most hopeful predictions of microfilm. He also predicts dictation, and though today’s software does a passable but not perfect job, it has not reached the level of ubiquity Bush predicts. He is also wrong about the form factor of cameras, predicting a walnut-sized lens mounted like a miner’s lamp. The result is similar to Google Glass, and no other product:

One can now picture a future investigator in his laboratory. His hands are free, and he is not anchored. As he moves about and observes, he photographs and comments. Time is automatically recorded to tie the two records together.

As for selecting information from the ensuing gigantic database, Bush posits the “Memex”, a desk with displays built into it. The memex is personal, allowing users to connect pieces of information together into trails for later examination. The memex is personal and built on connections, much like the mind.

The late Douglas Engelbart expanded on the purely hypothetical Memex with NLS, short for oNLine System. In “the mother of all demos”, he showed how users traverse and manipulate trees of data, with rich transclusion of content. Unlike the Memex, real-time sharing is possible by way of video chat. Like the memex, NLS was primary text, and the user-facing component was the size of a desk.

And yet … Bush and Englebart’s systems are not psychologically or sociologically realistic. Though Bush was writing in 1945, his vision seemed Victorian: a facade of proper intellectualism with no grounding in the less dapper side of human nature. One can hardly imagine multimedia beyond classical music and Old Master paintings emanating from the memex.  Bush used the effectiveness of Turkish bows in the crusades as an example of what one could research on a Memex. He missed the target. The Memex and NLS were designed for a race of hyper-rational superhumans that do not exist.

The fictitious enlightened user would emphasize restraint, but today’s technology can, for all intents and purposes, do anything. The ability to do anything is less productive and more dangerous than it sounds. Intellectually, such a system encourages slapdash and incomplete thought. It does not force you to abandon weaker ways of thinking; it gives you no guidance towards what will work, what will work well, and what will not work at all. Sociologically, the availability of information on a scale beyond what Bush could have dreamed hasn’t made us an enlightened society. Having correct information about (for example) evolution readily available online has not made a dent in the number of people who read Genesis literally. And it gets worse.

Moore’s law may be the worst thing to happen to information technology. With computing so cheap and so ubiquitous, with the ability to do anything, we have overshot the island of scarcity inhabited by Bush and Engelbart and into the land of social media, entertainment, and vice. The universal systems for the betterment of humanity have fallen to fragmented competitors in an open market. The emphasis on mobile these last six years has led to apps of reduced capability, used in bursts, on small screens with weak interaction paradigms. This is what happens when there’s more computing power in your pocket than Neil Armstrong took to the moon: we stop going to the moon.

Recreational computation is here to stay, but we may yet partially reclaim the medium. Clay Shirky is found of pointing out that erotic novels appeared centuries before scientific journals. Analogously, we should not be deterred by the initial explosion of inanity accompanying the birth of a new, more open medium.

I can only hazard a guess as to how this can be done for recreational computing: teach the internet to forget. (h/t AJ Keen, Digital Vertigo) One’s entire life should not be online (contrary to Facebook’s Timeline – it’s always hard to change ideas when corporations are profiting on them). A good social website would limit the ways in which content can be produced and shared, in an attempt to promote quality over quantity. Snapchat is a promising experiment in this regard. There’s been talk of having links decay and die over time, but this sees like a patch on not having proper transclusion in the first place.

As for programming, though, the future is constrained, even ascetic. If Python embodies the ability to do anything, then the future is Haskell, the most widely-used [citation needed] functional programming language.

Functional programming is a more abstract way of programming than most traditional languages, which use the imperative paradigm. If I had to describe the difference between imperative programming and functional programming to a layperson, it would be this: imperative programming is like prose, and functional programming is like poetry. In imperative programming, it’s easy to tack on one more thing. Imperative code likes to grow. Functional code demands revision, and absolute clarity of ideas that must be reforged for another feature to be added. In functional languages, there are fewer tools available, so one needs to be familiar with most of them in order to be proficient. Needless to say, imperative languages predominate outside of the ivory tower. Which is a shame, because imperative languages blithely let you think anything.

The problem with thinking anything is similar to doing anything: there’s no structure. But if we can’t think anything than some good ideas may remain unthought. There is a tension between thinking only good ideas and thinking any idea. In theory at least, this is the relationship between industry and academia. While companies want to produce a product quickly,  academia has developed programming paradigms that are harder to use in the short term but create more manageable code over time. These are all various ways of imposing constraints, of moving away from the ability to do anything. Maybe then we’ll get something done.

The Top 5 Things Done Wrong in Math Class

Sorry to jump on the top-n list bandwagon, as Vi Hart deliciously parodies, but that’s just how this one shakes out. Some of the reasons why these things are done wrong are pretty advanced, but if you’re a high school student who stumbled upon this blog, please stay and read. Know that it’s okay that you won’t get everything.

All of these gripes stem from the same source: they obfuscate what ought to be clear and profound ideas. They’re why math is hard. Like a smudge on a telescope lens, these practices impair the tool used to explore the world beyond us.

EDIT: This list focuses on notation and naming. There are other “things” done wrong in math class that any good teacher will agonize over with far more subtlety and care than this or any listicle.

5. Function Composition Notation

Specifically f \circ g, which is the same as g(f(x)). No wait, f(g(x)). Probably. This notation comes with a built-in “gotcha”, which requires mechanical memorization apart from the concept of function composition itself. The only challenge is to translate between conventions. In this case, nested parentheses are ready-made to represent composition without requiring any new mechanistic knowledge. They exploit the overloading of parentheses for both order of operations and function arguments; just work outwards as you’ve always done. We should not invent new symbols to describe something adequately described by the old ones.

Nested parentheses lend themselves to function iteration, f(f(x)). These functions are described using exponents, which play nice with the parens to make the critical distinction between f^2(x) = f(f(x)) and f(x)^2 = (f(x))^2 = f(x)f(x). This distinction becomes critical when we say arcsine aka \sin^{-1} and cosecant aka \frac {1}{\sin} are both the inverses of sine. Of course, things get confusing again when we drop the parens and get \sin^2x = (\sin x)^2 because \sin x^2 = \sin (x^2). This notation also supports  first-class functions: once we define a doubling function d(x) = 2x, what is meant by d(f)? I’d much rather explore this idea, which is “integral” to calculus (and functional programming), than quibble over a symbol.

4. The Word “Quadratic”

I’m putting “quadratic” where it belongs: number four. The prefix quadri- means four in every other context, dating back to Latin. (The synonym tetra- is Greek.) So why is x^2 called “quadratic”? Because of a quadrilateral, literally a four-sided figure. But the point isn’t the number of sides, it’s the number of dimensions. And dimensionality is tightly coupled with the notion of the right angle. And since x equals itself, then we’re dealing with not just an arbitrary quadrilateral but a right-angled one with equal sides, otherwise known as a square. So just as x^3 is cubic growth, x^2 is should be called squared growth. No need for any fancy new adjectives like “biatic”, just start using “square”. (Adverb: squarely.) It’s really easy to stop saying four when you mean two.

3.14 Pi

Unfortunately, there is a case when we have to invent a new term and get people to use it. We need to replace pi, because pi isn’t the circle constant. It’s the semicircle constant.

The thrust of the argument is that circles are defined by their radius, not their diameter, so the circle constant should be defined off the radius as well. Enter tau, \tau = \frac{C}{r}. Measuring radians in tau simplifies the unit circle tremendously. A fraction time tau is just the fraction of the total distance traveled around the circle. This wasn’t obvious with pi because the factor of 2 canceled half the time, producing \frac{5}{4}\pi instead of \frac{5}{8}\tau.

If you’ve never heard of tau before, I highly recommend you read Michael Hartl’s Tau Manifesto. But my personal favorite argument comes from integrating in spherical space. Just looking at the integral bounds for a sphere radius R:

\int_{\theta=0}^{2\pi} \int_{\phi=0}^{\pi} \int_{\rho=0}^{R}

It’s immediately clear that getting rid of the factor of two for the \theta (theta) bound will introduce a factor of one-half for the \phi (phi) bound:

\int_{\theta=0}^{\tau} \int_{\phi=0}^{\frac{\tau}{2}} \int_{\rho=0}^{R}

However, theta goes all the way around the circle (think of a complete loop on the equator). Phi only goes halfway (think north pole to south pole). The half emphasizes that phi, not theta, is the weird one. It’s not about reducing the number of operations, it’s about hiding the meaningless and showing the meaningful.

2. Complex Numbers

This is a big one. My high school teacher introduced imaginary numbers as, well, imaginary. “Let’s just pretend negative one has a square root and see what happens.” This method is backwards. If you’re working with polar vectors, you’re working with complex numbers, whether you know it or not.

Complex addition is exactly the the same as adding vectors in the xy plane. It’s also the same as just adding two numbers and then another two numbers, and then writing i afterwards. In this case, you might as well just work in R^2. (Oh hey, another use of exponents.) You can use the unit vectors \hat{x} and \hat{y}, rather than i and j which will get mixed up with the imaginary unit, and besides, you defined that hat to mean a unit vector. Use the notation you define, or don’t define it.

Complex numbers are natively polar. Every high school student (and teacher) should read and play through Steven Witten’s jaw-dropping exploration of rotating vectors. (Again students, the point isn’t to understand it all, the point is to have your mind blown.) Once we’ve defined complex multiplication – angles add, lengths multiply – then 1 \angle 90^{\circ} falls out as the square root of 1 \angle 180^{\circ} completely naturally. You can’t help but define it. And moreover, (1 \angle -90^{\circ})^2 goes around the other way, and its alternate representation (1 \angle 270^{\circ})^2 goes around twice, but they all wind up at negative one. Complex numbers aren’t arbitrary and forced; they’re a natural consequence of simple rules.

Even complex conjugates work better with angles. Instead of an algebraic argument and a formula to memorize, we can geometrically see that we we need to add an angle that brings us back to horizontal, which is just the negative of the angle we already have. This is mathematically equivalent to changing the sign on the imaginary component of the vector, but cognitively it’s very different. You can, with clarity and precision, see what you are doing in a way numerals can never express.

1. Boxplots

Boxplots make the top of the list because they’re taught at a young age and never challenged. They are brought up as a standard way to visualize data, when the boxplot was a relatively recent invention of one statistician, John Tukey. Edward Tufte has proposed variants which dramatically reduce the ink on the page. They are much easier to draw, which is important when you want to convince children that math isn’t about meticulous marks on the page. They have no horizontal component, so in addition to being more compact, they also do not encode non-information in their width.


Boxplots infuriate me because they indoctrinate the idea that there is one way to do it, and that it is not up for discussion. More time is spent on where to draw the lines than why quartiles are important, or how to read what a boxplot says about that data. Boxplots epitomize math as a recipebook, where your ideas are invalid by default and improvisation is prohibited. Nothing could be further from the truth. Moreover, boxplots slap a one-size-fits-all visualization on the data without bothering to ask what other things we could do with them. Tukey’s plots don’t just obscure the data, they obscure data science.

Visualizing Complexity

This post could be considered the third of three responding to Bret Victor’s trio of talks; the previous ones were Abstraction and Standardization and Media for Thinking the Eminently Thinkable.

Question: what makes a program complex? Answer: time.

There are multiple types of time. The obvious one, the one measured by stopwatches, I’ll call physical time. A small program promotes a tight feedback loop, where the effect of a change is visible in a few seconds. Large programs take longer to compile and run, as do those dealing with large amounts of data. To help offset this, programming languages developed threading and concurrency. An expensive task can be queued up, so it will happen at some point in the future. This sort of parallelism makes programs much harder to reason about and test.

Then there’s logical time. This includes event-based programming, which usually involves a GUI. A user’s clicks and drags become events to which the system responds. Code is called when something happens, not when the thing before it ends. Rather than a procedural recipe racing towards the final answer, these programs are state machines, looping indefinitely and branching in response to an arbitrary sequence of events.

Finally, for completeness, there’s developer time. Memories fade, requirements change, people join or leave the project, the technology itself changes. Like people, code deteriorates as it ages, although measures can be taken to mitigate the decline. Any large codebase has annoying “legacy code” kept around for “historical reasons” and “backwards compatibility”.

In his talk Drawing Dynamic Visualizations, Bret Victor presents a drawing tool where the user creates a program by direct manipulation. This program can be used to create custom pictures for multiple datasets (different measurements of the same variables). The results feel very “PowerPoint-y”, the sort of thing you’d present in a board room or paper scientific journal. The method of creation is new, but the results emulate old media.

If you’re reading this, Bret, and think I’m a bit obsessed, (1) thanks for noticing (2) this will likely be the last post about you for awhile.

Users can step through the drawing program, but it’s capable of running instantaneously (i.e. without time and therefore much complexity) . There’s no need for a visualization to wait for a network event, but a good visualization reacts to mouse motions, like hover, click and drag. Interactivity is a crucial component of visualization. Victor has made a great way to make charts for boardroom presentations, but he hasn’t allowed the user to interact with the data. The visualization is “dynamic” in that it accommodates new data, but it doesn’t react to the user. I’m not asking to drag a bar to set the data to that point; we’re working under the assumption that the underlying data is fixed. And I can abstract any color or magic number as a parameter, so I can set data-independent features of the graph like error bars dynamically. But without interactivity, we can only accomplish the first third of Shneiderman’s mantra:

Overview first, zoom and filter, then details-on-demand.

Without interactivity, we can’t zoom or filter or otherwise adjust the visualization to get our details on demand. All we have is an overview. Our visualization sits there, dead. This is not good enough. Data today is so complex that even the best static image isn’t going to elucidate subtle meanings. Instead we need interactivity so that the visualization reacts to the user, not just the designer. I should clarify straight away that I’m not talking about the interactivity Victor rails against in his paper Magic Ink, where the user has a specific, often mundane question she wants answered. (How long will I wait for the bus? What move theater should I go to?) I’m talking about systems where the user doesn’t know what she wants, and needs to explore it to develop an intuition or notice something strange.

There is a disconnect, an asymmetry, in Victor’s work. In Stop Drawing Dead Fish, we had a novel direct manipulation tool and interactivity with its results. In Drawing Dynamic Visualizations, we had a novel direct manipulation tool and dynamic data. In Media For Thinking The Unthinkable, specifically the part on signal processing, we had interactivity and dynamic data. Create with direct manipulation, load dynamic data, interact with the result: pick two.

How can we add interactivity to Victor’s tool? Let’s start with mouseover. As a function of the mouse position, which can be considered an input, hover is stateless. The tool can run geometric collision detection on its primitives and provide a boolean measurement (output) as to whether the shape is being hovered over. If you want to use this information to, say, change the shape’s color, you have to have shapes able to read their own outputs. This can lead to feedback loops. If we draw nothing on mouseover, then we’re not being moused over anymore, so we go back to drawing our shape, which is now being moused over…and suddenly our system has state, and “flickers” indefinitely. Worse, by creating a place for code that is executed only if certain external conditions are true, we create asynchronous, “jumpy” code. This is a large increase in physical and logical time.

Selecting a shape runs into similar problems, an additionally requires a global variable (internal, not a parameter) to keep track of the selection. It gets even worse if we want to add collision detection between objects, like a force-directed diagram. (Actually that’s not collisions, just proximity-based repulsion, but roughly the same idea.) Even if the system manages to detect when two subpictures touch, they now will need a place for code that is called when that is the case. Victor briefly demonstrated how physics can be simulated by using a guide vector to geometrically represent velocity, which we could presumably shift in reaction to the angle of line contact. But we’re starting to think of shapes as their own entities, having state represented in guides associated with them, rather than being drawn and forgotten about. This brings us into Object Oriented Programming, the traditional choice for this sort of interactivity. It’s a great paradigm but it’s quite foreign to Victor’s tool. (Although his Stop Drawing Dead Fish tool lets its user do exactly this. Maybe the line between data scientists and visual artists, or perhaps their tools, is blurring…)

There’s a brief moment where Victor abstracts a color from a shape, and makes it a parameter. This parameter starts off as numeric but changes to a color, likely in response to a keyboard command. If the tool already has a notion of types, that a number is not a color, then there’s a piece of complexity already imported from traditional programming. Types, OOP, collision detection, encapsulated mutable state – all of these ideas have their place in code. There are also a number of mainstays of drawing tools we could include, like gradients, z-order, manual kerning, and the dropper tool. Deciding which of these to include and which to omit, and how to integrate them into the tool, will require some careful design decisions. I wonder how many of these ideas we can pile into the tool before either the graphical interface or the layperson’s acuity collapses under the weight of the complexity.

I, like Victor, and frustrated at the state of software and computing. Most artists are able to react with their medium, to try something, revise it, and use mistakes as inspiration. Listen to how creators in fields as diverse as painting and carpentry discuss a problem. It’s always about sculpting the unruly workpiece material with capable and precise tools, man vs. nature. So why then are computers, where the tool and the medium are one and the same, so limiting that our society can’t see them as anything other than frustratingly complex? Instead of using the medium to find out what she wants to create, the creator has trouble merely realizing what’s in her head. We need a fundamental overhaul of the tools we use for thinking. These tools should let humans, data, and simulation work together. Victor produces tantalizing glimpses of such tools with ease.

Maybe there are true geniuses out there. People who effortlessly sift through complexity, and can make bold pronouncements with confidence. The rest of us have to fake it. We get mired in the cacophany of voices and ideas, paths to choose and tools to use. We do our best to make sense of them but always wonder, in a grass-is-greener sort of way, if we’re missing the point entirely.