How Typescript Inspired Ilograph
Influence #1: At-Home Good (or, The Problem With “Easy”)
In REWORK, the founders of 37Signals (now called Basecamp) describe products that are “at-home good”. Such products, they say, are not merely easy to pick up and use; they go beyond “quick wins” and provide the kind of long-term benefits sought out by professionals.
Using this as inspiration, Ilograph’s primary goal is to be “at-home good”. It is geared towards pros and designed to scale. For example, it does not use drag-and-drop; instead, users define diagrams using code. Drag-and-drop is easy to learn, but it doesn’t scale as well as code (rearranging boxes and fiddling with arrows and font sizes gradually becomes a nightmare).
Other features, like multi-perspective diagrams and resource inheritance allow advanced users to express things that simpler drag-and-drop tools do not. This is one of Ilograph’s “big bets”; it caters to a smaller pool of advanced users, but it is better tailored to their needs.
Influence #2: Starting with a Model
Together, all of the explicitly-declared types in a Typescript program form a model. This model is the foundation of the codebase; the functional code depends on this model, but not vice-versa.
Using this as inspiration, Ilograph diagrams also start with a model1. Users declare what resources are before declaring how they are related (in Relational perspectives) and their behaviors (in Sequence perspectives). Like in Typescript, users give resources both a name and a type (in the form of a subtitle and/or icon) since both are important. This explicitness not only improves developer and viewer understanding, but also improves developer tooling.
Influence #3: The Developer Experience
For the same reasons, Ilograph has an integrated editor with auto-complete that leverages the diagram model. More critically, Ilograph diagrams are laid out automatically, freeing the designer from having to manually place elements, arrows and so on.
In all of these cases, the cognitive load on the developer/designer is reduced. Whether programming or diagramming, the more the computer helps with the small things (syntax errors, diagram layout), the more the user can focus on the high-level goals they are trying to achieve.
Influence #4: Built-To-Change and Built-To-Last, a Paradox
Ilograph currently has about 15,000 lines of Typescript code. I’d estimate that at least that many lines of code have been deleted or rewritten over its lifespan (4 years). Almost everything about the original app, including its appearance, editing experience, and even nomenclature are drastically different today.
That may sound like waste, but it’s actually a sign of a healthy app that is adapting to feedback and shifting priorities. The world changes, after all, and we must change along with it.
I can say with 100% confidence that Ilograph would not exist without Typescript; it has made making so many changes possible. Without these changes, Ilograph would have been abandoned long ago. That is the paradox: things that are built-to-change last. Things that aren’t die out.
This might be the biggest influence Typescript has had on Ilograph. Like Typescript applications, Ilograph diagrams are easy to change. Making diagrams easy to change means that they are more likely to be kept up-to-date and relevant, and are more likely to provide long-term value.
Comments or thoughts? Please reach out to me @Ilographs on Twitter or by email at firstname.lastname@example.org.