wabi-sabi
The most incidental detail
Bells
Most Japanese bells when hung still have on them one or more rough lines obviously arising in horizontal mold joints. These lines are not removed in fettling the bell, and they seem to be regarded not as defects but rather as a reminder of the reality of the founder’s interaction with his materials. One is reminded of the ceramics that are most treasured in Japan which usually have some unexpected tool marks or irregularity resulting from a kiln mishap.
Roughness
Roughness is the odd shape, the quick brush stroke, the irregular column size or spacing, the change in pattern at the corner – it is adjusting to conditions as they present themselves with meaning, but without ego or contrived deliberation.
Though it may look superficially flawed, especially with human perception accustomed to mass-produced regularity and perfection as a goal, an object with roughness is often more precise because it comes about from paying attention to what matters most, and letting go of what matters less.
Wabi-sabi
Sabi is an aesthetic term, rooted in a given concern. It is concerned with chronology, with time and its effects, with product.
Wabi is a more philosophical concept, a quality not attached merely to a given object. It is concerned with manner, with process, with direction.
Optical Glass House
A Building by Hiroshi NakamuraA façade of some 6,000 pure-glass blocks (50mm x 235mm x 50mm) was employed. The pure-glass blocks, with their large mass-per-unit area, effectively shut out sound and enable the creation of an open, clearly articulated garden that admits the city scenery. To realize such a façade, glass casting was employed to produce glass of extremely high transparency from borosilicate, the raw material for optical glass. The casting process was exceedingly difficult, for it required both slow cooling to remove residual stress from within the glass, and high dimensional accuracy. Even then, however, the glass retained micro-level surface asperities, but we actively welcomed this effect, for it would produce unexpected optical illusions in the interior space.
How the light gets in
A Quote by Leonard CohenThere is a crack in everything.
That's how the light gets in.Is perfection boring?
An Article by Ralph AmmerWe love to see the process, not just the result. The imperfections in your work can be beautiful if they show your struggle for perfection, not a lack of care.
The Fidelity Curve
How do we choose which level of fidelity is appropriate for a project?
I think about it like this: The purpose of making sketches and mockups before coding is to gain confidence in what we plan to do. I’m trying to remove risk from the decision to build something by somehow “previewing” it in a cheaper form. There’s a trade-off here. The higher the fidelity of the mockup, the more confidence it gives me. But the longer it takes to create that mockup, the more time I’ve wasted on an intermediate step before building the real thing.
I like to look at that trade-off economically. Each method reduces risk by letting me preview the outcome at lower fidelity, at the cost of time spent on it. The cost/benefit of each type of mockup is going to vary depending on the fidelity of the simulation and the work involved in building the real thing.
Four levels of fidelity
Suppose we have four levels of fidelity…
- Rough sketch (on paper or an iPad)
- Static mock-up (eg. Photoshop or Sketch)
- Interactive mock-up (eg. Framer, InVision)
- Working code prototype (HTML/CSS, iOS views)
Depending on the feature you’re working on, these levels of fidelity take different amounts of time to create. If you plot them in terms of time to build versus confidence gained, you could imagine something like a per-feature fidelity curve.
Time to build versus confidence gained
Take a simple CRUD web UI, where you’re just navigating between screens. It doesn’t take much more time to build the real version than it does to mock it when the design is simple. If you were to build out an interactive mock first, you would end up spending twice as much time in total without gaining much out of it.
Contrast that with a complicated Javascript interaction. Or a native iOS feature that requires programmer time to build out. If it takes substantially more time to build the real code version, then it may be smart to do an interactive mockup first.