- -------------------------------------
とりとめのない思い付き。
- <<<
- ボットみたいなのはクライアントで実行
- 他でも検索
- 最後に参照したページ
- よく出てくる単語(頻出語)の一覧
- 深く読み進めるためのテキスト、概観するためのテキスト
- リクエスト、ログ読み(未読)
- 奥にしまう
- 携帯向けビュー
- 携帯向けのビューでは圧縮
- 表・行列・セルといったものは表だけにする
- CSS適当コンバーター
- 設定などのページにも適用
- 派閥内はSNS
- 必須でないプラグイン公開はWikiEngineとは別のサイトで。
- お客様向け
- 追記するとき
- 関連ページ
- 毎日ダンプ
- 発想の入り口、経路を振り返るには
- 発想の入り口を作るには
- 発想の順番が分かる履歴を
- ページ名(キーワード)とタグは同等の機能を持つ
- プラグインを実行時に取得
- ショートカットキーやHTML内のIDを重複させないため
- コラボレーションツール
- 編集者用メニューに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法で下位ページ説明
- ブラックリストとホワイトリスト
- 何かのヒント
- フローとストック
- 編集時コメント
- ToDoバルーン
- カスタムヘッダー
- Sandboxでは履歴を残さない
- -
- <<<
- ボットみたいなのはクライアントで実行
- 他でも検索
- 最後に参照したページ
- よく出てくる単語(頻出語)の一覧
- 深く読み進めるためのテキスト、概観するためのテキスト
- リクエスト、ログ読み(未読)
- 奥にしまう
- 携帯向けビュー
- 携帯向けのビューでは圧縮
- 表・行列・セルといったものは表だけにする
- CSS適当コンバーター
- 設定などのページにも適用
- 派閥内はSNS
- 必須でないプラグイン公開はWikiEngineとは別のサイトで。
- お客様向け
- 追記するとき
- 関連ページ
- 毎日ダンプ
- 発想の入り口、経路を振り返るには
- 発想の入り口を作るには
- 発想の順番が分かる履歴を
- ページ名(キーワード)とタグは同等の機能を持つ
- プラグインを実行時に取得
- ショートカットキーやHTML内のIDを重複させないため
- コラボレーションツール
- 編集者用メニューに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法で下位ページ説明
- ブラックリストとホワイトリスト
- 何かのヒント
- フローとストック
- 編集時コメント
- ToDoバルーン
- カスタムヘッダー
- Sandboxでは履歴を残さない
<<< †
ボットみたいなのはクライアントで実行 †
そのためのWebAPI。
可能なものはAPIごとにUIを作って、ネットで公開。
他でも検索 †
InterWikiNameのUI違い。
「「検索結果に登録されているWikiサイト」で検索をする」リングを作る。
検索ボックスにはWikiサイトの選択欄を。
Ajaxでリンクを随時作るのもいい。
最後に参照したページ †
もしWiki外へ出ても元のWikiページに戻れるように、
クライアント側データに「最後に参照したページ」のIDを残す。
クッキーがいい。
履歴すべてを残したいところだが、クライアント側のIDとサーバー側のDBで実現。(データが大きくなるので)
リンクやバックリンクの数が少ないページ/多いページをどう探すか? †
→ 量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。
よく出てくる単語(頻出語)の一覧 †
新しいページを作るきっかけなので、「新規ページ作成」ボタンの前に利用者に見せたい。
新規作成のページで表示するのもいい。ページ名を統一するために。似ているページ名を探すのに役立つ。
独立したページにすべき。
活用しやすくするため。1ページが1つのDBテーブルのようなもの。
検索で「ブログ」と「ログ」を分けたい †
「ログ」を検索したときに「ブログ」を見つけないように。逆に見つけたいときもある。
曖昧検索のルールで自動リンク †
頻出語のリストには、最後に発見された*1日付も。
データを活用するために。
曖昧検索と自動リンクを統合。
→プラグイン/テンプレート生成[?]
例えば、自動リンクするとき、ページ名やリンク対象に含まれるひらがなを無視して自動リンク。
ページ本文中の「読みやすい書き込」が「読みなれた書込」のページに自動リンクする。逆も起きる。
曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ(入口リンクはあるけど実在しないページのメタページ)から「読みなれた書込み」にリンク。類似したリンク先もそばにある。
ページ一覧で含まれる数字を全部集計 †
ページ一覧や下位展開、コレクション(サブセットWiki)など、複数のページを扱うページでは、含まれるページに書かれている数字を集計。数値類の記法がラベルを受け入れるなら、ラベル別に集計。
深く読み進めるためのテキスト、概観するためのテキスト †
Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。
ファセットナビゲーションの集計版。ページ要素を集める点は似ている。
閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。システムでやることではない。
→:集計
他のページを章単位で埋め込みできればいい。
「要出典」は指摘・抗議 †
「要出典」はコメントとは別の形の抗議。
「最近の更新」や「今日の100」が概観のためのページ。
断片的なので読むという感じはしない。
更新された部分や人気の部分が章単位で表示されれば効果あり。
編集者がなんでもサイドメニューに載せようとする。
更新されたことが上位ページに伝わる仕組みになっていれば、ルートにあるページだけメニューに載せればいい。
上位ページでは下位にあるコメントも見える †
コメント(スレッドモード)だけをつなげて並べる必要は無い。下位展開で各ページにコメントがあればいい。
New!が下位ページも調べるようになっていればいい。
上位ページが下位ページに依存したりしないこと。
見出し無しはルートページを指す †
見出しよりも先に書かれたテキストは、名前の無いページ(ルートページ)の本文に追記することになる。同名ページは1人ひとつまでなので、同名ページ作成にはならない。
リクエスト、ログ読み(未読) †
人気ページは「充実させてほしい」というリクエストの表れ。
編集者が自分が編集するペースで(というか、前回アクセスから今までの期間で)人気のあるページを調べられれば、
「次に編集すべきページ」「期待されているページ」というものが分かる。
検索結果の定義は特定名のページで †
その下位ページは、ヒットしたページごとに利用されるループ部分。
…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。
掲示板での「ログ読み」「未読」をWikiでやるならば、前回アクセス以降の差分(全ページ分)閲覧と、前回アクセス以降の人気ページを知ることになるのでは。
奥にしまう †
アクセスされていないページと付帯データは別サーバーに。
利用者が同一サイトに集まるわけない †
投票は結局無駄になる。
携帯向けビュー †
サブページが実装されれば目次を表示するだけでいい。
目次からサブページへリンク。
「自分にとって」は2つある †
自分のスペースにインポートすれば投票か †
他人のページをコピペ改変するのが投票か。
投票は自分のページと、自分が触れていないページにするもの。
コピペ元にも同時に投票される?重要な版を自動検出して代表化する。
実装 †
ユーザーエージェントで携帯かどうか判定。
ページセットはページの属性を表せる †
ページ属性はページセット。実装の違い。
ページ属性とページセットを同一視。
「自分にとって」を基本にして †
どう利用者間のコラボレーション・コミュニケーションをするか。
元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解・同名ページは無くなった。
携帯向けのビューでは圧縮 †
「自分にとって」は何と結び付けるか †
- 投票…ページ名とページの結び付け
- ページセットと?(コレクション)
- 承認と?SPAMでないこと
- すべて
FederatedWikiのように。 - 自分用にできないもの
ページ名はページの一部なのでできるはず。
表・行列・セルといったものは表だけにする †
ページの機能として汎用化するには無理がある。
CSS適当コンバーター †
他のシステムのCSSを変換。
叩き台ができる程度でいい。だいたい変換。
「自分にとって」を実現するために、1スペースに1人だけにすると †
過不足があるので完全に変換できるわけがない。
他のシステムとこれの両方で共通する部分だけ扱う。
スペースはページセットでコレクション †
1人でいくらでも持ちたい。
※自分のスペース内に。
「自分にとって」はスペース。スペースをまとめたのがWiki.
システムによってキーワードが異なるので、入力時に何のCSSかを指定。
個別対応。
「汎用(適当)」という適当なやり方も提供。
ゲストは投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース。
Wikiは5ペイン(上、下、右、左、真ん中)までの構成で、独自の段組み(システムが用意したものでなく、利用者が独自に作った段組み)が無ければどんなスタイルでも適用できるはず。
基本がFederationになっても、投票を伴なうピン留め操作は必要 †
これで(共有スペースでの)代表が決まる。コピペ改変も投票を伴なう。
Wikiとは独立したツール。
設定などのページにも適用 †
→派閥の中には版しか入らない。ページごとに別の派閥を作るのなら可。
投票はSisterWikiネットワーク内で有効 †
フォローも同様。
管理者に見せて活用法の提案
→管理者に派閥付きのURLクエリーを送ればいい。
承認時、モデレーター間で意見が分かれたら? †
- 投票は「自分にとって」のもの
- 投票でモデレーターになれる
- 利用者によって、どのページが存在して、削除されていて、SPAMかが異なる
- この3つはページセット。承認はページを3つのページセットに振り分けるもの
派閥内はSNS †
利用者名から利用者ポータルページは分からないようにして。
基本がFederationになっても、フォローは可能か †
同名ページ→その作成者→作成者の利用者ページでフォロー可能。
フォローリストはページセット。それもSisterWikiのインポート対象。
- メッセージはどの派閥経由か分かるように
- 派閥から抜けると縁が切れるように
匿名のままのつながりなのはこのため。
スペースをフォローするのがSisterWiki。
必須でないプラグイン公開は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・ショートカット定義の他にも類するものがあっても追加できるように。
コラボレーションツール †
他人以外にも過去の自分や未来の自分とも。
忘れたこともすぐ再開できるツールに。
思考の道筋をリンクの道筋として記録できるようなツールに。
編集者用メニューにdiffを †
編集者の場合によく使うメニュー
同じページを毎日チェックするとか、
書くとか、書く前に検索、編集するか新規作成か考えるためのメニュー。
アクセスキーはユーザー設定 †
外に出さない書き込み †
議論中の書き込み、不確定な書き込み、暴言は外に出したくない。
でも内部には公開したい。
Wikiなので、そのうち暴言は消される。
残るならそれがそのWikiでの結論。
→それなら追加された(更新された)部分はしばらく外に出さないだけでいい。
- 外
- Google、アンテナなど。
外に出さないものは拒否を表明しておくだけ。
別ページにしないと、更新された部分だけ分けることができない。
→外には古い版を出せばいい。
- ---------------------------------------------------------
つまり、不適切な書き込みをネットに広めないように…
…ということ。
編集ページは可変長 †
テキストエリアのスクロールバーを出さないように。
代わりにページのスクロールバーを使う。
新規ページ作成時、ページを作ってから入力受け付け †
通常では「ページ作成」(またはDanglingLinkを使用)→更新をして作成されるページ。
これをページ作成で作成するようにする。(で、既存ページを更新することに)
作成されるページ内容はWikiの定義による。
「ページ新規作成時のテンプレート」というページで定義。
DanglingLinkをクリックするだけでページが作られる。
引用にはタイトルを †
1行目または最後の行にタイトルを書けるように。
iPhoneではランドスケープ時のみ2カラム表示 †
リンクにスクリーンショットを †
プラグイン。
リンクにはてなスクリーンショットを付ける。
ブラウザー側でこのプラグインが有効なページでリンクにスクリーンショットを付ける拡張を。
画像の差分表示 †
画像ファイル(ページ)の差分を枠で強調。
絵よりも図の変更のために。
Microsoft/web (Microsoft Web UIのサイト)へ登録 †
ASP.NETなら登録先にMicrosoft/webもある。
索引 †
ページ内の索引と、サイト内の索引、他の単位も?
単語抽出が要るが本当の単語でなくていい。文字種区切りで可。
リンクを集めるだけでいい。
wiki内の単語・語彙とはページ名だから。
対象範囲 †
…など。
どう設計するか。
→どれもページ。wikiはルートページ、サブページなしのページはサブページを持たないページのこと。
©をページごとに用意 †
コピー可能。
そのまま別のページに貼り付け。追加できるように。
章の統合などでも©を継承できるように。
似ているページや追加位置を気にしない †
適当にぶっこむこともあるので、そのあとでまとめられるほうがいい。
自動生成ページは隠す †
自動生成ページは検索の対象外。特に指定されていなければ。
PukiWikiでの:始まりのように。
「:AutoGen/…」のように。
タグの継承 †
タグはページが持つ属性。
タグは上位ページのタグを弱く引き継ぐ。
連続するプラグインはつながる †
同じプラグイン、WikiNotationを続けるとつながる。
行単位の引用「>」や、段落単位の引用「>>…<<」など。
プラグインの対象範囲 †
- ページ
- 段落
空行間。 - 行
改行間。 - 文字列
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のクエリー部分違いはタイトルを変えるかということ。
ページの見た目に関わるなら変えるべき。
一覧できる表示方法、タイリング、リスト †
マイページでウォッチ範囲の新着(範囲か条件で指定)表示に。
レイアウト変更
ズーム(絵や動画の)
分派は多数派も少数派も守る †
- 少数派は多数派から攻撃されなくなる
- 多数派は?
→同じ。
永続セッション †
もう1つのセッションが一時セッション。
時限式ID、それを過ぎると変わる。
ユーザーアカウント1つあたり。それぞれ永続と一時のIDを持つ。
常に1つ(×2)持つ。(初めてセッションを作るまでの間を除いて常に)
フレームワークからdump呼び出し †
そのきっかけは普段コメントアウトされている行や、ユーザーからのdumpコマンド実行リクエストでいい。
少数派の猶予 †
支持票が無くてもページが消えたりしない。
支持されてなくでも多数のページを作って体系化する。それくらいできるように。
後になって支持されるかも知れない。
派閥は統合なし、分けるだけ †
コウモリはあり得なくなる。
統合するなら他の派閥を参考にして、自分のところを充実させることで実現。
編集できない派閥(のページ)を編集すると分派 †
別派閥作成+テンプレートとして元のページ使用。
OpenIDがあるのだから利用者の同定を当てにしていいのでは? †
1人1アカウントになるように。
それとアカウント持ちに便利なようにして。
これで
- 1人1アカウント
- 使い回せる
便利。作ることが面倒でない…騙れない
…といったことが実現できそう。
アカウントを持っているのにゲスト利用…は非公開利用、隠れて利用ということになる。
→認める。
ホワイトリストと組み合わせたOpenIDならWikiに合うアカウントとして使えそう。
OpenIDプロバイダーのホワイトリスト。
OpenIDは使えるが、OAuthは使えない †
OAuthを使うなら、OpenIDに結び付けて、他サイトのアカウントとOpenIDの結び付けをするために。
支持票は複数入れていい †
自分にとって都合のいいページだけを見せてくれるのが代表の仕組み †
これがゲストの場合…Wikipediaが目指しているような公に認められたページになる。
これはGoogleでもやっていること。
(ユーザーの検索履歴が反映されるようにページの順位を変えている)
カスタマイズがフォークソノミーになる仕組み。
見たいものを上位に。見たくないものを下位に。
派閥はデフォルト値が同じ人たちの集まり †
制限を課すようなものではない。
例えば代表の初期値(初期の代表、何も判断材料が無いときの代表)に同じ派閥の人を参照する。
自分のサイトへトラックバック送信 †
自分の日記のために。活動記録のために。各サイトのTwitter連携のようなもの。
自分のアカウント→トラックバック先を設定しておく必要がある。(利用者設定)
内容付きページ一覧 †
特に短いページが多いときに。
検索結果でも。
検索結果は検索キーワード付近を横断的に表示するもの。
文字数で数えて近いテキストのほか、別の尺度で近いテキストも表示できれば…?
カラムブラウザー †
iTunesの。テーブルの列ごとにまとめ。選ぶと選択した列に選択したのと同じ値を持つ行だけ表示。
これをWikiとページに適用すると…列→「タグ」、値→付けられたタグ。
ページは非定型、フリーフォーマットなので列にあたるものがタグくらいしかない。
見出しなどは重複することがないのでまとめにならない。
「フォームを再送信しますか」 †
フォームの送信をしたページをブラウザーの履歴に入れない方法はあるか。
派閥内は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 意見の衝突、共通点がわかりやすいように。人力を利用して。返信に2文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを2文字程度で返信・意志表示できるとか。
- @pmint_name 「会話」の流れも使える。
ページの追跡 †
外から存在しないページに来た時、新規作成よりもそのページはどこに行ったか追跡してくれたほうがいい。
削除されていたり追跡出来なかったら(できれば当時の)過去バージョンへ。
編集回数により変更可能範囲が増えるWiki †
Wikiは人力リソースに応じて編集できる量を変えたほうがいいので。
誰も編集しない「枯れたページ」は凍結していい。Spam対策としては凍結すべき。
機能として実装するなら、
作られた時点ではページ内容を100%変更可能、編集されずに時間が経過するにつれて一度に変更できるデータ量が0%まで変化。
リセットは権限保有者が行なう。ので、リセット要求を権限保有者に出せるように。
追記のみのコメント欄は自然凍結しないように設定したほうがいい。
サイト単位の完全な凍結は管理者が行なうほうがいい。
Wikiではなくなるので。完全凍結していないのならフロー式の投稿くらいできないと。
- -------
半凍結の状態をどう表現するかは再考。
データ量か?編集可能箇所は全体?編集箇所が連続するのを禁止?誤字修正くらいはいつでもできるように?
既存データの削除は禁止?追記だけ?
すぐに編集できないとWikiWikiでなくなってしまうので、編集可能にしつつSpam対処の労力を一個人に求めないように。
ページはバラバラなもの †
ページ構成というものはない。
検索などで構成、その中を見て回る。
とりあえずぶっ込んでおけばあとでまとめられる機能 †
- ぶっ込む
- あとづけのページでグルーピング(グループ化)
検索でリンク作成、検索記法の結果を埋め込み、それが検索にヒットするように。 - グルーピングページにさらに情報追加
関連語、関連ページへのリンク - 検索で探せる
グルーピング用ページがヒットするとリンク先まで表示。
BackLinkではなく、順方向リンク。
ヘルプにプラグインパラメーター例 †
「バグかな?と思ったら」
公式サイトに全てのパラメーター例。無いものは追加できるように。
例から問題が分かるように。例に無い挙動をするならバグレポートへ。
学習する検索 †
正しい例と誤った例を蓄積して。
リンクを合わせるかリンク先を合わせるか †
リンクしなかったとき、リンクを合わせる以外に、リンク先を変更する手もある。
Googleドキュメントにバックアップ †
管理者のアカウントへ。複数登録、アカウント選択なども。
OAuth。
リストアは必要ない。ファイルダウンロードして、通常のリストア。
リストア実行前にバックアップ †
最終バックアップから更新されていなければ要らない。
不要なバックアップになるとしてもバックアップは作る。
ゲストはバッチ的操作不可 †
複数ページに影響する(そして完全に戻すには手間のかかる)操作は要権限。
なんでもリンクで。 †
下位ページもリンク、その他の関連もリンク。
関連名が要る?リンクの属性
検索結果から関連ページへは直接か?クリックが必要では?後付けのまとめページから実体ページを閲覧するまでのステップは? †
置き換えプラグイン †
設定では他のプラグインより優先
これで他のプラグインのパラメーター固定値版Notationを定義
タグ… †
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での「ノート」。会話。提案・サジェスト。
あるページに投稿されたフローな情報は「そのページについての批評・提案」。
フローな情報の見せ方はどうするか? :t/ToDo
Wikipediaのノートのように表ページのナビゲーション的な場所にリンクを埋め込み?
フローをストックするためのWiki †
- WikiはTwitterやメールのような送りつけられる形を取り込めるようにならないか?ページ表示、フォーム表示、書いて送信は手順が多すぎる
- 送りつけ投稿でもいい感じ(読むためよりも再編集にいい感じ)にまとめるには?
- メールやTwitterをメーリングリスト的に使い、やりとり・流れる情報をいい感じにまとめるには?
- 意見の衝突、共通点がわかりやすいように。人力を利用して。返信に2文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを2文字程度で返信・意志表示できるとか。
- フロー投稿のまとめ(セグメント化)
同じ人から・同じページへ・同じ内容(?) - テーブル記法を使って左右に同意・異議を振り分け。一覧しやすくするとか。Twitterアカウントにもページを作って人別に一覧しやすくするとか。
編集時コメント †
特にページ削除時に必要。「なぜ」の推測材料がないので。
ToDoバルーン †
ページとページ内の位置を指定して吹き出し表示。
完了したら割る。
位置は見出し(ページ)でいい。
ページ名変更に追従するように、ページ内にバルーン用データを置ければいいけど。
それをクライアント側で吹き出し化。ページヘッダーにスクリプト埋め込み。
ユーザーでなく、システムが操作するデータをページに設けるということになる。
カスタムヘッダー †
レスポンス時のHTTPヘッダーに受け入れできる記法、HTMLヘッダーにシステム名