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