Precios de la salud, la venta de limones y la experiencia del desarrollador

Precios de la salud, la venta de limones y la experiencia del desarrollador |  consejos CSS

 

De vez en cuando, se publica una publicación de blog y provoca una reacción o respuesta de otros que, a su vez, se publican como publicaciones de blog, y comienza a surgir un tema. Eso es lo que sucedió la semana pasada y el tema se desarrolló en torno al costo de los marcos de JavaScript, un costo que, en este caso, revela cuán importante es usar JavaScript de manera responsable.

 

Eric Bailey: salud moderna, ejecutivos, rendimiento y daño

Aquí es donde comienza la historia. Eric va al sitio web de un proveedor de servicios de salud para programar una cita y obtiene... una pantalla en blanco.

Junto con una cantidad aterradora de telemetría, la experiencia del cliente de Modern Health se brinda mediante React y Webpack.

Si sabe cómo se construye la web, lo que sucedió es bastante obvio: un sitio web que depende demasiado de JavaScript para potenciar su experiencia ha visto cómo su lógica choca con una o más piezas errantes de lógica que él invoca. Esto creó un punto muerto.

Si no estás haciendo experimentos digitales para ganarte la vida, no está del todo claro qué sucedió. Todo lo que ves es una pequeña rueda de carga falsa que nunca se detiene.

D'oh. Esto puede ser una mera molestia, incluso risible, en algunas situaciones, pero no cuando la salud de alguien está en juego:

A una persona que busca ayuda en tiempos de crisis no le importa TypeScript, sacudir árboles, intercambiar módulos en caliente, pruebas A/B, gráficos de quemado, NPS, OKR, KPI o cualquier otra jerga de inicio. La experiencia del desarrollador no cuenta como una mierda si la persona que usa lo que construyó no puede obtener lo que necesita.

Este es el gran soplo de la realidad. ¿Qué sucede cuando nuestras herramientas e informes, las mismas cosas que se supone que deben hacer que nuestro trabajo sea más eficiente, se interponen en el camino de la experiencia del usuario? Son herramientas que proporcionan información que puede ayudarnos a anticiparnos a las necesidades de un usuario, especialmente cuando es necesario.

Me doy cuenta de que señalar con el dedo a los marcos de JavaScript ya es divisivo. Pero va más allá de si usas React o marco del día. Se trata de las prioridades comerciales y la experiencia del desarrollador que entran en conflicto con las experiencias de los usuarios.

Alex Russell: El mercado del limón

Los defensores de los marcos lentos y complejos han logrado comercializar limones como la novedad, a pesar de las fallas generalizadas a su paso, desplazando opciones de mayor calidad en el proceso.

Estas tecnologías se lanzaron por primera vez en la parte posterior de "mejores experiencias de usuario", pero han fallado por completo en cumplir esa promesa fuera de las organizaciones altamente maduras en las que nacieron. Trasplantadas a la red más amplia, estas nuevas pilas demostraron ser costosas fallas.

Esa es la trampa. Alex no se anda con rodeos, pero tenga en cuenta que la culpa es de cómo se comercializaron los marcos para los desarrolladores en lugar de los propios desarrolladores. ¿El argumento de venta?

Una vez que los vendedores de limones se sumaron a la idea de que mejorar la "experiencia del desarrollador" ("DX") conduce a mejores resultados para los usuarios, mejorar "DX" se convirtió y terminó en sí mismo, y muchos de los que sabían mejor se sintieron obligados a jugar. Los largos retrasos en la manipulación de UX de ejecución fueron una característica, no un error; no te necesitan para tener éxito, solo para seguir comprando.

Cuando se trata de marketing, el cebo y el cambio "DX" son brillantes, pero la tecnología no es rival para nadie. pero desarrolladores

Difícil de digerir, ¿verdad? Nadie quiere que lo engañen y es difícil admitir un costo irrecuperable cuando lo hay. Se vuelve francamente personal si ha invertido tiempo en una tecnología específica y se ha esforzado por integrarla en su pila. Los flujos de trabajo de desarrollo son difíciles, e instalarse en uno es un poco como instalarse en una casa en la que planea vivir en breve. Pero le gustaría saber si su casa fue construida sobre lo que Alex llama “cimientos de arena”.

Me gustaría hacer una pausa aquí por un momento para decir que no tengo piel en este debate. Como generalista de la web, tiendo a adoptar nuevas herramientas temprano para familiarizarme con ellas, luego las abandono rápidamente, relegándolas a mi caja de herramientas hasta que encuentre un buen uso para ellas. En otras palabras, mi conocimiento es ancho pero no muy profundo en alguna zona o cosa. HTML, CSS y JavaScript son mi cóctel favorito, pero me importa mucho la experiencia del usuario y sé cuándo buscar una herramienta para resolver un problema en particular.

Y reconozcamos que no todos tienen algo que decir. Muchos de nosotros trabajamos en equipos administrados a los que se prescriben las herramientas que usamos. Alex lo dice, lo cual creo que es importante señalar porque claramente no pretende ser personal. Es una declaración sobre nuestras prioridades y nos aseguramos de que coincidan con las expectativas de los usuarios.

Deja que Chris nos lleve de vuelta a la historia...

Chris Coyier: ¿Pruebas de extremo a extremo con bloqueadores de contenido?

Entonces, tal vez su aplicación esté basada en React y no importa por qué es así. Todavía queda trabajo por hacer para garantizar que la aplicación sea confiable y accesible.

El simple bloqueo de un archivo no debería destruir por completo un sitio web, ¡pero a menudo lo hace! En JavaScript, puede deberse a que los desarrolladores han escrito JavaScript patentado (que generalmente permito) que depende de JavaScript de terceros (que generalmente bloqueo).

[…]

Si bloqueo los recursos de tracking-website.com, ahora mi JavaScript patentado generará un error. JavaScript no es genial. Si se genera un error, ya no ejecuta JavaScript más abajo en el archivo. Si más abajo en este archivo está transitionToOnboarding();- no funcionará.

Tal vez valga la pena revisar su flujo de trabajo y ajustarlo para identificar más puntos de falla.

Entonces, aquí tiene una idea: ejecute sus pruebas de extremo a extremo en navegadores que tengan bloqueadores de contenido populares con configuraciones predeterminadas instaladas.

Puede revelar problemas como este que impiden que sus clientes, e incluso las personas necesitadas, se detengan en seco.

¡Buena idea! Oye, lo que sea que ayude a pintar una imagen más realista de cómo se usa la aplicación. Este tipo de claridad podría ocurrir mucho antes en el proceso, tal vez antes de que se tomen decisiones de desarrollo. Conozca a sus usuarios. ¿Por qué están usando la aplicación? ¿Cómo navegan por la web? ¿Dónde están ubicados físicamente? ¿Qué problemas podrían interponerse en su camino? Chris también tiene una gran conversación sobre eso.

Si quieres conocer otros artículos parecidos a Precios de la salud, la venta de limones y la experiencia del desarrollador puedes visitar la categoría Estilo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir

Esta página web utiliza cookies para analizar de forma anónima y estadística el uso que haces de la web, mejorar los contenidos y tu experiencia de navegación. Para más información accede a la Política de Cookies . Ver mas