The idea of “different views on the same data” is crucial. It’s ubiquitous in desktop applications—so much so that we forget about it—the proverbial water to the proverbial fish. It’s not nearly as common in modern web apps as it should be. Here are some examples, that we may better grasp just how basic and fundamental this concept is.

Example one: Finder windows

Note for non-Mac-users: the Finder is the graphical file manager on the Mac OS. (It also does other things, but that's the part of its role that we're concerned with here.)

In all of the examples in this section, the data is the same: “what files are in this folder?” Let’s look at some of the possible views onto this kind of data.

Figures 1–4 show the same folder in each of the four different available view modes: list, icon, column, and cover flow.

Let's play a game of “spot the difference” between Fig. 1 (list view) and Fig. 2 (icon view). Here we're not concerned with visual differences, but with UX differences. Here's a partial list:

(1) List view shows more metadata. (Here we see modification date, size, type; view options allow us to show more/other columns, like date added, version, tags, etc.)

Does the icon view show no metadata at all? Nope, it shows at least one piece of metadata: the file type—via the file icon. (This is an example of multiplexing; the icon has to be something—to provide a visual representation of a file, and to provide a click target—so why not multiplex file-type data into it?)

Of course, the icon is also visible in list view (but smaller); this means that in list view, file type is conveyed twice (if the “Kind” column is enabled). This is an example of redundancy in UI design, and of good use of sensory (in this case, visual) bandwidth (of which there is quite a lot!). Notice that this redundancy affords the UI a degree of freedom it would not otherwise have: the “Kind” column can be turned off (making room for other data columns, or allowing the window to be made smaller, to make room for other stuff on the screen) with minimal loss of information throughput for the UI.

But wait! What about the file name? There's metadata lurking there, too—the file type again, encoded this time in the file extension. Redundancy again; the file type is therefore displayed in three ways in list view (“Kind” column, icon, file extension) and in two ways in icon view (icon, file extension).

All of this gives the UI several degrees of freedom. How is this freedom spent? In at least two ways:

1. To allow for one or more of the channels through which file type information is communicated to be disabled or repurposed in certain circumstances, with minimal loss of information. (An example of a disabled channel: the “Kind” column is absent in icon view, but file type information is still visible. For an example of a repurposed channel, see the notes on Figures 5–9, below.)
2. To compensate for unreliability of some or all of the channels through which file type information is communicated. Sources of unreliability include:
   • The Finder may not recognize some obscure file types (the “Kind” column would then display no useful information); the file extension may be the only source of file type data in this case
   • The file extension may be missing (but Finder attributes may be set, thus allowing an appropriate icon to be shown and an appropriate value to be displayed in the “Kind” column)
   • The file icon channel may be repurposed (Again, see the notes on Figures 5–9, below, for an example)

(2) List view allows sorting. (Click on a column name to sort by that column's value; click again to reverse the sort order.)

… or is this really a difference? Actually, files can be sorted in icon view as well (there is both a “one-time sort” option and a “keep sorted by…” option). This is not obvious, because the UI for sorting in icon view is not discoverable by mere physical inspection, whereas in list view the column headers are visible, the sort order indicator is visible (the triangle, pointing up or down), and the “click column header to sort tabular data by that column's value” is a well-known idiom. (In icon view, sorting is done via a menu—either from the menubar, or from the context menu, or from a menu in the window toolbar.)

There is, however, a more subtle difference: in icon view it is not possible to sort in reverse order. Why not? The only reason is that Apple was unable (or unmotivated) to design a good UI for reversing sort order in icon view.

General lessons:

• The same (or analogous) forms of interaction with the data may be implemented via different UI designs in one view vs. another view.
• If the UX for a particular interaction in one view is obvious, don't assume that in other views it's impossible to design and implement.
• However, not all interactions that are possible in one view need to be (or can be) available in all views. (It makes little sense to provide “one-time sort” functionality in list view.)

Design principles:

1. In each view, provide as many interactions as is reasonable, no more and no less. (Provide more and you clutter and complicate the UI; provide fewer and some or all of the views will be too capability-poor to be useful.)
2. Strive to have each view provide as complete a set of interactions with the data as possible.
3. To reconcile the tension between the above two design principles, remember that it's better to provide a capability and hide it away behind a non-obvious or non-trivial-to-discover UI than not to provide it at all. This way, it will be available for power users but will not trouble less experienced users. (Of course, this is not an excuse to hide capabilities behind non-obvious UIs when there's a good reason, and a good way, to provide an easily-discoverable UI for them.)
4. At the same time, look for ways to exploit the unique properties of each view to provide additional interactions that would impossible or nonsensical in other views.
5. The more ways the user can interact with the data, the better.

(3) Icon view allows arbitrary grouping and arrangement; I can position the files in the window wherever I like (example 1, example 2, example 3, example 4, example 5).

(Unless a “keep sorted by…” option is enabled.)

Some file managers don't have this feature; the Finder does. The lesson:

Do not carry over UX/interaction limitations necessitated by one view, to another view where they are not necessary.

Arbitrary grouping and arrangement makes little sense in list view. In icon view, there's no reason not to permit it—except, of course, that allowing the user to set, and then tracking, arbitrary icon positions, takes work! Does it offer a benefit? Find out! Ask users, survey other implementations, etc. In general, users resent limitations on their freedom, and appreciate the lack of them.

(4) What aspect(s) of the data may be easily gleaned via visual inspection differs from one view to another.

Different views (usually) look different. It's easy to forget this, but it's crucial. Here (in the “Finder list view vs. Finder icon view” example) this manifests in a couple of ways:

1. In list view, it's easier to pick out files which differ from the others in any displayed metadata value (modification date, file name, etc.). This is true not only due to the sort feature, but also because humans find it easy to scan down a list of text items (which are horizontally aligned) and notice ones which stand out.
2. In icon view, the "file icon" data channel is wider (because the icon is displayed at a larger size); more data is coming through this channel. This makes it easier to distinguish icons, but also allows this channel to be used for other purposes (see notes on Figures 5–9, below).

General lessons:

For humans, the visual channel is a high-bandwidth one. Use it. Some ways to optimize UI visual bandwidth:

• Multiplex meaning.
• Allow the repurposing of high-bandwidth components.
• Remove obstacles to visual apprehension of patterns (minimize "non-data ink", etc.).
• Assist the brain's pattern-recognition abilities by using alignment, contrast, repetition, and proximity cues.

---

The same folder as in Fig. 1 and Fig. 2, but now in column view (Fig. 3) and cover flow view (Fig. 4):

---

Example two: Microsoft Word document windows

Example three: structured data

1. A .csv file, displayed as plain text
2. The same .csv file, opened in Excel
3. An HTML file, containing the same data, plus markup such that the data will be displayed in tabular form, displayed as plain text
4. The same HTML file, rendered in a browser

---

(Analysis of examples two and three left as exercise for the reader.)

I’ve never seen this concept named, or concisely articulated, anywhere else. The idea itself is not original to me, of course.

---

Of any skill, or any domain where expertise of execution may be gained, there are three levels of mastery.

At the zeroth level, you break the rules, because you do not know the rules. Success is accidental; failure is likely; excellence, all but impossible.

At the first level, you know the rules, and follow them. You do well enough, though excellence is unlikely.

At the second level, you know, not just the rules, but the motivations behind them; you understand why the rules must be as they are. You follow the rules or break them, as the task demands; your actions are governed by deep principles. Success is near-effortless; excellence becomes possible, and even likely.

---

To achieve greater mastery, you cannot skip levels. At the zeroth level, you may look at one who has achieved the second level of mastery, and note that he routinely breaks the very rules he has instructed you to follow. Are there no rules, then? But there are; and they exist for good reasons. You will not achieve the second level of mastery before the first.

Likewise, the one who has achieved the second level of mastery says to him who has yet to achieve the first: “Do as I say, not as I do”. This is not hypocrisy. One who does not understand the three levels may think: “He is allowed to break the rules, as I am not, because of some privilege of rank”. But it is only that to think outside the box, you must know the shape of the box, its contours; if you cannot see the box, you will never escape it.

And once more: you cannot explore the space of possibilities, if you do not know its dimensions. The axes of that space are not the bars of a cage, but signposts; not seeing them, you are not infinitely free—but only doomed to wander forever in a Flatland of amorphous mediocrity.

There’s a small-ish cluster of serif fonts—all of recent design, not digitizations of classic typefaces, nor even designed for (professional) print¹—that people always have trouble fitting into one of the traditional categories of serif typefaces.

In appearance, it looks something like if Baskerville, a 225-year-old typeface that has been shown to shape our perception of truth, and Caecilia made a baby.

The Kindle Finally Gets Typography That Doesn’t Suck

These fonts are sort of like transitional serifs, but they’re also sort of like slab serifs, and sometimes they’re called “transitional serif but with features of a slab serif”² etc. etc.

… a crisp, modern serif typeface … avoids the stuffiness of historical text faces and doesn’t overreach when it comes to contemporary detailing … a balanced, low-contrast typeface with economic proportions…

Elena font description

Fonts in this category share these properties:

• fairly thick strokes in the normal weight
• low stroke weight variation
• serifs that are not sharply tapering nor thin and dainty, but thick (yet not geometric or square, as slab serifs)
• relatively open counters
• relatively large x-heights

… simply a contemporary body text font.

Tuna font description

Fonts in this category include:

• Charter
• Source Serif Pro
• Equity
• Chaparral Pro

… and quite a few more more—see the full list (that I’ve found so far) on my wiki (and feel free to suggest additions on the Talk page!).

Some samples:

The category does not seem to have any accepted name³—yet unquestionably this is a real cluster in font-space. This blog post is meant to call attention to the cluster’s existence.

The characteristics listed above mean that fonts like this will render well across a variety of environments, software and hardware. And empirically, these fonts make for pleasing and readable body text on the web. So, at least for now (unless and until someone tells me that there’s already an accepted name), I’m calling these fonts “screen serif” fonts.

If you want your pages to be readable and attractive, try setting your body text in one of these fonts! (Again, check out my wiki for the full list—I’ll be adding more “screen serif” fonts to it as I come across them.)

SimTower was an elevator simulation game.

OK, it actually had other things in it, not just elevators. But the elevators were the heart of it—they were the most engaging part of the gameplay, with the most complex game mechanics—and, more than anything else, it was mastery of the elevator design that would bring a player success in SimTower.

I played SimTower a lot when I was younger. Read more...

Suppose that I, a college student, found a student organization—a chapter of Students Against a Democratic Society, perhaps. At the first meeting of SADS, we get to talking, and discover, to everyone’s delight, that all ten of us are fans of Star Trek.

This is a shared interest. Read more...

This is the second in a series of posts about lessons from my experiences in World of Warcraft. I’ve been talking about this stuff for a long time—in forum comments, in IRC conversations, etc.—and this series is my attempt to make it all a bit more legible. I’ve added footnotes to explain some of the jargon, but if anything remains incomprehensible, let me know in the comments.

Previous post in series: Goodhart’s law.

---

“How do we split the loot?”

That was one of the biggest challenges of raiding in World of Warcraft.Read more...

This is the first in a series of posts about lessons from my experiences in World of Warcraft. I’ve been talking about this stuff for a long time—in forum comments, in IRC conversations, etc.—and this series is my attempt to make it all a bit more legible. I’ve added footnotes to explain some of the jargon, but if anything remains incomprehensible, let me know in the comments.

---

World of Warcraft, especially WoW raiding¹, is very much a game of numbers and details.

At first, in the very early days of WoW, people didn’t necessarily appreciate this very well, nor did they have any good way to use that fact even if they did appreciate it. (And—this bit is a tangent, but an interesting one—a lot of superstitions arose about how game mechanics worked, which abilities had which effects, what caused bosses² to do this or that, etc.—all the usual human responses to complex phenomena where discerning causation is hard.)

And, more importantly and on-topic, there was no really good way to sift the good players from the bad; nor to improve one’s own performance. Read more...

Five quick tips for perfect cheesecakes:

Room temperature ingredients

Cream cheese, sour cream, heavy cream, eggs, and so on—all of these should be allowed to come up to room temperature, before mixing them to make the cheesecake batter. Read more...

Why traps?

Traps often seem like they exist to do the following:

1. Force the players to say "we check for traps" (or convince/threaten their DM into accepting "we are constantly and always checking for traps!" as a valid "standard operating procedure").
2. Slow down the party's progress, due to constantly and always checking for traps. (This allows the DM to make more wandering monster checks, thus affording more opportunities to cackle with sadistic glee when the party is jumped by a … <rolls d20> … "no encounter".)
3. Punish players who don't do #1, by inflicting gruesome injury on their characters, and forcing the party cleric to spend valuable spell slots to heal them.
4. Force someone in the party (inevitably, the hapless rogue) to spend ranks on Disable Device (the other use of the skill—opening locks—is fully subsumed by the knock spell, rendering rogues useless, although of course they were already useless, right?).
5. Reduce the party's successful negotiation of the fearsome dungeon hazards known as traps—those intricate brainchildren of the dungeon creator's fiendish intellect—to simple, unadorned die rolls (Disable Device again). How good are you at rolling high numbers on a d20? Pretty good? Great, you can advance through the dungeon. Not so good? Sorry, you have to keep rolling until you roll a high number. But if you roll low enough, something terrible may happen to your character!

Some of the above is true, some of the time. Sometimes it's not. But it usually feels true. Why? Read more...

This post is about two things: public epistemology, and pie.

(Yes, there is a recipe for Key lime pie, down near the end of the post. You can skip to the recipe if that’s all you’re here for!) Read more...