"bidirectionality" is our shortcut word for describing two way relationships between two types. For example, if you have a Company type and a Person type, then you often want to create/read/update/delete a relationship between the two. Our current solution is to put a Pointer on one and a Search on the other. This is a little tough to learn, but it basically works in terms of viewing the related cards. But the relationship is really only easy to update via the pointer side. To achieve real bidirectionality, it needs to be equally easy to edit in both directions (and ideally we'll find ways to make the whole thing easier to set up).
One approach would be to retain our current Pointer-Search data pattern but to make it easier to have pointer-like interfaces on the search side.
For example,, let's say we've got a simple system where:
What we want here is a simple way to express that:
Here are some possible ideas about how we could do that:
Another approach would be to use a Type1+Type2 pattern based solution. The existance of cards in one of thse patterns would be a bi-directional link between them (it's sort-of like having a join table. a particular set of this pattern representing the whole table, and each card instance like a join record). You can add either direction with equal ease.
whoops, this is a duplicate. Let's import the best stuff from the old idea here (closing the other one):
1-3 are explorations of the "one approach" (see top of solution). 4 is a different approach, no?
Yeah, it is more like creating a join record in ORM. I think it might make sense when we actually are using the *type_plus_type pattern as in wiki-rate extensions. So, I guess it really needs a second thing at the top level.
But it does illustrate the concept of linking via namespace (+). It isn't how we typically use the + relationship.
Thanks for putting forward the "another solution" (type+type). Definitely worth digging into. It's come up a few times, and I've always been uneasy about it, but it's worth deeper exploration. I'm guessing you're in the same boat (not advocating yet but wanting to explore?)
To me, it has several issues that would need working out. The first is the nature of relationships.
Let's say we have three companies: Holding Co, Producer Co, and Retailer Co. What does the existence of Producer Co+Retailer Co actually tell us? (In the Pointer-Search, the pointer name is meaningful, and in fact we could put +subsidiary, +client, +franchisee, _whatever else and represent multiple company-to-company relationships). We could put something in the content, but how would we distinguish between unidirectional and bidirectional links?
I should probably clarify that "bidirectionality" might be a confusing word here. In this use, it's not really about the nature of the relationship, but about the interface. Eg, we're not talking about distinguishing between A loves B, B loves A, both, and neither. We're talking here about whether you can *edit* the fact that A loves B from both A and B.
To my mind, the Pointer / Search pattern gives us pretty good coverage for representing of standard relationships. As you have pointed out, pointers are, by default, many to many. We need some good patterns for restricting that, but it's kind of an awesome starting place.
Do you agree that with pointers/ searches, most relationship patterns are easy to represent in data, even if difficult to update? Perhaps I should change the name of this ticket to "support bidirectional editing"?
In any case, unless we think we want to get rid of the pointer-search pattern, we will very likely want to be able to edit the relationship from the search side. I suppose the question whether that discussion should happen here or elsewhere depends on how much we think we want to invest in other relationship representations.
see also Relationship Card
OK, here's where I am. I think that we are at a place where we need either to (a) commit to the pointer-search framing and make it great, or (b) really articulate the need for a supplemental (or replacement?) system and exactly how it fits into the whole framework.
For pretty much the whole time we've been working on Decko I've been feeling iffy about deeply committing to the pointer-search idea, mostly because of limitations in our current configuration options but after these explorations, for the first time I'm starting to think we can really make it awesome. So I'm going to try to articulate the argument in favor here (in a form that might be moved into documentation at some point), but I would be very interested in hearing counterarguments. So...here goes.
I'm slowing down a bit on this and need to get to other work. Some quick points more relevant to our discussion:
I like the poly* discussion, dodgy, pretty funny. You have a bit of a sentence fragment at the end of the fourth bullet.
Something like making sets more composeable? That does sound interesting.
I think your point 4. is a matter of some shortcut buttons in the UI. Maybe you have an "association" widget, but it probably just uses the same WQL we would now.
So is it fair to say you're on board with going gangbusters on the pointer-search model, or do you think we need to give deeper attention to other options first?
Since is it closest to what we currently represent, I think it is really the only one viable in the short term. We'll have to see just how well it works. UX-wise, we should be able to support different data representations in the long run.
I think your short term challenge is to really evolve the client side to better support customization and extension. A lot of what you have on your hot-list for 1.0 will be largely in this part of the code. I think that our cards, sets, events, rules, names and all that are well developed and even refined so that with some magic on the client side it can do anything well.
I'm not that involved in the work, but our team is going towards using react and reflux on the front end. I think the reasons and results are good, and it could be a good fit for Decko.
My thinking was that we would try to support lots of UX options but focus on relatively few data representation patterns. If we do that, it makes it easier for the wagneer to switch between them. Not saying that we should make it impossible to use other patterns, but it's like rails - follow the conventions and it's all super easy. I think I'm finally coming around to thinking the pointer-search pattern that we, in some ways, stumbled into has some real strengths to it.
I'm thinking to close this and add another, narrower ticket to cover specifically bidirectional editing for the pointer/search pattern. Sound ok?