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

Legibilidad
Nuestra principal razón para limitar el ancho del contenido es mejorar la legibilidad de todo el contenido sorprendente en nuestras wikis. Leer texto de manera eficiente es crucial para la gran mayoría de todos 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 formar nuestras propias conclusiones, creemos que vale la pena señalar la abrumadora cantidad de sitios web importantes 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 de alrededor de 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 es en realidad 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) The white space feels like wasted space
 * 2) The white space is bright and distracting

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 tan malo?
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 escenario?
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.

That said, we are not inherently against configurability. If you would like to continue using the new version of the Vector skin without the limited width, you can use a local user script or gadget to do so. We can recommend this one.

How did we decide on 960px for the width?
Please review this page to learn more about how we made this decision:

When will these changes be available on the largest wikis?
Not in the first half of 2021, unless a community volunteers to join our testing. Currently, we are focusing on the development of our features based on data we have already collected, and on the tests on the early adopter wikis. We do hope to see the changes set as default on all wikis later in the year.

Are the improvements to be implemented on sister projects and on non-Latin script wikis?
Yes. We have already made a list of early adopter wikis which represents various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

Which wikis these changes are default turned on?
Currently, these are:


 * sister projects:
 * 
 * 
 * 


 * non-Latin script wikis:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Latin script Wikipedias:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * additionally:
 * Office Wiki
 * 

We are open to add more wikis to this list!

How can this be deployed on my home Wikimedia wiki?
If you are interested to see the Desktop Improvements as default on your wiki,
 * 1) ask your community and reach the consensus,
 * 2) contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org if you need support.

How can I enable it on my own (third-party) wiki?
First, make sure you have downloaded. Be mindful that the stable version will be released in mid 2021. If you accept the risk and would like to see our changes anyway, add following lines in your :

We are glad to learn that you appreciate our improvements!

Will Monobook or Timeless be affected?
No. These changes will be applied to Vector only. [ Vector] has been the default interface on Wikimedia wikis since 2010. No other skins will be affected, including [ Monobook], [ Timeless], [ Minerva] or [ Modern].

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, other templates?
No. We will not change anything that's within the light gray article content area (except for the table of contents):



How can I suggest improvements?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

How can I disable it?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page):.

Will you remove the link that allows to opt-out?
We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

How can I report a bug?
Check the following page to see if your bug is a know issue.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk-ctr@wikimedia.org.

Why not make a new skin? What will happen to Legacy Vector?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Why not use beta features only?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

What are the feature's success metrics?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.