- -------------------------------------
とりとめのない思い付き。
- Wikiは読みにくい
- URLクエリーの列からToDoリストやワークフローを生成できるように
- ボットみたいなのはクライアントで実行
- 他でも検索
- 最後に参照したページ
- よく出てくる単語（頻出語）の一覧
- 深く読み進めるためのテキスト、概観するためのテキスト
- 奥にしまう
- 携帯向けビュー
- 表・行列・セルといったものは表だけにする
- CSS適当コンバーター
- 設定などのページにも適用
- 派閥内はSNS
- 必須でないプラグイン公開はWikiEngineとは別のサイトで。
- お客様向け
- 追記するとき
- 毎日ダンプ
- 発想の入り口、経路を振り返るには
- 発想の入り口を作るには
- 発想の順番が分かる履歴を
- ページ名（キーワード）とタグは同等の機能を持つ
- プラグインを実行時に取得
- ショートカットキーやHTML内のIDを重複させないため
- コラボレーションツール
- 読み上げしやすいRSSフィード
- 編集者用メニューにdiffを
- アクセスキーはユーザー設定
- 外に出さない書き込み
- 編集ページは可変長
- interInclude
- 新規ページ作成時、ページを作ってから入力受け付け
- -
Wikiは読みにくい † 
wikiって相変わらず書いてある内容が分からないな
俺が新しい時代についていけてないだけか
- Wikiは読みにくい
- URLクエリーの列からToDoリストやワークフローを生成できるように
- ボットみたいなのはクライアントで実行
- 他でも検索
- 最後に参照したページ
- よく出てくる単語（頻出語）の一覧
- 深く読み進めるためのテキスト、概観するためのテキスト
- 奥にしまう
- 携帯向けビュー
- 表・行列・セルといったものは表だけにする
- CSS適当コンバーター
- 設定などのページにも適用
- 派閥内はSNS
- 必須でないプラグイン公開はWikiEngineとは別のサイトで。
- お客様向け
- 追記するとき
- 毎日ダンプ
- 発想の入り口、経路を振り返るには
- 発想の入り口を作るには
- 発想の順番が分かる履歴を
- ページ名（キーワード）とタグは同等の機能を持つ
- プラグインを実行時に取得
- ショートカットキーやHTML内のIDを重複させないため
- コラボレーションツール
- 読み上げしやすいRSSフィード
- 編集者用メニューにdiffを
- アクセスキーはユーザー設定
- 外に出さない書き込み
- 編集ページは可変長
- interInclude
- 新規ページ作成時、ページを作ってから入力受け付け
- 文字が多すぎる
減り張りの無い文字ばかり。だからと言って図が必要というわけではない。 - 整然としすぎている
本文中、行頭にあたる線が1本。
記事が1列に並んでいる。
俯瞰しづらい。 - サイドメニュー（MenuBar）が乱雑
上部にもグローバルナビがあったりする。見えているのはどちらか一方でいい。- 隠す
表示時に画面を再レイアウト。本文がずれるので気持ち悪い。 - 隠す
表示時は本文に重ね合わせて表示。表示のためのスイッチを小さくしないと邪魔。 - 隠す
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。 - 色を薄くする
表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。
&tip;これがいいかも。
- 隠す
- タイピングした文章と自動生成された文章が混在している
自動生成された文章（目次など）には人が読むには余計な部分が混ざる。
読み飛ばしができない人にとっては混乱の元。
これはコンテンツを作るときに気をつけること。ページの冒頭には自動生成された文章を置かず、そのページの概要をタイピングで書く、など。
URLクエリーの列からToDoリストやワークフローを生成できるように †
どちらも実装は同じになる。
- ToDoリストはインスタンス定義
- ワークフローはクラス定義
…のようなもの。
つまり、ワークフローは使うたびに新しいデータを生成し、ToDoは同じデータを扱う。
ワークフローはランダム文字列などを使ってインスタンス生成。
リンクやバックリンクの数が少ないページ／多いページをどう探すか？ †
→ 量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。
これらを生成するためのフォームはプラグイン扱い。
いろいろと考えられるので。
検索で「ブログ」と「ログ」を分けたい †
「ログ」を検索したときに「ブログ」を見つけないように。逆に見つけたいときもある。
曖昧検索のルールで自動リンク †
曖昧検索と自動リンクを統合。
ボットみたいなのはクライアントで実行 †
そのためのWebAPI。
可能なものはAPIごとにUIを作って、ネットで公開。
例えば、自動リンクするとき、ページ名やリンク対象に含まれるひらがなを無視して自動リンク。
ページ本文中の「読みやすい書き込」が「読みなれた書込」のページに自動リンクする。逆も起きる。
曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ（入口リンクはあるけど実在しないページのメタページ）から「読みなれた書込み」にリンク。類似したリンク先もそばにある。
ページ一覧で含まれる数字を全部集計 †
ページ一覧や下位展開、コレクション（サブセットWiki）など、複数のページを扱うページでは、含まれるページに書かれている数字を集計。数値類の記法がラベルを受け入れるなら、ラベル別に集計。
他でも検索 †
InterWikiNameのUI違い。
「「検索結果に登録されているWikiサイト」で検索をする」リングを作る。
検索ボックスにはWikiサイトの選択欄を。
Ajaxでリンクを随時作るのもいい。
ファセットナビゲーションの集計版。ページ要素を集める点は似ている。
→:集計
最後に参照したページ †
もしWiki外へ出ても元のWikiページに戻れるように、
クライアント側データに「最後に参照したページ」のIDを残す。
クッキーがいい。
履歴すべてを残したいところだが、クライアント側のIDとサーバー側のDBで実現。（データが大きくなるので）
「要出典」は指摘・抗議 †
「要出典」はコメントとは別の形の抗議。
上位ページでは下位にあるコメントも見える †
コメント（スレッドモード）だけをつなげて並べる必要は無い。下位展開で各ページにコメントがあればいい。
よく出てくる単語（頻出語）の一覧 †
新しいページを作るきっかけなので、「新規ページ作成」ボタンの前に利用者に見せたい。
新規作成のページで表示するのもいい。ページ名を統一するために。似ているページ名を探すのに役立つ。
独立したページにすべき。
活用しやすくするため。1ページが1つのDBテーブルのようなもの。
見出し無しはルートページを指す †
見出しよりも先に書かれたテキストは、名前の無いページ（ルートページ）の本文に追記することになる。同名ページは1人ひとつまでなので、同名ページ作成にはならない。
頻出語のリストには、最後に発見された*1日付も。
データを活用するために。
→プラグイン/テンプレート生成[?]
検索結果の定義は特定名のページで †
その下位ページは、ヒットしたページごとに利用されるループ部分。
…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。
深く読み進めるためのテキスト、概観するためのテキスト †
Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。
利用者が同一サイトに集まるわけない †
投票は結局無駄になる。
閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。システムでやることではない。
「自分にとって」は2つある †
他のページを章単位で埋め込みできればいい。
自分のスペースにインポートすれば投票か †
他人のページをコピペ改変するのが投票か。
投票は自分のページと、自分が触れていないページにするもの。
コピペ元にも同時に投票される？重要な版を自動検出して代表化する。
ページセットはページの属性を表せる †
ページ属性はページセット。実装の違い。
ページ属性とページセットを同一視。
「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
更新された部分や人気の部分が章単位で表示されれば効果あり。
「自分にとって」を基本にして †
どう利用者間のコラボレーション・コミュニケーションをするか。
元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解・同名ページは無くなった。
編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。
New!が下位ページも調べるようになっていればいい。
「自分にとって」は何と結び付けるか †
- 投票…ページ名とページの結び付け
- ページセットと？（コレクション）
- 承認と？SPAMでないこと
- すべて
FederatedWikiのように。 - 自分用にできないもの
ページ名はページの一部なのでできるはず。
上位ページが下位ページに依存したりしないこと。
奥にしまう †
アクセスされていないページと付帯データは別サーバーに。
「自分にとって」を実現するために、1スペースに1人だけにすると †
携帯向けビュー †
サブページが実装されれば目次を表示するだけでいい。
目次からサブページへリンク。
スペースはページセットでコレクション †
1人でいくらでも持ちたい。
※自分のスペース内に。
実装 †
ユーザーエージェントで携帯かどうか判定。
「自分にとって」はスペース。スペースをまとめたのがWiki.
ゲストは投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース。
表・行列・セルといったものは表だけにする †
ページの機能として汎用化するには無理がある。
基本がFederationになっても、投票を伴なうピン留め操作は必要 †
これで（共有スペースでの）代表が決まる。コピペ改変も投票を伴なう。
CSS適当コンバーター †
投票はSisterWikiネットワーク内で有効 †
フォローも同様。
他のシステムのCSSを変換。
叩き台ができる程度でいい。だいたい変換。
承認時、モデレーター間で意見が分かれたら？ †
- 投票は「自分にとって」のもの
- 投票でモデレーターになれる
- 利用者によって、どのページが存在して、削除されていて、SPAMかが異なる
- この3つはページセット。承認はページを3つのページセットに振り分けるもの
過不足があるので完全に変換できるわけがない。
他のシステムとこれの両方で共通する部分だけ扱う。
基本がFederationになっても、フォローは可能か †
同名ページ→その作成者→作成者の利用者ページでフォロー可能。
フォローリストはページセット。それもSisterWikiのインポート対象。
システムによってキーワードが異なるので、入力時に何のCSSかを指定。
個別対応。
「汎用（適当）」という適当なやり方も提供。
スペースをフォローするのがSisterWiki。
Wikiは5ペイン（上、下、右、左、真ん中）までの構成で、独自の段組み（システムが用意したものでなく、利用者が独自に作った段組み）が無ければどんなスタイルでも適用できるはず。
Wikiとは独立したツール。
設定などのページにも適用 †
→派閥の中には版しか入らない。ページごとに別の派閥を作るのなら可。
管理者に見せて活用法の提案
→管理者に派閥付きのURLクエリーを送ればいい。
派閥内はSNS †
利用者名から利用者ポータルページは分からないようにして。
- メッセージはどの派閥経由か分かるように
- 派閥から抜けると縁が切れるように
匿名のままのつながりなのはこのため。
必須でないプラグイン公開はWikiEngineとは別のサイトで。 †
「公式プラグイン」と呼ばれないようにするため。
公式は必須のもののみ。
お客様向け †
外から存在しないページに来た人 †
- 検索結果で動的にページ生成。
- ページ/存在しないページ[?]に検索語をDanglingLinkとして記録。
作ってもらえるように。
同じ検索語を検出したらカウントアップ。「ページ名(2)」のように。多い順にソートすることもできるが、順位が動かなくなってしまうのでしない。検出順に。検出されるとage。 - 管理者と、管理者が認めた利用者にメール。
ページ名と検索語とそのページを作るための直リンクを。
編集支援 †
- ページ/外からの訪問が少ないページ[?]のリスト
- 同じ人による一続きのアクセスで参照されたページを一覧表に。
「同じ人」は短時間だけでも同定できればいい。
一定以上つながりのあるページはまとめて一括りに。
対象期間の長さごとに別の表に。
対象期間は現在から過去1日、過去1週間…などのほか、ある日付から前後1週間、前後1カ月なども。
追記するとき †
Wikiに追記するとき…
この繰り返し部分を減らすには？
毎日ダンプ †
毎日ダンプファイル作成、特定ページの添付ファイルに追加。
そのページにリンクを作成。
いつでも作成できる最新版ダンプファイルは要パスワード。
（処理が重そうなので。重くならなければパスワード不要）
毎日というのが更新間隔に合わないかも。
それなら前回ダンプファイル作成から数えて最初の更新後、6時間経ったらダンプファイル作成などに。
発想の入り口、経路を振り返るには †
アイデアノートとしてのWikiでは思考の一時記憶として使えないと。
発想の入り口を作るには †
発想の順番が分かる履歴を †
残して、何かを考えながら思考経路を見るには…
「考えの履歴」
ページ名（キーワード）とタグは同等の機能を持つ †
タグ集め、ページ名（キーワード）集め。
閲覧、編集で追加したタグやキーワードを一覧化、
考えの経緯が分かるように。
自分が関わったタグ・キーワードだけでタグクラウド作成。
これを任意の期間だけに絞り込んで表示、集計、表示。
- -------------------------------------
発送の入り口、経緯が自分で確認出来るように。次の発想が出来るように。
プラグインを実行時に取得 †
プラグインをUIからのシステム呼び出し時に取得したい。
管理者がプラグインのURIを入力して。
システムがプラグインを取得、インストール。
アンインストールは…
プラグインと同じ著作者のファイルだけ消す。
他のプラグインでも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。
URIで示された場所に置くもの †
- プログラム他、インストールするもの
- 必要なもの（他者が作ったもの）
- インストールの仕方、形式的な書式
URI集を特定のサイトで作り、RSS化。
各Wikiで定期的に取得。
管理者用の機能。
ショートカットキーやHTML内のIDを重複させないため †
テスト（重複テスト）というメソッドを用意。
呼び出し順 †
| → | ページD（中） |
処理順 †
例。
- Aを呼び出す
- Bを呼び出す
- Cを呼び出し、テスト…OK
- Dを呼び出し、テスト…OK
- Bのテスト…NG
- AのテストはNG
（下位にあるBのテストがNGなので） - 結果…NG（AのテストがNGなので。それ以外のテスト結果は考慮しない）
テストでは下位の全IDの中に自身が持つIDが有るか調べる。
が、下位のテストがNGならそれだけでNGにしていい。結果は変わらない。
下位の全ID・ショートカット定義を扱う。
戻り値はOK/NGの区別と、下位と自身の全ID・ショートカット定義
実装ではID・ショートカット定義の他にも類するものがあっても追加できるように。
コラボレーションツール †
他人以外にも過去の自分や未来の自分とも。
忘れたこともすぐ再開できるツールに。
思考の道筋をリンクの道筋として記録できるようなツールに。
読み上げしやすいRSSフィード †
句読点を適切に。
強調は（記号ではなく）言葉で。
編集者用メニューにdiffを †
編集者の場合によく使うメニュー
同じページを毎日チェックするとか、
書くとか、書く前に検索、編集するか新規作成か考えるためのメニュー。
アクセスキーはユーザー設定 †
外に出さない書き込み †
議論中の書き込み、不確定な書き込み、暴言は外に出したくない。
でも内部には公開したい。
Wikiなので、そのうち暴言は消される。
残るならそれがそのWikiでの結論。
→それなら追加された（更新された）部分はしばらく外に出さないだけでいい。
- 外
- Google、アンテナなど。
外に出さないものは拒否を表明しておくだけ。
別ページにしないと、更新された部分だけ分けることができない。
→外には古い版を出せばいい。
- ---------------------------------------------------------
つまり、不適切な書き込みをネットに広めないように…
…ということ。
編集ページは可変長 †
テキストエリアのスクロールバーを出さないように。
代わりにページのスクロールバーを使う。
interInclude †
{{}}で、他のページを埋め込み。
その時、外部サイトも指定できるように。
新規ページ作成時、ページを作ってから入力受け付け †
通常では「ページ作成」（またはDanglingLinkを使用）→更新をして作成されるページ。
これをページ作成で作成するようにする。（で、既存ページを更新することに）
作成されるページ内容はWikiの定義による。
「ページ新規作成時のテンプレート」というページで定義。
DanglingLinkをクリックするだけでページが作られる。