„Einfachheit“ ist ein seltsames Adjektiv im Webdesign und in der Webentwicklung. Ich bin sicher, es ist ein erklärtes Ziel für fast jedes jemals durchgeführte Projekt. Niemand geht in ein Kick-off-Meeting und sagt: „Hey Team, entwerft mir etwas Kompliziertes. Oh, und stellt sicher, dass die Implementierung auch verschlungen ist. Überentwickelt das Ding, ja?“
Natürlich wollen sie Einfachheit. Jeder will Einfachheit. Wir wollen einfache Designs, weil einfach bedeutet, dass unsere Kunden es verstehen und mögen werden. Wir wollen Einfachheit in der Entwicklung. Niemand träumt davon, zur Arbeit zu gehen, um den ganzen Tag damit zu verbringen, sich in ein komplexes System einzuarbeiten, um einen einzigen Fehler zu beheben.
Dennoch gibt es viel zu besprechen, wenn es um Einfachheit geht. Es wäre sehr schwer zu argumentieren, dass die Webentwicklung im Laufe der Jahre einfacher geworden ist. Daher ist das Wort in letzter Zeit auf den Lippen vieler Webdesigner und -entwickler. Lassen Sie uns einen gemächlichen Walzer durch das machen, was andere Leute über Einfachheit zu sagen haben.
Bridget Stewart erinnert an einen frustrierenden Kampf gegen übermäßiges Engineering in „A Simpler Web: I Concur.“ Nachdem sie als Expertin für UI-Implementierung eingestellt wurde und die Aufgabe erhielt, ein Video per Klick abspielen zu lassen…
Ich schaute unter die Haube und verlor mich in all den Schleifenfunktionen und Variablen und konnte nicht herausfinden, was der Code tun sollte. Ich konnte kein HTML-
<video>finden, auf das verwiesen wurde. Ich konnte nicht sehen, wo ein Link oder ein Button generiert werden könnte. Ich war verloren.Ich bat ihn zu erklären, was die Funktionen taten, damit ich helfen konnte, die Ursache herauszufinden, denn der Browser kann Videos mit wenig Überredungskunst abspielen. Anstatt mich erfolgreich verstehen zu lassen, was er gebaut hatte, stritt er mit mir darüber, ob es überhaupt möglich sei. Ich versuchte zunächst ruhig zu erklären, dass ich das in meinem früheren Job schon oft gemacht hatte, also war ich absolut sicher, dass es getan werden konnte. Als er meine Erklärung weiterhin ablehnte, wurde die Situation hitzig. Als ich fertig war, ihm anzuschreien (nicht die professionellste Art, mich zu verhalten, ich weiß), kehrte ich zu meinem Arbeitsbereich zurück und startete einen Branch des Repos, um es zu implementieren. 20 Minuten später hatte ich es zum Laufen gebracht.
Es scheint, dass das *Hauptproblem* hier darin besteht, dass der Typ ein territorialer Dummkopf war, aber auch sein komplizierter Ansatz buchstäblich im Weg stand, Arbeit zu erledigen.
Einfachheit im Web bedeutet oft, den Browser für uns Dinge tun zu lassen. Wie oft haben Sie gesehen, dass eine komplexe Neukonstruktion eines Select-Menüs nicht so nutzbar oder zugänglich war wie ein <select>?
Jeremy Wagner schreibt in Make it Boring
Ich vermute, der Aufstieg von statischen Website-Generatoren – und von Websites, die so viel wie möglich serverseitig gerendert bekommen – ist ein Symptom dafür, dass die Branche nach dieser Art von Widerstandsfähigkeit giert.
Weniger tun, wie man sagt. Lyza Danger Gardner fand viel Wert darin in ihrer eigenen Arbeit
… wir müssen versuchen, so wenig wie möglich zu tun, wenn wir die zukünftige Web-Landschaft aufbauen.
Dies ist keine Rechtfertigung für Faulheit oder Faulenzen bei der Verantwortung – diese Eigenschaften sind wohl kaum bei erfolgreichen Webentwicklern zu finden. Es ist auch kein Vorschlag, dass wir langweilige, homogene Websites und Apps erstellen, die allen Nuancen oder Funken dem größeren Wohl der totalen Kompatibilität opfern.
Stattdessen ist es ein Appell für Einfachheit und Eleganz: Gemeinsamkeiten in den Vordergrund stellen, Differenzierung sorgfältig angehen und für Konsistenz bei der Erstellung und Anwendung von Webstandards eintreten.
Christopher T. Miller schreibt in „A Simpler Web“
Sollten wir etwas Einfacheres, etwas Zugänglicheres finden?
Ich denke, wir können. Indem wir unsere Websites vereinfachen, erreichen wir eine größere Reichweite, bessere Leistung und eine zuverlässigere Vermittlung der Informationen, die im Kern jeder Website stehen. Ich glaube, wir sehen das in den leidenschaftlichen Gesprächen über Benutzererfahrung, aber es kann nicht beim UX-Team aufhören. Entwickler müssen Verantwortung für die Komplexität übernehmen, die sie dem Web hinzufügen.
Es ist gut, sich daran zu erinnern, dass die Komplexität, die wir beim Erstellen von Websites hinzufügen, optional ist. Wir tun es oft aus gutem Grund, aber es ist *möglich*, es nicht zu tun. Garrett Dimon
Man kann heute eine robuste, zuverlässige und vollständig responsive Webanwendung mit nur semantischem HTML im Frontend erstellen. Keine Bilder. Kein CSS. Kein JavaScript. Es ist absolut möglich. Es wird in jedem modernen Browser funktionieren. Es wird einfach zu warten sein. Es entspricht vielleicht nicht der üblichen Definition von Schönheit, was Webumgebungen angeht, aber es wird funktionieren. In vielen Fällen wird es nutzbarer und zugänglicher sein als die, die mit modernen Frontend-Frameworks erstellt wurden.
Das soll nicht heißen, dass dies der beste Ansatz ist, aber es ist eine gute Erinnerung daran, dass das Web standardmäßig ohne all unsere zusätzlichen Schichten funktioniert. Wenn wir diese zusätzlichen Schichten hinzufügen, gehen Dinge kaputt. Oder wenn wir von Anfang an auf gute Markup- und CSS-Praktiken verzichten, beginnen wir mit etwas, das bereits kaputt ist, und verbringen dann Zeit damit, es wieder zum Laufen zu bringen.
Wir gehen davon aus, dass komplexe Probleme immer komplexe Lösungen erfordern. Wir versuchen, Komplexität zu lösen, indem wir Werkzeuge und Technologien erfinden, um ein Problem anzugehen; aber dabei schaffen wir eine weitere Schicht der Komplexität, die ihrerseits eigene Probleme verursacht.
— Max Böck, „On Simplicity“
Vielleicht der schlechteste Grund, eine komplexe Lösung zu wählen, ist, dass sie neu ist, und die *Neuheit* lässt es so erscheinen, als ob die Wahl, sie zu treffen, einen an der Spitze der Technologie und bei der guten Ausführung der Arbeit hält. Alt und langweilig mag genau das sein, was man tun muss, um seine Arbeit gut zu machen.
„Langweilig“ sollte nicht mit „schlecht“ verwechselt werden. Es gibt Technologie, die sowohl langweilig als auch schlecht ist. Das sollte man nicht verwenden. Aber es gibt viele Technologien, die langweilig und gut sind, oder zumindest gut genug. MySQL ist langweilig. Postgres ist langweilig. PHP ist langweilig. Python ist langweilig. Memcached ist langweilig. Squid ist langweilig. Cron ist langweilig.
Das Schöne an Langweiligkeit (in so engem Rahmen) ist, dass die Fähigkeiten dieser Dinge gut verstanden sind. Aber wichtiger ist, dass ihre Ausfallmodi gut verstanden sind.
Rachel Andrew schrieb , dass die Wahl etablierter Technologie für das CMS, das sie baut, ein No-Brainer war, weil es das war, was ihre Kunden *hatten*.
Sie werden weniger von alter und langweiliger Technologie hören. Wenn Sie sich gesund von Tech-Nachrichten ernähren, werden Sie wahrscheinlich nicht viele Blogbeiträge über alte und langweilige Technologie lesen. Das ist wirklich schade, ich persönlich würde das genießen. Aber ich verstehe, Publikationen brauchen frische Inhalte und Autoren sind weniger begeistert von Themen, die seit Jahrzehnten gut beackert wurden.
Wie David DeSandro sagt: „Neue Technologie sorgt für Gesprächsstoff“. Wenn es wenig zu sagen gibt, sagt man es einfach nicht.
Man hört nichts von TextMate, weil TextMate alt ist. Was würde ich twittern? *Benutze immer noch TextMate. Immer noch gut.*
Während wir mehr über neue Technologie hören, ist es alte Technologie, die *bekannter* ist, einschließlich dessen, was sie schlecht kann. Wenn neuere Technologie, vielleicht kompliziertere Technologie, benötigt wird, weil sie einen bekannten Schmerzpunkt löst, ist das großartig, aber wenn nicht…
Sie sind vollkommen in Ordnung, bei dem zu bleiben, was für Sie funktioniert. Je mehr Sie etwas verwenden, desto klarer werden seine Schmerzpunkte. Probieren Sie neue Technologien aus, wenn Sie bereit sind, diese Schmerzpunkte anzugehen. Fühlen Sie sich nicht verpflichtet, Ihren Workflow aufgrund von Gerede zu ändern. Neue Technologie sorgt für Gerede, aber das macht sie nicht besser.
Adam Silver sagt, dass ein langweiliger Entwickler voller Fragen ist,
„Wird das Debuggen von Code schwieriger sein?“, „Wird die Leistung beeinträchtigt?“ und „Werde ich durch Kompilierungszeiten ausgebremst?“
Dan Kim ist auch stolz darauf, langweilig zu sein
Ich muss gestehen – ich bin kein Rockstar-Programmierer. Ich bin auch kein Hacker. Ich beherrsche Ninjutsu nicht. Niemand hat mich je als Zauberer bezeichnet.
Dennoch bin ich stolz darauf, ein guter, solider Programmierer zu sein.
Komplexität ist kein Feind. Komplexität ist wertvoll. Wenn das, woran wir arbeiten, keine Komplexität hätte, wäre es viel weniger wert, da nichts die Konkurrenz aufhalten würde. Unsere Aufgabe ist Komplexität. Oder besser gesagt, unsere Aufgabe ist es, das Maß der Komplexität so zu steuern, dass sie wertvoll und dennoch beherrschbar ist.
Santi Metz hat einen großartigen Artikel, der sich mit verschiedenen Aspekten davon beschäftigt, darunter die Überlegung, wie viel komplizierter Code geändert werden muss
Wir verabscheuen Komplikation, aber wenn sich der Code nie ändert, kostet er uns kein Geld.
Ihr CMS ist vielleicht extrem kompliziert im Hintergrund, aber wenn Sie das nie anfassen, wen kümmert's. Aber wenn Ihr CMS Sie in dem, was Sie tun können, einschränkt und Sie viel Zeit damit verbringen, dagegen anzukämpfen, dann ist diese Komplexität sehr wichtig.
Es ist befriedigend, Sandis Analyse zu lesen, dass es möglich ist, vorherzusagen, wo Code bricht, und diese Punkte durch Komplexität definiert sind. „Ausreißer-Klassen“ (Teile einer Codebasis, die die meisten Probleme verursachen) können identifiziert werden, ohne die Codebasis überhaupt zu sehen
Ich bin nicht mit dem Quellcode dieser Apps vertraut, aber ohne sie zu sehen, fühle ich mich sicher, einige Vorhersagen über die Ausreißer-Klassen zu treffen. Ich vermute, dass sie
- größer sind als die meisten anderen Klassen,
- mit bedingten Anweisungen beladen sind und
- Kernkonzepte der Domäne darstellen
Ich fühle mich gesehen.
Cap Watkins schreibt in „The Boring Designer“
Der langweilige Designer wird vertraut und geschätzt, weil die Leute wissen, dass er sich für das Produkt und den Benutzer einsetzt. Der langweilige Designer stellt Fragen und stützt sich auf die Erfahrung und das Fachwissen anderer, wodurch mit der Zeit noch mehr Vertrauen aufgebaut wird. Er geht selten davon aus, die Antwort zu wissen.
Der langweilige Designer kann einer der besten Anführer eines Teams sein.
Sei also großartig. Sei langweilig.
Es ist so schwer, einen Designer davon zu überzeugen, eine Standard-Selectbox anstelle einer individuell gestalteten Version zu verwenden. Wenn wir bei der Standardversion bleiben, übernehmen wir die gesamte Funktionalität, Zugänglichkeit und plattformübergreifende Kompatibilität von Haus aus. Ein so geringer Aufwand ohne Wartung.
Stattdessen verbringen wir Stunden über Stunden damit, zu versuchen, eine anständige, individuell gestaltete Selectbox zu reproduzieren. Facepalm.
21.000% Zustimmung.
Yep – ich stimme auch zu. Es ist fast so, als würden wir in die Phase kommen, in der wir zur Predigt vor der versammelten Menge sprechen mit diesem „Sei einfach“-Mantra. Ich denke, wir wissen das (oder zumindest viele Entwickler sind davon jetzt überzeugt) – der nächste Schritt ist herauszufinden, wie wir die Zustimmung von zusätzlichen Stakeholdern erhalten (Designer und Markenmanager, die eine einzigartige Markenerfahrung wollen, was ich total verstehe). Wenn wir das knacken, werden wir echte Fortschritte machen.
Obwohl Frameworks und Tools die Entwicklung beschleunigen könnten, könnten sie auch den Prozess verlangsamen. Ich habe Rückschläge erlebt, bei denen ein Framework nicht richtig eingerichtet war, mit Updates in Konflikt geriet und zu stark auf einen bestimmten Entwicklungsprozess angewiesen war.
Ich möchte das am Beispiel eines Autos veranschaulichen. Während das äußere und innere Aussehen für den Verkauf wichtig ist, sind Leistung, Zuverlässigkeit und Wartung der Schlüssel zur Steigerung der Kundenbindung.
Ich sehe viel Verärgerung über einige der beliebten JavaScript-Frameworks (Node, React, Vue usw.), und ich muss zugeben, ich war selbst schuldig. Aber ehrlich gesagt, sie sind nicht das Problem, zumindest nicht an sich. Vielmehr ist es die Art und Weise, wie sie wahllos eingesetzt werden. Sie haben ihre geeigneten Anwendungsfälle, und statische Landingpages gehören typischerweise nicht dazu.
Ich stimme dir zu. „Wahllos“ ist eine gute Beschreibung.
Dieser Artikel gibt mir viel zu denken, wenn ich neue Apps mit trendigen Technologien oder alten, langweiligen Technologien erstelle.
Gut geschrieben, ohne Frage!!!
Ich schätze diesen Beitrag. Die letzten Jahre an Tech-Blogs/Artikeln/Diskussionen waren überwältigend Frontend-Systeme, die einen riesigen Tech-Stack nur für ein „Hallo Welt“ erfordern.
Ich habe mich jahrelang bewusst vom Rande des Geschehens ferngehalten und mich davor bewahrt, in nutzlose Trends zu investieren. Aber ab und zu ist ein „scheinbar“ komplexer Trend tatsächlich nützlich, um andere Dinge zu vereinfachen.
Aber wenn wir uns immer an das Neueste und Beste halten, wird unsere Fähigkeit, zwischen „ein komplexes System, um mit einem Trend Schritt zu halten“ und „ein komplexes System, um andere Dinge zu vereinfachen“ zu unterscheiden, stark beeinträchtigt.
Komplexe Systeme, Frameworks, JavaScript-Lösungen, sie alle beeinträchtigen die Zugänglichkeit, es sei denn, man unternimmt zusätzliche, manchmal außergewöhnliche Anstrengungen, um die Zugänglichkeit hinzuzufügen. HTML hat grundlegende Zugänglichkeit integriert, und assistierende Technologien wie Screenreader für Blinde folgen alle der HTML-Spezifikation.
In Ländern, in denen Gleichstellungs- und Zugänglichkeitsgesetze Zähne haben, mögen all diese komplexen Lösungen sehr schön aussehen, aber sie können Ihrem Unternehmen teure Klagen oder einen Besuch von den zuständigen Rechtsaufsichtsbehörden Ihres Landes einbringen. Halten Sie es einfach; es kann immer noch schön aussehen und jeder kann es auch benutzen.
Ja!
Ich sehe oft zwei Hauptprobleme –
Designer sind inkonsistent. Typografie ändert sich von Bildschirm zu Bildschirm, Dinge, die fast gleich sind und modular gemacht werden könnten, sind gerade unterschiedlich genug, um bedingte Formatierungen zu erfordern. Das erhöht die Komplexität für alle, einschließlich des Designers, der seine eigene Arbeit in Zukunft nicht wiederverwenden kann.
„UX“-Designer wissen oft nicht, für wen sie entwerfen. Sie verbringen keine Zeit mit den Personen, für die sie angeblich Lösungen entwickeln. So verschwenden sie Zeit mit Details, die wenig Wert haben. Verbringen Sie regelmäßig Zeit mit Ihren Nutzern, und Sie werden das Richtige in der richtigen Reihenfolge entwerfen. Und Sie werden sich viel weniger um Verzierungen sorgen.
Ich bin Grafik-/Webdesigner und Frontend-Entwickler.
Nach meiner Erfahrung betrachten die meisten Leute, einschließlich Manager und sogar Kunden, meine effektiven und einfachen Designlösungen mit Misstrauen. Da die Lösung keine wahrgenommene Komplexität aufweist, haben sie das Gefühl, dass sie ihr Geld nicht wert sind. Oft höre ich Leute sagen: „Das hätte ich auch entwerfen können.“
Solange unser Belohnungssystem nicht auf der Schaffung einfacher und effektiver Arbeit basiert, wird Komplexität der König bleiben.
Ich bin mir nicht sicher, ob es möglich ist, eine vollständig responsive Webanwendung nur mit semantischem HTML im Frontend zu erstellen, ohne CSS und ohne JavaScript.
Ich auch, dieser Satz hat eine meiner Augenbrauen gehoben und gebogen.
Aus meiner Erfahrung ist die bestehende Komplexität von Webanwendungen und Software im Allgemeinen oft auf Entwickler zurückzuführen, die den Sinn ihrer Arbeit verfehlen, nämlich – Software das tun zu lassen, was sie tun soll. Viele Entwickler konzentrieren sich zu sehr auf Technologien und vergessen, dass ihr Hauptanliegen funktionierende, wartbare und robuste Software sein sollte, die gut zur Lösung der Probleme dient, für die sie entwickelt wurde.
Wir erlauben uns, Technologien mehr zu genießen, als wir sollten, und vergessen, dass sie nur Werkzeuge sind.
Sie werden sich dafür bedanken, langweilig gewesen zu sein, wenn Sie Ihren eigenen, mehrere Jahre alten Code aktualisieren müssen.
Ich versuche, langweilig zu bleiben in einem Ozean von CMS-Unsinn seit einer sehr, sehr langen Zeit. Es ist schön zu sehen, dass ich nicht der Einzige bin, der es für wichtig hält. Schauen Sie sich meine Seite rgbk.org an und sehen Sie sich den Quelltext an, dann verstehen Sie, was ich meine :)
Michael Scharnagl: