Feature request based on Roam Research

[ABp]

As you guys know, I am finding the Fibery UX easier to navigate so far than Coda, and in fact Notion. I am getting a lot of success with the ease of creating relations. A good example of what causes me roadblocks in Coda is this feature:

[Feature Request] Relationship Column (alongside Lookup Column)

Hey @ABp and @GJ_Roelofs, it’s true that Coda doesn’t have editable bi-directional lookups yet, but we do have easy adding of bi-directional lookup columns without having to type formulas. Here’s a quick GIF of that in action: https://cl.ly/b2cdb21a43af/Screen%20Recording%202020-01-13%20at%2003.12%20PM.gif The column won’t add to table Lookup B automatically when you insert the lookup column in table Lookup A, but you can do it yourself with only two clicks.

@GJ_Roelofs we were both involved here. So when I use this, I was expecting simply for this to be a full bi-directional reference, that Ben is advertising can be done in “only two clicks.” Thing is, this solution is only one-directional, so not really “just two clicks” if you want the full reciprocal capabilities. With Fibery, as well as Notion in this case but with a bit more work, you set up the relation and it’s instantly visible in the receiving table. What’s more, Fibery has a notion of one-to-many vs. many-to-many. This is a little touch that allows much quicker creation of these relationships, something that requires more though to set up in Coda, and in a UI/UX arrangement that I can easily grasp. I cannot say the same about most of what I try to create in Coda.

I am really hoping we can get more of this user-friendly feature build in Coda. I don’t think it would in the least harm the underlying power, but could really make it more attainable for those “lesser” Makers such as myself. Sadly, I am getting ready to give up my efforts to build my “all-in-one” solution, for the time being, in Coda. I hope to be back though, as I’ve given up and returned several times in the last year!

Cheers guys.

[Bill_French]

@ABp

With Fibery, as well as Notion in this case but with a bit more work, you set up the relation and it’s instantly visible in the receiving table. What’s more, Fibery has a notion of one-to-many vs. many-to-many. This is a little touch that allows much quicker creation of these relationships

I agree - this is a very powerful feature and one that is critical for many applications and even some Airtable users have asked for this. Bi-directional linking is really important because complex relationships between information objects are best able to expose deep(er) knowledge and …

… what is Coda for if not for creating amplified capacity to convey knowledge, right?

The idea of bi-directional linking dates back to the early days of the HTTP protocol and some of the earliest discussions occurred at Xerox/PARC and of course, at W3 in 1990.

@ABp

I don’t think it would in the least harm the underlying power

Do not be fooled into thinking this concept has near-zero impact on performance. Indeed, while the feature is simple to conceptualize, the architecture required to pull it off without lots of added JOINs (in a traditional RDBMS), is non-trivial UNLESS you have the underlying power of a graph database OR a way to mimic a graph database architecture the way Fibery has [likely] achieved with this underlying technology.

Vastly More JOINs

The challenge with implementing this feature is best described using a common Facebook occurrence; the popularity of likes accumulating into a super-node. Since an unpopular target record (or document) has very few inbound and reciprocal outbound links, traditional relational databases can handle this without serious performance issues. However, when you create enough links that elevate a record (or document) to a high degree of relative popularity, a deep set of JOINs must exist. Example -

If we had a social graph of :People who :LIKE musical artists, it’s very likely that some of those artists, perhaps many, are supernodes. If we were looking at (:Person)-[:LIKES]→(:Artist {name:'Britney Spears'}) , we could reasonably assume that a :Person likely has relatively few :LIKES relationships, perhaps less than 100, but that a popular :Artist like Britney Spears may have millions of :LIKES relationships pointing her way.

Implementing this in an RDBMS would be catastrophic and this actually happened at Facebook in 2009.

Ideally, Coda would simply give us the ability to utilize a graph database for applications that require bi-directional linking. Alternatively they could throttle such a feature with a limited number of popular bidirections (I think SQL typically feels a good deal of stress after about 6 to 10 JOINs).

Yes - bi-directional linking has huge benefits, but it comes at a price.

[ABp]

@Bill_French, it’s been truly an education reading your posts on this subject.

Quick question: How much load would something like simply showing a reciprocal link in a “destination” row place on Coda? I’m talking about the exact same functionality we have here in this tool the community uses, Discourse.

So specifically, I use the @mention across Coda and reference another entity - section, or row. In that destination entity, there is a part of its details view that shows a link back that “mentioning” row. Possibly with some additional context besides a raw “link” only, or a toggle to open a bit more detail as Roam does, and Discourse also does:

This is one simple thing I recall from Jira, and some other tools like Aha!, that I think would be huge for my use of Coda. Without the need to build out more complex relations among tables, such as the ability for many-to-many table relations.

Cheers!

[Bill_French]

@ABp

This is one simple thing I recall from Jira

Sure, and Jira tickets represent a very different set of relationships than the possibilities we can create with Coda. There is no concept of a super-node in Jira - even the most popular tickets are unlikely to generate more than a few dozen inbound links even in a large team. And, can we assume Jira doesn’t use something like Neo4J to provide this functionality given Jira provides a Neo4J Plugin?

@ABp

How much load would something like simply showing a reciprocal link in a “destination” row place on Coda?

Well, that’s the point of my comment - it depends on popularity (i.e., the number of inbound links that emerge over time to a relatively popular destination). And really, this question is not something I can begin to comment on with any degree of certainty because I have no clue how Coda is designed. Coda should fear giving me any insight under the covers because my rants would be far more lengthy.

If it’s just a few bi-directional links, it’s pretty simple to track and manage these relationships even in a NoSQL database. But, imagine a corporate client where thousands of workers create their own copies of a Coda document that each link to a single source of data (or content) in another Coda document (which also links back) - a super-node has now emerged and one artefact in a Coda document must sustain thousands of outward links to separate documents. Aside from the data model (in an RDBMS) to support this possibility, any single viewing of the popular artefact must isolate your own link, and possibly (depending on permissions) many of the thousands of other outbound links because – well – that’s bi-direction linking’s objective, right?

My observation is simple; at scale, there’s probably a non-trivial cost for doing stuff like this and I’m sure there are some clever ways to implement it without supporting it at scale.

I see a lot of people in this community upset about performance. If you want more of that, implement this capability as a quick hack. Just sayin’ …

[GJ_Roelofs]

@Bill_French

I think I failed to make myself clear in the context of the comment you are referring. Let’s revisit the origin of my comment -

I should’ve have elaborated - My understanding was, and is, that @ABp and you were talking about two different functionalities.

From the following quotes:

@ABp

Mind map plug aside, I also wanted to say that Roam is warming me up to the potential of “blocks” of text in Coda that could be “promoted.” By promoted, I mean converted from text into more database-type records with more depth, such as status, due date, assignee, etc.

@ABp

Then, the idea is you could possibly “convert” them, via right click menu or ellipses, to a row in a table. All the while leaving this block where it is in its “home” in the canvas or Rich Text description or Comment. And creating a reference to the destination row.

@ABp

As you may know, you can easily manipulate text in Confluence into Jira issues

@ABp is outlining the workflow of quickly manually converting selected text into data, as shown here:

From your reply:

@Bill_French

This is already possible and I’ve done some of this in varying engagements. It’s not easy, and it’s non-trivial for the reasons I mentioned in my question to @shishir during the recent webinar .

And follow up, the request seemed to be re-interpreted as more broad - including programmatic access and ways to ease the lexification or parse results of text.

My reply tried to bring the discussion to @ABp initial request - the workflow for manual promotion of text to type (rows in specific tables).

I think the functionality I outlined above could be introduced without too much hassle, and immensely useful if we allow the user to also state to which column the selected text should be parsed and whether the link created should be an inline view of the data (E.g. a formula =@<selected_text_row>.<selected_column> or an @ link to the relevant row.

Combined with the functionality in the thread on editable data for formula’s this could be a very nice workflow.

[Bill_French]

@GJ_Roelofs

And follow up, the request seemed to be re-interpreted as more broad - including programmatic access and ways to ease the lexification or parse results of text.

Yes. This is absolutely the case. I am guilty of munging topics and perhaps especially in the new feature request category.

Often I will attempt to take a given feature request to a little higher - perhaps more abstract level - to suggest that by resolving missing architectural (or API) aspect (x), we will see requested features (y) and (z) and (n…) become much more attainable.

A good example - there are currently 29 feature requests in Airtable from as far back as 2016 and every one of them is gated by the lack of a Split() function. Every time a new feature is requested that would not exist if they would simply implement Split(), I go nuts and pound the community for failing to recognize that the feature they seek is not what Airtable designers should build.

In this community, we fly a little higher (technically-speaking), but I occasionally see opportunities to help Coda avoid featuring a product to death when there are alternative approaches that help us help ourselves while not overburdening the team or the product. I need to preface these comments and point them at Codans.

[GJ_Roelofs]

Honestly, I understand your point of view. The disparity between regular tabled data and the non-regular Section text is maddening at times.

I dream of the time where just everything can be an entity with designed structure and easily manipulable.

Imagine! Even the more-than-one-layer-folders request would be moot - I could just generate a graph based on my context and the attributes of sections, and use that as sidebar navigation.

However being a lead I often have to find a balance between the abstract and the practical - and not lose myself in the workload implications of the abstract and kneejerk reject a feature request before seeing its direct cost and impact. He said with pain in his functional programming heart.

[Bill_French]

@GJ_Roelofs

I dream of the time where just everything can be an entity with designed structure and easily manipulable.

I believe this is actually the case (under Coda’s covers). It’s simply not surfaced in a way we can manipulate the entities.

[tomavatars]

This indeed would be a very nice workflow

[ABp]

@tomavatars, @Bill_French, @GJ_Roelofs - just want to add guys that I really get excited seeing you experts in here discussing the viability of all this, which I hope will lead to a practical implementation that will allow those lesser-technical types like myself to do just what you @GJ_Roelofs are talking about - highlight text, manually, and then add it to a row of choice. Essentially what you can do adding something from Confluence to Jira, but in a much smoother, more thought-out, faster - simply superior! - experience.

Cheers!

[tomerikosan]

Roam focus on Outliner Style (which mean every data stored in bullet points), I have tried Roam in the past and then moved to Obsidian.md
I think the what makes Obsidian even more powerful this is the huge community that release many features to the software. one of the most powerful features is Dataview plugin which makes which simple SQL style language to generate dynamic (live) tables of any kind of data you need.
I think this & the bio-directional linking (+Graph View ofcurse ) with the combination of Coda as we know it today could be the most powerful productivity application in the market.