Many systems are organized hierarchically. The CERNDOC documentation system is an example, as is the Unix file system, and the VMS/HELP system. A tree has the practical advantage of giving every node a unique name. However, it does not allow the system to model the real world. For example, in a hierarchical HELP system such as VMS/HELP, one often gets to a lead on a tree such as:
HELP COMPILER SOURCE_FORMAT PRAGMAS DEFAULTS
only to find a reference to another leaf: Please see
HELP COMPILER COMMAND OPTIONS DEFAULTS PRAGMAS
and it is necessary to leave the system and re-enter it. What was needed was a link from one node to another, because in this case the information was not naturally organized into a tree.
This, I think, is the brilliance of Notion, and what makes it one of the best examples of “fidelity to digital information” that I’ve come across. The structure of the app reflects the structure of the web itself: digital content is purposefully formatted, like semantic HTML elements, and exists in a hierarchical structure (directories on the web, nested pages in Notion), yet can be linked and referenced to create a complex network of information. And pages in Notion reveal the structure of the information: when nesting a page within a page, the child page always displays on the parent page. There’s no way to create a child page that doesn’t display on a parent page, no way to obscure the structure of the information. The semantic structure of Notion reflects the semantic structure of the web itself.
Truchet's approach was more topological than geometric, and the qualitative aspects of pattern take priority over the metric ones. His principles provide a kind of metaphor for the hierarchy of separation and connection in all things.
Craftsmanship is about thoughtfulness and care in the work we do. It means being deliberate about what we build and how possible it will be to maintain and extend in the future. A solution that will require revisiting in a month — because it’s not scaling, because it has a ton of bugs, because it doesn’t support all the use cases it needs to — is not useful to us and ultimately will generate pain for our users.
What we trade off by living this value is (sometimes) day-to-day speed. It’s easy to imagine an engineering team that emphasizes moving fast over keeping things stable and bug-free -- like a team building a product that isn’t responsible for important user data and doesn’t support anyone’s livelihood. But given the role the Figma product plays in the lives of our users, we feel it’s worth it to ensure we hold a high quality bar for them. And in the long run, being thoughtful about how we build often reduces the complexity of ongoing development and new features regardless.