Solo funcionalidades web normales

• Con el aumento de nuevas plataformas de redes sociales, clientes, apps y ports web basados en React Native, se han vuelto más frecuentes los casos en que los sitios web pierden el comportamiento web básico que los usuarios esperan
• La presión por lanzar rápido, la ausencia de ingenieros de UI, los diseños móviles touch-first y las implementaciones que reemplazan el comportamiento predeterminado del navegador con JavaScript se señalan como causas principales
• Funciones como copiar texto, hacer clic derecho en enlaces y usar ctrl + click, el zoom del navegador, los layouts responsivos, :hover y :focus, la actualización de URL e historial, las barras de desplazamiento y ctrl + f, es decir, funciones básicas del navegador, deberían seguir funcionando tal cual
• Implementaciones como quitar pointer-events en tarjetas clicables o superponer capas, o navegar con div y on-click en lugar de anclas, rompen la experiencia normal de los enlaces
• Aunque hay mucho solapamiento con infracciones de accesibilidad, las apps web deberían conservar las funcionalidades web normales que los usuarios esperan, en vez de verse como apps móviles

---

El comportamiento básico que los sitios web han perdido

• Cada vez es más común que los proyectos web bloqueen funcionalidades web normales que los usuarios esperan
• A medida que aumentan las nuevas plataformas de redes sociales, se crean múltiples clientes y apps, y también son más frecuentes los casos que intentan compartir código entre plataformas, como con React Native
• Estos intentos en sí son positivos, pero a veces se omiten no solo requisitos básicos de accesibilidad, como el texto alt de las imágenes, sino también las formas habituales de interactuar con la web
• Entre las causas se pueden ver las siguientes
  • Presión por lanzar rápido hasta llegar a un nivel que se pueda probar
  • Situaciones en las que el proyecto no cuenta con un ingeniero de UI
  • Diseños que priorizan la entrada táctil en móviles e ignoran otros métodos de entrada o dispositivos
  • Implementaciones que evitan o reemplazan el comportamiento predeterminado del navegador con JavaScript

Funcionalidades web normales que deberían mantenerse

• Debe ser posible copiar texto
  • Si en un componente de tarjeta clicable se quitan los pointer-events o se superpone una capa clicable, puede impedirse la selección y copia de texto
• Los elementos que navegan como enlaces deben ofrecer la funcionalidad de enlace tal cual
  • Debe ser posible abrir el menú contextual con clic derecho para copiar el texto o la dirección del enlace
  • Deben funcionar los atajos habituales de enlaces, como ctrl + click en Windows para abrir en una pestaña nueva
  • En vez de navegar agregando on-click a un div, se deberían usar elementos de ancla
• El layout no debería romperse al usar el zoom del navegador, y el usuario debería poder hacer zoom para leer
• Un sitio responsivo, en vez de caer en un layout móvil simple apenas baja de 1200 px, debería usar el espacio de forma adecuada incluso en viewports estrechos
  • Mastodon y Twitter pueden verse como ejemplos donde, al reducir el ancho del navegador, la UI se mantiene familiar y en general aprovecha bien el espacio
• Las apps web deben ofrecer correctamente estados de interacción como :hover, :focus y :active
  • En casos de apps React Native portadas a la web, a veces no hay estilos :hover o :focus, o aparecen estilos :active que se ven extrañamente deshabilitados
• Si después de un clic la UI cambia por completo como si fuera una página nueva, el historial del navegador y la URL también deberían cambiar
  • Si no se puede enlazar a un estado de UI que parece una página independiente, y el estado desaparece después de navegar, la usabilidad empeora
• No se deberían ocultar las barras de desplazamiento
  • Los usuarios pueden querer hacer clic y arrastrar la barra de desplazamiento
• No se deberían interceptar los atajos comunes del navegador para funciones internas de la app
  • Si ctrl + f abre un cuadro de búsqueda personalizado dentro de la app, la búsqueda en la página puede no funcionar como de costumbre
• Aunque hay mucho solapamiento con elementos que pueden considerarse infracciones de accesibilidad, el foco está en evitar que las apps web rompan las expectativas básicas del navegador de los usuarios
• Los casos faltantes pueden seguir comentándose en Mastodon

[plastic041]

Parece que el contenido del cuerpo está incorrecto.

[xguru]

Vaya, qué curioso. Parece que el rastreo de esa entrada del blog en sí se está haciendo de forma un poco extraña.
Tendré que revisar la parte del crawler.

[GN⁺]

Opiniones de Hacker News

• Si primero aprendes la web con React y después aprendes HTML, puede pasar que dejes de prestar atención al comportamiento predeterminado de los enlaces.
  Cuando me uní al equipo, todos los enlaces eran botones, elementos arbitrarios o se manejaban con onClick; nadie se quejaba, pero Ctrl+clic era inútil y el menú contextual tampoco ofrecía las opciones esperadas.
  Creo que, al menos en lo que respecta a los enlaces, no hay margen para negociar.

  • Odio mucho este abuso de JS, y cada vez está rompiendo más cosas que deberían hacerse de la manera correcta.
    Archbee, una plataforma de documentación financiada por YC, tampoco permite abrir resultados de búsqueda en una pestaña nueva, así que hay que abrir uno en la pestaña actual y, si no sirve, volver atrás, buscar de nuevo y abrir el siguiente resultado.
    Se puede ver un ejemplo aquí: https://docs.sparklayer.io/
  • En la nueva versión web de Reddit, todos los enlaces son botones, así que no se pueden abrir en una pestaña nueva.
    Es realmente raro y desesperante que un servicio de Internet tan grande tenga un problema de accesibilidad tan evidente.
  • Esta es más o menos la mitad de la razón por la que uso nitter en lugar de Twitter.
    También está el hecho de que no hace falta una cuenta, pero además puedo hacer clic derecho en un hilo de tuits y abrirlo en una pestaña nueva.
    Por la naturaleza de las conversaciones en Twitter, quiero poder abrir varios hilos en pestañas nuevas manteniendo la posición de la página original, pero la interfaz real de Twitter hace que eso sea muy difícil.
  • El problema de los enlaces es una colina en la que vale la pena resistir hasta el final, siempre.
    Hay pocas cosas más molestas que esto; si tuviera que elegir una, sería romper el historial de navegación del navegador.
  • En sitios con una pantalla de lista y una pantalla de detalle, es un desastre para el uso de la web cuando no puedes hacer clic derecho en un elemento, o usar una extensión, para abrir la pantalla de detalle en una pestaña nueva.
    Si volver atrás funcionara de forma inmediata y fluida, quizá sería perdonable, pero en la práctica terminas esperando a que el contenido se cargue de nuevo y además pierdes la posición del scroll.
    Peor aún, hay sitios como Facebook que fuerzan el mismo estado de los popups de chat en varias pestañas. Si lo cierras en una pestaña, también se cierra en las otras, cuando hay una razón para tener varias pestañas abiertas.

• Creo que en el momento en que tocas un comportamiento incorporado por defecto, también asumes la responsabilidad por él.
  La “funcionalidad” que creaste no se queda dentro del alcance estrecho que imaginó el diseñador, sino que se convierte en toda la experiencia que realmente vive el visitante.
  Si cambias la lógica del botón de volver, estás cambiando el significado mismo de lo que ofrece volver atrás en ese sitio, y también tienes que hacerte responsable de que, como consecuencia, usuarios confundidos y enojados lo llamen un “sitio roto”.
  Hay que pensar si de verdad estás listo para hacerte cargo incluso de comportamientos que varían entre navegadores y sistemas operativos, como las barras de desplazamiento.
  Al final, es como hacer que el sitio web hable una especie de criollo, así que no debería sorprender si el visitante no entiende ese idioma o lo “interpreta mal”.
  Estas funciones no son solo algo que habría que evitar por amabilidad con el visitante; las ganancias parecen limitadas y los perjuicios casi ilimitados.

  • Es cierto. Los sitios web se benefician de modismos de diseño que se han refinado durante mucho tiempo.
    Los sitios que ignoran esos modismos se vuelven más difíciles de usar porque no hablan el lenguaje al que los usuarios están acostumbrados.
    También hay un artículo extenso sobre la pérdida de los modismos de diseño: https://loeber.substack.com/p/4-bring-back-idiomatic-design

• Pienso en esto como la appificación de los sitios web, y ya debería detenerse.
  Los sitios web deberían volver al renderizado del lado del servidor y agregar solo el JavaScript necesario.
  En cambio, las aplicaciones web pueden manejar un poco más la UX si aportan valor al usuario, pero mientras estén dentro del navegador, los principios básicos siguen aplicando.
  Apoyo las aplicaciones web porque son una plataforma de desarrollo accesible para cualquiera fuera del jardín amurallado de las app stores, pero hay que dejar de tratar todos los sitios web como si fueran apps.
  Si una página quiere aparecer en los resultados de los motores de búsqueda, entonces no es una aplicación web, es un sitio web.

  • Me gustaría que el navegador pudiera enviar Accept: text/markdown para documentos sin procesar, pero creo que ese barco zarpó en cuanto apareció CSS.
  • Puede que te guste este artículo: https://notan.app/
  • Estoy de acuerdo con que “los sitios web deberían volver al renderizado del lado del servidor y un poco de JS”.
    Por suerte, gracias a cosas como React Server Components, parece que estamos volviendo a la dirección de agregar JavaScript poco a poco a los sitios web, y eso me parece bueno.
  • Una buena aplicación web también puede ser un sitio web.
    Es un problema que se puede resolver si se le dedica suficiente tiempo.

• No entiendo por qué los sitios web de los bancos bloquean pegar
  Para cuando uno se da cuenta de que no puede pegar, ya copió el texto
  Escribirlo a mano es más propenso a errores, y si el portapapeles está contaminado, cuando notas la prohibición de pegar, la copia ya está hecha

  • Se siente como si en algún lugar tipo “Introducción a la programación de formularios” hubiera código para bloquear copiar y pegar, y esa idea hubiera dejado miles de descendientes por toda la web
    Parece que la gente imagina que es una medida de seguridad y la copia por iniciativa propia
    De entrada, no entiendo la razón para impedir que el usuario pegue
  • El sitio de mi banco no solo bloquea pegar la “contraseña”, sino también la entrada por teclado
    Esa “contraseña” es apenas un número de 6 dígitos, y ni siquiera puedo configurarla yo. Como si 6 dígitos fueran mucho más seguros que una cadena aleatoria de 16 caracteres generada por un administrador de contraseñas
    Te obliga a ingresarla con botones en posiciones aleatorias dentro de la página, pero si el dispositivo ya está tan infectado como para que registren teclas y clics, creo que el atacante también podría simplemente leer la contraseña desde la memoria del navegador
  • Hace unos días me registré con un ISP nuevo y el campo de contraseña bloqueaba pegar, así que rompió el administrador de contraseñas
    Desde el punto de vista de seguridad, es una decisión increíblemente mala
  • Por lo general empieza cuando una empresa tiene problemas de tráfico de bots
    Prueban varias cosas para molestar a los bots, y un día unos desarrolladores empujados por un mando medio bloquean copiar y pegar en la página de inicio de sesión, y los bots se detienen por un rato
    Unos días después los bots lo esquivan, pero el “arreglo” anterior queda con la idea de que “quizás bloquee algunos bots”
    Así, unas 10 líneas de JavaScript sobreviven hasta la reescritura v6, y meses o años después de empezar de cero vuelve a entrar la misma prohibición
    No es que lo diga por experiencia, claro
  • No digo que este sea el caso, pero sí hubo malware de portapapeles que, si lo copiado parecía una dirección de Bitcoin, la cambiaba por la suya
    https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
    Tal vez tenían en mente algo de ese tipo

• Me molesta cuando desarrolladores de JS vistosos esconden complejidad y funciones que nadie pidió detrás de menús select que parecen HTML nativo
  Lo veo mucho al ingresar ciudad y estado: la ciudad es un campo de texto y el estado es un desplegable/menú select
  Como soy de Texas, escribo la ciudad, voy con Tab al selector de estado, presiono t, t y paso al siguiente elemento del formulario
  Pero hoy en día suele ser un campo de búsqueda de texto disfrazado de desplegable, así que t, t no selecciona Texas después de Tennessee, sino que busca literalmente tt
  Solo funciona como se espera para quien hace clic con el mouse en el triangulito y desplaza la lista de estados
  Si no está roto, no hay que arreglarlo

  • Esto en general era un problema causado por un agujero en la plataforma web
    Históricamente, un <select> real era muy difícil o imposible de estilizar o de ampliar en comportamiento, así que muchas apps lo reimplementaron por su cuenta, casi siempre mal
    Parece que están llegando reemplazos nativos nuevos que sí se pueden estilizar
    Además, como era difícil compartir código entre apps, frameworks y empresas, solo las grandes compañías podían crear reemplazos de componentes nativos con funcionalidad completa, accesibilidad y personalización
    Web Components puede resolver esto al permitir colaboración global en componentes terminales comunes como <select>
    Artículo relacionado: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

• Creo que gran parte del comportamiento roto de los enlaces ocurre por falta de métodos de más alto nivel para sobrescribir el comportamiento predeterminado de los links
  Por ejemplo, no quiero agregar un listener de evento de clic para mostrar un enlace en un modal. El evento de clic es de un nivel demasiado bajo, porque hay que revisar manualmente las teclas modificadoras
  Lo que realmente quiero es decirle al navegador: “si este elemento ancla va a cambiar la URL de la ventana actual, llama a esta función en su lugar”
  Así el usuario puede abrir el enlace libremente en una ventana o pestaña nueva, y en ese caso mi código no se ejecuta
  Con CSS pasa lo mismo: no quiero especificar una imagen de cursor para cada elemento y pseudoclase. Quiero decir: “donde fueras a usar el cursor predeterminado de mano/espera/redimensionar, usa esta imagen personalizada”
  Así, aunque aparezcan elementos o UI nuevos, el código queda preparado para el futuro
  Algunas APIs del navegador parecen sufrir a veces el problema XY

  • Esto es bastante posible con JavaScript
    Basta con registrar onclick en la etiqueta y cancelar el comportamiento de navegación predeterminado en el manejador del evento
    Si el usuario desactiva JavaScript, el sitio sigue funcionando bien, y los comportamientos integrados del navegador como el menú de enlace con clic derecho o Ctrl+clic también siguen funcionando
    Pero es un “truco” bastante obscure, así que estaría bien que la API del DOM lo facilitara
  • https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
    Creo que este es un caso de uso de la Navigation API
  • Por fin vi en línea lo que pienso
    No necesitamos eventos de clic ni de puntero, sino un evento visit de más alto nivel

• Cuando vi Flutter Gallery por primera vez, me sorprendió que en el navegador web todo se sintiera roto: https://gallery.flutter.dev
  Creo que en especial pasaba con el ejemplo Reply
  En los enlaces no funcionaban Ctrl+clic ni el botón central del mouse, tampoco el clic derecho, no se podía seleccionar ni copiar texto, por su estructura técnica tampoco se podían inspeccionar elementos, y al intentar hacer zoom en la página no pasaba nada
  Al recordar esa experiencia y algunas implementaciones de SPA hechas con tecnologías más tradicionales, este artículo me suena acertado

  • Flutter es otro callejón sin salida más en el camino hacia un framework de desarrollo unificado
    Ya sea en web o en móvil, ninguna demo de Flutter me ha convencido de que tenga una UX aceptable
  • Parece que también maneja de forma rara la selección de texto en navegadores móviles
    Si la promesa de Flutter es que sea igual en todas partes, esta demo será igual de mala en escritorio

• Comportamiento del desplazamiento: preferiría que tampoco lo sobrescribieran
  No deberían intentar “mejorar” el desplazamiento haciéndolo “más suave”
  En Windows puede parecer bien, pero en Mac, al usar dispositivos de entrada de Apple, el movimiento del dedo sobre el trackpad o el mouse se corresponde 1:1 con el movimiento del elemento que se desplaza
  Estas “mejoras” por lo general se sienten como desplazarse dentro de melaza
  En general, no deberían intentar mejorar el comportamiento predeterminado del navegador

• Una de las cosas que odio de la web moderna desastrosa es que manipulen la History API
  Si en un sitio como HN hago clic en un enlace que parece interesante, entro a la página y hago scroll, cada encabezado o elemento poco importante agrega una entrada al historial
  Para volver al sitio original, tengo que presionar atrás como un millón de veces
  Odio a todos los que hacen esto

  • También quisiera agregar aquí el scroll infinito
    Simplemente usen paginación
    Se puede enlazar, buscar, navegar y funciona correctamente con el historial
    El scroll infinito rompe todo eso sin mucha razón

• En realidad, aquí hay dos problemas tan antiguos como la web: expectativas bajas y la ausencia de estándares o criterios que definan a las personas o las prácticas
  Hoy en día, si miras las ofertas de empleo, todas dicen “Senior Fullstack Engineer”, pero al entrar suele resultar que lo que realmente quieren es una combinación de Java o Python, R, Spring y SQL
  Si no es fullstack y aun así lo escriben así, hacen perder el tiempo a la gente y le envían al público la señal de que no entienden la tecnología o no les importa
  En programación, a esto se le llama el “problema X/Y”. Es un antipatrón en el que se debería resolver el estado final deseado X, pero en cambio solo se habla del enfoque Y que uno quiere tomar
  Por eso los empleadores reciben 500 currículums para una sola oferta y aun así sienten que nadie encaja
  El punto de partida debería ser el objetivo: “Estamos contratando para crear una app cliente/servidor de este tipo; la persona candidata deberá escribir y dar soporte a las funciones X, Y y Z, y las restricciones son A, B y C”
  La razón por la que las empresas no logran hacer esto suele ser que no saben realmente qué hacen y ya cargan con tecnología rota después de haber tomado varios caminos equivocados. Por eso se le llama deuda técnica
  Con un objetivo claro, tanto la empresa como la persona candidata saben qué deben verificar en la entrevista y pueden filtrarse mutuamente de forma adecuada. De lo contrario, se convierte en un proceso horrible que parece una mezcla de cita a ciegas y programa de concursos
  Por ejemplo, se podría especificar que se está contratando para crear una aplicación de conferencias multimedia altamente distribuida, y que el desarrollador deberá escribir TypeScript, canalizar datos de streaming desde sockets, trabajar tanto en el navegador como en el servidor y escribir automatización de pruebas
  Las restricciones operativas incluyen cumplimiento de WCAG AA, una checklist de cumplimiento de privacidad creada por el equipo legal y consideraciones de rendimiento orientadas a la velocidad de ejecución y la latencia de red; la persona candidata ideal deberá demostrar en la entrevista soluciones para la latencia de red, la lógica de aplicaciones en el navegador y la gestión de estado de datos en streaming