Salud, venta de limones y el costo de la experiencia del desarrollador | trucos CSS
De vez en cuando se publica una publicación de blog y provoca una reacción o respuesta en otros, que a su vez se publican como publicaciones de blog, y comienza a surgir un tema. Esto sucedió la semana pasada y el tema giró en torno al precio de los marcos de JavaScript, un precio que, en este caso, revela cuán importante es usar JavaScript de manera responsable.
Eric Bailey: Cuidado de la salud contemporáneo, marcos, efectividad y daño
Aquí es donde comienza la historia. Eric va al sitio web de un proveedor de atención médica para programar una cita y obtiene... una pantalla en blanco.
Además de una cantidad aterradora de telemetríaLa experiencia de atención al cliente de Modern Health se ofrece mediante React y Webpack.
Si está familiarizado con la forma en que se construye la web, lo que sucedió es bastante obvio: un sitio web que dependía demasiado de JavaScript para potenciar su experiencia se topó con una o más piezas de lógica defectuosas a las que llamó .
Si no haces experiencias digitales para ganarte la vida, lo que sucedió no es obvio en absoluto. Todo lo que ves es una pequeña rueda giratoria de carga falsa que nunca se detiene.
Oh Esto podría ser un inconveniente, o incluso divertido, en algunas situaciones, pero no cuando la salud de alguien está en juego:
A una persona que busca ayuda durante una 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 para nada si la persona que usa lo que construyó no puede obtener lo que necesita.
Este es el gran sabor 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, interfieren en la experiencia del usuario? Estas son herramientas que brindan información que puede ayudarnos a anticipar las necesidades de un usuario, especialmente en un momento de necesidad.
Me doy cuenta de que señalar con el dedo a los marcos de JavaScript ya es motivo de controversia, pero esto va más allá de si está usando React o marco del díaSe trata de prioridades comerciales y la experiencia del desarrollador en conflicto con la experiencia del usuario.
Alex Russell: El mercado de los limones
Los defensores de los marcos lentos y complejos han comercializado con éxito los limones como lo nuevo, a pesar de las fallas generalizadas que siguieron, desplazando las opciones de mayor calidad en el proceso.
Estas tecnologías se colocaron originalmente en la parte posterior de "mejores experiencias de usuario"pero tienen completamente fallido para cumplir esta promesa más allá Organizaciones con alta madurez gerencial. en que nacieron. Trasplantadas a la red más amplia, estas nuevas pilas han demostrado su eficacia tonterías caras.
Este es el problema. Alex no se anda con rodeos, pero tenga en cuenta que la responsabilidad recae en cómo se comercializaron los marcos para los desarrolladores y no en los propios desarrolladores.
Después de que los vendedores de limones plantearon la idea de datos de que una "Experiencia de desarrollador" ("DX") mejorada conducía a mejores resultados para los usuarios, mejorar "DX" se convirtió en un fin en sí mismo, y muchos que sabían mejor se sintieron obligados a jugar juntos. tiempo de ejecución cuando falsificar la filtración de UX era una característica, no un error; no te necesitan para tener éxito, solo para seguir comprando.
Según Marketing "DX" cebo y cambio es genial, pero la tecnología no le da resultados a nadie pero desarrolladores
Difícil de digerir, ¿verdad? Nadie quiere ser engañado y es difícil reconocer una sanción cuando la hay. Se vuelve francamente personal si ha invertido tiempo en una pieza de tecnología en particular y se ha esforzado por integrarla en su pila. Los flujos de trabajo de desarrollo son difíciles, e instalarse en uno es como instalarse en una casa en la que planea vivir en breve. Pero te gustaría saber si tu casa está construida sobre lo que Alex llama "base de arena".
Me gustaría hacer una pausa aquí por un momento para decir que no tengo piel en este debate. Como profesional web, tiendo a adoptar nuevas herramientas temprano para familiarizarme con ellas, luego las abandono rápidamente, dejándolas en mi caja de herramientas hasta que encuentre un buen uso para ellas. En otras palabras, mi conocimiento es ancho pero no mucho Profundo en un área o algo así. HTML, CSS y JavaScript son mi cóctel favorito, pero realmente me importa mucho la experiencia del usuario y saber cuándo buscar una herramienta para resolver un problema en particular.
Y seamos realistas, no todo el mundo tiene algo que decir al respecto. Muchos de nosotros trabajamos en equipos administrados a los que se prescriben las herramientas que usamos. Alex dice lo mismo, lo cual creo que es importante mencionar porque está claro que esto no pretende ser personal. Esta es una declaración de nuestras prioridades y de garantizar que cumplan con las expectativas de los consumidores.
Vamos Deja que Chris nos lleve de vuelta a la historia...
Chris Coyer: ¿Pruebas de extremo a extremo con bloqueadores de contenido?
Entonces, tal vez su aplicación esté basada en React y no importa por qué. Todavía hay trabajo que hacer asegura que la aplicación sea confiable y esté disponible.
El bloqueo de un archivo por sí solo no debería romper por completo un sitio web, ¡pero a menudo lo hace! En JavaScript, esto puede deberse a que los desarrolladores han escrito JavaScript de origen (que generalmente permito) que depende de JavaScript de terceros (que generalmente bloqueo).
[…]
Si bloqueo los recursos de
tracking-website.com
ahora mi JavaScript de origen arrojará un error. JavaScript no es relajado. Si se arroja un error, no ejecuta más JavaScript más abajo en el archivo. Si más abajo en este archivo estátransitionToOnboarding();
- Eso no funcionará.
Puede valer la pena revisar su flujo de trabajo y cambiarlo para identificar más puntos de falla.
Así que aquí tienes una idea: ejecuta tus pruebas de principio a fin en navegadores que tengan instalados bloqueadores de contenido populares de forma predeterminada.
Esto puede revelar problemas como este que están deteniendo a sus clientes y, de hecho, las personas necesitadas se detuvieron en seco.
¡Buena idea! Oye, cualquier cosa que ayude a pintar una imagen más realista de cómo se usa la aplicación. Este tipo de claridad puede ocurrir mucho antes en el proceso, tal vez antes de decidirse por las decisiones de desarrollo. Conozca a sus usuarios. ¿Cómo navegan por la web? ¿Dónde están ubicados físicamente? ¿Qué problemas pueden interponerse en el camino? Chris también tiene una gran charla sobre eso.
Deja una respuesta