Codecraft
software = science + art + people
Progressive Disclosure Everywhere
2012-09-16
If you google “progressive disclosure,” you’ll get hits that describe the phrase as an interaction design technique. UI folks have long recognized that it’s better to show a simple set of options, and allow users to drill into greater detail only when they need it. (Thanks to James Russell — a brilliant UI designer — for teaching me PD years ago.)
But calling progressive disclosure a “technique” is, I think, a serious understatement. Progressive disclosure aligns with a profound cognitive principle, and its use is (and should be) pervasive, if you have eyes to see.
The Principle
Here’s my best attempt to distill the operative rule behind progressive disclosure:
Focus on essence. Elaborate on demand.
In other words, begin by addressing fundamentals without cluttering detail. When more detail is needed, find the next appropriate state, and move there. Repeat as appropriate.
Stated that way, perhaps you’ll see the pattern of progressive disclosure in lots of unexpected places. I’ve listed a few that occur to me…
Manifestations
The scientific method is an iterative process in which hypotheses gradually align to increasingly detailed observation. We learn by progressive disclosure.
Good conversationalists don’t gush forever on a topic. They throw out an observation or a tidbit, and wait to see if others are interested. If yes, they offer more info.
The development of a complex organism from a one-celled zygote, through differentiation and all subsequent phases, into adulthood, could be considered a progressive disclosure of the patterns embedded in its DNA. The recursive incorporation of the golden mean in many morphologies is another tie to biology.
In journalism, the inverted pyramid approach to storytelling is a form of progressive disclosure. So are headlines.
Depending on how you’re reading this post, you might see a “Read more…” link that I’ve inserted right after this paragraph. Making below-the-fold reading optional is progressive disclosure at work. TLDR…
Agile software development is a form of progressive disclosure. You start out with vague requirements, and turn your clarifying attention to a small subset, one sprint/iteration at a time. Contrast waterfall, where all requirements must be spelled out in great detail, in advance.
Derivatives and integrals in calculus (not to mention fractals, and lots of other mathematical concepts) capture the result of a limit-as-x-approaches-zero function.
Markedness in language reveals a linguistic community’s preference for what can be assumed or omitted, and what must be explicitly stated. To override the default semantic payload, extra negotiation and effort (the “mark”) is required.
Task-based documentation is motivated by the insight that people rarely want to know everything they possibly could about a given topic — they’re happier just knowing enough to get their job done, and finding information aligned with their current focus.
In many religious traditions, the idea of reaching higher and higher levels of enlightenment over time is important. A common observation in such world views is that simple beginnings form the foundation for later growth. C.S. Lewis explored this spiritual odyssey in The Great Divorce; he returned to it in The Last Battle with the metaphor of a stable bigger on the inside than the outside, and repeated invitations to “come further up, further in.”
In software ecosystems, the increasingly popular philosophy of convention over configuration allows uninteresting details to be deferred and often ignored entirely.
Most education gives high-level summaries in introductory courses, saving complex details for a follow-on.
In gaming, the pervasive notion of “levels” allows the creators to disclose experience a little at a time.
In programming languages, constructs such as default parameters, interfaces, abstract base classes, abstract factories, templates, and mixins all help to minimize the level of detail that must be mastered to work effectively in unfamiliar contexts.
In western culture, traditions of healthy dating and courtship involve a progression of increasing intimacy in which each party gradually comes to know the other more and more deeply, in a variety of settings.
In sports, a champion is often derived through a tournament, in which the best competitors become obvious through repeated elimination rounds.
In music theory, a theme is typically articulated in the opening bars of a composition, and then elaborated and embellished as the piece develops.
Treeviews and fish-eye lenses in software UI are forms of progressive disclosure.
In Great By Choice, Jim Collins’ notion of firing bullets, then cannonballs is an attempt to describe how successful companies commit resources incrementally.
In children’s literature, the idea of a reiterated and expanded problem or solution crops up repeatedly. Think of Kipling’s The Elephant’s Child, Hansel and Gretel, Goldilocks and the three bears, Sheherazade…
The Moral
What should we learn from this principle’s pervasiveness?
I believe one important lesson is that we ignore this principle at our peril. Humans need gradually expanded focus, not sudden overload. Flout progressive disclosure in a conversation, and people will think you’re a bore or a know-it-all. Use cheats to get to level 99 in an MMORPG, and you’ll miss the experience that makes the game rich. Skip courtship in favor of one-night stands, and you get existential angst.
Applied to software, I think we need to be much, much more aware of when we’re disclosing too much too soon. There’s a reason why encapsulation is one of the foundational ideas in OO theory, and why tight coupling is a major problem for living softwarcosystems.
I have some ideas about how progressive disclosure might manifest more cleanly in programming languages, and in the software craft in general. I explored one in my series of posts on role-play centered design. I’ll disclose some more ideas … progressively … in other posts. :-)
Action Item
Analyze a piece of code with progressive disclosure lenses. What do you (what does the compiler) have to know about this code to interact with it successfully? For example, does a C++ header #include a bunch of other headers when it could use a forward declaration instead? Could you use the pimpl idiom to decrease what's exposed? Is there a class that should be used through an interface? Do the comments and names disclose the right amount of detail in the right places?