Después de un breve descanso con conferencias, comenzamos el sprint de Año Nuevo. Como hace un año, consistirá completamente de materiales de la gran conferencia FrontTalks, que Yandex celebró en Ekaterimburgo. Comencemos con un discurso de Anton Kastritsky, desarrollador de Yandex.Market. Anton mostró con ejemplos cómo y desde qué interfaces se ensamblan, y también habló sobre textos, su diseño, accesibilidad y rendimiento en el contexto de las aplicaciones web modernas.
- Mi nombre es Anton, trabajo como desarrollador de interfaces en el equipo de interfaz de socios Yandex.Market. Hoy quiero hablar sobre tipografía en la web.
Antes de eso, quiero contar una historia corta sobre cómo resultó que este tema es cercano e interesante para mí.
Una vez pensé en el hecho de que tal vez no todos entienden cómo trabajar con texto, fuentes y visualización en la web. Y quizás la primera vez que lo pensé fue cuando quise ingresar a Yandex. Me entrevistaron, tenía una sección con diseño. Me encanta el diseño, nada complicado, me gusta. Era necesario componer el componente, hice todo, genial. En la descripción de la tarea se escribió que era necesario configurar las fuentes, estaba Arial, Helvetica. Bueno, no hay problema, escribí Helvetica, Arial, sans-serif. Todo es como debería ser. Pero el entrevistador no estuvo de acuerdo, dijo que he escrito incorrectamente. Me confundió, pensé que Yandex es una gran empresa, probablemente esperan mucho de mí. Sepa qué son las fuentes del sistema, qué son las fuentes seguras. Les conté cómo funcionan y por qué escribí todo como está.
El entrevistador no estuvo de acuerdo conmigo de inmediato, pero como resultado, llegamos a comprender que deberíamos escribir Helvetica, Arial, y no al revés. Entonces llegué a Yandex. Empecé a entrevistar, encontré este problema, lo solucioné. Así que ven a nosotros a trabajar, es genial con nosotros.
Antes de pasar a la tipografía, hablemos sobre qué es el texto.
Texto
El texto es una herramienta que nos ayuda a decirle al usuario algo sobre sus próximas acciones. Una gran parte del contenido en Internet es texto. A pesar de que los servicios como Instagram y YouTube son populares ahora, las personas consumen una gran cantidad de contenido multimedia, el texto también ocupa un gran espacio en Internet y la gente todavía lo lee. Esto es muy importante
¿Quién trabaja en empresas donde hay un redactor o escritor, que se dedica a los textos? Casi la mitad. ¿Y a quién se le ocurre el texto para la aplicación en sí? También la mitad.
A veces sucede que el diseñador te dio el diseño, comenzaste a hacerlo. Pero hubo varias condiciones imprevistas, y usted tiene que pensar el texto usted mismo. Casi todo wow. En tales situaciones, debería ser una pena. Me dio la impresión de que los desarrolladores subestiman el papel de los redactores en la empresa, los desprecian y los presentan de alguna manera.
Solo un grupo de mujeres de arte que se sientan en la oficina y simulan muy hábilmente el trabajo. Este no es realmente el caso.
Redactores: como este profeta que está tratando de mostrarle a la chica desarrolladora cómo debería ser en realidad, y ella hace todo lo posible para ignorarlo.
El papel de los redactores es muy importante. Pueden tener un impacto directo en el producto, ofrecer soluciones más armoniosas, interacciones, mecánica. Una persona, después de leer el texto en la página, puede percibir su producto de una manera completamente diferente. Su papel es realmente muy importante, siempre deben ser escuchados, y no como esta chica, que trata de trabajar y no prestar atención a lo que este profeta le está transmitiendo. Intenta escuchar a tus redactores y no dudes en hacerles preguntas.
También es muy importante no solo lo que escribes, sino que generalmente escribes en general. Quiero mostrar un ejemplo de la vida real. Teníamos un componente donde el usuario necesitaba agregar un número de teléfono.
Una página enorme con configuraciones, todo es como siempre. Había una etiqueta, un número, un botón "Agregar", el usuario hizo clic en él y apareció una entrada telefónica.
Después de ingresar con éxito el número de teléfono, tenía que hacer clic en la marca de verificación gris para guardar.
Cuando comenzamos a realizar pruebas de UX, descubrimos que un número muy pequeño de usuarios incluso adivinó que era necesario hacer clic en el botón gris para guardar el número de teléfono. Que hemos hecho Después de que el usuario ingresó con éxito el número de teléfono, pintamos la marca de verificación en amarillo, y el usuario pudo guardarlo.
Realizamos pruebas repetidas de UX. Un poco más de personas descubrieron cómo guardar un número de teléfono.
En este punto, puede parecerle que nuestros usuarios tienen algunos problemas para interactuar con nuestras interfaces, las usan de alguna manera.
Pero, de hecho, el problema no es con los usuarios, sino con nosotros, porque no podíamos transmitirles exactamente lo que queremos de ellos. Por lo tanto, hoy este componente se ve un poco diferente: todo también hace clic en el botón, pero ahora tiene una ventana emergente con botones explícitos "cancelar" y "guardar".
Después de ingresar con éxito el número de teléfono, se enciende el botón "guardar" y el usuario puede decidir independientemente si desea guardarlo o no. Si hace clic fuera de la ventana emergente, la ventana emergente desaparecerá y todavía no ha agregado el número.
De esto podemos concluir: no tengas miedo de escribir cosas obvias. Los desarrolladores pasamos una gran cantidad de tiempo en Internet, vemos muchas opciones de GUI diferentes sobre cómo hacer lo mismo. Pero no todos nuestros usuarios tienen esta experiencia. Entonces, hagamos interfaces más simples e intuitivas para que sea más fácil para el usuario descubrir por sí mismo.
Display
Hablemos de mapeo en general. Es fácil adivinar que todas las reglas de visualización nos llegaron desde la impresión.
Es importante reemplazar que soy desarrollador, y no puedo hacerlo maravillosamente. Sé cómo hacerlo funcionar, y cuando todo está bien, y funcionó de manera productiva. Por lo tanto, no hablaré sobre serifs o diferentes tipos de fuentes. Lo haré, pero luego.
Hay una gran cantidad de contenido textual y servicios en Internet donde los usuarios van exclusivamente a leer algo.
Me parece que uno de los servicios más convenientes es Medium. Creo que todos lo conocen, entran, leen las noticias, especialmente sobre el tema de la interfaz. El servicio realmente presenta contenido que es fácil de leer. Pero daré un contraejemplo, que todos usamos.
No conozco a una sola persona que visite Wikipedia y lea cualquier cosa con placer. Me parece que esta no es una opción legible, aunque se puede solucionar siguiendo solo dos o tres reglas.
El primero es tener alrededor de 10 palabras por línea.
Necesitamos limitar el ancho del contenido del texto a unos 80 caracteres. Esta regla puede parecerse a la configuración de su linter, porque la visualización del código y el código en sí, así como el texto en los sitios, está escrito para que pueda ser fácilmente percibido por una persona, no por una computadora.
El segundo es el interlineado. Cuando sus líneas están demasiado cerca unas de otras, los usuarios ya comienzan a tener dificultades con la percepción de esto.
Y haga que la fuente sea un poco más grande, para facilitar la percepción. Ahora Wikipedia está tomando una forma que ya es notablemente más fácil de percibir.
Y también, si el espacio de la pantalla es muy importante para usted, puede agregar guiones.
Es posible que esto no siempre funcione correctamente con texto en ruso, pero puede ayudar a guardar un par de líneas.
No olvide que en el idioma ruso hay muchas reglas de ortografía. Necesitamos deshacernos de cosas como colgar pretextos, asegurarnos de que, cuando sea necesario, haya grandes guiones, etc. Herramientas como
Typographer pueden ayudarlo con esto. Simplemente ejecute su texto y ya está.
Si tiene texto estático, puede agregar un
complemento de babel para convertirlo cuando cree su aplicación. Si su texto se almacena en un almacenamiento externo, tal
paquete npm puede ser útil; con él, puede convertir el texto antes de enviarlo al cliente.
Fuentes web
¿Cómo sucedió que podemos usar diferentes fuentes en la web?
Los desarrolladores adultos pueden recordar que durante mucho tiempo tuvimos que agregar diferentes imágenes si queríamos transformar de alguna manera la apariencia del texto en las páginas. Más tarde obtuvimos una etiqueta de fuente. Y hoy utilizamos la propiedad font-family, donde enumeramos las fuentes en el orden en que queremos que se apliquen. Si de repente el navegador no encuentra y no reconoce uno, simplemente irá más lejos en esta lista y usará lo siguiente.
Ya hoy tenemos una gran cantidad de propiedades para transformar la visualización del texto.
Y no puedo evitar mencionar algo como las fuentes variables.
Esto nos ayuda a transformar aún más la visualización de nuestras interfaces. Hoy, el apoyo ya es lo suficientemente bueno.
En los últimos años se ha escrito una gran cantidad de información sobre esta tecnología en Internet, que no vamos a considerar ahora.
Fuentes
Hay una gran cantidad de fuentes. Pero quería acercarme desde un punto de vista de ingeniería y dividirlos en varios tipos.
Creo que todos los que leen las especificaciones, y no solo, saben que hay fuentes del sistema preinstaladas en el sistema operativo desde la caja; Hay fuentes instaladas que el usuario instaló independientemente; así como las fuentes descargables o web, esto es todo lo que el usuario descarga al ir a su aplicación.
No puedo dejar de mencionar las fuentes seguras. ¿Cómo resultó que los teníamos? Anteriormente, no podíamos esperar que el usuario tuviera esta o aquella fuente, por lo tanto, a principios de la década de 2000, Microsoft ofreció una lista de seis fuentes que estaban presentes en todos los sistemas desde el comienzo de la última década, y los desarrolladores podían usarlas con la conciencia tranquila, sabiendo que estas fuentes ya están presentes en los usuarios y no tendrán que enviar solicitudes adicionales.
Y aquí vemos el mismo Arial. Mirando hacia el futuro: alguien ya sabe que Helvetica es una fuente del sistema en macOS, ha estado presente allí durante muchos años. Por lo tanto, en la historia que mencioné al principio, dije que deberíamos grabar Helvetica, Arial, y no al revés.
Después de eso, noté mucho este registro en una variedad de recursos, y me preguntaba de dónde vino, cómo resultó que las personas pueden cometer un error tan básico. Después de todo, lo aprendemos cuando apenas comenzamos a aprender CSS.
Me sorprendió mucho cuando me di cuenta de que provenía de un recurso tan respetado como w3schools, les envié un informe de error, pero aún no lo han solucionado, eh.
Ahora volvamos a las fuentes. ¿Cómo podemos conectar fuentes? Tenemos CSS y JavaScript.
Podemos declarar una fuente personalizada y especificar varios formatos desde los cuales el navegador seleccionará y descargará el primero que conozca.
- WOFF2 es mejor comprimido y compatible con todos los navegadores modernos.
- WOFF se comprime un poco peor, pero tiene un excelente soporte.
- EOT es necesario exclusivamente para IE más antiguo. - TTF, también tiene un buen soporte, y al descargarlo, podemos instalarlo en el sistema operativo.
- SVG, que en desuso, en mi opinión, solo se admite en uno o dos navegadores en la actualidad.
También tenemos una función CSS tan local como local, con su ayuda podemos verificar si la fuente está presente en el sistema operativo del usuario. Pero realmente no tienes que confiar en ella. Incluso si las fuentes tienen el mismo nombre, esto no significa en absoluto que sean la misma fuente. Por lo tanto, si lo usa, tenga cuidado.
Después de que haya anunciado la fuente, no olvide especificar algunos fallos, en caso de que el navegador no pueda descargarla.
Creo que mucha gente sabe que podemos especificar un rango Unicode para las fuentes, y después de descargar la fuente, se usará exclusivamente para los caracteres especificados. Por ejemplo, desea mostrar solo texto en inglés en esta fuente o solo números, etc.
También le permite reducir significativamente el tráfico que enviamos a los usuarios.
Arriba, podemos dividir la fuente en dos archivos separados, en uno solo hay caracteres latinos, y en el segundo - cirílico. Les dimos el mismo nombre de familia de fuentes para que el navegador comprenda que son partes de una sola fuente. Ahora, si solo tenemos caracteres cirílicos en la página, el usuario descargará solo el segundo archivo, lo que reduce el tráfico descargado por el usuario.
Como resultado, no es tan difícil hacer subconjuntos, existen herramientas GUI y CLI para esto, no es difícil encontrarlas y tratarlas.
El soporte es bastante bueno hoy. No seas tímido para usarlo.
No te olvides del gran proverbio "mide siete veces, sabasa una vez", de lo contrario, te puedes meter en una situación bastante incómoda.
También podemos descargar fuentes usando JS, tenemos una API FontFace para esto, se ve bastante similar.
Declaramos una nueva fuente, la cargamos, se carga de forma asíncrona. Después de que se haya cargado, podemos agregarlo a la página.
A primera vista, este enfoque puede parecer inútil, a menos que esté involucrado en un servicio de fuentes. Pero al final del informe, puede cambiar de opinión.
Bueno, tenemos un servicio, le hemos agregado varias fuentes. Y nuestro usuario llega a nuestra página y se encuentra con esa imagen.
¿Cómo sucedió eso? El HTML ha llegado, los estilos se han cargado y las fuentes aún no han llegado, y aquí el comportamiento del navegador puede variar. Algunos de los navegadores bloquean la representación del texto, parece que no hay texto, pero de hecho, los navegadores dibujan el texto con su propia fuente transparente, porque necesitan saber cuánto espacio en la página ocupa el texto, de modo que todas las sangrías son similares. Cuando se carga la fuente, el texto se vuelve a dibujar con su fuente y se muestra en el navegador.
Sería genial si pudiéramos unificar el comportamiento del navegador en tales casos. De hecho, algunos navegadores pueden procesar texto con una fuente transparente, mientras que otros con una fuente doblada. Para esto, solo tenemos una línea de código.
Básicamente, solo bloquear o intercambiar será útil para usted a partir de esto. Block hará que el navegador espere y muestre el contenido de la página con una fuente transparente, porque es muy posible que tenga una fuente personalizada muy hermosa que no se parece a nada. Por lo tanto, no desea que el usuario vea el texto, por lo tanto, espere. No esperará para siempre, solo tres segundos, después de lo cual usará la siguiente fuente y esperará el infinito completo hasta que llegue.
O intercambie, cuando el navegador toma inmediatamente la siguiente fuente doblada, dibuja el contenido con ella y espera un tiempo infinito para que llegue su fuente.
Hoy el soporte es bastante bueno, esto ya se puede usar. Después de todo, CSS no es JS, si de repente el navegador no comprende algo, está bien, ignorará esta regla e irá más allá. En tales casos, obtenemos el mismo comportamiento que antes.
Genial, solicitamos el navegador, ahora tenemos el mismo comportamiento en casi todos los navegadores no heredados.
Pero no resolvimos el problema en sí. ¿Cómo sucedió que las fuentes son tan largas? Hace mucho tiempo, cuando aún no estaba trabajando en Yandex, hice un pequeño aterrizaje, nada especial, pero muchas fotos y un poco de estilo.
Encontré un problema tal que la fuente llegó literalmente a los 6-7 segundos, y esto fue solo con estrangular la red para acelerar 3G, aunque el primer render ya se mostró en algún lugar durante 2.5 segundos, y el usuario simplemente miró una página en blanco.
HTML azul se carga en la parte superior, luego van los estilos morados. ¿Dónde está nuestra fuente?
Ahí está. Como sucedio Tenemos una pequeña aclaración, incluso si declaramos nuestra fuente al comienzo de nuestros estilos, el navegador enviará una solicitud solo después de que descargue todo el CSS, lo analice por completo y vea que hay texto en la página que debe dibujarse con esta fuente .
Sería genial si pudiéramos decirle al navegador: escucha, definitivamente usaré esta fuente y la descargaré ahora mismo.
Entonces podemos. Esto se llama carga de fuente. Podemos decirle al navegador en una sola línea que necesitamos descargar esta fuente en particular y enviar una solicitud antes de enviar la solicitud de estilos. Ahora la cascada de solicitudes se ve diferente.
Nuestro texto con la fuente correcta aparece con el resto del contenido durante aproximadamente 3 segundos. Esto no acelera nuestro sitio, pero el usuario puede comenzar a navegar de inmediato por este contenido. Y eso está bien.
La precarga de enlaces solo funciona en navegadores bastante modernos, y vale la pena usarla principalmente con woff2, si no es así, simplemente woff. Porque la solicitud siempre se envía.
Otra buena práctica con la precarga: solo necesita especificar un archivo que el navegador entienda. Si comienza a leer sobre esto en MDN, verá algo similar.
Esto nunca vale la pena hacerlo, porque así es como enviamos muchas solicitudes de fuentes de cada formato, aunque el navegador usa solo una. ¿Por qué agregaron el formato eot aquí, que se usa solo para IE, que ya no está desarrollado y ni siquiera es compatible con Microsoft? Es poco probable que nos digan esto.
Un código similar debería parecer más probable.
¿Quizás tenga otras tareas que necesite completar cuando inicialice su aplicación? , , , , , .
— . JS, , , , , .
. , , . . Font style matcher, , CSS , , , , , , “”.
-? , , .
, . ? , , , Yandex Sans. , . , ? , , ?
«», -. , . ? , . .
, system-ui, , stage 2, , Windows, .
, , . , , . , github, Twitter, Medium. , .
, , , , bootstrap. .
, , accessibility, , , , .
? , - ?
, , -, , . , , .
,
axe pa11y , accessibility test runners, CI-. . pa11y .
- . , , ? .
, , . , color picker dev tools, Chromium- — .
, , , , . , , , , , , .
, , , .
.
, localStorage, . , , . , , , - , .
, : localStorage , key-value-, — . - , , .
— . head HTML- . , . , , bounce rate. , — , , .
, , . : , 200 , . — , . , — , , svg. , . svg CSS- .
, . . , , . — svg.
. , , . — : , , , . .
. , . . , . , , .
, , , . — , . Gracias