発想の原点。ここからやりたいこと/要件が生まれる。
目次 †
関連 †
検索:コンセプト
:t/コンセプトより †
#tagcloud(0,related=コンセプト)
未分類 †
あとで:t/コンセプトを追加。
コンセプトとは †
思い付き †
遅い→起動時:*[Wiki]
† 遅い→起動時:*[Wiki]
- 書く人のための支援を中心に。読む人のための情報はシステム任せ。
- 適当に書いてるのに読みやすくなるような。
- 書く人のための支援を中心に。読む人のための情報はシステム任せ。
- 適当に書いてるのに読みやすくなるような。
1人でアイデアノートとして使うことを念頭に。複数人での活用は、過去・未来の自分とのコラボレーションということで。 - 書く人、読む人、Wikiを組み立てる人の3ロール。
どちらかと言えば機能追加は簡単なほう。
- 書く人、読む人、Wikiを組み立てる人の3ロール。
- どちらかと言えば機能追加は簡単なほう。
難しいのは機能の最適化。
個々の機能を正規化するには関連する機能も正規化されていなければ無理。
ストレージの容量は気にしない。
- ストレージの容量は気にしない。
トレードオフがあれば容量に負担を掛けるように。
概観←→断片ができるように †
Wiki自体が1つのページ †
- 概観→断片
- 全体像から、気になるところの詳細を引けるように
発想支援にも †
UIの設計方針をユーザーマニュアルに †
支援できるのはリンクすることくらい
それと、並べることで欠けているものを見つけやすくすること
wikiは例を集めて分類することに向いている †
それを読めば抽象化しやすい。抽象化の支援にもなる
具象→抽象
KJ法とよく合う
逆方向。
抽象から(不完全な)具象を考えたとき、それと元の抽象をリンクできる
自動リンクが有効だと意識も操作もせずに具象と抽象がリンクされる
抽象←→具象を双方向とも支援できれば発想ツールとして使える
支援できるのはリンクすることと並べること †
・抽象→具象
・具象→具象(具象同士)
・同じ抽象に関連する具象同士を一覧化
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とは †
- 情報を保存するシステム
- 情報を公開するシステム
- 索引を作るシステム
コラボレーションツール?ではコラボレーションツールとは…
→他人の考えを自分の考えと同じように見つけやすくするもの。
過去の自分は他人。自分ともコラボ。過去の考えも今の自分の考えと同じように見つけやすく。
つまり、誰にとっても(今の)自分が作ったかのように思えるサイトを作るもの。
エラーはユーザーに見せない †
:i/エラーはユーザーに見せない †
記法のエラーなら何とか解釈。
解釈できない時でも別形式で表示。
Google:Wikiデザイン原則
バージョン管理と同じ点、異なる点 †
†:Wikiデザイン原則 OR Wiki-Design-Principles
参考に/question_1298117876[?]
そのほか †
同じ点
- 大勢でまとめる、1つの知識にする
- 内容はずっとベータ版
- -
違う点
いい加減 †
- あるページを編集したとき、それに関連するページの更新はそのうち行われる
- 書式を間違えたときでもエラーも警告も出ない。ただ思った通りに表示されないだけ。
(ただし、そういうところを探し出す方法は用意する)
…とか。
こんなWikiEngineあったらいいな †
まとまるWiki †
「とりあえず情報をぶっ込んでおけばそのうちまとまるWiki」
「つぎにすることがわかるWiki」
絵だけのWiki †
ギャラリーやお絵かきコミュニケーション。
ステイルテーマ?
読み進めるほど収束するWiki †
読み進めるほどに収束していく構成にならないか。
通常は読めば読むほど拡散していくもの。特に内容が多ければ。
それを逆に収束方向に出来ればまとまるwikiに。
読むときなので読み手の必要な分だけでできる。
深く読み進めるためのテキスト、概観するためのテキスト †
Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。
閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。→システムでやることではない。
- -----
他のページを章単位で埋め込みできればいい。
「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
更新された部分や人気の部分が章単位で表示されれば効果あり。
- -----
編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。
New!が下位ページも調べるようになっていればいい。
上位ページが下位ページに依存したりしないこと。
概観のための体裁 †
テキストを再編、再レイアウトして。
見出し以外のフォントを小さくすれば情報の密度も分かる。
見出しを読めるようにすること。