通知/Sorting schemes

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Notifications/Sorting schemes and the translation is 100% complete.
Other languages:
Bahasa Indonesia • ‎English • ‎español • ‎français • ‎polski • ‎العربية • ‎中文 • ‎日本語 • ‎한국어

タスクの全体図として右記を想定しています。通知の種類を2群に分類 (例:"新規の利用者ページ向けメッセージ usertalkpage message"、"編集が差し戻されました"、"作成したページが●●にリンクされました"、"感謝" など)。 現状の分類には問題がいくつかあります

もともと提案は2つありました。 フィードバックを受け、現状のスキームに対して1案のみ残すことに決まりました (2016年4月時点)。 その点について皆さんのフィードバックを募集します (支持か不支持か、気がかりな点とか)。 推奨事項として、まずは「緊急度基準」で分類することにします (試作版はこちら)。

皆さんからのフィードバックの投稿先は タスク T123018 または MediaWiki.org のこちら でお願いします。

解決すべき問題点

現状では、受信通知 Notification flyout に2種類のメニューがあり、一方は警告用、他方はメッセージ用です。 通知のメニューによって、表示させる通知の種類を分けています。 これまでにメッセージを分別する基準の不明瞭さもしくは統一が取れていないとの批判が寄せられました。 具体的な批判の内容は次のとおりです。

  • 「緊急性」および「フォローアップが必要」という視点が混同され、それぞれの受信通知に間違った種類の項目が混ざってしまう理由の説明も予測も困難です。
  • 現状で「警告」項目は受信通知を開くと自動的に「既読に変更」されます。 それでも、警告の中には内容を把握するために読むだけでなく手順や操作が必要なものもあり (例:言及)、この機能の役割は必ずしも明確ではありません。
  • 「警告」は「緊急」だと解釈されますから、「感謝」その他の項目はその受信通知には不適切と受け取られる可能性があります。

目標

  • 理解やすく覚えやすく、予測しやすいスキームの作成。
  • 新しく受信した通知の情報を、編集者に明確に伝えること。
  • 緊急性の低い通知で無駄に作業の邪魔をしないこと。
  • 通知の受信件数の多い (または少ない) 編集者にとって便利なもの。
  • 新規の (要望があった) 通知の種類を作成したとして、それらがうまく拡張できること。
  • ウィキ間通知が可能になったとして、うまく拡張できる方式。

種類

もっともよく使われる通知の種類はこちら。 File:Notifications Catalog.png

選択肢

  1. 現行のもの
  2. 緊急かそうでないか
  3. (以前は使われたが廃止された) フォローアップかそうでないか (返信が必要かどうかに近い)

(この表はもっとも一般的な通知の種類を示し、特に注釈はありません。 googledocs にもっと詳細な版をご用意してありますので、ご参照ください。3番目と4番目 (もっと複雑な処理を伴う) の提案も掲出してあります。)

2つの代替案 ー 通知を2種類の受信通知メニューに振り分けるかどうか
#1: 現行の分け方 #2: 緊急かそうでないか
提案の仮仕様を表示
アラート メッセージ アラート 通知
ようこそ トークページヘのメッセージ トークページヘのメッセージ ようこそ
編集の差し戻し 通知-新しい-話題 編集の差し戻し ページへのリンク
ページへのリンク 通知-投稿-返信 言及 感謝
言及 通知-投稿-編集済 利用者権限の変更 通知-感謝
利用者権限の変更 通知-話題-改名済 他の利用者からのメール 通知-新しい-話題
他の利用者からのメール 通知-言及 通知-投稿-編集済 通知-投稿-返信
感謝 通知-言及 通知-話題-改名済
通知-感謝 cx拡張機能-初めて-翻訳
cx拡張機能-初めて-翻訳 cx拡張機能-10回目-翻訳
cx拡張機能-10回目-翻訳 cx拡張機能-100回目-翻訳
cx拡張機能-100回目-翻訳
分析 分析
賛成意見 反対意見 賛成意見 反対意見
緊急性とアクションが必要かどうか (Follow up) はいろいろな形で共存しており、その方法も一定していないため、説明も予測も難しくなります。 分別は恣意的ですが明確であり、利用者の予測にある程度、合致します (バッジが赤色の場合)。 分別は恣意的です。 使い方の様式が異なるとすると、ユーザーの中に個別の項目の設定に反対する人がいそうです。
「警告」には読んだだけでなく手順が必要なものがあり (例:言及)、開封したとたん「既読にする」機能の有効性に疑問があります。 緊急性の要素がトリアージに役立つかもしれません (「これを先に読む」check these first)
「警告」は「緊急」だと解釈されますから、「感謝」その他の項目はその受信通知には不適切と受け取られる可能性があります。
全般的な事項 全般的な事項
こちらのスキームでは、ユーザーがすぐに内容を知りたがるメッセージと、急がなくても良いと受け取られるものの分別に努力しました。 さまざまなチームのメンバーから聞き取りをしたところ、おおまかに緊急性を優先するという合意が得られました。 次の場合のラベルはどうするか。「警告」は緊急性をうまく伝えるという点で、許容できる範囲で適切に作動します。 しかしながら「警告」の大部分は実はメッセージでもあります。(例:編集-利用者-トークページ) 「通知」とは、非難されたようには聞こえなくても、緊急性は低いと暗示するものとして提案します。
このスキームでは、「緊急」バッジに赤色を使うよう推奨されます。 緊急性の低い項目にラベルをつける場合に要注意点があり、グループ (例:翻訳) によって自分たちの活動の重要度を低く見られることを容認しないことです。
緊急性の高い (警告) 項目は多くの場合、手続きが必要 (例:編集-利用者-トークページ)で、自動的に「既読にする」機能は適切とは言えません。