wikiって相変わらず書いてある内容が分からないな
俺が新しい時代についていけてないだけか
なぜか。
それと解決策は。
文字が多すぎる † 
メリハリの無い文字ばかり。だからと言って図が必要というわけではない。
ページを見渡すと唯一の画像が広告だったり。
パッと見で読むべきところ（見出し）が分かるように。見出しを見ているときにその他の文字が邪魔をしないように。
参考:256倍シリーズ
絵文字やアイコンが含まれていればそれも大きくして。
x256プラグイン。
整然としすぎている †
本文中、行頭にあたる線が1本。
記事が1列に並んでいる。
俯瞰しづらい。
階層が深いのはなお悪いので、2段まで。多くても3段か。
見出しレベルで深くするのは良い。
サイドメニュー（MenuBar）が乱雑 †
上部にもグローバルナビがあったりする。見えているのはどちらか一方でいい。
どうするか…
- 隠す
表示時に画面を再レイアウト。本文がずれるので気持ち悪い。 - 隠す
表示時は本文に重ね合わせて表示。表示のためのスイッチを小さくしないと邪魔。 - 隠す
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。 - 色を薄くする
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。
→これがいいかも。 - （モバイルなら）画面外からスワイプイン
ブラウザーがスワイプインジェスチャーを受け入れる仕様でも、Webページは低優先度なので邪魔にならない。
逆にこちらが使えない可能性はある。
タイピングした文章と自動生成された文章が混在している †
自動生成された文章（目次など）には人が読むには余計な部分が混ざる。
読み飛ばしができない人にとっては混乱の元。
これはコンテンツを作るときに気をつけること。ページの冒頭には自動生成された文章を置かず、そのページの概要をタイピングで書く、など。
どれも書き方の問題なのでシステムが制限を加えるようなことはしない。
例を示すくらい。WikipediaがWikiの例になってしまっているのは問題。解決すべきはそこだけのような気がする。
ページ構造、サイト構成 †
単にツリー構造が分からないという話かも。
ブログと対比されていた時代のログを読むと、ブログは分かりやすいらしい。
読み手にとって両者の違いはページ構成。文字量はブログかWikiかの話ではない。
Wikiのページを一列にできたら…
情報が1ページで完結しない構成もWikiを分かりにくくしている。ページ構成との組み合わせでなおさら。
そこにリンクも絡んでくる。
書き手が（ひとつのエントリーとして）読んで欲しい＝必読のリンクと、その他のリンクが一緒。
これは書き手がブログ的に「…についてはここを参照→」と書けば済む話。
システムでは「明示的なリンク」で支援。
【ページ名】
…を記法にすれば打ち込みにくくもない。[[でもそんなに面倒じゃないけど。
構造を把握する必要は無いのでは。
満足するだけの情報があればいいだけ。
あるいは情報がないことが早く分かればいい。
「どこからどこまで読む必要か有りそうか」が分かればいい。
情報の凝集度とそれを探す検索が必要。
単純なやり方…検索して出てきたページを全てリーディングリストに入れる。おそらく多すぎる。
せめてページごとに優先度を付けたい。
優先度を付けるための情報とは？
- 長さ、情報量
- 新しさ
ただし一文字更新しただけで最新になってしまうような新しさは除く。 - プレビュー
正確には検索にヒットした理由のこと。プレビューよりも確かな方法があればそっちのがいい。プレビューを出すなら段落ごと表示して読みやすく。 - ヒット数
ヒット数が少なすぎるページをよけるための情報。キーワードがどんなのかによっては少なくてもいいので加工してない生情報を表示。文字列探索の欠点を補うだけのもの。改善の余地あり。 - などを総合したスコア
…が算出できればいいけど、何を重視するかのバランスはユーザーと時と場合によるし、バランス調整の感覚を身に着けないと操作できないのでまず無駄。
デフォルトでは簡素な検索結果。検索後にオプション選択して豪華な情報を表示。というのが良さそう。
Wikipediaのモバイルビューのようにcollapse/expandを切り換えるUIで。これを縦ではなく横にテーブル列を展開する形にして。
タッチパネル向けなら行ヘッダーが常時表示される横スクロールのほうが良さそう。全列展開済みで。スクロールで見えなくなる対策は「列ピン」。指定した列をフロート状態にして常時表示。スクロールはするけど表示領域外には出ない。
編集者が多数いること †
書き手が１人でないことも。第一、文章にまとまりがなくなる。
追記する者のリテラシーによる。システムはそれを支援。関連情報を見せるとか。
元記事の編集者にも追記後の記事を編集するというリテラシーがいる。その点でシステムが支援できるのは追記されたことを知らせるくらい？
編集者間だけの付箋紙をページ上に貼れるか、あるいはどのページのどの箇所か分かるような表示で打ち合わせスペースを用意できれば…。
テンプレートメソッド。文章の場合はただのテンプレート。「ここに経緯を書く」「ここに根拠を書く」など。自分で書く「要出典」。
ただこれを記事として公開するのはどうか。
裏記事・ノートとしてならいい。
編集者が見るビューではコメントが表示されるけど、閲覧者には見えない。というのでいい。
ただのコメントで可。
コメント自体が乱雑になるかも。コメントを見やすく（把握しやすくなくていい）する方法がいる。マップ？リスト？
それを読まなければ追記もできないのは避けたいので、編集する段になってからコメントが見えるのは良くない。
ユーザーが編集したことのあるページを閲覧するとコメントが見えるように。
コメントの中からユーザー指名（IDコール）できるように。書き方は「このページの編集者全員」や「このページの一つ前の編集者」や「このページの編集者が所属するグループ」など抽象的な表現で。
権限設定と似た仕組み。
編集（というよりウォッチ）している人にだけ見えるようにバルーン記法でコメントを書くとか。
だらだら感 †
これも書き方の話。
でも単に1画面スクロールに合わせて文章間に隙間を作るだけで解消されるかも。ページ分け。コマ割り。
参考:256倍シリーズ
スペースキーやスクロールバーのクリック、1画面分スクロール「下へ進む」リンクで過不足なくスクロールすれば「長い」感覚が軽減される。
途中に「すべて表示…」を入れて、それ以降を隠すだけでもいいかも。これは見た目だけで、1回のレスポンスでページ全体が返される。
いずれにしても書き方の問題。システムが出来ることはセクション間を広げるとか、「すべて表示…」を入れられるようにすること。
→:i/すべてを表示記法
行間がつまり過ぎているのもある。空行が狭い。一行が長い＝本文スペースの横幅が広すぎる。
スタイルの問題。デフォルトスタイルやスタイルテーマの問題。
†:Instapaper †:Readability †:Pocketなどを参考に。ユーザーが閲覧ビューで切り替えられれば便利そう。（システムでなく）スタイルテーマがそういう切り替えに対応したものである必要あり。
断片的 †
起承転結や序破急の最初がない。
書き手と読み手の視点を合わせないので伝わらない。
Wikiのどのページにも「先日こんなことがあった」のような書き出しか、きっかけになったURIを示す必要がある。書き方の問題。
システム面でできるのは文脈を調べる支援。
書き手が書いた順序を調べるとか。書き手があるページのある部分を書いた頃、どのページのどの部分を書いていたか──執筆した日時が近いテキストを示すとか。
書き手が複数いるぶん実現が難しくなる。
要するに編集されていないから †
編集作業が必要。