This is a continuation of a post I made, and I figured I’d create a new post to separate it from that support thread:
I wanted to riff on this a little more and then I’ll go to bed. A use case related to this idea of interoperability with outlining software is: Sometimes I start with fairly structured notes on a topic. It might be outlining a book I’m reading or taking lecture notes. I would love a way to maintain and encode this structure somehow in Kinopio. Because then, a next step is to start moving these elements around to make connections, understand relationships, etc.
I keep coming back to figuring out how to bring a little more structure into Kinopio because I feel like that’s a pretty powerful thing that can make it all the more useful. (Another feature request on this theme is card grouping). Not wanting Kinopio to become like something it’s not, but nudging it in that direction so it can more be a tool in a larger ecosystem.
I started playing around a little bit with representing an outline in Kinopio. I think you can capture everything with connections, to denote hierarchy, and then outline numbering as part of the card (I, II, A, B, etc), although you could also use positioning for that. You’re welcome to comment on this experimental space: https://kinopio.club/sample-outline-1uMf2AIRWHpXQ-tMG0SVh
Another thought, be able to import and export a Markdown-formatted outline. That’s another reasonable format for outlines (logseq uses markdown for storage).
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.
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.
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):
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.
- 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.
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
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?
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, Kudos is level 1, and We 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