Growth/Personalized first day/Structured tasks/Add an image/es

Esta página describe el trabajo en una tarea estructurada de "añadir una imagen", que es un tipo de tarea estructurada que el equipo de Crecimiento ofrecerá a través de la página de inicio para recién llegados. El equipo de Android ha trabajado en una versión mínima de una tarea similar para la aplicación de Wikipedia para Android utilizando los mismos componentes de base. Además, el equipo de Datos estructurados está en las primeras fases de estudio de algo similar, dirigido a usuarios más experimentados y que se beneficie de Datos estructurados en Commons. Los comentarios y actualizaciones de esta página son relevantes para el trabajo de todos los equipos.

Esta página contiene los principales elementos, diseños, preguntas abiertas y decisiones. To try out the experience, |please open up this interactive prototype on your mobile device.

La mayoría de las actualizaciones sobre el progreso se publicarán en la página general de Actualizaciones del equipo de crecimiento, con algunas actualizaciones grandes o detalladas publicadas aquí.

Estado actual

 * 2020-06-22: reflexión inicial sobre las ideas para crear un algoritmo sencillo de recomendación de imágenes
 * 2020-09-08: evaluó un primer intento de algoritmo de comparación en inglés, francés, árabe, coreano, checo y vietnamita
 * 2020-09-30: evaluó un segundo intento de algoritmo de comparación en inglés, francés, árabe, coreano, checo y vietnamita
 * 2020-10-26: Discusión interna sobre la viabilidad del servicio de recomendación de imágenes
 * 2020-12-15: realizar una ronda inicial de pruebas con los usuarios para empezar a entender si los recién llegados pueden tener éxito con esta tarea
 * 2021-01-20: Nuestro equipo de ingeniería de plataformas comienza a construir una prueba de concepto de la API para las recomendaciones de imágenes.
 * 2021-01-21: El equipo de Android comienza a trabajar en una versión mínima viable para el aprendizaje
 * 2021-01-28: publicación de resultados de las pruebas de usuarios
 * 2021-02-04: Publicación de un resumen del debate comunitario y de las estadísticas de cobertura.
 * 2021-05-07: El MVP de Android se pone a disposición de los usuarios
 * 2021-08-06: resultados publicados de Android y maquetas para la Iteración 1
 * 2021-08-17: Comienza el trabajo backend en la Iteración 1
 * 2021-08-23: publicación de prototipos interactivos y comienzo de las pruebas de usuario en inglés y español
 * 2021-10-07: resultados publicados de las pruebas de usuarios y diseños finales basados en los datos obtenidos
 * 2021-11-19: El embajador comienza a probar la función en sus Wikipedias de producción
 * 2021-11-22: el conjunto de datos de sugerencia de imágenes se actualiza antes de entregar la Iteración 1 a los usuarios
 * 2021-11-29: Iteration 1 deployed to 40% of mobile accounts on Arabic, Czech, and Bengali Wikipedias.
 * Siguiente: evaluate leading indicators week of December 13

Resumen
Las tareas estructuradas tienen como objetivo dividir las tareas de edición en flujos de trabajo paso a paso que tengan sentido para los recién llegados y para los dispositivos móviles. El equipo de Crecimiento cree que la introducción de estos nuevos tipos de flujos de trabajo de edición permitirá que más personas nuevas comiencen a participar en Wikipedia, algunas de las cuales aprenderán a hacer ediciones más relevantes y se involucrarán con sus comunidades. Después de discutir la idea de las tareas estructuradas con las comunidades, decidimos construir la primera tarea estructurada: "añadir un enlace".

Después de desplegar "añadir un enlace" en mayo de 2021, recogimos datos iniciales que mostraban que la tarea era atractiva para los recién llegados y que hacían ediciones con bajas tasas de reversión, lo que indica que las tareas estructuradas parecen valiosas para la experiencia de los recién llegados y las wikis.

Mientras construíamos esa primera tarea, estuvimos pensando en cuál podría ser la siguiente tarea estructurada, y creemos que añadir imágenes podría ser una buena opción para los recién llegados. La idea es que un simple algoritmo recomiende imágenes de Commons para colocarlas en artículos que no tienen imágenes. Para empezar, utilizaría sólo las conexiones existentes que se pueden encontrar en Wikidata, y los recién llegados usarían su sentido común para colocar la imagen en el artículo o no.

Sabemos que hay muchas preguntas abiertas sobre cómo funcionará este sistema, y también muchas razones posibles para que no salga bien. Por eso queremos escuchar a muchos miembros de la comunidad y mantener un debate continuo mientras decidimos cómo proceder.

¿Por qué imágenes?
Buscando contribuciones relevantes

Cuando comentamos por primera vez las tareas estructuradas con los miembros de la comunidad, muchos señalaron que añadir wikilinks no era un tipo de edición especialmente valioso. Los miembros de la comunidad aportaron ideas sobre cómo los recién llegados podrían hacer contribuciones más significativas. Una idea es la de las imágenes. Wikimedia Commons contiene 65 millones de imágenes, pero en muchas Wikipedias, más del 50% de los artículos no tienen imágenes. Creemos que muchas imágenes de Commons pueden hacer que Wikipedia esté sustancialmente más ilustrada.

Intereses de los recién llegados

Sabemos que muchos recién llegados están interesados en añadir imágenes a Wikipedia. "Añadir una imagen" es una respuesta común que dan los recién llegados en la encuesta de bienvenida para explicar por qué están creando su cuenta. También vemos que una de las preguntas más frecuentes del panel de ayuda es sobre cómo añadir imágenes, algo que ocurre en todas las wikis con las que trabajamos. Aunque la mayoría de estos recién llegados probablemente traen su propia imagen que quieren añadir, esto indica que las imágenes pueden resultar atractivas y estimulantes. Esto tiene sentido, dados los elementos de imagen de las otras plataformas en las que participan los recién llegados, como Instagram y Facebook.

Dificultades de trabajar con imágenes

Las numerosas preguntas del panel de ayuda sobre las imágenes reflejan que el proceso para añadirlas a los artículos es muy complicado. Los recién llegados tienen que entender la diferencia entre Wikipedia y Commons, las reglas en torno a los derechos de autor y las partes técnicas de insertar y subtitular la imagen en el lugar correcto. Encontrar una imagen en Commons para un artículo no ilustrado requiere aún más habilidades, como el conocimiento de Wikidata y las categorías.

Éxito de la campaña "Páginas de Wikipedia que quieren fotos"

La campaña Páginas de Wikipedia que quieren fotos (WPWP) tuvo un éxito sorprendente: 600 usuarios añadieron imágenes a 85.000 artículos. Lo hicieron con la ayuda de un par de herramientas comunitarias que identificaron las páginas que no tenían imágenes, y sugerían posibles imágenes a través de Wikidata. Aunque aún quedan importantes aspectos que comprender sobre cómo ayudar a los recién llegados a tener éxito con la adición de imágenes, esto nos da la certeza de que a los usuarios pueden ser entusiastas sobre la adición de imágenes y de que con las herramientas se les puede ayudar.

Tomando todo esto en conjunto

Considerando toda esta información, pensamos que podría ser posible construir una tarea estructurada de "añadir una imagen" que sea divertida para los recién llegados y productiva para las Wikipedias.

Validación de ideas
''Desde junio de 2020 hasta julio de 2021, el equipo de Crecimiento trabajó en discusiones con la comunidad, investigación de fondo, evaluaciones y pruebas de concepto en torno a la tarea de "añadir una imagen". Esto llevó a la decisión de empezar a construir nuestra primera iteración en agosto de 2021 (ver Iteración 1). Esta sección contiene todo ese trabajo de fondo que lleva a la Iteración 1.''

Algoritmo
Nuestra capacidad de hacer una tarea estructurada para añadir imágenes depende de que podamos crear un algoritmo que genere recomendaciones suficientemente buenas. Definitivamente, no queremos instar a los recién llegados a que añadan las imágenes equivocadas a los artículos, lo que causaría trabajo a los patrulleros para limpiarlas. Por eso, una de las primeras cuestiones que hemos estudiado es si podemos crear un buen algoritmo.

Lógica
Hemos estado trabajando con el equipo de investigación de Wikimedia, y por ahora hemos estado probando un algoritmo que prioriza la precisión y el juicio humano. En lugar de utilizar cualquier tipo de visión informática, que podría generar resultados inesperados, simplemente agrega la información existente en Wikidata, basándose en las conexiones realizadas por colaboradores experimentados. Estas son las tres formas principales en las que sugiere coincidencias con los artículos no ilustrados:


 * Mira el elemento de Wikidata del artículo. Si tiene una imagen (P18), elige esa imagen.
 * Mira el elemento de Wikidata del artículo. Si tiene una categoría Commons asociada (P373), elige una imagen de la categoría.
 * Mira los artículos sobre el mismo tema en las Wikipedias de otros idiomas. Elige una imagen principal de esos artículos.

El algoritmo también incluye una lógica para realizar cosas como excluir imágenes que probablemente sean iconos o que estén presentes en un artículo como parte de un navbox.

Precisión
Desde agosto de 2021, hemos llevado a cabo tres rondas de pruebas del algoritmo, cada vez examinando las coincidencias con artículos en seis idiomas: inglés, francés, árabe, vietnamita, checo y coreano. Las evaluaciones fueron realizadas por los embajadores de nuestro equipo y otros wikimedistas expertos, que son hablantes nativos de los idiomas probados.

Primeras dos evaluaciones

Al ver las 50 coincidencias sugeridas en cada idioma, las revisamos y las clasificamos en estos grupos:

Una cuestión que se plantea a lo largo de todo el trabajo sobre un algoritmo como éste es: ¿qué grado de precisión debe tener? Si el 75% de las coincidencias son buenas, ¿es suficiente? ¿Necesita una precisión del 90%? ¿O puede tener una precisión de tan sólo el 50%? Esto depende del buen juicio de los novatos que lo utilicen y de la paciencia que tengan con las coincidencias dudosas. Sabremos más sobre esto cuando probemos el algoritmo con usuarios reales.

En la primera evaluación, lo más importante es que encontramos un montón de mejoras fáciles de realizar en el algoritmo, incluyendo tipos de artículos e imágenes a excluir. Incluso sin esas mejoras, alrededor del 20-40% de las coincidencias fueron "2s", lo que significa grandes coincidencias para el artículo (dependiendo de la wiki). Puedes ver los resultados completos y las notas de la primera evaluación aquí.

Para la segunda evaluación, se incorporaron muchas mejoras, y la precisión aumentó. Entre el 50-70% de las coincidencias fueron "2s" (dependiendo de la wiki). Pero el aumento de la precisión puede disminuir la cobertura, es decir, el número de artículos para los que podemos hacer coincidencias. Utilizando un criterio conservador, el algoritmo sólo puede sugerir decenas de miles de coincidencias en una wiki determinada, aunque esa wiki tenga cientos de miles o millones de artículos. Creemos que ese tipo de volumen sería suficiente para construir una versión inicial de esta función. Puedes ver los resultados completos y las notas de la segunda evaluación aquí.

Tercera evaluación

En mayo de 2021, el equipo de Datos estructurados realizó una prueba a mayor escala del algoritmo de comparación de imágenes (y del algoritmo MediaSearch) en las Wikipedias en árabe, cebuano, inglés, vietnamita, bengalí y checo. En esta prueba, unas 500 coincidencias tanto del algoritmo de comparación de imágenes como de MediaSearch fueron evaluadas por expertos en cada idioma, que pudieron clasificarlas como coincidencias "buenas", " aceptables" o "malas". Los resultados que se detallan a continuación así lo demuestran:


 * El algoritmo de concordancia de imágenes oscila entre el 65 y el 80% de precisión, dependiendo de si se cuenta "Bueno" o "Bueno+Aceptable", y dependiendo del wiki/evaluador. Curiosamente, en nuestra experiencia en la evaluación de las coincidencias de imágenes, los wikimedistas expertos a menudo no están de acuerdo entre sí, porque cada uno tiene sus propios estándares sobre si las imágenes deben estar en los artículos.
 * Wikidata P18 ("Wikidata") es la fuente más fuerte de coincidencias, con una precisión del 85% al 95%. Las imágenes de otras Wikipedias ("Cross-wiki") y de las categorías Commons adjuntas a los artículos de Wikidata ("Commons category") son menos precisas en un grado similar.
 * Las imágenes de otras Wikipedias ("Cross-wiki") es la fuente más común de coincidencias. En otras palabras, el algoritmo dispone de más imágenes de este tipo que de las otras dos fuentes.

Los resultados completos pueden encontrarse aquí..

Cobertura
La precisión del algoritmo es claramente un componente muy importante. Igualmente importante es su "cobertura", que se refiere a "cuántas" coincidencias de imágenes puede hacer. La precisión y la cobertura tienden a estar relacionadas de forma inversa: a mayor precisión del algoritmo, menor número de sugerencias (porque sólo hará sugerencias cuando esté seguro). Tenemos que responder a estas preguntas: ¿es el algoritmo capaz de proporcionar suficientes coincidencias como para que merezca la pena construir una característica con él? ¿Podría tener un impacto sustancial en las wikis? Hemos analizado 22 wikipedias para hacernos una idea de las respuestas. La siguiente tabla muestra el resumen de estos aspectos:


 * Los números de cobertura reflejados en la tabla parecen ser suficientes para una primera versión de una función de "añadir una imagen". Hay suficientes coincidencias de candidatos en cada wiki como para que (a) los usuarios no se queden sin ellas, y (b) la función pueda tener un impacto significativo en lo ilustrada que esté una wiki.
 * Las wikis oscilan entre el 20% sin ilustrar (serbia) y el 69% sin ilustrar (vietnamita).
 * Podemos encontrar entre 7.000 (bengalí) y 155.000 (inglés) artículos no ilustrados que tienen opciones de coincidencia. En general, se trata de un volumen suficiente para una primera versión de la tarea, de modo que los usuarios tienen bastantes posibilidades de realizar emparejamientos. En algunas de las wikis más escasas, como la bengalí, podría entrar en números pequeños una vez que los usuarios se limiten a los temas de interés. Dicho esto, el bengalí sólo tiene unos 100.000 artículos en total, por lo que estaríamos proponiendo coincidencias para el 7% de ellos, lo cual es considerable.
 * En cuanto a la mejora de las ilustraciones que podríamos hacer en las wikis con este algoritmo, el límite oscila entre el 1% (cebwiki) y el 9% (trwiki). Ese es el porcentaje global de artículos adicionales que podrían incorporar ilustraciones si todas las coincidencias fueran buenas y se añadieran a la wiki.
 * Las wikis con el menor porcentaje de artículos sin ilustrar para las que podemos encontrar coincidencias son arzwiki y cebwiki, que tienen un alto volumen de artículos creados por bots. Esto tiene sentido porque muchos de esos artículos son de ciudades o especies específicas que no tendrían imágenes en Commons. Pero como esas wikis tienen tantos artículos, aún hay decenas de miles para los que el algoritmo tiene coincidencias.
 * En un futuro más lejano, esperamos que las mejoras en el algoritmo de comparación de imágenes, o en MediaSearch, o en los flujos de trabajo para subir/titular/etiquetar imágenes produzcan más coincidencias potenciales.

MediaSearch
Como se ha mencionado anteriormente, el equipo de Datos estructurados está explorando el uso del algoritmo MediaSearch para aumentar la cobertura y obtener más resultados potenciales.

MediaSearch funciona combinando la búsqueda tradicional basada en texto y los datos estructurados para proporcionar resultados relevantes para las búsquedas de manera independiente al idioma. Al utilizar las declaraciones de Wikidata añadidas a las imágenes como parte de Datos estructurados en Commons como entrada para la clasificación de la búsqueda, MediaSearch es capaz de aprovechar los alias, los conceptos relacionados y las etiquetas en varios idiomas para aumentar la relevancia de las coincidencias de las imágenes. Puedes encontrar más información sobre el funcionamiento de MediaSearch aquí.

Desde febrero de 2021, el equipo está investigando cómo proporcionar una puntuación de confianza para las coincidencias de MediaSearch que el algoritmo de recomendaciones de imágenes pueda consumir y utilizar para determinar si una coincidencia de MediaSearch es de suficiente calidad para ser utilizada en tareas de emparejamiento de imágenes. Queremos estar seguros de que los usuarios confían en las recomendaciones que MediaSearch proporciona antes de incorporarlas a la función.

El equipo de Datos Estructurados también está explorando y creando un prototipo para que los bots generados por el usuario utilicen los resultados generados tanto por el algoritmo de recomendaciones de imágenes como por MediaSearch para añadir automáticamente imágenes a los artículos. Se trata de un experimento en wikis con muchos bots, en colaboración con los creadores de bots de la comunidad. Puedes saber más sobre este proyecto o expresar tu interés en participar en la tarea phabricator.

En mayo de 2021, en la misma evaluación citada en la sección "Precisión", MediaSearch resultó ser mucho menos preciso que el algoritmo de comparación de imágenes. Mientras que el algoritmo de comparación de imágenes tenía una precisión del 78%, las coincidencias de MediaSearch tenían una precisión del 38%. Por lo tanto, el equipo de Crecimiento no tiene previsto utilizar MediaSearch en su primera iteración de la tarea "añadir una imagen".

Preguntas abiertas
Las imágenes son una parte muy importante y notoria de la experiencia de Wikipedia. Es fundamental que pensemos detenidamente en cómo funcionaría una función que permitiera añadir imágenes de forma sencilla, cuáles podrían ser los posibles obstáculos y cuáles serían las implicaciones para los miembros de la comunidad. Con este fin, tenemos muchas preguntas abiertas, y queremos escuchar otras que los miembros de la comunidad puedan plantear.


 * ¿Será nuestro algoritmo lo suficientemente preciso como para proporcionar muchas coincidencias buenas?
 * ¿Qué metadatos de Commons y del artículo sin ilustrar necesitan los recién llegados para tomar una decisión sobre si añadir la imagen?
 * ¿Tendrán los recién llegados el suficiente buen criterio a la hora de analizar las recomendaciones?
 * ¿Los recién llegados que no leen inglés serán igualmente capaces de tomar buenas decisiones, dado que gran parte de los metadatos de Commons están en inglés?
 * ¿Serán capaces los recién llegados de escribir buenos pies de foto que acompañen a las imágenes que coloquen en los artículos?
 * ¿Hasta qué punto los recién llegados deben considerar las imágenes en función de su "calidad" frente a su "relevancia"?
 * ¿Los recién llegados pensarán que esta tarea es interesante? ¿Divertida? ¿Difícil? ¿Fácil? ¿Aburrida?
 * ¿Con qué precisión debemos determinar qué artículos no tienen imágenes?
 * ¿En qué parte del artículo debe colocarse la imagen? ¿Es suficiente con ponerla en la parte superior del artículo?
 * ¿Cómo podemos controlar el posible sesgo de las recomendaciones, por ejemplo, si el algoritmo hace muchas más coincidencias con temas de Europa y América del Norte?
 * ¿Será este flujo de trabajo un vector de vandalismo? ¿Cómo se puede evitar?

Notas de las discusiones comunitarias 04-02-2021
Desde diciembre de 2020, invitamos a los miembros de la comunidad a hablar sobre la idea de "añadir una imagen" en cinco idiomas (inglés, bengalí, árabe, vietnamita y checo). La discusión en inglés tuvo lugar principalmente en la página de discusión, con conversaciones en el idioma local en las otras cuatro Wikipedias. Hemos escuchado a 28 miembros de la comunidad, y esta sección resume algunas de las ideas más comunes e interesantes. Estas discusiones están influenciando fuertemente nuestro próximo conjunto de diseños.


 * En general: Los miembros de la comunidad son en general cautelosamente optimistas sobre esta idea. En otras palabras, la gente parece estar de acuerdo en que sería valioso utilizar algoritmos para añadir imágenes a la Wikipedia, pero que hay muchas trampas potenciales y formas en que esto puede salir mal, especialmente con los recién llegados.
 * Algoritmo
 * Los miembros de la comunidad parecían confiar en el algoritmo porque sólo se basa en las asociaciones codificadas en Wikidata por usuarios experimentados, y no en una especie de inteligencia artificial impredecible.
 * De las tres fuentes para el algoritmo (Wikidata P18, enlaces interwiki y categorías de Commons), la gente estuvo de acuerdo en que las categorías de Commons son las más débiles (y que Wikidata es la más fuerte). Esto se ha confirmado en nuestras pruebas, y es posible que excluyamos las categorías de Commons en futuras iteraciones.
 * Recibimos buenos consejos para excluir ciertos tipos de páginas de la función: desambiguaciones, listas, años, artículos buenos y destacados... También podríamos excluir las biografías de personas vivas.
 * También debemos excluir las imágenes que tengan una plantilla de borrado en Commons y que hayan sido eliminadas previamente de la página de Wikipedia.
 * Criterio del recién llegado
 * A los miembros de la comunidad les preocupaba en general que los recién llegados aplicaran un criterio pobre y dieran al algoritmo el beneficio de la duda. Sabemos, gracias a nuestros tests de usuario, que los recién llegados son capaces de aplicar el buen juicio, y creemos que un diseño adecuado lo fomentará.
 * En la discusión de la campaña de Páginas de Wikipedia que Quieren Fotos (WPWP), aprendimos que mientras muchos recién llegados pudieron mostrar buen juicio, algunos usuarios demasiado entusiastas pudieron hacer muchos emparejamientos malos rápidamente, causando mucho trabajo para los patrulleros. Es posible que queramos añadir algún tipo de validación para evitar que los usuarios añadan imágenes demasiado rápido, o que sigan añadiendo imágenes después de haber sido revertidas repetidamente.
 * La mayoría de los miembros de la comunidad afirmaron que la "relevancia" es más importante que la "calidad" a la hora de decidir si una imagen debe aparecer. En otras palabras, si la única foto de una persona es borrosa, suele ser mejor que no tener ninguna imagen.  Hay que explicar a los recién llegados esta norma mientras realizan la tarea.
 * Nuestra interfaz debe transmitir que los usuarios deben avanzar despacio y ser cuidadosos, en lugar de intentar hacer todos los emparejamientos que puedan.
 * Debemos enseñar a los usuarios que las imágenes deben ser instructivas, no meramente decorativas.
 * Interfaz de usuario
 * Varias personas propusieron que mostráramos a los usuarios varias imágenes candidatas para elegir, en lugar de sólo una. Así sería más probable que se añadieran imágenes buenas a los artículos.
 * Muchos miembros de la comunidad recomendaron que se permitiera a los recién llegados elegir áreas temáticas de interés (especialmente geográficas) para trabajar con los artículos. Si los recién llegados eligen áreas en las que tienen algún conocimiento, podrán hacer elecciones más acertadas.  Afortunadamente, esto formará parte automáticamente de cualquier característica que el equipo de Crecimiento construya, puesto que ya permitimos a los usuarios elegir entre 64 áreas temáticas al seleccionar las tareas de edición sugeridas.
 * Los miembros de la comunidad recomiendan que los recién llegados vean la mayor parte posible del contexto del artículo, en lugar de sólo una vista previa. Esto les ayudará a entender la relevancia de la tarea y a tener mucha información para usar en sus decisiones.
 * Ubicación en el artículo
 * Aprendimos sobre los infoboxes de Wikidata. Aprendimos que para las wikis que las usan, la preferencia es que las imágenes se añadan a Wikidata, en lugar de al artículo, para que puedan aparecer a través del infobox de Wikidata.  En este sentido, vamos a investigar cómo de comunes son estos infoboxes en varias wikis.
 * En general, parece que la regla de "colocar una imagen debajo de las plantillas y encima del contenido" en un artículo funcionará la mayoría de las veces.
 * Algunos miembros de la comunidad nos aconsejaron que incluso si la colocación en un artículo no es perfecta, otros usuarios corregirán encantados la colocación, ya que el trabajo difícil de encontrar la imagen correcta ya estará hecho.
 * Usuarios de habla no inglesa
 * Los miembros de la comunidad nos recordaron que algunos elementos de metadatos de Commons pueden ser ajenos al idioma, como los pies de foto y las declaraciones de representación. Hemos analizado cómo de común es esto en esta sección.
 * Hemos escuchado la sugerencia de que, aunque los usuarios no dominen el inglés, pueden utilizar los metadatos si saben leer los caracteres latinos. Esto se debe a que, para realizar muchas de las coincidencias, el usuario sólo busca el título del artículo en algún lugar de los metadatos de la imagen.
 * Alguien también propuso la idea de utilizar la traducción automática (por ejemplo, Google Translate) para traducir los metadatos al idioma local a efectos de esta función.
 * Leyendas
 * Los miembros de la comunidad (y los miembros del equipo de Crecimiento) son escépticos sobre la capacidad de los recién llegados para escribir leyendas adecuadas.
 * Recibimos consejos para mostrar a los usuarios ejemplos de subtítulos y directrices adaptadas al tipo de artículo que se subraya.

Plan para el test de usuario


Considerando las preguntas abiertas anteriores, además de las aportaciones de la comunidad, queremos generar alguna información cuantitativa y cualitativa que nos ayude a evaluar la viabilidad de crear una función de "añadir una imagen". Aunque hemos estado evaluando el algoritmo entre el personal y los wikimedistas, es importante ver cómo reaccionan los recién llegados a él, y ver cómo utilizan su juicio a la hora de decidir si una imagen pertenece a un artículo.

Para ello, vamos a realizar pruebas con usertesting.com, en las que las personas que son nuevas en la edición de Wikipedia puedan recorrer las posibles coincidencias de imágenes en un prototipo y responder "Sí", "No" o "No estoy seguro". Construimos un prototipo rápido para la prueba, respaldado con coincidencias reales del algoritmo actual. El prototipo sólo muestra una coincidencia tras otra, todas en un feed. Las imágenes se muestran junto con todos los metadatos relevantes de Commons:


 * Nombre del archivo
 * Tamaño
 * Fecha
 * Usuario/a
 * Descripción
 * Leyenda
 * Categorías
 * Etiquetas

Aunque es posible que el flujo de trabajo no sea así para los usuarios reales en el futuro, el prototipo se hizo para que los usuarios probadores pudieran revisar rápidamente muchas coincidencias potenciales, generando mucha información.

Para probar el prototipo interactivo, use este enlace. Tenga en cuenta que este prototipo es principalmente para ver las coincidencias del algoritmo - todavía no hemos pensado mucho en la experiencia real del usuario. En realidad, no crea ninguna edición. Contiene 60 coincidencias reales propuestas por el algoritmo.

Esto es lo que buscaremos en la prueba:


 * 1) ¿Pueden los participantes confirmar con certeza las coincidencias basándose en las sugerencias y los datos proporcionados?
 * 2) ¿Qué grado de precisión tienen los participantes a la hora de evaluar las sugerencias? ¿Creen que están haciendo un trabajo mejor o peor del que realmente hacen?
 * 3) ¿Qué opinan los participantes de la tarea de añadir imágenes a los artículos de esta manera? ¿Les parece fácil/difícil, interesante/aburrido, gratificante/irrelevante?
 * 4) ¿Qué información encuentran los participantes más valiosa para ayudarles a evaluar las coincidencias de imágenes y artículos?
 * 5) ¿Son los participantes capaces de escribir buenos pies de foto para las imágenes que consideran adecuadas utilizando los datos proporcionados?

Concepto A vs. B
Al pensar en el diseño de esta tarea, tenemos una cuestión similar a la que nos enfrentamos para "añadir un enlace" con respecto al Concepto A y al Concepto B. En el Concepto A, los usuarios completarían la edición en el artículo, mientras que en el Concepto B, harían muchas ediciones seguidas todas desde un feed. El Concepto A da al usuario más contexto para el artículo y la edición, mientras que el Concepto B prioriza la eficiencia.

En el prototipo interactivo anterior, utilizamos el Concepto B, en el que los usuarios avanzan a través de un feed de sugerencias. Lo hicimos así porque en nuestras pruebas de usuario queríamos ver muchos ejemplos de usuarios interactuando con las sugerencias. Ese es el tipo de diseño que podría funcionar mejor para una plataforma como la aplicación de Wikipedia para Android. Para el contexto del equipo de Crecimiento, estamos pensando más en la línea del Concepto A, en el que el usuario hace la edición "en el artículo". Esa es la dirección que elegimos para "añadir un enlace", y creemos que podría ser apropiada para "añadir una imagen" por las mismas razones.

Invidual vs. Muúltiple
Otra cuestión importante de diseño es si se debe mostrar al usuario una "única" imagen propuesta que coincida, o darle varias imágenes que coincidan para que elija. Si se ofrecen varias correspondencias, hay más posibilidades de que una de ellas sea buena. Pero también puede hacer que los usuarios piensen que deben elegir una de ellas, aunque ninguna sea buena. Además, será una experiencia más complicada de diseñar y construir, especialmente para los dispositivos móviles. Hemos hecho un simulacro de tres posibles flujos de trabajo:


 * Individual: En este diseño, el usuario sólo recibe una propuesta de imagen que coincide con el artículo, y sólo tiene que aceptarla o rechazarla. Es sencillo para el usuario.
 * Múltiple: este diseño muestra al usuario múltiples posibilidades de concordancia, y éste podría compararlas y elegir la mejor, o rechazarlas todas. Una preocupación sería que el usuario sintiera que debe añadir la mejor al artículo, aunque realmente no encaje.
 * Serie: este diseño ofrece múltiples sugerencias de imágenes, pero el usuario las observa de una en una, valora cada una y luego elige la mejor al final en el caso de haber indicado que más de una podría coincidir. Esto podría ayudar al usuario a centrarse en una imagen a la vez, pero añade un paso extra al final.



Tests de usuarios Diciembre 2020
Antecendentes

Durante diciembre de 2020, utilizamos usertesting.com para realizar 15 pruebas del interactivo móvil. El prototipo contenía sólo un diseño rudimentario, poco contexto o onboarding, y fue probado sólo en inglés con usuarios que tenían poca o ninguna experiencia previa en la edición de Wikipedia. Probamos deliberadamente un diseño rudimentario en las primeras fases del proceso para poder reunir muchos aprendizajes. Las principales cuestiones que queríamos abordar con esta prueba se referían a la "viabilidad" de la función en su conjunto, no a los detalles del diseño:


 * 1) ¿Pueden los participantes confirmar con seguridad las coincidencias basándose en las sugerencias y los datos proporcionados?
 * 2) ¿Qué grado de acierto tienen los participantes a la hora de evaluar las sugerencias? ¿Y cómo se compara la aptitud real con su capacidad percibida para evaluar las sugerencias?
 * 3) ¿Qué opinan los participantes de la tarea de añadir imágenes a los artículos de esta manera? ¿Les parece fácil/difícil, interesante/aburrido, gratificante/irrelevante?
 * 4) ¿Qué metadatos consideran los participantes más valiosos para ayudarles a evaluar las coincidencias de imágenes y artículos?
 * 5) ¿Son los participantes capaces de escribir buenos pies de foto para las imágenes que consideran adecuadas utilizando los datos proporcionados?

En el test, pedimos a los participantes que anotaran al menos 20 coincidencias entre artículos e imágenes mientras hablaban en voz alta. Cuando marcaban "sí", el prototipo les pedía que escribieran un pie de foto que acompañara a la imagen del artículo. En total, recogimos 399 anotaciones.

Resumen

Creemos que estas pruebas de usuario confirman que podríamos crear con éxito una función de "añadir una imagen", pero sólo funcionará si la diseñamos bien. Muchos de los probadores entendieron bien la tarea, se la tomaron en serio y tomaron buenas decisiones, lo que nos hace confiar en que es una idea que merece la pena llevar a cabo. Por otro lado, muchos otros usuarios estaban confundidos sobre el sentido de la tarea, no la evaluaron tan críticamente, y tomaron decisiones débiles -- pero para esos usuarios confusos, fue fácil para nosotros encontrar maneras de mejorar el diseño para darles el contexto apropiado y transmitir la importancia de la tarea.

Observaciones

''Para ver el conjunto de conclusiones, puedes consultar las diapositivas. Los puntos más importantes están escritos al pie de las diapositivas.''




 * La capacidad de comprensión general de la tarea de emparejar imágenes con artículos de Wikipedia fue razonablemente buena, dado el contexto mínimo proporcionado para la herramienta y el conocimiento limitado de Commons y la edición de Wikipedia. Hay oportunidades para aumentar la comprensión una vez que la herramienta se rediseñe en una UX de Wikipedia.
 * El patrón general que observamos fue el siguiente: un usuario consultaba el título de un artículo y las dos primeras frases, luego miraba la imagen para ver si podía coincidir (por ejemplo, este es un artículo sobre una iglesia y esta es una imagen de una iglesia). A continuación, buscaba el título del artículo en algún lugar de los metadatos de la imagen, ya sea en el nombre del archivo, la descripción, el pie de foto o las categorías.  Si lo encontraba, confirmaba la coincidencia.
 * Cada tarea de emparejamiento de imágenes podía ser realizada rápidamente por alguien no familiarizado con la edición. De media, se tardó 34 segundos en revisar una imagen.
 * Todos dijeron que estarían interesados en realizar dicha tarea, y la mayoría la calificó de fácil o muy fácil.
 * La calidad percibida de las imágenes y las sugerencias fue variada. Muchos participantes se centraron en la composición de la imagen y en otros factores estéticos, lo que afectó a su percepción de la precisión de las sugerencias.
 * Sólo unos pocos metadatos de imágenes de Commons eran fundamentales para la comparación de imágenes: nombre del archivo, descripción, pie de foto y categorías.
 * En ocasiones, muchos participantes trataban de relacionar incorrectamente una imagen con sus "propios" datos, en lugar de con el artículo (por ejemplo, "¿le parece correcto este nombre de archivo a la imagen?"). Deberían estudiarse cambios en el diseño y la jerarquía visual para centrarse mejor en el contexto del artículo para la imagen sugerida.
 * Las "rachas" de buenas coincidencias hicieron que algunos participantes fueran más conformistas a la hora de aceptar más imágenes: si muchas seguidas eran "Sí", dejaban de evaluarlas tan críticamente.
 * Los usuarios no hicieron un buen trabajo a la hora de añadir pies de foto. Con frecuencia escribían su explicación de por qué coincidían con la imagen, por ejemplo: "Esta es una foto de alta calidad de la persona que aparece en el artículo". Esto es algo que creemos que se puede mejorar con el diseño y la explicación para el usuario.

Métricas


 * Los miembros de nuestro equipo anotaron todas las coincidencias de imágenes que se mostraron a los usuarios en la prueba, y registramos las respuestas que dieron los usuarios. De este modo, elaboramos algunas estadísticas sobre la calidad del trabajo de los usuarios.
 * De las 399 sugerencias que encontraron los usuarios, pulsaron "Sí" 192 veces (48%).
 * De ellas, 33 no eran buenas coincidencias y podrían revertirse si se añadieran a los artículos en la realidad. Esto supone un 17%, y lo denominamos "tasa de reversión probable".

Para llevar a cabo


 * La "tasa de reversión probable" del 17% es una cifra realmente importante, y queremos que sea lo más baja posible. Por un lado, esta cifra es cercana o inferior a la tasa media de reversión de las ediciones de los recién llegados a Wikipedia (en inglés es del 36%, en árabe del 26%, en francés del 22% y en vietnamita del 11%). Por otra parte, las imágenes tienen mayor impacto y visibilidad que los pequeños cambios o las palabras en un artículo. Teniendo en cuenta el tipo de cambios que haríamos en el flujo de trabajo que probamos (que estaba optimizado para el volumen, no para la calidad), creemos que esta tasa de reversión bajaría considerablemente.
 * Creemos que esta tarea funcionaría mucho mejor en un flujo de trabajo que lleve al usuario al artículo completo, en lugar de mostrarle rápidamente una sugerencia tras otra en el feed. Al llevarlos al artículo completo, el usuario vería mucho más contexto para decidir si la imagen coincide y ver dónde iría en el artículo. Creemos que asimilarían la importancia de la tarea: que realmente van a añadir una imagen a un artículo de Wikipedia. En lugar de buscar la velocidad, creemos que el usuario sería más cuidadoso al añadir imágenes. Esta es la misma decisión a la que llegamos para "añadir un enlace" cuando decidimos construir el flujo de trabajo "Concepto A".
 * También creemos que los resultados mejorarán con la incorporación, la explicación y los ejemplos. Esto es especialmente cierto en el caso de los pies de foto. Creemos que si mostramos a los usuarios algunos ejemplos de buenos pies de foto, se darán cuenta de cómo escribirlos adecuadamente. También podríamos animarles a utilizar la descripción o el pie de foto de Commons como punto de partida.
 * Nuestro equipo ha estado debatiendo últimamente si sería mejor adoptar un marco de "decisión colaborativa", en el que una imagen no se añadiría a un artículo hasta que "dos" usuarios la confirmen, en lugar de uno solo. Esto aumentaría la precisión, pero plantea cuestiones sobre si este flujo de trabajo se ajusta a los valores de Wikipedia, y sobre qué usuario recibe el crédito por la edición.

Metadatos
Las pruebas con usuarios nos mostraron que los metadatos de las imágenes de Commons (por ejemplo, el nombre del archivo, la descripción, el pie de foto, etc.) son fundamentales para que un usuario pueda establecer una correspondencia con garantías. Por ejemplo, aunque el usuario puede ver que el artículo trata de una iglesia y que la foto es de una iglesia, los metadatos le permiten saber si es "la" iglesia de la que se habla en el artículo. En las pruebas de usuarios, vimos que estos elementos de metadatos eran los más importantes: nombre del archivo, descripción, pie de foto, categorías. Los elementos que no eran útiles eran el tamaño, la fecha de subida y el nombre del usuario que la realizó.

Dado que los metadatos son una parte fundamental a la hora de tomar una decisión firme, hemos pensado si los usuarios necesitarán tener metadatos en su propio idioma para poder realizar esta tarea, especialmente teniendo en cuenta que la mayoría de los metadatos de Commons están en inglés. Para 22 wikis, observamos el porcentaje de las coincidencias de imágenes del algoritmo que tienen elementos de metadatos en el idioma local. En otras palabras, para las imágenes que pueden coincidir con artículos no ilustrados en la Wikipedia árabe, ¿cuántas de ellas tienen descripciones, pies de foto y representaciones en árabe? La tabla se encuentra debajo de estos puntos de resumen:


 * En general, la cobertura de los metadatos en el idioma local es muy baja. El inglés es la excepción.
 * En todas las wikis, excepto en la inglesa, menos del 7% de las coincidencias de imágenes tienen descripciones en el idioma local (la inglesa está en el 52%).
 * En todas las wikis, excepto en la inglesa, menos del 0,5% de las coincidencias de imágenes tienen subtítulos en el idioma local (la inglesa está en el 3,6%).
 * En el caso de los enunciados, las wikis oscilan entre el 3% (serbia) y el 10% (sueca) de cobertura para sus coincidencias de imágenes.
 * La escasa cobertura de las descripciones y subtítulos en el idioma local significa que en la mayoría de las wikis hay muy pocas imágenes que podamos sugerir a los usuarios con metadatos en el idioma local. Algunas de las wikis mayores tienen unos cuantos miles de candidatas con descripciones en el idioma local. Pero ninguna Wikipedia que no sea la inglesa tiene más de 1.000 candidatos con subtítulos en el idioma local.
 * Aunque la cobertura de "muestras" es mayor, esperamos que las declaraciones de "muestras" no contengan normalmente suficientes detalles para hacer una coincidencia positiva. Por ejemplo, es mucho más probable que una frase de muestra aplicada a una foto de la Iglesia de San Pablo en Chicago sea "iglesia", que "Iglesia de San Pablo en Chicago".
 * Es posible que queramos dar prioridad a las sugerencias de imágenes con metadatos en el idioma local en nuestras interfaces de usuario, pero hasta que se construyan otras características para aumentar la cobertura, depender de los idiomas locales no es una opción viable para estas características en las wikis que no están en inglés.

Dado que los metadatos en el idioma local tienen poca cobertura, nuestra idea actual es ofrecer la tarea de concordancia de imágenes sólo a aquellos usuarios que sepan leer en inglés, lo que podríamos plantear al usuario como una pregunta rápida antes de comenzar la tarea. Lamentablemente, esto limita el número de usuarios que pueden participar. Es una situación similar a la de la herramienta Traducción de contenidos, en el sentido de que los usuarios necesitan conocer el idioma de la wiki de origen y de la wiki de destino para poder mover contenidos de una wiki a otra. También creemos que habrá un número suficiente de este tipo de usuarios basándonos en los resultados de la encuesta de bienvenida del equipo de Crecimiento, que pregunta a los recién llegados qué idiomas conocen. Dependiendo de la wiki, entre el 20% y el 50% de los recién llegados seleccionan el inglés.

Android MVP
Visita esta página para conocer los detalles sobre el MVP de Android.

Antecedentes
Después de muchas discusiones de la comunidad, numerosas discusiones internas, y los resultados de las pruebas de usuarios de arriba, creemos que esta idea de "añadir una imagen" tiene suficiente potencial para seguir adelante. Los miembros de la comunidad han sido generalmente positivos, pero también cautelosos -- también sabemos que todavía hay muchas preocupaciones y razones por las que la idea podría no funcionar como se espera. El siguiente paso que queremos dar para saber más es construir un "2|producto mínimo viable" (MVP) para la aplicación Android de Wikipedia. Lo más importante de este MVP es que no guardará ninguna edición en Wikipedia. Más bien, sólo se utilizará para recopilar datos, mejorar nuestro algoritmo y mejorar nuestro diseño.

La aplicación de Android es donde se originaron las "ediciones sugeridas", y ese equipo tiene un marco para construir nuevos tipos de tareas fácilmente. Estas son las partes principales:


 * La aplicación tendrá un nuevo tipo de tarea que los usuarios saben que es sólo para ayudarnos a mejorar nuestros algoritmos y diseños.
 * Mostrará a los usuarios las coincidencias de las imágenes, y ellos seleccionarán "Sí", "No" u "Omitir".
 * Registraremos los datos de sus selecciones para mejorar el algoritmo, determinar cómo mejorar la interfaz y pensar en lo que podría ser apropiado para que el equipo de Crecimiento desarrolle la plataforma web más adelante.
 * No se editará la Wikipedia, por lo que se trata de un proyecto de muy bajo riesgo.

Resultados
El equipo de Android lanzó la aplicación en mayo de 2021 y, a lo largo de varias semanas, miles de usuarios evaluaron decenas de miles de coincidencias de imágenes del algoritmo de comparación de imágenes. Los datos resultantes permitieron al equipo de Crecimiento decidir seguir con la Iteración 1 de la tarea de "añadir una imagen". Al examinar los datos, tratamos de responder a dos preguntas importantes en torno a la "participación" y la "eficacia".

Compromiso: ¿a los usuarios de todos los idiomas les gusta esta tarea y quieren hacerla?
 * De media, los usuarios del MVP de Android hicieron unas 11 anotaciones cada uno. Aunque esto es menos que las descripciones de imágenes y las traducciones de descripciones, es mayor que los otros cuatro tipos de tareas de Android.
 * Las ediciones de coincidencia de imágenes mostraron una tasa de retención sustancialmente menor que otros tipos de ediciones sugeridas por Android, pero nos preocupa que no sea posible calcular una comparación de manzanas con manzanas. Además, pensamos que el hecho de que las ediciones de este MVP no cambien realmente las wikis conduciría a una menor retención, porque los usuarios estarían menos motivados para volver y hacer más cosas.
 * Con respecto al idioma, se recogieron datos de usuarios de la Wikipedia en inglés, así como de usuarios que utilizan exclusivamente la Wikipedia en otros idiomas, incluyendo un gran número de evaluaciones de las Wikipedias en alemán, turco, francés, portugués y español. Esperábamos que los usuarios ingleses y no ingleses tuvieran experiencias bastante diferentes, porque la mayoría de los metadatos de las imágenes en Commons están en inglés. Sin embargo, las métricas fueron notablemente similares en los dos grupos, incluyendo el número de tareas completadas, el tiempo dedicado a la tarea, la retención y el juicio. Esto es un buen presagio de que esta tarea se puede utilizar en todas las wikis, aunque es probable que muchos de los usuarios de Android que no están en inglés sean realmente bilingües.

Eficacia: ¿las ediciones resultantes serán de suficiente calidad?
 * El 80% de las correspondencias para las que los recién llegados dijeron "sí" son realmente buenas correspondencias según los expertos. Esto supone una mejora de unos 5 puntos porcentuales respecto al algoritmo por sí solo.
 * Esta cifra se eleva al 82-83% si eliminamos a los recién llegados, que tienen un tiempo medio de evaluación muy bajo.
 * Los expertos tienden a estar de acuerdo entre sí sólo un 85% de las veces.
 * Dado que la precisión de los recién llegados aumenta cuando se eliminan ciertos tipos de recién llegados (aquellos que evalúan demasiado rápido o que aceptan demasiadas sugerencias), creemos que las "puertas de calidad" automatizadas podrían aumentar el rendimiento de los recién llegados hasta niveles aceptables para las comunidades.

Vea los resultados completos aquí.

Ingeniería
Esta sección contiene enlaces sobre cómo seguir los aspectos técnicos de este proyecto:


 * Trabajo en la "prueba de concepto" de la API por parte del equipo de ingeniería de la plataforma, construida para respaldar el MVP de Android
 * Tareas de Phabricator en torno al MVP del equipo de Android
 * Tareas de Phabricator y evaluaciones del algoritmo de comparación de imágenes

Iteración 1
En julio de 2021, el equipo de Crecimiento decidió seguir adelante con el desarrollo de una primera iteración de una tarea de "añadir una imagen" para la web. Esta fue una decisión difícil, debido a las muchas preguntas abiertas y a los riesgos en torno a animar a los recién llegados a añadir imágenes a los artículos de Wikipedia. Pero después de pasar por un 1|año de validación de la idea, y de ver las discusiones de la comunidad, las evaluaciones, los tests y las pruebas de concepto resultantes en torno a esta idea, decidimos construir una primera iteración para poder seguir aprendiendo. Estas son las principales conclusiones de la fase de validación de la idea que nos llevaron a seguir adelante:


 * Apoyo moderado de la comunidad: los miembros de la comunidad son cautelosamente optimistas sobre esta tarea, y están de acuerdo en que sería valiosa, pero señalan muchos riesgos y obstáculos que creemos que podemos abordar con un buen diseño.
 * Algoritmo preciso: el algoritmo de coincidencia de imágenes ha demostrado ser un 65-80% preciso a través de múltiples pruebas diferentes, y hemos sido capaces de refinarlo con el tiempo.
 * Pruebas de usuarios: muchos recién llegados que experimentaron los prototipos encontraron la tarea divertida y atractiva.
 * Android MVP: los resultados del MVP de Android mostraron que los recién llegados en general aplicaron un buen criterio a las sugerencias, pero lo más importante es que nos dieron pistas sobre cómo mejorar sus resultados en nuestros diseños. Los resultados también indicaron que la tarea podría funcionar bien en todos los idiomas.
 * Conclusiones generales: al haber tropezado con muchos obstáculos en nuestras diversas etapas de validación, podremos evitarlos en nuestros próximos diseños. Este trabajo de fondo nos ha dado muchas ideas sobre cómo guiar a los recién llegados hacia el buen juicio y cómo evitar ediciones problemáticas.

Hipótesis
No estamos seguros de que esta tarea vaya a funcionar bien, por eso planeamos construirla en pequeñas iteraciones, aprendiendo por el camino. Creemos que podemos hacer un buen intento utilizando lo que hemos aprendido hasta ahora para construir una primera iteración sencilla. Una forma de pensar en lo que estamos haciendo con nuestras iteraciones es la prueba de hipótesis. A continuación se presentan cinco hipótesis optimistas que tenemos sobre la tarea "añadir una imagen". Nuestro objetivo en la Iteración 1 será ver si estas hipótesis son correctas.

Paradigma: el paradigma de diseño que construimos para "la tarea de añadir un enlace estructurado" se extenderá a las imágenes.
 * 1) Leyendas: los usuarios pueden escribir leyendas satisfactorias. Esta es nuestra mayor pregunta abierta, ya que las imágenes que se colocan en los artículos de Wikipedia generalmente requieren pies de foto, pero el MVP de Android no probó la capacidad de los novatos para escribirlos bien.
 * 2) Eficacia: los recién llegados tendrán el suficiente criterio para que sus ediciones sean aceptadas por las comunidades.
 * 3) Engagement: a los usuarios les gusta hacer esta tarea en el móvil, hacer muchas y volver para hacer más.
 * 4) Idiomas: los usuarios que no sepan inglés podrán realizar esta tarea. Se trata de una cuestión importante, ya que la mayoría de los metadatos de Commons están en inglés, y es fundamental que los usuarios lean el nombre del archivo, la descripción y el pie de foto de Commons para confirmar con seguridad las coincidencias.

Alcance
Dado que nuestro principal objetivo con la Iteración 1 es el aprendizaje, queremos ofrecer una experiencia a los usuarios lo antes posible. Esto significa que queremos limitar el alcance de lo que construimos para poder liberarlo rápidamente. A continuación se presentan las limitaciones de alcance más importantes que creemos que debemos imponer a la Iteración 1.


 * Sólo para móviles: mientras que muchos wikimedistas experimentados hacen la mayor parte del trabajo de la wiki desde su ordenador/computadora de sobremesa/portátil, los recién llegados que se esfuerzan por contribuir a la Wikipedia utilizan mayoritariamente dispositivos móviles, y son la audiencia más importante para el trabajo del equipo de Crecimiento. Si construimos la Iteración 1 sólo para móviles, nos concentraremos en ese público y ahorraremos el tiempo que nos llevaría diseñar y construir adicionalmente el mismo flujo de trabajo para ordenadores/computadoras de sobremesa/portátiles.
 * Sugerencias estáticas: en lugar de construir un servicio backend para ejecutar y actualizar continuamente las coincidencias de imágenes disponibles utilizando el algoritmo de coincidencia de imágenes, ejecutaremos el algoritmo una vez y utilizaremos el conjunto estático de sugerencias para la Iteración 1. Aunque esto no permitirá disponer de las imágenes más recientes y los datos más actuales, creemos que será suficiente para nuestro aprendizaje.
 * Paradigma de añadir un enlace: nuestro diseño seguirá generalmente los mismos patrones que el diseño de nuestra tarea estructurada anterior, "añadir un enlace".
 * Artículos sin ilustraciones: limitaremos nuestras sugerencias sólo a los artículos que no tengan ninguna ilustración, en lugar de incluir artículos que ya tengan algunas, pero que podrían necesitar más. Esto significará que nuestro flujo de trabajo no necesitará incluir pasos para que el recién llegado elija en qué parte del artículo colocar la imagen. Dado que será la única imagen, se puede asumir que es la imagen principal en la parte superior del artículo.
 * Sin infoboxes: limitaremos nuestras sugerencias sólo a los artículos que no tengan infoboxes. Esto se debe a que si un artículo no ilustrado tiene una infobox, su primera imagen debería colocarse normalmente en la infobox. Pero es un reto técnico importante asegurarse de que podemos identificar los campos correctos de imagen y pie de foto en todos los infoboxes en muchos idiomas. Esto también evita los artículos que tienen infoboxes de Wikidata.
 * Una sola imagen: aunque el algoritmo de comparación de imágenes puede proponer varias imágenes candidatas para un solo artículo no ilustrado, limitaremos la Iteración 1 a proponer sólo la candidata de mayor confianza. Esto hará que la experiencia sea más sencilla para el recién llegado, y que el diseño y el esfuerzo de ingeniería sean más sencillos para el equipo.
 * Puertas de calidad: creemos que deberíamos incluir algún tipo de mecanismo automático para evitar que un usuario haga un gran número de ediciones malas en poco tiempo. Las ideas en torno a esto incluyen (a) limitar a los usuarios a un cierto número de ediciones de "añadir una imagen" por día, (b) dar a los usuarios instrucciones adicionales si invierten muy poco tiempo con cada sugerencia, (c) dar a los usuarios instrucciones adicionales si parecen estar aceptando demasiadas imágenes. Esta idea se inspiró en la experiencia de Wikipedia en inglés 2021 con la campaña Páginas de Wikipedia que quieren fotos.
 * Wikis piloto: al igual que con todos los nuevos desarrollos de Crecimiento, primero vamos a implementar sólo en nuestras cuatro wikis piloto, que son las Wikipedias árabe, vietnamita, bengalí y checa. Se trata de comunidades que siguen de cerca el trabajo de Growth y son conscientes de que forman parte de experimentos. El equipo de Crecimiento emplea a embajadores de la comunidad para ayudarnos a mantener una correspondencia rápida con esas comunidades. Es posible que el año que viene añadamos las Wikipedias en español y portugués a la lista.

Nos interesa conocer la opinión de los miembros de la comunidad sobre si estas opciones de alcance son buenas, o si alguna parece que limitaría mucho nuestros aprendizajes en la Iteración 1.

Mockups y prototipos
Basándonos en los diseños de nuestras pruebas de usuario anteriores y en el MVP de Android, estamos considerando múltiples conceptos de diseño para la Iteración 1. Para cada una de las cinco partes del flujo de usuarios, tenemos dos alternativas. Probaremos ambas para obtener información de los recién llegados. Nuestras pruebas de usuario se llevarán a cabo en inglés y en español: es la primera vez que nuestro equipo realiza pruebas en un idioma distinto del inglés. También esperamos que los miembros de la comunidad analicen los diseños y aporten sus opiniones en la página de discusión.

Prototipos para los test de usuarios

La forma más fácil de experimentar lo que estamos planteando construir es a través de los prototipos interactivos. Hemos construido prototipos para los diseños "Concepto A" y "Concepto B", y están disponibles tanto en inglés como en español. No se trata de un software wiki real, sino de una simulación del mismo. Esto significa que no se guardan las ediciones, y que no todos los botones e interacciones funcionan, pero los más importantes relacionados con el proyecto "añadir una imagen" "sí" funcionan.


 * Concepto A (inglés)
 * Concepto B (inglés)
 * Concepto A (español)
 * Concepto B (español)

Mockups para test de usuarios

A continuación se muestran imágenes estáticas de las maquetas que vamos a utilizar para las pruebas de usuario en agosto de 2021. Los miembros de la comunidad pueden explorar el archivo Figma del diseñador del equipo de crecimiento, que contiene las maquetas que aparecen abajo en la parte inferior derecha del cuadro, así como las diversas piezas de referencia y las notas que condujeron a ellas.

Feed

Estos diseños se refieren a la primera parte del flujo de trabajo, en la que el usuario elige un artículo para trabajar desde el feed de ediciones sugeridas. Queremos que la presentación sea atractiva, pero sin confundir al usuario.

Diseños finales de la Iteración 1

Based on the user test findings above, we created the set of designs that we are implementing for Iteration 1. The best way to explore those designs is here in the Figma file, which always contains the latest version.

Leading indicators
Whenever we deploy new features, we define a set of "leading indicators" that we will keep track of during the early stages of the experiment. These help us quickly identify if the feature is generally behaving as expected and allow us to notice if it is causing any damage to the wikis. Each leading indicator comes with a plan of action in case the defined threshold is reached, so that the team knows what to do.

We collected data on usage of "add an image" from deployment on November 29, 2021 until December 14, 2021. "Add an image" has only been made available on the mobile website, and is given to a random 50% of registrations on that platform (excluding our 20% overall control group). We therefore focus on mobile users registered after deployment. This dataset excluded known test accounts, and does not contain data from users who block event logging (e.g. through their ad blocker).

Overall: The most notable thing about the leading indicator data is how few edits have been completed so far: only 89 edits over the first two weeks. Over the first two weeks of "add a link", over 1,000 edits were made. That feature was deployed to both desktop and mobile users, but that alone is not enough to make up the difference. The leading indicators below give some clues. For instance, task completion rate is notably low. We also notice that people do not do many of these tasks in a row, whereas with "add a link", users do dozens in a row. This is a prime area for future investigation.

Revert rate: We use edit tags to identify edits and reverts, and reverts have to be done within 48 hours of the edit. The latter is in line with common practices for reverts.

The "add an image" revert rate is comparable to the copyedit revert rate, and it’s significantly higher than "add a link" (using a test of proportions). Because "add an image" has a comparable revert rate to unstructured tasks, the threshold described in the leading indicator table is not met, and we do not have cause for alarm. That said, we are still looking into why reverts are occurring in order to make improvements. One issue we've noticed so far is a large number of users saving edits from outside the "add an image" workflow. They can do this by toggling to the visual editor, but it is happening so much more often than for "add a link" that we think there s something confusing about the "caption" step that is causing users to wander outside of it.

Rejection rate: We define an edit “session” as reaching the edit summary dialogue or the skip dialogue, at which point we count whether the recommended image was accepted, rejected, or skipped. Users can reach this dialogue multiple times, because we think that choosing to go back and review links again is a reasonable choice.

The threshold in the leading indicator table was a rejection rate of 40%, and this threshold has not been met. This means that users are rejecting suggestions at about the same rate as we expected, and we don't have reason to believe the algorithm is underperforming.

Over-acceptance rate: We reuse the concept of an "edit session" from the rejection rate analysis, and count the number of users who only have sessions where they accepted all links. In order to understand whether these users make many edits, we measure this for all users as well as for those with five or more edit sessions. In the table below, the "N total" column shows the total number of users with that number of edit sessions, and "N accepted all" the number of users who only have edit sessions where they accepted all suggested links.

It is clear that over-acceptance is not an issue in this dataset, because there are no users who have 5 or more completed image edits, and for those who have more than one, 38% of the users accepted all their suggestions. This is in the expected range, given that the algorithm is expected usually to make good suggestions.

Task completion rate: We define "starting a task" as having an impression of "machine suggestions mode". In other words, the user is loading the editor with an "add an image" task. Completing a task is defined as clicking to save the edit, or confirming that you skipped the suggested image.

The threshold defined in the leading indicator table is "lower than 55%", and this threshold has been met. This means we are concerned about why users do not make their way through the whole workflow, and we want to understand where they get stuck or drop out.