Spark Cards: Spaced repetition for Hunches and Ideas

Spark Cards

Summary: Flashcards that one consults via spaced repetition, that contain the hunches for ideas, and can be annotated and commented on. Using spark cards allows ideas to not be forgotten, mature and be connected to other ideas over long periods of time.

Introduction

I found reference to “Spark Notes” via the HN discussion of the article “Put it on the crazy pile: Ideas and creativity” where “spark notes” are mentioned in the footnotes. The term was introduced by Steven Johnson, author of the book “Where good ideas come from” (see IdeationHub intro page). In the HN thread “spaced repetition” is mentioned.

How it works

A hunch for an idea comes and goes. Hunches are very fleeting thoughts. In order to remember them it must be as easy as possible to pen them down as soon as you have them. Both hunches and ideas are also easily forgotten about, and your notes about them never revisited. Ideas develop best if you frequently look at them and relate/reflect to what you are doing and thinking at that time. So they can be refined, connected to other ideas, or - if they make no sense at all - be discarded.

Therefore just having an ideas list - a Spark File - hanging around somewhere that is growing and growing is not enough. You need to actively re-read the list.

This is where Flashcards and Spaced repetition come in. They are a proven method for memorization and learning. And can be very well used to keep you aware of past hunches and ideas.

A Spark Cards feature for IdeationHub might have:

  • Flashcard spaced repetition of Idea lists.
  • Ability to annotate Ideas.
  • Ability to cross-reference Ideas.
  • Ability to discuss Ideas with others.
  • Ability to create new Ideas as flashcards on-the-fly.

My first thought when reading this: This sounds like a “FediVerse bot” that announces the Flashcards periodically, e.g. announce one a day. One obviously covers some of the requirements like “annotating” by simply allowing people to reply.

Implementation thoughts

  1. By modelling a Flashcard as a ActivityStreams Note, one should obtain good interoperability.
  2. “FediVerse Bot” = ActivityStreams Service Actor
  3. Flashcards could be stored as an ActivityStreams OrderedCollection and management be done through Add/Remove Activities (with some permission checking).
  4. For people unable to send Add/Remove, an alternative management system is needed (that can send these Activities on their behalf).

1 + 2 + 3 = Minimal Product. If one had an ActivityPub Server supporting collection management, it would be almost trivial to accomplish.
4 = necessary for this to be viable, but messy.

1 Like

Welcome to Social Coding @helge :wave:

I like these ideas, and they trigger some additional thoughts. :thinking: umm, let’s see…

Fediverse bot + Forge repository

What if this bot was interacting with a forge repository as its client? Like e.g. fediverse-ideas repo. The bot might use some ForgeFed-foo (cc: @fr33domlover) and maybe forge-specific API (e.g. Forgejo/Gitea).

Repo would have ideas as issues in the issue tracker, based on an issue template and an idea label. The bot’s toot content would be markdown for those clients that support it, and stripped where it isn’t supported (e.g. Mastodon). It might be that the bot only publishes a specific section from the issue template (e.g. the “Summary” heading).

The bot doesn’t have to keep an archive of ideas-related toots to regularly re-boost. Instead it creates new toots from the idea issues. Replies to the toot become issue comments (I know this has issues with spamming etc. but leave that out of the brainstorm for now), which can be curated where off-topic irrelevant ones are minimized.

Each idea issue might be elaborated into a markdown doc in the repo, and idea feedback incorporated via PR’s. These markdown docs might have a frontmatter section that holds metadata used by the bot. In this way it could e.g. report on number of people that interacted on the idea before, status of the idea, submitter/owner, contributors, license, etc.

When the bot kicks off an idea for another fediverse-brainstorm round, it might send another toot to the submitter / owner, so they stand ready to process the feedback that comes in on the repo.

The bot might be installed as a forge application, and be a backend-only piece of software otherwise.

I’m elaborating on this idea. We have a repository with markdown files, e.g.

  • idea1.md
  • idea2.md

Each corresponds to an idea kind of like the issues [here[(Issues - fediverse-ideas - Codeberg.org). These are manually maintained.

Once can then use longhorn, a cron job running a wrapper around poetry run post idea2.md with

:information_source: Need algorithm: repository → markdown file to post

Continued in next post due to 2 links limit.

1 Like

See

for how it looks natively vs on Mastodon.

:information_source: A few tasks need to be done on Longhorn like making CSS better and include capabilities for tagging / mention. Both are “grunt work”. Probably a bunch of other stuff like an “about page” and a better explainer on how to reply using Mastodon.

Then after a few days of discussion, the “idea maintenance team” can circle back, look through the replies, and update the markdown file. One could probably attempt to automate some things like adding links to a reference list or something, not sure. Needs thinking.

1 Like

Wrt connecting to a forge, yesterday I re-bumped into:

Maybe the code might be made suitable for use on Codeberg.