:Done のバックアップ(No.5)

ウィキエンジンX / :Done
 
バックアップ

Send to your Kindle
  • バックアップ一覧
  • 差分 を表示
  • 現在との差分 を表示
  • 現在との差分 - Visual を表示
  • ソース を表示
  • :Done へ行く。
    • 1 (2011-12-14 (水) 01:29:17)
    • 2 (2013-03-20 (水) 22:27:31)
    • 3 (2013-03-23 (土) 08:14:31)
    • 4 (2013-03-29 (金) 05:26:00)
    • 5 (2014-01-23 (木) 20:31:37)
    • 6 (2014-01-24 (金) 13:28:59)
    • 7 (2015-07-27 (月) 08:46:40)

  • :Done/2つ呼ぶ記法
  • :Done/Forkしてページタイトルを変えるには
  • :Done/HTTP_ACCEPT…をどう反映するか
  • :Done/SPAM対策
    • 承認されたページとは
      • 同名ページ群内で得票の多いページ
      • 承認されたページから明示的リンクでリンクされているページ名
    • 承認されたページを判定する他の方法は?
      • 3つのケースそれぞれの対処方法
      • :i/SPAMと正当な新コンテンツの差
    • コメントの追記に対しては?
    • 結局
  • :Done/TwitterをWikiのスレッドモードとして使うには
    • 関連
    • メールとTwitterは同じ扱い?
    • Twitterへフィードバック
    • botがWikiを読み書き
    • wikiに書かなくてもいい
  • :Done/Twitter連携するときページ名をどうするか
    • 命名ルール
  • :Done/Variablesで自動リンクの優先順位を実装できるのか?
  • :Done/Wikiはリンクが面倒
    • アウトライナーと比較
      • 構造の違い
      • 順序の違い
      • アウトライナーの特徴を取り入れるには
  • :Done/WikiエンジンがWordPressのようになるには
  • :Done/「リンク先」ファセットの大きさにどう対処するか
    • 例えば、
  • :Done/「編集UI」と書いたのに「UI編集」になる
  • :Done/「自分にとって」はプレビューモード
    • 「自分にとって」からプレビューモード開始
  • :Done/おすすめコンテンツは広告
  • :Done/どこに書くか
    • 内容が移動先を決める
    • 追記するなら追記先は文字入力で
  • :Done/まとまるだけでなく、切り口も
    • 方法
      • 切り口から新しいまとめを作るには
      • 検索結果での共起関係
      • 下位展開とリンクで
      • :i/検索語もタグにする
  • :Done/よそのシステムをUI上で統合するツールとして使えるか
    • 実装可能か
  • :Done/アーカイブと削除と下書きと作成と
    • アーカイブ
      • 対象はページ
    • 削除
    • ページ/作成
    • 下書き
  • :Done/アーカイブと削除の違い
    • アーカイブ属性
    • :Done/バックリンクの多いページは変更が困難に#ja9ebeea
    • アーカイブは特定版に星/スターを付けて削除すること
    • 違い
    • アーカイブ属性を外す操作とUIが要る
    • ページ名変更は影響するか
    • アーカイブは削除を伴うほうがいい?
  • :Done/ウォッチリストはコレクションか
    • コレクションはページセットの通称
    • 他でもページセットが使えればいい
    • コレクションの内容表示
  • :Done/エディターについて
  • :Done/オートフォーマットは導入できるか
  • :Done/クライアント側にサービス側オブジェクトのProxyを作るには
  • :Done/サイトの目次を作るには
  • :Done/サイトをまるごとABテスト
  • :Done/サブセットWikiでは不要なDanglingLinkができる?
    • DanglingLink化しない?
    • DanglingLink化する?
    • サイドバーは別のサブセット
  • :Done/サブセットモードの解除操作
  • :Done/サブヘッダーをページ属性にできるか
    • ページ/属性にすると?
  • :Done/シンタックスシュガーを復元するには
    • シンタックスシュガーは復元できない?
    • シンタックスシュガーはNotationTextを残さなければ復元できない?
  • :Done/スナップショットは必要か
    • 必要な情報はさまざま
    • サブセットWikiの場合は統合できなそう
    • → スナップショットは名称を変えて残す
  • :Done/スペースの下に見解があるのはおかしいか
    • 重複の問題
  • :Done/スペースを統合するには
    • 統合しても消さない
    • 分離は不可能
  • :Done/スレッドと同名ページを下位展開で表示するには
    • 同名ページとは競合しない
    • スレッドを表示できそうなところ
    • スレッドモードはドキュメントモードと区別しない
    • 編集ビューにも影響する
    • スレッドを書くUI
    • 下位ページに言及してもいいように
    • 細切れになったスレッドでコミュニケーションしてもらえるか
    • 特定のページ構成に依存していい
    • 結論
  • :Done/スレッドモードと版
    • スレッドモードと版の比較
    • スレッドモードで1件追加されるたびに新しい版が作られるない
  • :Done/スレッドモードは不要
    • 下位ページでスレッドモードを実現すると?
    • 元々スレッドモードはドキュメントモードの一部
    • 違いは人気か新着か
    • ドキュメントを侵食するスレッド
    • 投稿ごとのページか
    • 1ページ分のスレッドを単一ページにする必要はない
    • ページ名に共通部分を
    • ページの中にドキュメントとスレッド
    • 見せ方/スタイル
    • 下位展開との併用
  • :Done/スレッドモードを再考
    • スレッドモード主体にすれば、Twitterのようなwikiになる
    • :Done/スレッドモードは不要だけど、情報提供は受けられるようにしないと
    • スレッドモードも自分にとってのもの
    • スレッドモードを主体にする必要はあるか?
    • スレッドモードの見せ方
      • :i/スレッドモードの下位展開
      • :i/スレッドの見せ方
      • :i/トラックバックをどこに表示するかと同じ解決策になりそう
      • スレッドモードを表示するなら、省略表示
      • 下位展開とスレッドモードの相性が悪い
  • :Done/セクションと版の競合
  • :Done/セットの扱い
    • ページセットをフィルタリングするのは要素
    • ページセット以外は?
    • :i/ハブとして機能する要素
  • :Done/ソートはスコアリング結果で決まるのでは
    • 検索/ソートは要らない
    • 検索/フォーマットでソート順を変えられるようにしてもいい
  • :Done/タイムマシンモードでの閲覧時展開
  • :Done/タグとはページか
    • タグとは?
      • ページ?
      • ページ/要素?
    • タグをページにする理由
    • タグをページとしない理由
    • 自動リンクをタグ付けとするのは有用か
    • なぜ階層化したいか
    • リンク
    • 他の要素との整合性
    • タグであることを検索に反映させるには
    • 共起タグ
    • やはりページで
  • :Done/タグに色づけ
    • 方法
  • :Done/タグのようなディレクトリ名に対応した自動リンク規則
    • 近いページ
    • 順不同に対応するアルゴリズム
  • :Done/タグ別の一覧を作るには
    • タグとは…例えば順不同パス
    • タグとは…ページ/要素
  • :Done/ダッシュボードはスペースの外に
    • 「どこか」ではなく「すべて」
  • :Done/テンプレートはサーバーレンダリングか
  • :Done/デフォルトスペースは管理用
  • :Done/データアクセスでやりたいこと
    • 集計
      • データアクセスの一例
      • 例えば、日付の集計をするには
      • 例えば、検索結果の1日前を調べるには
      • 例えば、「検索結果に含まれるページ」が持つタグを集計
      • 一般化すると…
  • :Done/データアクセスでページ要素を更新したい
    • 通常のページ書換えは総入れ替え
    • JSONで更新できるか
    • 対象要素自身に指示を出す
    • 要素に絶対パスを与える
    • JSONもNotationTextも同じ用途
  • :Done/データアクセス/データコンテキスト/ビュー/ページ型を統合
    • 問.データアクセス、データコンテキスト、ビューにつながりはありそう?
    • つながり
  • :Done/ノートの実装は見解か
  • :Done/バックリンクと呼ぶかリバースリンクと呼ぶか
  • :Done/バックリンクの多いページは変更が困難に
    • 「修正ではなく新しいまとめページを作るのがおすすめ」
  • :Done/バックリンク先もページセットになるか
  • :Done/バージョン管理の考え方を取り入れると
  • :Done/パーマリンクは特定見解?
  • :Done/ビューとコンテキストの統合
    • ビューはMVCのView
  • :Done/ビューとレイアウトとテンプレートと
    • テンプレートとは
    • 全部「テンプレート」と言っておけばいい
    • ビューとは
    • レイアウトとは
  • :Done/ビューとレイアウトの違いをはっきりと
    • Traction TeamPageをヒントにすると
    • 下位展開はビュー?レイアウト?
    • :i/レイアウトも下位展開も実装はページセットを受け入れるテンプレート
  • :Done/ビューと閲覧と編集
  • :Done/フォローのUI
  • :Done/フォークの仕様が複雑
  • :Done/フォークは下位ページも含むか
  • :Done/フローをストックするためのWiki
    • フローをストックするためのWiki
  • :Done/ブログや掲示板として利用できるか
    • 順不同パスのせいで日付を書きにくい
  • :Done/プラグインが開発しづらいのでは
  • :Done/プレビューモードのまま仮公開したい
  • :Done/プレビューモードはタイムマシンモードの中で使う
  • :Done/プレビュー・ロケール・デバイス・権限の判定はどこで?
  • :Done/ページの中のページは不可か
    • ページはElementではない
  • :Done/ページの拒否
    • 拒否情報をどこに記録するか?
    • 閲覧以外の拒否は?
    • 他の方法は?
  • :Done/ページの発展が分かるビューとは
    • 複数世代の差分をどう見せるか
    • 追加だけ/削除だけを見せる方法
    • 使い道
    • 動画化
    • 2行表示
  • :Done/ページの統合/分割は段落移動で
    • 見出しと段落の二重構造が面倒
    • 空のページができてもそのまま
    • 新しいページを作るには
    • 非対称な操作方法が問題
    • →必要なのは移動ではなく見出しの入力
    • これを下位展開ビューで
  • :Done/ページは下位ページを含まないか
  • :Done/ページを分割/統合しても情報の履歴を追いたい
    • ページ/履歴で追う
    • 過去版を含む検索で探す
  • :Done/ページセットでページ構成も変更可能にしたい
  • :Done/ページセット取得記法とエレメント取得記法
    • ページセット取得記法
    • セクションリーダー記法(節読み記法)
    • いらない
  • :Done/ページングかスクロールか
    • 分ける設定は無意味
    • スクロール式で
    • スクロール式の利点
    • タグとしての活用
    • 例
    • 結論:スクロールで
  • :Done/ページ内容からいい目次を作るには
  • :Done/ページ削除のUI
    • ユースケースの始まりはどんな状況?
    • 承認の自動化
    • 削除と復帰の手間は同等
    • 削除予定→削除
    • 削除でも編集と同様な関連情報を
    • 削除予定はページ名変更
    • 削除予定マークに日時は不要
    • Del!とNew!
    • セクションの削除でも
    • 編集/承認にする
  • :Done/ページ名だけを指定したときは全見解・全版も含むか
    • 過去バージョンの更新日時も含むか
  • :Done/ページ名の入れ換えはどう行われるのか
  • :Done/ページ名の自動生成
    • 方法
  • :Done/ページ名を誰でも変更可能にすると
    • ページ名を変更された後でも、普通に復帰できる?
  • :Done/ページ名一覧と見出しの統合
  • :Done/ページ名以外の表現方法
  • :Done/ページ名変更で投票状態はどうなるか
    • やり直しの仕方
  • :Done/ページ型を常に有効なものにするには
  • :Done/ページ型/スレッド/データコンテキスト/記法定義まとめ
    • ページ/型について再考
      • ページ/型は添付ファイルの型
    • ページの内部
      • スレッドは1件1件がドキュメントと同じ型
      • 属性領域はただのページ
    • ページ/属性を何かと統一できない?
      • 特殊な点
      • データコンテキストの指定で属性/継承すれば分かりやすい?
    • 記法定義
      • 記法定義をどこに書くか
      • 記法――オブジェクト変換は双方向
      • 要素を2系統に分ける
      • 記法系ごとのクラスは必要
    • 記法定義とデータコンテキストとページ/型
      • ページ/要素が対応すべきデータコンテキスト
    • ほか
      • CSVコンテキストでは最上位のみフィールド生成
  • :Done/ページ属性を使うときどこに問い合わせるか
  • :Done/ページ属性を検索対象にするには
  • :Done/ページ編集の方法
    • 編集ビューになるまで
    • 投稿すると
  • :Done/ページ自動更新時の権限
  • :Done/ページ要素のライブラリ
  • :Done/ページ要素はページ
  • :Done/ページ集合の指定方法
    • ワイルドカード?
    • サブセットWikiを作る?
    • ページ名を一部だけ指定することはできる?
    • 機能次第、または代表拒否で
    • 制限
    • 任意の代表を拒否するには
    • 代表を含んだ集合を指定するには?
  • :Done/モデレーション期間に差し戻せるか
  • :Done/ユーザーページではなくワークスペース
    • ほかには
  • :Done/ユースケースはコントローラークラス
  • :Done/リダイレクトページが下位展開に含まれていたら
  • :Done/リンクの上位クラス
    • リンクは関連名を持つが、その持たせ方は?
    • 他オブジェクトとの関わり合い
    • ページ?
    • 検証
    • 解決済み
  • :Done/リンクは階層か
  • :Done/リンク元をどう記述するか
    • リンク先は表現できる
  • :Done/ルートページをリクエストすると、どこまで下位展開されるか?
  • :Done/一覧に検索スコアが渡るまで
    • 機能/一覧にどうスコアが渡るか
    • 検索(スコアあり)と、表作成(スコアなし)の差をどう埋めるか
    • ()内は出力されるデータのはず
    • 解決
  • :Done/一覧を加味して、検索結果をソート
  • :Done/上位ページが削除されると、編集不可でも削除か
    • 編集不可でも削除は可能か
    • 編集不可でも復帰はできるのか
  • :Done/下位ページがユーザーに見えないなら、下位にしても無意味?
  • :Done/下位ページをどうレイアウトするか
  • :Done/下位展開で下位のページ属性は参照できるか
  • :Done/下位展開といろいろなビュー
    • 閲覧時
    • 編集時
    • 履歴表示時
    • 検索時
    • ほか
  • :Done/下位展開と自動リンク
  • :Done/下位展開にはページ内リンクもある
  • :Done/下位展開はサブセットWikiと相性が悪いのでは
    • 下位展開しないところでは問題に
    • サブセットWikiの外も判定材料に
  • :Done/下位展開を再考
    • 必要な情報は利用者が持つ
    • デフォルトで下位展開する
    • 同じページが何度も現れる
    • 下位展開は連鎖する
  • :Done/下位展開を分かりやすく
    • 一部だけ非表示になると分かりにくい
    • 書いた通りに読めれば問題なし
  • :Done/下位展開時、本文記法にどうページを渡すか
    • 埋め込まれ
    • このままでもいい
  • :Done/下位展開時の枠はコンテンツに合わせて伸縮するか
  • :Done/下書きをどう実装するか
    • 見えない名前にも衝突
    • 名前が無ければいい?
    • 下書きと削除は同じ?
    • 下書きはプレビューか
  • :Done/他言語版をどこに置くか
    • 却下。でも、ページ一覧は言語ごとに分けるべき
    • ページ名の下に複数の言語別コンテンツがある
    • 順不同パスにより、上下関係はどちらでもいい
    • 言語設定はページセットを作る
    • ルートページは
  • :Done/保存された検索(検索リンク)はどう書くか
    • 「保存された検索」は別
  • :Done/個人のWikiなんて誰が書き換えるのか
  • :Done/内部名のフォーマット
  • :Done/内部名を再考
    • 内部名はページ名の分だけ
    • メジャーID、マイナーID
    • 版を含まない
    • 同名ページ内のIDが必要
    • 自動リンクされる内部名はどう決まるか
    • 結局、内部名は必要
    • ページ名を変更した場合2通り
    • マイナーIDのほうがメジャーぽい
    • 変更点
    • 最新版を指すURIがない
    • 再々考
    • ページ名変更は編集のうち
    • 自動リンクは内部名を保持
  • :Done/凍結はアーカイブのことでは?
    • 関連
  • :Done/利用者の権限はどこに書くか?
    • ページと利用者をどう関連付けるか
    • どちらがより追加・削除されるか
    • 両方に対応?必要
    • 見やすさ、分かりやすさ
    • 一方を変えると同期?独立させる?
    • 権限を分けなければならない
  • :Done/利用者はスペース別か
  • :Done/利用者ページのスレッドモードがブログか
  • :Done/削除予定はどう解除するのか
  • :Done/動的に生成されるページをウォッチするには
    • 存在しないページもウォッチするには?
  • :Done/動的に生成したページでもデータアクセスを有効に
  • :Done/区切り文字で終わるページ名
  • :Done/参照したときすでに古いかも
    • 最新版
    • 編集の衝突判定で解決
    • ロック
  • :Done/古いことが(初見さんにも)分かるようにするには
    • 古さをどう見せるか
    • 範囲を限定
  • :Done/各種ログエントリーにも権限が必要か
    • ログエントリーの権限(錠)はどこに記録するか?
    • 同じログのサブセットを作る
    • 行の内容を増減するのは無理
    • 行ごとにページを用意する手も
  • :Done/同名ページの更新日時順とは
  • :Done/同名ページはひとりにひとつか
  • :Done/同名ページ群から属性を継承するには
  • :Done/同名ページ/フォークしたページ/SisterWikiページを再考
  • :Done/名前がなければリンクできない
    • 自動命名
  • :Done/外部名1つには複数の内部名が対応する
    • フォークかリバートかを選ぶのは利用者
  • :Done/大きくなればなるほど追加しづらく壊しやすくなる問題
    • :Done/バックリンクの多いページは変更が困難に
    • すべて捨てる
    • バックリンクを元に探せる
    • 同名ページにする
    • 読んで理解するための支援が、書き手にとっても役に立つ
    • 解決は不可能
    • Webサイトとしては壊れていてもいいのでは?
  • :Done/定義可能な記法と記法系変換について再考
    • NotationTextの復元
    • ビルトイン要素でシンタックスシュガーがあるもの
    • Markdownのさらに細かい記法系を選ぶUI
  • :Done/属性と権限について再考
    • 属性/継承や権限判定は読む側で行なうのか
    • 権限の権限・属性の属性
    • 権限と、権限を扱う権限はどこに書くか
    • 権限を設定する権限
    • 設定はページ本文/属性領域1つごとに行なえればいい
  • :Done/属性の継承法則
    • 同階層で競合する属性はマージ/異階層は上書き
    • 属性のマージは却下、優先順位を定義
    • 独自のオーバーライド処理
    • 継承ルール
    • 継承ルール
    • 同名ページもある
    • 属性値にページ名を設定したとき
  • :Done/属性は本文を見ながら編集したい
  • :Done/属性継承時の権限判定は?
    • 継承不可なら権限設定が行われなくなる
    • 判定不要にする
    • 属性設定時に権限判定
  • :Done/履歴とは何か
    • :Done/履歴を残さない
  • :Done/履歴はオブジェクト形式で?
  • :Done/履歴はページ単位かセクション単位か
  • :Done/履歴をまとめるよりも、表示だけまとめたほうがいいのでは
  • :Done/履歴を残さない
  • :Done/差分の選び方
  • :Done/情報が失われていないという確証を得るには
    • ログの整合性を確認するツールを用意
    • Wikiの分析結果を振り返れる
    • 過去版を含めた検索ができれば十分?
    • 集計(概要)とソース(詳細なデータ)で
    • 見つかればいい
    • アクセスログがあればいい
  • :Done/情報を扱えるシステム
    • 書き手しか知り得ない情報
    • メタデータは誰かが作る
    • 上位と下位(概念的か具体的か)
    • ページ分割は情報を見つけにくくする
  • :Done/情報構造のテンプレート
    • 要するに一覧の見せ方
    • このテンプレートもページ
  • :Done/投票が分かりにくい
    • 投票の影響範囲が広すぎる
  • :Done/投票とコレクションについて再考
    • 投票について再考
      • 投票は選ぶだけの知的生産
      • 投票は順序替えでもある
      • 投票はページ名に相応しい版を選ぶ操作
      • 投票候補は同名ページのうちの最新版
      • Wikiが目指す民主制は投票ではない
      • 利用者間の衝突を投票で解決
      • 投票対象は履歴にある版
      • 投票を隠して、いつのまにか投票
      • 投票のUIは「いいね」
      • ページ名と内容は一体のはず
      • ページに投票での「支持率」を併記
      • どんな処理でも投票を反映しなければならない
      • 次の版や同名ページができるたびに投票
    • コレクションについて再考
      • コレクション
      • コレクションはページ
      • Wikiはコレクション
      • 共有領域で自分にとっての文書を作るのが投票とコレクション
      • SPAM対策は気に入らない投稿を決めるもの
      • コレクションは検索条件の集まり
    • 投票とコレクションについて再考
      • 投票とコレクションはUIが異なる
      • 義務的な投票と、自発的なコレクション
      • 投票とコレクションは選ぶものが異なる
      • 投票とコレクションは両立させる
      • コレクションには同名ページのすべてが入る
      • コレクション作成にも編集/承認がある
    • いらない
      • 投票が「選ばれた版の履歴」を作る
      • 投票期間
      • どのコレクションでも投票がある
      • 同じ版でもコレクションごとに別投票
      • 投票はコレクション別
  • :Done/投票とページの順序とフォークについて再考
    • フォーク
      • wiki/フォーク
      • Wiki全体を編集するにはフォーク
    • 下位展開時の順序
      • 下位展開時の順序替えも投票と同じように、フォーク不要で他人のWikiで行ないたい
      • 下位展開時の順序は利用者の下位に残す
  • :Done/投票をコレクションと統合しない
    • SPAMというコレクション
    • 自分のドキュメントを自分で隠してしまう問題
  • :Done/文書作成中に見えるもの
  • :Done/文脈を再現する
    • 読むための構成
    • 読むための切り口
    • 文脈生成方法
    • 文脈は複数ある
    • 作業内容と関連付ける
  • :Done/新しいページ構成を提案したいときは
    • 同名ページにも集約が必要か
    • ページ構成はページ名の集約
  • :Done/新しく追加された情報だけを読めるか
  • :Done/更新日時は下位ページのものも含むか
    • ページの更新日時は下位ページを含むか
  • :Done/最新版のつもりがそうじゃなかったとき
  • :Done/最近更新されたページは検索結果か
    • 検索結果をページに埋め込むと
  • :Done/検索UIの統合
    • 大検索と小検索の統合については
  • :Done/検索で日時範囲を指定できるか
    • :i/日時表現は1つでも範囲
    • いずれにせよ類似度を評価
  • :Done/検索はクエリーとページの類似度判定
  • :Done/検索フォーマットUI
    • 検索/フォーマット/UI
    • キャプチャーはRegexフィルタリングで
  • :Done/検索フォーマットは機能を呼ぶか
    • フォーマットは機能を呼ぶか
  • :Done/検索フォーマットを分ける必要は無いのか
  • :Done/検索時に自動リンクを順不同パスとして評価するには
  • :Done/検索結果でwikiを作りたい
    • 実装に必要なもの
    • 方法
  • :Done/概要をどう見せるか
    • :i/リンクのツールチップにはリンク先の概要を表示
    • 編集可能に
    • アウトラインコンテキスト
  • :Done/権限について再々考
    • 権限
    • 錠と鍵がある
    • 拒否(許可の否定)
    • 下位の管理者に与える権限
    • 錠はユースケースにもかける
    • 権限領域は隠す
    • 順不同パスのせいで属性名が重複する問題
    • 権限を書くところ
    • かかっている錠はすべて外す
    • 同名ページの権限領域は別々
  • :Done/権限の対象はページか見解か
    • ページ属性
    • ページの操作
    • 属性の継承元
  • :Done/権限の継承について再考
    • 権限セット(ロール)の実現方法
    • 下位の管理者
    • 全権限を継承
    • 与える人が持っている権限だけ継承可能
    • 関連
  • :Done/権限設定をページごとにしたい
  • :Done/死んでしまうドキュメント
    • 支援ツールとは
    • :i/眠るページ
  • :Done/段落内のリストをどう表示するか
  • :Done/添付ファイルをページ化する方法
    • 通常のページとは異なる
    • 解決策
  • :Done/版を再考
    • 用語
    • ページセットに版IDも含める
    • ページ名と版IDで区別
  • :Done/特定ページの更新情報をニュースフィードにするには
  • :Done/目次に出したいだけの見出しはどう書くか
  • :Done/細切れドキュメントと同名ページの仕様が衝突
    • 細切れドキュメントと同名ページの仕様が衝突しそう
    • 自分で自分のページを隠してしまう問題
    • 統合編集と同名ページの仕様が衝突しそうでしない
    • 見出しごと編集で見出しを書いても問題なし
  • :Done/細切れドキュメントはUI次第
  • :Done/継承は下位展開の影響を受けるか
    • 矛盾点
    • 無い属性だけ補完?
    • 下位展開付きの場合のみ?
    • 下位展開のルールを無視して?
    • やはり影響されないことになる
  • :Done/編集ボタンを押す直前に気付きにくい荒らしがあったら?
  • :Done/編集時、編集できない部分はどうするか
    • 1. 下位ページ(見出し)ごとに編集権限が必要
    • 2. 元から編集時に展開しない
    • → 1。編集可能な部分のみ展開。
    • 編集不可能なWikiTextが見えなくなる
    • 3. 統合編集を禁止
  • :Done/編集時の下位展開 で一部権限不足だと…
  • :Done/編集権限のある利用者一覧作成方法
  • :Done/編集権限のないWikiからフォークはできるか
  • :Done/自分にとってのFederationとは
    • みんな自分のスペースにだけ書き込める
    • :Done/同名ページはひとりにひとつか
    • 投票もフォローも他のスペースのものに対してするもの
    • :i/みんなのスペース
  • :Done/自動リンクの仕方を再考
    • 区切り文字から末尾一致/先頭一致/完全一致
    • 自動リンクの種類
    • 文字同一視
    • あらかじめ解析
    • 字句解析と単語列解析
    • 長さ優先なら単語数で
  • :Done/自動リンクは埋め込み前か後か
  • :Done/複数ある設定ページをまとめるには
    • :Done/属性の継承法則
    • :Done/継承は下位展開の影響を受けるか
    • 目標
  • :Done/複数行記法をwikiで定義する書き方
    • ToDo/機能呼び出しで複数行パラメーターを書くには
      • ただ改行を含めて書く
      • 置き換え
      • ブロックにする
      • ページ全体
      • 答え
    • 必要な処理
    • 答え
  • :Done/要素がアクティブなWiki/Page/Userを得るには
  • :Done/見出しレベルとページ階層の深さが競合
    • 見出しレベルとページ階層の深さが競合
    • ページ作成時のページ名に区切り文字を入れたときは?
    • 見出しの重複が許されないのでは?
    • 見出しレベルの指定は、相対的な指定にする
  • :Done/見解が分岐しても内部名は引き継ぐ
  • :Done/見解に名前を付けるべきか
    • 方法
    • パーマリンク
  • :Done/見解を再考
    • 権限にも複数見解があるのは複雑
    • 1つの見解を1つのページにしたら簡単になるか
      • 投票反映までが影響範囲
      • 統合後でも再分離可能
      • 影響のありそうな箇所
    • 代わりになる呼び方
  • :Done/記法の衝突対策
  • :Done/記法の選び方
  • :Done/記法定義の方法
    • ビルトイン記法とプラグイン記法に分ける
    • 複数行に渡る記法
    • ビルトインとプラグインでは異なる
  • :Done/設定はいくつでも重複可能か
  • :Done/誤字に対応するには
  • :Done/賑やかさ
    • 特設ページではいけない
    • 丸窓にプロフィール画像?
    • 閲覧数(PV)のようなものを見せる
    • 役に立たないコメントを書ければいい
    • 付箋やマーカーでもいい
  • :Done/適度な自動リンク
    • 自分の知らないリンクに価値がある
    • 問題は見た目
  • :Done/選んでもいない見解が代表になるのは良くない
  • :Done/選んでページセットを作るには
    • 生存期間
  • :Done/関連するタグしか付いていないページを探すには
  • :Done/集めるだけでまとまるのか
    • 読むためのノート
    • 関連情報を集めやすく
    • :Done/大きくなればなるほど追加しづらく壊しやすくなる問題
    • :i/結局、読みやすさ
  • :Done/非公開情報の伝播
    • 処理方法
    • 出力先を調べる
    • 公開範囲が決まってから読み込まれる
  • :Done/鮮度維持
    • 方法
    • 同じ名前のページを作ろうとした場合
    • 新しいページを書いてしまってから、古いのをなんとかする
    • つまり…
  • :Done/鮮度維持の続き
    • 手順
    • ページを複数選択、一括処理
今日2 昨日2 / 合計2702 :閲覧数

コメント:
  • https://mobile-mods.ru/ — это интересный способ улучшить игровой процесс. Особенно если вы играете на Android, модификации открывают перед вами огромный выбор. Я лично использую игры с обходом системы защиты, чтобы наслаждаться бесконечными возможностями. Модификации игр дают невероятную свободу выбора, что взаимодействие с игрой гораздо красочнее. Играя с модификациями, я могу добавить дополнительные функции, что добавляет приключенческий процесс и делает игру более захватывающей. Это действительно захватывающе, как такие модификации могут улучшить игровой процесс, а при этом с максимальной безопасностью использовать такие модифицированные приложения можно без особых рисков, если быть внимательным и следить за обновлениями. Это делает каждый игровой процесс персонализированным, а возможности практически широкие. Рекомендую попробовать такие модифицированные версии для Android — это может придаст новый смысл < Try Out Free Meetup Apps To For Just Sex[?] New!
  • https://mobile-mods.ru/ — это интересный способ улучшить игровой процесс. Особенно если вы играете на Android, модификации открывают перед вами огромный выбор. Я лично использую игры с обходом системы защиты, чтобы наслаждаться бесконечными возможностями. Модификации игр дают невероятную свободу выбора, что взаимодействие с игрой гораздо красочнее. Играя с модификациями, я могу добавить дополнительные функции, что добавляет приключенческий процесс и делает игру более захватывающей. Это действительно захватывающе, как такие модификации могут улучшить игровой процесс, а при этом с максимальной безопасностью использовать такие модифицированные приложения можно без особых рисков, если быть внимательным и следить за обновлениями. Это делает каждый игровой процесс персонализированным, а возможности практически широкие. Рекомендую попробовать такие модифицированные версии для Android — это может придаст новый смысл < Try Out Free Meetup Apps To For Just Sex[?] New!
  • 社内Wikiの作成と知識の共有なら| Lark Wiki < :Dashboard/pmint

→ 過去のコメント

 

バックアップ ヘルプ 最終更新のRSS  
pmint.name; "Soft Wallpaper" by Atle Mo, "Slash it" by Venam / CC BY-SA 3.0; "Caviar Dreams" by Lauren Thompson
Powered by PukiWiki Plus! 1.4.7plus-u2-i18n/PHP 7.2.34. 0.120sec to conversion.