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

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

最後に参照したページ Edit

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

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

よく出てくる単語(頻出語)の一覧 Edit

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

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

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

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

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

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

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

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

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

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

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

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

奥にしまう Edit

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

携帯向けビュー Edit

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

実装 Edit

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

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

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

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

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

CSS適当コンバーター Edit

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

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

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

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

Wikiとは独立したツール

設定などのページにも適用 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

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

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


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

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

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

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

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

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

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

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

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

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

呼び出し順 Edit

ページA(外)ページB(中)ページC(中)
ページD(中)

処理順 Edit

例。

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

テストでは下位の全IDの中に自身が持つIDが有るか調べる。
が、下位のテストがNGならそれだけでNGにしていい。結果は変わらない。

下位の全ID・ショートカット定義を扱う。
戻り値はOK/NGの区別と、下位と自身の全ID・ショートカット定義

実装ではID・ショートカット定義の他にも類するものがあっても追加できるように。

パスワードを複数設定 Edit

IDは同じでもパスワード次第で別のロールに属す。

管理者用は全ての権限を持つ、といったことができるように。

…など。

ID(1)──(*)パスワード(1)──(1)ロール(1)──(*)権限
で、1つのパスワードで複数の権限が使える。

これはID1つとパスワード1つの組(1)─◆アカウント(1)──(*)ロール(1)──(*)権限
を簡略化したもの。

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

他人以外にも過去の自分や未来の自分とも。

忘れたこともすぐ再開できるツールに。

思考の道筋をリンクの道筋として記録できるようなツールに。

読み上げしやすいRSSフィード Edit

句読点を適切に。
強調は(記号ではなく)言葉で。