Crecimiento/Primer día personalizado/Tareas estructuradas/Añadir una imagen

This page is a translated version of the page Growth/Personalized first day/Structured tasks/Add an image and the translation is 75% complete.
Outdated translations are marked like this.

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.

"Añadir una imagen" funcionalidad para móvil/celular

Esta página contiene los principales elementos, diseños, preguntas abiertas y decisiones.

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: Iteración 1 desplegada al 40% de cuentas móviles en las wikis árabe, checa y bengalí.
  • 2021-12-22: principales indicadores publicados
  • 2022-01-28: versión de escritorio desplegada para el 40% de las nuevas cuentas en las Wikipedias árabe, checa y bengalí.
  • 2022-02-16: Los recién llegados a la Wikipedia en español empiezan a recibir "añadir una imagen"
  • 2022-03-22: Los recién llegados a la Wikipedia en portugués, farsi, francés y turca empiezan a recibir "añadir una imagen"
  • 2023-02-07: Evaluación completa de las sugerencias de imágenes para secciones (T316151)
  • 2023-10-16: Image Recommendations added to the Android Wikipedia app
  • 2024-04-11: Publish "Add an image" Experiment Analysis
  • Siguiente: Release "Add an image" to more Wikipedias


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 piensa que la introducción de estos nuevos tipos de flujos de edición permitirá que más personas nuevas comience a participar en Wikipedia, algunas de las cuales aprenderán a hacer ediciones más sustanciales y se involucrarán con sus comunidades. Después de discutir la idea de las tareas estructuradas con las comunidades, decidimos crear 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.

Proyectos relacionados

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.

¿Por qué imágenes?

Ampliar para leer la sección "¿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"

 
En la campaña Páginas de Wikipedia que quieren fotos, 600 usuarios añadieron imágenes a 85.000 páginas.

La campaña Wikipedia Pages Wanting Photos (WPWP) fue un éxito sorprendente: 600 personas añadieron imágenes a 85.000 páginas. Lo hicieron con la ayuda de un par de herramientas comunitarias que identificaban las páginas que no tenían imágenes y que 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.

Ampliar para leer la sección "Validación de ideas"

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:

Clasificación Explicación Ejemplo
2 Excelente complemento para el artículo, que ilustra el tema que titula el artículo. El artículo es "Mariposa" y es una imagen de una mariposa.
1 Buena coincidencia, pero difícil de confirmar para el artículo a menos que el usuario tenga algún contexto, y necesitaría un buen pie de foto. El artículo es "Mariposa" y es una imagen de un importante científico que estudia las mariposas.
0 No encaja en absoluto con el artículo. El artículo es "Mariposa" y la imagen es de un automóvil.
-1 La imagen es correcta para el tema, pero no se ajusta a la cultura local. El artículo es "Mariposa" y la imagen es una mariposa específica de una parte del mundo que tiene mariposas diferentes a las locales.
-2 Imagen engañosa que un recién llegado podría pensar por error que es correcta. El artículo es "Mariposa" y la imagen es de una polilla.
-3 La página no debe tener una imagen. Páginas de desambiguación, listas o artículos de "nombre de pila".

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.
Fuente Precisión (buena) Precisión (buena+aceptable) Cuota de cobertura
Wikidata 85% 93% 7%
Cross-wiki 56% 76% 80%
Categoría de Commons 51% 76% 13%
All 63% 80% 100%

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.
Wiki Total de artículos Artículos sin imágenes Porcentaje de artículos sin imágenes Con imagen potencial Porcentaje de artículos sin imágenes con imagen potencial
enwiki 6 199 587 2 932 613 47% 154 508 5%
trwiki 382 825 151 620 40% 35 561 23%
bnwiki 99 172 33 642 34% 6921 21%
frwiki 2 273 610 952 994 42% 94 594 10%
ruwiki 1 680 385 584 290 35% 60 415 10%
fawiki 755 709 304 253 40% 55 382 18%
arwiki 1 080 564 581 710 54% 59 551 10%
dewiki 2 506 229 1 190 517 48% 110 771 9%
ptwiki 1 048 255 388 605 37% 79 483 20%
hewiki 282 232 73 261 26% 14 453 20%
cswiki 467 573 182 177 39% 37 300 20%
kowiki 526 990 274 338 52% 48 417 18%
plwiki 1 441 429 560 334 39% 71 456 13%
ukwiki 1 058 563 365 209 35% 51 154 14%
svwiki 3 514 965 1 686 664 48% 91 337 5%
huwiki 479 215 170 936 36% 26 559 16%
euwiki 364 458 105 412 29% 21 481 20%
hywiki 278 487 96 729 35% 13 531 14%
arzwiki 1 171 440 759 418 65% 32 956 4%
srwiki 640 678 126 102 20% 27 326 22%
viwiki 1 259 538 867 672 69% 83 785 10%
cebwiki 5 377 763 1 357 405 25% 61 839 5%

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 y discusión

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

 
Captura de pantalla del prototipo de un posible flujo de trabajo de comparación de imágenes, utilizado en las pruebas de usuario. El usuario puede desplazarse hacia abajo para ver más metadatos sobre la imagen de Commons.

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?

Diseño

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.
 
Individual: en este diseño, el usuario sólo recibe una sugerencia de imagen que coincide con el artículo, y sólo tiene que aceptarla o rechazarla.
 
Múltiple: este diseño muestra al usuario múltiples posibilidades de coincidencia, y éste puede compararlas y elegir la mejor, o rechazarlas todas.
 
Serie: este diseño ofrece múltiples sugerencias de imágenes, pero el usuario las examina de una en una, emite una valoración y, al final, elige la mejor si ha indicado que más de una podría coincidir.

Tests de usuarios Diciembre 2020

Antecendentes

Durante diciembre de 2020, utilizamos usertesting.com para realizar 15 pruebas del prototipo 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.

 
Diapositivas con los resultados completos de las pruebas de usuarios
  • 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.
Wiki Descripción en el idioma local Leyenda en el idioma local Muestra
enwiki 51.71% 3.65% 6.20%
trwiki 1.91% 1.32% 4.33%
bnwiki 0.51% 1.08% 5.74%
frwiki 5.95% 0.66% 8.52%
ruwiki 4.05% 0.61% 6.73%
fawiki 0.58% 0.59% 4.06%
arwiki 0.97% 0.59% 7.00%
dewiki 6.11% 0.49% 5.16%
ptwiki 1.38% 0.34% 4.27%
hewiki 1.20% 0.30% 6.18%
cswiki 1.82% 0.23% 5.71%
kowiki 0.97% 0.19% 4.80%
plwiki 1.82% 0.17% 5.93%
ukwiki 1.04% 0.12% 5.95%
svwiki 0.90% 0.07% 10.10%
huwiki 2.28% 0.03% 5.96%
euwiki 0.27% 0.03% 6.20%
hywiki 0.69% 0.03% 5.39%
arzwiki 0.02% 0.01% 6.84%
srwiki 0.36% 0.01% 3.46%
viwiki 0.08% 0.00% 6.63%
cebwiki 0.00% 0.00% 9.93%

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 "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:

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 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.

  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.

Paradigma: el paradigma de diseño que construimos para "la tarea de añadir un enlace estructurado" se extenderá a las imágenes.

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.

Diseño

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.

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.

Onboarding

Estos diseños se refieren a lo que el usuario ve después de abrir su primera tarea, con la intención de explicar en qué consiste la tarea y cómo hacer un buen trabajo. Queremos que el usuario entienda que añadir una imagen es una edición importante que hay que considerar seriamente. Hay que tener en cuenta que este texto exacto no se ha diseñado con cuidado todavía - más bien, estamos pensando ahora en la experiencia a través de la cual entregamos este contenido.

Añadiendo la imagen

Estos diseños se refieren a la parte del flujo de trabajo en la que el usuario ve la imagen sugerida, ve sus metadatos de Commons y decide si la añade al artículo. Sabemos por las pruebas de usuarios que es importante que lean el título de la imagen, la descripción de Commons y el pie de foto de Commons para tomar esta decisión correctamente. Esta es la parte más desafiante del diseño: hacer que toda esa información esté disponible en la pantalla del móvil.

Leyenda y publicación

Estos diseños se refieren a la parte del flujo de trabajo después de que el usuario ha decidido añadir una imagen al artículo, y ahora está escribiendo un pie de foto para acompañarla. Esta puede ser la parte más difícil para los recién llegados, y todavía estamos pensando en cómo ayudarles a entender qué tipo de pie de foto es apropiado.

Rechazo

Cuando un usuario rechaza una sugerencia, queremos recopilar datos sobre la razón por la que la coincidencia fue errónea, para poder mejorar el algoritmo. Esta es también una oportunidad para recordar continuamente al usuario los criterios de evaluación que debe utilizar al evaluar las imágenes.

Resultados de las pruebas de usuarios septiembre de 2021

In August 2021, we ran 32 user tests amongst people who were new to Wikipedia editing, using respondents from usertesting.com. Half the respondents walked through Concept A and half through Concept B. In order to represent more diverse perspectives, this was the first time that the Growth team ran user tests outside of English: 11 de las personas encuestadas realizaron el test en español, todas ellas fuera de Estados Unidos. This will help us make sure we're building a feature that is valuable and understandable for populations around the world.

Our goals for the testing were to identify which parts of the design concepts worked best, and to surface any other potential improvements. These are our main findings and changes to the designs we plan to make.

  • Findings
    • Concept B clearly performed better for participants in both English and Spanish tests, particularly:
      • Better understanding of the task. In Concept A, users sometimes thought the image was already in the article, because of its preview on the suggested edit card and the preview in the article.
      • More careful engagement and consideration of article contents and image metadata when evaluating image suitability to an article. We suspect this is because the article and metadata areas were clearly separated.
      • Greater use of image details and article contents during caption composition. The Concept B caption experience shows the full article text.
    • Other notes
      • Most people misunderstood the task initially as uploading images when they opened the Suggested edits module, regardless of design. But expectation about self-sourcing images was immediately corrected for almost all participants as soon as they opened the task, and overall, Design B evoked better task comprehension and successful image evaluation than Design A.
      • Newcomers would benefit from more user education around Commons and use of images on Wikipedia articles in their understanding of the broader editing ecosystem of Wikipedia and its sister projects.
      • Users understood the purpose of the caption, and understood that it would be displayed with the image in the Wikipedia article.
      • Spanish participants were far more interwiki-attuned than English participants. Potentially explore ways to better cater to multilingual/cross-wiki users.
      • Spanish participants needed to translate Commons metadata to themselves in order to write good captions in Spanish.
      • The current task requires several different skills, such as image evaluation, caption writing, and translation (for reading Commons metadata from a non-English Wikipedia). There may be benefits and opportunities for separating out this task into multiple tasks in future so that users don't have to have all the skills in order to complete the task.
  • Cambios
    • Do not show a preview of the suggested image on the card in the suggested edits feed.
    • The onboarding tooltips worked well to help users understand the task. But they could be overwhelming or cluttering for smaller screens. Though we prefer to implement tooltips, we have decided to implement fullscreen overlays for onboarding in Iteration 1, because tooltips will take a substantially longer time to engineer well. We may implement tooltips in a future iteration.
    • Image and image metadata need to be next to each other -- when they are in separate parts of the screen, users become confused.
    • Because it is very important that users consider image metadata when making their decision and writing the caption, we need to increase the visibility of the metadata with clearer calls to read it.
    • Include simple validation on the free-text caption, such as enforcing a minimum length for captions, or not allowing the filename to be part of the caption.
    • Provide samples of good and bad captions in the explanation for the caption step.
    • When users reject a suggestion and give the reason for the rejection, some of the reasons should not remove the suggestion from the queue, e.g. "I do not know this topic". Perhaps another user will be able to confidently make the match.
  • Example captions: below are three image/article pairings used in the test and the actual captions written by user testers. This gives us a sense of the sorts of captions we can expect from newcomers. They all seem to be generally on the right track, though they range from more like "alt text" to more like captions. There are also a couple that miss the mark.

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.

Measurement

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.

Indicator Plan de acción
Revert rate This suggests that the community finds the "add an image" edits to be unconstructive. If the revert rate for "add an image" is substantially higher than that of unstructured tasks, we will analyze the reverts in order to understand what causes this increase, then adjust the task in order to reduce the likelihood of edits being reverted.
User rejection rate This can indicate that we are suggesting a lot of images that are not good matches. If the rejection rate is above 40%, we will QA the image suggestion algorithm and adjust thresholds or make changes to improve the quality of the recommendations.
Over-acceptance rate This might indicate that some users aren't actually applying judgment to their tasks, meaning we might want to implement different quality gates. (What percentage of users who have a complete session have never rejected or skipped an image? What percentage of users who have five or more complete sessions have never rejected or skipped an image? How many sessions across all users contained only acceptances?)
Task completion rate This might indicate that there’s an issue with the editing workflow. If the proportion of users who start the "add an image" task and complete it is lower than 55% (completion rate for "add a link"), we investigate where in the workflow users leave and deploy design changes to enable them to continue.

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", almost 300 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.

Tasa de reversiones: 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.

Tipo de edición N ediciones N reversiones Tasa de reversión
Añadir una imagen 69 13 18,8%
Añadir un enlace 209 4 1,9%
Revisión 93 19 20,4%

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 is something confusing about the "caption" step that is causing users to wander outside of it.

Tasa de rechazo: 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 an image or edit the caption is a reasonable choice.

N aceptadas % N rechazadas % N saltadas % N total
53 41,7 38 29,9 36 28,3 127

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 the image. In order to understand whether these users make many edits, we measure this for all users as well as for those with multiple edit sessions and 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 images.

Ediciones N total N aceptadas en total %
≥1 edición 97 34 35,1
≥2 edits 21 8 38,1
≥5 ediciones 0 0 0,0

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.

N Started a Task N Completed 1+ Tasks %
313 96 30,7

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.

Add an Image Experiment Analysis

Review the full report: "Add an Image" Experiment Analysis, March 2024.

"Añadir una imagen" a una sección

 
Sugerencias para "añadir una imagen" en una sección

En las wikis en las que está implementado, las personas recién llegadas tienen acceso a la tarea estructurada "añadir una imagen" desde su página de inicio. La tarea existente "añadir una imagen" sugiere imágenes a nivel de artículo para artículos sin ilustraciones. A continuación, la imagen se añade a la sección principal del artículo para ayudar a ilustrar el concepto del artículo en su conjunto.

 
Presentación de la tarea "añadir una imagen" a nivel de sección

Habrá una introducción a la tarea, seguida de una sugerencia específica (que incluye la razón por la que se sugiere la imagen). Si la persona recién llegada decide que la imagen encaja en la sección del artículo, entonces recibe orientación sobre la redacción del pie de imagen. La tarea estructurada proporciona detalles de la imagen, ayuda adicional para la redacción del pie de imagen si es necesario y, a continuación, solicita que se revise y publique la edición.

A partnership with the Structured Data team

El equipo de Crecimiento está colaborando con el equipo de Datos Estructurados para trabajar en una variación a nivel de sección de la tarea "añadir una imagen".

Este es uno de los aspectos del proyecto Datos estructurados en toda Wikipedia. Esta nueva tarea proporcionará sugerencias de imágenes que sean relevantes para una sección concreta dentro de un artículo. Esta tarea de sugerencia de imágenes a nivel de sección se considerará una tarea más compleja que sólo se sugerirá a las personas recién llegadas que tengan éxito en la actual tarea "añadir una imagen" a nivel de artículo.

Lea más sobre el trabajo del equipo de Datos Estructurados en Wikimedia aquí: Sugerencias de imágenes a nivel de sección .

Hipótesis

  • Una experiencia de edición estructurada reducirá la barrera de entrada y, por tanto, atraerá a más personas y a más tipos de usuarios que una experiencia no estructurada.  
  • Quienes se familiaricen con el flujo de trabajo realizarán más ediciones en su primera sesión y es más probable que vuelvan para realizar más.
  • La adición de un nuevo tipo de tarea "añadir una imagen" aumentará el número de sugerencias de imágenes disponibles para cada idioma.

Ámbito

Entrega clave: finalización de las Imágenes a nivel de sección (tarea estructurada para personas nuevas) Épica (1 $).

Diseño

A la derecha se pueden ver capturas de pantalla de dos diseños de móvil. Los diseños de "añadir una imagen a nivel de sección" son visibles en este archivo Figma.

Test de usuario

Las pruebas iniciales con usuarios/as de los diseños se completaron en abril de 2023 en inglés. Se dieron instrucciones a seis personas testeadoras, a quienes se pidió que experimentaran con este prototipo de diseño a nivel de sección y evaluaran la facilidad y el agrado de la tarea. La edad de los participantes oscilaba entre los 18 y los 55 años, procedían de 5 países diferentes y la mayoría no había editado Wikipedia anteriormente. 3 de las personas del test eran hombres y otras 3 eran mujeres. Se les pidió que revisaran dos sugerencias de imágenes, una era una "buena" sugerencia de imagen y la otra era una "mala" sugerencia de imagen.

Algunas conclusiones clave de las pruebas de usuarios:

  • Todos los participantes entendieron el onboarding: "'Claro, fácil de entender, directo'".
  • Los participantes parecían comprender la tarea y que debían centrarse en la sección a la hora de tomar su decisión. Un participante aceptó una sugerencia de imagen "mala":
    • 2/6 participantes aceptaron la sugerencia de imagen "buena" (3 rechazaron la imagen, 1 participante la omitió).
    • 5/6 participantes rechazaron la sugerencia de imagen "mala".
      • Nota: el algoritmo que potencia las sugerencias de imágenes debería proporcionar más sugerencias "buenas" que "malas", pero el algoritmo no es perfecto, por lo que esta tarea necesita revisión humana y es adecuada para las personas que empiezan a editar.
  • Algunos participantes mencionaron que querían revisar más de una imagen por sección: “Una sugerencia no es suficiente, tal vez pueda presentar más imágenes entre las que elegir para que pueda seleccionar la imagen más adecuada.

Evaluación del algoritmo

El equipo de Crecimiento pretende garantizar que las tareas estructuradas para las personas nuevas ofrezcan sugerencias acertadas al menos el 70% de las veces. Hemos realizado varias rondas de evaluación para revisar la precisión del algoritmo de sugerencia de imágenes.

En una evaluación inicial, las sugerencias fueron claramente imprecisas (T316151). Se sugirieron muchas imágenes en secciones que no deberían tener imágenes, o la imagen estaba relacionada con un tema de la sección pero no representaba a la sección en su conjunto. Basándose en los resultados de esta evaluación, el equipo de Datos Estructurados siguió trabajando en mejoras lógicas y de filtrado para garantizar que las sugerencias fueran más precisas (1 $).

En la segunda evaluación, por término medio, las sugerencias fueron mucho mejores (T330784). Por supuesto, los resultados variaron mucho según el idioma, pero la precisión media fue bastante alta en muchas wikis. Sin embargo, hay algunas wikis en las que las sugerencias siguen sin ser lo suficientemente buenas como para presentarlas a las personas novatas, a menos que sólo utilicemos las sugerencias de "buena intersección". Eso limitaría mucho el número de sugerencias de imágenes disponibles, por lo que en su lugar estamos intentando aumentar la puntuación de confianza de las sugerencias que ofrecemos.

wiki % buen alineamiento % buena intersección % buena imagen p18/p373/plomo total de sugerencias valoradas
arwiki 71 91 54 511
bnwiki 28 86 26 204
cswiki 41 77 23 128
enwiki 76 96 75 75
eswiki 60 67 48 549
frwiki N.A. N.A. 100 3
idwiki 66 81 37 315
ptwiki 92 100 84 85
ruwiki 73 89 69 250
overall 64 86 57 2,120

Es importante tener en cuenta que esta tarea será configurable por la Comunidad a través de Special:EditGrowthConfig. Esperamos mejorar la tarea hasta el punto de que pueda funcionar bien en todas las wikis, pero las comunidades decidirán en última instancia si esta tarea es una buena opción y debe permanecer habilitada.

Consulta a la comunidad

Para mayo de 2023 está previsto un debate con las wikis piloto de Crecimiento (T332530). Publicaremos diseños, planes y preguntas en la Wikipedia en árabe, Wikipedia en bengalí, Wikipedia en checo y Wikipedia en español, además de compartir más detalles aquí en MediaWiki.

Medición

We decided to not deploy this feature in an A/B test and instead allow users to opt in to using it through the task selection dialogue on the Newcomer Homepage, or through the "Try a new task" post-edit dialogue that's part of the Levelling Up features. This meant that we focused on measuring a set of leading indicators to understand if the task was performing well. More details about this can be found in T332344.

We pulled data from Growth's KPI Grafana board from 2023-07-31 to 2023-08-28 (available here) for Section-Level and Article-Level suggestions. This timeframe was chosen because it should not be as much affected by the June/July slump in activity that we often see on the wikis. The end date is limited by the team shutting off image suggestions in late August (see T345188 for more information). This data range covers four whole weeks of data. While this dataset does not allow us to separate it by platform (desktop and mobile web), nor does it allow us more fine-grained user filtering, it was easily available and provides us with a reasonably good picture that's sufficient for this kind of analysis at this time. Using this dataset we get the overview of task activity shown in Table 1.

Table 1: Task clicks, completions, and reverts by task type.
Task type Task clicks Saved edits Reverts Task completion rate Revert rate
Section-level 1149 688 60 58,1% 9,0%
Article-level 6800 2414 105 35,5% 4,3%

We see from the table that the task completion rate for section-level image suggestions is high, on par with Add a Link (ref) when that was released. This is likely because the section-level task is something users either choose themselves in the task selection dialogue, or choose to try out after being asked through the "Try a new task" dialogue that's part of Levelling Up. Those users are therefore likely already experienced editors and don't have too many issues with completing this task.

The revert rate for the section-level task is higher than the article-level task. We don't think this difference is cause for concern for two reasons. First, it might be harder to agree that an article is clearly improved by adding a section-level image compared to adding an article-level image. Secondly, articles suggested for section-level images already have a lead image, which might mean that they're also longer and have more contributors scrutinizing the edit.