風Feng_Yijing_Dao

双方向リンクノートでの新旧カードノートの処理フロー#

デモ用アーカイブ - 2021-11-10 || [[✍Notes_吕江涛 20xx 高效信息管理术]]#

旧カードノートの処理フロー#

• インスピレーション + その他のカードボックス
  • #Fleeting と ZKCards、2 つのタグを一緒に使用
  • 個別の #Fleeting コンテンツを #toProject に変換するか、廃止する [[Deprecation]]
  • 学んだことを #ZK に変換するか、両方を独立した集約タグ ZKCards #Fleeting に変換する
• 永続ノートカードボックス ❌
  • 専用の設計はなく、#ZK タグを直接使用して #🧩REF タグを持つコンテンツを永続カードとして扱う
• 全体の構造
  • 引用されたブロック
    • 問題 + さまざまなタグ
      • 回答
      • 例（ある場合もあるし、ない場合もある）
      • 他のノートへのリンク（ある場合もあるし、ない場合もある）
    • ❓Q: ビットリテラシーとは何ですか？ #ZK
      • インターネット情報の爆発的な時代において、情報の過負荷に対する処理と生産。つまり、情報管理の能力です。
  • ❓Q: 情報をキャプチャする際、プロジェクトに感度を高めるプロセスはどのようなものですか？ ZKCards
    • 多くの分野では、理解できない状態から、一部の変化に気づくようになり、最終的にはコア部分を把握して事柄を推進するプロセスです。これがプロジェクトの感度、つまり私たちが感じるものを見つけるということです。
    • [[🌰]] 最近、UE エンジンの学習をしていますが、私は異業種ではなく、以前は 2D モバイルゲーム開発をしていました。しかし、ツールの違いは非常に大きいです。言語やメカニズムが異なるため、操作や学習を行いながら、徐々に感覚を掴んでいきました。
    • [[🌰]] バスケットボールの練習と同じです。最初は適当にやっていたが、感覚を掴んで、シュートの命中率が大幅に向上した。

旧カードノートの処理フローにおいて、私にとっての問題は、情報の表示が多すぎて境界が曖昧であり、認知負荷が増加していることです。#

• 専用の永続ノートカードボックスがなく、#🧩REF の有無を基準にしていますが、基準が明確で便利ではありません
  • 作成後は問題ありませんが、判断が必要で直感的ではありません
    • sm の標準化では、#🧩REF が指定されていないものや、指定されていないものがあります
  • 作成時に非常に面倒になります
• ZKCards と #Fleeting は色で区別されていますが、数が多いと比較が不十分です。改善したいと思います
• クリックリンクでは、元のテキストと #🧩REFが指す具体的な内容が表示されますが、私が気にするのは元のテキストだけで、情報のソースだけです。他の情報はカードノートを表示する際に邪魔な要素です
• もし私がRR でカードを復習して修正する場合、間隔復習ソフトウェアではなく、Neuracache、anki、supermemo のような場所で、情報の表示が多すぎるので、質問カードだけを見たいです。文脈の環境は必要ありません。カードが最小限の情報になるようにします。
  • 問題駆動のカードノートでは、問題を見ると、答えがない場合は本能的に答えを導き出します
• 私のタグデザインでは、プロジェクト、記事、書籍のキーワードは大文字で始まり、具体的なタスクやカードノートのキーワードは小文字です。使用シーン、関連など、小文字で始まります
  • #🧩REF タグを作成すると、直接ブロック引用することで、具体的なシーンを直接表示できますが、大文字のようなトピックスの要約的な視点が欠けています

設計中の新しいカードノートの処理フロー V1.0#

• 旧カードノートの処理フローの問題を解決する
  • ZKCards と #Fleeting は色で区別されていますが、数が多いと比較が不十分です。改善したいと思います
    • 解決策: 視覚的な処理を追加：呼吸や点滅のアニメーションを追加し、考えているような感覚を与え、#Fleeting と関連付けます
  • 専用の永続ノートカードボックスがなく、#🧩REF の有無を基準にしていますが、基準が明確で便利ではありません
    • 解決策: Evergreen カードボックスを追加
  • もし私がRR でカードを復習して修正する場合、間隔復習ソフトウェアではなく、Neuracache、anki、supermemo のような場所で、情報の表示が多すぎるので、質問カードだけを見たいです。文脈の環境は必要ありません。カードが最小限の情報になるようにします。
    • 解決策: 使用シーンを分割し、異なるビューで異なる階層の情報を表示：後述の設計を参照
  • 私のタグデザインでは、プロジェクト、記事、書籍のキーワードは大文字で始まり、具体的なタスクやカードノートのキーワードは小文字です。使用シーン、関連など、小文字で始まります
    • 解決策: ブロックをページに昇格させ、2 つの間のリンクを作成し、結びつきを解除
  • クリックリンクでは、元のテキストと #🧩REFが指す具体的な内容が表示されますが、私が気にするのは元のテキストだけで、情報のソースだけです。他の情報はカードノートを表示する際に邪魔な要素です
    • 解決策: [[[[EVD]] - RR のブロック引用は逆リンクに表示されず、クエリにはさらなるクリックが必要]]
    • 1. 技術的には、参照にフィルタリング機能を追加❌（手間がかかり、JavaScript コードを書く必要があり、パフォーマンスに影響を与えます。最も重要なことは、他の場所でも必要ありません）
    • 2. ブロック引用をページ引用にアップグレード✅（簡単で、ネイティブの方法で実装するようにします）

• ストレージの標準化とカード化ノートの 2 つのプロセスを人為的に分離#

  • 旧デザインでは、明確な境界がなく、ぼんやりとした範囲に属しています。ストレージの標準化は一連のプロセスデータであり、バックアップやデータの冗長性は良いことです。一方、カード化ノートは考える負担を最小限に抑えるべきであり、影響要因は隠されるべきです
  • == 私が達成したい目標は、カップリングを解除し、元の関数を直接変更できない（コンピュータ用語で説明）==
  • ストレージの標準化: ソースの明確な表示、一目でわかり、トレースバックが容易
  • カード化ノート: カードを永続カードボックスに入れる基準を判断するのが容易

• カード化ノートに対して使用シーンを分割し、人為的に異なるビューを作成する、核心的なアイデアは異なるシーンの自分に手間をかけることで、1〜2 つの操作を追加することです#

  • カード作成時#

  • カードの抽出と簡略化のレビュー#

  • 永続ノートの作成とカードボックスへの追加#

• 現在の新旧カードノートの処理フローの比較#

  • ビュー（直感的に使用できるシーンをビューと呼ぶ）#

    • プロジェクト、書籍など、全体のノートビュー
      • ブロック引用の結合、抜粋と質問
    • 抜粋ビュー
    • カードビュー ZKCards
      • カードの追加、削除、編集
    • 永続カードボックス Evergreen [[🧩REF]]

今後のアイデア#

• 命名規則と双方向リンクの特徴を活用して、トピックと番号を強く結び付ける
• == もしdiscourse graphのバグが十分に修正されて使用可能になった場合、それを使用してリファクタリングを完了する ==
  • アイデアと私の一致する点
    • 名前の考え方
    • ブロック引用 ➡️ ページ引用
    • リンクの管理
  • より良い点
    • リンクのターゲット自動化
  • == リンクの管理にかかる労力を軽減する ==