目次 †
発想の原点。ここからやりたいこと/要件が生まれる。
関連 †
検索:コンセプト
コンセプト周辺のタグ †
Arrayコンセプト †
遅い→起動時:*[Wiki
:t/コンセプトより †
- 適当に。
- 人にやさしく。
- 抽象的に。
- 半自動的に。
未分類 †
どちらかと言えば機能追加は簡単なほう。
あとで:t/コンセプトを追加。
思い付き †
† 遅い→起動時:*[Wiki]
- 書く人のための支援を中心に。読む人のための情報はシステム任せ。
- 適当に書いてるのに読みやすくなるような。
1人でアイデアノートとして使うことを念頭に。複数人での活用は、過去・未来の自分とのコラボレーションということで。 - 書く人、読む人、Wikiを組み立てる人の3ロール。
- どちらかと言えば機能追加は簡単なほう。
難しいのは機能の最適化。
個々の機能を正規化するには関連する機能も正規化されていなければ無理。
ストレージの容量は気にしない。
- ストレージの容量は気にしない。
トレードオフがあれば容量に負担を掛けるように。
柱 †
Wiki自体が1つのページ †
ページ主体 †
ページにできるものはページに統一。
ページ同士のつながりを管理するシステムを。
ページどんなページをどうつなげるかで活用できるような。
ページのつながりを検索に利用するように。
UIの設計方針をユーザーマニュアルに †
書くこと優先 †
書きたい人にとにかく書いてもらえるように。
他人にとっても有益な情報にするのはシステムの役目。
システムができないことだけ書く人にやって貰う。
:i/エラーはユーザーに見せない †
記法のエラーなら何とか解釈。
解釈できない時でも別形式で表示。
†:Wikiデザイン原則 OR Wiki-Design-Principles
アイデアノートとしてのWikiを作るために重要なこと †
- 分類のしやすさ
- 分類の手間の少なさ
分類しなくても分類されているような。
整理しなくても整理されているような。
※人力ではなくシステムで。人手をかけずに。 - 分類の変えやすさ
アイデア創出で手伝えることは分類くらいしかない。
分類することは理解を要する知的な情報処理だから、これをサポートしなくてはアイデアをまとめるツールにならない。
構造化 †
簡略化のため、構造化。
型の定義が正しければいいはず。
何でも複数にできるように。
Wikiは1つのページ †
UIの設計方針をユーザーマニュアルに †
参考 †
最良のメモソフトってどんなものだと思います? - 人力検索はてな
http://d.hatena.ne.jp/pmint/20070406/p2
Wiki構築には2つの側面が †
Wikiの構築はシステム構築とコンテンツ構築。
システムは…
- 開発者
- 管理者
…の役目。
コンテンツは…
いずれも管理者は2番目。
管理者の役目は開発者が作ったシステムと利用者が作ったコンテンツを結びつけること。できる限り有用に。
Wikiとは †
- 情報を保存するシステム
- 情報を公開するシステム
- 索引を作るシステム