とりとめのない思い付き
  • -------------------------------------
  • -
  1. <<<
  2. 対象範囲
    1. リンクやバックリンクの数が少ないページ/多いページをどう探すか?
  3. ライセンス表明
  4. 似ているページや追加位置を気にしない
    1. 検索で「ブログ」と「ログ」を分けたい
    2. 曖昧検索のルールで自動リンク
  5. 自動生成ページは隠す
  6. タグの継承
    1. ページ一覧で含まれる数字を全部集計
  7. 連続する機能はつながる
  8. 機能の対象範囲
    1. 「要出典」は指摘・抗議
    2. 上位ページでは下位にあるコメントも見える
    3. 見出し無しはルートページを指す
    4. 検索結果の定義は特定名のページで
  9. バックアップダンプをメール送信
    1. 利用者が同一サイトに集まるわけない
    2. 「自分にとって」は2つある
  10. WAI-ARIA
    1. 自分のスペースにインポートすれば投票か
    2. ページセットはページの属性を表せる
  11. 履歴→記録
    1. 「自分にとって」を基本にして
  12. 見解の仕組みをwiki間でもできたら?
    1. 「自分にとって」は何と結び付けるか
  13. 編集の衝突
    1. 「自分にとって」を実現するために、1スペースに1人だけにすると
  14. NintehdoDSブラウザー対応
  15. URIの#!
    1. スペースはページセットでコレクション
  16. 保管してあるアイデアはアップデートしない限り役に立たない
    1. 基本がFederationになっても、投票を伴なうピン留め操作は必要
  17. 日付記法とカレンダー
    1. 投票はSisterWikiネットワーク内で有効
    2. 承認時、モデレーター間で意見が分かれたら?
  18. 何やってたんだっけリスト
    1. 基本がFederationになっても、フォローは可能か
  19. ブラウザーのウィンドウタイトルに検索語を付けたら便利?
  20. 一覧できる表示方法、タイリング、リスト
  21. 分派は多数派も少数派も守る
  22. 永続セッション
  23. フレームワークからdump呼び出し
  24. 少数派の猶予
  25. 派閥は統合なし、分けるだけ
  26. 編集できない派閥(のページ)を編集すると分派
  27. OpenIDがあるのだから利用者の同定を当てにしていいのでは?
  28. OpenIDとOAuth
  29. 支持票は複数入れていい
  30. 自分にとって都合のいいページだけを見せてくれるのが代表の仕組み
  31. 派閥はデフォルト値が同じ人たちの集まり
  32. 自分のサイトへトラックバック送信
  33. 内容付きページ一覧
  34. カラムブラウザー
  35. 「フォームを再送信しますか」
  36. 派閥内はSNS
  37. ダンプで一括置き換え可能に
  38. バックリンク(BackLink)の一覧
  39. アンケートは自分のページに回答を書く
  40. ダンプにはindex.htmlを
  41. 書き込みできるかをwiki全体で表示
  42. Twitterから
  43. ページの追跡
  44. 編集回数により変更可能範囲が増えるWiki
  45. ページはバラバラなもの
  46. とりあえずぶっ込んでおけばあとでまとめられる機能
  47. ヘルプに機能パラメーター例
  48. 学習する検索
  49. リンクを合わせるかリンク先を合わせるか
  50. Googleドキュメントにバックアップ
  51. リストア実行前にバックアップ
  52. ゲストはバッチ的操作不可
  53. なんでもリンクで。
  54. 検索結果から関連ページへは直接か?クリックが必要では?後付けのまとめページから実体ページを閲覧するまでのステップは?
  55. 置き換え機能
  56. タグ…
  57. 検索しかないのか
  58. KJ法で下位ページ説明
  59. ブラックリストとホワイトリスト
  60. 何かのヒント
  61. フローとストック
    1. フローをストックするためのWiki
  62. 編集時コメント
  63. ToDoバルーン
  64. カスタムヘッダー
  65. Sandboxでは履歴を残さない
  66. 「HTMLに対応付けられていた記法を、文書の構造に使った」
  67. サブページごとの読み込み
  68. 下位ページレイアウト
  69. 編集機能
  70. tel:記法
  71. スマホ
  72. 編集→書き込みと、即時書き込み
  73. スタイルテーマ
  74. 図と自動リンク
  75. Turn off the lights
  76. 最近の入力
  77. ページネーション
  78. 記録系機能
  79. テーブルを追加するフォーム
  80. 特定版リンクとはローカル名付きのページ名リンク。
  81. ページ属性に「HTTPSを使わせる」
  82. 不完全なページ要求+代表拒否
  83. 振って「とりあえずマイリスト」
  84. ページの重さ
  85. タブビュー
  86. *(ワイルドカード)
  87. 埋め込みオブジェクトの事前レイアウト
  88. 自動リンク・リンクを、色分け・サイズ分け
  89. ページ一覧にダイジェスト
  90. 権限の表示にアイコンを
  91. コードインポート
  92. 索引
  93. ファセット分類
  94. おかえりなさいメール
  95. アカウント削除予約
  96. 機能/Google計算機の結果に置き換え
  97. いろいろフォーマット
  98. 紹介はマンションやホテル・旅館の紹介のように。
  99. EverWiki
  100. WikiEngineをまとめたWikiEngine
  101. 何かを書くと「で?」
  102. サポートはありません。
  103. 参考に
  104. 問題追跡、提案板にアイコン風のテキスト
  105. "X POWERED"
  106. 見解は削除に代わる手段
  107. Ui 1つのオブジェクトに複数の操作を割り当てるなら、フリック。
  108. @場所名
  109. ブレインストーミング
  110. 発想の流れ
  111. おすすめ検索キーワード
  112. コード内のToDo
  113. 活用法 マイメソッド
  114. 2ホップ先は共起相手
  115. サイト分析
  116. スタイルテーマはROM専のため
  117. UI クライアントビュー上で切り換えたいもの
  118. UI ツイートボタンやいいね!はまとめて
  119. UI モバイル用UI
  120. 検索
  121. プラグイン内でプラグインを呼び出すために
  122. インデックス不可能な語をインデックス可能にするには
  123. ①・②・③に順序を持たせる
  124. 見解統合はページの削除と投票×2
  125. バックリンクをまとめたページ
  126. 1つ支持すれば他の派閥は不支持になるか
  127. 支持を変えて他の派閥に負担をかける攻撃
  128. 「はてなの人力質問で"Wiki"をウォッチしています」という表明
  129. 文字列からの型変換はExcelでもやっている
  130. CSVファイル取り込みは添付ファイル化
  131. 検索クエリーは式とページ内容のobj化
  132. まとめる作業をしているときに新発想がある
  133. まとめる作業
  134. まとめる作業支援
  135. 「と関係のある」という検索式
  136. ページ名変更をリンクに反映
  137. プレビューはボタンにしない
  138. 注釈(note)はセクションを越えない
  139. 関連情報にAmazonなどの商品も
  140. 外部リンクにfavicon併記
  141. インデント
  142. 場所によって変わる補完候補
  143. 顔文字はインラインタグ
  144. 特定単語がタグ
  145. 古く見えるテーマ
  146. テキストボックスに選択文字列
  147. 明るく暗くをランプで
  148. RecentChangesのビューにwikiが発展する様子を表したい
  149. 選択文字列に一言コメント
  150. X-Runtime
  151. なぞなぞ認証
  152. 1IDに1パスワード
  153. オープン認証だけ
  154. オープン認証ではユーザーIDにサイトドメイン追加
  155. オリジナルテーマを作って広める
  156. 1ページに集めるだけで「そのうちまとまる」と言えるのか?
  157. パーマリンクには内部名を使う
  158. 汎用プラグイン記法はどんな書式?
  159. 草稿
  160. メール送信記法
  161. アクティビティのカレンダー表示
  162. tipsかるた
  163. バックリンクと一緒に名前変更
  164. よく使うコマンドを上げる
  165. 前後ナビのデザイン
  166. ページは空でも消さない
  167. APIバージョン
  168. 利用者ページに書くこと
  169. 検索には高いレスポンス性能が必要
  170. エクスポート
  171. URLを貼るとブクマと☆も表示
  172. UI 画面切り替えには前後画面に1つだけ共通点を
  173. ぐにゃぐにゃできる検索結果
  174. Wikiの分かりにくさ
  175. 機能/前後ナビ
  176. super要素
  177. クリック、打ち込み、通知
  178. まず書く
  179. 右上
  180. メモ化のキー
  181. Wiki 編集UI リバートよりも前版コピペ支援
  182. 一秒以内の編集ボタン→投稿ボタンには応じにくい
  183. 編集ボタンを押す直前に気付きにくい荒らしがあったら?
  184. 自動的に出る「追記」
  185. リバートは管理者グループのものでいい
  186. 内容依存なFoldingTextはできないか?
  187. 日付で分ける以外の目次インデックス作り?
  188. 名言
  189. 読みにくさ解消
  190. 追加と編集は別権限
  191. universe->space->entry->side->section->revision
  192. ファセットWiki

<<< Edit

対象範囲 Edit


…など。

どう設計するか。

→どれもページ。wikiはルートページサブページなしのページサブページを持たないページのこと。

リンクバックリンクの数が少ないページ/多いページをどう探すか? Edit


量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。

ライセンス表明 Edit


コピペ可能。

そのまま別のページに貼り付け。追加できるように。

章の統合などでも©を継承できるように。

下位ページ継承可能なフッターを用意してそこに書いておければいい。

記法にして置くのもいい。©のほか、CC BY-SAなど。ライセンス条項はアップデートされるので、プラグインの差し替えでアップデート可能に。

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


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

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


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

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

自動生成ページは隠す Edit


自動生成ページ検索の対象外。特に指定されていなければ。

PukiWikiでの:始まりのように。

「:AutoGen/…」のように。

曖昧検索自動リンクを統合。

例えば、自動リンクするとき、ページ名リンク対象に含まれるひらがなを無視して自動リンク

ページ本文中の「読みやすい書き込」が「読みなれた書込」のページ自動リンクする。逆も起きる。

タグ継承 Edit


タグページが持つ属性

タグは上位ページタグ弱く引き継ぐ。

曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ(入口リンクはあるけど実在しないページメタページ)から「読みなれた書込み」にリンク。類似したリンク先もそばにある。

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


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

ファセットナビゲーションの集計ページ要素を集める点は似ている。

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


同じ機能、記法を続けるとつながる。

行単位の引用「>」や、段落単位の引用「>>…<<」など。

→:集計

機能の対象範囲 Edit

  • ページ
  • 段落
    空行間。

  • 改行間。
  • 文字列

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


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

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

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


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

それぞれの表記方法(例)
  • ページ
    ページのどこに書いてもいい。

    先に書いたほうが優先されるので、通常は先頭に。あるいは特別な領域へ。
  • 段落
    段落の中(見やすくするため段落始めか

    段落終わりに)。一行使うか段落内の行頭か行末に。

  • 行頭か行末に。行頭と行末の

    両方に何か書くなら文字列指定とかわらない。
  • 文字列
    面倒。括弧でくくらなければならない。

    例えば明示的なリンク

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

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


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

書く内容…
  • 機能名(属性名)

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

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


その下位ページは、ヒットしたページごとに利用されるループ部分。

…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。

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


携帯などからでもバックアップできるように。

トリガーをメール受信にできればなおいい。

送信先は管理者設定か、リクエストメールの送信者に。

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


投票は結局無駄になる。

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

WAI-ARIA Edit

自分のスペースインポートすれば投票 Edit


他人のページコピペ改変するのが投票か。

投票は自分のページと、自分が触れていないページにするもの。

コピペ元にも同時に投票される?重要なを自動検出して代表化する。

ページセットページ属性を表せる Edit


ページ属性ページセット。実装の違い。

ページ属性ページセットを同一視。

履歴→記録 Edit


履歴バックアップは記録。パーマリンク付き。

Google検索の下位に出したいが、それができないなら出さなくてもいい。

自分にとって」を基本にして Edit


どう利用者間のコラボレーションコミュニケーションをするか。

元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解同名ページは無くなった。

見解の仕組みをwiki間でもできたら? Edit


InterWikiNameがインターネット内の代表ページにつながる。

他のWikiEngineを仲間に入れるには?片方向リンクでもいい。

餅は餅屋のwikiで。

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

編集の衝突 Edit


一般的ではないので、「古いバージョンを更新してしまったようです」のように。

お互いの元バージョンと変更後バージョンを示して、ユーザー自身と他のユーザーがそれぞれ何をしたのかを説明。

でも編集箇所が異なれば衝突とはしないことに。

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

NintehdoDSブラウザー対応 Edit


UserAgent別のビューで。

URIの#! Edit


http://code.google.com/intl/ja-JP/web/ajaxcrawling/docs/html-snapshot.html

HTML Snapshot を適切に作る方法

スペースページセットコレクション Edit


1人でいくらでも持ちたい。

※自分のスペース内に。

自分にとって」はスペーススペースをまとめたのがWiki.

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


いつのアイデアか分かるように。

差分表示で日付を含めて「追加」「削除」を表示。

ゲスト投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース

発想→保管→更新や追加や集約→保管→更新→活用。

更新すること(古い内容や正しいことを確認すること)が必要。

更新にかかる時間、手間を少なくするには?

→開いたときに関連情報が集まっている…KJ法の途中のような。

いつのアイデアか分かるように。

差分表示は複数差分をまとめて。履歴を範囲指定で、ここからここまで。

現在のも含めて履歴表示。そうすれば「現在との比較」というリンクが要らなくなる。

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

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

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


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

日付記法とカレンダー Edit


日付(WikiNotaion)を書くとタグのような扱いに。タグクラウドの対象外

日付ページへのリンクになり、日付リンクツールチップにはその日の一行日記が表示されるように。→リンク/ツールチップ[?]の仕組みとツールチップに何を書くかで。

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


フォローも同様。

日付リンクを集めたページがカレンダー。

静的なページでもいい。リンクが存在する月ごとに表示や生成をする動的(な機能を含む)ページでもいい。

の更新コメントを一覧化するためのもの。

サイト全体に渡る更新が書きやすくなる。

ページごとに書くこともあるので、の更新コメント欄もあっていい。

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

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


パンくずリスト。迷っても通った道順通りにリストアップ。

ルートからの最短経路になるトピックパスとは違う。

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


同名ページ→その作成者→作成者の利用者ページフォロー可能。

フォローリストはページセット。それもSisterWikiインポート対象。

スペースフォローするのがSisterWiki

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


ブックマークのために。
「…」から(ページタイトル)

外部(Googleなど)からの検索語も同様に。

URLのクエリー部分違いはタイトルを変えるかということ。

ページの見た目に関わるなら変えるべき。検索語強調付きのときなど。

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


マイページウォッチ範囲の新着(範囲か条件で指定)表示に。

レイアウト変更

ズーム(絵や動画の)

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

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

永続セッション Edit


もう1つのセッションが一時セッション

時限式ID、それを過ぎると変わる。

ユーザーアカウント1つあたり。それぞれ永続と一時のIDを持つ。

常に1つ(×2)持つ。(初めてセッションを作るまでの間を除いて常に)

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


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

少数派の猶予 Edit


支持票が無くてもページが消えたりしない。

支持されてなくでも多数のページを作って体系化する。それくらいできるように。

後になって支持されるかも知れない。

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


コウモリはあり得なくなる。

統合するなら他の派閥を参考にして、自分のところを充実させることで実現。

編集できない派閥(のページ)を編集すると分派 Edit


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

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


1人1アカウントになるように。

それとアカウント持ちに便利なようにして。

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

…といったことが実現できそう。

アカウントを持っているのにゲスト利用…は非公開利用、隠れて利用ということになる。

→認める。

ホワイトリストと組み合わせたOpenIDならWikiに合うアカウントとして使えそう。

OpenIDプロバイダーのホワイトリスト。

OpenIDOAuth Edit


1つのOpenIDOAuthアカウントログイン後、他のアカウント認証すれば統合。

複数の外部アカウントを1つの内部アカウントにできるように。

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


別派閥のページに複数の支持票を入れられる。複数の不支持票も。

こうすればコウモリはどっち付かずではなく八方美人ということになる。

→無害になる。

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


これがゲストの場合…Wikipediaが目指しているような公に認められたページになる。

これはGoogleでもやっていること。

ユーザー検索履歴が反映されるようにページの順位を変えている)

カスタマイズがフォークソノミーになる仕組み。

見たいものを上位に。見たくないものを下位に。

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


制限を課すようなものではない。

例えば代表の初期値(初期の代表、何も判断材料が無いときの代表)に同じ派閥の人を参照する。

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


自分の日記のために。活動記録のために。各サイトのTwitter連携のようなもの。

自分のアカウント→トラックバック先を設定しておく必要がある。(利用者設定

内容付きページ一覧 Edit


特に短いページが多いときに。

検索結果でも。

検索結果は検索キーワード付近を横断的に表示するもの。

文字数で数えて近いテキストのほか、別の尺度で近いテキストも表示できれば…?

カラムブラウザー Edit


iTunesのファセット分類と検索システム。テーブルの列ごとにまとめ。選ぶと選択した列に選択したのと同じ値を持つ行だけ表示。

これをWikiとページに適用すると…列→「タグ」、値→付けられたタグ

ページは非定、フリーフォーマットなので列にあたるものがタグくらいしかない。

見出しなどは重複することがないのでまとめにならない。
  • 検索キーワードの前後の単語
  • 作成年、最終更新年、年と月、年と四半期、半期
  • 最終編集
  • 上位ページ、上位にあるいずれかのページ

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

記法別にする?記法ファセットだと多くなりがちかも。有効なファセットを選びやすいように項目の多いものを強調表示。項目数を出すだけでもいい。デフォルトでファセット名と項目数だけ表示。選ぶと内容一覧を展開。

運用側で何もしない記法を作ってファセット分類専用にするのもいい。

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


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

派閥内はSNS Edit


利用者名から利用者ポータルページは分からないようにして。
  • メッセージはどの派閥経由か分かるように
  • 派閥から抜けると縁が切れるように
    匿名のままのつながりなのはこのため。

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


ダンプで単一テキストファイル化できれば、DB操作で一括置き換えなどできなくていい。

テキストエディターで一括・逐次処理の両方で置き換え可能になる。

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


バックリンク一覧、ページあたりのバックリンク数付きで、テキスト解析。

「予定」のバックリンク一覧なら忙しい日が濃い色で表示されるスケジュール表。

「重要」や「※」ならページの重要度。

タグを対象にすると厳密になる。

体裁をカレンダーにしたり。

数を色にマッピングするならリストよりテーブル形式で背景を塗りつぶすような形に。

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

ダンプにはindex.htmlを Edit


ダンプファイルには一覧をつける。

HTMLで。index.htmlで。

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


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

Twitterから Edit

  • @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 「会話」の流れも使える。

ページの追跡 Edit


外から存在しないページに来た時、新規作成よりもそのページはどこに行ったか追跡してくれたほうがいい。

削除されていたり追跡出来なかったら(できれば当時の)過去バージョンへ。

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


Wikiは人力リソースに応じて編集できる量を変えたほうがいいので。

誰も編集しない「枯れたページ」は凍結していい。Spam対策としては凍結すべき。

機能として実装するなら、

作られた時点ではページ内容を100%変更可能、編集されずに時間が経過するにつれて一度に変更できるデータ量が0%まで変化。

リセットは権限保有者が行なう。ので、リセット要求を権限保有者に出せるように。

追記のみのコメント欄は自然凍結しないように設定したほうがいい。

サイト単位の完全な凍結管理者が行なうほうがいい。

Wikiではなくなるので。完全凍結していないのならフロー式の投稿くらいできないと。
  • -------

半凍結の状態をどう表現するかは再考。

データ量か?編集可能箇所は全体?編集箇所が連続するのを禁止?誤字修正くらいはいつでもできるように?

既存データの削除は禁止?追記だけ?

すぐに編集できないとWikiWikiでなくなってしまうので、編集可能にしつつSpam対処の労力を一個人に求めないように。

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


ページ構成というものはない。

検索などで構成、その中を見て回る。

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

  1. ぶっ込む
  2. あとづけのページでグルーピング(グループ化)
    検索リンク作成、検索記法の結果を埋め込み、それが検索にヒットするように。
  3. グルーピングページにさらに情報追加
    関連語関連ページへのリンク
  4. 検索で探せる
    グルーピング用ページがヒットするとリンク先まで表示。

    BackLinkではなく、順方向リンク

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


「バグかな?と思ったら」

公式サイトに全てのパラメーター例。無いものは追加できるように。

例から問題が分かるように。例に無い挙動をするならバグレポートへ。

学習する検索 Edit


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

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


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

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


管理者アカウントへ。複数登録、アカウント選択なども。

OAuth

リストアは必要ない。ファイルダウンロードして、通常のリストア。

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


最終バックアップから更新されていなければ要らない。

不要なバックアップになるとしてもバックアップは作る。

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


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

なんでもリンクで。 Edit


下位ページリンク、その他の関連もリンク

関連名が要る?リンク属性

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

置き換え機能 Edit


設定では他の機能より優先

これで他の機能のパラメーター固定値記法を定義

タグ Edit


Elementクラス名:値クラス名(同義と見なせる範囲ごとに付けた範囲名)

gram:0-1000

タグクリック→リスト開く、リストには0-1000などの値クラス名

それを多段対応。

gram:0-1000:0-100

リストを開かず選択すると、検索キーになる。

Elementが出力するタグはいつでもどこにでも表示可能。でも検索結果(サブセットWiki)以外で見る意味は?

検索しかないのか Edit


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

KJ法で下位ページ説明 Edit


KJ法Aのラベルが内容を表す点、内容の集約がラベルになる点を参考に。

すべてを集めたラベルがトップページになることを説明。

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


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

何かのヒント Edit


「迷う楽しさのあるwikiスタイル

「もやもやWiki」

フローとストック Edit


フロー…板、Twitter、ブログ(日記)とコメント

ストック…ブログ(備忘録)、Wiki、HTML、ちゃんとした板

ビューの違いだけで切り替え可能。

フロー…一つのURLで新着順に複数の記事表示。そのURLで書かれたことを全て表示。

ストック…一つのURLで最新版だけ表示。最新版がそのURLの

記事全てを包含、踏襲している。

フロー…サブページ一覧と消えていくページ(消費期限付きページ)、で。

ストック…通常のWikiページ
  • -------

wiki ブログにするには

管理用メニューを縮小すればいい。

トップ…ブログタイトルでいい。

リロード…不要。

新規…記事を書く

一覧…記事一覧

単語検索検索

最終更新…wiki特有 *

ヘルプ…システムの配布サイトへ、とプロフ

編集…表示中の記事を編集

凍結…表示中の記事の編集にパスワードをかける

複製…不要。コピペでいい。

名前変更…不要。編集で名前変更。または新しく作って消す。

差分…RSS、ping、wiki特有

バックアップ…wiki特有

添付…不要。編集の一部に。

編集用メニューを作れば、ブログに近づく。

閲覧メニュー、編集メニュー(閲覧メニュー含む)、管理メニュー(編集メニュー含む)

差分など、過去に遡る操作は閲覧メニュー?

つまり、ユーザーロール分け。閲覧も編集権限に違いなし。メニューが異なるだけ。
  • -----------------

メールがフロー、Wikitextがストック

メール投稿をフローとして…Wikipediaでの「ノート」。会話。提案・サジェスト。

あるページに投稿されたフローな情報は「そのページについての批評・提案」。

フローな情報の見せ方はどうするか?

Wikipediaのノートのように表ページナビゲーション的な場所にリンク埋め込み

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

  • WikiはTwitterやメールのような送りつけられる形を取り込めるようにならないか?ページ表示、フォーム表示、書いて送信は手順が多すぎる
  • 送りつけ投稿でもいい感じ(読むためよりも再編集にいい感じ)にまとめるには?
  • メールやTwitterをメーリングリスト的に使い、やりとり・流れる情報をいい感じにまとめるには?
  • 意見の衝突、共通点がわかりやすいように。人力を利用して。返信に2文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを2文字程度で返信・意志表示できるとか。
  • フロー投稿のまとめ(セグメント化)
    同じ人から・同じページへ・同じ内容(?)
  • テーブル記法を使って左右に同意・異議を振り分け。一覧しやすくするとか。Twitterアカウントにもページを作って人別に一覧しやすくするとか。

編集コメント Edit


特にページ削除時に必要。「なぜ」の推測材料がないので。

編集ステップを増やしたくない。

「投稿完了しましたが、よろしければコメントをどうぞ」で無視することも可能、のようなUIで。

ToDoバルーン Edit


ページページ内の位置を指定して吹き出し表示。

完了したら割る。

位置は見出しページ)でいい。

ページ名変更に追従するように、ページ内にバルーン用データを置ければいいけど。

それをクライアント側で吹き出し化。ページヘッダーにスクリプト埋め込み

ユーザーでなくシステムが操作するデータをページに設けるということになる。

編集者間のやりとりに。本文に重ねて見せるノート・コメント・注意書き。

カスタムヘッダー Edit


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

Sandboxでは履歴を残さない Edit

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

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


で遅い感軽減。下位が上位に依存していなければ。

速いときはサブページを埋め込んだページ生成。クライアント側はその分を通信せずすぐレンダリングできる。

下位ページレイアウト Edit


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

編集機能 Edit


サブページを複数選択して分割か、

サブページを並べ替えて切るか。

→両方。並べ替えて切るのはスマホで有利

tel:記法 Edit

スマホ Edit


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

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

スタイルテーマ Edit

図と自動リンク Edit


図中のテキストがWiki内のページ自動リンク

クリッカブルマップ。

テキスト、その位置、図を別々に受け取れないと。

自動リンクするために図(を表すページ)の(ページ構造内での)位置を決めないといけない。

Turn off the lights Edit


テーマ切り換えUI。明/暗と中間の夕方があればいい。

実装はテーマ変更するようなリクエストを生成するだけ。

ブラウザーに状態保存。…だとどうテーマに反映させるか問題。スタイルテーマ自体をブラウザーに保存できないと無理。

:t/スタイル :t/テーマ :t/即時編集[?]

最近の入力 Edit


「最近編集されたページ」ではなく、最近このWikiに入力されたテキスト。新しい順になっているだけでWiki稼働時からの全てのテキストを保持。ページとは独立した記録。純粋なログ。消されたテキストも保存。

体裁は…

ページ名特定版リンク

入力されたテキスト

入力されたテキスト

入力されたテキスト


どこかに書いておけばポケット1つ原則で取り出せる。

ページネーション Edit


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

記録系機能 Edit

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

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


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

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

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


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

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


見解名などが指定されていないとき→代表を返す

代表を返す場面で代表拒否が指定されていたら…

→ワイルドカードに当てはまるページをリスト表示

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


マイリストは一時的な履歴コレクション

今の考えをたどるためのパンくずリスト

ß

ページの重さ Edit


リファレンスカウントと含むセクションそれぞれの長さを考慮して、重要度算出、表示。

式は管理者が自由に変えていい。記法と違い他サイトから来た人のことは考えなくていい。

タブビュー Edit


1ページの中に複数ページ表示。リンククリック→左カラムにページ展開、遷移前のページは右側へ移動。

古い履歴が右へ右へ移っていく。

古いページからの分岐はその左側にでも展開。分岐は左側に壁を作る。壁は直接のつながりが無いことを示す。

カラムの移動、カラムを次の壁まで移動、カラムを先頭に、カラムを末尾になどの操作も。

*(ワイルドカード) Edit


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

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

…でウェルカムページ
…*…
*…*

…なども。

?も同じ意味。

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


外部サイトのイメージなどは表示中にレイアウトされるため操作性が悪くなる。

あらかじめサイズだけでも読み込んでおいて、max-heightなどのスタイル属性でサイズを指定しておく。

スクロール方向のサイズだけでいいので、heightだけ。

サイズ情報は適当に更新。リンク切れ監視と同じタイミングで。

画像自体のキャッシュにしたほうが読み込み時間が安定していいかも。

加えてキャッシュしない(サイズを保存しない)オプションも。

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


言葉(ページ名)を属性付け。それを色と大きさで表現。(書体でも?)

言葉の属性はどの言葉と関連しているか(ページ同士の関連具合)で決定。wikiの発展にあわせて変わってもいい。

関連度が強いのは近い色、疎遠なのが違う色になっていればいい。

基本色を利用者設定スタイルテーマ次第にすればいい。それを元に他の色も決定。

これで文字ばかりのページタグクラウドのような体裁にする。文字ばかりならどうレイアウトを考えても平坦になってしまうので。

読む人が気になるような言葉を強く見せたほうが、どのページにどんなことが書いてあったか印象に残りやすい。

俯瞰してページ内の言葉の傾向をつかめるのも大きい。

読まずに見るだけで分かる。

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


あるいは本文プレビュー

検索結果の一覧では検索にヒットしたあたり。

最近の更新一覧では編集されたあたり(の最新版のほう)。

履歴一覧では編集されたあたり(の新しいのほう)。

バックリンク一覧ではリンクがあるあたり。

…など。

呼び出し側によって同じページ一覧でもダイジェストが異なる。

常に全てを用意するのは非効率なので、場合によって異なるコードを実行しないと。

権限の表示にアイコン Edit


錠と鍵 錠…要求する権限 鍵…ユーザー側が持っている権限ユーザーページで見せる

ページテンプレートに絵を埋め込むだけ ユーザーページは書き換え自由なはず。 消されるかも?

コードインポート Edit


Git→全単語(シンボル名)1つごとにページを作る リポジトリないのファイルをインポートして、自動リンクでクロス リファレンス作成

構文解析できるなら 変数、クラス、などといった分類でページまとめ

コードはコード用の記法

インポートしたぶんとは分けて説明を入れられるようにしたい 次のインポートでも説明は残るように
  • -------------------------------------
    自動的にページを作るのなら自動的に消す方法も必要。

索引 Edit


自動リンクリンク検索

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


という体裁で。リンク対象はフルパスのページ名。パス内単語をど ういう順番にする か?全並び順をリストするか?

で、自動リンクだとページ作らない限りリンクにならないので、 Wikipediaやはてな キーワードやニコニコ大百科にもリンク

※難しければ明示的リンクだけでも

ファセット分類 Edit


iTunesのような。タグで実現。

に加えて、フォーカスに関連性を付けられるように。関連性はリンクで。フォーカスをページ化すればリンク可能。

・類似

似ているフォーカスをリンク別名。いずかを指定すると、類似フォーカスを全て指定したのと同じ効果。

・包含、包括

階層化されたタグのような。一つのフォーカスが複数を含む。上下関係があって上位を指定すると下位をすべて指定したのと同じ。下位を指定しても上位は含まない。

類似/包含はリンク関連名で区別。関連名が不適切だとほかの目的のリンクとなる。

ファセット)とフォーカス(値) は定義なし。存在していれば有効。

フォーカスには日付のようなテキストではないも入れたい。(ファセット指定するのではない。一つのファセットに複数のが対応してていい)
  • -

(WYSIWYGの代替の)テンプレートと組み合わせると良くなるように。

パーソナルデータベースのフォームのように項目が分かれていて、それぞれの項目がファセットになるように。

定義なしで非定フォームを修正・項目を追加しても古いデータと一緒に検索できて、しかも項目ごとに選択肢で絞り込み検索。指定した項目だけを対象にキーワード検索とかも。

おかえりなさいメール Edit


久しぶりのログインだとメール送信。メールアドレスが登録されていることを注意。

「久しぶりのログインなのでメールを送りました。このメールからでもパスワード変更、アカウント削除ができます」

パスワード変更、アカウント削除予約ができるのは…

ログインした人

・おかえりなさいメールを見られる人

「パスワードを忘れちゃいました」リンク→IDとCAPTCHA入力でおかえりなさいメール送信。

アカウント削除予約 Edit


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

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

いろいろフォーマット Edit


フォーマット名を書いて、あとは一つの囲みの中にフリーフォーマットで書いていく。

あとは自動認識でいい感じにエレメント化する。

実装は改行区切りや空白区切りで。

フォーマット変換も。選択すると再認識。ユーザーが書いたことは変えずにフォーマット名だけ変更。

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


スクリーンショット、キャッチコピー、説明、トピックパス

合間に豆知識。

Xは落ち着ける住空間を提供します。

EverWiki Edit

WikiEngineをまとめたWikiEngine Edit


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

何かを書くと「で?」 Edit


でさらなるアイデアを促す。

というレスポンスメッセージ

セクションのスライドショーで、一段落つくまでの文章を全画面に表示。

そこになんとかのチェックリストとかなんとか発想法に沿った質問を。

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


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

…という説明。

参考に Edit


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

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


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

"X POWERED" Edit


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

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

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

@場所名 Edit


で場所記法

ほか、GPSからの経度緯度も。

Twitterより、@名前でTwitterユーザープロフィールヘリンク。でもWiki内か、インターリンクWiki内にそんな名前のユーザーがあればそっちへリンク。存在確認してリンク先を変えたり曖昧さ回避ページへ。

id:ではてなIDへリンクとかも。

ブレインストーミング Edit


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

発想の流れ Edit


具象に裏打ちされた抽象になる

→必要な分だけをコンパクトに考える

→→新しいアイデアを生み出すには必要なこと'だけ'集めること

→→→

局所検索、局所自動リンクサブセットWiki

サブセットWikiは「小さなKJ法」

グルーアイデアでつなぐ。足してまとめる、まとめるために足す

つながったら抽象化、一目で理解できる形に。

おすすめ検索キーワード Edit


年中行事を先読み。ユーザー数が少ないのでソーシャル手法でトレンドをおすすめするのは無理。

いろいろな状況を検索キーワード化、毎年この時期にはこのキーワードが活発化するというのを検出。

日時、季節、利用者ページ名(Wiki内のキーワード)

コード内のToDo Edit


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

その他にもFixMe:なども。

活用法 マイメソッド Edit


何か思い付いたとき、何か解決したときに「何をしたか」をタグにしておく。

それを集めると自分の技、思考の道具がわかる。

有名な発想フレームワークかも知れないし、その一部かも。

既存フレームワークを基にしつつ独自部分があったり、知らないうちにカスタマイズ

してるかも。

実装

具体的には文中の「これを…すると」の部分をリンクにするだけ。「…すればいい」

とか「…してみた」なども。

本文をタグ化することで妥当なタグ付けになる。思考をタグ付け用に切り換えなくて

いい。

原文(生きている文、実用した文章)を利用するのがWikiらしくていい。

2ホップ先は共起相手 Edit


リンク(バックリンク含むので双方向)の2ホップ先は共起相手と同じ。

これの1ホップ先(共起文脈)に注目。

1ホップ先をグループ、自身と2ホップ先をそのメンバーとすると、「メンバーが似て

いるグループ」をまとめられる

まとめなくても「このページと…(グループ名)…つながりのページたち」というリス

トを「…(グループ名)…つながり」ごとに出せる。
ページなんとかと…ページなんとかと…ページなんとかと…
…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ

関心空間のようなつながり。

タイル状表示。

で、サイト中にあるすべてのページについてまとめると…似ているページ検出になる。

→これはただのリンク調査。同じリンクがあれば似ているページとなる。これを1ペー

ジだけ取り上げてできるということ。

サイト分析 Edit


傾向検出で。

…などでwikiを分析。
  • -
    これで発想支援や

    さらなるまとめ支援。

日記なら自分を知る機能になる。

「…をした次の日には…しているという傾向」とか。

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


スタイルテーマは読む側のもの。

書く側にとってはテーマがなんであっても普通のwiki。

編集が不自由なwikiならスタイルテーマの意味が強くなる。

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

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


外部サイトにあるボタンはコンテナーに入れて、一度に表示させたい。

レイアウトが何度もやり直しになるのは見づらいので。

内容によるテーブルサイズ決定と同じ問題。

外部サイトが提供するコードをそのまま貼れるコンテナー。

ページを読み込んで、読み込みの進捗表示が終わってからコンテナー内を読み込みた

い。

ここは遅くてかまわない。本当に遅延していい遅延ロード。

UI モバイル用UI Edit


下部にボタン用パネル。

ボタン区切りに溝を設ける。溝は切り抜き。隙間からページが見えるように。

これで画面を広く見せる。溝がなければ画面が小さく感じる。

それと画面隅に三角形のボタンを配置するとか。

ページがめくれてる感じにするとか。

サイドメニューバーは引き出しにするとか。タップやドラッグインには無反応、画面

端からのドラッグだけに反応。

検索 Edit

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

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


WikiTextを作って、それをWikiEngineで処理。HTMLやXMLを得たりできるように。

%%利用方法→開発方法が分かりやすいようにするためにWikiTextを使う。UI(記法)が

APIになる。%%

→To...を呼べばいい。URLパラメーターを条件にしていろいろ判断するような処理は

Action(インスタンス生成後の処理)でやることにして、To...は引数だけに依存する

ようにプラグインを作ってもらって。

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


量をインデックス化するには値1つと誤差の2パラメーターで指定。インデックスなの

で広く指定できれば十分。

でも同値(100%)だけでなく0%以外をすべてインデックスにするので、インデックス化

自体が無意味。

ページ要素プラグインにインデックス項目生成をさせるなら、列挙可能な場合だけで。

列挙不可能な場合は*。どんな検索でもそのページが評価されるように。

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


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

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


%%元仲間には空のページかほかに指示しているページが表示されることになる。アナ

ウンス。%%

復帰に手間がかかるので、何度も繰り返されると困る。

投票を取り消すにはコストがかかるように。それか不可能にするか。

→不要。

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


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

…にまとめたページ

探索のために。

→ルートを始めとする上位ページ下位ページの集約…という考え方はもうない。や

るならページごとの集計になる。

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


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

全て不支持はできる。→支持1つまで。ほかは考えないということ。

分派すれば支持を入れ直せる。が既存のものを支持できない。

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

で無理をなくす。

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


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

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


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

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


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

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


テーブル記法ではなく。

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

記法を介す必要なし。

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


フォーマッティング、フィルタリング、スコアリング

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

検索クエリーもページ

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


自然にまとまるよりも、まとめる作業のほうが大事かも。

まとめる作業は知識の反芻、再学習。システムがやると発想に必要な入力がなくなっ

てしまう。

まとめ作業中は情報を集めた人自身が閲覧者になる。閲覧者は投稿者以上に情報をつ

なぐ役目を持っているので、それを投稿せずに投稿できるようじゃないと。

獣道

まとめる作業 Edit


まとめる作業は

検索(ざっくりと)、さらに検索(小分類の中を)、細分化、読む、書き直す、加える、

ここでも検索と分類と細分化。

KJ法的に適当なメモを探す。

まとめる作業支援 Edit


まとめ支援は検索人力

そのための支援。

メモ書きをするような。

欲しいデータが手に入るような。0ステップか、ほかの作業中に手に入るような。

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

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


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

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


プレビューするならニコニコ大百科のようにチェックボックスにする。

紛らわしいのでボタンにはしない。

チェックはオプトアウト。でもよく編集する人向けに利用者設定でオプトインにもできるように。

チェックボックス自体を無効化したりはしない。

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


ページ末尾に置くと遠すぎるので。

同じ見出しの最後に表示。

関連情報にAmazonなどの商品も Edit


Wiki内からローカルな情報を、Googleで一般的な情報を、Amazonでモノを。

外部リンクにfavicon併記 Edit


apple-touch-icon.pngがあればそれを優先。

apple-touch-icon-precomposed.pngがあればさらに優先。

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

インデント Edit


行頭の空白類は無視したい。

特に全半角スペースとタブ文字を。

WikiTextのままでも読みやすくするためにインデントできる。

改行文字も無視できればより読みやすくできるが…。行頭空白の連続+改行文字を無視するのならできそう。

それよりもテキストエリアの行間を広げられればそちらのほうがいい。

場所によって変わる補完候補 Edit


テキストボックスに補完指定。

補完リストの内容を変える。

項目セットと、動的な(入力中に収集するような)項目も。

項目セットはページの内容。

ということは補完は特定の単語を含むページ

動的な項目はwikiの機能呼び出し?機能名や呼び出しパラメーターを補完ページに書いておく?

顔文字はインラインタグ Edit


顔文字記法。CSSセレクター付けて。

普通のテキストと見分けは付かなくていい。

リンク先はタグと同じ。

自然にいつの間にかタグ付けできる。

近い顔文字を同一視したい。近いページを探せれば十分。

特定単語がタグ Edit


自動リンクと同じように、記法でも何でもない言葉がタグ化。

クリックで検索可能なだけ?

ページ属性を特定のものにしてページを作ると、自動リンク先が検索になるとか。バックリンクだけのページとも言える。

タグっぽく見せたほうが使い道があるかも。見た目が変わらなければ範囲選択→検索UIのほうが使い勝手はいい?

古く見えるテーマ Edit


スタイルテーマ

ページセクションの日付に応じて、文字はかすれ色はあせていく。

使う日付はセクションに書かれている日付記法か、それが無ければセクションの更新日時。

日付が複数書かれていればそれらの平均値(に近い実在する日付)にする。

これで意図的に古くすることができる。

アイデアノートに。古いアイデアは更新するよりも保存しておく方が簡単。必要なときに見つかればいい。使うアイデアだけ更新して保守。

テキストボックスに選択文字列 Edit


常設テキストボックスには常に選択文字列を入力

例えば検索とかページ新規作成とか

新規作成ならDanglingLink不要になる。

明るく暗くをランプで Edit


暗いスタイルテーマにランプを含める。

位置はページ端。スクロールで見えなくなる。

左上にドラッグして明るく、逆は暗く。

青い光。

特に説明は要らない。隠し要素。

RecentChangesビューにwikiが発展する様子を表したい Edit

選択文字列に一言コメント Edit


コメント投稿では選択文字列と選択位置も記録

位置はすぐ上の見出しIDとその見出しからの文字数

そのページ編集者かウォッチャーが閲覧したときに本文上にも表示。

位置指定が曖昧になりやすいので、最も近い位置に表示。

見つからなければ非表示。そのため一覧も用意してそこにも表示。

一覧から表示位置へジャンプ可能に。逆方向にも。

X-Runtime Edit


処理時間を出すならHTTPヘッダー X-Runtime でいい。

なぞなぞ認証 Edit


なぞなぞに正解した人に一時的な・ページ毎に異なる編集権限付与。

コメント#1644034 | Wikiを用いたプロジェクトでの議論ってどうしてる? | スラッシュドット・ジャパン

IQ-Auth

なぞなぞ認証機能を追加し、認証の設定をMyはてなで一括して行うよう変更しました - はてなダイアリー日記


例えばページ作成者がなぞなぞ設定にする。問うのは議論の争点。選択肢式で複数、あるいは文字入力で1問。

ゲスト(非ログインユーザー)にも適用できてWiki向き。

1IDに1パスワード Edit


複数統合もしない

オープン認証だけ Edit


パスワードを保管しない

オープン認証ではユーザーIDにサイトドメイン追加 Edit


anon@twitter.comなど。長くなる。

オリジナルテーマを作って広める Edit


Chromeテーマやブログテーマとして。

1ページに集めるだけで「そのうちまとまる」と言えるのか? Edit


ぶっこんでおけばそのうちまとまる仕組み

パーマリンクには内部名を使う Edit


分かりやすくするなら、Amazonのようにページ名も付ける。でも使うのは内部名だけ

汎用プラグイン記法はどんな書式? Edit

<<plugin p1:... ...>>
<plugin p1="..." ...>
#plugin(p1=..., ...)

複数の記法を許可。全角文字でも。

名前付き/匿名パラメーター混在可能。匿名パラメーターには左から順に自動当てはめ。

草稿 Edit


NOINDEX期間のを「草稿」として、最新版とは区別。最新版草稿でないの中の最新。

権限を持ったユーザーはNOINDEX期間を終わらせることができる。

で、草稿を明示指定しないと誰からも見えない。草稿があることはバナー表示でわかる。履歴から差分表示するときなどはを明示しているので普通に見える。

これでWebAPI経由でページを外に出せる

ブログパーツとか、DataWikiとか、iPhone向けのHTMLアプリのUI作成とか

メール送信記法 Edit


どこに、いつ、

ほかの記法で書けばそれぞれのUIその場編集ができたり。

アクティビティのカレンダー表示 Edit


リビジョン含めた自分による更新履歴をカレンダーに書き込み。数が多くても見やすいように日付は一列レイアウト。画面スクロールあり。

tipsかるた Edit


tip of the dayを日本風にすると…Wikiかるたか、今日の「できる!」なんとかWiki。一文字目の重複・欠けがあっていい。

バックリンクと一緒に名前変更 Edit


ページ名変更で、1つのWikiにある全てのリンクも変更

名前のリファクタリングを可能にする

リンクオブジェクト向けの変更履歴に変更前後の名前を追加、リンクオブジェクトは可能なときに参照、反映

保存を伴わなくていい?次もまた反映しないと

いつ反映されるのかわからないので、変更履歴を消せなくなる

変更後に作られたリンクにまで影響してしまうので、やはりすぐ反映させないと。

よく使うコマンドを上げる Edit


よく使うコマンド枠を設置。

既存のメニューは変えない。

ナビゲーション編集時の書式・ヘルプ表示なども含めて。

前後ナビのデザイン Edit


複数のナビを同時に生成するので、スタックのできるデザインに。

ページは空でも消さない Edit


ページ名を空にすると消える。

見出しだけを書くと空の下位ページを作る。で辻褄合わせ。

つまり、アクセス手段がなくなると消えるということ。でもOrphanは消さない。そのOrphanページ編集でアクセス手段がなくなるわけではないので。

APIバージョン Edit


プラグインになるクラスすべてにAPIバージョンの指定を。「APIバージョン…を使用中」という表明。

プラグインバージョンではない。

それをどう判断するかはフレームワークによる。

spec:1.0.* など。

利用者ページに書くこと Edit


利用者ページには設定というよりもユーザーが表明していることを書く。

検索には高いレスポンス性能が必要 Edit


または繰り返さなくていいような検索結果…UXを。

検索はシステムも使うので、1回のレスポンスまでに複数回検索を使うことになる。

エクスポート Edit


テキストで、UTF-8やShiftJISで。

SVGで1枚に4ページ掲載(4in1)とか。

ePub、PDF、E-InkデバイスやKindle向け。

Wikipedia形式。
  • -
  1. ダウンロード
  2. Webブラウザーで開く。どうなるかはクライアント環境次第。
  3. 交換後URIを共有、メールとか

URLを貼るとブクマとも表示 Edit

UI 画面切り替えには前後画面に1つだけ共通点を Edit


クリック、項目がオレンジ背景に → 見出しが背景オレンジで表示、背景色がフェードアウト。
  • -
    色を共通点に使うのなら、全体的に白紙風デザインに。

    1つだけしかない共通点が目立つように。

ぐにゃぐにゃできる検索結果 Edit


ビュークライアント側にも分割。フィルタリングやソートを可能に。

サーバー側では関連情報を含めて取得。情報が多すぎてもクライアント側で要求にあう情報に加工できればいい。

フィルタリングとソートを、縦/横方向にできるように。横ソート/フィルタリングは手作業で。

…と、結果中に関連項目があればツリー化。関連元でまとめ。関連元が親になる。

1つの親に複数の関連名があるので、それをどう区別してグループ化するか。→親→関連名→子にすればいい。

関連を持つのはページくらい。

ツリーだけど、列は親子で共通。一覧性を損ねないように。

ツリー以外にも色分けでグループ化とか。行入れ換えはしなくていい。セルの背景色を変えるだけ。

ぐにゃぐにゃするために、サーバー側でもクライアント側でもフィルタリングとソートを。

ページロード時に枠しか見えないのは不満なので、サーバー側でのフィルタリングとソートの結果をデフォルトにしておく。その後クライアント側での操作でクリア、再描画。

サーバー側では普通に検索結果を作るということ。クライアントと機能が重複する。

実装では

検索要素の出力を、テーブル要素に与えて。テーブルHTMLにはクライアント側のフィルタリングとソート機能を持たせて。

テーブルにはセルごとの背景色…は要らない。どの列の値を背景色に反映させるか変えられればいい。

ファセット検索の機能もテーブル要素に。集計とフィルタリング。

テーブルのフィルタリング機能に、選択項目のハイライトを。

ブラウザー上でセルを選択すると、同じ内容を持つセルをハイライト表示。選択したセルも同じスタイルでハイライト。他のセルを暗くしたり淡色表示にしてもいい。

Wikiの分かりにく Edit


書き手が複数いる。大勢が全体を把握せずに編集。流れがなくなる。→分かりにく

でも全体を把握しないと編集できないのでは書き手にとって分かりにくい。

書き手の分かりやすさと読み手の分かりやすさを両立するには?

起承転結の起と結が全ページにあればいい。

コンテンツヘッダーにはの作成日と著者リスト、直近の親ページ名でもあればいい。

起結はページ埋め込みで。つまり書き手が気をつける。「…を…するシリーズ。全15回を予定しています。」のような第一段落を埋め込みように作っておけばいい。

自動化したいなら親ページ継承される属性に入れておいて。←これがコンテンツヘッダー

機能/前後ナビ Edit


Wikiの:t/分かりやすさのために。

兄弟ページ間をつなぐナビゲーションページ名で関連が決まる。

前後の順序は一定。変えるならサイト設定継承可能なページ属性で。

これをページフッターやコンテンツヘッダーに入れておけば、日付をページ名にしてあるブログでも有効に使える。

ページを見ることなく前後ページをたどれれば、読み手が細切れな内容のWikiで分かった感を得る手助けになるのでは。

兄弟ページ間での共通のコンテンツヘッダーと組み合わせて使用。

super要素 Edit


継承可能属性の中で使うために。

ページを表す記法を。

これと属性名指定の記法を組み合わせて使用。

汎用記法でいい。

ページ />>>-><<<ページ属性 コンテンツフッター />>> のような。

クリック、打ち込み、通知 Edit


UIでの操作は3種類。

ユーザー→システムはマウスクリックとキーボード打ち込み。(で、レスポンス→またクリックへ)

システム→ユーザー通知(→クリックへ)

…くらいで事足りるはず。

通知方法は何種類も考えられる。

キーボードから打ち込むのは文章も記法もある。

クリックは見たものに反応するだけ。フリックや長押しもあるかも。

ユーザー→システムは文字データ。URIも文字。記法も文字。

システム→ユーザーは文字とその他メディア。でもこれはユーザーが入力したもの。

まず書く Edit


使い方を考えたとき、やろうとしたことまでが遠い。

読むにも書くにも「目的のページ」がある。そこにたどり着くまでには広告だけでなく、ログインメッセージもパスワード入力もサイトの更新情報も、それ以前のアプリケーションアイコンやブックマークのリストも、すべて邪魔。

(その場では)使わないキーボードのキーさえ邪魔。

で、まず何をするか(ToDo)を書けるように。
  1. Wikiを開いて右上欄に文字を打ち込んでEnterか、OpenSearchで一言書く。
    これでセッションページに記録される。
  2. Wikiがなにか提案
    検索結果など。これは動的ナビゲーション
  3. ユーザーが判断
    ToDoは記録済みなので判断が入ってもいい。何をするかを忘れてしまっていい。

あとは普通に編集など。

右上 Edit


Spotlight風な右上。

/やタップでフォーカス取得。

モバイル用の専用クライアントならEvernote for Androidのようなフリックで現れる画面にSpotlight風な入力フォームを。ページ上にはタップできるものが散在しているのでそれ以上何も置けない。普段は読み専用、フリックで書く用のUI

右上には新規ページ作成の機能も。

PukiWikiページ作成のように、入力されたページ名が既存かどうかで読み/作成の両方できるように。

打つ→選択肢から「(打ち込んだページ名)作成」を選択→ページ作成

右上がページ作成の「ページ名」欄になるような。

とりあえずToDoを書けるように、Enterキーで打ち込んだテキストを残す。セッションページに記録。

複数行を貼り付けても残るように。複数行を入力したら複数行表示に拡張したい。

メモ化のキー Edit


個人情報が一般公開されないように、メモのキーにはセッションキーを含めて。

Wiki 編集UI リバートよりも前コピペ支援 Edit


に戻すボタンよりも、前をコピペできるビューへのリンク設置。

不要なを隠すためであっても、リバートではなく新しいにする編集であるべき。

お手軽リバートボタンならプラグインテンプレート書き換えで。

管理者用のビューテンプレートに追加しておけば一人運営に便利。

一秒以内の編集ボタン→投稿ボタンには応じにくい Edit


秒単位でしか時刻を管理しないとして、他の利用者編集ボタンを押したりすると、最新版の判断ができないから。

編集ボタンを押す直前に気付きにくい荒らしがあったら? Edit


押してからも、投稿ボタンを押すときも気付かないとしたら?

自動的に出る「追記」 Edit

リバート管理者グループのものでいい Edit


荒らしと不服な編集は似たようなもの。リバートの省力化は特権を持つ利用者向け。

内容依存なFoldingTextはできないか? Edit


Gmailのように同じテキストが省略されるようにするには?

・省略単位が必要

Gmailではメールごとに数行の重複があれば、行単位で省略。この「メール」にあたる単位は見出し

・一文字だけ異なる行があったらどうするか

・省略して何を残すのか?

日付で分ける以外の目次インデックス作り? Edit


UI、閲覧しやすするもの

TOCのインデックス。

ログなら日付、Wikiならページ名、掲示板ならトピック名と日付。

…だけ?

名言 Edit


名言をどこに入れるか

インストール直後

エラー時

アンインストール直前

セッションの終わり(開始時は邪魔)

読みにくさ解消 Edit


コンセプト/Wikiは読みにくい

見出しは分割←短いなら読みやすい…ではなく入口を増やすためのもの。ここから読もうかというもの。

見出しごとにつかみがいる。というか見出しはつかみ。続く第一段落はつかみの完全化。そして起承転結へ。第一段落まででここにはなにが書いてあるか判断できるように。見出しは入口であり入らずに通り過ぎるときの出口。

というのを見出しごとに行なうには…

テンプレート?自分への注釈?

完全に書き方の問題。

追加と編集は別権限 Edit

universe->space->entry->side->section->revision Edit


1つのsideに複数section。

オブジェクトはsectionのみ。

上下関係は考えなくてもいい。すべてSectionの属性

ファセットWiki Edit


http://meatballwiki.org/wiki/PeriPeri

"Facet Terminology"