Outlining, mind mapping, OPML, interop and more

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.

But, I still want a way to get back at the original structure. A few of us had brainstormed in Discord about this when I brought up this idea of layers (https://discord.com/channels/857305113936134204/857724442797146173/915416811116310538). That was one idea.

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.

2 Likes

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).

1 Like

the big diff between a traditional outliner and kinopio is that outliners only have a single tree. in a kinopio document nodes can have several parents (many:many). How would you reconcile this?

1 Like

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):

image

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:

Screen Shot 2021-12-16 at 10.22.40 AM Screen Shot 2021-12-16 at 10.22.30 AM

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 :slight_smile:

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 :slight_smile:

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, 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 :slight_smile:

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 :slight_smile:

2 Likes