Web Almanac 2019 by HTTP Archive: Estado de la web en el 2019

HTTP Archive ha publicado los resulados de un análisis de 5.790.700 sitios web. No es algo habitual —recuerdo hace muchos años algo similar que publicó Opera—. En todos esos sitios web ha ido analizando su código y el resultado es una serie de artículos que, podríamos decir, sirve como muestra de las características de los sitios web en la actualidad.

Aquí está la tabla de contenidos, y creo que es necesario que los profesionales relacionados con la web lo tengamos muy en cuenta. Es un recurso de referencia y consulta. Un recurso valioso e imprescindible.

Part I. Page Content

Part II. User Experience

Part III. Content Publishing

Part IV. Content Distribution

Appendix

Web Almanac 2019 by HTTP Archive

El botón de los 300 millones de dólares. Diseñar un botón como ejercicio

El botón de los 300 millones de dólares

¿Conocéis la vieja historia del botón de los 300 millones de dólares que contó Jared M. Spool en el 2009 (The $300 Million Button)? Es interesante. Cómo al cambiar, entre otras cosas, el texto de un botón, mejoró en 300 millones de dólares las ventas anuales en una web de comercio electrónico.

¿Qué ocurrió? ¿cómo pudo afectar tanto a las ventas el cambio de un botón?
Contexto: en una web de comercio electrónico, al comenzar el proceso de compra tras tener el carro con la compra deseada, aparecía un formulario en el que se pedía el usuario, la contraseña, y la posibilidad de entrar en la página web (para confirmar la dirección de entrega y el medio de pago) o la de darse de alta. Ah, y también el enlace de olvido de contraseña.

Es decir, algo como:

Campo de usuario, contraseña, botón de acceso y vínculos de olvidé mi contraseña y darme de alta.
Recreación libre del formulario del carro de la compra.

¿Qué problemas podían haber (recordemos, año 2009)? De todo tipo:

  • Usuarios que no quieren registrarse en la web (sólo querían comprar).
  • Usuarios dados de alta que dudan cuál es la dirección de correo electrónico que tienen como usuario.
  • Usuarios que se habían dado de alta con varias direcciones de correo electrónicas diferentes.
  • Usuarios que no recuerdan la contraseña.

La consecuencia: en esa página se producía un cuello de botella que impedía finalizar la compra.

La solución: tras realizar pruebas con usuarios, pasa por cambiar el literal de un botón (de «darse de alta» a «continuar»), e incluir un texto indicando que se puede comprar sin darse de alta.

El resultado: 15 millones más de ventas en un mes, y 300 millones en un año (de ahí el sugerente título del artículo para los que se excitan con dólares).

Diseñando un botón: un elemento fundamental

Siempre me ha intrigado el proceso que está detrás de la toma de decisiones en un diseño. El porqué.

Porque se supone que detrás de una decisión de diseño (particularizando en una página web: fuente, tamaño, color, posición, rejilla,…) debería haber motivos que fundamentan esa decisión. ¿Cómo ejercitar esa habilidad o conocimiento?

What if, instead of trying to design an entire page with dozens of elements (nav, text, input controls, a logo, etc.), we consciously started by designing the simplest thing possible? We deliberately limit the playing field to one, tiny thing and see what we learn? Let’s try.

What is the simplest possible element? I vote that it’s a button.

The King vs. Pawn Game of UI Design — Erik D. Kennedy

Enumeremos algunas características de un simple botón:

  • tamaño
  • texto
  • fuente
  • tamaño y efecto de la fuente
  • color de fondo (¿gradiente de colores?)
  • color del texto
  • acompañar o no de un icono
  • padding (separación del texto y el borde)
  • margen (separación entre el botón y el resto de los elementos)
  • forma (esquinas cuadradas, redondeadas, radio de la redondez)
  • tipo de acción que realiza (continuar un proceso, acción «peligrosa», acción neutra, acción principal, acción secundaria,…)

Podemos delegar varias características al estilo por defecto que tenga el navegador (en el caso de una página web), o a algún framework con posibles síntomas de vigorexia.

O podemos diseñar un simple botón. Con el objetivo de cumplir los requisitos del proyecto (real o ficticio). Intentando argumentar cada característica. Me parece un ejercicio muy saludable.

Desarrollo web front: escala discutible de complejidad y/o dependencia

  • HTML
  • HTML + CSS
  • HTML + CSS + JavaScript
  • HTML + CSS + JavaScript + jQuery
  • HTML + CSS + JavaScript + jQuery + jQuery Plugins
  • HTML + CSS + JavaScript + jQuery + jQuery Plugins + npm
  • HTML + CSS + JavaScript + jQuery + jQuery Plugins + npm + 700,000 building blocks

Plus…

  • CSS frameworks
  • Javascript frameworks
  • Task managers
  • Packages managers

UXCON: Midiendo la desesperación de los usuarios

Navegar por muchas páginas webs actualmente es un suplicio:

  • Sobrepeso
  • Excesivo uso de seguimiento por motivos publicitarios
  • Incontables ficheros de javascript
  • Uso ineficiente y abusivo de webfonts
  • Publicidad intrusiva en videos, imágenes, contenido que aparece de repente en mitad del texto…

No olvidemos que el peso y el consumo de recursos de una web sigue teniendo su importancia, y hay que evaluar muy bien si esos centenares de kilobytes extras por tener una webfonts, por ejemplo, merecen realmente la pena.

UXCON User Experience CONdition

No vendría mal plantearse una especie de DEFCON, en el que en lugar de medir el estado de alerta por motivos militares, midiera el nivel de desesperación del usuario medio de nuestra web: por ejemplo, UXCON (User Experience CONdition). Y sí, hay nombres mejores, pero creo que al terminar también en “CON” es más memorable (y aquí mi consejo de naming).

Los niveles de DEFCON y sus consecuencias, se pueden consultar en el lugar habitual (DEFCON en la wikipedia). Pero aquí hablamos de UXCON, y es tan serio como el anterior, aunque menos mortal (de momento):

UXCON 5
Se navega con placided. Con mejor o peor contenido, con un diseño más o menos acertado, nada interfiere al usuario.
UXCON 4
En general la web es correcta, pero tenemos algunos enlaces que nada tienen que ver con el contenido de la página o el tema de la web, y encontramos algunos –pocos, eso si– banners de texto e imágenes. En el fondo es tolerable y lo entiendes. Lo que te cuesta de entender es porqué usa tanto javascript.
UXCON 3
Poder acceder a la página se complica: el aviso de cookies inicial, demasiados banners, la cabecera de la página se desplaza para incluir un anuncio, y el anuncio (por si no ha captado nuestra atención e ira) también aparece como fondo de página por los laterales. En lugar de enlaces para ampliar información relacionada, nos encontramos con enlaces publicitarios que a fuerza de verlos diariamente, reconoces y en los que alguna vez –débil es la carne– a veces visitas.
UXCON 2
El tiempo de carga es insufrible, la fuente cambia a los dos segundos, un video publicitario se inicia sólo, la mitad de la pantalla está ocupada por el aviso de las cookies, y por si fuera poco nos encontramos con un banner animado a pantalla completa. Para ver el contenido, tienes que navegar en un carrusel de texto e imágenes.
UXCON 1
La situación se vuelve crítica. Sólo queda lanzar el aparato contra el suelo o por la ventana.

Más allá de la idea tonta, de la clasificación arbitraria y de los ejemplos de cada criterio, me queda la sensación que de lo normal es navegar entre los niveles 3 y 4 de UXCON. Y no llegamos al nivel 5 porque en el fondo nos fastidiaría destrozar el móvil, tablet u ordenador: su dinero nos ha costado.

Nos quejábamos hace años del flash, y los banners parpadeantes y casi uno tiene añoranza por esos primitivos casos de agresivas técnicas contra los usuarios: era el coste que había por lograr un click publicitario.

Hoy todo a cambiado, y creo que a peor 🙁

¿La situación es reversible? ¿La tendencia de estorbo es lineal? ¿exponencial? Preguntas que quedan en el aire.

Y las preguntas incómodas: ¿de quién es la responsabilidad? ¿Quienes son responsables de modo activo y pasivo?

¿Hay espacio para la ética en el diseño web? ¿Sigue siendo la falta de empatía con los usuarios algo prescindible?

Cambiando de tema, una cita que me ha inducido a escribir este panfleto:

[…] there is the capability for pages to load in a second or two, but it has instead been used to spy on users’ browsing habits, make them miserable, and inundate them on other websites and in their inbox.
[…]
An actual solution recognizes that this bullshit is inexcusable. It is making the web a cumulatively awful place to be. Behind closed doors, those in the advertising and marketing industry can be pretty lucid about how much they also hate surveillance scripts and how awful they find these methods, while simultaneously encouraging their use. Meanwhile, users are increasingly taking matters into their own hands — the use of ad blockers is rising across the board, many of which also block tracking scripts and other disrespectful behaviours. Users are making that choice.

They shouldn’t have to. Better choices should be made by web developers to not ship this bullshit in the first place. We wouldn’t tolerate such intrusive behaviour more generally; why are we expected to find it acceptable on the web?

An honest web is one in which the overwhelming majority of the code and assets downloaded to a user’s computer are used in a page’s visual presentation, with nearly all the remainder used to define the semantic structure and associated metadata on the page. Bullshit — in the form of CPU-sucking surveillance, unnecessarily-interruptive elements, and behaviours that nobody responsible for a website would themselves find appealing as a visitor — is unwelcome and intolerable.

Death to the bullshit web.

The Bullshit Web — Nick Heer

Diseño web: de la teoría a la práctica

Uno puede leer Universal Principles of Design, y aprender más o menos sobre diseño. Pero de la teoría a la práctica, a veces falta “algo más” que ayude a afrontar con confianza un proyecto.

Aquí van algunos recursos que nos muestran algo de teoría y práctica aplicada en el diseño web. Comencemos:

  • Laws of UX: probablemente conozcas la Ley de Fitt, la Ley de Hicks, la Regla de Occam,… en esta página se recopilar 13 leyes y aparte de una breve descripción, incluye algunos recursos adicionales.
  • En Las leyes de UX con casos prácticos, vemos algunos buenos ejemplos de cómo aplicar esas leyes.

Por otro lado, un par de enlaces para terminar:

  • 7 Practical Tips for Cheating at Design, tenemos algunos buenos consejos para mejora el diseño de páginas o aplicaciones.
  • Y en Redesigning Laravel.io, vemos como los mismos autores, explican el rediseño de un foro, basándose en muchos de los consejos del enlace anterior, y argumentando las decisiones.