Reading/Web/Desktop Improvements/Frequently asked questions/es

Legibilidad
Nuestra principal razón para limitar el ancho del contenido es mejorar la legibilidad del todo el increíble contenido en nuestras wikis. Leer texto de manera eficiente es crucial para la gran mayoría de los casos de uso de lectura y edición en nuestros proyectos. Si bien hay varios factores que afectan la legibilidad, es decir, el tamaño de la fuente, el contraste, la fuente y la longitud de la línea, hemos decidido centrarnos inicialmente en la longitud de la línea. La investigación de longitud de línea formativa sobre lectura de textos impresos recomienda longitudes de línea entre 45 y 90 caracteres por línea (cpl). La investigación reciente sobre la lectura del texto del sitio web se centra principalmente en el rango de 35 a 100 cpl, y la mayoría de las recomendaciones se ubican en el extremo más pequeño de ese rango. Sin embargo, actualmente sin ninguna limitación de ancho en el contenido del artículo, los lectores pueden encontrarse con longitudes de línea muy por encima del rango recomendado. Un estudio de 2005 resume bien la investigación más reciente: "las líneas cortas son más fáciles de leer" y, además, con respecto al aprendizaje y la retención de información, "los sujetos que leen los párrafos estrechos tienen una mejor retención que los que leen los párrafos anchos".

Por último, si bien siempre es importante para nosotros hacer nuestra propia investigación y extraer nuestras propias conclusiones, creemos que vale la pena señalar la abrumadora cantidad de importantes sitios web que tienen limitaciones similares en el ancho del contenido. Por ejemplo: revistas académicas como Nature, sitios web de noticias como The New York Times, sitios web gubernamentales e intergubernamentales como UN, documentos académicos como LaTeX y procesadores de texto como Google Docs y Etherpad. Estos ejemplos, combinados con la extensa investigación, nos dan confianza en esta decisión.

En resumen, limitar el ancho del contenido permite una mejor legibilidad, menos fatiga visual y una mejor retención de la información en sí.

¿¡Pero qué pasa con todo el espacio en blanco!?
Hemos escuchado unos 30 editores (particularmente personas con pantallas grandes) que están frustrados por todo el espacio en blanco creado en los lados de la página, aunque algunos de ellos están de acuerdo en que la limitación de ancho es mejor para la lectura. Parece haber dos causas principales para esta frustración: Nuestro objetivo es crear la mejor experiencia de lectura que podamos, no llenar cada píxel de la pantalla con contenido. Y en este caso, menos en realidad es más: las personas pueden leer más fácilmente con longitudes de línea más cortas y enfocarse más fácilmente sin la distracción de las barras laterales u otros elementos. Si el mejor diseño es uno que incluye espacios en blanco, está bien: no hay nada intrínsecamente incorrecto con los espacios en blanco.
 * 1) El espacio en blanco parece espacio desperdiciado
 * 2) El espacio en blanco es brillante y distrae

Además, a medida que avanza el proyecto, esperamos comenzar a utilizar parte de este espacio para otras funciones. Hemos comenzado a experimentar haciendo que la barra lateral se adhiera al lado izquierdo de la página (enlace al prototipo). Más adelante en el proyecto, planeamos experimentar colocando una tabla de contenido y / o herramientas de página junto al contenido. Además, como, limitar el ancho del contenido nos brinda nuevas opciones para el diseño del contenido, como una columna de la derecha dedicada a los cuadros de información e imágenes.

¿Por qué los lectores no pueden hacer que sus ventanas del navegador sean más pequeñas?
Varias personas han retrocedido diciendo: si las personas quieren que el contenido sea más estrecho, pueden hacer que la ventana de su navegador sea más pequeña o hacer clic en el enlace "Vista móvil" en la parte inferior de la página. Como se mencionó anteriormente: dado que sabemos que la mayoría de las personas vienen a leer artículos, debemos optimizar el diseño en torno a ese caso de uso. Solo tenemos una oportunidad para causar una primera impresión y debemos apuntar a brindar a las personas una gran experiencia tan pronto como lleguen, sin que tengan que hacer ajustes.

Las tablas y otras plantillas no se ajustan al ancho limitado, ¿no es eso negativo?
Hemos recibido varios informes de tablas con barras de desplazamiento horizontales largas o plantillas que se expanden más allá del ancho limitado. Nos gustaría señalar que un gran porcentaje de nuestros usuarios, que no tienen pantallas grandes y acceden a Wikipedia desde sus computadoras portátiles, ya tenían problemas con las tablas y las plantillas incluso antes del cambio. Debemos trabajar para asegurarnos de que todo nuestro contenido sea lo más receptivo posible para acomodar a todos los visitantes.

¿Por qué no lo convertimos en un entorno?
Una de las mejores partes de la interfaz de MediaWiki es lo configurable que es. Y aunque podríamos establecer una configuración para el ancho del contenido, nos preguntamos si podría ser beneficioso fomentar una experiencia común que se comparta entre editores y lectores. Esto podría ser útil para los editores cuando tomen decisiones sobre diseños de página (nota: 1024px se menciona como un tamaño mínimo a considerar en el Manual de estilo de Wikipedia en inglés, aunque eso no es exactamente lo mismo). Actualmente, un editor puede estar editando una página con un ancho de 1500 px, mientras que un lector la lee con un ancho de 1200 px. Al implementar un ancho máximo, no eliminamos esta discrepancia por completo (porque todavía habría variación por debajo del ancho máximo, para las personas con pantallas más estrechas); sin embargo, estaríamos limitando en gran medida el rango de variación.

Dicho esto, no estamos intrínsecamente en contra de la configurabilidad. Si desea continuar usando la nueva versión de la piel Vector sin el ancho limitado, puedes usar un script de usuario local o un gadget para hacerlo. Podemos recomendar este.

¿Cómo decidimos 960px para el ancho?
Revise esta página para obtener más información sobre cómo tomamos esta decisión:

¿Cuándo estarán disponibles estos cambios en las wikis más grandes?
Esperamos ver los cambios establecidos como predeterminados en todas las wikis este año Cada comunidad es bienvenida para unirse a los early adopters.

¿Se implementarán las mejoras en proyectos hermanos y en wikis de escritura no latina?
Si. Ya hemos hecho una lista de wikis de "primeros usuarios" que representa varios tamaños y scripts. También queríamos asegurarnos de que se selecciona al menos un proyecto que no sea de Wikipedia.

¿En qué wikis están activados de forma predeterminada estos cambios?
Actualmente, estos son:


 * Proyectos hermanos:
 * 
 * 
 * 


 * wikis de escritura no latina:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Wikipedias de escritura latina:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * Adicionalmente:
 * Office Wiki
 * 

¡Estamos abiertos a añadir más wikis a esta lista!

¿Cómo se puede implementar esto en la wiki de Wikimedia de mi comunidad?
Si está interesado en ver las Mejoras de escritorio como predeterminadas en su wiki,
 * 1) pregunte a su comunidad y llegue al consenso,
 * 2) póngase en contacto con  SGrabarczuk (WMF), envíe un correo electrónico a: sgrabarczuk@wikimedia.org si necesita ayuda.

¿Cómo puedo habilitarlo en mi propia wiki (de terceros)?
Primero, asegúrese de haber descargado. Tenga en cuenta que la versión estable se lanzará a mediados de 2021. Si acepta el riesgo y desea ver nuestros cambios de todos modos, agregue las siguientes líneas en su :

¡Nos alegra saber que aprecia nuestras mejoras!

¿Se verán afectados los temas Monobook o Timeless?
No. Estos cambios se aplicarán únicamente a Vector. [ Vector] ha sido la interfaz predeterminada en los wikis de Wikimedia desde 2010. Ningún otro aspecto se verá afectado, incluidos [ Monobook], [ Timeless], [ Minerva] o [ Modern].

¿Mejorarás los gráficos, mapas, a- / f- / o- / tmboxes, infoboxes, navboxes u otras plantillas?
No. No cambiaremos nada que esté dentro del área de color gris claro de contenido del artículo (excepto la tabla de contenido):



¿Cómo puedo sugerir mejoras?
Agregue una sección en la [ página de discusión de la página principal del proyecto] o comuníquese con SGrabarczuk (WMF), correo electrónico: sgrabarczuk@wikimedia.org.

¿Cómo trabajas con las comunidades?

 * 1) Antes de las implantaciones:
 * 2) Hemos realizado una investigación sobre los usuarios y revisado sus gadgets y scripts. Consulta la página  para más detalles.
 * 3) Hemos contactado con varias wikis para pedirles que se unan a los  early adopters.
 * 4) We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * 5) Hemos realizado dos rondas de tests de prototipos. Los editores han podido conocer nuestras ideas y compartir lo que les gusta o les resulta confuso.
 * 6) Poco después de la implantación de cada mejora de características, recogemos datos de uso a través de  para cada wiki piloto.
 * 7) Lo realizamos A/B tests con los usuarios registrados. La mitad de ellos puede experimentar el cambio de interfaz, y la otra mitad no ve ninguna diferencia. A continuación, comparamos las estadísticas. Si los resultados son negativos, mejoramos el cambio o lo retiramos.
 * 8) Para los usuarios desconectados, comparamos el "antes y el después". Desgraciadamente, no podemos realizar pruebas A/B con usuarios desconectados.
 * 9) Observamos la página de discusión de proyecto. También participamos en discusiones en las wikis específicas con regularidad.
 * 10) Nuestros  embajadores contratados nos facilitan el trabajo con algunas comunidades de forma más estrecha, reaccionando más rápida y eficazmente.

¿Cómo puedo desactivarlo?
Es posible activar y desactivar las mejoras dentro de preferencias de usuario. También hemos proporcionado un botón de exclusión voluntaria en la barra lateral izquierda (accesible en cada página): [$optout ]. 

¿Se eliminará el enlace que permite optar por no participar?
No eliminaremos el enlace de exclusión voluntaria. Legacy Vector seguirá estando disponible a través de ese enlace, similar a otras máscaras que han sido predeterminadas en el pasado, como Monobook.

¿Cómo puedo reportar un error?
Consulte la siguiente página para ver si su error es un problema conocido.

Puede agregar una tarea en Phabricator y agregar Etiqueta de proyecto de mejoras de escritorio o comunicarse con  SGrabarczuk (WMF), correo electrónico: sgrabarczuk@wikimedia.org.

¿Por qué no hacer un nuevo skin? ¿Qué pasará con Legacy Vector?
Sería una excelente idea hacer una nueva máscara, pero en el caso de las máscaras de Wikimedia, es más fácil cambiar una existente que crear una nueva desde cero. Hay varias razones:


 * Sería demasiado complejo hacer que las extensiones, los gadgets y los scripts de usuario existentes sean compatibles con otra máscara, y demasiado costoso mantener su compatibilidad.
 * sería demasiado difícil construir y mantener otra máscara (ya que un reemplazo total no es una opción),
 * Sería menos probable que las comunidades colaboren de manera eficaz en el proceso de construcción de una nueva piel.

Técnicamente, las mejoras de escritorio son similares a características o proyectos anteriores, como o. La única diferencia es que esta vez habrá más. La documentación del tema Vector debe seguir siendo relevante.

Conservaremos y mantendremos el tema Vector heredado. No hay intención de eliminarlo.

¿Por qué no usar solo las funciones beta?
Las funciones beta están disponibles solo para usuarios registrados, y las mejoras están destinadas a servir a nuestros lectores y usuarios no registrados también. Por lo tanto, usar solo las funciones beta nos brindaría comentarios de un tipo de usuario muy específico que no es representativo de toda nuestra base de usuarios. Y además, deseamos recibir los comentarios de los lectores y usuarios anónimos de las primeras implementaciones.

¿Cuáles son las métricas de éxito de la función?
Aumentar la utilidad entre nuestras audiencias existentes, representada por:


 * Interacciones
 * Incrementar las búsquedas por sesión en un 5% durante el transcurso del proyecto.
 * Aumentar el cambio de idioma por proyecto en un 5% durante el transcurso del proyecto.


 * Afinidad
 * Aumento de sentimientos positivos y acogedores hacia el sitio (a través de encuestas y pruebas de usuarios)
 * Aumento de los sentimientos de confianza y credibilidad (medidos a través de encuestas y pruebas de usuarios)

A medida que definamos los cambios que queremos hacer con más especificidad, ampliaremos e iteraremos en esta lista.