とりとめのない思い付き。
Wikiは読みにくい † 
wikiって相変わらず書いてある内容が分からないな
俺が新しい時代についていけてないだけか
- -
あやしいわーるど＠暫定(暫定退避) 過去ログ検索結果 (＠検索)
- 文字が多すぎる
減り張りの無い文字ばかり。だからと言って図が必要というわけではない。 - 整然としすぎている
本文中、行頭にあたる線が1本。
記事が1列に並んでいる。
俯瞰しづらい。 - サイドメニュー（MenuBar）が乱雑
上部にもグローバルナビがあったりする。見えているのはどちらか一方でいい。- 隠す
表示時に画面を再レイアウト。本文がずれるので気持ち悪い。 - 隠す
表示時は本文に重ね合わせて表示。表示のためのスイッチを小さくしないと邪魔。 - 隠す
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。 - 色を薄くする
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。
&tip;これがいいかも。
- 隠す
- タイピングした文章と自動生成された文章が混在している
自動生成された文章（目次など）には人が読むには余計な部分が混ざる。
読み飛ばしができない人にとっては混乱の元。
これはコンテンツを作るときに気をつけること。ページの冒頭には自動生成された文章を置かず、そのページの概要をタイピングで書く、など。
URLクエリーの列からToDoリストやワークフローを生成できるように †
どちらも実装は同じになる。
- ToDoリストはインスタンス定義
- ワークフローはクラス定義
…のようなもの。
つまり、ワークフローは使うたびに新しいデータを生成し、ToDoは同じデータを扱う。
リンクやバックリンクの数が少ないページ／多いページをどう探すか？ †
→ 量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。
ワークフローはランダム文字列などを使ってインスタンス生成。
検索で「ブログ」と「ログ」を分けたい †
「ログ」を検索したときに「ブログ」を見つけないように。逆に見つけたいときもある。
曖昧検索のルールで自動リンク †
これらを生成するためのフォームはプラグイン扱い。
いろいろと考えられるので。
曖昧検索と自動リンクを統合。
例えば、自動リンクするとき、ページ名やリンク対象に含まれるひらがなを無視して自動リンク。
ページ本文中の「読みやすい書き込」が「読みなれた書込」のページに自動リンクする。逆も起きる。
ボットみたいなのはクライアントで実行 †
そのためのWebAPI。
可能なものはAPIごとにUIを作って、ネットで公開。
曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ（入口リンクはあるけど実在しないページのメタページ）から「読みなれた書込み」にリンク。類似したリンク先もそばにある。
ページ一覧で含まれる数字を全部集計 †
ページ一覧や下位展開、コレクション（サブセットWiki）など、複数のページを扱うページでは、含まれるページに書かれている数字を集計。数値類の記法がラベルを受け入れるなら、ラベル別に集計。
ファセットナビゲーションの集計版。ページ要素を集める点は似ている。
他でも検索 †
InterWikiNameのUI違い。
「「検索結果に登録されているWikiサイト」で検索をする」リングを作る。
検索ボックスにはWikiサイトの選択欄を。
Ajaxでリンクを随時作るのもいい。
→:集計
最後に参照したページ †
もしWiki外へ出ても元のWikiページに戻れるように、
クライアント側データに「最後に参照したページ」のIDを残す。
クッキーがいい。
「要出典」は指摘・抗議 †
「要出典」はコメントとは別の形の抗議。
履歴すべてを残したいところだが、クライアント側のIDとサーバー側のDBで実現。（データが大きくなるので）
上位ページでは下位にあるコメントも見える †
コメント（スレッドモード）だけをつなげて並べる必要は無い。下位展開で各ページにコメントがあればいい。
実装 †
ページを指定していないリクエストでは
…を返す。
見出し無しはルートページを指す †
見出しよりも先に書かれたテキストは、名前の無いページ（ルートページ）の本文に追記することになる。同名ページは1人ひとつまでなので、同名ページ作成にはならない。
というわけで、トップページを見せたいときはトップページを指定したリンクを作り、通常はページを指定しないリンクを使う。
これで、静的なページからでもWebブラウザーの履歴を操作することなく、最後に参照したページに戻れる。
検索結果の定義は特定名のページで †
その下位ページは、ヒットしたページごとに利用されるループ部分。
…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。
よく出てくる単語（頻出語）の一覧 †
新しいページを作るきっかけなので、「新規ページ作成」ボタンの前に利用者に見せたい。
新規作成のページで表示するのもいい。ページ名を統一するために。似ているページ名を探すのに役立つ。
利用者が同一サイトに集まるわけない †
投票は結局無駄になる。
独立したページにすべき。
活用しやすくするため。1ページが1つのDBテーブルのようなもの。
「自分にとって」は2つある †
頻出語のリストには、最後に発見された*1日付も。
データを活用するために。
自分のスペースにインポートすれば投票か †
他人のページをコピペ改変するのが投票か。
投票は自分のページと、自分が触れていないページにするもの。
コピペ元にも同時に投票される？重要な版を自動検出して代表化する。
→プラグイン/テンプレート生成[?]
ページセットはページの属性を表せる †
ページ属性はページセット。実装の違い。
ページ属性とページセットを同一視。
深く読み進めるためのテキスト、概観するためのテキスト †
Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。
「自分にとって」を基本にして †
どう利用者間のコラボレーション・コミュニケーションをするか。
元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解・同名ページは無くなった。
閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。システムでやることではない。
他のページを章単位で埋め込みできればいい。
「自分にとって」は何と結び付けるか †
- 投票…ページ名とページの結び付け
- ページセットと？（コレクション）
- 承認と？SPAMでないこと
- すべて
FederatedWikiのように。 - 自分用にできないもの
ページ名はページの一部なのでできるはず。
「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
章単位で更新された部分や人気の部分が表示されれば効果あり。
「自分にとって」を実現するために、1スペースに1人だけにすると †
編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。
スペースはページセットでコレクション †
1人でいくらでも持ちたい。
※自分のスペース内に。
New!が下位ページも調べるようになっていればいい。
「自分にとって」はスペース。スペースをまとめたのがWiki.
上位ページが下位ページに依存したりしないこと。
ゲストは投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース。
奥にしまう †
アクセスされていないページと付帯データは別サーバーに。
基本がFederationになっても、投票を伴なうピン留め操作は必要 †
これで（共有スペースでの）代表が決まる。コピペ改変も投票を伴なう。
携帯向けビュー †
サブページが実装されれば目次を表示するだけでいい。
目次からサブページへリンク。
投票はSisterWikiネットワーク内で有効 †
フォローも同様。
実装 †
ユーザーエージェントで携帯かどうか判定。
承認時、モデレーター間で意見が分かれたら？ †
- 投票は「自分にとって」のもの
- 投票でモデレーターになれる
- 利用者によって、どのページが存在して、削除されていて、SPAMかが異なる
- この3つはページセット。承認はページを3つのページセットに振り分けるもの
タブでインデントしたい †
テキストエディターを使うとインデントしやすくなる。
基本がFederationになっても、フォローは可能か †
同名ページ→その作成者→作成者の利用者ページでフォロー可能。
フォローリストはページセット。それもSisterWikiのインポート対象。
スペースをフォローするのがSisterWiki。
http://lesbimovies1730.forum5.com/?mforum=lesbimovies1730