1. Wikiは読みにくい
  2. URLクエリーの列からToDoリストやワークフローを生成できるように
  3. ボットみたいなのはクライアントで実行
  4. 他でも検索
  5. 最後に参照したページ
  6. 実装
  7. よく出てくる単語（頻出語）の一覧
  8. 深く読み進めるためのテキスト、概観するためのテキスト
  9. 奥にしまう
  10. 携帯向けビュー
    1. 実装
  11. タブでインデントしたい
  12. 表・行列・セルといったものは表だけにする
  13. CSS適当コンバーター
  14. 自動リンクには手間がかかる
  15. 設定などのページにも適用
  16. 派閥内はSNS
  17. 必須でないプラグイン公開はWikiEngineとは別のサイトで。
  18. お客様向け
    1. 外から存在しないページに来た人
    2. 編集支援
  19. 追記するとき
  20. 毎日ダンプ
  21. 発想の入り口、経路を振り返るには
  22. 発想の入り口を作るには
  23. 発想の順番が分かる履歴を
  24. 検索用クラスやめ
  25. ページ名（キーワード）とタグは同等の機能を持つ
  26. リンクも検索対象
  27. プラグインを実行時に取得
    1. URIで示された場所に置くもの

Wikiは読みにくい † Edit

wikiって相変わらず書いてある内容が分からないな

俺が新しい時代についていけてないだけか

あやしいわーるど＠暫定(暫定退避) 過去ログ検索結果 (＠検索)

  1. 文字が多すぎる
    減り張りの無い文字ばかり。だからと言って図が必要というわけではない。
    1. パッと見で読むべきところ（見出し）が分かるように。見出しを見ているときにその他の文字が邪魔をしないように。
  2. 整然としすぎている
    本文中、行頭にあたる線が1本。
    記事が1列に並んでいる。
    俯瞰しづらい。
  3. サイドメニュー（MenuBar）が乱雑
    上部にもグローバルナビがあったりする。見えているのはどちらか一方でいい。
    1. 隠す
      表示時に画面を再レイアウト。本文がずれるので気持ち悪い。
    2. 隠す
      表示時は本文に重ね合わせて表示。表示のためのスイッチを小さくしないと邪魔。
    3. 隠す
      表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。
    4. 色を薄くする
      表示領域は確保。マウスオーバー時、フォーカス時に表示。表示のためのスイッチは表示領域全体になるので、広く使いやすい。
      &tip;これがいいかも。
  4. タイピングした文章と自動生成された文章が混在している
    自動生成された文章（目次など）には人が読むには余計な部分が混ざる。
    読み飛ばしができない人にとっては混乱の元。
    これはコンテンツを作るときに気をつけること。ページの冒頭には自動生成された文章を置かず、そのページの概要をタイピングで書く、など。

URLクエリーの列からToDoリストやワークフローを生成できるように † Edit

どちらも実装は同じになる。

  • ToDoリストはインスタンス定義
  • ワークフローはクラス定義

…のようなもの。

つまり、ワークフローは使うたびに新しいデータを生成し、ToDoは同じデータを扱う。

ワークフローはランダム文字列などを使ってインスタンス生成。

 

これらを生成するためのフォームはプラグイン扱い。
いろいろと考えられるので。

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

そのためのWebAPI。
可能なものはAPIごとにUIを作って、ネットで公開。

他でも検索 † Edit

InterWikiNameのUI違い。
「「検索結果に登録されているWikiサイト」で検索をする」リングを作る。
検索ボックスにはWikiサイトの選択欄を。
Ajaxでリンクを随時作るのもいい。

最後に参照したページ † Edit

もしWiki外へ出ても元のWikiページに戻れるように、
クライアント側データに「最後に参照したページ」のIDを残す。
クッキーがいい。

履歴すべてを残したいところだが、クライアント側のIDとサーバー側のDBで実現。（データが大きくなるので）

実装 † Edit

ページを指定していないリクエストでは

  1. 最後に参照したページ（クライアントにあるデータによる）
  2. デフォルトページ（Wikiの設定による）

…を返す。

 

というわけで、トップページを見せたいときはトップページを指定したリンクを作り、通常はページを指定しないリンクを使う。
これで、静的なページからでもWebブラウザーの履歴を操作することなく、最後に参照したページに戻れる。

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

新しいページを作るきっかけなので、「新規ページ作成」ボタンの前に利用者に見せたい。
新規作成のページで表示するのもいい。ページ名を統一するために。似ているページ名を探すのに役立つ。

独立したページにすべき。
活用しやすくするため。1ページが1つのDBテーブルのようなもの。

頻出語のリストには、最後に発見された*1日付も。
データを活用するために。

→プラグイン/テンプレート生成[?]

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

Wikiを普通に使うと、深く読み進めるためのテキストしかできない。
閲覧者のためのテキストは別途用意しないと。

閲覧者用はルートディレクトリにあるページの冒頭を集めればよさそうだが、固い。システムでやることではない。

他のページを章単位で埋め込みできればいい。

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

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

New!が下位ページも調べるようになっていればいい。

上位ページが下位ページに依存したりしないこと。

奥にしまう † Edit

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

携帯向けビュー † Edit

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

実装 † Edit

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

タブでインデントしたい † Edit

テキストエディターを使うとインデントしやすくなる。

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

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

CSS適当コンバーター † Edit

他のシステムのCSSを変換。
叩き台ができる程度でいい。だいたい変換。

過不足があるので完全に変換できるわけがない。
他のシステムとこれの両方で共通する部分だけ扱う。

システムによってキーワードが異なるので、入力時に何のCSSかを指定。
個別対応。
「汎用（適当）」という適当なやり方も提供。

Wikiは5ペイン（上、下、右、左、真ん中）までの構成で、独自の段組み（システムが用意したものでなく、利用者が独自に作った段組み）が無ければどんなスタイルでも適用できるはず。

Wikiとは独立したツール。

自動リンクには手間がかかる † Edit

Wikiの自動リンクは「自動リンク」というより「半自動リンク」。何をリンクするか明示*2しなければならない。

これでは「書き散らしたことが自動的にまとまる」とはいかない。
人的資源が必要。

一人で使うとなると手間がかかってしょうがないので、検索キーワードを自動的にページ化する機能でもないとアイデアノートにはしづらい。
とは言っても他の方法と比べると格段にWikiのほうが良いわけだけど。

検索キーワードから自動的にページを作るとなると、そうやって作ったページを自動的に削除する機能も欲しくなってくる。
削除の条件は、自動的に作られて、かつ…

  • 古いもの
  • 参照数の少ないもの
  • 検索結果の少ないもの（リンクの少ないもの）
  • 被リンク数（BackLink数）の少ないもの（参照数、検索結果とも関係がある）
    …といったものだろうか。

被リンク数は有効そうだ。
検索で作られたページも検索に引っかかるようにすれば、後で関係のある言葉を検索したときにも被リンク数が増えることになる。

これに新しいものを残す（古いものを消す）というルールを加味すれば実用的になりそう。
これで<b>最近</b>注目されている言葉ほど残ることになる。注目され続けていればいつまでも残る。個々のページを参照しなくても残る。使用頻度の低い言葉でも残る。
Wikiの読み方が検索中心*3じゃないとダメだけど。

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

一般利用者が派閥を独立した1つのWikiとして改良、自分たちなりのシステムを作って自分たちで利用できる。
→派閥の中には版しか入らない。ページごとに別の派閥を作るのなら可。

管理者に見せて活用法の提案
→管理者に派閥付きのURLクエリーを送ればいい。

派閥内はSNS † Edit

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

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

必須でないプラグイン公開はWikiEngineとは別のサイトで。 † Edit

「公式プラグイン」と呼ばれないようにするため。

公式は必須のもののみ。

お客様向け † Edit

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

編集支援 † Edit

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

追記するとき † Edit

Wikiに追記するとき…

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

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

毎日ダンプ † Edit

毎日ダンプファイル作成、特定ページの添付ファイルに追加。
そのページにリンクを作成。

いつでも作成できる最新版ダンプファイルは要パスワード。
（処理が重そうなので。重くならなければパスワード不要）

毎日というのが更新間隔に合わないかも。
それなら前回ダンプファイル作成から数えて最初の更新後、6時間経ったらダンプファイル作成などに。

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

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

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

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

残して考えている最中に見るには…
「考えの履歴」

検索用クラスやめ † Edit

「検索」に書かれているクラスを廃止。
Notationで行う。

Notationの機能…

  • 検索式→オブジェクトの単行表現
  • ページのテキスト→オブジェクトの複数行表現
  • オブジェクト同士を比較したときの適合度算出
    具象クラスが同じ場合も先祖が共通の場合も使える。
    先祖が共通の場合は適合度がやや下がる。
    クラスメソッド。
  • オブジェクト→テキスト（HTML)

…といったことができる。

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

タグ集め、ページ名（キーワード）集め。
閲覧、編集で追加したタグやキーワードを一覧化、
考えの経緯が分かるように。

自分が関わったタグ・キーワードだけでタグクラウド作成。
これを任意の期間だけに絞り込んで表示、集計、表示。

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

リンクも検索対象 † Edit

プラグインと同じ扱いで。
検索式にリンクを表す記号「→」があれば。

プラグインを実行時に取得 † Edit

プラグインをUIからのシステム呼び出し時に取得したい。
管理者がプラグインのURIを入力して。

システムがプラグインを取得、インストール。

アンインストールは…
プラグインと同じ著作者のファイルだけ消す。
他のプラグインでも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。

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

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

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