Wikimedia Apps/Team/Android/Communication/UsertestingOctober2021/Feedback

Feedback for user testing. Thanks!

Wugapodes

1. When do you want to communicate with other users on Wikipedia? In what kind of situations? Please choose one or multiple answers below.

(delete ones that don't apply, leaving just the ones you agree with)

a) When undoing (reverting) an edit

b) When improving an article

c) When noticing a helpful edit

d) When patrolling content

e) Reviewing pages on my watchlist

2. Describe how you got to the point of communicating in one or multiple of the situations above.

I usually wind up in the situations above through my watchlist. I tend to use the diff view and from there evaluate whether I want to use article talk or user talk. For helpful edits I tend to go with user talk and a template welcome if they're new, otherwise I use the thanks button. For reverts and substantial work I tend to leave an edit summary pointing them to article talk and then ping them in a post on the article talk page.

3. Besides talk pages, what tools do you use to communicate with other editors in- and outside of Wikipedia? And how do you use these tools?

For article content I use talk pages almost exclusively. Email I use for discussions that are more private in nature, and for discussions that don't have a private component I tend to point them to my talk page. I use IRC for tasks that need real-time communication like deployments or code review and it's pretty restricted to my MediaWiki work. I use Discord mostly for socializing or answering the occasional question.

4. Should user and article talk pages work and look the same or differently? Why?

User talk page in the current version of the Wikipedia for Android app
Article talk page in the current version of the Wikipedia for Android app

I'm confused by the question; same or different from each other? Unified but different or same in the future? I think content talk pages should be different from project talk pages since the use cases are ime different. On article talk the level two headers tend to actually be subject lines and independently useful. This is often the case for project talk but editors are a lot more fluid in how they use them. Often the headings aren't helpful, and content may not be organized in a consistent (or even coherent) way. I also think the current design shouldn't be retained for either. I think Article talk is closer to the goal, but headers can get long and I don't find the organization of them visually appealing.

5. Which of the three variants do you prefer to go to an article talk page?

Variant A
Variant B
Variant C

Variant C

6. Why do you prefer the variant you chose to go to the article talk page? Please describe.

Variant A makes it seem more like a comments section than an editorial forum. Variant B hides it and makes it hard to find. Variant C makes it prominent but without styling it in a way that makes it seem like a comment section on a news article.

7. Which of the three variants do you prefer to view an article talk page?

Variant A: Right sheet
Variant B: Bottom sheet
Variant C: A separate screen

(your feedback here)

Variant B

8. Why do you prefer the variant you chose to view an article talk page? Please describe.

Variant A is not visually balanced. Variant C takes the curious reader too far away from the content. Variant B is visually appealing and gives the reader a heads up about what's on the talk page without taking them away from the page they actually wanted to read. Strikes a good balance between useful for editors and useful for curious readers.

9. Which of the three variants do you prefer to go to your user talk page in the app?

Variant A
Variant B
Variant C

Variant B (N.B. this was really hard to tell the difference in)

10. Which of the two variants below do you prefer to search for other users on Wikipedia?

Variant A: Searching users via the main search field of the app. Users can be searched by typing a User: prefix before the username.

Navigating to the search input field in the Explore feed
Search for other users by typing the prefix 'User:' followed by the username

Variant B: Searching users via a special field to find users in a new Wikipedia community area of the app. In the screens below, we call the new area in the app “Community”. Users can be searched by directly typing the username.

The user search field in a possible community area in the app
Typing the username without a 'User:' prefix

Variant B

11. Imagine one of your recent contributions on Wikipedia was undone, because it contained information from an unreliable source. The user who undid the edit also left a message on your user talk page. You get a notification about the revert and the message on your talk page. You tap the revert notification and find yourself on the diff view, which displays differences between article edits. Which of the three variants do you prefer in the described scenario?

Variant A: Diff view of the revert
Variant B: Diff view with info about the new talk page message
Variant C: Diff view with info about the new talk page message and direct reply functionality

Variant C

12. We are currently thinking about adopting reply functionality that has been introduced on Desktop Wikipedia . How do you feel about the reply functionality on Desktop? Is there other functionality you would like to see on article and user talk pages for the Android app?

I haven't used it because I'm fine with my current workflow, but I think the direction is amazing. It's a great way to get new editors involved without having to adopt my esoteric and programmer-centric workflow, I think bringing it to mobile is a great idea. In that situation I could actually see myself preferring it.

13. Please watch this prototype video of suggested responses when replying to other users on a talk page and answer the following questions:

a) Please tell us about your first impression.

That's super cool! I think experienced editors will love that feature as it's like personalized templates without the actual hassle of templates.

b) What other functionality you would like to see here?

I think it would be a good idea to let communities set defaults through a MediaWiki: config page. Similarly, I think it would be cool if (like templates) there was a way to import default messages through a user config page or template or something. For example, EnWiki already has a system of standard reply templates for various noticeboards and things like new page patrol. If coordinators could extend those existing reply sets so that they can be imported, I think it would help with uptake of the feature.

c) What common phrases do use when communicating and which ones would like to see pre-populated?

"If you have any questions, feel free to leave a message on my talk page" is one I usually sign off with when talking to a newbie. I also use "You can notify me using {{ping|Wugapodes}} ~~~~ when the editor might not know how Echo works.

14. We are curious about what other communication functionality you would like to see in the Wikipedia for Android app. Please rank the following feature ideas by your personal priority:

Onboarding to talk pages for newcomers: Educate and guidance to new users about “What are talk pages?” What are talk pages used for?” or “Where do I find talk pages?”
Visual editing and no code on Mobile: More intuitive usage of talk pages, e.g. by featuring inline replies, e.g. contextual/custom Wiki keyboards for better ergonomics, improved handling of typing in multiple languages
Archiving of sections, e.g. allow users to close sections
Voice input: a more voice input driven approach to communicate on Wikipedia, e.g. listen to messages, create audio messages via dictation, voice calls with other users or better speech recognition to better support typing with voice.
Chat rooms: A space to meet and interact with other Wikipedia users in your area or grouped by interest. Here is some inspiration from other services:
Private messaging: Send private messages to other users directly on Wikipedia, e.g. with a non-public direct messaging system. Here is some inspiration from other services:

15. Can you tell us more about why you made the choices in the previous question?

Onboarding is important especially to make clear that they are not comment sections, but also orient those who want to do more than just poke around. I think that' smost important to prevent negative effects and bring about positive ones.
I think visual editing is important for editor recruitment but I would like to see source editing retained as a fall-back. This is most effective when readers actually know what talk pages are and how to use them.
Archiving of sections is useful for experienced editors but it should be gated behind a permission that can be assigned to various groups (probably autoconfirmed by default). Not very useful for newbies.
I don't use voice input, but it might be useful.
I find this scary. I can imagine it being fine, but introducing real time communication on mobile and not more generally is going to be a very hard sell and might make communication issues worse.
I think this is a bad idea. We shouldn't duplicate email, we shouldn't take on the storage of non-public communications, and we shouldn't open up a new vector for hounding.

16. Do you have other feature ideas related to communication for the Android app?

Nope.

17. Thanks for participating, we appreciate it! Please use this space here to provide any further comments.

Thanks for all this! It's looking good and I'm excited for the results. Wugapodes (talk) 23:29, 25 October 2021 (UTC)[reply]