You could restrict what you export to cards with a specific connection type and ignore others. In my space, all of those connections are the same type and labeled “outline”.
Importing wouldn’t be a problem since you can represent a tree.
1 Like
I’ll look into this, but it’s p niche and has a lot of edge cases and requires a lot of ui to make the export match your expectations (it’s a round peg in a square hole) so consider it longer-term
1 Like
to bulid this I’ll have no more information on a space than what you can get through the api , so if you’ve got specific ideas maybe the self-serve route would be a helpful starting point
1 Like
Personally, exporting doesn’t matter to me, especially corn the complications.
Importing would be cool and probably easier to map out and bring into Kinopio.
Again personally (and I understand it’s niche), I’d love just being able to create a little bit more structure from the keyboard for fast notes with indents and outdents and connections.
1 Like
is your preferred input format opml or raw text formatted in a standard way?
the other complication is that connections have a direction that’s not programmatically obvious. each connection has a start and end card, but sometimes ppl may or may not drag from the child to the parent - technically blurring the line between parent and child.
not having to be cognizant of parent and child is a feature of the UI, but presents a (not insurmountable) complication for export.
1 Like
I don’t see this as a huge problem. If someone is intending on creating/editing an outline within Kinopio for export purposes, they will have to and be motivated to follow the requirement that connections must go from ascendent to descendent.
In terms of programming, as long as we use a single connection type for denoting outline hierarchy, and go from ascendent to descendent, then it should be unambiguous what the outline should be.
ascendant = parent has higher card.y position?
why does a single type matter? couldn’t we ignore types when making the tree?
No, maybe better terms to use are predecessor and successor, to pull from graph terminology. If you look at cards as edges and connections as vertices, then an outline is a directed acyclic graph.
A single type is useful to distinguish which connections denote outline hierarchy from other uses of connections. So you in a space, you could use connections wherever you want, but when you want to create an outline, you use a specific/conventional connection type (so it is programmatically understandable).
The other approach is to ignore types, but then you would have to assume all connections are for outline hierarchy and you can’t use them for any other uses like this (the comment card and connection):
so then predecessor = higher card.y position?
1 Like
that’s true, but I wonder if type specificity is worth the complexity of explaining to people that these two are different and will produce different export results:
1 Like
My thinking was that a space would generally contain a single outline. In your example, there are two separate outlines. I feel like supporting more than one outline would be fraught with edge cases an ambiguous behaviors.
The reason I was proposing using a specific connection type is that it’s the only way I could think with current mechanisms to allow using connections for non-outline purposes. How else can we distinguish what cards and connections should be exported as an outline? I don’t think we want to assume every card and connection is an outline.
Here’s another actual use case that I had for multi-level Markdown list export (a kind of outline). I was writing up a summary from my retrospective and wanted to paste this as a Markdown message in Webex chat to my manager.
Here’s what I wanted to export:
## Summary
- Kudos
- We made code complete! (go team)
- Amazing demos at FMC meeting (esp Nick)
- CDO acceleration demo well received
- Automation keeps getting better (Sam)
- Using Fusion in CDO is working well (Erik)
- What didn't go well
- Cloud FMC has issues
- Create bugs for known issues
- To do
- Need to write stories for automation improvement (to decrease time on regression testing)
I ended up exporting the text, and then using another editor (Bear) to make the outline.
1 Like
so in this case, diff connection types are all treated the same?
1 Like
Yes, although this was not meant to be a precise example of how this would work 
This is a different use case where I do have an outline within a larger space, and I want to export it as such upon selection. In this case, I guess you can use the connections, regardless of type, to understand hierarchy. And then assume cards without predecessors are the top level.
Hope that clears things up rather than the opposite
1 Like
I have long been thinking/dreaming about writing an API integration that will flexibly read a space’s cards JSON and format/order it into whatever hierarchy you want.
I was thinking of a declarative system where you can say:
Level 1 = All cards where Heading Level = H1, Order by x
Level 2 = Connected Cards of Level 1, Order by y
But potentially with multiple then by orderings on each level…
This is tricky. I also think it’s way too deep to go into Kinopio proper, some of these things are best as integrations.
The problem with this screenshot is how you order your headings (“Kudos”, “What didn’t go well”), because given raw data of the cards, how do you tell by x/y/connectedness which ones are headings and which ones are children?
2 Likes
- All cards without predecessors (parents) are level 1. Their order is top-to-bottom (x value, increasing) like you would read it.
- Level 2 are cards with a single predecessor. The connection must go from higher level to lower level. (I’m using “predecessor” to indicate directionality of connection). In this screenshot,
Kudosis level 1, andWe made code complete!is level 2, etc.
I think that’s it. As far as I can tell, it’s unambiguous given those rules.
But I think it might be worth being more strict/prescriptive because that allows you to use connections for things other than denoting outlining hierarchy, as I noted earlier in this thread. Hence this example where I have a root node. In this case, all level 1 cards have 1 predecessor (root), and level 2 cards have 2, etc.
Apropos of https://twitter.com/Conaw/status/1472034213214007298, my long time dream is to have the UI/UX of Kinopio along with the structure/query-ibility of a tool like Roam. This is largely my motivation for starting this thread, to see ways this can be realized 
Also, going back to what @kordumb’s use case more seems to be, I think it would be very useful to have a quick way to create outlines within Kinopio proper. If that were in place, and someone wrote an OPML export, that would be super powerful
2 Likes
Scripting News: Saturday, January 8, 2022 Dave Winer is working on interop between his software and LogSeq using OPML.
2 Likes
opml docs:
includes examples, but no outliner specific ones
if you have examples of opml exports from outliners you use, please include them below
1 Like