Far-fetched Idea: Database Widget + Properties

[kordumb]

So I had this thought that I started writing on my blog:

I think my dream software tool is something along the lines of Kinopio + Notion. Basically a database tool with the flexibility, ease, and delight of Kinopio. Notion is the most user-friendly tool, but is still pretty rigid.

This got me thinking. What if Kinopio could serve this need too! Warning: a bit of rambling and thinking out loud to come…

Basically, what if there could be a widget/card-type thingy that served to show a table of Spaces w/ their Dates (created and modified) and ~Properties~. You’d create a Table and be able to filter and sort by Date, Tags, and ~Properties~. If a Tag exists in a space, it would pull through to the table.

If you’re smart you caught on to my use of ~Properties~. I’m thinking of these as Tags on steroids, basically a tag with a second attribute. So maybe within ten of my spaces I include the Property “Type”, three may be {{Type: Journal}}, two may be {{Type: Work}}, and five may be {{Type: Wiki}}. So you could see all spaces with a “Type” property in it or drill down to the specific attributes.

I had more to say, but my iPad lost everything I already wrote, and had to retype it. So when I’m less frustrated I’ll come back…

What I think is neat, though, is the data entry is freeform, so it could be used however and wherever the use wants, but tags and properties allow you to slice and dice and get some high level structure above and around the wonderful messiness and chaos that comes within a space.

Things to expand on:

• example use case
• why it’s a fit for Kinopio
• how it could work in practice a la Tags
• how it could be used as semi-folder structure

[pirijan]

looking forward to hearing more

[stegriff]

I realise you may not have posted this blog yet, but what’s your url? I wanna check it out

[bentsai]

I’m also looking forward to hear what use cases you have in mind. At a high level, I totally vibe with this. I want Kinopio to be able to handle more of my digital life, and what we’ve both been proposing is how to add more structure.

Right now, the data in Kinopio is largely unstructured and freeform. Which is a feature in many ways. But if we might add structure and semantics, it makes this data queryable. And that makes it more suitable as a knowledge management system. (Hear me out, I know, I am rolling my eyes too).

Boxes are really interesting, and I appreciate how freeform they remain. In the data model, they are simply another type. From the data model point of view, boxes don’t contain boxes. They have dimensions, and you can calculate what cards are currently inside, but that meaning lives outside of Kinopio in a sense.

A different angle that I’m looking at things is from the data model and API perspective. What if Kinopio is the main frontend to my data, but I can query it in useful ways using the API? I think my WIP: Exploring my Kinopio data in Datasette experiment remains an under-explored proof-of-concept. Imagine being able to search for memories/notes globally across Kinopio, and then exploring that space spatially. What if changing modalities was seamless, and you could browse and sort your data in a structured way (my most recent cards, browse by images, e.g.), and then see those items in context?

Here’s a use case from work. I have a bunch of bits of information I want to remember: URL of the build server, developer certificate for app—basically, key-value pairs. I could encode this in kinopio as, box name = key, value = card inside the box. I could then arrange these boxes in a space in a memory palace. This way, I might go top down to find this information (navigate to the space, then walk my palace). Or I could do a query (find boxes with the text “certificate”, then find the card inside the box).

@kordumb I don’t mean to hijack this thread. I think your idea is just as great and powerful. And probably better because you’re proposing bringing this structure into the Kinopio UI, giving users access to it. And perhaps making some of this structure first class. That means it will get @pirijan’s UI/UX treatment too . I look forward to your follow up!

[bentsai]

@stegriff

I realise you may not have posted this blog yet, but what’s your url?

https://tiv.today/ I think

[kordumb]

Correct, tiv.today and I came here instead of writing anything on the blog since my rambling became more specific to Kinopio // @stegriff

[kordumb]

Your box to card relationship is exactly how I’d imagine properties working. And I know you’re not saying one way or the other, but to pitch you…. I think what I like about Properties over your Box/key→Card/value, is the lack of structure required to have and get the information.

For your scenario, you essentially have to set-up the box and card structure, in a sense, recreating the Notion properties form at the top of every Notion page.

For my Property idea, the goal is to be as simple as dropping a [[Tag]] in a card anywhere in the space. But instead of a single value in the [[Tag]], it has a second layer as {{Key: Value}}.

I’ll try to get back to this later today.

[kordumb]

very quick mock-up in excel of what I’m imagining the table card could look like.

One thing to point out based on Ben’s response is my focus here is for looking at things at the Space level. I don’t know that a table/database view like this would be very useful at the card level and could potentially be quite overwhelming.

[Sharknader]

But why stop at spaces, why not do the same with cards ?

[kordumb]

What’s the use case for cards that would be different than the Global Search topic?

[kordumb]

So Tags and Properties… let’s go a little deeper.

There are a few different approaches that can be taken, some could even be solved today with no changes to Kinopio and I’m not quite sold on the overall usefulness of Properties themselves in Kinopio (other than for myself and the usecases I’ll lay out next).

The goal I have with the Properties idea is to basically get Tags with a bit more of an advanced feature set, where they can contain a key/value relationship.

Today, you can basically achieve this by just using two tags:

[[Year]] [[2022]]

The idea here being I’d want a way to see all spaces with a Year, but also then be able to drill down by year.

In my imagined Property syntax, it’d be more like:

{{Year: 2022}}

Which again, essentially achieves the same thing, but, I think, becomes way more useful because there is a direct relationship with the Key and Value This would help eliminate some of the noise and give more filterable/sortable data, both within the existing dialog type boxes that exist today with tags, but also with the proposed database table feature.

For the database table, the potential feature set today would essentially be four columns: Space name, Modified date, Created date, and Tags. Tags, in this case, would essentially be a comma separated list of all the tags that exist in the space (I have ideas for how to visualize so it doesn’t become a monster ). And then you’d be able to filter by the Tags column to show only spaces with specific tags.

With Properties, though, you’d be able to add a column to these tables for every single Property Key (the specific Property columns in any given table would be determined by the user), and display the associating Values in the data rows, which would be filterable/sortable, obviously. While I think Properties would still be useful without this database table feature, it’s obviously where the biggest bang for your buck comes from.

I can already picture the UX for entering a property in a card. Typing “{{“ will pull up a dialog just like the one for Tags, showing you the Property Keys you’ve already used in the past. Once the Key is entered/chosen, the dialog then displays all the Values that have already been used with that specific Property Key. (Using the {{Key: Value}} syntax as an example, but obviously it could be different).

Lastly, I had the thought that maybe you could expand todays Tags feature set and just have values added to them, like [[Key: Value]]. I think that’s the wrong approach because then you’d have some Tags with values, others without, and maybe even a single specific Tag that both does and does not have values across different spaces. This adds an additional layer of confusion that will likely already come out of “should I use a tag or property for this?” Keeping them separate and making a Value required for every Property Key, I think, will at least start to help answer that for people.

Next time on Far-fetched Idea: Database Table Use-Cases

[bentsai]

Can you give an example use case?

[kordumb]

Was planning to go a lot deeper into usecases a bit later, but… a big thing is overall organization of spaces. So I have a ton of spaces that are essentially “hubs” with links to other spaces that are all related example. This solves that and basically gives people a way to organize and tackle the evergrowing Spaces list.

So this space for example: https://kinopio.club/-2022-humdrum-media-U8lXIrvFcUQFALJQzweTd

…links out to 7 2022 media ranking spaces. These seven could live in a table instead, which would be filtered by Tags: [[Rankings]] and [[2022]]. I have [[Hub]] and [[Life Wiki]] tags used across various spaces as well and a way to have a static way to look and get to all those places would be super helpful. Or even a space of all the spaces that have database tables so I can basically create a folder structure. Or a table of all my [[2022]] [[Daily Note]]’s.

Lastly, I have my TV and Movie spaces, but also this Notion database. The entire usecase for Notion could basically be done in Kinopio with the database table feature as laid out, which is really where Properties would shine for me.

[kordumb]

Mentioned this to Ben, but wanted to throw in here as well.

I think another way to phrase this would be similar to Queries in Logseq or Roam.

Essentially it’s a Saved Search for creating a list of spaces, determined (filtered) by various data points such as Tags.

[pirijan]

@kordumb

very quick mock-up in excel of what I’m imagining the table card could look like

this explains it nicely, along with the notion example. I don’t doubt the potential usefulness , but I’d consider this a much longer-term feature because of it’s high dev-difficulty/scope (building a notion/excel is no small task), and that it sounds like the use cases are relatively advanced/niche.

The plan is to at least have built the ability to globally search across all your spaces before this, which might address/alleviate some of the use cases here too

[kordumb]

100% - called it Far-fetched for a reason

[Sharknader]

What about creating a Space that serves as a map for other spaces that you manage manually? Frankly, I’m finding the need for Logseq/Roam-like queries much reduced in Kinopio, as I can actually remember stuff, and it’s not an infinite pile of bulletpoints.

[kordumb]

I have many of these types of spaces, but manually updating them is quite a bit of work for me given how many spaces and types of spaces I have.

That’s where the database table card comes in handy because it’d essentially automate that.

[Sharknader]

That makes sense.

[kordumb]

Related:

(Apologies for poor quality)

But just wanted to share Drafts has an upcoming “Scoped Tags” feature that is very similar to the Property idea above.