コンセプトのバックアップ(No.47)

1. 例を集める（ブレインストーミング）→分類・抽象化
2. 抽象化すると欠けている例を見つけやすくなる。挙げた例で抽象を説明できるか考える
3. 1つの抽象を説明するための例示・具体例の穴埋め→具体化
4. 連想でよその抽象になる例まで思い付く（不完全な例挙げ・ブレインストーミング）
5. 1に戻る

調べるよりも考えるだけに、考えるよりも考えなくていいように †

ページの追加位置を調べて
前後の文に合うように書くことを考えて

…などというのは避けたい。
これならWikiサイト全体を1つのページにするのと大差ない（検索しづらい分、Wikiのほうが劣るかも）

ページを追加すると、自然にまとまる（既存ページから探しやすいようにリンクされる）のが理想。
せめて調べなくていいように。

柱 †

コンセプト

ページ主体 †

ページにできるものはページに統一。
ページ同士のつながりを管理するシステムを。
どんなページをどうつなげるかで活用できるような。

ページのつながりを検索に利用するように。

ページは… †

ページはファイル
ページはフォルダー
ページはデータベース
ページはメール
ページは書き込み
ページは掲示板、コメントリスト
ページは順序や前後のある本のページ
ページはToDoリスト
ページはオブジェクト
ページはログ
ページは記録

→データは全てページとして扱えるように。
内部のフォーマットは記法を利用して、個別に定義、専用コードで読み書き。
記法はXMLのような扱い。

書くこと優先 †

書きたい人にとにかく書いてもらえるように。

他人にとっても有益な情報にするのはシステムの役目。
システムができないことだけ書く人にやって貰う。

書かなければ読めない、読むものがないというのもある。

アイデアノートとしてのWikiを作るために重要なこと †

分類のしやすさ
分類の手間の少なさ
分類しなくても分類されているような。
整理しなくても整理されているような。
※人力ではなくシステムで。人手をかけずに。
分類の変えやすさ

アイデア創出で手伝えることは分類くらいしかない。
分類することは理解を要する知的な情報処理だから、自動ではいけない。
そしてこれをサポートしなくてはアイデアをまとめるツールにならない。

Wikiを書く際に気をつけること †

重複がないこと
自動リンクしたい言葉で、誤字がないこと
書き方、（ローカルな）ルール

気にさせないのは不可能なので、すぐに解決できるように取り計らう。

重複がないことを簡単に（あるいはすぐに）調べられるように。
自動リンクで誤字があればすぐに分かるように。あるいは見つけやすいように。
書き方は分からなくてもいいように。
ローカルルールが不適切なら運営者（それを決めた者）に連絡。

構造化 †

簡略化のため、構造化。
型の定義が正しければいいはず。

何でも複数にできるように。

Wikiは1つのページ †

UIの設計方針をユーザーマニュアルに †

参考 †

最良のメモソフトってどんなものだと思います？ - 人力検索はてな
 http://d.hatena.ne.jp/pmint/20070406/p2

Wiki構築には2つの側面が †

Wikiの構築はシステム構築とコンテンツ構築。

システムは…

開発者
管理者

…の役目。

コンテンツは…

…の役目。

いずれも管理者は2番目。
管理者の役目は開発者が作ったシステムと利用者が作ったコンテンツを結びつけること。できる限り有用に。

Wikiとは †

情報を保存するシステム
情報を公開するシステム
索引を作るシステム

コラボレーションツール？ではコラボレーションツールとは…
→他人の考えを自分の考えと同じように見つけやすくするもの。
過去の自分は他人。自分ともコラボ。過去の考えも今の自分の考えと同じように見つけやすく。

つまり、誰にとっても（今の）自分が作ったかのように思えるサイトを作るもの。

エラーはユーザーに見せない †

記法のエラーなら何とか解釈。
解釈できない時でも別形式で表示。
Google:Wikiデザイン原則

バージョン 管理と同じ点、異なる点 †

wikiとバージョン管理の違いはある？

参考に/question_1298117876[?]

そのほか †

同じ点

大勢でまとめる、1つの知識にする
内容はずっとベータ版

違う点

分岐、マージ
支流と本流がそれぞれ発展、マージも可能。
→見解にあたる。見解を導入すれば「同じ点」になる。

いい加減 †

あるページを編集したとき、それに関連するページの更新はそのうち行われる
書式を間違えたときでもエラーも警告も出ない。ただ思った通りに表示されないだけ。
（ただし、そういうところを探し出す方法は用意する）

…とか。

こんなWikiEngineあったらいいな †

まとまるWiki †

「とりあえず情報をぶっ込んでおけばそのうちまとまるWiki」
「つぎにすることがわかるWiki」

絵だけのWiki †

ギャラリーやお絵かきコミュニケーション。
ステイルテーマ？

読み進めるほど収束するWiki †

読み進めるほどに収束していく構成にならないか。
通常は読めば読むほど拡散していくもの。特に内容が多ければ。
それを逆に収束方向に出来ればまとまるwikiに。
読むときなので読み手の必要な分だけでできる。

深く読み進めるためのテキスト、概観するためのテキスト †

Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。

閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。→システムでやることではない。

他のページを章単位で埋め込みできればいい。

「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
更新された部分や人気の部分が章単位で表示されれば効果あり。

編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。

New!が下位ページも調べるようになっていればいい。

上位ページが下位ページに依存したりしないこと。

概観のための体裁 †

テキストを再編、再レイアウトして。
見出し以外のフォントを小さくすれば情報の密度も分かる。
見出しを読めるようにすること。

発想の入り口、経路を振り返るには †

アイデアノートとしてのWikiでは思考の一時記憶として使えないと。

発想の入り口を作るには †

発想の順番が分かる履歴を †

残して、何かを考えながら思考経路を見るには…
「考えの履歴」

発想支援は利用者の学習を助けるだけ †

発想はすべて利用者の頭の中で生まれる。
それを支援するには利用者の学習を助けるだけ。

目次 †

関連 †

コンセプトとは †

概観←→断片ができるように †

発想支援にも †

wikiは例を集めて分類することに向いている †

支援できるのはリンクすることと並べること †