Gesundheitswesen, Verkauf von Zitronen und die Kosten der Entwickler Erfahrung

Ab und zu wird ein Blogbeitrag veröffentlicht und löst eine Reaktion oder eine Antwort in anderen aus, die wiederum als Blogbeiträge veröffentlicht werden, und ein Thema beginnt sich abzuzeichnen. Genau das ist letzte Woche passiert, und das Thema entwickelte sich rund um die Kosten von JavaScript-Frameworks – Kosten, die in diesem Fall zeigen, wie wichtig es ist, JavaScript verantwortungsvoll einzusetzen.

Eric Bailey: Moderne Gesundheit, Frameworks, Performance und Schaden

Hier beginnt die Geschichte. Eric besucht eine Website eines Gesundheitsdienstleisters, um einen Termin zu buchen, und erhält... einen leeren Bildschirm.

Zusätzlich zu einer erschreckenden Menge an Telemetriedaten wird die kundenorientierte Erfahrung von Modern Health mit React und Webpack realisiert.

Wenn Sie sich mit dem Aufbau des Webs auskennen, ist das Geschehene ziemlich offensichtlich: Eine Website, die sich zu sehr auf JavaScript verlässt, um ihre Erfahrung zu ermöglichen, hatte ihre Logik mit einem oder mehreren anderen fehlerhaften Logikteilen kollidieren lassen, die sie aufruft. Dies führte zu einer Blockade.

Wenn Sie nicht Ihr Geld mit digitalen Erlebnissen verdienen, ist das Geschehene überhaupt nicht offensichtlich. Alles, was Sie sehen, ist ein winziger, gefälschter Ladekreis, der niemals aufhört.

Mist. Dies mag in manchen Situationen lediglich lästig – oder sogar lächerlich sein –, aber nicht, wenn es um die Gesundheit einer Person geht.

Eine Person, die in einer Krisenzeit Hilfe sucht, interessiert sich nicht für TypeScript, Tree Shaking, Hot Module Replacement, A/B-Tests, Burndown-Charts, NPS, OKRs, KPIs oder anderen Startup-Jargon. Die Entwicklererfahrung zählt nichts, wenn die Person, die das von ihnen Erstellte nutzt, nicht tatsächlich das bekommt, was sie braucht.

Das ist der große Schlag der Realität. Was passiert, wenn unsere Werkzeuge und Berichte – die Dinge, die unsere Arbeit effektiver machen sollen – dem Benutzererlebnis im Wege stehen? Dies sind Werkzeuge, die Einblicke geben, die uns helfen können, die Bedürfnisse eines Benutzers vorherzusehen, insbesondere in einer Zeit der Not.

Ich erkenne an, dass das Zeigen mit dem Finger auf JavaScript-Frameworks bereits spaltend ist. Aber das geht über die Frage hinaus, ob Sie React oder das *Framework des Tages* verwenden. Es geht um Geschäftsentscheidungen und die Entwicklererfahrung, die mit der Benutzererfahrung kollidieren.

Alex Russell: Der Markt für Zitronen

Verfechter langsamer, komplexer Frameworks haben Zitronen erfolgreich als das angesagte neue Ding vermarktet, trotz der allgegenwärtigen Misserfolge, die sie hinterlassen, und verdrängen dabei qualitativ hochwertigere Optionen.

Diese Technologien wurden ursprünglich mit dem Versprechen von *„besseren Benutzererlebnissen“* beworben, haben aber völlig versagt, dieses Versprechen außerhalb der Organisationen mit hoher Managementreife zu erfüllen, in denen sie entstanden sind. Übertragen auf das breitere Web haben sich diese neuen Stacks als kostspielige Fehlschläge erwiesen.

Da liegt der Hase im Pfeffer. Alex nimmt kein Blatt vor den Mund, aber beachten Sie, dass die Verantwortung bei der Art und Weise liegt, wie Frameworks an Entwickler vermarktet wurden, und nicht bei den Entwicklern selbst. Der Verkaufsspruch?

Sobald die Zitronenverkäufer die datenarme Idee verbreitet hatten, dass eine verbesserte „Entwicklererfahrung“ („DX“) zu besseren Benutzerergebnissen führt, wurde die Verbesserung der „DX“ zu einem Selbstzweck, und viele, die es besser wussten, sahen sich gezwungen mitzuspielen. Die langen Vorlaufzeiten bei der Fälschung von Trickle-Down-UX waren ein Merkmal, kein Fehler; sie brauchen Sie nicht zum Erfolg, sondern nur zum Weiterkaufen.

Was das Marketing angeht, ist der „DX“ Bait-and-Switch brillant, aber die Technik liefert für niemanden *außer* für Entwickler.

Schwer zu schlucken, oder? Niemand möchte getäuscht werden, und es ist schwer zuzugeben, dass es versunkene Kosten gibt. Es wird geradezu persönlich, wenn Sie Zeit in eine bestimmte Technologie investiert und Anstrengungen unternommen haben, diese in Ihren Stack zu integrieren. Entwicklungsworkflows sind schwierig, und sich in einen einzufinden ist so etwas wie sich in ein Haus einzuleben, in dem man eine Weile leben will. Aber Sie möchten wissen, ob Ihr Haus auf dem von Alex genannten „sandigen Fundament“ gebaut ist.

Ich möchte hier kurz innehalten und sagen, dass ich an dieser Debatte nicht beteiligt bin. Als Web-Generalist neige ich dazu, neue Werkzeuge frühzeitig zur Vertrautheit zu übernehmen und sie dann schnell wieder fallen zu lassen, sie in meinem Werkzeugschuppen zu lagern, bis ich einen guten Verwendungszweck dafür finde. Mit anderen Worten, mein Wissen ist *breit*, aber in einem Bereich oder einer Sache nicht sehr *tief*. HTML, CSS und JavaScript ist mein Lieblingscocktail, aber ich kümmere mich sehr um die Benutzererfahrung und weiß, wann ich zu einem Werkzeug greifen muss, um eine bestimmte Sache zu lösen.

Und lassen Sie uns anerkennen, dass nicht jeder eine Mitsprache hat. Viele von uns arbeiten in verwalteten Teams, denen die Werkzeuge, die wir verwenden, vorgeschrieben werden. Alex sagt das auch, was meiner Meinung nach wichtig ist hervorzuheben, weil klar ist, dass dies nicht persönlich gemeint ist. Es ist eine Aussage über unsere Prioritäten und stellt sicher, dass sie den Benutzererwartungen entsprechen.

Lassen Sie uns Chris die Geschichte weiterführen...

Chris Coyier: End-To-End-Tests mit Content-Blockern?

Also, vielleicht ist Ihre App auf React aufgebaut und es spielt keine Rolle, warum das so ist. Es gibt immer noch Arbeit zu tun, um sicherzustellen, dass die App zuverlässig und zugänglich ist.

Nur das Blockieren einer Datei sollte eine Website nicht komplett zerstören, aber das tut sie oft! In JavaScript kann das daran liegen, dass die Entwickler First-Party-JavaScript (das ich normalerweise zulassen werde) geschrieben haben, das von Third-Party-JavaScript (das ich normalerweise blockieren werde) abhängt.

[…]

Wenn ich Ressourcen von `tracking-website.com` blockiere, löst mein First-Party-JavaScript nun einen Fehler aus. JavaScript ist nicht entspannt. Wenn ein Fehler auftritt, führt es nicht mehr JavaScript weiter unten in der Datei aus. Wenn weiter unten in dieser Datei `transitionToOnboarding();` steht – das wird nicht funktionieren.

Vielleicht lohnt es sich, Ihren Workflow zu überprüfen und anzupassen, um mehr Fehlerpunkte zu identifizieren.

Hier ist eine Idee: Führen Sie Ihre End-to-End-Tests in Browsern aus, auf denen beliebte Content-Blocker mit Standardkonfigurationen installiert sind.

Das könnte Probleme aufdecken, die Ihre Kunden und tatsächlich Menschen in Not von ihrem Weg abbringen.

Gute Idee! Hey, alles, was dazu beiträgt, ein realistischeres Bild davon zu zeichnen, wie die App genutzt wird. Diese Klarheit könnte viel früher im Prozess entstehen, vielleicht bevor Entwicklungentscheidungen getroffen werden. Kennen Sie Ihre Nutzer. Warum nutzen sie die App? Wie surfen sie im Internet? Wo befinden sie sich physisch? Welche Probleme könnten ihnen im Weg stehen? Chris hat dazu auch einen großartigen Vortrag.