• ‘Front-end’ problems aren’t always about how something looks or is represented — usually what I want from the distinction is to separate those aspects of the project which I do or don’t want users to pay attention to. This sort of separation is particularly relevant in an application like Goby, where a user is prompted to design a system that can be visually presented in more than one way. The tools for designing that system include structural affordances as well as an actual visual interface — I consider the former equally front-end-related because it's about what power Goby gives to a user.

• In addressing any ‘front-end’ problem I’m not only thinking about these things, but also how it’ll scale, what repercussions it’ll have on the rest of the design system, and of course how it can or can’t be achieved in code.

• In addressing any ‘back-end’ problem I’m also thinking about what limitations will be imposed by my solution on the (broadly-defined) ‘front-end’.

• visual: It’s possible for two nodes to be related to each other in more than one way. This creates an issue in space view: at the moment it just draws a straight line between any two items that are related, meaning there’s no way of distinguishing between two separate relations connecting the same two nodes. My best idea for how to account for this right now is to have the relation lines be curved in the case that there’s more than one, as in this website which I believe also uses D3-force.

• functional: It’s possible to create a property to reference other objects in the same class/table. It’s also possible to create a property that references objects from multiple classes/tables. Relations in Goby are stored as junction tables in SQLite, and the two relation features I detailed just now are a little unorthodox and complicated to account for in this system. I still think junction tables are by far the best way of doing it, but all the same the logic gets very complicated and I haven't gotten clear about it in my head yet.

One discovery when I started the live D3 version of the space view was that having arrows (example from an early prototype) ended up looking cluttery/claustrophobic, particularly with nodes that had many many inbound relationships from other nodes.

Ultimately I’d like arrows to be something you can turn on and off, because there are some use cases where I feel they’re less annoying. But I wonder if there’s any other minimal way of indicating directionality. To that end, one idea I just had was to have a relation line touch the node on the sending end, but stop short of the node on the receiving end.

In regards to the right ----->

When presenting Goby to guest critics a couple weeks ago, one of their suggestions was to move beyond the generic typeface collection example, and really stress-test the system with example projects that are more idiosyncratic and hold personal meaning. I had a little time this week to add the resource entry/preview interface this week, and it created the impetus to do this.

Here Goby is being used to represent a book that I made last fall in my thesis course. That book helped me explore some of the themes — levels of abstraction, structurally representing information, world-building — that have driven me in Goby’s development over the past year / going forward. It also has an unconventional structure: I wrote four separate “strands” of text, each addressing a different theme, which are threaded nonlinearly across a collection of 50 found images (think Cortázar’s Hopscotch x 4). So it’s perfect as a “stress-test” in this way, because it allows me to think about how best to produce that structure from Goby’s underlying data architecture (already noticing some significant things I'd like to add/change to make Goby more flexible). It’s also nice as a sort of recursive gesture, applying Goby’s system to the collection that inspired it.