Phát triển/Tập trung vào bàn giúp đỡ

Dự án Quỹ Wikimedia Focus on help desk Make it easy for new editors to ask questions Nhóm: Growth Khởi đầu: 2018-10-01 Thành viên nhóm: Stephane Bisson (software engineer), Benoît Evellin (community relations specialist), Elena Tonkovidova (QA engineer), Kosta Harlan (software engineer), Morten Warncke-Wang (data analyst), Rita Ho (senior user experience designer) Công việc tồn đọng: #T206711 Trưởng nhóm: Roan Kattouw Quản lý: Ryan Kaldari (engineering), Marshall Miller (product), Jazmin Tanner (program) Cập nhật: Most updates posted here.

Trang này mô tả công việc của nhóm Phát triển trong dự án "trang chủ người mới", đây là một dự án cụ thể theo sáng kiến "ngày đầu tiên được cá nhân hóa". Trang này chứa các tài sản, thiết kế và quyết định chính. Hầu hết các cập nhật gia tăng về tiến trình sẽ được đăng trên Trang cập nhật nhóm Phát triển, với một số cập nhật lớn hoặc chi tiết được đăng ở đây. Most incremental updates on progress will be posted on the general Growth team updates page, with some large or detailed updates posted here.

Tính đến Tháng 9 năm 2019, chúng tôi đã hoàn thành việc phân tích các thí nghiệm cho thấy bảng trợ giúp không ảnh hưởng đến việc kích hoạt hoặc ở lại của người mới. Vì vậy, chúng tôi sẽ không tiếp tục làm việc với tính năng đó nữa, và thay vào đó là với các tính năng trang nhà người mới và nhiệm vụ người mới đầy hứa hẹn. Hãy xem chi tiết kết quả thí nghiệm tại đây.

• 2019-09-30: thí nghiệm bảng trợ giúp đã kết thúc và kết quả.
• 2019-07-22: bảng trợ giúp được triển khai tại Wikipedia tiếng Ả Rập trong một thử nghiệm A/B, với một nửa số người mới không nhận được nó.
• 2019-03-26: Báo cáo ban đầu với các chỉ số dẫn đầu .
• 2019-03-04: bảng trợ giúp được hiển thị trong ngữ cảnh đọc trong Trợ giúp, Thảo luận trợ giúp, Wikipedia, Thảo luận Wikipedia, Không gian Thành viên và Thảo luận thành viên.
• 2019-02-28: bảng trợ giúp được triển khai tại Wikipedias tiếng Việt trong thử nghiệm A/B, với một nửa số người mới không nhận được nó.
• 2019-02-14: khả năng tìm kiếm được triển khai cho các nhóm điều trị tại Wikipedia tiếng Séc và Hàn Quốc.
• 2019-01-11: bảng trợ giúp được triển khai tại Wikipedia tiếng Séc và Hàn Quốc trong thử nghiệm A/B, với một nửa số người mới không nhận được bảng trợ giúp. Để xem câu hỏi từ bảng trợ giúp trong các wiki đó, hãy xem bàn trợ giúp của họ:
  • Bàn trợ giúp của Séc
  • Bàn trợ giúp tiếng Hàn
• Tiếp theo: chúng tôi đang nghiên cứu các tính năng gia tăng để khuyến khích người dùng đặt câu hỏi, cải thiện kết quả tìm kiếm của họ và để tăng khả năng họ đọc phản hồi của bộ phận trợ giúp.

• Bảng trợ giúp lần đầu được triển khai đến người dùng mới vào tháng 01 năm 2019, và tính đến tháng 9 năm 2019, chúng tôi đã xong việc phân tích dữ liệu để xác định sức ảnh hưởng của nó. Đây là một tóm tắt ngắn gọn, và sắp tới sẽ có một bản phân tích chuyên sâu hơn.
• Tóm lại thì bảng trợ giúp "chưa" cho thấy một sự tăng nào trong việc kích hoạt (tức người dùng tạo sửa đổi đầu tiên) hay ở lại (tức người dùng quay lại để sửa đổi thêm). Tuy kết quả này là đáng thất vọng nhưng nhóm chúng tôi có một số các tính năng đầy hứa hẹn khác mà chúng tôi muốn tiếp tục thí nghiệm.
• Bảng trợ giúp "có" tạo ra một sự thay đổi nhẹ trong số lượng sửa đổi được tạo ra, nhưng kết quả thì khá gây tranh cãi. Nó làm tăng lượng sửa đổi trong ngày đầu tiên của người mới, nhưng lại giảm trong hai tuần tiếp theo.
• Nhìn chung, hiện tại chúng tôi không biết lý do tại sao bảng trợ giúp lại cho ra những kết quả như vậy, và chúng tôi có nhiều giả thuyết mà chúng tôi sẽ tiếp tục suy nghĩ thêm. Ví dụ, trong khi chúng tôi hy vọng rằng bảng trợ giúp sẽ khuyến khích người dùng mới tạo sửa đổi đầu tiên bằng cách cung cấp cho họ thông tin về cách thực hiện nó, cũng có thể bảng trợ giúp lại "làm nhụt chí" sửa đổi của một số người dùng mới bởi vì nó cho họ thấy nhiều các văn bản phức tạp có thể nhàm chán hoặc đáng sợ.
• Mặc dù tăng việc kích hoạt và ở lại là mục tiêu tối hậu của nhóm nhưng chúng tôi cũng quan sát thấy rằng một lượng lớn người mới mở bảng trợ giúp (20%) và tương tác với nó sau khi mở ra (50%). Việc này cho chúng tôi biết được rằng mọi người có nhu cầu cho kiểu giúp đỡ mà bảng trợ giúp cung cấp.
• Khi suy xét tất cả thì những kết quả này thật đáng thất vọng -- chúng tôi chắc chắn là hy vọng bảng trợ giúp có một tác động tích cực lên các con số. Tuy chúng tôi có nhiều ý tưởng để cải thiện bảng trợ giúp nhưng chúng tôi đã quyết định không lặp lại và phát triển bảng trợ giúp trong thời gian gần nữa, và thay vào đó tập trung vào trang nhà người mới và nhiệm vụ người mới. Những dự án này có những kết quả ban đầu đầy hứa hẹn và đã tới được với nhiều người mới hơn so với bảng trợ giúp. Bảng trợ giúp cũng sẽ được sử dụng như là một phần của dự án nhiệm vụ người mới, và sẽ tiếp tục là một phần của trải nghiệm người mới mà nhóm Tăng trưởng đang xây dựng. Chúng tôi có thể sẽ quay lại với nó sau trong tương lai.

Thông thường các biên tập viên mới phải đối mặt với những thách thức về kỹ thuật, khái niệm và văn hóa khi họ bắt đầu chỉnh sửa. Họ có những câu hỏi cụ thể và có thể hưởng lợi từ một biên tập viên người trả lời câu hỏi của họ. Hầu hết các wiki đều có bàn trợ giúp nơi các biên tập viên mới có thể đặt câu hỏi và những địa điểm như vậy đã được chứng minh là có hiệu quả, đặc biệt là Phòng trà trong Wikipedia tiếng Anh (xem tờ giấy này để phân tích tác động). Vấn đề là hầu hết các biên tập viên mới không biết hoặc tìm bàn trợ giúp - mặc dù họ thường xuyên nhận được "mẫu chào mừng" trên các trang thảo luận có liên kết.

Chúng tôi có hai giả thuyết:

• Những người mới đến có nhiều khả năng tìm kiếm sự giúp đỡ khi được trình bày một cách dễ dàng để gửi câu hỏi.
• Những người mới đến có nhiều khả năng hoàn thành các chỉnh sửa bằng cách biết nơi để tìm kiếm sự giúp đỡ.

Do đó, dự án "Tập trung vào bàn trợ giúp" có hai phần:

1. Mời các biên tập viên mới đến bàn trợ giúp. Chúng tôi có bốn ý tưởng về cách mời họ: bằng cách đăng lên trang thảo luận của họ, bằng cách sử dụng biểu ngữ, qua email hoặc bằng cách thêm một liên kết trong ngữ cảnh chỉnh sửa. Chúng tôi đã quyết định mời các biên tập viên mới vào bàn trợ giúp bằng cách thêm một liên kết rõ ràng và rõ ràng đến bàn trợ giúp bên trong trải nghiệm chỉnh sửa của họ, chúng tôi gọi đó là "bảng trợ giúp". Đó là vì những lý do sau:
   • Chúng tôi biết từ nghiên cứu Kinh nghiệm của Biên tập viên Mới rằng việc nhận trợ giúp trong ngữ cảnh rất quan trọng. Điều này sẽ cung cấp một liên kết để nhận trợ giúp vào lúc này khi người dùng cần nó và ở một nơi hiện không có cách nào rõ ràng để nhận trợ giúp.
   • Chúng tôi có các câu hỏi mở xung quanh ý tưởng "Câu hỏi trong ngữ cảnh hoặc trò chuyện" và điều này sẽ giúp chúng tôi tìm hiểu xem có nhu cầu về tính năng như vậy không.
2. Khi chúng tôi thành công trong việc đưa các biên tập viên mới đến bàn trợ giúp, hãy thực hiện các cải tiến cho chính bàn trợ giúp để biến nơi này thành một nơi tốt hơn để đặt câu hỏi. Điều này có thể bao gồm liệt kê các câu hỏi mới ở đầu trang hoặc thông báo cho các biên tập viên mới khi câu hỏi của họ đã được trả lời.

Nhóm Tăng trưởng đã xây dựng Phần 1 (bảng trợ giúp) đầu tiên trong quý 2 năm 2018 (tháng 10 năm 2018 - tháng 12 năm 2018) và triển khai nó tại Wikipedia tiếng Séc và Hàn Quốc vào ngày 11 tháng 1 năm 2019 trong thử nghiệm A/B có kiểm soát. Thử nghiệm này sẽ mất đến tháng 7 năm 2019 để hoàn thành đầy đủ. Khi có kết quả, chúng tôi có thể thêm các khả năng bổ sung cho tính năng, triển khai nó trong các wiki bổ sung hoặc quyết định bắt đầu Phần 2 (thực hiện các cải tiến cho chính bàn trợ giúp).

Designer của nhóm đã xem lại cách mà các nền tảng khác (như SurveyMonkey, American Express, Codecademy) cung cấp hướng dẫn in-context cho người dùng của họ (chi tiết xem T206713). Chúng tôi nghĩ rằng tốt nhất chúng tôi nên học hỏi từ thực tiễn từ các phần mềm khác, đặc biệt là khi xem xét cùng một khuôn mẫu xuyên suốt nhiều loại phần mềm khác nhau. Kể cả khi chúng tôi học tập ý tưởng từ các phần mềm khác thì chúng tôi vẫn bảo đảm gìn giữ các giá trị độc đáo của Wikipedia như tính mở, trung lập và rõ ràng. Có thể xem bảng so sánh tại slide này, và những điểm chính bao gồm:

UI trợ giúp trong bối cảnh

• Trợ giúp trong bối cảnh thường được thể hiện là một nút hoặc tab dính ở góc dưới cùng bên phải màn hình
• Click vào trợ giúp thường sẽ mở ra một bảng dính trên UI cung cấp một hoặc nhiều lựa chọn trợ giúp
• Người dùng thường có thể tìm kiếm và xem các chủ đề trợ giúp hàng đều bên trong bảng trợ giúp trong bối cảnh
• Trợ giúp trong bối cảnh cũng liên kết người dùng đến trung tâm/diễn đàn trợ giúp chính/chuyên dụng
• Trợ giúp chung/toàn trang cũng thường là lựa chọn định hướng chính, và cũng có thể cho phép tiếp cận việc chat/phản hồi bên trong UI
• Chỉ dẫn riêng tư và bảo mật cũng thường được trình bày trong UI trợ giúp mở rộng
• Phiên bản điện thoại di động (app/web) thường không có trợ giúp tiếp cận được trong bối cảnh mà phải đi đến nó thông qua một mục điều hướng chính phải mở riêng

Các loại trợ giúp được cung cấp trong bối cảnh

• Liên kết tới một Trung tâm Trợ giúp / Bàn Trợ giúp
• Top FAQ được liên kê cho bối cảnh cụ thể đó
• Live chat
• Video/Tutorial
• Liên kết tour hướng dẫn
• Lịch sử các câu hỏi trợ giúp trước đó
• Diễn đàn cộng đồng - được sử dụng ở một số nơi mà mọi người ít có kỳ vọng về sự ngay lập tức trong thời gian trả lời và mức độ 'dịch vụ'
• "Report a bug" - cho người dùng gửi phản hồi về các hành vi/bọ không ngờ tới, thường có thêm lựa chọn đính kèm ảnh chụp màn hình của UI. Kỳ vọng ngầm rằng người dùng sẽ không mong có câu trả lời.

Các tính năng Chat/Q&A trong trợ giúp

• Người dùng có thể email câu hỏi sử dụng bảng chat khi không có sẵn người "live"
• Người dùng được cung cấp phản hồi về cửa sổ thời gian trả lời và nơi họ có thể tìm câu trả lời
• Giọng nói và văn phong chat thì thân thiện và dễ gần, đôi khi sử dụng emoji và gif khi chat.
• Người dùng có thể kỳ vọng một mức độ dịch vụ, vì chat thường được cung cấp bởi một đại diện dịch vụ khách hàng được trả lương.
• Liên kết riêng tư và thông tin về việc lịch sử chat được quản lý như thế nào được trình bày rõ ràng
• Câu hỏi/chủ đề thường được hỏi phổ biến cho bối cảnh cụ thể thì thường được trình bày trong cùng một UI như là một biện pháp thay thế trợ giúp cần người tham gia ít hơn cho người dùng
• Trả lời tự động/ "Bot trả lời" đôi lúc được sử dụng trước để cố gắng giải quyết v���n đề trước khi người dùng được cung cấp lựa chọn đăng câu hỏi của họ

Khi chúng tôi thảo luận về các ý tưởng cho bảng trợ giúp, một số nhân viên WMF đã nhắc nhở chúng tôi rằng hai tính năng nghe tương tự đã được phát triển trong quá khứ: MoodBar và Phản hồi bài viết. Cả hai tính năng này (tuy giờ không được sử dụng nữa) đều cung cấp cho người dùng các công cụ trong bối cảnh để cung cấp thông tin, và vì vậy chúng tôi nghĩ rằng chúng tôi có thể học hỏi từ họ. Chi tiết của công việc này ở tại T206714, và các ý chính bao gồm:

Công cụ phản hồi bài viết

• Potential for account creation and editor activation - anonymous users who start an edit may be prompted to create an account when asking for help so that they can get feedback from the “Help team”.
• Provide more upfront help options prior to allowing submission of free-text comments and questions - Per findings from the Article Feedback Tool, making it too easy to submit unstructured and out-of-context comments about articles leads to a high degree of noise for moderators. Whilst our hypothesis is that users who are in the editing context and seeking help for a specific task may be less likely to submit un-useful questions, providing more self-directed help alternatives upfront may further reduce volume.
• Mechanisms to provide context to comments – The lack of context to comments in AFT was a main point of dissatisfaction for editors. For in-context help, it would be ideal if users submitting a question or comment would be able to denote where in the article or UI they would like assistance – for example being able to submit a screenshot along with their question, or being able to highlight the section related to their comment.
• Making interactions into actual edits - This tool created a separate queue of work for experienced editors to deal with, that they couldn't manage through their Watchlists or RecentChanges, and current curate with existing processes for removing damaging content. It is important that any additional traffic we create can be managed through existing systems, which is done most easily if interactions with our feature are done as posts on wiki pages.

MoodBar

• Capturing email for responses is an effective option – As shown in the MoodBar experiment, email notifications is an effective means of engaging new editors.
• Clear, prominent call to action for new editors to ask for feedback/help - per high level findings, the addition of a tooltip drawing attention to the MoodBar significantly increased its use.
• Tracking the perceived helpfulness of responses is important - It would be useful for us to track similar new user perceptions of feedback, since a poor experience from receiving unhelpful advice has been shown to negatively impact editing.

Our evolving designs can always be found in this interactive prototype. These clickable mockups also contain other design ideas for future iterations of the help panel, although some elements in those mockups may be obsolete. To see the latest version of the help panel, edit a page in Beta or Test wiki after having turned the help panel on in your preferences.

The "Comparative review" and "Review of similar MediaWiki features" were critical in the design process because they helped us "dream big" to explore the space of what the help panel could eventually become. Our team mocked up and discussed many ideas that probably will not become part of the help panel unless we see that earlier, simpler versions are successful. First, we are going to work on an initial version of the help panel to be deployed in January 2019.

In the initial version of the help panel, we want to answer these questions:

• Will newcomers click on a clear option to get help during the editing experience?
• Do newcomers seem more interested in reading content to answer their own questions, or in asking a question for others to answer?
• Will newcomers take action to write and post a question to the help desk?
• Will the presence of the help panel increase new editor retention?

Therefore, we have decided to include these elements in the initial version, detailed in T206717 and T209318:

• A call to action in the editing context.
• A panel that opens containing links to helpful existing pages.
• The ability to ask a question from that panel, and for that question to be automatically posted to the wiki's help desk.
• The ability to add an email address to their account if the user does not already have one, and to modify their email address if it is not yet confirmed (and then to receive a confirmation email upon submitting).
• The ability to turn off the help panel by clicking through to Preferences.

The mockups below show initial designs for that functionality as of November 2018 (to see the most up-to-date designs, use this interactive prototype). Right now, we will show this only to newcomers (meaning new account holders who are not auto-created). We also know that the wording in the feature is very important here, because it is critical that newcomers understand where and how information they write will be posted, and when and where they can except a reply. These mockups only contain some initial drafting of the wording, and we'll continue to refine it. We are hoping for strong ideas from community members, so please post any ideas on the talk page.

• 
  1) Mockup of initial call-to-action on desktop and mobile
• 
  2) Mockup of help pane initial state on desktop and mobile
• 
  3) Mockup of asking a question in help pane
• 
  4) Mockup of confirmation received after asking a question
• 
  5) Mockup of a question having been automatically posted to a help desk

Below are the current rules we're using to determine who receives the help panel and how it works. These may change as our team and the community continues to discuss and learn from the feature.

• Users: the help panel will be a feature that can be turned on and off in user preferences. When it is deployed in January, it will be turned on to only newly created accounts (not auto-created) from the deployment date forward (except for a control group that will not have the feature). All other users whose accounts were created before the deployment date will have the feature turned off, but will be able to go to their preferences to turn it on if they wish to try it out. We will also be embedding an option to turn the help panel off inside the feature. Our team discussed the possibility of turning the help panel on for all users, but wanted to first learn about how new users interact with it, and we want to make sure not to flood help desks with incoming questions. See this Phabricator task for the discussion.
• Namespaces: the help panel will be available in all namespaces. Our team discussed limiting the feature to only the main article namespace because the help documentation linked in the panel is mostly relevant to that namespace. Ultimately, we decided to make it available in all namespaces so that we can learn in which namespaces people are most commonly looking for help -- we know that new editors struggle to edit the Talk namespace. We will also encourage communities to develop documentation relevant to editing other namespaces (particularly the Talk namespace) so that we can make those links available in the appropriate namespaces. See this Phabricator task for the discussion.
• Headers: the help panel will automatically post users' questions to their wiki's help desk, and will automatically generate a header for that post. We have decided that the header will include the title of the page from which the question originates (with a link), as well as a timestamp to distinguish it from questions that may have originated from that some page. Users will be able to decline to include the title in their header, if they consider it sensitive. See this Phabricator task for the discussion. Our preference is to number the posts instead of including a long and redundant timestamp, but that will require additional engineering work for a future version.

The wording for the help panel is complete, and the current state can be seen in the interactive mockups. Some of the most important things we have been considering in the wording are:

• How to make it clear that by asking a question in the help panel, users will be posting in public?
• How to encourage users to add their email address, since that is the best way for them to find out when they get a response to their question?
• How to give users the option of excluding the title of the page they're editing from the automatically-generated header in the help desk, if they want to keep that private?
• How to correctly set expectations about how quickly a user can expect a help desk response?
• What to include in the automatically-generated header in the help desk?

In determining the initial version of the help panel, many ideas for features were set aside to be evaluated later on. Many of them are visible in the initial mockups here. The following is a list of capabilities that are either being built for the help panel, or may be built in the future:

• Nearer term
  •  - Search: the ability to search help pages. Users found this option appealing during testing, and it was built in T209301 and deployed on 2019-02-14.

    

  •  - More contexts: since help desks have not yet been overwhelmed with incoming questions, we are thinking of exposing the help panel to newcomers in contexts beyond editing -- perhaps while they are viewing pages in the Help or Wikipedia namespaces. We thought of this because the EditorJourney analysis showed that large portions of newcomers viewed pages in those namespaces during their first 24 hours. Currently being built in T215664.
  • Greater affordance: so far, it looks like a minority of users who see the help panel button actually open it up. We could attempt to make it more visually obvious that it is a recommended place to start.
  • - Vary links with context: the help panel contains five links to help pages, and about half of users that see them click on one. Different links are probably valuable in different contexts. For instance, there might be some links for visual editor and some for wikitext. Or some that are helpful on a talk page and some on an article page. This is being worked on in T211117.
• Longer term
  • Live chat: allowing newcomers to immediately chat with experienced editors right from the help panel. This would be a major project with many challenges. See this page for our notes so far.
  • Suggested answers: many questions that users asked may have already been answered before, and we might be able to provide suggested answers as users type. This would be relevant once many more questions have been asked. Ticketed in T209327.
  • Feedback on responses: newcomers may find the responses to their questions more or less satisfactory. By allowing newcomers to rate their responses, we may increase higher quality responses, and make it possible to surface the best ones to future newcomers. Ticketed in T209332.
  • Marking question context: newcomers may have questions related to very specific elements of the editing experience. This idea would allow them to indicate exactly where on the page their issue is occurring. Ticketed in T209328.
  • Templated replies: research shows us that the tone of a reply to a newcomer can make a difference in whether they edit again. We may be able to help people answering questions to format their replies in a nurturing way. Ticketed in T209331.
  • Anonymous editors: though our team is focused on registered newcomers, it is possible to make the help panel present for anonymous editors, though it will be more difficult for them to find out that they have received a response. Ticketed in T209325.

During the week of November 26, 2018, we used usertesting.com to conduct eight tests of the help panel interactive prototype with internet users unaffiliated with the Wikimedia movement. Four tests were done on desktop and four were done on mobile. In these tests, respondents are compensated for trying out the mockups, speaking aloud on what they observe, and answering questions about the experience. As our team's designer described on the Phabricator task, the goals of this testing were:

1. Gauge the discoverability of the help pane call to action and help pane
2. Identify improvements to the usability of the help pane:
   • Do users understand they can edit and use help links at the same time?
   • Are users able to successfully follow the steps to post a question?
   • Is there anything users that would like to be able to do from the help pane that they are missing?
3. Gauge user reactions to the help pane and expectations of how their questions will be answered.

Summary of findings

• All users found the help panel contents to be very useful in getting help for editing.
• No one had issues with having the article title included in the question.
• Most participants would post a question to the help desk as a last resort after trying to help themselves through clicking on links, with two people saying they would likely not post at all as they would want a more immediate response.
• One user said they would more likely just Google the editing help over the options shown.
• Whilst it was understood that the Help desk would be answered by volunteers, many participants wanted more reiteration and clarity of expected wait times.
• Clear layout of options, shown in the order in which almost participants said they would seek for help.
• Discoverability of the help panel call-to-action may be reduced in the case when the user is using the Visual Editor or wikitext2017 editor because those editors have a competing “?” icon.
• One user suggested having an example question in hint text.
• One user wanted more information shown about when their question was viewed and by how many people.
• Two users mentioned the help recommendations shown on the Help Desk seemed disjointed from what was shown in the help panel.

Recommendations (not all of these will be implemented)

• Prioritize the Searching help task inside the help panel.
• Provide clearer times on both the review and confirmation screens for when a newcomer should expect a response from the help desk.
• Add a more specific help question sample in the placeholder/hint text.
• Experiment or A/B test alternative text on the initial “Ask a question” call-to-action.
• Show a first-run tooltip/pulse indicator to highlight the new help panel.
• Add an additional menu item to existing editing toolbar help on Desktop VE or Wikitext2017 which opens the help panel.

High-level questions

These are the main things we want to find out from the help panel.

1. Does the presence of the help panel lead to questions being asked and answered?
2. Does the presence of the help panel increase editor activation (making their first edit)?
3. Does the presence of the help panel increase editor retention (coming back to edit again)?
4. Does the presence of the help panel increase the proportion of constructive edits?

Controlled experiments

See this page for the detailed experiment plan.

In order to understand the help panel’s impact on editor activation and retention, we propose a six month A/B test. During that test, 50% of new registrations on target wikis will have the help panel enabled by default, and 50% will have it disabled. We anticipate that we will be able to detect 10% changes in activation after about one month, and 10% changes in retention after about six months. We are likely to be running other experiments on the target wikis at the same time, for example, testing variants of our welcome survey. Therefore, assignment of users to treatment and control groups for all tests will have to be coordinated so that we ensure the distributions are not biased.

Specific measurements: quantitative

These are specific measurements that help us answer the high-level questions. These are measurements we will be able to do programmatically. See this EventLogging schema for the exact details on the data that is being recorded and stored.

1. What is the context the user is in when they start interacting with the help panel?
2. What percent of users open the help panel?
3. What percent close the help panel without using any part of it?
4. What percent click one or more of the help links?
5. How far do users go in the workflow of asking a question?
6. What percent of users turn the help panel off?
7. What is the average length of questions asked via the help panel?
8. What percent of users click any of the links in the final confirmation page of asking a question?
9. What percent of users who post a question return to view the answer?
10. Does interacting with the help panel alter the probability of abandoning an edit session?
11. What percent of users use the help panel more than once?
12. Are newly registered users with an email address likely to return to view the answer to their question?
13. What percent of newcomers that had no email address add one when asking a question?
14. What percent of newcomers confirm their email address (within 48 hours) after asking a question?
15. What percent of newcomers ask a question without an email address?
16. What percent of newcomers submit a question without including the title of the page they were editing?
17. How does help panel usage vary with welcome survey responses?

Specific measurements: qualitative

These are specific measurements that help us answer the high-level questions. These are measurements we will need to do manually, by counting and reading the contents of help desks.  Doing these programmatically would be an inordinate amount of work.

1. What percent of questions get answered?
2. How quickly do questions get answered?
3. How often do newcomers edit the question they asked?
4. What kind of questions do people ask and which ones are more likely to get answered?

After about two months of being deployed to half of new accounts in Czech and Korean Wikipedias, and two weeks of being deployed to half of new accounts in Vietnamese Wikipedia, these are the numbers (as of 2019-03-28):

• 3,343 users have seen the help panel button
• 566 users have opened up the panel
• 225 users have clicked a link in the panel
• 51 have run searches
• 51 users have submitted a question to the help desk (Czech: 34, Korean: 8, Vietnamese: 9)

The help panel's experiment plan defines a set of leading indicators that the team evaluates in order to determine whether the feature is behaving as expected, and whether there are any urgent problems that need to be solved.

Using a month of data, we published an initial evaluation of leading indicators here. In summary, the help panel seems to be behaving in a healthy way, with good numbers of newcomers opening and using it. The analysis identified a couple areas for improvement that the team has taken action on:

• Because we wanted to increase the number of newcomers who open the panel, we started showing it in additional contexts on March 4, 2019. Newcomers now see the help panel when reading in the Wikipedia, Help, and User namespaces.
• Because we saw that in Korean Wikipedia very few users ask questions, we built the search feature so that newcomers would have an easier way to find helpful information on their own.

See results above.

• More on this feature: The help panel contains a link to learn "More about this feature". That link will lead to this page, which will hopefully answer user questions about how the feature works. Feel free to translate it into your language!
• Best practices: Because many communities don't have a lot of experience concerning help desks, the WMF Community Relations Team has assembled on a page with some best practices that can help communities have more successful collaborations with newcomers. Please feel free to translate that page into your language!