思い付きのバックアップの現在との差分(No.250)

新しいページを作るきっかけなので、「新規ページ作成」ボタンの前に利用者に見せたい。
新規作成のページで表示するのもいい。ページ名を統一するために。似ているページ名を探すのに役立つ。
独立したページにすべき。
活用しやすくするため。1ページが1つのDBテーブルのようなもの。
頻出語のリストには、最後に発見された*1日付も。
データを活用するために。
→機能/テンプレート生成[?]

深く読み進めるためのテキスト、概観するためのテキスト †

Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。
閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。→システムでやることではない。

-----

他のページを章単位で埋め込みできればいい。
「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
更新された部分や人気の部分が章単位で表示されれば効果あり。

-----

編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。
New!が下位ページも調べるようになっていればいい。
上位ページが下位ページに依存したりしないこと。

概観のための体裁 †

テキストを再編、再レイアウトして。
見出し以外のフォントを小さくすれば情報の密度も分かる。
見出しを読めるようにすること。

リクエスト、ログ読み（未読） †

人気ページは「充実させてほしい」というリクエストの表れ。
編集者が自分が編集するペースで（というか、前回アクセスから今までの期間で）人気のあるページを調べられれば、
「次に編集すべきページ」「期待されているページ」というものが分かる。
掲示板での「ログ読み」「未読」をWikiでやるならば、前回アクセス以降の差分（全ページ分）閲覧と、前回アクセス以降の人気ページを知ることになるのでは。

奥にしまう †

アクセスされていないページと付帯データは別サーバーに。

携帯向けビュー †

サブページが実装されれば目次を表示するだけでいい。
目次からサブページへリンク。

実装 †

ユーザーエージェントで携帯かどうか判定。

携帯向けのビューでは圧縮 †

gzip圧縮
イメージリソースを公式サイトに置いて、クライアント側キャッシュを共有
その他静的リソースを別サイトに置いて、クライアントにクッキーの送信を要求しないように

表・行列・セルといったものは表だけにする †

ページの機能として汎用化するには無理がある。

CSS適当コンバーター †

他のシステムのCSSを変換。
叩き台ができる程度でいい。だいたい変換。
過不足があるので完全に変換できるわけがない。
他のシステムとこれの両方で共通する部分だけ扱う。
システムによってキーワードが異なるので、入力時に何のCSSかを指定。
個別対応。
「汎用（適当）」という適当なやり方も提供。
Wikiは5ペイン（上、下、右、左、真ん中）までの構成で、独自の段組み（システムが用意したものでなく、利用者が独自に作った段組み）が無ければどんなスタイルでも適用できるはず。
Wikiとは独立したツール。

設定などのページにも適用 †

~~一般利用者が派閥を独立した1つのWikiとして改良、自分たちなりのシステムを作って自分たちで利用できる。~~
→派閥の中には版しか入らない。ページごとに別の派閥を作るのなら可。
管理者に見せて活用法の提案
→管理者に派閥付きのURLクエリーを送ればいい。

派閥内はSNS †

利用者名から利用者ポータルページは分からないようにして。

メッセージを相手のポータルページに送ったり
相手を検索で探せるようになったり
友達申請して相手の名前を自分のポータルページ内で上位にしたり
(同じ派閥の利用者はもともと表示されている)

メッセージはどの派閥経由か分かるように
派閥から抜けると縁が切れるように
匿名のままのつながりなのはこのため。

必須でない機能公開はWikiEngineとは別のサイトで。 †

「公式機能」と呼ばれないようにするため。
公式は必須のもののみ。

お客様向け †

外から存在しないページに来た人 †

検索結果で動的にページ生成。
ページ/存在しないページ[?]に検索語をDanglingLinkとして記録。
作ってもらえるように。
同じ検索語を検出したらカウントアップ。「ページ名(2)」のように。多い順にソートすることもできるが、順位が動かなくなってしまうのでしない。検出順に。検出されるとage。
管理者と、管理者が認めた利用者にメール。
ページ名と検索語とそのページを作るための直リンクを。

編集支援 †

ページ/外からの訪問が少ないページ[?]のリスト
同じ人による一続きのアクセスで参照されたページを一覧表に。
「同じ人」は短時間だけでも同定できればいい。
一定以上つながりのあるページはまとめて一括りに。
対象期間の長さごとに別の表に。
対象期間は現在から過去1日、過去1週間…などのほか、ある日付から前後1週間、前後1カ月なども。

追記するとき †

Wikiに追記するとき…

検索する
繰り返す
1. 検索結果から追加位置を探す
2. それっぽいページを開く
追記する

この繰り返し部分を減らすには？

検索結果にページ内容を併記
編集ボタンも。

毎日ダンプ †

毎日ダンプファイル作成、特定ページの添付ファイルに追加。
そのページにリンクを作成。
いつでも作成できる最新版ダンプファイルは要パスワード。
（処理が重そうなので。重くならなければパスワード不要）
毎日というのが更新間隔に合わないかも。
それなら前回ダンプファイル作成から数えて最初の更新後、6時間経ったらダンプファイル作成などに。

発想の入り口、経路を振り返るには †

アイデアノートとしてのWikiでは思考の一時記憶として使えないと。

発想の入り口を作るには †

発想の順番が分かる履歴を †

残して、何かを考えながら思考経路を見るには…
「考えの履歴」

発想支援は利用者の学習を助けるだけ †

発想はすべて利用者の頭の中で生まれる。
それを支援するには利用者の学習を助けるだけ。

ページ名（キーワード）とタグは同等の機能を持つ †

タグ集め、ページ名（キーワード）集め。
閲覧、編集で追加したタグやキーワードを一覧化、
考えの経緯が分かるように。
自分が関わったタグ・キーワードだけでタグクラウド作成。
これを任意の期間だけに絞り込んで表示、集計、表示。

-------------------------------------

発送の入り口、経緯が自分で確認出来るように。次の発想が出来るように。

機能を実行時に取得 †

機能をUIからのシステム呼び出し時に取得したい。
管理者が機能のURIを入力して。
システムが機能を取得、インストール。
アンインストールは…
機能と同じ著作者のファイルだけ消す。
他の機能でも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。

URIで示された場所に置くもの †

プログラム他、インストールするもの
必要なもの（他者が作ったもの）
インストールの仕方、形式的な書式

URI集を特定のサイトで作り、RSS化。
各Wikiで定期的に取得。
管理者用の機能。

ショートカットキーやHTML内のIDを重複させないため †

テスト（重複テスト）というメソッドを用意。

呼び出し順 †

ページA（外）

→

ページB（中）

→

ページC（中）

→

ページD（中）

処理順 †

例。

Aを呼び出す
Bを呼び出す
1. Cを呼び出し、テスト…OK
2. Dを呼び出し、テスト…OK
Bのテスト…NG
AのテストはNG
（下位にあるBのテストがNGなので）
結果…NG（AのテストがNGなので。それ以外のテスト結果は考慮しない）

テストでは下位の全IDの中に自身が持つIDが有るか調べる。
が、下位のテストがNGならそれだけでNGにしていい。結果は変わらない。
下位の全ID・ショートカット定義を扱う。
戻り値はOK/NGの区別と、下位と自身の全ID・ショートカット定義
実装ではID・ショートカット定義の他にも類するものがあっても追加できるように。

コラボレーション ツール †

他人以外にも過去の自分や未来の自分とも。
忘れたこともすぐ再開できるツールに。
思考の道筋をリンクの道筋として記録できるようなツールに。

編集者用メニューにdiffを †

編集者の場合によく使うメニュー

差分(diff)
検索
編集
新規
最終更新

同じページを毎日チェックするとか、
書くとか、書く前に検索、編集するか新規作成か考えるためのメニュー。

アクセスキーはユーザー 設定 †

外に出さない書き込み †

議論中の書き込み、不確定な書き込み、暴言は外に出したくない。
でも内部には公開したい。
Wikiなので、そのうち暴言は消される。
残るならそれがそのWikiでの結論。
→それなら追加された（更新された）部分はしばらく外に出さないだけでいい。

外: Google、アンテナなど。
外に出さないものは拒否を表明しておくだけ。

別ページにしないと、更新された部分だけ分けることができない。
→外には古い版を出せばいい。

---------------------------------------------------------

つまり、不適切な書き込みをネットに広めないように…

Google、その他対応可能なボットには古い版を見せる
ボットが最新版をリクエストしてきた場合、拒否する
定着した古い版を代わりに見せる。

…ということ。

編集 ページは可変長 †

テキストエリアのスクロールバーを出さないように。
代わりにページのスクロールバーを使う。

新規ページ作成時、ページを作ってから入力受け付け †

通常では「ページ作成」（またはDanglingLinkを使用）→更新をして作成されるページ。
これをページ作成で作成するようにする。（で、既存ページを更新することに）
作成されるページ内容はWikiの定義による。
「ページ新規作成時のテンプレート」というページで定義。
DanglingLinkをクリックするだけでページが作られる。

引用にはタイトルを †

1行目または最後の行にタイトルを書けるように。

iPhoneではランドスケープ時のみ2カラム表示 †

リンクにスクリーンショットを †

機能。
リンクにはてなスクリーンショットを付ける。
ブラウザー側でこの機能が有効なページでリンクにスクリーンショットを付ける拡張を。

画像の差分表示 †

画像ファイル（ページ）の差分を枠で強調。
絵よりも図の変更のために。

Microsoft/web (Microsoft Web UIのサイト)へ登録 †

ASP.NETなら登録先にMicrosoft/webもある。

索引 †

ページ内の索引と、サイト内の索引、他の単位も？
単語抽出が要るが本当の単語でなくていい。文字種区切りで可。
リンクを集めるだけでいい。
wiki内の単語・語彙とはページ名だから。

対象範囲 †

…など。
どう設計するか。
→どれもページ。wikiはルートページ、サブページなしのページはサブページを持たないページのこと。

©をページごとに用意 †

コピー可能。
そのまま別のページに貼り付け。追加できるように。
章の統合などでも©を継承できるように。

似ているページや追加位置を気にしない †

適当にぶっこむこともあるので、そのあとでまとめられるほうがいい。

自動生成ページは隠す †

自動生成ページは検索の対象外。特に指定されていなければ。
PukiWikiでの:始まりのように。
「:AutoGen/…」のように。

タグの継承 †

タグはページが持つ属性。
タグは上位ページのタグを弱く引き継ぐ。

連続する機能はつながる †

同じ機能、記法を続けるとつながる。
行単位の引用「>」や、段落単位の引用「>>…<<」など。

機能の対象範囲 †

ページ
段落
空行間。
行
改行間。
文字列

Wiki全体がページ一つなので、ページより大きい単位は無い。

-------

それぞれの表記方法（例）

ページ
ページのどこに書いてもいい。
先に書いたほうが優先されるので、通常は先頭に。あるいは特別な領域へ。
段落
段落の中（見やすくするため段落始めか
段落終わりに）。一行使うか段落内の行頭か行末に。
行
行頭か行末に。行頭と行末の
両方に何か書くなら文字列指定とかわらない。
文字列
面倒。括弧でくくらなければならない。
例えば明示的なリンク。

実装を簡略化するため、文字列は改行を含まないし、行は複数行含まないし、段落は一つの段落だけ。ページも一つ、ただしサブページは含んでいい。
書く内容…

機能名（属性名）
値
記法化するような機能では必要ないはず。
対象
ページ、段落、行、文字列

バックアップダンプをメール送信 †

携帯などからでもバックアップできるように。
トリガーをメール受信にできればなおいい。
送信先は管理者設定か、リクエストメールの送信者に。

WAI-ARIA †

履歴→記録 †

履歴・バックアップは記録。パーマリンク付き。
Google検索の下位に出したいが、それができないなら出さなくてもいい。

見解の仕組みをwiki間でもできたら？ †

InterWikiNameがインターネット内の代表ページにつながる。
他のWikiEngineを仲間に入れるには？片方向リンクでもいい。
餅は餅屋のwikiで。

編集の衝突 †

一般的ではないので、「古いバージョンを更新してしまったようです」のように。
お互いの元バージョンと変更後バージョンを示して、ユーザー自身と他のユーザーがそれぞれ何をしたのかを説明。
でも編集箇所が異なれば衝突とはしないことに。

NintehdoDSブラウザー対応 †

UserAgent別のビューで。

URIの#! †

http://code.google.com/intl/ja-JP/web/ajaxcrawling/docs/html-snapshot.html
HTML Snapshot を適切に作る方法

保管してあるアイデアはアップデートしない限り役に立たない †

いつのアイデアか分かるように。
→差分表示で日付を含めて「追加」「削除」を表示。
発想→保管→更新や追加や集約→保管→更新→活用。
更新すること（古い内容や正しいことを確認すること）が必要。
更新にかかる時間、手間を少なくするには？
→開いたときに関連情報が集まっている…KJ法の途中のような。
いつのアイデアか分かるように。
→差分表示は複数差分をまとめて。履歴を範囲指定で、ここからここまで。
現在の版も含めて履歴表示。そうすれば「現在との比較」というリンクが要らなくなる。
表示は…

+:32行め:2010/10/10: 1行分の内容…

…のように、日付を含める。

日付記法とカレンダー †

日付(WikiNotaion)を書くとタグのような扱いに。タグクラウドの対象外。
日付ページへのリンクになり、日付リンクのツールチップにはその日の一行日記が表示されるように。→リンク/ツールチップ[?]の仕組みとツールチップに何を書くかで。
日付リンクを集めたページがカレンダー。
静的なページでもいい。リンクが存在する月ごとに表示や生成をする動的（な機能を含む）ページでもいい。
版の更新コメントを一覧化するためのもの。
サイト全体に渡る更新が書きやすくなる。
ページごとに書くこともあるので、版の更新コメント欄もあっていい。

何やってたんだっけリスト †

パンくずリスト。迷っても通った道順通りにリストアップ。
ルートからの最短経路になるトピックパスとは違う。

ブラウザーのウィンドウタイトルに検索語を付けたら便利？ †

ブックマークのために。

「…」から（ページタイトル）

外部（Googleなど）からの検索語も同様に。
URLのクエリー部分違いはタイトルを変えるかということ。
ページの見た目に関わるなら変えるべき。検索語強調付きのときなど。

一覧できる表示方法、タイリング、リスト †

マイページでウォッチ範囲の新着（範囲か条件で指定）表示に。
レイアウト変更
ズーム（絵や動画の）

分派は多数派も少数派も守る †

少数派は多数派から攻撃されなくなる
多数派は？
→同じ。

永続セッション †

パスワードなしで使えるセッション領域
セッションIDがずっと有効。

もう1つのセッションが一時セッション。
時限式ID、それを過ぎると変わる。
ユーザーアカウント1つあたり。それぞれ永続と一時のIDを持つ。
常に1つ（×2）持つ。（初めてセッションを作るまでの間を除いて常に）

フレームワークからdump呼び出し †

そのきっかけは普段コメントアウトされている行や、ユーザーからのdumpコマンド実行リクエストでいい。

少数派の猶予 †

支持票が無くてもページが消えたりしない。
支持されてなくでも多数のページを作って体系化する。それくらいできるように。
後になって支持されるかも知れない。

派閥は統合なし、分けるだけ †

コウモリはあり得なくなる。
統合するなら他の派閥を参考にして、自分のところを充実させることで実現。

編集できない派閥（のページ）を編集すると分派 †

別派閥作成+テンプレートとして元のページ使用。

禁止ではない
エラーメッセージ「編集できません」でもない

OpenIDがあるのだから利用者の同定を当てにしていいのでは？ †

1人1アカウントになるように。
それとアカウント持ちに便利なようにして。
これで

1人1アカウント
使い回せる
便利。作ることが面倒でない…騙れない

…といったことが実現できそう。
アカウントを持っているのにゲスト利用…は非公開利用、隠れて利用ということになる。
→認める。
ホワイトリストと組み合わせたOpenIDならWikiに合うアカウントとして使えそう。
OpenIDプロバイダーのホワイトリスト。

OpenIDとOAuth †

1つのOpenID、OAuth アカウントでログイン後、他のアカウントを認証すれば統合。
複数の外部アカウントを1つの内部アカウントにできるように。

支持票は複数入れていい †

~~別派閥のページに複数の支持票を入れられる。複数の不支持票も。~~
~~こうすればコウモリはどっち付かずではなく八方美人ということになる。~~
~~→無害になる。~~

自分にとって都合のいいページだけを見せてくれるのが代表の仕組み †

これがゲストの場合…Wikipediaが目指しているような公に認められたページになる。
これはGoogleでもやっていること。
（ユーザーの検索履歴が反映されるようにページの順位を変えている）
カスタマイズがフォークソノミーになる仕組み。
見たいものを上位に。見たくないものを下位に。

派閥はデフォルト値が同じ人たちの集まり †

制限を課すようなものではない。
例えば代表の初期値（初期の代表、何も判断材料が無いときの代表）に同じ派閥の人を参照する。

自分のサイトへトラックバック送信 †

自分の日記のために。活動記録のために。各サイトのTwitter 連携のようなもの。
自分のアカウント→トラックバック先を設定しておく必要がある。（利用者設定）

内容付きページ一覧 †

特に短いページが多いときに。
検索結果でも。
検索結果は検索キーワード付近を横断的に表示するもの。
文字数で数えて近いテキストのほか、別の尺度で近いテキストも表示できれば…？

カラムブラウザー †

iTunesのファセット分類と検索システム。テーブルの列ごとにまとめ。選ぶと選択した列に選択したのと同じ値を持つ行だけ表示。
これをWikiとページに適用すると…列→「タグ」、値→付けられたタグ。
ページは非定型、フリーフォーマットなので列にあたるものがタグくらいしかない。
見出しなどは重複することがないのでまとめにならない。

検索キーワードの前後の単語
作成年、最終更新年、年と月、年と四半期、半期
最終編集者
上位ページ、上位にあるいずれかのページ

日付には「199X年」「90年代」という指定もしたい。（日付記法次第）

「フォームを再送信しますか」 †

フォームの送信をしたページをブラウザーの履歴に入れない方法はあるか。

派閥内はSNS †

利用者名から利用者ポータルページは分からないようにして。

メッセージを相手のポータルページに送ったり
相手を検索で探せるようになったり
友達申請して相手の名前を自分のポータルページ内で上位にしたり
(同じ派閥の利用者はもともと表示されている)

メッセージはどの派閥経由か分かるように
派閥から抜けると縁が切れるように
匿名のままのつながりなのはこのため。

ダンプで一括置き換え可能に †

ダンプで単一テキストファイル化できれば、DB操作で一括置き換えなどできなくていい。
テキストエディターで一括・逐次処理の両方で置き換え可能になる。

バックリンク(BackLink)の一覧 †

バックリンク一覧、ページあたりのバックリンク数付きで、テキスト解析。
「予定」のバックリンク一覧なら忙しい日が濃い色で表示されるスケジュール表。
「重要」や「※」ならページの重要度。
タグを対象にすると厳密になる。
体裁をカレンダーにしたり。
数を色にマッピングするならリストよりテーブル形式で背景を塗りつぶすような形に。

アンケートは自分のページに回答を書く †

ダンプにはindex.htmlを †

ダンプファイルには一覧をつける。
HTMLで。index.htmlで。

書き込みできるかをwiki全体で表示 †

ヘッダーで見せればいい。

Twitterから †

＠pmint_name はてなレットを参考に
ページ内にクライアントサイドスクリプトを埋め込めたら？→ページ/HTML書き込み
@pmint_name →ページ/編集/HTML書き込み
＠pmint_name フィードバックはリツイートにするか、全文引用にするか。TLに出さないか、出すか。
@pmint_name 全文引用か、RT+リプライにしないとダメか。
@pmint_name あとリプライ後すぐ消すとか。
@pmint_name 引用せずにあのツイートかとわかる表現でリプライするには…一部だけ/ツイート数だけ/何分前のツイートかだけ…
@pmint_name RSSと同等の情報をTwitterに載せないとRTの意味がないよね。
＠pmint_name ☆。コレクション用。付けるとそのページをコレクション。
@pmint_name 検索を可能に。文字列でstarred:～とか。
@pmint_name Twitterでの言及も☆にして、☆と同じ扱いに。ポイントするとツイート表示、クリックでTwitterへ。ツイートがトラックバックのようになる。
@pmint_name ☆見せ方・付け方…ページ名横に。ページ名と常に組にして。
ページを意識したときに☆を付けられるように。
例えば、ページ名一覧、検索結果（のページ名）など。一覧は☆を外すときに使うかも。
@pmint_name 更新情報の出力先。最近更新されたページ一覧、RSSのほかTwitterの特定アカウント。OAuthでは書き込み権限要求。
@pmint_name WikiはTwitterやメールのような送りつけられる形を取り込めるようにならないか？ページ表示、フォーム表示、書いて送信は手順が多すぎる
@pmint_name 送りつけ投稿でもいい感じ（読むためよりも再編集にいい感じ）にまとめるには？
@pmint_name メールやTwitterをメーリングリスト的に使い、やりとり・流れる情報をいい感じにまとめるには？
＠pmint_name 意見の衝突、共通点がわかりやすいように。人力を利用して。返信に２文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを２文字程度で返信・意志表示できるとか。
@pmint_name 「会話」の流れも使える。

ページの追跡 †

外から存在しないページに来た時、新規作成よりもそのページはどこに行ったか追跡してくれたほうがいい。
削除されていたり追跡出来なかったら（できれば当時の）過去バージョンへ。

編集回数により変更可能範囲が増えるWiki †

Wikiは人力リソースに応じて編集できる量を変えたほうがいいので。
誰も編集しない「枯れたページ」は凍結していい。Spam対策としては凍結すべき。
機能として実装するなら、
作られた時点ではページ内容を100%変更可能、編集されずに時間が経過するにつれて一度に変更できるデータ量が0%まで変化。
リセットは権限保有者が行なう。ので、リセット要求を権限保有者に出せるように。
追記のみのコメント欄は自然凍結しないように設定したほうがいい。
サイト単位の完全な凍結は管理者が行なうほうがいい。
Wikiではなくなるので。完全凍結していないのならフロー式の投稿くらいできないと。

-------

半凍結の状態をどう表現するかは再考。
データ量か？編集可能箇所は全体？編集箇所が連続するのを禁止？誤字修正くらいはいつでもできるように？
既存データの削除は禁止？追記だけ？
すぐに編集できないとWikiWikiでなくなってしまうので、編集可能にしつつSpam対処の労力を一個人に求めないように。

ページはバラバラなもの †

ページ構成というものはない。
検索などで構成、その中を見て回る。

とりあえずぶっ込んでおけばあとでまとめられる機能 †

ぶっ込む
あとづけのページでグルーピング（グループ化）
検索でリンク作成、検索記法の結果を埋め込み、それが検索にヒットするように。
グルーピングページにさらに情報追加
関連語、関連ページへのリンク
検索で探せる
グルーピング用ページがヒットするとリンク先まで表示。
BackLinkではなく、順方向リンク。

ヘルプに機能パラメーター例 †

「バグかな？と思ったら」
公式サイトに全てのパラメーター例。無いものは追加できるように。
例から問題が分かるように。例に無い挙動をするならバグレポートへ。

学習する検索 †

正しい例と誤った例を蓄積して。

リンクを合わせるかリンク先を合わせるか †

リンクしなかったとき、リンクを合わせる以外に、リンク先を変更する手もある。

Googleドキュメントにバックアップ †

管理者のアカウントへ。複数登録、アカウント選択なども。
OAuth。
リストアは必要ない。ファイルダウンロードして、通常のリストア。

リストア実行前にバックアップ †

最終バックアップから更新されていなければ要らない。
不要なバックアップになるとしてもバックアップは作る。

ゲストはバッチ的操作不可 †

複数ページに影響する（そして完全に戻すには手間のかかる）操作は要権限。

なんでもリンクで。 †

下位ページもリンク、その他の関連もリンク。
関連名が要る？リンクの属性

検索結果から関連ページへは直接か？クリックが必要では？後付けのまとめページから実体ページを閲覧するまでのステップは？ †

置き換え機能 †

設定では他の機能より優先
これで他の機能のパラメーター固定値版記法を定義

タグ… †

Elementクラス名:値クラス名（同義と見なせる範囲ごとに付けた範囲名）
gram:0-1000
タグクリック→リスト開く、リストには0-1000などの値クラス名
それを多段対応。
gram:0-1000:0-100
リストを開かず選択すると、検索キーになる。
Elementが出力するタグはいつでもどこにでも表示可能。でも検索結果（サブセットWiki）以外で見る意味は？

検索しかないのか †

検索＋選択式でいいのでは。

KJ法で下位ページ説明 †

KJ法A型のラベルが内容を表す点、内容の集約がラベルになる点を参考に。
すべてを集めたラベルがトップページになることを説明。

ブラックリストとホワイトリスト †

ブロックにはホワイトリストも。

何かのヒント †

「迷う楽しさのあるwikiスタイル」
「もやもやWiki」

フローとストック †

フロー…板、Twitter、ブログ（日記）とコメント
ストック…ブログ（備忘録）、Wiki、HTML、ちゃんとした板
ビューの違いだけで切り替え可能。
フロー…一つのURLで新着順に複数の記事表示。そのURLで書かれたことを全て表示。
ストック…一つのURLで最新版だけ表示。最新版がそのURLの
記事全てを包含、踏襲している。
フロー…サブページ一覧と消えていくページ（消費期限付きページ）、で。
ストック…通常のWikiページ

-------

wiki ブログにするには
管理用メニューを縮小すればいい。
トップ…ブログタイトルでいい。
リロード…不要。
新規…記事を書く
一覧…記事一覧
単語検索…検索
最終更新…wiki特有＊
ヘルプ…システムの配布サイトへ、とプロフ
編集…表示中の記事を編集
凍結…表示中の記事の編集にパスワードをかける
複製…不要。コピペでいい。
名前変更…不要。編集で名前変更。または新しく作って消す。
差分…RSS、ping、wiki特有
バックアップ…wiki特有
添付…不要。編集の一部に。
編集用メニューを作れば、ブログに近づく。
閲覧メニュー、編集メニュー（閲覧メニュー含む）、管理メニュー（編集メニュー含む）
差分など、過去に遡る操作は閲覧メニュー？
つまり、ユーザーのロール分け。閲覧も編集も権限に違いなし。メニューが異なるだけ。

-----------------

メールがフロー、Wikitextがストック
メール投稿をフローとして…Wikipediaでの「ノート」。会話。提案・サジェスト。
あるページに投稿されたフローな情報は「そのページについての批評・提案」。
フローな情報の見せ方はどうするか？
Wikipediaのノートのように表ページのナビゲーション的な場所にリンクを埋め込み？

フローをストックするためのWiki †

WikiはTwitterやメールのような送りつけられる形を取り込めるようにならないか？ページ表示、フォーム表示、書いて送信は手順が多すぎる
送りつけ投稿でもいい感じ（読むためよりも再編集にいい感じ）にまとめるには？
メールやTwitterをメーリングリスト的に使い、やりとり・流れる情報をいい感じにまとめるには？
意見の衝突、共通点がわかりやすいように。人力を利用して。返信に２文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを２文字程度で返信・意志表示できるとか。

フロー投稿のまとめ（セグメント化）
同じ人から・同じページへ・同じ内容(?)
テーブル記法を使って左右に同意・異議を振り分け。一覧しやすくするとか。Twitter アカウントにもページを作って人別に一覧しやすくするとか。

編集時コメント †

特にページ削除時に必要。「なぜ」の推測材料がないので。
編集ステップを増やしたくない。
「投稿完了しましたが、よろしければコメントをどうぞ」で無視することも可能、のようなUIで。

ToDoバルーン †

ページとページ内の位置を指定して吹き出し表示。
完了したら割る。
位置は見出し（ページ）でいい。
ページ名変更に追従するように、ページ内にバルーン用データを置ければいいけど。
それをクライアント側で吹き出し化。ページヘッダーにスクリプト埋め込み。
ユーザーでなくシステムが操作するデータをページに設けるということになる。
編集者間のやりとりに。本文に重ねて見せるノート・コメント・注意書き。

カスタムヘッダー †

レスポンス時のHTTPヘッダーに受け入れできる記法、HTMLヘッダーにシステム名

Sandboxでは履歴を残さない †

「HTMLに対応付けられていた記法を、文書の構造に使った」 †

サブページごとの読み込み †

で遅い感軽減。下位が上位に依存していなければ。
速いときはサブページを埋め込んだページ生成。クライアント側はその分を通信せずすぐレンダリングできる。

下位ページ レイアウト †

下位をどう並べるか。リスト、グリッド、横幅だけ固定のグリッド、Metro風の大きさの異なるタイル、単行リスト、縦書き、縦書きサブページを横書きリストの配置に、ランダム余白のランダム配置、1文節たけの詰め込み配置

編集機能 †

サブページを複数選択して分割か、
サブページを並べ替えて切るか。
→両方。並べ替えて切るのはスマホで有利

tel:記法 †

スマホ †

スマホクライアント、Evernoteを公開するのとどう違うか。

編集→書き込みと、即時書き込み †

スタイルテーマ †

Microsoft好きテーマ
Google好きテーマ
最近のMicrosoft好きテーマ(Metro)
夜型テーマ、朝型テーマ
懐かしのWeb2.0風テーマ
Evernoteテーマ
テーマ手書き、ニコニコ動画原宿
テーマうごメモ
テーマ Zen縦書

図と自動リンク †

図中のテキストがWiki内のページに自動リンク。
クリッカブルマップ。
テキスト、その位置、図を別々に受け取れないと。
自動リンクするために図（を表すページ）の（ページ構造内での）位置を決めないといけない。

Turn off the lights †

テーマ切り換えUI。明/暗と中間の夕方があればいい。
実装はテーマ変更するようなリクエストを生成するだけ。
ブラウザーに状態保存。…だとどうテーマに反映させるか問題。スタイルテーマ自体をブラウザーに保存できないと無理。
:t/スタイル :t/テーマ :t/即時編集[?]

ページネーション †

スマホで、縦向き使用時にランドスケープ表示、で縦書きにしたら通常のスクロールでも文庫ビューアーっぽくできそう。

記録系機能 †

スクレイピング、記録
スクリプトは書いてもらって。
データ保存、グラフ作成

テーブルを追加するフォーム †

と、テーブル1行ごとに削除するボタン。と1行ごとに打ち消し線を引いてグレーアウトするボタン。その場編集で。

特定版リンクとはローカル名付きのページ名 リンク。 †

ページ属性に「HTTPSを使わせる」 †

ページ作成時、属性変更時、wiki内リンクも https:…に。

不完全なページ要求+代表拒否 †

見解名などが指定されていないとき→代表を返す
代表を返す場面で代表拒否が指定されていたら…
→ワイルドカードに当てはまるページをリスト表示

振って「とりあえずマイリスト」 †

マイリストは一時的な履歴、コレクション。
今の考えをたどるためのパンくずリスト。
ß

ページの重さ †

リファレンスカウントと含むセクションそれぞれの長さを考慮して、重要度算出、表示。
式は管理者が自由に変えていい。記法と違い他サイトから来た人のことは考えなくていい。

タブビュー †

1ページの中に複数ページ表示。リンククリック→左カラムにページ展開、遷移前のページは右側へ移動。
古い履歴が右へ右へ移っていく。
古いページからの分岐はその左側にでも展開。分岐は左側に壁を作る。壁は直接のつながりが無いことを示す。
カラムの移動、カラムを次の壁まで移動、カラムを先頭に、カラムを末尾になどの操作も。

*（ワイルドカード） †

リンクなどのシンボル名を指定できるところで*や?を使うとワイルドカード化。

ページ/*/背景色

…でページ/ヘッダー/背景色などがリンク候補になる。

*ページ

…でウェルカムページ。

…*…
*…*

…なども。
?も同じ意味。

埋め込みオブジェクトの事前レイアウト †

外部サイトのイメージなどは表示中にレイアウトされるため操作性が悪くなる。
あらかじめサイズだけでも読み込んでおいて、max-heightなどのスタイル属性でサイズを指定しておく。
スクロール方向のサイズだけでいいので、heightだけ。
サイズ情報は適当に更新。リンク切れ監視と同じタイミングで。
画像自体のキャッシュにしたほうが読み込み時間が安定していいかも。
加えてキャッシュしない（サイズを保存しない）オプションも。

自動リンク・リンクを、色分け・サイズ分け †

言葉（ページ名）を属性付け。それを色と大きさで表現。（書体でも？）
言葉の属性はどの言葉と関連しているか（ページ同士の関連具合）で決定。wikiの発展にあわせて変わってもいい。
関連度が強いのは近い色、疎遠なのが違う色になっていればいい。
基本色を利用者設定、スタイルテーマ次第にすればいい。それを元に他の色も決定。
これで文字ばかりのページをタグクラウドのような体裁にする。文字ばかりならどうレイアウトを考えても平坦になってしまうので。
読む人が気になるような言葉を強く見せたほうが、どのページにどんなことが書いてあったか印象に残りやすい。
俯瞰してページ内の言葉の傾向をつかめるのも大きい。
読まずに見るだけで分かる。

ページ一覧にダイジェスト †

あるいは本文プレビュー。
検索結果の一覧では検索にヒットしたあたり。
最近の更新一覧では編集されたあたり（の最新版のほう）。
版の履歴一覧では編集されたあたり（の新しい版のほう）。
バックリンク一覧ではリンクがあるあたり。
…など。
呼び出し側によって同じページ一覧でもダイジェストが異なる。
常に全てを用意するのは非効率なので、場合によって異なるコードを実行しないと。

権限の表示にアイコンを †

錠と鍵錠…要求する権限鍵…ユーザー側が持っている権限。ユーザーページで見せる
ページテンプレートに絵を埋め込むだけユーザーページは書き換え自由なはず。消されるかも?

コードインポート †

Git→全単語（シンボル名）1つごとにページを作るリポジトリないのファイルをインポートして、自動リンクでクロスリファレンス作成
構文解析できるなら変数、クラス、などといった分類でページまとめ
コードはコード用の記法で
インポートしたぶんとは分けて説明を入れられるようにしたい次のインポートでも説明は残るように

-------------------------------------
自動的にページを作るのなら自動的に消す方法も必要。

索引 †

自動リンク、リンクを検索

リンク対象＜・・・・それを含むページリスト

という体裁で。リンク対象はフルパスのページ名。パス内単語をどういう順番にするか？全並び順をリストするか？
で、自動リンクだとページ作らない限りリンクにならないので、 Wikipediaやはてなキーワードやニコニコ大百科にもリンク
※難しければ明示的リンクだけでも

ファセット分類 †

iTunesのような。タグで実現。
に加えて、フォーカスに関連性を付けられるように。関連性はリンクで。フォーカスをページ化すればリンク可能。
・類似
似ているフォーカスをリンク。別名。いずかを指定すると、類似フォーカスを全て指定したのと同じ効果。
・包含、包括
階層化されたタグのような。一つのフォーカスが複数を含む。上下関係があって上位を指定すると下位をすべて指定したのと同じ。下位を指定しても上位は含まない。
類似/包含はリンクの関連名で区別。関連名が不適切だとほかの目的のリンクとなる。
ファセット（型）とフォーカス（値）は定義なし。存在していれば有効。
フォーカスには日付のようなテキストではない型も入れたい。（ファセットで型指定するのではない。一つのファセットに複数の型が対応してていい）

おかえりなさいメール †

久しぶりのログインだとメール送信。メールアドレスが登録されていることを注意。
「久しぶりのログインなのでメールを送りました。このメールからでもパスワード変更、アカウント削除ができます」
パスワード変更、アカウント削除予約ができるのは…
・ログインした人
・おかえりなさいメールを見られる人
「パスワードを忘れちゃいました」リンク→IDとCAPTCHA入力でおかえりなさいメール送信。

アカウント削除予約 †

ここでできるのはアカウント削除予約、アカウントを無効化するだけ。1週間か2週間で削除。削除以降同じIDを取っても二世(Jr.)となる。削除前に同じIDは取れない。

機能/Google計算機の結果に置き換え †

いろいろフォーマット †

フォーマット名を書いて、あとは一つの囲みの中にフリーフォーマットで書いていく。
あとは自動認識でいい感じにエレメント化する。
実装は改行区切りや空白区切りで。
フォーマット変換も。選択すると再認識。ユーザーが書いたことは変えずにフォーマット名だけ変更。

紹介はマンションやホテル・旅館の紹介のように。 †

スクリーンショット、キャッチコピー、説明、トピックパス、
合間に豆知識。
Xは落ち着ける住空間を提供します。

EverWiki †

WikiEngineをまとめたWikiEngine †

FederatedWikiもまとめ。ユーザーが各自自分の環境にまとめ。

何かを書くと「で？」 †

でさらなるアイデアを促す。
というレスポンスメッセージ。
セクションのスライドショーで、一段落つくまでの文章を全画面に表示。
そこになんとかのチェックリストとかなんとか発想法に沿った質問を。

サポートはありません。 †

身近で一番頼りになる人にX専門家になってもらってください。
…という説明。

参考に †

Catch Notesのやワコムタブレット付属の円形メニューを参考に

問題追跡、提案板にアイコン風のテキスト †

「もっとひねって」「せめてボケて」「いいかね？」「いいんじゃね！」「そうなったらいいね」など。テキストで書いてテキストで表示。登録はせずに使い回し、コピペ。

"X POWERED" †

使用サイトを探せるような権利表示

見解は削除に代わる手段 †

Ui 1つのオブジェクトに複数の操作を割り当てるなら、フリック。 †

@場所名 †

ブレインストーミング †

ブレインストーミング用に、タイマー付きのコメント欄。タイマーは増加。発言してリセット。自分がどれだけの間発言していないかが分かるような。

発想の流れ †

具象に裏打ちされた抽象になる
→必要な分だけをコンパクトに考える
→→新しいアイデアを生み出すには必要なこと'だけ'集めること
→→→
局所検索、局所自動リンクをサブセットWikiで
サブセットWikiは「小さなKJ法」
グルーアイデアでつなぐ。足してまとめる、まとめるために足す
つながったら抽象化、一目で理解できる形に。

コード内のToDo †

コードインポート時にコード内のToDo:などのコメントを特別扱い。
その他にもFixMe:なども。

活用法マイメソッド †

何か思い付いたとき、何か解決したときに「何をしたか」をタグにしておく。
それを集めると自分の技、思考の道具がわかる。
有名な発想フレームワークかも知れないし、その一部かも。
既存フレームワークを基にしつつ独自部分があったり、知らないうちにカスタマイズ
してるかも。
実装
具体的には文中の「これを…すると」の部分をリンクにするだけ。「…すればいい」
とか「…してみた」なども。
本文をタグ化することで妥当なタグ付けになる。思考をタグ付け用に切り換えなくて
いい。
原文(生きている文、実用した文章)を利用するのがWikiらしくていい。

2ホップ先は共起相手 †

リンク(バックリンク含むので双方向)の2ホップ先は共起相手と同じ。
これの1ホップ先(共起の文脈)に注目。
1ホップ先をグループ、自身と2ホップ先をそのメンバーとすると、「メンバーが似て
いるグループ」をまとめられる。
まとめなくても「このページと…(グループ名)…つながりのページたち」というリス
トを「…(グループ名)…つながり」ごとに出せる。

ページなんとかと…				ページなんとかと…				ページなんとかと…

…つながりのページ

…

関心空間のようなつながり。
タイル状表示。
で、サイト中にあるすべてのページについてまとめると…似ているページ検出になる。
→これはただのリンク調査。同じリンクがあれば似ているページとなる。これを1ペー
ジだけ取り上げてできるということ。

サイト分析 †

傾向検出で。

(ページ名)と(ページ名)はよく共起している
共起…2ホップ先は共起相手
(ページ名)─(関連名)→
「(ページ名)からは(関連名)関連が多い」
─(関連名)→(ページ名)
「(ページ名)は(関連名)として見られていることが多い」

…などでwikiを分析。

これで発想支援や
さらなるまとめ支援。
日記なら自分を知る機能になる。
「…をした次の日には…しているという傾向」とか。

<<<
@場所名
ローカルストレージでオフラインWiki
ボットみたいなのはクライアントで実行
他でも検索
最後に参照したページ
よく出てくる単語（頻出語）の一覧
深く読み進めるためのテキスト、概観するためのテキスト
概観のための体裁
リクエスト、ログ読み（未読）
奥にしまう
携帯向けビュー
1. 実装
携帯向けのビューでは圧縮
表・行列・セルといったものは表だけにする
CSS適当コンバーター
設定などのページにも適用
派閥内はSNS
必須でない機能公開はWikiEngineとは別のサイトで。
お客様向け
1. 外から存在しないページに来た人
2. 編集支援
追記するとき
関連ページ
毎日ダンプ
発想の入り口、経路を振り返るには
発想の入り口を作るには
発想の順番が分かる履歴を
発想支援は利用者の学習を助けるだけ
ページ名（キーワード）とタグは同等の機能を持つ
機能を実行時に取得
1. URIで示された場所に置くもの
ショートカットキーやHTML内のIDを重複させないため
1. 呼び出し順
2. 処理順
コラボレーションツール
編集者用メニューにdiffを
アクセスキーはユーザー設定
外に出さない書き込み
編集ページは可変長
新規ページ作成時、ページを作ってから入力受け付け
引用にはタイトルを
iPhoneではランドスケープ時のみ2カラム表示
リンクにスクリーンショットを
画像の差分表示
Microsoft/web (Microsoft Web UIのサイト)へ登録
索引
対象範囲
©をページごとに用意
似ているページや追加位置を気にしない
自動生成ページは隠す
タグの継承
連続する機能はつながる
機能の対象範囲
バックアップダンプをメール送信
WAI-ARIA
履歴→記録
見解の仕組みをwiki間でもできたら？
編集の衝突
NintehdoDSブラウザー対応
URIの#!
保管してあるアイデアはアップデートしない限り役に立たない
日付記法とカレンダー
何やってたんだっけリスト
ブラウザーのウィンドウタイトルに検索語を付けたら便利？
一覧できる表示方法、タイリング、リスト
分派は多数派も少数派も守る
永続セッション
フレームワークからdump呼び出し
少数派の猶予
派閥は統合なし、分けるだけ
編集できない派閥（のページ）を編集すると分派
OpenIDがあるのだから利用者の同定を当てにしていいのでは？
OpenIDとOAuth
支持票は複数入れていい
自分にとって都合のいいページだけを見せてくれるのが代表の仕組み
派閥はデフォルト値が同じ人たちの集まり
自分のサイトへトラックバック送信
内容付きページ一覧
カラムブラウザー
「フォームを再送信しますか」
派閥内はSNS
ダンプで一括置き換え可能に
バックリンク(BackLink)の一覧
アンケートは自分のページに回答を書く
ダンプにはindex.htmlを
書き込みできるかをwiki全体で表示
Twitterから
ページの追跡
編集回数により変更可能範囲が増えるWiki
ページはバラバラなもの
とりあえずぶっ込んでおけばあとでまとめられる機能
ヘルプに機能パラメーター例
学習する検索
リンクを合わせるかリンク先を合わせるか
Googleドキュメントにバックアップ
リストア実行前にバックアップ
ゲストはバッチ的操作不可
なんでもリンクで。
検索結果から関連ページへは直接か？クリックが必要では？後付けのまとめページから実体ページを閲覧するまでのステップは？
置き換え機能
タグ…
検索しかないのか
KJ法で下位ページ説明
ブラックリストとホワイトリスト
何かのヒント
フローとストック
1. フローをストックするためのWiki
編集時コメント
ToDoバルーン
カスタムヘッダー
Sandboxでは履歴を残さない
「HTMLに対応付けられていた記法を、文書の構造に使った」
サブページごとの読み込み
下位ページレイアウト
編集機能
tel:記法
スマホ
編集→書き込みと、即時書き込み
スタイルテーマ
図と自動リンク
Turn off the lights
最近の入力
ページネーション
記録系機能
テーブルを追加するフォーム
特定版リンクとはローカル名付きのページ名リンク。
ページ属性に「HTTPSを使わせる」
不完全なページ要求+代表拒否
振って「とりあえずマイリスト」
ページの重さ
タブビュー
*（ワイルドカード）
埋め込みオブジェクトの事前レイアウト
自動リンク・リンクを、色分け・サイズ分け
ページ一覧にダイジェスト
権限の表示にアイコンを
コードインポート
索引
ファセット分類
おかえりなさいメール
アカウント削除予約
機能/Google計算機の結果に置き換え
いろいろフォーマット
紹介はマンションやホテル・旅館の紹介のように。
EverWiki
WikiEngineをまとめたWikiEngine
何かを書くと「で？」
サポートはありません。
参考に
問題追跡、提案板にアイコン風のテキスト
"X POWERED"
見解は削除に代わる手段
Ui 1つのオブジェクトに複数の操作を割り当てるなら、フリック。
@場所名
ブレインストーミング
発想の流れ
おすすめ検索キーワード
コード内のToDo
活用法マイメソッド
2ホップ先は共起相手
サイト分析
スタイルテーマはROM専のため
UI クライアントビュー上で切り換えたいもの
UI ツイートボタンやいいね！はまとめて
1. リンクやバックリンクの数が少ないページ／多いページをどう探すか？
2. 検索で「ブログ」と「ログ」を分けたい
3. 曖昧検索のルールで自動リンク
UI モバイル用UI
1. ページ一覧で含まれる数字を全部集計
検索
プラグイン内でプラグインを呼び出すために
1. 「要出典」は指摘・抗議
インデックス不可能な語をインデックス可能にするには
①・②・③に順序を持たせる
1. 上位ページでは下位にあるコメントも見える
見解統合はページの削除と投票×2
1. 見出し無しはルートページを指す
バックリンクをまとめたページ
1. 検索結果の定義は特定名のページで
1つ支持すれば他の派閥は不支持になるか
1. 利用者が同一サイトに集まるわけない
2. 「自分にとって」は2つある
3. 自分のスペースにインポートすれば投票か
支持を変えて他の派閥に負担をかける攻撃
1. ページセットはページの属性を表せる
「はてなの人力質問で"Wiki"をウォッチしています」という表明
文字列からの型変換はExcelでもやっている
1. 「自分にとって」を基本にして
CSVファイル取り込みは添付ファイル化
検索クエリーは式とページ内容のobj化
1. 「自分にとって」は何と結び付けるか
まとめる作業をしているときに新発想がある
1. 「自分にとって」を実現するために、1スペースに1人だけにすると
まとめる作業
1. スペースはページセットでコレクション
まとめる作業支援
「と関係のある」という検索式
ページ名変更をリンクに反映
1. 基本がFederationになっても、投票を伴なうピン留め操作は必要
プレビューはボタンにしない
1. 投票はSisterWikiネットワーク内で有効
2. 承認時、モデレーター間で意見が分かれたら？
注釈(note)はセクションを越えない
1. 基本がFederationになっても、フォローは可能か
関連情報にAmazonなどの商品も
外部リンクにfavicon併記
インデント

スタイルテーマはROM専のため †

スタイルテーマは読む側のもの。
書く側にとってはテーマがなんであっても普通のwiki。
編集が不自由なwikiならスタイルテーマの意味が強くなる。

UI クライアント ビュー上で切り換えたいもの †

明暗テーマ切り替え
時間帯で変わるテーマを使っていれば不要。
タッチ用／モバイル／PCのビュー切り替え
引き出し表示／非表示
クリップボードとか、メニューとか、ログイン名とかの表示。

UI ツイートボタンやいいね！はまとめて †

外部サイトにあるボタンはコンテナーに入れて、一度に表示させたい。
レイアウトが何度もやり直しになるのは見づらいので。
内容によるテーブルサイズ決定と同じ問題。

リンクやバックリンクの数が少ないページ／多いページをどう探すか？ †

→ 量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。
外部サイトが提供するコードをそのまま貼れるコンテナー。
ページを読み込んで、読み込みの進捗表示が終わってからコンテナー内を読み込みた
い。
ここは遅くてかまわない。本当に遅延していい遅延ロード。

検索で「ブログ」と「ログ」を分けたい †

「ログ」を検索したときに「ブログ」を見つけないように。逆に見つけたいときもある。

曖昧検索のルールで自動リンク †

UI モバイル用UI †

下部にボタン用パネル。
ボタン区切りに溝を設ける。溝は切り抜き。隙間からページが見えるように。
これで画面を広く見せる。溝がなければ画面が小さく感じる。
曖昧検索と自動リンクを統合。
それと画面隅に三角形のボタンを配置するとか。
ページがめくれてる感じにするとか。
例えば、自動リンクするとき、ページ名やリンク対象に含まれるひらがなを無視して自動リンク。
ページ本文中の「読みやすい書き込」が「読みなれた書込」のページに自動リンクする。逆も起きる。
サイドメニューバーは引き出しにするとか。タップやドラッグインには無反応、画面
端からのドラッグだけに反応。
曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ（入口リンクはあるけど実在しないページのメタページ）から「読みなれた書込み」にリンク。類似したリンク先もそばにある。

ページ一覧で含まれる数字を全部集計 †

ページ一覧や下位展開、コレクション（サブセットWiki）など、複数のページを扱うページでは、含まれるページに書かれている数字を集計。数値類の記法がラベルを受け入れるなら、ラベル別に集計。
ファセットナビゲーションの集計版。ページ要素を集める点は似ている。

検索 †

~~(ページ|クエリー)の内部をobj化~~
~~WikiFormatと同じ処理~~
~~クエリー←ページ~~
~~クエリーに適合したか？~~
~~または適合率を尋ねる。内部のobjを1つずつ突き合わせる。適合したページだけ得るのがフィルタリング。得たページに順序付けするのがソート。~~
→:集計

プラグイン内でプラグインを呼び出すために †

~~WikiTextを作って、それをWikiEngineで処理。HTMLやXMLを得たりできるように。~~
%%利用方法→開発方法が分かりやすいようにするためにWikiTextを使う。UI(記法)が
APIになる。%%
→To...を呼べばいい。URLパラメーターを条件にしていろいろ判断するような処理は
Action(インスタンス生成後の処理)でやることにして、To...は引数だけに依存する
ようにプラグインを作ってもらって。

「要出典」は指摘・抗議 †

「要出典」はコメントとは別の形の抗議。

インデックス不可能な語をインデックス可能にするには †

量をインデックス化するには値1つと誤差の2パラメーターで指定。インデックスなの
で広く指定できれば十分。
でも同値(100%)だけでなく0%以外をすべてインデックスにするので、インデックス化
自体が無意味。
ページ要素プラグインにインデックス項目生成をさせるなら、列挙可能な場合だけで。
列挙不可能な場合は*。どんな検索でもそのページが評価されるように。

①・②・③に順序を持たせる †

数字記法に囲み数字を含める。

上位ページでは下位にあるコメントも見える †

コメント（スレッドモード）だけをつなげて並べる必要は無い。下位展開で各ページにコメントがあればいい。

見解統合はページの削除と投票×2 †

%%元仲間には空のページかほかに指示しているページが表示されることになる。アナ
ウンス。%%
~~復帰に手間がかかるので、何度も繰り返されると困る。~~
~~→投票を取り消すにはコストがかかるように。それか不可能にするか。~~
→不要。

見出し無しはルートページを指す †

見出しよりも先に書かれたテキストは、名前の無いページ（ルートページ）の本文に追記することになる。同名ページは1人ひとつまでなので、同名ページ作成にはならない。

バックリンクをまとめたページ †

外からの被リンクを

リンク先(Wiki内)ページごと
リンク元(外)のサイトごと
まとめ方はリンクのtarget属性と一緒でいい。

…にまとめたページ。
探索のために。

検索結果の定義は特定名のページで †

その下位ページは、ヒットしたページごとに利用されるループ部分。
…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。
→ルートを始めとする上位ページが下位ページの集約…という考え方はもうない。や
るならページごとの集計になる。

1つ支持すれば他の派閥は不支持になるか †

全て支持したほうが得。支持さえしていれば相手を編集するのも自由。なので。

利用者が同一サイトに集まるわけない †

投票は結局無駄になる。
~~全て不支持はできる。→支持1つまで。ほかは考えないということ。~~
~~分派すれば支持を入れ直せる。が既存のものを支持できない。~~

「自分にとって」は2つある †

投票…ページと名前の対応付け
承認…SPAM、削除済み、デフォルトの3ページセットにページを振り分け

→支持に制限はない。支持はサイトが見やすくなるだけのもの。制限をかけないこと
で無理をなくす。

自分のスペースにインポートすれば投票か †

他人のページをコピペ改変するのが投票か。
投票は自分のページと、自分が触れていないページにするもの。
コピペ元にも同時に投票される？重要な版を自動検出して代表化する。

支持を変えて他の派閥に負担をかける攻撃 †

防ぐには、支持に制限、支持の意味を小さくする、

ページセットはページの属性を表せる †

ページ属性はページセット。実装の違い。
ページ属性とページセットを同一視。

「はてなの人力質問で"Wiki"をウォッチしています」という表明 †

「ご意見があるときはTwitterでwikiと書いてくださいね！全リプします！」という表明

文字列からの型変換はExcelでもやっている †

日付・曜日の認識とか、金額の数値化とか。

「自分にとって」を基本にして †

どう利用者間のコラボレーション・コミュニケーションをするか。
元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解・同名ページは無くなった。

CSVファイル取り込みは添付ファイル化 †

テーブル記法ではなく。
でも添付ファイルを埋め込みするとテーブル要素のHTML変換機能を利用するように。
記法を介す必要なし。

検索クエリーは式とページ内容のobj化 †

~~フォーマッティング、フィルタリング、スコアリング~~
~~フォーマット→フィルタリング→クエリー→スコアリング~~

「自分にとって」は何と結び付けるか †

投票…ページ名とページの結び付け
ページセットと？（コレクション）
承認と？SPAMでないこと
すべて
FederatedWikiのように。
自分用にできないもの
ページ名はページの一部なのでできるはず。

→検索クエリーもページ。

まとめる作業をしているときに新発想がある †

自然にまとまるよりも、まとめる作業のほうが大事かも。
まとめる作業は知識の反芻、再学習。システムがやると発想に必要な入力がなくなっ
てしまう。

「自分にとって」を実現するために、1スペースに1人だけにすると †

投票はどうなるか
利用者ページや権限（鍵／錠）は？

まとめ作業中は情報を集めた人自身が閲覧者になる。閲覧者は投稿者以上に情報をつ
なぐ役目を持っているので、それを投稿せずに投稿できるようじゃないと。
獣道

まとめる作業 †

まとめる作業は
検索(ざっくりと)、さらに検索(小分類の中を)、細分化、読む、書き直す、加える、
ここでも検索と分類と細分化。
KJ法的に適当なメモを探す。

スペースはページセットでコレクション †

1人でいくらでも持ちたい。
※自分のスペース内に。

まとめる作業支援 †

まとめ支援は検索と人力。
そのための支援。
メモ書きをするような。
欲しいデータが手に入るような。0ステップか、ほかの作業中に手に入るような。
「自分にとって」はスペース。スペースをまとめたのがWiki.
ゲストは投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース。

「と関係のある」という検索式 †

ページ名変更をリンクに反映 †

ページ名変更をリンクに反映。ページ名変更はリンク変更までの承認を含むとして。

基本がFederationになっても、投票を伴なうピン留め操作は必要 †

これで（共有スペースでの）代表が決まる。コピペ改変も投票を伴なう。

プレビューはボタンにしない †

プレビューするならニコニコ大百科のようにチェックボックスにする。
紛らわしいのでボタンにはしない。

投票はSisterWikiネットワーク内で有効 †

フォローも同様。
チェックはオプトアウト。でもよく編集する人向けに利用者設定でオプトインにもできるように。
チェックボックス自体を無効化したりはしない。

承認時、モデレーター間で意見が分かれたら？ †

投票は「自分にとって」のもの
投票でモデレーターになれる
利用者によって、どのページが存在して、削除されていて、SPAMかが異なる
- 投票によって、ページ名とページの対応付けも異なる
この3つはページセット。承認はページを3つのページセットに振り分けるもの

注釈(note)はセクションを越えない †

ページ末尾に置くと遠すぎるので。
同じ見出しの最後に表示。

基本がFederationになっても、フォローは可能か †

同名ページ→その作成者→作成者の利用者ページでフォロー可能。
フォローリストはページセット。それもSisterWikiのインポート対象。

外部リンクにfavicon併記 †

apple-touch-icon.pngがあればそれを優先。
apple-touch-icon-precomposed.pngがあればさらに優先。
スクリーンショットが使えるならさらに優先。でもできればスクショにアイコンを重ねて表示。スクリーンショットの枠やドロップシャドウにはアイコンのキーカラーを使いたい。

インデント †

行頭の空白類は無視したい。
特に全半角スペースとタブ文字を。
WikiTextのままでも読みやすくするためにインデントできる。
改行文字も無視できればより読みやすくできるが…。行頭空白の連続+改行文字を無視するのならできそう。
それよりもテキストエリアの行間を広げられればそちらのほうがいい。

<<< †

@場所名 †

ローカルストレージでオフラインWiki †

ボットみたいなのはクライアントで実行 †

他でも検索 †

最後に参照したページ †

よく出てくる単語（頻出語）の一覧 †

深く読み進めるためのテキスト、概観するためのテキスト †

概観のための体裁 †

リクエスト、ログ読み（未読） †

奥にしまう †

携帯向けビュー †

実装 †

携帯向けのビューでは圧縮 †

表・行列・セルといったものは表だけにする †

CSS適当コンバーター †

設定などのページにも適用 †

派閥内はSNS †

必須でない機能公開はWikiEngineとは別のサイトで。 †

お客様向け †

外から存在しないページに来た人 †

編集支援 †

追記するとき †

関連ページ †

毎日ダンプ †

発想の入り口、経路を振り返るには †

発想の入り口を作るには †

発想の順番が分かる履歴を †

発想支援は利用者の学習を助けるだけ †

ページ名（キーワード）とタグは同等の機能を持つ †

機能を実行時に取得 †

URIで示された場所に置くもの †

ショートカットキーやHTML内のIDを重複させないため †

呼び出し順 †

処理順 †

コラボレーションツール †

編集者用メニューにdiffを †

アクセスキーはユーザー設定 †

外に出さない書き込み †

編集ページは可変長 †

新規ページ作成時、ページを作ってから入力受け付け †

引用にはタイトルを †

iPhoneではランドスケープ時のみ2カラム表示 †

リンクにスクリーンショットを †

画像の差分表示 †

Microsoft/web (Microsoft Web UIのサイト)へ登録 †

索引 †

対象範囲 †

©をページごとに用意 †

似ているページや追加位置を気にしない †

自動生成ページは隠す †

タグの継承 †

連続する機能はつながる †

機能の対象範囲 †

バックアップダンプをメール送信 †

WAI-ARIA †

履歴→記録 †

見解の仕組みをwiki間でもできたら？ †

編集の衝突 †

NintehdoDSブラウザー対応 †

URIの#! †

保管してあるアイデアはアップデートしない限り役に立たない †

日付記法とカレンダー †

何やってたんだっけリスト †

ブラウザーのウィンドウタイトルに検索語を付けたら便利？ †

一覧できる表示方法、タイリング、リスト †

分派は多数派も少数派も守る †

永続セッション †

フレームワークからdump呼び出し †

少数派の猶予 †

派閥は統合なし、分けるだけ †

編集できない派閥（のページ）を編集すると分派 †

OpenIDがあるのだから利用者の同定を当てにしていいのでは？ †

OpenIDとOAuth †

支持票は複数入れていい †

自分にとって都合のいいページだけを見せてくれるのが代表の仕組み †

派閥はデフォルト値が同じ人たちの集まり †

自分のサイトへトラックバック送信 †

内容付きページ一覧 †

カラムブラウザー †