1. <<<
  2. :i/埋め込みオブジェクトの事前レイアウト
  3. :i/自動リンク・リンクを、色分け・サイズ分け
  4. :i/ページ一覧にダイジェスト
  5. :i/権限の表示にアイコンを
  6. :i/コードインポート
  7. :i/索引
  8. :i/ファセット分類
  9. :i/おかえりなさいメール
  10. :i/アカウント削除予約
  11. :i/機能/Google計算機の結果に置き換え
  12. :i/いろいろフォーマット
  13. :i/紹介はマンションやホテル・旅館の紹介のように。
  14. :i/EverWiki
  15. :i/WikiEngineをまとめたWikiEngine
  16. :i/何かを書くと「で？」
  17. :i/サポートはありません。
  18. :i/参考に/円形UI
  19. :i/問題追跡、提案板にアイコン風のテキスト
  20. :i/"X POWERED"
  21. :i/見解は削除に代わる手段
  22. :i/1つのオブジェクトに複数の操作を割り当てるならフリック
  23. :i/@場所名
  24. :i/ブレインストーミング
  25. :i/発想の流れ
  26. :i/おすすめ検索キーワード
  27. :i/コード内のToDo
  28. :i/マイメソッド
  29. :i/2ホップ先は共起相手
  30. :i/サイト分析
  31. :i/スタイルテーマはROM専のため
  32. :i/クライアントビュー上で切り換えたいもの
  33. :i/ツイートボタンやいいね！はまとめて
  34. :i/モバイル用UI
  35. :/検索
  36. :i/インデックス不可能な語をインデックス可能にするには
  37. :i/①・②・③に順序を持たせる
  38. :/見解統合はページの削除と投票×2
  39. :i/バックリンクをまとめたページ
  40. :i/1つ支持すれば他の派閥は不支持になるか
  41. :i/支持を変えて他の派閥に負担をかける攻撃
  42. :i/「はてなの人力質問でwikiをウォッチしています」という表明
  43. :i/文字列からの型変換はExcelでもやっている
  44. :i/CSVファイル取り込みは添付ファイル化
  45. :/検索クエリーは式とページ内容のobj化
  46. :i/まとめる作業をしているときに新発想がある
  47. :i/まとめる作業
  48. :i/まとめる作業支援
  49. :i/「と関係のある」という検索式
  50. :i/ページ名変更をリンクに反映
  51. :i/プレビューはボタンにしない
  52. :i/注釈(note)はセクションを越えない
  53. :i/関連情報にAmazonなどの商品も
  54. :i/外部リンクにfavicon併記
  55. :i/インデント
  56. :i/場所によって変わる補完候補
  57. :i/顔文字はインラインタグ
  58. :i/特定単語がタグ
  59. :i/古く見えるテーマ
  60. :i/テキストボックスに選択文字列
  61. :i/明るく暗くをランプで
  62. :i/RecentChangesのビューにwikiが発展する様子を表したい
  63. :i/選択文字列に一言コメント
  64. :i/X-Runtime
  65. :i/なぞなぞ認証
  66. :i/1IDに1パスワード
  67. :i/オープン認証だけ
  68. :i/オープン認証ではユーザーIDにサイトドメイン追加
  69. :i/オリジナルテーマを作って広める
  70. :i/1ページに集めるだけで「そのうちまとまる」と言えるのか？
  71. :i/パーマリンクには内部名を使う
  72. :i/草稿
  73. :i/メール送信記法
  74. :i/アクティビティのカレンダー表示
  75. :i/tipsかるた
  76. :i/バックリンクと一緒に名前変更
  77. :i/よく使うコマンドを上げる
  78. :i/前後ナビのデザイン
  79. :i/ページは空でも消さない
  80. :i/APIバージョン
  81. :i/利用者ページに書くこと
  82. :i/検索には高いレスポンス性能が必要
  83. :i/エクスポート
  84. :i/URLを貼るとブクマと☆も表示
  85. :i/UI 画面切り替えには前後画面に1つだけ共通点を
  86. :i/ぐにゃぐにゃできる検索結果
  87. :i/Wikiの分かりにくさ
  88. :i/機能/前後ナビ
  89. :i/super要素
  90. :i/クリック、打ち込み、通知
  91. :i/まず書く
  92. :i/右上
  93. :i/メモ化のキー
  94. :i/Wiki 編集UI リバートよりも前版コピペ支援
  95. :i/一秒以内の編集ボタン→投稿ボタンには応じにくい
  96. :i/編集ボタンを押す直前に気付きにくい荒らしがあったら？
  97. :i/自動的に出る「追記」
  98. :i/リバートは管理者グループのものでいい
  99. :i/内容依存なFoldingTextはできないか？
  100. :i/日付で分ける以外の目次インデックス作り？
  101. :i/名言
  102. :i/読みにくさ解消
  103. :i/追加と編集は別権限
  104. :i/universe->space->entry->side->section->revision
  105. :i/universe->space->entry->side->revision
  106. :i/Wikiがニュースフィードアグリゲーターになったら
  107. :i/ページ名変更は見出し変更で
  108. :i/スタイル/スクロールできるなら陰影
  109. :i/重複リンク
  110. :i/属性領域に書いたタグは継承される
  111. :i/メリハリ
  112. Twitterから

<<< † Edit

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

外部サイトのイメージなどは表示中にレイアウトされるため操作性が悪くなる。
あらかじめサイズだけでも読み込んでおいて、max-heightなどのスタイル属性でサイズを指定しておく。

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

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

画像自体のキャッシュにしたほうが読み込み時間が安定していいかも。
加えてキャッシュしない（サイズを保存しない）オプションも。

:i/自動リンク・リンクを、色分け・サイズ分け † Edit

言葉（ページ名）を属性付け。それを色と大きさで表現。（書体でも？）
言葉の属性はどの言葉と関連しているか（ページ同士の関連具合）で決定。wikiの発展にあわせて変わってもいい。

関連度が強いのは近い色、疎遠なのが違う色になっていればいい。
基本色を利用者設定、スタイルテーマ次第にすればいい。それを元に他の色も決定。

これで文字ばかりのページをタグクラウドのような体裁にする。文字ばかりならどうレイアウトを考えても平坦になってしまうので。
読む人が気になるような言葉を強く見せたほうが、どのページにどんなことが書いてあったか印象に残りやすい。

俯瞰してページ内の言葉の傾向をつかめるのも大きい。
読まずに見るだけで分かる。

:i/ページ一覧にダイジェスト † Edit

あるいは本文プレビュー。

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

:i/権限の表示にアイコンを † Edit

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

:i/コードインポート † Edit

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

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

:i/索引 † Edit

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

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

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

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

:i/ファセット分類 † Edit

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

・類似
似ているフォーカスをリンク。別名。いずかを指定すると、類似フォーカスを全て指定したのと同じ効果。
・包含、包括
階層化されたタグのような。一つのフォーカスが複数を含む。上下関係があって上位を指定すると下位をすべて指定したのと同じ。下位を指定しても上位は含まない。

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

ファセット（型）とフォーカス（値） は定義なし。存在していれば有効。
フォーカスには日付のようなテキストではない型も入れたい。（ファセットで型指定するのではない。一つのファセットに複数の型が対応してていい）

（WYSIWYGの代替の）テンプレートと組み合わせると良くなるように。
パーソナルデータベースのフォームのように項目が分かれていて、それぞれの項目がファセットになるように。
定義なしで非定型。フォームを修正・項目を追加しても古いデータと一緒に検索できて、しかも項目ごとに選択肢で絞り込み検索。指定した項目だけを対象にキーワード検索とかも。

:i/おかえりなさいメール † Edit

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

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

パスワード変更、アカウント削除予約ができるのは…
・ログインした人
・おかえりなさいメールを見られる人

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

:i/アカウント削除予約 † Edit

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

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

計算機能と単位変換。

:i/いろいろフォーマット † Edit

フォーマット名を書いて、あとは一つの囲みの中にフリーフォーマットで書いていく。
あとは自動認識でいい感じにエレメント化する。

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

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

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

スクリーンショット、キャッチコピー、説明、トピックパス、
合間に豆知識。

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

:i/EverWiki † Edit

:i/WikiEngineをまとめたWikiEngine † Edit

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

:i/何かを書くと「で？」 † Edit

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

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

セクションのスライドショーで、一段落つくまでの文章を全画面に表示。
そこになんとかのチェックリストとかなんとか発想法に沿った質問を。

:i/サポートはありません。 † Edit

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

:i/参考に/円形UI † Edit

Catch Notesのやワコムタブレット付属のラジアルメニューを参考に

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

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

:i/"X POWERED" † Edit

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

:i/見解は削除に代わる手段 † Edit

:i/1つのオブジェクトに複数の操作を割り当てるならフリック † Edit

:i/@場所名 † Edit

で場所記法。
ほか、GPSからの経度緯度も。

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

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

:i/ブレインストーミング † Edit

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

:i/発想の流れ † Edit

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

:i/おすすめ検索キーワード † Edit

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

いろいろな状況を検索キーワード化、毎年この時期にはこのキーワードが活発化するというのを検出。
日時、季節、利用者、ページ名（Wiki内のキーワード）

:i/コード内のToDo † Edit

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

:i/マイメソッド † Edit

何か思い付いたとき、何か解決したときに「何をしたか」をタグにしておく。
それを集めると自分の技、思考の道具がわかる。

有名な発想フレームワークかも知れないし、その一部かも。
既存フレームワークを基にしつつ独自部分があったり、知らないうちにカスタマイズ
してるかも。

実装方法
具体的には文中の「これを…すると」の部分をリンクにするだけ。「…すればいい」
とか「…してみた」なども。

本文をタグ化することで妥当なタグ付けになる。思考をタグ付け用に切り換えなくて
いい。
原文(生きている文、実用した文章)を利用するのがWikiらしくていい。

:i/2ホップ先は共起相手 † Edit

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

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

ページなんとかと…ページなんとかと…ページなんとかと…
…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ…つながりのページ
………………………
………………………
………………………

関心空間のようなつながり。
タイル状表示。

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

:i/サイト分析 † Edit

傾向検出で。

…などでwikiを分析。

これで発想支援や
さらなるまとめ支援。

日記なら自分を知る機能になる。
「…をした次の日には…しているという傾向」とか。

:i/スタイルテーマはROM専のため † Edit

スタイルテーマは読む側のもの。
書く側にとってはテーマがなんであっても普通のwiki。

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

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

:i/ツイートボタンやいいね！はまとめて † Edit

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

外部サイトが提供するコードをそのまま貼れるコンテナー。
ページを読み込んで、読み込みの進捗表示が終わってからコンテナー内を読み込みた
い。
ここは遅くてかまわない。本当に遅延していい遅延ロード。

:i/モバイル用UI † Edit

下部にボタン用パネル。
ボタン区切りに溝を設ける。溝は切り抜き。隙間からページが見えるように。
これで画面を広く見せる。溝がなければ画面が小さく感じる。

それと画面隅に三角形のボタンを配置するとか。
ページがめくれてる感じにするとか。

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

:/検索 † Edit

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

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

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

どこで定義するか。

:i/①・②・③に順序を持たせる † Edit

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

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

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

→不要。

:i/バックリンクをまとめたページ † Edit

外からの被リンクを

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

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

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

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

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

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

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

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

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

:i/「はてなの人力質問でwikiをウォッチしています」という表明 † Edit

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

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

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

:i/CSVファイル取り込みは添付ファイル化 † Edit

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

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

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

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

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

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

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

:i/まとめる作業 † Edit

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

:i/まとめる作業支援 † Edit

まとめ支援は検索と人力。
そのための支援。
メモ書きをするような。
欲しいデータが手に入るような。0ステップか、ほかの作業中に手に入るような。

:i/「と関係のある」という検索式 † Edit

:i/ページ名変更をリンクに反映 † Edit

ページ名変更をリンクに反映。ページ名変更はリンク変更までの承認を含むとして。
†:i/リンク要素はページ名変更に追従

:i/プレビューはボタンにしない † Edit

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

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

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

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

:i/関連情報にAmazonなどの商品も † Edit

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

:i/外部リンクにfavicon併記 † Edit

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

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

:i/インデント † Edit

行頭の空白類は無視したい。
特に全半角スペースとタブ文字を。

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

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

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

:i/場所によって変わる補完候補 † Edit

テキストボックスに補完型指定。
補完リストの内容を変える。
項目セットと、動的な（入力中に収集するような）項目も。

項目セットはページの内容。
ということは補完型は特定の単語を含むページ？
動的な項目はwikiの機能呼び出し？機能名や呼び出しパラメーターを補完型ページに書いておく？

:i/顔文字はインラインタグ † Edit

顔文字記法。CSSセレクター付けて。
普通のテキストと見分けは付かなくていい。

リンク先はタグと同じ。
自然にいつの間にかタグ付けできる。

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

:i/特定単語がタグ † Edit

自動リンクと同じように、記法でも何でもない言葉がタグ化。
クリックで検索可能なだけ？
ページ属性を特定のものにしてページを作ると、自動リンク先が検索になるとか。バックリンクだけのページとも言える。

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

:i/古く見えるテーマ † Edit

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

使う日付はセクションに書かれている日付記法か、それが無ければセクションの更新日時。
日付が複数書かれていればそれらの平均値（に近い実在する日付）にする。
これで意図的に古くすることができる。

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

:i/テキストボックスに選択文字列 † Edit

常設テキストボックスには常に選択文字列を入力
例えば検索とかページ新規作成とか

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

:i/明るく暗くをランプで † Edit

暗いスタイルテーマにランプを含める。
位置はページ端。スクロールで見えなくなる。

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

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

:i/RecentChangesのビューにwikiが発展する様子を表したい † Edit

:i/選択文字列に一言コメント † Edit

コメント投稿では選択文字列と選択位置も記録
位置はすぐ上の見出しIDとその見出しからの文字数

そのページの編集者かウォッチャーが閲覧したときに本文上にも表示。
位置指定が曖昧になりやすいので、最も近い位置に表示。
見つからなければ非表示。そのため一覧も用意してそこにも表示。
一覧から表示位置へジャンプ可能に。逆方向にも。

:i/X-Runtime † Edit

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

:i/なぞなぞ認証 † Edit

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

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

IQ-Auth

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

例えばページ作成者がなぞなぞ設定にする。問うのは議論の争点。選択肢式で複数、あるいは文字入力で1問。
ゲスト（非ログインユーザー）にも適用できてWiki向き。

:i/1IDに1パスワード † Edit

複数統合もしない

:i/オープン認証だけ † Edit

パスワードを保管しない

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

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

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

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

:i/1ページに集めるだけで「そのうちまとまる」と言えるのか？ † Edit

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

:i/パーマリンクには内部名を使う † Edit

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

:i/草稿 † Edit

NOINDEX期間の版を「草稿」として、最新版とは区別。最新版は草稿でない版の中の最新。
権限を持ったユーザーはNOINDEX期間を終わらせることができる。

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

これでWebAPI経由でページを外に出せる
ブログパーツとか、DataWikiとか、iPhone向けのHTMLアプリのUI作成とか

†編集/承認

:i/メール送信記法 † Edit

どこに、いつ、
ほかの記法で書けばそれぞれのUIでその場編集ができたり。

:i/アクティビティのカレンダー表示 † Edit

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

:i/tipsかるた † Edit

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

:i/バックリンクと一緒に名前変更 † Edit

ページ名変更で、1つのWikiにある全てのリンクも変更
名前のリファクタリングを可能にする
リンクオブジェクト向けの変更履歴に変更前後の名前を追加、リンクオブジェクトは可能なときに参照、反映

保存を伴わなくていい？次もまた反映しないと
いつ反映されるのかわからないので、変更履歴を消せなくなる

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

:i/よく使うコマンドを上げる † Edit

よく使うコマンド枠を設置。
既存のメニューは変えない。
ナビゲーションや編集時の書式・ヘルプ表示なども含めて。

:i/前後ナビのデザイン † Edit

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

:i/ページは空でも消さない † Edit

ページ名を空にすると消える。
見出しだけを書くと空の下位ページを作る。で辻褄合わせ。
つまり、アクセス手段がなくなると消えるということ。でもOrphanは消さない。そのOrphanページの編集でアクセス手段がなくなるわけではないので。

:i/APIバージョン † Edit

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

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

spec:1.0.* など。

:i/利用者ページに書くこと † Edit

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

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

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

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

:i/エクスポート † Edit

テキストで、UTF-8やShiftJISで。
SVGで1枚に4ページ掲載(4in1)とか。
ePub、PDF、E-InkデバイスやKindle向け。
Wikipedia形式。

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

:i/URLを貼るとブクマと☆も表示 † Edit

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

クリック、項目がオレンジ背景に → 見出しが背景オレンジで表示、背景色がフェードアウト。

色を共通点に使うのなら、全体的に白紙風デザインに。
1つだけしかない共通点が目立つように。

:i/ぐにゃぐにゃできる検索結果 † Edit

ビューをクライアント側にも分割。フィルタリングやソートを可能に。
サーバー側では関連情報を含めて取得。情報が多すぎてもクライアント側で要求にあう情報に加工できればいい。

フィルタリングとソートを、縦/横方向にできるように。横ソート/フィルタリングは手作業で。
…と、結果中に関連項目があればツリー化。関連元でまとめ。関連元が親になる。
1つの親に複数の関連名があるので、それをどう区別してグループ化するか。→親→関連名→子にすればいい。
関連を持つのはページくらい。

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

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

ぐにゃぐにゃするために、サーバー側でもクライアント側でもフィルタリングとソートを。
ページロード時に枠しか見えないのは不満なので、サーバー側でのフィルタリングとソートの結果をデフォルトにしておく。その後クライアント側での操作でクリア、再描画。
サーバー側では普通に検索結果を作るということ。クライアントと機能が重複する。

実装では
検索要素の出力を、テーブル要素に与えて。テーブルHTMLにはクライアント側のフィルタリングとソート機能を持たせて。
テーブルにはセルごとの背景色…は要らない。どの列の値を背景色に反映させるか変えられればいい。値をクラス分け。設定不要で同列内の相対値（偏差値？）が離れている帯域で色が変わるように。
ファセット検索の機能もテーブル要素に。集計とフィルタリング。

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

:i/Wikiの分かりにくさ † Edit

書き手が複数いる。大勢が全体を把握せずに編集。流れがなくなる。→分かりにくく
でも全体を把握しないと編集できないのでは書き手にとって分かりにくい。
書き手の分かりやすさと読み手の分かりやすさを両立するには？

起承転結の起と結が全ページにあればいい。
コンテンツヘッダーには版の作成日と著者リスト、直近の親ページ名でもあればいい。
起結はページの埋め込みで。つまり書き手が気をつける。「…を…するシリーズ。全15回を予定しています。」のような第一段落を埋め込みように作っておけばいい。
自動化したいなら親ページの継承される属性に入れておいて。←これがコンテンツヘッダー？

:i/機能/前後ナビ † Edit

Wikiの:t/分かりやすさのために。
兄弟ページ間をつなぐナビゲーション。ページ名で関連が決まる。
前後の順序は一定。変えるならサイト設定や継承可能なページ属性で。

これをページフッターやコンテンツヘッダーに入れておけば、日付をページ名にしてあるブログでも有効に使える。
親ページを見ることなく前後ページをたどれれば、読み手が細切れな内容のWikiで分かった感を得る手助けになるのでは。

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

:i/super要素 † Edit

継承可能属性の中で使うために。
親ページを表す記法を。
これと属性名指定の記法を組み合わせて使用。

汎用記法でいい。

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

:i/クリック、打ち込み、通知 † Edit

UIでの操作は3種類。
ユーザー→システムはマウスクリックとキーボード打ち込み。(で、レスポンス→またクリックへ)
システム→ユーザーは通知(→クリックへ)
…くらいで事足りるはず。

通知方法は何種類も考えられる。
キーボードから打ち込むのは文章も記法もある。
クリックは見たものに反応するだけ。フリックや長押しもあるかも。

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

:i/まず書く † Edit

使い方を考えたとき、やろうとしたことまでが遠い。
読むにも書くにも「目的のページ」がある。そこにたどり着くまでには広告だけでなく、ログインメッセージもパスワード入力もサイトの更新情報も、それ以前のアプリケーションアイコンやブックマークのリストも、すべて邪魔。
（その場では）使わないキーボードのキーさえ邪魔。

で、まず何をするか(ToDo)を書けるように。

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

あとは普通に編集など。

:i/右上 † Edit

Spotlight風な右上。
/やタップでフォーカス取得。

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

右上には新規ページ作成の機能も。
PukiWikiのページ作成のように、入力されたページ名が既存かどうかで読み/作成の両方できるように。
打つ→選択肢から「(打ち込んだページ名)作成」を選択→ページ作成へ
右上がページ作成の「ページ名」欄になるような。

とりあえずToDoを書けるように、Enterキーで打ち込んだテキストを残す。セッションページに記録。
複数行を貼り付けても残るように。複数行を入力したら複数行表示に拡張したい。

:i/メモ化のキー † Edit

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

:i/Wiki 編集UI リバートよりも前版コピペ支援 † Edit

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

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

お手軽リバートボタンならプラグインとテンプレート書き換えで。
管理者用のビューテンプレートに追加しておけば一人運営に便利。

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

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

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

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

:i/自動的に出る「追記」 † Edit

:i/リバートは管理者グループのものでいい † Edit

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

:i/内容依存なFoldingTextはできないか？ † Edit

Gmailのように同じテキストが省略されるようにするには？
・省略単位が必要
Gmailではメールごとに数行の重複があれば、行単位で省略。この「メール」にあたる単位は見出し？
・一文字だけ異なる行があったらどうするか
・省略して何を残すのか？

:i/日付で分ける以外の目次インデックス作り？ † Edit

UI、閲覧しやすするもの
TOCのインデックス。
ブログなら日付、Wikiならページ名、掲示板ならトピック名と日付。

…だけ？

:i/名言 † Edit

名言をどこに入れるか
インストール直後
エラー時
アンインストール直前
セッションの終わり（開始時は邪魔）

:i/読みにくさ解消 † Edit

コンセプト/Wikiは読みにくい
見出しは分割←短いなら読みやすい…ではなく入口を増やすためのもの。ここから読もうかというもの。
見出しごとにつかみがいる。というか見出しはつかみ。続く第一段落はつかみの完全化。そして起承転結へ。第一段落まででここにはなにが書いてあるか判断できるように。見出しは入口であり入らずに通り過ぎるときの出口。

というのを見出しごとに行なうには…
テンプレート？自分への注釈？
完全に書き方の問題。

:i/追加と編集は別権限 † Edit

:i/universe->space->entry->side->section->revision † Edit

1つのsideに複数section。
オブジェクトはsectionのみ。
上下関係は考えなくてもいい。すべてSectionの属性。

:i/universe->space->entry->side->revision † Edit

:i/Wikiがニュースフィードアグリゲーターになったら † Edit

自分ログを作って全てを記録
Evernoteとは違ってフィードを記録。専用APIも相手側の対応も要らない。

フィードが多数でも入口は1種類になるので、振り分けや分類がいる。

:i/ページ名変更は見出し変更で † Edit

見出しは編集時にフルパス化しないと。
でも閲覧時はリーフだけ表示なので分かりにくくなる。

見出しにカーソルを合わせたときだけフルパス化？それでも分かりにくい。

:i/スタイル/スクロールできるなら陰影 † Edit

スクロールできる方向の端には白色/黒色の影をかける。
モバイル向けで使われてるけどそれを標準に。
上下だけでなく左右にも。インラインフレームの中にも別に。

:i/重複リンク † Edit

明示的リンクを複数書くと明示度合い増。
バックリンクリストで(2)が付いたり。

:i/属性領域に書いたタグは継承される † Edit

:i/メリハリ † Edit

見出しに含まれる固有名詞をハイライト。週刊誌の広告のように。
見出しだけを速読みできるようになる。

辞書はオンラインのもので。ニコニコ大百科・はてなキーワード・Wikipedia、Yahoo!のテキスト解析サービス…

これを「今週追加されたテキスト」で。
Wikiに入力されたテキスト→ページ#見出し
という体裁で本当の新着情報を配信。

Twitterから † Edit

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