Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021/ja

This page is a translated version of the page Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021 and the translation is 83% complete.

背景

Androidチームでは、Androidアプリ内のユーザーへの情報通知のための各システムの改良を行っています。現在、Androidアプリでは全ての通知およびアラートに対応しています。

しかし、ユーザーがアプリを開いている状態では、通知は簡単には見つかりません。通知をより目立つ形で提示できるようにする計画です。

2021年7月から2021年9月のアップデートで、アプリ内でも通知を見つけやすくし、ロック画面でもより目立つ形で提示できるようにします。2021年12月までに、Androidのシステム要素を念頭に置いた上で、通知ホームセンターに直感的な受信箱およびインターフェースを実装します。

2021年7月から2021年12月にかけては、少なくとも1回の編集をすでに行っているログイン済みユーザーに焦点を当てます。これまでの数ヶ月の予備的な作業を基礎とし、2022年初頭にはログアウト済みユーザーにもアラートをより目立つ形で提示できるようにします。ログアウト済みユーザーにコミュニケーションツールの存在をどのようなオンボーディング体験を通して伝えるとツールを見つけてもらいやすくなるかを探る計画です。この試みと同時に、ログイン済みユーザー向けにも、再リマインドの試みやオンボーディングワークフローの改良を行います。

アプリの通知およびメッセージ提示の方法にさらなる変更を加える前に、アプリ内のどこにどのような機能およびワークフローがあるとユーザーにとって直感的であるかを理解したいと考えています。本プロジェクトページは、初期段階のユーザー調査の結果を収集するためのものです。本調査の参加者の方は、以下のプロトコルへの返答を、このディスカッショントークページ上にコメントするかandroid-support@wikimedia.orgにメールでお寄せください。

調査すべき問い

ユーザーにアプリ内で通知を確認するよう促した時、ユーザーはどこをクリックするか。
提示されている通知の様々なエントリーポイントの発見可能性はどれほどか（どれほど見つけやすいか）を探る。
利用者は、プッシュ通知を無効にしている利用者と比較して、プッシュ通知を有効にするとどのようなフローおよび挙動を期待しているか。
ユーザーは、受信箱をクリックした際と比較して、ベルをクリックした際には何が表示されると期待しているか、およびその代わりに1つの方法のみで通知を行うことのデメリットは何か。
ユーザーは、ユーザートークページの要素が通知センターに含まれるべきであると考えているか。

プロトコル

1）発見可能性：通知を確認するためにWikipediaアプリを開いたとします。新着の通知があることが最も明確にわかるのは、どのバージョンのアプリですか。通知を閲覧したければ画面のどこをタップするかを教えてください。以下のバージョンについて、どれほど通知アイコン/ボタンを見つけやすいかをランク付けしてください。

バージョンA 👇

変種 A = アプリバーに通知ベル（これが現在推奨されているデザインです）

メリット：

ここではアプリ全体にポジション設定を適用できます
他のプラットフォーム（デスクトップ、モバイル）と一貫性があります

デメリット：

検索フィールドが小さくなります
タブおよび通知が誤解を生む可能性があります

変種 B 👇

変種 B = 通知一覧項目をオーバーフローメニューに追加

メリット：

オーバーフローメニューに1つ項目を加えるだけで済みます
ウォッチリスト、ユーザープロフィール、履歴、または通知など、リンクを用いて拡張することもできます

デメリット：

機能が不明瞭な「さらに表示」ボタンをタップしないと通知が得られません（ハンバーガーナビゲーションアイコンと同様の問題）

変種 C 👇

変種 C = 一貫性のあるアプリ内ナビゲーション (記事からツールバーを削除)

メリット：

アプリを通して一貫性のあるナビゲーションなので、ユーザーはどこで機能を探せばいいのか常に把握できます
「さらに表示」メニュー（右上）は、表示内容に関連する項目のみを表示します（例えば、記事の場合はリンク共有、ウォッチリスト追加、トークページ閲覧、編集履歴閲覧など）

デメリット：

記事ビューの「さらに表示」メニューは機能が多すぎて肥大しており、AndroidのChromeのように全てを隠してしまっており、これは良い情報構成と言えるでしょうか。
ユーザビリティーテストに基づいて記事ビューに大幅な改良を行ったので、このアプローチには躊躇しています

2）アイコン：以下の3つのアイコンのそれぞれをタップするとどのような情報が得られると期待しますか。ご自身の考えを教えてください。

変種 A: ベルアイコン 🔔
変種 B: 受信箱アイコン 📥
変種 C: 人アイコン 👤

3）モバイルユーザーにより良いサービスを届けるにあたって、複数の通知タイプを区別することを検討しています。ご自身はどのような通知なら高優先度だとお考えですか。

4）以下の画像では、通知タイプを区別するコンセプトを示しています。「All」には、現状とほとんど同じように、全ての通知が1ヶ所に一覧化されます。「Mentions」には、ユーザートークページ関連の通知、および他のユーザーがご自身のユーザー名をトークページにタグ付けした旨の通知が一覧化されます。WikipediaのAndroidアプリでこのように通知を区別するというコンセプト全般に関してはどうお考えですか。こうすれば、効率的、またはご自身にわかりやすいと感じられる形で、情報が提示されていますか。

5）上のイラストをご覧ください。通知の「All」と「Mentions」のうち、どちらのタブをデフォルトで表示して欲しいですか。さらに、ご自身なら別の基準で通知ホームセンターの通知を分類したいですか。

6）通知ビューにどのような新機能があるとありがたいですか。以下のアイデアを優先度順にランク付けしてください。

A）通知をwikiの言語ごとに素早くフィルタリングする機能（例：スウェーデン語版Wikipedia、韓国語版Wikipedia）
B）通知をプロジェクトごとに素早くフィルタリングする機能（例：Wikipedia、Commons、Wikidata）
C）通知をタイプごとに素早くフィルタリングする機能（例：メンション付きのもののみ表示）
D）通知のグループ化（例：記事編集に「ありがとう」のメッセージを複数受け取った場合はグループ化する）
E）新規およびアーカイブ済みの通知の検索機能
F）通知設定の向上、例えばどの通知を受け取るかを細かく設定する機能（以下の第7問をご覧ください）
G）ウォッチリストの通知
H）左スワイプ/右スワイプの動作のカスタマイズ機能（例：Gmail → 設定 → 全般設定 → スワイプの動作）
I）アーカイブ済みの通知に簡単にアクセスできる機能

7）現在のバージョンのアプリでは、システム、マイルストーン、感謝、リバート、トークページ、ログイン、およびメンションの通知を有効化/無効化できます。現在アプリに足りないと感じる通知設定はありますか

現在の様子は以下の画像でご覧いただけます。

8）現在、ユーザーが通知を受け取った際のフローの最適化を行っています。回り道することなく適切な場所に導くことが目標です。また、通知を受け取った直後にメッセージに簡単に返信できる方法も実装する予定です。以下の画像には様々な通知方法の例が表示されていますが、どれも一貫して返信フィールドがあり、トークページでメッセージを送信してきた、または編集をリバートしたユーザーに直接連絡できるようになっています。このように通知を受け取った後に反応/返信する方法についてどのようにお考えですか。提示された情報だけで返信できると感じますか。それともさらなる情報が必要だと感じますか。

ユーザーがご自身または別のユーザーのトークページにメッセージを残しました。返信フィールドを使えば、通知をタップ後簡単に返信できます。
画面下に返信フィールドがあるので、リバートに関して確実に質問することができます。
通知をタップすると記事のトークトピックに遷移し、素早い返信オプションが表示されます。

9）現在、前述の「Reply」フィールドのタップ後に素早い返信/デフォルト返信が可能なインターフェースを搭載することを計画しています。以下の画像では、素早い返信の開発中のコンセプトをご覧いただけます。絵文字ではなく、一般的な表現、例えば新規利用者を歓迎するために用意している様々なフレーズや管理者がユーザーをブロックするために用意しているよくある理由などを使用することを計画しています。Wiki上でご自身が他の編集者と会話する中で、よく使う返事またはフレーズは何ですか。

10）現在、重要なWikipedia通知がWikipediaアプリの中でも外でも確実にユーザーの目に留まるようにすることに取り組んでいます。通知リマインダー（例：通知が既読になるまでリバートに関して毎週通知リマインダーを受け取らせる）の導入を検討しています。通知リマインダーは、ユーザー設定で設定を変えられます。この搭載候補機能に関してのご感想を選択してください。

A）はい、この機能を搭載して欲しいです。

B）いいえ、この機能は気に入りません。

C）どちらでも構いません。

Results

We received feedback from an English Wikipedia editor, Arabic Wikipedia editor, and Indonesian Wikipedia editor.

1) Variant A is the winner The first question we wanted to understand which icon was better for discoverability. Our Arabic and English users chose A (Bell Icon top right) as their first choice, and our Indonesian user chose A as their second choice. B (top right overflow menu) was the first choice for the Indonesian user, the second for the English Wikipedia editor and the third choice for the Arabic user. C (Bottom navigation) was ranked second, and the last choice for our Indonesian and English Wikipedia user.

2) Bell Icon is the winner

All three users associate the bell icon for notifications. The inbox was understood as a link to messages. The person iconography was associated with a profile, user page or ping.

3) We are going ahead with our assumptions made in T288064, as the consistent notifications that were prioritized by respondents were: mentions, talk page messages, email from other users, edit reverts and user right changes.

4) All respondents were in favor of the idea of having mentions separately and that mentioned they would appreciate some sort of grouping within the 'All' tab

   The idea of separating the notification types on the Android app is a good one. The information is presented in an understandable and efficient way but the other notifications might be jumbled up under 'All'.
  Quotes from respondents:
That's an excellent idea. However, it would be nice to separate some of the notifications into several categories. The 'All' section is still confusing.
   I think separating notifications is a good idea, but having All might bury important notifications inside, like what's happening with FB, even with the iconography used. Mentions might be merged with emails to give more sense

Our thoughts:* Grouping could make it easy to miss notifications, so we will see how filtering addresses the organization challenge

5) Two users prefer mentions first and all secondarily. One user prefer all first. To reduce risk we will have 'All' first and review metrics around people clicking on mentions.

Answers:

   “I would prefer all notifications as the default tab. If I had to organize my notification home center, I would have tabs for each notification type and a button/text to 'view all notifications' which would remove/hide the tabs and just show all the notifications in a list.”
   “I suggest adding the 'Edits' section in the notification. This section contains notifications about edit reverts, page links, thanks, and translation. For the default tab, I prefer mentions because when admins give warnings, users can see them instantly.”
   “I'd like to see Mentions and emails merged under one name and then All. But in the All, I want to be able to distinguish easily the list of notifications, maybe use a slightly different color variation for the background + the icon.”

6) Filtering by type: Ranking (point scale from 1-9)

   D (22 points): Grouping of notifications (e.g. if someone received several “Thanks” for an article edit, should it be grouped) [Grouping by Mentions].
   C (21 points):** Filtering by type [action item for design]
   B (17 points):** Filter by project, task created: T288068
   E (14 points):** Search for new notifications: Yes. Search for archived notifications: No (as technically not ready / out of scope)
   H (13 points):** Customizable swipe left and right gestures~~ (No, since design feedback from experienced Android users advocated for one swipe gesture [Mark as read]
   A (12 points):** Filter by language, task created (T288068)
   F (11 points):** Better preferences, task created (T287477)
   G (11 points):** Notifications for Watchlist (Not now, as technically not ready / out of scope)
   I (11 points):** Easy access to archived notifications. New designs have been improved and it’s easy to access it

7) Page links was the only thing mentioned as missing, and it has been added in the designs (T287477) 8) One user said: More context is needed for edit reverts or article talk. Otherwise people are ok with the suggestion 9) "Thank you". "I'll fix that", "I agree", "Thanks for pointing that out" "Well done" "Very good point, it will be updated" (Task created: T288105) 10) People would like to see notification reminders (V2 option)

Research Questions

   When asking a user to check their notifications, in the app, where do they click?
   What flows and actions do users expect when they have push turned on vs. those that have it turned off?
   What are the expectations of what a user will see if they click a bell vs. an inbox and what are the tradeoffs for consolidation?
   Do users believe elements of the user talk page should be in the notification center?

主なフィードバックオーディエンス

フィードバックは、現在および今後の全てのWikipedia編集者から募集します。

しかし、以下の方々にツールがどのように影響する可能性があるかに関して、とりわけ関心を持っています。

インド在住で視覚障がいがある英語版Wikipediaの編集者
ヒンディー語版Wikipediaの編集者
モロッコ、エジプト、コンゴ民主共和国、およびマリ在住のアラビア語版およびフランス語版Wikipediaの編集者
ナイジェリア在住の英語版Wikipediaの編集者
インドネシア語版Wikipediaの編集者
女性およびノンバイナリーの日本語版Wikipediaの編集者

上記のグループは、WMF製品戦略に従って現在のオーディエンスおよび成長の可能性があるエリアに関してチームが今年これまでに実施した調査に基づいて選択されたものです。