This channel documents my project Goby, an interface for organizing information and visualizing it in tables and graphs. Here is a primer.
Goby was originally a web app that enriched Are.na channels with metadata. But it’s now expanding to a project about structuring and representing data stored anywhere you want according to logical patterns.
I was recently prompted to explain the theoretical drive behind Goby, and I think it led to a better articulation than ones which I have been able to give in the past:
There’s a professor at Parsons who teaches courses on a wide range of subjects, but claims that all of them are about the same thing, something he calls “the art of grammar”. Anyone who has taken one of his courses has heard him articulate the pedagogy behind this term: his are “art” rather than “subject” courses because rather than teaching you new facts within a particular domain, they train a general mental faculty, which can then be applied to many subjects. “Grammar” is the faculty he teaches, and by this he means not English grammar, but Grammar writ large, or “the ability to analyze something in terms of its parts and their relations”. Students in his courses are tasked with reading a philosophical text, and re-presenting its content in a way that makes its internal structure explicit. Each class session consists of discussing a text while he “maps it out” on a whiteboard: writing down terms, defining them, and articulating their relations to one another. It’s significant that this “map” of a text is nonlinear, and he often discourages students from looking to the order of the text itself as a signifier of the structure of its content.
I’m driven by the question of how to formalize this kind of abstract thinking in an interface, i.e. thinking of something in terms of its parts and their interrelations. It’s a kind of thinking which is so pervasive that to formalize it feels to me like attempting to draw an outline around the shape of thought itself, as lofty as that may rightfully sound. But aside from that theoretical fascination, I think embedding this kind of thinking in an interface has pedagogical value. The other way my professor has described his approach is as “teaching students how to read”. Connecting to Andy Matuschak and Michael Nielsen’s work on timeful texts and doing-centric learning, his idea is that in order to really engage with a work (and particularly a work of philosophy), you have to bring the concepts to life by articulating and applying them on your own. As Matuschak and Nielsen remark in Timeful Texts, it’s hard for someone without training to go beyond the linear reading process and engage closely with a text in this way. So what if an interface ambiently prompted you to represent something in terms of its conceptual structure? If this interface was integrated in your everyday activity (if it was a “medium” of thought), it might train you to interpret new information differently — it could teach you the art of grammar.
Goby is my first attempt to formalize the art of grammar. In it, you organize things into different “classes”, which each have a set of properties — e.g., an “author” class might have properties for first name, last name, and books authored. Some of these properties (like books authored) are relational: i.e., they relate one entity to other entities of the same or different classes. Thus in my previous example, you would also create a class for “books”, one property of which would be “author”. These properties then define a possible two-way link between the entities in these classes.
Now, what I’ve just described (and what you’ll clearly see looking at Goby) is a relational database architecture, structurally similar to something like Airtable or Notion. But by centering a tabular representation of data, and providing reduced “single/multiple select” fields, I think Notion and Airtable obscure the very conceptual order that I want to make explicit. So whenever you want to select from a set of items, Goby forces you to make or pick a class that represents the kind of item being selected. And borrowing from “Zettelkasten” inspired apps like Roam, I introduced a spatial view which represents your data as a node-network graph; by seeing the same information in multiple formats, my hope is you decouple your conceptual understanding from any particular visual representation.
With the table nav bar, I'm wondering how I'm going to do intersection observer detection in two dimensions / account for the fact that multiple tables are visible at once. Potentially it will be limited to letting you auto-scroll to a table, without actually indicating what table you're currently viewing.
Rather than having URLs be stored directly as strings, I’m thinking it might make more sense to put them all in a single storage table which other classes “point” to using an ID, so there’s no redundancy. Would be architecturally pretty difficult to implement though.
Maybe as you move your mouse over areas of the grid where nothing is filled in, the square you're hovering over can be filled in with grey, to indicate that you do something there if you so choose.