Growth/Personalized first day/Structured tasks/tr

Bu sayfada, Büyüme ekibinin "yeni gelen görevler" ve "yeni gelen anasayfa ile ilgili olan "yapılandırılmış görevler" projesi üzerindeki çalışmaları açıklanmaktadır. Bu sayfada önemli varlıklar, tasarımlar, açık sorular ve kararlar bulunmaktadır. İlerlemedeki en artımlı güncellemeler, genel olarak Büyüme ekibi güncellemeleri sayfasında yayımlanacak ve burada bazı büyük veya ayrıntılı güncellemeler yayımlanacaktır.

Mevcut durum

 * 2020-05-01: ilk notları planlama ve belgeleme
 * 2020-05-17: topluluk tartışmasına başlayın
 * 2020-05-29: ilk tel kafesler
 * 2020-08-24: planlama toplantıları haftası
 * 2020-09-08: en son tasarımlarla ilgili topluluk tartışması için çağrı
 * 2020-10-21: masaüstü tasarımlarının kullanıcı testi

Özet
Büyüme ekibi Kasım 2019'da "yeni gelen görevler" projesini devreye soktu, bu da yeni gelenlere yeni gelen ana sayfasında düzenlemeleri için önerilen maddelerin bir beslemesini veriyor. Nisan 2020 itibariyle, önerilen maddeler yalnızca deneyimli editörler tarafından uygulanan bakım şablonları içeren ve yeni gelenlere hangi cümlelerin, kelimelerin veya bölümlerin özellikle dikkat etmesi gereken belirli bir yön vermeyen maddelerden elde edilmektedir. Bu yönelim eksikliğine rağmen, yeni gelenlerin verimli önerilen düzenlemeler yapılmasından mutluyuz.

Bakım şablonları, yeni gelenler için çeşitli düzenleme türleri sunsa da, yeni gelenlerin başarılı olması için çok geniş ve açık uçlu olabilir. Mobil cihazlarda, görsel veya vikimetin editörleri yeni ekranda yeni gelenleri bunaltabilir.

Bu nedenle, "yapılandırılmış görevler" adlı bir fikri denemek istiyoruz. Bu düzenleme iş akışlarını yeni gelenlerin kolayca başarabileceği bir dizi adıma ayırmakla ilgilidir. Android ve Dil ekibi çalışmalarından elde edilen başarılı örnekleri takiben, bu tür düzenlemelerin yeni gelenlerin mobil cihazlarda daha kolay ve daha kolay olacağını ve daha fazla yeni kullanıcının daha fazla düzenleme yapmasına yardımcı olacağını düşünüyoruz. Bu yapılandırılmış görevlere, yeni gelen görevler projesinin bir parçası olarak yeni gelenler erişebilir.

Düzenleme karmaşık
Büyüme ekibinin deneyimi sayesinde, yeni gelen bir kişinin vikideki ilk anlarının kalmak ya da ayrılmak isteyip istemediklerini hızlıca belirleyebileceğine inanmaya başladık. Yeni gelenlerin hızlı bir şekilde düzenleme yapabildikleri ve olumlu bir deneyim yaşadıklarında kalmak istediklerine inanıyoruz. Ancak hemen hemen her tür katkı için Wikipedia'ya katkıda bulunmak karmaşıktır ve bu onların hızlı bir şekilde başarılı olmalarını zorlaştırır. Örneğin, bir makaleye tek bir cümle eklemek kadar basit bir şey yapmak için yaklaşık bir düzine adım gereklidir:


 * 1) Doğru maddeyi arayın.
 * 2) Eklemek istediğiniz bilgilerin maddede olup olmadığını öğrenin.
 * 3) Cümlenin ekleneceği bir bölüm seçin.
 * 4) Düzenlemeye başlamak için tıklayın.
 * 5) Cümleyi doğru yere yazın.
 * 6) Alıntı düğmesine tıklayın.
 * 7) Bağlantı veya alıntı bilgisini almak için kaynağa dönün.
 * 8) Atıf formunu doldurun ve kaydedin.
 * 9) Düzenlemeyi yayınlamak için tıklayın.
 * 10) Bir değişiklik özeti doldurun.
 * 11) Yayınla.

Görsel veya vikimetin editörüne ilk kez bakan yeni başlayanlar, bu adımların ne olduğunu, hangi sırayla yapılacağını veya gerçekleşmesi için hangi düğmelerin tıklanacağını bilmiyorlar. Başka bir deyişle, deneyimleri yapılandırılmış değildir. Sadece bunalmış ve terk edilmiş olabilirler. Ya da deneme yanılma yöntemini kullanabilir, hata yapabilir ve deneyimli editörlerden olumsuz geri bildirim alabilirler. Bu proje bununla ilgili: yeni gelenlerin bu iş akışlarında doğru sırayla ilerlemelerine nasıl yardımcı olabiliriz?

Diğer ekiplerden gelen bilgilere dayanmak
Düzenleme iş akışlarına yapı eklemek uzun zamandır Wikimedia projelerinin bir parçası olmuştur. Bazı örnekler:


 * HotCat: kullanıcıların vikimetine manüel olarak düzenlemek yerine birkaç tıklamayla maddelere eklenecek kategorileri seçmelerine olanak tanır.
 * Commons Yükleme Sihirbazı: Commons'a medya yükleme işlemini bir dizi basit adıma böler.
 * Citoid: Görsel Düzenleyici'de mevcutsa, bu, alıntı metnini ve şablonu otomatik olarak üretmek için algoritmalar içeren adımlara bir alıntı ekleme işlemini bozar.

En son olarak, "yapılandırılmış görevler" fikri Vikipedi Android uygulamasında ve İçerik Çevirisi aracında iyi çalışmaktadır. Çalışmalarından ilham alıyoruz.

"Önerilen düzenlemeler" projesiyle Android ekibi bozulması bir Vikipedi maddesine bir metin kutusuna yazmanın kolay bir adımına başlık açıklaması ekleme işlemidir. O zamandan beri aynı şeyi başlık açıklamalarını diller arasında çevirmekle yaptılar. Aynı görevleri yapılandırılmış bir iş akışı olmadan  yapmak  için, kullanıcılar Vikiveri'ye gitmeli ve aynı düzenlemeleri yapmak için birkaç adım atmalıdırlar. Ekip bu yöntemin işe yaradığını öğrendi: Birçok Android kullanıcısı bu küçük yüzlerce katkıyı yapıyor.

Dil ekibi, İçerik Çeviri aracını oluşturdu, bu da bir maddeyi tercüme etme sürecini yapılandırmak için birkaç şey yapar. Çeviriler için tasarlanmış yan yana arabirim sunar, çeviriyi bölümlere ayırır ve otomatik olarak makine çeviri algoritmaları uygular. Vikipedistler maddeleri aracın varlığından önce çevirebilse de, gerekli manüel adımların sayısı bunu çok zorlaştırdı. Bu araç, yüz binlerce çeviri tamamlandığında başarılı. Bir maddeyi çevirirken adımlara ayrılırken, ezber parçalarının (örn. makine çevirisi) otomatik olarak halledilmesiyle daha fazla maddenin çevrildiğini öğrendik.

Büyüme ekibi, bu ilkeleri bağlantı eklemek, resim eklemek, kaynak eklemek ve cümleler eklemek gibi makalelerdeki içerik düzenlemelerine de uygulamayı düşünüyor.

Yapılandırılmış bir görev çizimi
Yapısal görevler hakkında nasıl düşündüğümüzü açıklamanın en iyi yolu hızlı bir taslak göstermektir. Düşündüğümüz ilk yapılandırılmış görev "bir (viki)bağlantısı ekle"'dir. Ancak aynı fikirler, "resim eklemek", "kaynak eklemek" ve hatta "gerçek eklemek" için yapılandırılmış görevler için de geçerli olabilir.

Yeni gelenler görevinde, pek çok yeni gelen "(viki)bağlantısı ekle" görevlerini tamamlar, burada çok fazla olmayan makalelere dahili mavi bağlantılar eklerler. Bu başlamak için basit bir düzenleme görevi gibi görünüyor. Ancak, birçok yeni kişinin bir bağlantı ekleme adımlarından nasıl geçeceğini anlamayabileceğini ve bağlantılara hangi kelimelerin yapılacağını bilemeyebileceğini düşünüyoruz. Hangi kelimelerin veya kelime öbeklerinin en iyi bağlantıları yapabileceğini tahmin edebilen bir algoritmanın yardımıyla, adım adım ilerleyen bir iş akışı hayal ediyoruz.

Aşağıdaki çizimde, yeni gelen bir maddeye ulaşır ve iyi bir (viki)bağlantı oluşturabilecek bir kelime önerisi verilir. Bir bağlantı yapılması gerektiğine katılırlarsa, bağlantı kurma adımlarından geçerler. Bu, umarım gelecekte kendi başlarına bağlantılar eklemeyi öğretir ve belki de bu algoritmik bağlantı önerilerini almaya devam etmenin tadını çıkaracaklar. Algoritma ile ilgili olarak, WMF Araştırma ekibi böyle bir algoritmanın mümkün olduğundan emin olmamızı sağlayan bazı ön çalışmalar yaptı.



Bunun hakkında daha fazla düşünürken, ikinci bir fikir çizdik. Yeni gelen kişiye görsel düzenleyiciyi kullanarak bağlantı eklemeyi öğretmeyi amaçlamak yerine, bu bir sonraki iş akışı kullanıcının makaleyi doğrudan düzenleyerek algoritmadan gelen önerileri hızlı bir şekilde onaylamasını veya reddetmesini sağlar. Editör aracılığıyla nasıl bağlantı ekleneceğini öğretmese de, yeni gelen bir kişinin yüksek ses düzeyinde düzenlemesine yardımcı olabilir ve hareket halindeyken basit görevlerle üretken olmaya çalışan bir kullanıcı için daha uygun olabilir. Ya da, sadece çok basit düzenlemelerle ilgilenen kullanıcılar için iyi bir uyum olabilir, Android uygulamasının sadece başlık açıklamaları yazmak isteyen birçok editörleri olduğu gibi.



Yapılandırılmış görevleri düşünürken, bu büyük bir soru olabilir: iş akışları yeni gelenlere geleneksel araçları kullanmalarını öğretmeyi mi, yoksa yeni gelenlerin daha yüksek ses düzeyinde kolay düzenlemeler yapabilmelerini mi hedeflemelidir?

Bu fikre neden öncelik tanınır
Hızlı bir şekilde verimli düzenlemeler yapmanın yeni başarıya yol açtığını düşünüyoruz. Bazı düzenlemeler yaptıktan sonra, viki deneyiminin geri kalanı hızla zenginleşir. Yeni gelenler daha sonra etkilerini görebilir, teşekkür edebilir, mentorları bilinçli sorular sorabilir, kullanıcı sayfalarını oluşturabilir, vb. Yeni gelen görevleri projesinden, birçok yeni gelenin yapmak için kolay görevler aradığını gördük. Ancak biz de bunları gözlemledik:


 * Bir öneriyi tıklayan yeni gelenlerin yalnızca %25'i gerçekten bir öneriyi düzenler.
 * Önerilen bir düzenlemeyi yapanların yalnızca %25'i başka bir düzenleme yapar.
 * Önerilen düzenlemelerde gerçekten başarılı olan ve her gün düzinelerce yapan bir kaç yeni kullanıcı var. Bu, yeni gelenlerin çok sayıda viki çalışması yapma potansiyelini göstermektedir.
 * Canlı kullanıcı testlerinde, yeni gelenlere bir maddeyi kopyalamaları veya bir maddeye bağlantılar eklemeleri söylendiğinde, sıklıkla hangi cümlenin veya kelimelerin dikkatini çekmesi gerektiğini tam olarak bilmek isterler. Başka bir deyişle, maddenin tamamını düzenlemeye çalışmak çok açık uçlu.

Bu noktaları, Android ve İçerik Çevirisi ekiplerinin yukarıda açıklanan deneyimleriyle birlikte alarak, Vikipedi'deki bazı içerik düzenleme iş akışlarını yapılandırarak düzenleme ve düzenlemeye devam eden yeni kullanıcıların sayısını artırabileceğimizi düşünüyoruz.

Yapılandırılmış görevlerle fırsatlar
İş akışlarını düzenleme adımlarına böldüğümüzde, onlara "yapılandırılmış görevler" diyoruz. Yapılandırılmış görevlerden gelebileceğini düşündüğümüz bazı olası faydalar şunlardır:


 * Yeni gelenlerin anlamlı katkılar yapmasını kolaylaştırın.
 * Mobil cihazlar için anlamlı olan düzenleme iş akışları geliştirin. Mobil tasarım ilkeleri, kullanıcıların karmaşık bir çalışma alanını değil, her seferinde bir adım görmesi gerektiğini söylüyor.
 * Yeni gelenlerin becerilerini aşamalı olarak artırmasına izin verin. Başarılı bir şekilde daha zorlu görevler üstlenebilirler.
 * Kişilerin kendilerine uyan bir düzenleme deneyimi bulmasına izin verin. Yeni gelenlere yapılandırılmış görevler akışı vererek, istedikleri görev türünü bulabilirler.
 * Belki de benzer iş akışları gelecekte deneyimli editörlere açılabilir.

Yapılandırılmış görevlerin endişeleri ve dezavantajları
İnsanların Vikipedi'yi düzenlemeleri için yeni yollar eklediğimizde, yanlış gidebilecek birçok şey vardır:


 * Düzenlemeyi çok hızlı ve kolay hale getirerek, vandalları veya düzenleme sırasında yeterli bakım yapmayan kullanıcıları çekebiliriz.
 * Yeni gelenlere basit iş akışları vermek, en etkili viki çalışmasını yapmak için gerekli olan geleneksel düzenleme araçlarını öğrenmelerini engelleyebilir.
 * Yapısal görevler, diller arasındaki farklılıkları, vikimetin ile yapılan özdilemeleri hesaba katmada iyi olmayabilir ve başka tür hatalara neden olabilir.
 * Yüzeysel yapılandırılmış görevleri yeterince doğru bulmayabilecek algoritmalar ve yeni gelenleri, yapmamaları gereken düzenlemeleri tamamlamaları için yanlış bir şekilde teşvik edebilirler.

Topluluk tartışması
Mayıs 2020'de, yapılandırılmış görevler için yukarıdaki fikirler hakkında topluluk üyeleriyle altı dilde (İngilizce, Fransızca, Korece, Arapça, Vietnamca, Çekçe) tartışmalar yaptık. İngilizce tartışma çoğunlukla buradaki tartışma sayfasında, diğer İngilizce Vikipedi'deki sohbetler ve diğer beş Vikipedi'lerde yerel dil konuşmaları ile gerçekleşti. 35 topluluk üyesinden haber aldık ve bu bölüm en popüler ve ilginç düşüncelerden bazılarını özetlemektedir. Bu tartışmalar, sonraki tasarım setimizi büyük ölçüde etkiledi.


 * Topluluk üyeleri, yeni gelenlerin düzenlemeye başlamasına yardımcı olacak yapılandırılmış görevlerin potansiyeli konusunda genellikle olumluydu. Ancak, süreç boyunca yeni gelenlerin geleneksel kaynak ve görsel editörlerle tanışmasının önemli olduğu da yaygın olarak ifade edilen bir görünüştü. Topluluk üyeleri, yeni gelenlerin ayrı bir düzenleme deneyiminde toplanmamasını ve daha değerli düzenlemeler için kendi yollarını bulabilmelerini ister.
 * The Czech community talked about ideas for how the structured tasks can place inside the visual editor, so that newcomers can start getting used to being in the editor. Perhaps the editing tools that are not needed for the structured task can be grayed-out.
 * Community members asked why we are choosing "add a link" as our first structured task, as opposed to higher-value types of edits. We talked about how this task is one of the easiest for us to build, which will help us prototype and learn from structured tasks sooner, and how it is a comparatively low-risk task, with fewer opportunities for newcomers to damage articles.
 * Several communities mentioned that spelling corrections would be a particularly valuable task, and we talked about technical options for how to generate lists of potential spelling mistakes. See these notes for more details.
 * We also talked about whether reverting vandalism is a good fit for newcomers. It doesn't seem like the answer is clear, and this will have to be discussed more in the future.
 * An idea that was mentioned multiple times is how to "step newcomers up" to progressively more challenging tasks, perhaps while giving them rewards for successfully completing easier ones.

Types of tasks
There are many different editing workflows that have the potential to become structured. We began to list workflows when we first designed the newcomer tasks workflow here, and we have since narrowed down to a shorter list of task types that seem best suited to being structured. The table below contains that short list, ranked in a potential priority order.

Prioritizing "add a link"
The Growth team currently (May 2020) wants to prioritize the "add a link" workflow over the other ones listed in the table above. Although other workflows, such as "copyedit", seem to be more valuable, there are a set of reasons we would want to start first with "add a link":


 * In the near term, the most important thing we would want to do first is to prove the concept that "structured tasks" can work. Therefore, we would want to build the simplest one, so that we can deploy to users and gain learnings, without having to invest too much in the first version. If the first version goes well, then we would have the confidence to invest in types of tasks that are more difficult to build.
 * "Add a link" seems to be the simplest for us to build because there already exists an algorithm built by the WMF Research team that seems to do a good job of suggesting wikilinks (see the Algorithm section).
 * Adding a wikilink doesn't usually require the newcomer to type anything of their own, which we think will make it particularly simple for us to design and build -- and for the newcomer to accomplish.
 * Adding a wikilink seems to be a low-risk edit. In other words, the content of an article can't be as compromised through adding links incorrectly as it could through adding references or images incorrectly.

Notes on "copyedit"
In conversations with community members on this project's discussion page, many people brought up the question of how to make a structured task around copyediting. Correcting spelling, grammar, punctuation, and tone seemed to everyone to be a clearly useful task that should be prioritized. The Growth team initially shied away from this workflow because of scaling concerns: even if we were able to find or develop an algorithm that could reliably find copyedits in one language, would we be able to do that in dozens of other languages?

We began to learn more about this by talking with User:Beland, who developed the "moss" script for English Wikipedia's Typo Team. We wanted to understand how the process works, and what it might look like to do something similar in other languages. In short, it sounds like the most promising avenue is through existing open-source spellcheckers and dictionaries. Two examples are the aspell and hunspell libraries. Below are our notes from learning about "moss" with User:Beland.


 * Prospects for doing something similar in other languages
 * A process like this should theoretically work in other languages, given that other languages also have Wiktionaries and open-source spellcheckers.
 * But it would not be possible to deploy in a new language without native speakers validating it. There would likely need to be customization for many languages.
 * Likely more challenges for languages without word segmentation (e.g. Japanese).
 * Likely more challenges for agglutinative languages.
 * Different projects have differing manuals of style, which may cause issues.
 * If an algorithm is performing poorly, it should always be possible to change its thresholds so that it identifies fewer potential errors, but with higher confidence.
 * How does moss work?
 * Download the dump files of all of English Wikipedia every two weeks.
 * In order to cut down on false positives, remove templates and everything inside quotation marks, etc.  Only want to work on the main text in the article: the things written “in Wikipedia’s voice”.
 * Check that every word is in English Wiktionary.
 * Uses Python NLTK (natural language toolkit) for word segmentation.
 * Looks at edit distance to classify misspellings.  e.g. “T1” is one edit distance (95% precision).  Also classifies “TS” whitespace errors.
 * Also includes an English open-source spellchecker to narrow the search space so that the algorithm can run faster.
 * He has also started trying to add grammar rules (e.g. identifying passive voice), but that’s more experimental, and much more difficult than spelling.
 * At the end of the process, it produces a list of articles and likely typos.  The user opens the article and searches for the likely typo.

Many copyedit requests are also editors whose native language is not English, asking for English polishing. See WikiProject Guild of Copy Editors.

Design
While the "structured task sketch" section above contains some quick initial sketches to demonstrate the idea behind structured tasks, this section contains our current design thinking. To look into the full set of thinking around designs for the "add a link" structured task, , which contains background, user stories, and initial design concepts.

Comparative review
When we design a feature, we look into similar features in other software platforms outside of the Wikimedia world. These are some highlights from comparative reviews done in preparation for Android’s suggested edits feature, which remain relevant for our project.


 * Task types – are divided into five main types: Creating, Rating, Translating,  Verifying content created by others (human or machine), and Fixing content created by others.
 * Visual design & layout – incentivizing features (stats, leaderboards, etc) and onboarding is often very visually rich, compared to pared back, simple forms to complete short edits. Gratifying animations often compensate for lack of actual reward.
 * Incentives – Most products offered intangible incentives grouped into: Awards and ranking (badges) for achieving set milestones, Personal pride and gratification (stats), or Unlocking features (access rights)
 * Users motivations – those with more altruistic motivations (e.g., help others learn) are more likely to be incentivized by intangible incentives than those with self-interested motivations (e.g., career/financial benefits)
 * Personalization/Customization – was used in some way on most apps reviewed. The most common customization was via surveys during account creation or before a task; and geolocalization used for system-based personalization.
 * Guidance – Almost all products reviewed had at least basic guidance prior to task completion, most commonly introductory ‘tours’. In-context help was also provided in the form of instructional copy, tooltips, step-by-step flows,  as well as offering feedback mechanisms (ask questions, submit feedback)

Initial wireframes
After organizing our thoughts and doing background research, the first visuals in the design process are "wireframes". These are simply meant to experiment and display some of the ideas we think could work well in a structured task workflow. For full context around these wireframes, see the.

Mobile mockups: August 2020
Translate this section

Our team discussed the wireframes from the previous section. We considered what would be best for the newcomers, taking into account the preferences expressed by community members, and thinking about engineering constraints. In August 2020, we took the next step of creating mockups, meant to show in more detail what the feature might look like. These mockups (or similar versions) will be used in team discussions, community discussions, and user tests. One of the most important things we thought about with these mockups is the concern we heard consistently from community members during the discussion: structured tasks may be a good way to introduce newcomers to editing, but we also want to make sure they can find and use the traditional editing interfaces if they are interested.

We have mockups for two different design concepts. We're not necessarily aiming to choose one design concept or the other. Rather, the two concepts are meant to demonstrate different approaches. Our final designs may contain the best elements from both concepts:


 * Concept A: the structured task edit takes place in the Visual Editor. The user can see the whole article, and switch out of "recommendation mode" into source or visual editor mode.  Less focused on adding the links, but easier access to the visual and source editors.
 * Concept B: the structured task edit takes place in its own new area. The user is shown only the paragraph of the article that needs their attention, and can go edit the article if they choose.  Fewer distractions from adding links, but more distant access to the visual and source editors.

Please note that the focus in this set of mockups is on the user flow and experience, not on the words and language. Our team will go through a process to determine the best way to write the words in the feature and to explain to the user whether a link should be added.



Static mockups

To view these design concepts, we recommend viewing the full set of slides below.



Interactive prototypes

You can also try out the "interactive prototypes" that we're using for live user tests. These prototypes, for Concept A and for Concept B, show what it might feel like to use "add a link" on mobile. They work on desktop browsers and Android devices, but not iPhones. Note that not everything is clickable -- only the parts of the design that are important for the workflow.

 Essential questions 

In discussing these designs, our team is hoping for input on a set of essential questions:


 * 1) Should the edit happen at the article (more context)?  Or in a dedicated experience for this type of edit (more focus, but bigger jump to go use the editor)?
 * 2) What if someone wants to edit the link target or text?  Should we prevent it or let them go to a standard editor?  Is this the opportunity to teach them about the visual editor?
 * 3) We know it’s essential for us to support newcomers discovering traditional editing tools. But when do we do that? Do we do it during the structured task experience with reminders that the user can go to the editor? Or periodically at completion milestones, like after they finish a certain number of structured tasks?
 * 4) Is "bot" the right term here? What are some other options? "Algorithm", "Computer", "Auto-", "Machine", etc.?"   What might better help convey that machine recommendations are fallible and the importance of human input?

Mobile user testing: September 2020
Background

During the week of September 7, 2020, we used usertesting.com to conduct 10 tests of the mobile interactive prototypes, 5 tests each of Concepts A and B, all in English. By comparing how users interact with the two different approaches at this early stage, we wanted to better understand whether one or the other is better at providing users with good understanding and ability to successfully complete structured tasks, and to set them up for other kinds of editing afterward. Specific questions we wanted to answer were:


 * Do users understand how they are improving an article by adding wikilinks?
 * Do users seem like they will want to cruise through a feed of link edits?
 * Do users understand that they're being given algorithmic suggestions?
 * Do users make better considerations on machine-suggested links when they have the full context of the article (like in Concept A)?
 * Do users complete tasks more confidently and quickly in a focused UI (like in Concept B)?
 * Do users feel like they can progress to other, non-structured tasks?

Key findings


 * The users generally were able to exhibit good judgment for adding links. They understood that AI is fallible and that they have to think critically about the suggestions.
 * While general understanding of what the task would be ("adding links") was low at first, they understood it well once they actually started doing the task. Understanding in Concept B was marginally lower.
 * Concept B was not better at providing focus. The isolation of excerpts in many cases was mistaken for the whole article. There were also many misunderstandings in Concept B about whether the user would be seeing more suggestions for the same term, for the same article, or for different articles.
 * Concept A better conveyed expectations on task length than Concept B. But the additional context of a whole article did not appear to be the primary factor of why.
 * As participants proceed through several tasks, they become more focused on the specific link text and destination, and less on the article context. This seemed like it could lead to users making weak decisions, and this is a design challenge. This was true for both Concepts A and B.
 * Almost every user intuitively knew they could exit from the suggestions and edit the article themselves by tapping the edit pencil.
 * All users liked the option to view their edits once they finished, either to verify or admire them.
 * “AI” was well understood as a concept and term. People knew the link suggestions came from AI, and generally preferred that term over other suggestions. This does not mean that the term will translate well to other languages.
 * Copy and onboarding needs to be succinct and accessible in multiple points. Reading our instructions is important, but users tended not to read closely. This is a design challenge.

Outcome


 * We want to build Concept A for mobile, but absorbing some of the best parts of Concept B's design. These are the reasons why:
 * User tests did not show advantages to Concept B.
 * Concept A gives more exposure to rest of editing experience.
 * Concept A will be more easily adapted to an “entry point in reading experience”: in addition to users being able to find tasks in a feed on their homepage, perhaps we could let them check to see if suggestions are available on articles as they read them.
 * Concept A was generally preferred by community members who commented on the designs, with the reason being that it seemed like it would help users understand how editing works in a broader sense.
 * We still need to design and test for desktop.

Ideas

The team had these ideas from watching the user tests:


 * Should we consider a “sandbox” version of the feature that lets users do a dry run through an article for which we know the “right” and “wrong” answers, and can then teach them along the way?
 * Where and when should we put the clear door toward other kinds of editing?  Should we have an explicit moment at the end of the flow that actively invites them copyedit or do another level task?
 * It’s hard to explain the rules of adding a link before they try the task, because they don't have context. How might we show them the task a little bit, before they read the rules?
 * Perhaps we could onboard the users in stages?  First they learn a few of the rules, then they do some links, then we teach them a few more pointers, then they do more links?
 * Should users have a cooling-off period after doing lots of suggestions really fast, where we wait for patrollers to catch up, so we can see if the user has been reverted?

Desktop mockups: October 2020
After designing, testing, and deciding on Concept A for mobile users, we moved on to thinking about desktop users. We again have the same question around Concepts A and B. The links below open interactive prototypes of each, which we are using for user testing.


 * Concept A: the structured task takes place at the article, in the editor, using some of the existing visual editor components. This gives users greater exposure to the editing context and may make it more likely that they explore other kinds of editing tasks.
 * Concept B: the structured task takes place on the newcomer homepage, essentially embedding the compact mobile experience into the page. Because the user doesn't have to leave the page, this may encourage them to complete more edits. They could also see their impact statistics increase as they edit.

We are user testing these designs during the week of October 23. See below for mockups showing the main interaction in each concept.

Engineering
To follow along with engineering progress on the backend "add link" service, please see this page on Wikitech.