とりとめのない思い付き。
- -------------------------------------
- -
- <<<
- 対象範囲
- ライセンス表明
- 似ているページや追加位置を気にしない
- 自動生成ページは隠す
- タグの継承
- 連続する機能はつながる
- 機能の対象範囲
- バックアップダンプをメール送信
- WAI-ARIA
- 履歴→記録
- 見解の仕組みをwiki間でもできたら?
- 編集の衝突
- NintehdoDSブラウザー対応
- URIの#!
- 保管してあるアイデアはアップデートしない限り役に立たない
- 日付記法とカレンダー
- 何やってたんだっけリスト
- ブラウザーのウィンドウタイトルに検索語を付けたら便利?
- 一覧できる表示方法、タイリング、リスト
- 分派は多数派も少数派も守る
- 永続セッション
- フレームワークからdump呼び出し
- 少数派の猶予
- 派閥は統合なし、分けるだけ
- 編集できない派閥(のページ)を編集すると分派
- OpenIDがあるのだから利用者の同定を当てにしていいのでは?
- OpenIDとOAuth
- 支持票は複数入れていい
- 自分にとって都合のいいページだけを見せてくれるのが代表の仕組み
- 派閥はデフォルト値が同じ人たちの集まり
- 自分のサイトへトラックバック送信
- 内容付きページ一覧
- カラムブラウザー
- 「フォームを再送信しますか」
- 派閥内はSNS
- ダンプで一括置き換え可能に
- バックリンク(BackLink)の一覧
- アンケートは自分のページに回答を書く
- ダンプにはindex.htmlを
- 書き込みできるかをwiki全体で表示
- Twitterから
- ページの追跡
- 編集回数により変更可能範囲が増えるWiki
- ページはバラバラなもの
- とりあえずぶっ込んでおけばあとでまとめられる機能
- ヘルプに機能パラメーター例
- 学習する検索
- リンクを合わせるかリンク先を合わせるか
- Googleドキュメントにバックアップ
- リストア実行前にバックアップ
- ゲストはバッチ的操作不可
- なんでもリンクで。
- 検索結果から関連ページへは直接か?クリックが必要では?後付けのまとめページから実体ページを閲覧するまでのステップは?
- 置き換え機能
- タグ…
- 検索しかないのか
- KJ法で下位ページ説明
- ブラックリストとホワイトリスト
- 何かのヒント
- フローとストック
- 編集時コメント
- ToDoバルーン
- カスタムヘッダー
- Sandboxでは履歴を残さない
- 「HTMLに対応付けられていた記法を、文書の構造に使った」
- サブページごとの読み込み
- 下位ページレイアウト
- 編集機能
- tel:記法
- スマホ
- 編集→書き込みと、即時書き込み
- スタイルテーマ
- 図と自動リンク
- Turn off the lights
- 最近の入力
- ページネーション
- 記録系機能
- テーブルを追加するフォーム
- 特定版リンクとはローカル名付きのページ名リンク。
- ページ属性に「HTTPSを使わせる」
- 不完全なページ要求+代表拒否
- 振って「とりあえずマイリスト」
- ページの重さ
- タブビュー
- *(ワイルドカード)
- 埋め込みオブジェクトの事前レイアウト
- 自動リンク・リンクを、色分け・サイズ分け
- ページ一覧にダイジェスト
- 権限の表示にアイコンを
- コードインポート
- 索引
- ファセット分類
- おかえりなさいメール
- アカウント削除予約
- 機能/Google計算機の結果に置き換え
- いろいろフォーマット
- 紹介はマンションやホテル・旅館の紹介のように。
- EverWiki
- WikiEngineをまとめたWikiEngine
- 何かを書くと「で?」
- サポートはありません。
- 参考に
- 問題追跡、提案板にアイコン風のテキスト
- "X POWERED"
- 見解は削除に代わる手段
- Ui 1つのオブジェクトに複数の操作を割り当てるなら、フリック。
- @場所名
- ブレインストーミング
- 発想の流れ
- おすすめ検索キーワード
- コード内のToDo
- 活用法 マイメソッド
- 2ホップ先は共起相手
- サイト分析
- スタイルテーマはROM専のため
- UI クライアントビュー上で切り換えたいもの
- UI ツイートボタンやいいね!はまとめて
- UI モバイル用UI
- 検索
- プラグイン内でプラグインを呼び出すために
- インデックス不可能な語をインデックス可能にするには
- ①・②・③に順序を持たせる
- 見解統合はページの削除と投票×2
- バックリンクをまとめたページ
- 1つ支持すれば他の派閥は不支持になるか
- 支持を変えて他の派閥に負担をかける攻撃
- 「はてなの人力質問で"Wiki"をウォッチしています」という表明
- 文字列からの型変換はExcelでもやっている
- CSVファイル取り込みは添付ファイル化
- 検索クエリーは式とページ内容のobj化
- まとめる作業をしているときに新発想がある
- まとめる作業
- まとめる作業支援
- 「と関係のある」という検索式
- ページ名変更をリンクに反映
- プレビューはボタンにしない
- 注釈(note)はセクションを越えない
- 関連情報にAmazonなどの商品も
- 外部リンクにfavicon併記
- インデント
- 場所によって変わる補完候補
- 顔文字はインラインタグ
- 特定単語がタグ
- 古く見えるテーマ
- テキストボックスに選択文字列
- 明るく暗くをランプで
- RecentChangesのビューにwikiが発展する様子を表したい
- 選択文字列に一言コメント
- X-Runtime
- なぞなぞ認証
- 1IDに1パスワード
- オープン認証だけ
- オープン認証ではユーザーIDにサイトドメイン追加
- オリジナルテーマを作って広める
- 1ページに集めるだけで「そのうちまとまる」と言えるのか?
- パーマリンクには内部名を使う
- 汎用プラグイン記法はどんな書式?
- 草稿
- メール送信記法
- アクティビティのカレンダー表示
- tipsかるた
- バックリンクと一緒に名前変更
- よく使うコマンドを上げる
- 前後ナビのデザイン
- ページは空でも消さない
- APIバージョン
- 利用者ページに書くこと
- 検索には高いレスポンス性能が必要
- エクスポート
- URLを貼るとブクマと☆も表示
- UI 画面切り替えには前後画面に1つだけ共通点を
- ぐにゃぐにゃできる検索結果
- Wikiの分かりにくさ
- 機能/前後ナビ
- super要素
- クリック、打ち込み、通知
- まず書く
- 右上
- メモ化のキー
- Wiki 編集UI リバートよりも前版コピペ支援
- 一秒以内の編集ボタン→投稿ボタンには応じにくい
- 編集ボタンを押す直前に気付きにくい荒らしがあったら?
- 自動的に出る「追記」
- リバートは管理者グループのものでいい
- 内容依存なFoldingTextはできないか?
- 日付で分ける以外の目次インデックス作り?
- 名言
- 読みにくさ解消
- 追加と編集は別権限
- universe->space->entry->side->section->revision
- ファセットWiki
<<< †
対象範囲 †
…など。
どう設計するか。
→どれもページ。wikiはルートページ、サブページなしのページはサブページを持たないページのこと。
リンクやバックリンクの数が少ないページ/多いページをどう探すか? †
→ 量の問題には立ち向かわなくていい。リンクの多さもOrphanも気にせず使いたい。
ライセンス表明 †
下位ページに継承可能なフッターを用意してそこに書いておければいい。
記法にして置くのもいい。©のほか、CC BY-SAなど。ライセンス条項はアップデートされるので、プラグインの差し替えでアップデート可能に。
似ているページや追加位置を気にしない †
適当にぶっこむこともあるので、そのあとでまとめられるほうがいい。
検索で「ブログ」と「ログ」を分けたい †
「ログ」を検索したときに「ブログ」を見つけないように。逆に見つけたいときもある。
曖昧検索のルールで自動リンク †
自動生成ページは隠す †
自動生成ページは検索の対象外。特に指定されていなければ。
PukiWikiでの:始まりのように。
「:AutoGen/…」のように。
曖昧検索と自動リンクを統合。
例えば、自動リンクするとき、ページ名やリンク対象に含まれるひらがなを無視して自動リンク。
ページ本文中の「読みやすい書き込」が「読みなれた書込」のページに自動リンクする。逆も起きる。
タグの継承 †
タグはページが持つ属性。
タグは上位ページのタグを弱く引き継ぐ。
曖昧なリンクだとリンク先が複数になるはず。「読みやすい書込」のメタページ(入口リンクはあるけど実在しないページのメタページ)から「読みなれた書込み」にリンク。類似したリンク先もそばにある。
ページ一覧で含まれる数字を全部集計 †
ページ一覧や下位展開、コレクション(サブセットWiki)など、複数のページを扱うページでは、含まれるページに書かれている数字を集計。数値類の記法がラベルを受け入れるなら、ラベル別に集計。
ファセットナビゲーションの集計版。ページ要素を集める点は似ている。
連続する機能はつながる †
同じ機能、記法を続けるとつながる。
行単位の引用「>」や、段落単位の引用「>>…<<」など。
→:集計
機能の対象範囲 †
- ページ
- 段落
空行間。 - 行
改行間。 - 文字列
「要出典」は指摘・抗議 †
「要出典」はコメントとは別の形の抗議。
Wiki全体がページ一つなので、ページより大きい単位は無い。
- -------
上位ページでは下位にあるコメントも見える †
コメント(スレッドモード)だけをつなげて並べる必要は無い。下位展開で各ページにコメントがあればいい。
それぞれの表記方法(例)
- ページ
ページのどこに書いてもいい。
先に書いたほうが優先されるので、通常は先頭に。あるいは特別な領域へ。 - 段落
段落の中(見やすくするため段落始めか
段落終わりに)。一行使うか段落内の行頭か行末に。 - 行
行頭か行末に。行頭と行末の
両方に何か書くなら文字列指定とかわらない。 - 文字列
面倒。括弧でくくらなければならない。
例えば明示的なリンク。
実装を簡略化するため、文字列は改行を含まないし、行は複数行含まないし、段落は一つの段落だけ。ページも一つ、ただしサブページは含んでいい。
見出し無しはルートページを指す †
見出しよりも先に書かれたテキストは、名前の無いページ(ルートページ)の本文に追記することになる。同名ページは1人ひとつまでなので、同名ページ作成にはならない。
書く内容…
検索結果の定義は特定名のページで †
その下位ページは、ヒットしたページごとに利用されるループ部分。
…は、ループ部分の仕様次第。ループ変数としてページが与えられるループ。
バックアップダンプをメール送信 †
携帯などからでもバックアップできるように。
トリガーをメール受信にできればなおいい。
送信先は管理者設定か、リクエストメールの送信者に。
利用者が同一サイトに集まるわけない †
投票は結局無駄になる。
「自分にとって」は2つある †
WAI-ARIA †
自分のスペースにインポートすれば投票か †
他人のページをコピペ改変するのが投票か。
投票は自分のページと、自分が触れていないページにするもの。
コピペ元にも同時に投票される?重要な版を自動検出して代表化する。
ページセットはページの属性を表せる †
ページ属性はページセット。実装の違い。
ページ属性とページセットを同一視。
履歴→記録 †
履歴・バックアップは記録。パーマリンク付き。
Google検索の下位に出したいが、それができないなら出さなくてもいい。
「自分にとって」を基本にして †
どう利用者間のコラボレーション・コミュニケーションをするか。
元は見解を書いたり、コメントを追記するもの。今はコメントはみんなのスペースだけのもの。見解・同名ページは無くなった。
見解の仕組みをwiki間でもできたら? †
InterWikiNameがインターネット内の代表ページにつながる。
他のWikiEngineを仲間に入れるには?片方向リンクでもいい。
餅は餅屋のwikiで。
「自分にとって」は何と結び付けるか †
- 投票…ページ名とページの結び付け
- ページセットと?(コレクション)
- 承認と?SPAMでないこと
- すべて
FederatedWikiのように。 - 自分用にできないもの
ページ名はページの一部なのでできるはず。
編集の衝突 †
一般的ではないので、「古いバージョンを更新してしまったようです」のように。
お互いの元バージョンと変更後バージョンを示して、ユーザー自身と他のユーザーがそれぞれ何をしたのかを説明。
でも編集箇所が異なれば衝突とはしないことに。
「自分にとって」を実現するために、1スペースに1人だけにすると †
NintehdoDSブラウザー対応 †
UserAgent別のビューで。
URIの#! †
http://code.google.com/intl/ja-JP/web/ajaxcrawling/docs/html-snapshot.html
HTML Snapshot を適切に作る方法
スペースはページセットでコレクション †
1人でいくらでも持ちたい。
※自分のスペース内に。
「自分にとって」はスペース。スペースをまとめたのがWiki.
保管してあるアイデアはアップデートしない限り役に立たない †
いつのアイデアか分かるように。
→差分表示で日付を含めて「追加」「削除」を表示。
ゲストは投票結果をどこで見るのか。どのスペースも誰かのもの。中立のスペースがない。→ デフォルトスペースが中立スペース。
発想→保管→更新や追加や集約→保管→更新→活用。
更新すること(古い内容や正しいことを確認すること)が必要。
更新にかかる時間、手間を少なくするには?
→開いたときに関連情報が集まっている…KJ法の途中のような。
いつのアイデアか分かるように。
→差分表示は複数差分をまとめて。履歴を範囲指定で、ここからここまで。
現在の版も含めて履歴表示。そうすれば「現在との比較」というリンクが要らなくなる。
表示は…
+:32行め:2010/10/10: 1行分の内容…
…のように、日付を含める。
基本がFederationになっても、投票を伴なうピン留め操作は必要 †
これで(共有スペースでの)代表が決まる。コピペ改変も投票を伴なう。
日付記法とカレンダー †
日付(WikiNotaion)を書くとタグのような扱いに。タグクラウドの対象外。
日付ページへのリンクになり、日付リンクのツールチップにはその日の一行日記が表示されるように。→リンク/ツールチップ[?]の仕組みとツールチップに何を書くかで。
投票はSisterWikiネットワーク内で有効 †
フォローも同様。
日付リンクを集めたページがカレンダー。
静的なページでもいい。リンクが存在する月ごとに表示や生成をする動的(な機能を含む)ページでもいい。
版の更新コメントを一覧化するためのもの。
サイト全体に渡る更新が書きやすくなる。
ページごとに書くこともあるので、版の更新コメント欄もあっていい。
承認時、モデレーター間で意見が分かれたら? †
- 投票は「自分にとって」のもの
- 投票でモデレーターになれる
- 利用者によって、どのページが存在して、削除されていて、SPAMかが異なる
- この3つはページセット。承認はページを3つのページセットに振り分けるもの
何やってたんだっけリスト †
パンくずリスト。迷っても通った道順通りにリストアップ。
ルートからの最短経路になるトピックパスとは違う。
基本がFederationになっても、フォローは可能か †
同名ページ→その作成者→作成者の利用者ページでフォロー可能。
フォローリストはページセット。それもSisterWikiのインポート対象。
スペースをフォローするのがSisterWiki。
ブラウザーのウィンドウタイトルに検索語を付けたら便利? †
ブックマークのために。
「…」から(ページタイトル)
外部(Googleなど)からの検索語も同様に。
URLのクエリー部分違いはタイトルを変えるかということ。
ページの見た目に関わるなら変えるべき。検索語強調付きのときなど。
一覧できる表示方法、タイリング、リスト †
マイページでウォッチ範囲の新着(範囲か条件で指定)表示に。
レイアウト変更
ズーム(絵や動画の)
分派は多数派も少数派も守る †
- 少数派は多数派から攻撃されなくなる
- 多数派は?
→同じ。
永続セッション †
もう1つのセッションが一時セッション。
時限式ID、それを過ぎると変わる。
ユーザーアカウント1つあたり。それぞれ永続と一時のIDを持つ。
常に1つ(×2)持つ。(初めてセッションを作るまでの間を除いて常に)
フレームワークからdump呼び出し †
そのきっかけは普段コメントアウトされている行や、ユーザーからのdumpコマンド実行リクエストでいい。
少数派の猶予 †
支持票が無くてもページが消えたりしない。
支持されてなくでも多数のページを作って体系化する。それくらいできるように。
後になって支持されるかも知れない。
派閥は統合なし、分けるだけ †
コウモリはあり得なくなる。
統合するなら他の派閥を参考にして、自分のところを充実させることで実現。
編集できない派閥(のページ)を編集すると分派 †
別派閥作成+テンプレートとして元のページ使用。
OpenIDがあるのだから利用者の同定を当てにしていいのでは? †
1人1アカウントになるように。
それとアカウント持ちに便利なようにして。
これで
- 1人1アカウント
- 使い回せる
便利。作ることが面倒でない…騙れない
…といったことが実現できそう。
アカウントを持っているのにゲスト利用…は非公開利用、隠れて利用ということになる。
→認める。
ホワイトリストと組み合わせたOpenIDならWikiに合うアカウントとして使えそう。
OpenIDプロバイダーのホワイトリスト。
OpenIDとOAuth †
1つのOpenID、OAuthアカウントでログイン後、他のアカウントを認証すれば統合。
複数の外部アカウントを1つの内部アカウントにできるように。
支持票は複数入れていい †
自分にとって都合のいいページだけを見せてくれるのが代表の仕組み †
これがゲストの場合…Wikipediaが目指しているような公に認められたページになる。
これはGoogleでもやっていること。
(ユーザーの検索履歴が反映されるようにページの順位を変えている)
カスタマイズがフォークソノミーになる仕組み。
見たいものを上位に。見たくないものを下位に。
派閥はデフォルト値が同じ人たちの集まり †
制限を課すようなものではない。
例えば代表の初期値(初期の代表、何も判断材料が無いときの代表)に同じ派閥の人を参照する。
自分のサイトへトラックバック送信 †
自分の日記のために。活動記録のために。各サイトのTwitter連携のようなもの。
自分のアカウント→トラックバック先を設定しておく必要がある。(利用者設定)
内容付きページ一覧 †
特に短いページが多いときに。
検索結果でも。
検索結果は検索キーワード付近を横断的に表示するもの。
文字数で数えて近いテキストのほか、別の尺度で近いテキストも表示できれば…?
カラムブラウザー †
iTunesのファセット分類と検索システム。テーブルの列ごとにまとめ。選ぶと選択した列に選択したのと同じ値を持つ行だけ表示。
これをWikiとページに適用すると…列→「タグ」、値→付けられたタグ。
ページは非定型、フリーフォーマットなので列にあたるものがタグくらいしかない。
見出しなどは重複することがないのでまとめにならない。
日付には「199X年」「90年代」という指定もしたい。(日付記法次第)
記法別にする?記法別ファセットだと多くなりがちかも。有効なファセットを選びやすいように項目の多いものを強調表示。項目数を出すだけでもいい。デフォルトでファセット名と項目数だけ表示。選ぶと内容一覧を展開。
運用側で何もしない記法を作ってファセット分類専用にするのもいい。
「フォームを再送信しますか」 †
フォームの送信をしたページをブラウザーの履歴に入れない方法はあるか。
派閥内は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。
リストアは必要ない。ファイルダウンロードして、通常のリストア。
リストア実行前にバックアップ †
最終バックアップから更新されていなければ要らない。
不要なバックアップになるとしてもバックアップは作る。
ゲストはバッチ的操作不可 †
複数ページに影響する(そして完全に戻すには手間のかかる)操作は要権限。
なんでもリンクで。 †
下位ページもリンク、その他の関連もリンク。
関連名が要る?リンクの属性
検索結果から関連ページへは直接か?クリックが必要では?後付けのまとめページから実体ページを閲覧するまでのステップは? †
置き換え機能 †
設定では他の機能より優先
これで他の機能のパラメーター固定値版記法を定義
タグ… †
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での「ノート」。会話。提案・サジェスト。
あるページに投稿されたフローな情報は「そのページについての批評・提案」。
フローな情報の見せ方はどうするか?
Wikipediaのノートのように表ページのナビゲーション的な場所にリンクを埋め込み?
フローをストックするためのWiki †
- WikiはTwitterやメールのような送りつけられる形を取り込めるようにならないか?ページ表示、フォーム表示、書いて送信は手順が多すぎる
- 送りつけ投稿でもいい感じ(読むためよりも再編集にいい感じ)にまとめるには?
- メールやTwitterをメーリングリスト的に使い、やりとり・流れる情報をいい感じにまとめるには?
- 意見の衝突、共通点がわかりやすいように。人力を利用して。返信に2文字程度のタグを付けてもらってもいいかも。リプライのつながりも利用できそう。同意・異議ありを2文字程度で返信・意志表示できるとか。
- フロー投稿のまとめ(セグメント化)
同じ人から・同じページへ・同じ内容(?) - テーブル記法を使って左右に同意・異議を振り分け。一覧しやすくするとか。Twitterアカウントにもページを作って人別に一覧しやすくするとか。
編集時コメント †
特にページ削除時に必要。「なぜ」の推測材料がないので。
編集ステップを増やしたくない。
「投稿完了しましたが、よろしければコメントをどうぞ」で無視することも可能、のようなUIで。
ToDoバルーン †
ページとページ内の位置を指定して吹き出し表示。
完了したら割る。
位置は見出し(ページ)でいい。
ページ名変更に追従するように、ページ内にバルーン用データを置ければいいけど。
それをクライアント側で吹き出し化。ページヘッダーにスクリプト埋め込み。
ユーザーでなくシステムが操作するデータをページに設けるということになる。
編集者間のやりとりに。本文に重ねて見せるノート・コメント・注意書き。
カスタムヘッダー †
レスポンス時のHTTPヘッダーに受け入れできる記法、HTMLヘッダーにシステム名
Sandboxでは履歴を残さない †
「HTMLに対応付けられていた記法を、文書の構造に使った」 †
サブページごとの読み込み †
で遅い感軽減。下位が上位に依存していなければ。
速いときはサブページを埋め込んだページ生成。クライアント側はその分を通信せずすぐレンダリングできる。
下位ページレイアウト †
下位をどう並べるか。リスト、グリッド、横幅だけ固定のグリッド、Metro風の大きさの異なるタイル、単行リスト、縦書き、縦書きサブページを横書きリストの配置に、ランダム余白のランダム配置、1文節たけの詰め込み配置
編集機能 †
サブページを複数選択して分割か、
サブページを並べ替えて切るか。
→両方。並べ替えて切るのはスマホで有利
tel:記法 †
スマホ †
スマホクライアント、Evernoteを公開するのとどう違うか。
編集→書き込みと、即時書き込み †
スタイルテーマ †
- Microsoft好きテーマ
- Google好きテーマ
- 最近のMicrosoft好きテーマ(Metro)
- 夜型テーマ、朝型テーマ
- 懐かしのWeb2.0風テーマ
- Evernoteテーマ
- テーマ 手書き、ニコニコ動画原宿
- テーマ うごメモ
- テーマ Zen縦書
図と自動リンク †
図中のテキストがWiki内のページに自動リンク。
クリッカブルマップ。
テキスト、その位置、図を別々に受け取れないと。
自動リンクするために図(を表すページ)の(ページ構造内での)位置を決めないといけない。
Turn off the lights †
テーマ切り換えUI。明/暗と中間の夕方があればいい。
実装はテーマ変更するようなリクエストを生成するだけ。
ブラウザーに状態保存。…だとどうテーマに反映させるか問題。スタイルテーマ自体をブラウザーに保存できないと無理。
:t/スタイル :t/テーマ :t/即時編集[?]
最近の入力 †
「最近編集されたページ」ではなく、最近このWikiに入力されたテキスト。新しい順になっているだけでWiki稼働時からの全てのテキストを保持。ページとは独立した記録。純粋なログ。消されたテキストも保存。
体裁は…
入力されたテキスト
入力されたテキスト
入力されたテキスト
どこかに書いておけばポケット1つ原則で取り出せる。
ページネーション †
スマホで、縦向き使用時にランドスケープ表示、で縦書きにしたら通常のスクロールでも文庫ビューアーっぽくできそう。
記録系機能 †
- スクレイピング、記録
スクリプトは書いてもらって。 - データ保存、グラフ作成
テーブルを追加するフォーム †
と、テーブル1行ごとに削除するボタン。と1行ごとに打ち消し線を引いてグレーアウトするボタン。その場編集で。
特定版リンクとはローカル名付きのページ名リンク。 †
ページ属性に「HTTPSを使わせる」 †
ページ作成時、属性変更時、wiki内 リンクも https:…に。
不完全なページ要求+代表拒否 †
見解名などが指定されていないとき→代表を返す
代表を返す場面で代表拒否が指定されていたら…
→ワイルドカードに当てはまるページをリスト表示
振って「とりあえずマイリスト」 †
マイリストは一時的な履歴、コレクション。
今の考えをたどるためのパンくずリスト。
ß
ページの重さ †
リファレンスカウントと含むセクションそれぞれの長さを考慮して、重要度算出、表示。
式は管理者が自由に変えていい。記法と違い他サイトから来た人のことは考えなくていい。
タブビュー †
1ページの中に複数ページ表示。リンククリック→左カラムにページ展開、遷移前のページは右側へ移動。
古い履歴が右へ右へ移っていく。
古いページからの分岐はその左側にでも展開。分岐は左側に壁を作る。壁は直接のつながりが無いことを示す。
カラムの移動、カラムを次の壁まで移動、カラムを先頭に、カラムを末尾になどの操作も。
*(ワイルドカード) †
リンクなどのシンボル名を指定できるところで*や?を使うとワイルドカード化。
ページ/*/背景色
…でページ/ヘッダー/背景色などがリンク候補になる。
*ページ
…でウェルカムページ。
…*… *…*
…なども。
?も同じ意味。
埋め込みオブジェクトの事前レイアウト †
外部サイトのイメージなどは表示中にレイアウトされるため操作性が悪くなる。
あらかじめサイズだけでも読み込んでおいて、max-heightなどのスタイル属性でサイズを指定しておく。
スクロール方向のサイズだけでいいので、heightだけ。
サイズ情報は適当に更新。リンク切れ監視と同じタイミングで。
画像自体のキャッシュにしたほうが読み込み時間が安定していいかも。
加えてキャッシュしない(サイズを保存しない)オプションも。
自動リンク・リンクを、色分け・サイズ分け †
言葉(ページ名)を属性付け。それを色と大きさで表現。(書体でも?)
言葉の属性はどの言葉と関連しているか(ページ同士の関連具合)で決定。wikiの発展にあわせて変わってもいい。
関連度が強いのは近い色、疎遠なのが違う色になっていればいい。
基本色を利用者設定、スタイルテーマ次第にすればいい。それを元に他の色も決定。
これで文字ばかりのページをタグクラウドのような体裁にする。文字ばかりならどうレイアウトを考えても平坦になってしまうので。
読む人が気になるような言葉を強く見せたほうが、どのページにどんなことが書いてあったか印象に残りやすい。
俯瞰してページ内の言葉の傾向をつかめるのも大きい。
読まずに見るだけで分かる。
ページ一覧にダイジェスト †
あるいは本文プレビュー。
検索結果の一覧では検索にヒットしたあたり。
最近の更新一覧では編集されたあたり(の最新版のほう)。
版の履歴一覧では編集されたあたり(の新しい版のほう)。
バックリンク一覧ではリンクがあるあたり。
…など。
呼び出し側によって同じページ一覧でもダイジェストが異なる。
常に全てを用意するのは非効率なので、場合によって異なるコードを実行しないと。
権限の表示にアイコンを †
錠と鍵 錠…要求する権限 鍵…ユーザー側が持っている権限。ユーザーページで見せる
ページテンプレートに絵を埋め込むだけ ユーザーページは書き換え自由なはず。 消されるかも?
コードインポート †
Git→全単語(シンボル名)1つごとにページを作る リポジトリないのファイルをインポートして、自動リンクでクロス リファレンス作成
構文解析できるなら 変数、クラス、などといった分類でページまとめ
コードはコード用の記法で
インポートしたぶんとは分けて説明を入れられるようにしたい 次のインポートでも説明は残るように
- -------------------------------------
自動的にページを作るのなら自動的に消す方法も必要。
索引 †
自動リンク、リンクを検索
という体裁で。リンク対象はフルパスのページ名。パス内単語をど ういう順番にする か?全並び順をリストするか?
で、自動リンクだとページ作らない限りリンクにならないので、 Wikipediaやはてな キーワードやニコニコ大百科にもリンク
※難しければ明示的リンクだけでも
ファセット分類 †
iTunesのような。タグで実現。
に加えて、フォーカスに関連性を付けられるように。関連性はリンクで。フォーカスをページ化すればリンク可能。
・類似
似ているフォーカスをリンク。別名。いずかを指定すると、類似フォーカスを全て指定したのと同じ効果。
・包含、包括
階層化されたタグのような。一つのフォーカスが複数を含む。上下関係があって上位を指定すると下位をすべて指定したのと同じ。下位を指定しても上位は含まない。
類似/包含はリンクの関連名で区別。関連名が不適切だとほかの目的のリンクとなる。
ファセット(型)とフォーカス(値) は定義なし。存在していれば有効。
フォーカスには日付のようなテキストではない型も入れたい。(ファセットで型指定するのではない。一つのファセットに複数の型が対応してていい)
- -
(WYSIWYGの代替の)テンプレートと組み合わせると良くなるように。
パーソナルデータベースのフォームのように項目が分かれていて、それぞれの項目がファセットになるように。
定義なしで非定型。フォームを修正・項目を追加しても古いデータと一緒に検索できて、しかも項目ごとに選択肢で絞り込み検索。指定した項目だけを対象にキーワード検索とかも。
おかえりなさいメール †
久しぶりのログインだとメール送信。メールアドレスが登録されていることを注意。
「久しぶりのログインなのでメールを送りました。このメールからでもパスワード変更、アカウント削除ができます」
パスワード変更、アカウント削除予約ができるのは…
・ログインした人
・おかえりなさいメールを見られる人
「パスワードを忘れちゃいました」リンク→IDとCAPTCHA入力でおかえりなさいメール送信。
アカウント削除予約 †
ここでできるのはアカウント削除予約、アカウントを無効化するだけ。1週間か2週間で削除。削除以降同じIDを取っても二世(Jr.)となる。削除前に同じIDは取れない。
機能/Google計算機の結果に置き換え †
いろいろフォーマット †
フォーマット名を書いて、あとは一つの囲みの中にフリーフォーマットで書いていく。
あとは自動認識でいい感じにエレメント化する。
実装は改行区切りや空白区切りで。
フォーマット変換も。選択すると再認識。ユーザーが書いたことは変えずにフォーマット名だけ変更。
紹介はマンションやホテル・旅館の紹介のように。 †
スクリーンショット、キャッチコピー、説明、トピックパス、
合間に豆知識。
Xは落ち着ける住空間を提供します。
EverWiki †
WikiEngineをまとめたWikiEngine †
FederatedWikiもまとめ。ユーザーが各自自分の環境にまとめ。
何かを書くと「で?」 †
でさらなるアイデアを促す。
というレスポンスメッセージ。
セクションのスライドショーで、一段落つくまでの文章を全画面に表示。
そこになんとかのチェックリストとかなんとか発想法に沿った質問を。
サポートはありません。 †
身近で一番頼りになる人にX専門家になってもらってください。
…という説明。
参考に †
Catch Notesのやワコムタブレット付属の円形メニューを参考に
問題追跡、提案板にアイコン風のテキスト †
「もっとひねって」「せめてボケて」「いいかね?」「いいんじゃね!」「そうなったらいいね」など。テキストで書いてテキストで表示。登録はせずに使い回し、コピペ。
"X POWERED" †
使用サイトを探せるような権利表示
見解は削除に代わる手段 †
Ui 1つのオブジェクトに複数の操作を割り当てるなら、フリック。 †
@場所名 †
で場所記法。
ほか、GPSからの経度緯度も。
Twitterより、@名前でTwitterユーザープロフィールヘリンク。でもWiki内か、インターリンクWiki内にそんな名前のユーザーがあればそっちへリンク。存在確認してリンク先を変えたり曖昧さ回避ページへ。
id:ではてなIDへリンクとかも。
ブレインストーミング †
ブレインストーミング用に、タイマー付きのコメント欄。タイマーは増加。発言してリセット。自分がどれだけの間発言していないかが分かるような。
発想の流れ †
具象に裏打ちされた抽象になる
→必要な分だけをコンパクトに考える
→→新しいアイデアを生み出すには必要なこと'だけ'集めること
→→→
局所検索、局所自動リンクをサブセットWikiで
サブセットWikiは「小さなKJ法」
グルーアイデアでつなぐ。足してまとめる、まとめるために足す
つながったら抽象化、一目で理解できる形に。
おすすめ検索キーワード †
年中行事を先読み。ユーザー数が少ないのでソーシャル手法でトレンドをおすすめするのは無理。
いろいろな状況を検索キーワード化、毎年この時期にはこのキーワードが活発化するというのを検出。
日時、季節、利用者、ページ名(Wiki内のキーワード)
コード内のToDo †
コードインポート時にコード内のToDo:などのコメントを特別扱い。
その他にもFixMe:なども。
活用法 マイメソッド †
何か思い付いたとき、何か解決したときに「何をしたか」をタグにしておく。
それを集めると自分の技、思考の道具がわかる。
有名な発想フレームワークかも知れないし、その一部かも。
既存フレームワークを基にしつつ独自部分があったり、知らないうちにカスタマイズ
してるかも。
実装
具体的には文中の「これを…すると」の部分をリンクにするだけ。「…すればいい」
とか「…してみた」なども。
本文をタグ化することで妥当なタグ付けになる。思考をタグ付け用に切り換えなくて
いい。
原文(生きている文、実用した文章)を利用するのがWikiらしくていい。
2ホップ先は共起相手 †
リンク(バックリンク含むので双方向)の2ホップ先は共起相手と同じ。
これの1ホップ先(共起の文脈)に注目。
1ホップ先をグループ、自身と2ホップ先をそのメンバーとすると、「メンバーが似て
いるグループ」をまとめられる。
まとめなくても「このページと…(グループ名)…つながりのページたち」というリス
トを「…(グループ名)…つながり」ごとに出せる。
… | … | … | … | … | … | … | … | … |
… | … | … | … | … | … | … | … | … |
… | … | … | … | … | … | … | … | … |
関心空間のようなつながり。
タイル状表示。
で、サイト中にあるすべてのページについてまとめると…似ているページ検出になる。
→これはただのリンク調査。同じリンクがあれば似ているページとなる。これを1ペー
ジだけ取り上げてできるということ。
サイト分析 †
傾向検出で。
- (ページ名)と(ページ名)はよく共起している
共起…2ホップ先は共起相手 - (ページ名)─(関連名)→
「(ページ名)からは(関連名)関連が多い」 - ─(関連名)→(ページ名)
「(ページ名)は(関連名)として見られていることが多い」
…などでwikiを分析。
- -
これで発想支援や
さらなるまとめ支援。
日記なら自分を知る機能になる。
「…をした次の日には…しているという傾向」とか。
スタイルテーマはROM専のため †
スタイルテーマは読む側のもの。
書く側にとってはテーマがなんであっても普通のwiki。
編集が不自由なwikiならスタイルテーマの意味が強くなる。
UI クライアントビュー上で切り換えたいもの †
UI ツイートボタンやいいね!はまとめて †
外部サイトにあるボタンはコンテナーに入れて、一度に表示させたい。
レイアウトが何度もやり直しになるのは見づらいので。
内容によるテーブルサイズ決定と同じ問題。
外部サイトが提供するコードをそのまま貼れるコンテナー。
ページを読み込んで、読み込みの進捗表示が終わってからコンテナー内を読み込みた
い。
ここは遅くてかまわない。本当に遅延していい遅延ロード。
UI モバイル用UI †
下部にボタン用パネル。
ボタン区切りに溝を設ける。溝は切り抜き。隙間からページが見えるように。
これで画面を広く見せる。溝がなければ画面が小さく感じる。
それと画面隅に三角形のボタンを配置するとか。
ページがめくれてる感じにするとか。
サイドメニューバーは引き出しにするとか。タップやドラッグインには無反応、画面
端からのドラッグだけに反応。
検索 †
(ページ|クエリー)の内部をobj化
WikiFormatと同じ処理クエリー←ページクエリーに適合したか?
または適合率を尋ねる。内部のobjを1つずつ突き合わせる。適合したページだけ得るのがフィルタリング。得たページに順序付けするのがソート。
プラグイン内でプラグインを呼び出すために †
%%利用方法→開発方法が分かりやすいようにするためにWikiTextを使う。UI(記法)が
APIになる。%%
→To...を呼べばいい。URLパラメーターを条件にしていろいろ判断するような処理は
Action(インスタンス生成後の処理)でやることにして、To...は引数だけに依存する
ようにプラグインを作ってもらって。
インデックス不可能な語をインデックス可能にするには †
量をインデックス化するには値1つと誤差の2パラメーターで指定。インデックスなの
で広く指定できれば十分。
でも同値(100%)だけでなく0%以外をすべてインデックスにするので、インデックス化
自体が無意味。
ページ要素プラグインにインデックス項目生成をさせるなら、列挙可能な場合だけで。
列挙不可能な場合は*。どんな検索でもそのページが評価されるように。
①・②・③に順序を持たせる †
数字記法に囲み数字を含める。
見解統合はページの削除と投票×2 †
%%元仲間には空のページかほかに指示しているページが表示されることになる。アナ
ウンス。%%
→不要。
バックリンクをまとめたページ †
外からの被リンクを
…にまとめたページ。
探索のために。
→ルートを始めとする上位ページが下位ページの集約…という考え方はもうない。や
るならページごとの集計になる。
1つ支持すれば他の派閥は不支持になるか †
全て支持したほうが得。支持さえしていれば相手を編集するのも自由。なので。
→支持に制限はない。支持はサイトが見やすくなるだけのもの。制限をかけないこと
で無理をなくす。
支持を変えて他の派閥に負担をかける攻撃 †
防ぐには、支持に制限、支持の意味を小さくする、
「はてなの人力質問で"Wiki"をウォッチしています」という表明 †
「ご意見があるときはTwitterでwikiと書いてくださいね!全リプします!」という表明
文字列からの型変換はExcelでもやっている †
日付・曜日の認識とか、金額の数値化とか。
CSVファイル取り込みは添付ファイル化 †
テーブル記法ではなく。
でも添付ファイルを埋め込みするとテーブル要素のHTML変換機能を利用するように。
記法を介す必要なし。
検索クエリーは式とページ内容のobj化 †
→検索クエリーもページ。
まとめる作業をしているときに新発想がある †
自然にまとまるよりも、まとめる作業のほうが大事かも。
まとめる作業は知識の反芻、再学習。システムがやると発想に必要な入力がなくなっ
てしまう。
まとめ作業中は情報を集めた人自身が閲覧者になる。閲覧者は投稿者以上に情報をつ
なぐ役目を持っているので、それを投稿せずに投稿できるようじゃないと。
獣道
まとめる作業 †
まとめる作業は
検索(ざっくりと)、さらに検索(小分類の中を)、細分化、読む、書き直す、加える、
ここでも検索と分類と細分化。
KJ法的に適当なメモを探す。
まとめる作業支援 †
まとめ支援は検索と人力。
そのための支援。
メモ書きをするような。
欲しいデータが手に入るような。0ステップか、ほかの作業中に手に入るような。
「と関係のある」という検索式 †
ページ名変更をリンクに反映 †
ページ名変更をリンクに反映。ページ名変更はリンク変更までの承認を含むとして。
プレビューはボタンにしない †
プレビューするならニコニコ大百科のようにチェックボックスにする。
紛らわしいのでボタンにはしない。
チェックはオプトアウト。でもよく編集する人向けに利用者設定でオプトインにもできるように。
チェックボックス自体を無効化したりはしない。
注釈(note)はセクションを越えない †
ページ末尾に置くと遠すぎるので。
同じ見出しの最後に表示。
関連情報にAmazonなどの商品も †
Wiki内からローカルな情報を、Googleで一般的な情報を、Amazonでモノを。
外部リンクにfavicon併記 †
apple-touch-icon.pngがあればそれを優先。
apple-touch-icon-precomposed.pngがあればさらに優先。
スクリーンショットが使えるならさらに優先。でもできればスクショにアイコンを重ねて表示。スクリーンショットの枠やドロップシャドウにはアイコンのキーカラーを使いたい。
インデント †
行頭の空白類は無視したい。
特に全半角スペースとタブ文字を。
WikiTextのままでも読みやすくするためにインデントできる。
改行文字も無視できればより読みやすくできるが…。行頭空白の連続+改行文字を無視するのならできそう。
それよりもテキストエリアの行間を広げられればそちらのほうがいい。
場所によって変わる補完候補 †
テキストボックスに補完型指定。
補完リストの内容を変える。
項目セットと、動的な(入力中に収集するような)項目も。
項目セットはページの内容。
ということは補完型は特定の単語を含むページ?
動的な項目はwikiの機能呼び出し?機能名や呼び出しパラメーターを補完型ページに書いておく?
顔文字はインラインタグ †
顔文字記法。CSSセレクター付けて。
普通のテキストと見分けは付かなくていい。
リンク先はタグと同じ。
自然にいつの間にかタグ付けできる。
近い顔文字を同一視したい。近いページを探せれば十分。
特定単語がタグ †
自動リンクと同じように、記法でも何でもない言葉がタグ化。
クリックで検索可能なだけ?
ページ属性を特定のものにしてページを作ると、自動リンク先が検索になるとか。バックリンクだけのページとも言える。
タグっぽく見せたほうが使い道があるかも。見た目が変わらなければ範囲選択→検索のUIのほうが使い勝手はいい?
古く見えるテーマ †
スタイルテーマ。
ページやセクションの日付に応じて、文字はかすれ色はあせていく。
使う日付はセクションに書かれている日付記法か、それが無ければセクションの更新日時。
日付が複数書かれていればそれらの平均値(に近い実在する日付)にする。
これで意図的に古くすることができる。
アイデアノートに。古いアイデアは更新するよりも保存しておく方が簡単。必要なときに見つかればいい。使うアイデアだけ更新して保守。
テキストボックスに選択文字列 †
常設テキストボックスには常に選択文字列を入力
例えば検索とかページ新規作成とか
新規作成ならDanglingLink不要になる。
明るく暗くをランプで †
暗いスタイルテーマにランプを含める。
位置はページ端。スクロールで見えなくなる。
左上にドラッグして明るく、逆は暗く。
青い光。
特に説明は要らない。隠し要素。
RecentChangesのビューにwikiが発展する様子を表したい †
選択文字列に一言コメント †
コメント投稿では選択文字列と選択位置も記録
位置はすぐ上の見出しIDとその見出しからの文字数
そのページの編集者かウォッチャーが閲覧したときに本文上にも表示。
位置指定が曖昧になりやすいので、最も近い位置に表示。
見つからなければ非表示。そのため一覧も用意してそこにも表示。
一覧から表示位置へジャンプ可能に。逆方向にも。
X-Runtime †
処理時間を出すならHTTPヘッダー X-Runtime でいい。
なぞなぞ認証 †
なぞなぞに正解した人に一時的な・ページ毎に異なる編集権限付与。
例えばページ作成者がなぞなぞ設定にする。問うのは議論の争点。選択肢式で複数、あるいは文字入力で1問。
ゲスト(非ログインユーザー)にも適用できてWiki向き。
1IDに1パスワード †
複数統合もしない
オープン認証だけ †
パスワードを保管しない
オープン認証ではユーザーIDにサイトドメイン追加 †
anon@twitter.comなど。長くなる。
オリジナルテーマを作って広める †
Chromeテーマやブログテーマとして。
1ページに集めるだけで「そのうちまとまる」と言えるのか? †
「ぶっこんでおけばそのうちまとまる仕組み」
パーマリンクには内部名を使う †
分かりやすくするなら、Amazonのようにページ名も付ける。でも使うのは内部名だけ
汎用プラグイン記法はどんな書式? †
<<plugin p1:... ...>> <plugin p1="..." ...> #plugin(p1=..., ...)
複数の記法を許可。全角文字でも。
名前付き/匿名パラメーター混在可能。匿名パラメーターには左から順に自動当てはめ。
草稿 †
NOINDEX期間の版を「草稿」として、最新版とは区別。最新版は草稿でない版の中の最新。
権限を持ったユーザーはNOINDEX期間を終わらせることができる。
で、草稿は版を明示指定しないと誰からも見えない。草稿があることはバナー表示でわかる。履歴から差分表示するときなどは版を明示しているので普通に見える。
これでWebAPI経由でページを外に出せる
ブログパーツとか、DataWikiとか、iPhone向けのHTMLアプリのUI作成とか
メール送信記法 †
どこに、いつ、
ほかの記法で書けばそれぞれのUIでその場編集ができたり。
アクティビティのカレンダー表示 †
全リビジョン含めた自分による更新履歴をカレンダーに書き込み。数が多くても見やすいように日付は一列レイアウト。画面スクロールあり。
tipsかるた †
tip of the dayを日本風にすると…Wikiかるたか、今日の「できる!」なんとかWiki。一文字目の重複・欠けがあっていい。
バックリンクと一緒に名前変更 †
ページ名変更で、1つのWikiにある全てのリンクも変更
名前のリファクタリングを可能にする
リンクオブジェクト向けの変更履歴に変更前後の名前を追加、リンクオブジェクトは可能なときに参照、反映
保存を伴わなくていい?次もまた反映しないと
いつ反映されるのかわからないので、変更履歴を消せなくなる
変更後に作られたリンクにまで影響してしまうので、やはりすぐ反映させないと。
よく使うコマンドを上げる †
よく使うコマンド枠を設置。
既存のメニューは変えない。
ナビゲーションや編集時の書式・ヘルプ表示なども含めて。
前後ナビのデザイン †
複数のナビを同時に生成するので、スタックのできるデザインに。
ページは空でも消さない †
ページ名を空にすると消える。
見出しだけを書くと空の下位ページを作る。で辻褄合わせ。
つまり、アクセス手段がなくなると消えるということ。でもOrphanは消さない。そのOrphanページの編集でアクセス手段がなくなるわけではないので。
APIバージョン †
プラグインになるクラスすべてにAPIバージョンの指定を。「APIバージョン…を使用中」という表明。
プラグインのバージョンではない。
それをどう判断するかはフレームワークによる。
spec:1.0.* など。
利用者ページに書くこと †
利用者ページには設定というよりもユーザーが表明していることを書く。
検索には高いレスポンス性能が必要 †
または繰り返さなくていいような検索結果…UXを。
検索はシステムも使うので、1回のレスポンスまでに複数回検索を使うことになる。
エクスポート †
テキストで、UTF-8やShiftJISで。
SVGで1枚に4ページ掲載(4in1)とか。
ePub、PDF、E-InkデバイスやKindle向け。
Wikipedia形式。
- -
- ダウンロード
- Webブラウザーで開く。どうなるかはクライアント環境次第。
- 交換後URIを共有、メールとか
URLを貼るとブクマと☆も表示 †
UI 画面切り替えには前後画面に1つだけ共通点を †
クリック、項目がオレンジ背景に → 見出しが背景オレンジで表示、背景色がフェードアウト。
- -
色を共通点に使うのなら、全体的に白紙風デザインに。
1つだけしかない共通点が目立つように。
ぐにゃぐにゃできる検索結果 †
ビューをクライアント側にも分割。フィルタリングやソートを可能に。
サーバー側では関連情報を含めて取得。情報が多すぎてもクライアント側で要求にあう情報に加工できればいい。
フィルタリングとソートを、縦/横方向にできるように。横ソート/フィルタリングは手作業で。
…と、結果中に関連項目があればツリー化。関連元でまとめ。関連元が親になる。
1つの親に複数の関連名があるので、それをどう区別してグループ化するか。→親→関連名→子にすればいい。
関連を持つのはページくらい。
ツリーだけど、列は親子で共通。一覧性を損ねないように。
ツリー以外にも色分けでグループ化とか。行入れ換えはしなくていい。セルの背景色を変えるだけ。
ぐにゃぐにゃするために、サーバー側でもクライアント側でもフィルタリングとソートを。
ページロード時に枠しか見えないのは不満なので、サーバー側でのフィルタリングとソートの結果をデフォルトにしておく。その後クライアント側での操作でクリア、再描画。
サーバー側では普通に検索結果を作るということ。クライアントと機能が重複する。
実装では
検索要素の出力を、テーブル要素に与えて。テーブルHTMLにはクライアント側のフィルタリングとソート機能を持たせて。
テーブルにはセルごとの背景色…は要らない。どの列の値を背景色に反映させるか変えられればいい。
ファセット検索の機能もテーブル要素に。集計とフィルタリング。
テーブルのフィルタリング機能に、選択項目のハイライトを。
ブラウザー上でセルを選択すると、同じ内容を持つセルをハイライト表示。選択したセルも同じスタイルでハイライト。他のセルを暗くしたり淡色表示にしてもいい。
Wikiの分かりにくさ †
書き手が複数いる。大勢が全体を把握せずに編集。流れがなくなる。→分かりにくく
でも全体を把握しないと編集できないのでは書き手にとって分かりにくい。
書き手の分かりやすさと読み手の分かりやすさを両立するには?
起承転結の起と結が全ページにあればいい。
コンテンツヘッダーには版の作成日と著者リスト、直近の親ページ名でもあればいい。
起結はページの埋め込みで。つまり書き手が気をつける。「…を…するシリーズ。全15回を予定しています。」のような第一段落を埋め込みように作っておけばいい。
自動化したいなら親ページの継承される属性に入れておいて。←これがコンテンツヘッダー?
機能/前後ナビ †
Wikiの:t/分かりやすさのために。
兄弟ページ間をつなぐナビゲーション。ページ名で関連が決まる。
前後の順序は一定。変えるならサイト設定や継承可能なページ属性で。
これをページフッターやコンテンツヘッダーに入れておけば、日付をページ名にしてあるブログでも有効に使える。
親ページを見ることなく前後ページをたどれれば、読み手が細切れな内容のWikiで分かった感を得る手助けになるのでは。
兄弟ページ間での共通のコンテンツヘッダーと組み合わせて使用。
super要素 †
継承可能属性の中で使うために。
親ページを表す記法を。
これと属性名指定の記法を組み合わせて使用。
汎用記法でいい。
クリック、打ち込み、通知 †
UIでの操作は3種類。
ユーザー→システムはマウスクリックとキーボード打ち込み。(で、レスポンス→またクリックへ)
システム→ユーザーは通知(→クリックへ)
…くらいで事足りるはず。
通知方法は何種類も考えられる。
キーボードから打ち込むのは文章も記法もある。
クリックは見たものに反応するだけ。フリックや長押しもあるかも。
ユーザー→システムは文字データ。URIも文字。記法も文字。
システム→ユーザーは文字とその他メディア。でもこれはユーザーが入力したもの。
まず書く †
使い方を考えたとき、やろうとしたことまでが遠い。
読むにも書くにも「目的のページ」がある。そこにたどり着くまでには広告だけでなく、ログインメッセージもパスワード入力もサイトの更新情報も、それ以前のアプリケーションアイコンやブックマークのリストも、すべて邪魔。
(その場では)使わないキーボードのキーさえ邪魔。
で、まず何をするか(ToDo)を書けるように。
- Wikiを開いて右上欄に文字を打ち込んでEnterか、OpenSearchで一言書く。
これでセッションページに記録される。 - Wikiがなにか提案
検索結果など。これは動的ナビゲーション。 - ユーザーが判断
ToDoは記録済みなので判断が入ってもいい。何をするかを忘れてしまっていい。
あとは普通に編集など。
右上 †
Spotlight風な右上。
/やタップでフォーカス取得。
モバイル用の専用クライアントならEvernote for Androidのようなフリックで現れる画面にSpotlight風な入力フォームを。ページ上にはタップできるものが散在しているのでそれ以上何も置けない。普段は読み専用、フリックで書く用のUI。
右上には新規ページ作成の機能も。
PukiWikiのページ作成のように、入力されたページ名が既存かどうかで読み/作成の両方できるように。
打つ→選択肢から「(打ち込んだページ名)作成」を選択→ページ作成へ
右上がページ作成の「ページ名」欄になるような。
とりあえずToDoを書けるように、Enterキーで打ち込んだテキストを残す。セッションページに記録。
複数行を貼り付けても残るように。複数行を入力したら複数行表示に拡張したい。
メモ化のキー †
個人情報が一般公開されないように、メモのキーにはセッションキーを含めて。
Wiki 編集UI リバートよりも前版コピペ支援 †
前版に戻すボタンよりも、前版をコピペできるビューへのリンク設置。
不要な版を隠すためであっても、リバートではなく新しい版にする編集であるべき。
お手軽リバートボタンならプラグインとテンプレート書き換えで。
管理者用のビューテンプレートに追加しておけば一人運営に便利。
一秒以内の編集ボタン→投稿ボタンには応じにくい †
秒単位でしか時刻を管理しないとして、他の利用者も編集ボタンを押したりすると、最新版の判断ができないから。
編集ボタンを押す直前に気付きにくい荒らしがあったら? †
押してからも、投稿ボタンを押すときも気付かないとしたら?
自動的に出る「追記」 †
リバートは管理者グループのものでいい †
荒らしと不服な編集は似たようなもの。リバートの省力化は特権を持つ利用者向け。
内容依存なFoldingTextはできないか? †
Gmailのように同じテキストが省略されるようにするには?
・省略単位が必要
Gmailではメールごとに数行の重複があれば、行単位で省略。この「メール」にあたる単位は見出し?
・一文字だけ異なる行があったらどうするか
・省略して何を残すのか?
日付で分ける以外の目次インデックス作り? †
UI、閲覧しやすするもの
TOCのインデックス。
ブログなら日付、Wikiならページ名、掲示板ならトピック名と日付。
…だけ?
名言 †
名言をどこに入れるか
インストール直後
エラー時
アンインストール直前
セッションの終わり(開始時は邪魔)
読みにくさ解消 †
コンセプト/Wikiは読みにくい
見出しは分割←短いなら読みやすい…ではなく入口を増やすためのもの。ここから読もうかというもの。
見出しごとにつかみがいる。というか見出しはつかみ。続く第一段落はつかみの完全化。そして起承転結へ。第一段落まででここにはなにが書いてあるか判断できるように。見出しは入口であり入らずに通り過ぎるときの出口。
というのを見出しごとに行なうには…
テンプレート?自分への注釈?
完全に書き方の問題。
追加と編集は別権限 †
universe->space->entry->side->section->revision †
1つのsideに複数section。
オブジェクトはsectionのみ。
上下関係は考えなくてもいい。すべてSectionの属性。
ファセットWiki †
http://meatballwiki.org/wiki/PeriPeri
"Facet Terminology"