タグを中心にした知識の構築

創造的なツールには魅力的なUI、ビジュアルも必要ではないか

しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。

情報を後から見返したいと思えるようなUIだろうか？

まず最初に、僕はWindowsとiPhoneとiPadのクライアントしか使ったことがありません。もしかしたら、Macでは違うかもしれません。ただ、WindowsとiPhoneとiPadのクライアントのUIは、正直あまり好きにはなれません。あまり素敵ではないからです。

色々な情報をEvernoteに蓄積していく。そして数ヵ月後か数年後、それを見返したいと思うときがくるでしょう。ただ、果たしてこのEvernoteで情報を見返して満足感が得られるのか？機能は貧弱でもより魅力的なUIを持つアプリケーションの方が、読み返すモチベーションも読み返した後の満足感も上ではないだろうか？そう感じたことはありませんか？

ただ、見返すものが、文字通りただの情報だたっとしたら、そこにデザインという観点は的外れでしょう。ただ、大学ノートではなく会えて高価なモレスキンなどのノートを手に取るような人であれば、一度は感じたことがあるのではないでしょうか。

Awesome NoteのUIデザインは本当に素敵です。 もう素敵すぎて、アプリを起動する度にウットリしてしまいます。惜しむらくべきはアイコンでしょうか…。

そして、使い勝手も決して悪くないんですよね。ノートの表示方法も多彩だし、ソートも結構強力です。クイックメモ機能やToDo管理も便利です。ノートブック毎にカラーやアイコンを変えて、ノートブック一覧も見やすくできます。検索の速さも優秀です。

• タグクラウドビューのワクワク感！
  • 大きく育ったタグには、たくさんインプットしたなぁという満足感も感じられますね！！
• スライドバー操作で、様々に変化するフラグメントリストビューの爽快感！
  • 画像フラグメントのサムネイルが表示されるようになると更に楽しくなりますね！！（要望です、ご検討よろしく御願いします）
• 軽快な検索スピードと、的確な検索結果を併せ持つ、優秀な全文検索！
  • 一回の表示量を制限しているので、大量の検索結果がある場合でも、極端に遅くなったり重くなったりしないのが職人技って感じです！！
• フィルタ操作を意識させないシームレスな｢関連するタグ｣機能！
  • ＋ボタン、－ボタンでポチっポチっと操作していく感じも、分かりやすく面白いです！！
• フラグメントツリービューからのつながりをたどるネットサーフィンの楽しさ！
  • 双方向つながりだと更にネットワークが広がり、まさに脳内シミュレータと化します！！

• html body div.ac_results ul li.ac_over{ color: #ff6600 ! important;} の発見。
  • タグの入力補完機能が働いている時に選択しているタグを区別するための色の指定の記述を発見。
• 小さなアルファベットが読みやすくなるように"Verdana"フォントを指定。
  • フラグメントのつながり表示が読みやすくなります。
• visited linkの色を変更しない。
  • ニュースサイトなどと違い、自分で入力した記事なので必要が無い。無意味に色に差がでると逆に混乱する。
  • todo的な利用をする方、読み返し具合を把握したい方などは、個別に配色を設定する方が良いでしょう。
• @-moz-document url-prefix("http://localhost:8080/warファイル名/document-view.htm" の記述に注意。
  • スタンドアロン・パッケージ以外のユーザーの方は、微調整が必要です。

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document url-prefix("http://localhost:8080/") {

html body div.ac_results ul li.ac_over{
    color: #ff6600  ! important;
  }
　
body,span, div, td,  h1, h2, h3, h4, h5, h6, li {
   color: #ffffff;
   background-color:#333333 !important;
   font-family:"Verdana" !important;
  }

a:link {
    color: #ff6600  ! important;
  }

a:visited {
    color: #ff6600  ! important;
  }

a:hover {
    color: #ff0066  ! important;
  }

a:active {
    color: #ff0000  ! important;
  }
}


@-moz-document url-prefix("http://localhost:8080/document-view.htm") {
  * {
    background:#ffffff !important;
  }
  body, span,  div, td,  h1, h2, h3, h4, h5, h6, li {
   background-color:#ffffff  !important;
   color: #666666
  }
  H1 {font-size:medium!important;}
  H2 {font-size:small!important;}
}

つながりの意味とランダムビュー

ネットワーク構造というのは頭の中にだけにある抽象的な構造で、これを抽象的なまま視覚情報、つまり図示するのは結構難しい。例えば、もっとも単純だと思われる２ノードのネットワークを図示することを考える。

ノードをどのように配置するかで、ネットワークの「意味」が変わってしまう。横の配置では対等に見えていた二つのノードが、縦の配置では上下関係があるかのよう見えてしまう。

Piggydbを操作すること、それ自体が今以上に楽しくなりますように

整理法などの本を読むと分かりますが、情報を探しやすくするために情報を分類・整理することは、あまり費用対効果が高い作業ではありません。情報の量と種類が多くなればなるほど、管理が難しくなります。探すことにフォーカスするのであれば、高度な検索機能があれば事足ります。とりあえず何でも保存しておいて、あとから検索すればいいわけです。実際にそのようなツールは沢山あって、それらの機能は信じられないほど高度になっています。

続けるためには「快」が不可欠

以上、ごくありきたりの話に得心がいきましたら、ユビキタス・キャプチャーを続けるための個人的な快感要素を探し出してください。不快要素も見つけ出してください。快の要素を強め、意識し、不快要素を撲滅するようにしていけば、続けられます。

これはユビキタス・キャプチャーに限った話ではないのです。私は最近、かろうじてブログが連日続けられるようになりましたが、続けられるようになった要因は「１Password」と「Text Expander」と「MarsEdit」にあるのです。

ぜんぶLifehacking.jpの堀さんに教わったものですが、「ブログを続ける」というときに障害となったのは、Password入力が面倒くさかったことと、同じ文章をくりかえし入力するのが面倒くさかったことと、タグを覚えるのが面倒くさかったことなのです。それを面倒くさがりながらも何度も続けていたため、それらを取り払ってくれるツールを使うのが快感なのです。だから続くようになったのです。

デイリータスクが全てきちんと片付けば「快」だし、自分の予定、タスクが全て書き出されていてそこに書かれていることにだけフォーカスすればいい状況も「快」、考えていることやアイデアが頭の中にだけあって「忘れるかも・・・」と思っている事はひどく「不快」。

• タグページからＤ＆Ｄでタグ付けが出来るようになる。
  • (#541 タグフラグメントからＤ＆Ｄでタグ付けできたら最高　など）
• 画像をＤ＆Ｄすることで、新規の画像フラグメントが作成される。
  • 既存のフラグメントにＤ＆Ｄすると、上記の作業に加えて、そのフラグメント番号が埋め込まれる。
• フラグメントにリッチテキストやカラー表示が使えるようになる。
  • カラータグの採用(#369 見た目のカスタマイズについて)
  • テキストの一部にclassを設定できるようにすればStylish経由でスタイルを設定できる(#380)
• つながりのあるフラグメントを空間的に自由に配置できるように
  • (#473 作者からの回答 など)

ユーザの成長は表裏一体

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。

• #394 "タグ"は"エッセンス"を括ったもの
• #262 (タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています)

1. 正式名称の親タグの下に、簡略したタグ名を子タグとして登録します。
2. そうすると、子タグは親タグに含まれますから、正式名称の親タグ、簡略名の子タグ、そのどちらからでも目的のフラグメントが検出されるようになります。

例えば、本連載を筆者はプロジェクトと位置づけていますから、本連載に役立ちそうな資料となるメモはすべて.「シゴトハッカーズ」というタグを付けています。

そして、プロジェクトが終わったら、タグをリネームします。例えば本連載が残念なことに終わってしまったら、■「シゴトハッカーズ」というタグに切り替えるのです。

すると、タグは名称で並び替わるので、それまでは上位の方に並んでいた「シゴトハッカーズ」のタグが一番下に落ちます。

1. 新タグが旧タグを細分化するものであれば、旧タグの子タグとして新タグを作る。
2. フラグメントカートを使い、旧タグの中から適切なフラグメントのみを新タグに登録する。
   1. このとき、複数の親タグからフラグメントをセレクトする事が可能。
3. 旧タグは削除せずにリネームする。（タグの記号を更新する）

1. 新タグが旧タグよりも大きなカテゴリーであれば、単純に旧タグの親タグとして新タグを作成すれば、ＯＫ
2. 当然、複数の旧タグを子タグとする事が可能。
3. この場合も、旧タグは削除せずにリネームする。（タグの記号を更新する）

1. 旧タグ全てを削除せずにリネームする。（タグの記号を更新する）
2. 全ての旧タグの親タグとして、｢引退済み｣というルートタグを設定
   1. 他の旧タグがタグツリービューのルートタグから表示されないようにする。
3. 次に、出来る限り旧タグの設定を活かしつつ、全てのフラグメントに新タグを設定していく。

• 古いフラグメントには新旧二重のタグが設定され、新しいタグは新タグのみが設定されるようになりますが、それは気にしないことにします。
• タグのリネームと｢引退済み｣ルートタグにより、３つのタグビュー全てにおいて、新旧タグの区別がハッキリ表示されるので、大きな混乱は無いと思います。
• 何より、タグの移行作業は大仕事になり、必ず移行期という期間が発生しますが、この方法なら移行期でも余り混乱せずにPiggydbの使用を継続することが可能になります。

タグフラグメント化と既存のつながり

1. 既存のフラグメントをタグフラグメント化する。
2. そのタグがつけられる候補になるのは、タグフラグメントとつながりのあるフラグメント群であることが多い。
3. そのフラグメントからタグフラグメントへのつながりを今後も残していくかどうか。
4. また、新しくタグ付けされたフラグメントはタグフラグメントへつながりを作成する必要があるのか。

• 既存のつながりはそのまま維持する。
  • つながりは芋づる式の記憶の連鎖を保存する役割も担っているから、タグフラグメント化しても重要な役割を果たし続ける。
• 新しいタグは基本的にタグフラグメントへのつながりを作成する必要はない。
  • タグフラグメント化するということは、新しい概念が自分の中に誕生したと言うこと。
  • 新しい概念に沿って、タグ付けすることと、発想の連鎖によってつながりを作成することは意図が違う。
  • 新しい概念に沿ってタグ付けしたフラグメントに発想の連鎖を感じたのであれば、臨機応変に重複して対応させればよい。

トップダウン式のインデックスタグと、ボトムアップ式のエッセンスタグの使い分け

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。

今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。

そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

#270 つながりとタグの使い分け例: 「Table Tennis Videos」

そして重要なのは、フラグメントに適用すべきタグは最も具体的なタグだけでOKだということです。ある選手のタグを試合フラグメントに貼り付ければ、そのフラグメントはその選手の所属国やスタイル、性別によっても同時に分類されることになります。

1. このフラグメントはどのようなタグで分類すべきなのか、などは気にせずに、とにかくフラグメントを貯めていく。
2. ある程度、フラグメントがたまった段階で、フラグメント群を見なしてみて、中心になっているフラグメントを探す。
3. そのフラグメントをタグフラグメント化して、関連するフラグメントをタグづけていく。

• 人によって判断基準が異なる分類、主観的な分類。
  • 上記の固有名詞を中心にした｢トップダウン式のインデックスタグ｣は誰が見ても同じ分類ができる客観的な分類ですよね。
  • 逆に、個々で判断が分かれる分類である、ということが｢ボトムアップ式のエッセンスタグ｣の一つの目安となるはずです。

#155 何のために「分類」するのか？

ではPiggydbにおける「分類」とは何なのか？ それは一言で言えば、「ユーザー自身が学習するため」の分類です。本来分類という作業は機械的にできるものではありません。先程書いたように知的負荷の高い作業です。検索のためのタグ付けであれば、単純にキーワード検索でもいいということになってしまうかもしれませんが、本当の分類(classification)は、そのキーワードが情報に含まれるかどうかとは無関係です。よって、Piggydbではユーザー自身が考えてタグ付けすることが重要です。

• ｢こんなに暗い設定なのに何故か笑える、こんなドラマ、阿部サダヲじゃなきゃムリ！｣
  • 凄く面白かったドラマに関する感想を書いたブログ記事があったとします。
  • そして、何作か違うタイトルなのに同じような感想のブログ記事を書いたことに気付きます。
  • その時に、一番分かりやすい（とか一番最初に書いた等）ブログ記事のタイトルをタグフラグメント化します。
  • そして、似た感想を持ったブログ記事を、作成したタグフラグメントでタグ付けしていきます。
  • （※ブログ記事＝フラグメント）
  • 単純に阿部サダヲが出演したドラマに関するフラグメント全てにタグを付ける訳ではないです。
  • あなたが自身が実際に見て、そう感じたドラマについて語ったフラグメントにのみこのタグを付けます。
  • 逆に、例え阿部サダヲが出演していないドラマでも、同じような雰囲気を感じれば、このタグを付けます。
  • そうなった場合、タグの名前をリネームすることもあります。
  • リネームを繰り返し、自分のもやもやっとした感想が一つの言葉として整理され時こそ、記念すべき新たな概念の誕生の瞬間です。

• 喜怒哀楽タグ、感情タグ
  • どんな気分になりたい時に読み返したいのか、を意識してタグを付けていきます。
  • 落ち込んでいるから笑いたいなぁ、という時のために｢笑｣。今日は泣きたい気分だ、というときに｢哀｣。
  • もちろん、自分のグチをつらねた｢怒｣タグなど、フラグメント記入時の感情をタグにしてもＯＫです。

• 明確なキーワードが思いつかないんだけど、なんとなく共通点を感じるフラグメント群、その中の一つのフラグメントをタグフラグメント化
  • そうして感性でフラグメントを集めていくと、次第に具体的な共通点が明確なキーワードとなって浮かんでくる時が来る、かもしれない。

• ｢楽しくなくちゃ続かない｣
• ｢シンプルイズベスト｣
• ｢コストパフォーマンスは重要。高い商品は気軽に消費出来ないから逆効果｣
• ｢オレの好み｣
• ｢いつか試してみたい｣

• 「全てを手帳に記録する」、ユビキタス・キャプチャーの実践 | Lifehacking.jp

• ユビキタス・キャプチャーの他にもライフログやMoleskineなど、別の固有名詞が含まれているから。
• 正式なユビキタス・キャプチャーの方法論ではなく、自己流にアレンジされているから。

1. まず、 「全てを手帳に記録する」、ユビキタス・キャプチャーの実践 | Lifehacking.jp]というフラグメントをタグフラグメント化
2. タイトルが長すぎるので、｢全てを手帳に記録する」、ユビキタス・キャプチャーの実践｣にリネーム
3. インデックスタグとしてに｢ユビキタス・キャプチャー｣、｢ライフログ｣、｢Moleskine｣という固有名詞タグを作成。
   1. ３つの固有名詞タグのそれぞれの子タグとして、｢全てを手帳に記録する」、ユビキタス・キャプチャーの実践｣を登録。
   2. ここを親タグor子タグとして登録する、そもそも登録しない、はケースバイケースです。
4. 自分の中で考え方が消化できてきたので、タグの名前を｢書いて忘れる｣にリネームする。
5. 以後、｢書いて忘れる｣為のコツ、などに関するフラグメント全てに、このタグを付けていく。

まずはとことんツナガリだけで構造化してみよう

1. Piggydbを図解風にボトムアップ思考で使いたいなら、まずはとことんまでツナガリだけを使ってフラグメントを構造化することに挑戦してみよう。
2. その中で、これだけは特別な関係だ、これは俺だけの閃きだ、これは私だけの新鮮な発見だ、というフラグメントの構造を見つけたら、そこだけ特別にタグフラグメントを使って、『ID810番』をしてみよう。
   1. このとき、既存のツナガリを削除する必要はない。ダブって良い。それが二重構造。だからこそ、『ID810番』。

ゆるやかなタグと重み付けされたタグフラグメントの差異と区別

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係（つながり）と弱い関係（タギング）という二層化されたグルーピングを提供するのがタグフラグメントなんですね。

たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも？程度の繋がり」のあるフラグメントをタギングで関連付けておきます（タグフラグメントをタグとして貼り付ける）。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造（例えば順序）を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます（この移行作業を簡単にできるようにしていく予定です）。これが、Piggydbで提案しようとしている知識構築（情報の重み付け）の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。

つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括でタグ付けする機能は既にありますので。

• #627 強い関係と弱い関係

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。

結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。

今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。

そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

• #544 タグを中心にした知識の構築

• ゆるいタグ→つながりによる構造化→タグフラグメントによる情報の重み付け
• 利用者自身が学習によってよりよい分類方法を発見する事と過去のタグの修正の困難さ