Nachdenkliches zur Wochenmitte: Jeffrey Zeldman „Blue Beanie Day matters“

[Gunnar Bittersmann]

Anlässlich des bevorstehenden Blue Beanie Day (Was’n das?) hat Jeffrey Zeldman einen unbedingt lesenswerten Artikel geschrieben:

This year more than ever, Blue Beanie Day matters

Darin beschreibt er gegenwärtige Fehlentwicklungen in der Webbranche und das Problem, das „Frameworkistas“ dabei darstellen.

Einen Auszug hab ich mal übersetzt:

Das Problem an diesem Top-down-Ansatz ist dreischichtig:

Erstens: Viele junge Entwickler bauen mächtige Portfolios mit Werkzeugen, deren Wirkung und Auswirkungen sie womöglich nicht verstehen und überschauen. Die Resultate davon sind nicht unbedingt benutzbar für alle Nutzer und auf verschiedenen Geräten – und die Entwickler wissen das gar nicht. Vielleicht wissen sie es auch und schauen unter die Haube und beheben das. (Die Resultate sind womöglich auch sehr langsam und überladen, und die Entwickler wissen auch hier nicht, wie das zu beheben wäre.) Die beeindruckenden Portfolios dieser Entwickler unbenutzbarer Websites führen dazu, dass sie eingestellt und in Führungspositionen gehoben werden, wo sie anderen Entwicklern beibringen, Frameworks zu verwenden und damit beeindruckende, aber unbenutzbare Webseiten zu erstellen.

Nur Entwickler, die inklusives Design und Barrierefreiheit verstehen und wertschätzen und die in der Lage sind, ihren eigenen Code zu schreiben, nehmen die Mühen auf sich, die ebenso spannenden wie bahnbrechenden neuen Standards (wie CSS Grid Layout) zu erlernen, mit denen es möglich wird, schlanke, benutzbare, barrierefreie, zukunftskompatible, zukunftsweisende Webseiten zu bauen. Immer weniger Entwickler tun das.

Zweitens: Da Unternehmen auf ihre Senior-Entwickler bauen, die bestimmen, was für Webanwendungen und auf welche Art diese gebaut werden; da Web-Standard-basierte Ansätze aus dem Gedächtnis verschwinden und Frameworks sich im Universum breitmachen, werden in immer mehr Organisationen Framework- und JavaScript-orientierte Entwickler den Ton angeben.

Drittens, und als Folge der ersten beiden Punkte: Jeden Tag werden mehr und mehr Webanwendungen entwickelt, die schlichtweg unbenutzbar sind – nicht benutzbar für Menschen mit Beeinträchtigungen (oder mit dem „falschen“ Telefon oder Browser oder Gerät). Und das wird noch weiter zunehmen, wenn Webstandard-orientierte Entwickler in Rente gehen oder herausgedrängt werden und durch Frameworkistas ersetzt werden.

Ich hoffe, dass noch genügend Entwickler da sind, um sich dem entgegenzusetzen. Und dass die, die sich am 30. November eine blaue Mütze aufsetzen, das nicht tun, weil es hip ist, sondern dass die das denn auch wirklich ernst meinen.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Und dass die, die sich am 30. November eine blaue Mütze aufsetzen, das nicht tun, weil es hip ist, sondern dass die das denn auch wirklich ernst meinen.

Kannst du eine blaue Mütze für selfhtml malen? Ich kann auch mal @Performer fragen.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Hallo Gunnar Bittersmann,

Kannst du eine blaue Mütze für selfhtml malen? Ich kann auch mal @Performer fragen.

Performer hat sich mit ersten Entwürfen zurückgemeldet. Sieht imho sehr stimmig aus.

Bis demnächst
Matthias

[Performer]

Hi @all,

Performer hat sich mit ersten Entwürfen zurückgemeldet. Sieht imho sehr stimmig aus.

Danke. Hier kann sich jetzt jeder ein Bild machen.

Nun ist das Anliegen Zeldmans für SELFHTML ja nicht gerade unwichtig, so dass ich vorschlagen möchte, die Mützenlogos länger als einen Tag einzubinden (vielleicht drei?). Dazu oben im Forum eine kleine Info-Box mit einem Link zur Erklärung?

Ciao, Performer

[Gunnar Bittersmann]

@@Performer

Warum zieht sich das S die Mütze über den Bauch, nicht über den Kopf?

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Warum zieht sich das S die Mütze über den Bauch, nicht über den Kopf?

Weil du anderenfalls entweder das Logo kleiner oder die Grafik höher machen musst. Das eine sieht nicht aus, das andere macht das Layout kaputt.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Hallo Gunnar Bittersmann,

Warum zieht sich das S die Mütze über den Bauch, nicht über den Kopf?

Weil du anderenfalls entweder das Logo kleiner oder die Grafik höher machen musst. Das eine sieht nicht aus, das andere macht das Layout kaputt.

Ich finde, Mütze überm Bauch sieht nicht aus.

Das Logo kleiner machen sollte schon gehen. Eventuell nur in y-Richtung stauchen, damit die Mütze drüberpasst.

Aber vermutlich ist Grafik größer machen der bessere Weg. Damit’s das Layout nicht kaputtmacht, im Stylesheet (für geänderte bzw. zusätzliche Klasse "logo-mit-mütze") die größere Höhe angeben und entsprechenden negativen oberen Abstand angeben.

Wenn man das einmal fürs blue beanie getan hat, kann man dem S auch eine Weihnachtsmütze aufsetzen, so wie die Spinne früher eine hatte.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Aber vermutlich ist Grafik größer machen der bessere Weg. Damit’s das Layout nicht kaputtmacht, im Stylesheet (für geänderte bzw. zusätzliche Klasse "logo-mit-mütze") die größere Höhe angeben und entsprechenden negativen oberen Abstand angeben.

Ja, es scheint im Forum tatsächlich so einfach zu gehen.

Wenn man das einmal fürs blue beanie getan hat, kann man dem S auch eine Weihnachtsmütze aufsetzen, so wie die Spinne früher eine hatte.

Gute Idee(n). Was meinst du, @Performer?

Bis demnächst
Matthias

[Performer]

Hi Gunnar,

Warum zieht sich das S die Mütze über den Bauch, nicht über den Kopf?

du hast von Mode keine Ahnung.

Weil du anderenfalls entweder das Logo kleiner oder die Grafik höher machen musst. Das eine sieht nicht aus, das andere macht das Layout kaputt.

Das war auch mein Gedanken.

Ich finde, Mütze überm Bauch sieht nicht aus.

Bleiben wir mal bei der menschlich-anatomischen Sichtweise, ist dann Mütze-vorm-Gesicht besser?

Das Logo kleiner machen sollte schon gehen. Eventuell nur in y-Richtung stauchen, damit die Mütze drüberpasst.

Würde ich mit einer solchen Idee im CSS-Bereich kommen, hättest du mich ruck-zuck einen Kopf kürzer gemacht. Stauchen machen nur Banausen!

Aber vermutlich ist Grafik größer machen der bessere Weg. Damit’s das Layout nicht kaputtmacht, im Stylesheet (für geänderte bzw. zusätzliche Klasse "logo-mit-mütze") die größere Höhe angeben und entsprechenden negativen oberen Abstand angeben.

Wenn wir wegen einer CSS-Änderung nicht bei Zeldman nachfragen müssen, wie das geht, können wir auch die Grafik 6 Pixel höher machen. Eine Weihnachtsmannmütze male ich dann auch noch. Aber heute nicht mehr und morgen nicht gleich. Herr Wiki wartet auch noch auf eine Antwort von mir.

Ciao, Performer

[Matthias Apsel]

Hallo Performer,

Wenn wir wegen einer CSS-Änderung nicht bei Zeldman nachfragen müssen, wie das geht, können wir auch die Grafik 6 Pixel höher machen. Eine Weihnachtsmannmütze male ich dann auch noch. Aber heute nicht mehr und morgen nicht gleich. Herr Wiki wartet auch noch auf eine Antwort von mir.

Wenns nur 6 Pixel sind, brauchen wir nicht mal das CSS zu ändern, aber die Änderungen wären auch so nur marginal.

Aber mir gefällts nicht. Sieht aus wie eine an einem Garderobenhaken vergessene Mütze. Dann lieber auf der linken Seite.

Bis demnächst
Matthias

[Performer]

Hi Matthias,

Aber mir gefällts nicht. Sieht aus wie eine an einem Garderobenhaken vergessene Mütze. Dann lieber auf der linken Seite.

tja, mit den Assoziationen ist es echt so eine Sache. Eine mittlere Platzierung finde ich einfacher, unprätentiös, nur auf eine Aktion hinweisend, nicht Geschichten erzählend von Bäuchen, Gesichtern oder Wandhaken. Man sollte sich immer wieder K.I.S.S. in Erinnerung rufen.

Ciao, Performer

[Gunnar Bittersmann]

@@Matthias Apsel

Aber mir gefällts nicht. Sieht aus wie eine an einem Garderobenhaken vergessene Mütze.

Etwas gerader aufsetzen und weiter in die Mitte rücken?

Dann lieber auf der linken Seite.

Das wäre dann blau in blau. Bei dem Orange – also rechts – ist das blue beanie schon besser aufgehoben, IMHO.

LLAP 🖖

PS: Fake small caps – pfui Teufel!

[Gunnar Bittersmann]

@@Gunnar Bittersmann

PS: Fake small caps – pfui Teufel!

BTW, verkackt.

LLAP 🖖

[Performer]

Hi Gunnar,

Etwas gerader aufsetzen und weiter in die Mitte rücken?

ich habe das mal gemacht.

Meine Stimme bekommt nach wie vor die erste Version. Es geht bei der Blue Beanie um ein Symbol, es geht um eine Aktion, und es geht um ein Zeichen, dass man diese Aktion unterstützt. Dazu platziert man das Symbol in sein eigenes Logo, mitten rein. In der Gesamtansicht passt das gut zusammen. Bauch hin oder her. Bei einem permanenten Logo wäre die Abwägung sicher eine andere.

Ciao, Performer

[Matthias Apsel]

Hallo Performer,

Meine Stimme bekommt nach wie vor die erste Version. Es geht bei der Blue Beanie um ein Symbol, es geht um eine Aktion, und es geht um ein Zeichen, dass man diese Aktion unterstützt. Dazu platziert man das Symbol in sein eigenes Logo, mitten rein. In der Gesamtansicht passt das gut zusammen. Bauch hin oder her.

+1

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Performer

Etwas gerader aufsetzen und weiter in die Mitte rücken?

ich habe das mal gemacht.

Sieht doch ganz gut aus.

Meine Stimme bekommt nach wie vor die erste Version.

−1

Es geht bei der Blue Beanie um ein Symbol, es geht um eine Aktion, und es geht um ein Zeichen, dass man diese Aktion unterstützt. Dazu platziert man das Symbol in sein eigenes Logo, mitten rein.

Ich habe noch niemanden gesehen, der die Mütze mitten rein plaziert hätte.

Wenn es denn ein Pudelmütze wäre … Oder eine Schiebermütze … Irgendwas, was als Mütze zu erkennen wäre … Aber dieses Beanie sieht für sich allein aus wie ein UFO – einzig die Position oben auf dem Kopf lässt es als Mütze erkennen.

LLAP 🖖

[Performer]

Hi Gunnar,

ich habe das mal gemacht.

Sieht doch ganz gut aus.

ja, kein Widerspruch.

Wenn es denn ein Pudelmütze wäre … Oder eine Schiebermütze … Irgendwas, was als Mütze zu erkennen wäre … Aber dieses Beanie sieht für sich allein aus wie ein UFO – einzig die Position oben auf dem Kopf lässt es als Mütze erkennen.

Selbst dazu braucht es die „richtige“ Assoziation. Das „Ding“ – übrigens vorgegeben von den Urhebern der ganzen Aktion – erklärt sich nicht von selbst, egal wo es platziert ist. Ich halte es für übertrieben und unpassend, wegen eines(!) Tages das Logo samt Stylesheet umzubauen – und Diskussionen über „Bäuche“ und „Köpfe“ zu führen. Die erste Version funktioniert gut als Blickfang, mehr braucht es nicht. An der Stelle möchte ich jetzt ungern den Gerd zitieren. ;-)

Ciao, Performer

[Gunnar Bittersmann]

@@Performer

… einzig die Position oben auf dem Kopf lässt es als Mütze erkennen.

Selbst dazu braucht es die „richtige“ Assoziation.

Bei einem Kopf als Avatar (was wohl die meisten verwenden, die sich das blue beanie aufsetzen) ergibt sie sich. Bei einem Logo wie dem SELFHTML-S nicht zwangsläufig, da hast du recht. Umso wichtiger die Position oben.

Ich halte es für übertrieben und unpassend, wegen eines(!) Tages das Logo samt Stylesheet umzubauen

Die kleine Erweiterung tut ja nun niemandem weh. Außerdem ließe sich das ja – wie gesagt – die ganze Adventszeit nutzen.

Die erste Version funktioniert gut als Blickfang, mehr braucht es nicht.

Ein Blick, der nur ein „Häh??“ auslöst, hätte nicht gefangen werden sollen.

An der Stelle möchte ich jetzt ungern den Gerd zitieren. ;-)

Häh??

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann? (So ähnlich, wie das auch bei der Einladung zum Selftreffen war)

Danke.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann?

Und das am besten heute oder morgen? Ja, das krieg ich hin.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann?

Und das am besten heute oder morgen? Ja, das krieg ich hin.

heute? Wenn ich wieder zurück bin, würde ich das gern fürs Wiki online stellen. Damit erreichen wir schließlich die meisten Leute. Die sollen sich nicht nur über das veränderte Logo wundern.

Im Blog ist es auch Mützenwetter.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Hallo Gunnar Bittersmann,

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann?

Im Wiki ist die Infobox jetzt drin. Im Forum müsste das mal jemand anders machen, @Christian Kruse vielleicht?

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann?

Im Wiki ist die Infobox jetzt drin. Im Forum müsste das mal jemand anders machen, @Christian Kruse vielleicht?

Ich sehe keine Info-Box?

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Im Wiki ist die Infobox jetzt drin. Im Forum müsste das mal jemand anders machen, @Christian Kruse vielleicht?

Ich sehe keine Info-Box?

Ich sehe sie auch nur, wenn ich im Wiki angemeldet bin. Serverseitiger/clientseitiger Cache?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Serverseitiger/clientseitiger Cache?

Gute Frage. Ich sehe die Box inzwischen auf einigen Seiten, aber nicht auf allen.

LG,
CK

[Gunnar Bittersmann]

@@Matthias Apsel

schreibst du bitte einen Zweizeiler, der das Ansinnen erklärt und als Motto des Tages in Forum und Wiki erscheinen kann?

Und das am besten heute oder morgen? Ja, das krieg ich hin.

heute?

Grmpf, hier staut sich gerade einiges auf. Ist doch erst heute Morgen geworden.

@Matthias Apsel hat’s ins Wiki reingestellt.

Darin sollte „aktuelle Diskussion“ eigentlich ein Link zur aktuellen Diskussion (d.h. zum Anfang dieses Threads) sein. Nicht?

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Umso wichtiger die Position oben.

Das S hält die Mütze jetzt schon mal in der Hand, um sie sich übermorgen auf den Kopf zu setzen?

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Wenn es denn ein Pudelmütze wäre … Oder eine Schiebermütze … Irgendwas, was als Mütze zu erkennen wäre … Aber dieses Beanie sieht für sich allein aus wie ein UFO – einzig die Position oben auf dem Kopf lässt es als Mütze erkennen.

Sag ich’s nicht? Aber auf mich hört ja keiner.

LLAP 🖖

[Gunnar Bittersmann]

@@Performer

Ich finde, Mütze überm Bauch sieht nicht aus.

Bleiben wir mal bei der menschlich-anatomischen Sichtweise, ist dann Mütze-vorm-Gesicht besser?

Du hast von Mode keine Ahnung.

LLAP 🖖

[pl]

Danke für die auszugsweise Übersetzung!

Darin beschreibt er gegenwärtige Fehlentwicklungen in der Webbranche und das Problem, das „Frameworkistas“ dabei darstellen.

Einen Auszug hab ich mal übersetzt:

Das Problem an diesem Top-down-Ansatz ist dreischichtig:

Nur Entwickler, die inklusives Design und Barrierefreiheit verstehen und wertschätzen und die in der Lage sind, ihren eigenen Code zu schreiben, nehmen die Mühen auf sich, die ebenso spannenden wie bahnbrechenden neuen Standards (wie CSS Grid Layout) zu erlernen, mit denen es möglich wird, schlanke, benutzbare, barrierefreie, zukunftskompatible, zukunftsweisende Webseiten zu bauen. Immer weniger Entwickler tun das.

Zukunftskompatible Ideen im produktiven Umfeld durchzusetzen ist nicht möglich, weil deren Entwicklung viel zu lange dauern würde.

Ich hoffe, dass noch genügend Entwickler da sind, um sich dem entgegenzusetzen.

Für mich persönlich hat sich dies mit meinem Aussscheiden aus dem Berufsleben gottseidank erledigt. Und wo Du mal wieder an mein Framework denkst:

Das war schon immer sowas wie eine Zufluchtstätte, gerade in Zeiten in denen mir irrationale Entscheidungen auf CTO-Ebene bezüglich Webentwicklung ständig und in Folge gesundheitlich bis zur Berufsunfähigkeit zugesetzt haben -- Ja da hab ich mich gerne in mein stilles Kämmerlein verkrochen und an meinem Framework weiter entwickelt, was letztendlich ein Ergebnis solcher Erfahrungen ist. Die Kollegen sind ja nicht dumm und haben auch gute Ideen. Und Ja, vielleicht hast sogar Du daran mitgearbetet ohne das zu wissen (Aber ich weiß es noch, es ging darum, unter Beibehaltung der Legacy-Parameterliste das Umschalten von NativeCGI // Ajax über einen Custom-Request-Header zu steuern).

MfG

[Gunnar Bittersmann]

@@pl

Zukunftskompatible Ideen im produktiven Umfeld durchzusetzen ist nicht möglich, weil deren Entwicklung viel zu lange dauern würde.

Da wage ich mal zu widersprechen. Entschieden.

Mitunter wird „agile Software-Entwicklung“ so verstanden, dass man sich Scheuklappen aufsetzt und nur das macht, was gerade ansteht, ohne in die Zukunft zu blicken. Wenn sich in Zukunft was ändert, überlegt man halt dann neu – und fängt von vorne an.

Ich halte das für Bullshit. 💩

Erfahrungsgemäß kommt die Zukunft eher früher als später.

Beim ersten Feature ist man natürlich schneller, wenn man erstmal einfach so loslegt ohne groß nachzudenken. Schon beim zweiten stimmt das wohl nicht mehr und beim dritten ist man deutlich langsamer als wenn man beim ersten schon in die Zukunft gedacht hätte.

Harry Roberts hat in seinem Vortrag auf der beyond tellerrand eine ähnliche Rechnung aufgemacht: ab 12:45 im Video.

Wie ich neulich erst schrub, sollte man den zweiten Teil von “Don’t write code that guesses the future, arrange code so you can adapt to the future when it arrives” (Sandi Metz) nicht unterschlagen.

Und wo Du mal wieder an mein Framework denkst:

Nein, an dein Framework dachte ich hier nicht.

Sondern an Frameworks, die gerade hip sind: Angular, React, … Und nächste/n/s Woche/Monat/Jahr wird die nächste Sau durchs Dorf getrieben.

Die Gründe für deren Einsatz sind allzu oft:

1. Andere setzen dieses Framework auch ein. Und Million Fliegen können ja nicht irren.
2. Unsere Entwickler kennen sich mit diesem Framework aus. Und mit keinem anderen.
3. Unsere Entwickler können Aufgaben ohne dieses Framework gar nicht mehr lösen.

1 und 2 habe ich selbst schon erlebt. 3 ist das, wovor Zeldman eindringlich warnt.

Ich will hier aber keinesfalls den Sinn von Frameworks/Bibliotheken infragestellen. Wenn sie mit Bedacht eingestzt werden, sind sie eine gute Sache.

jQuery hat damals™ die JavaScript-Entwicklung schon revolutioniert. Und sicherlich Einfluss auf natives JavaScript gehabt: jetzt gibt es querySelector/querySelectorAll (und damit einen Grund weniger, noch jQuery einzusetzen).

Und 3D möchte ich auch lieber mit Three.js als ohne machen.

Die Frage ist, wie man das einsetzt. Zunächst einmal, ob man ein Framwork deshalb wählt, weil es zu dem jeweiligen Projekt passt. Und nicht wegen obigen 1, 2, 3.

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer. Man kann eine SPA (singe page application) so bauen, dass der Nutzer sekundenlang nichts zu sehen bekommt bis das Framework geladen ist. Man kann eine SPA mit modernen Frameworks aber auch so bauen, dass die vom Nutzer aufgerufene Seite serverseitig gerendert und sofort übertragen wird und erst danach das Framework geladen wird.

Und wenn bei einer SPA Dinge wie Browser-History (incl. Funktion des Back-Buttons) und Möglichkeit des Setzen als Lesezeichen/Verlinkung der einzelnen „Seiten“ (Zustände der SPA) bedacht werden, ist gegen SPA nicht einzuwenden – im Gegenteil.

Nur leider wird allzu oft derartiges nicht bedacht und ein Framework eingesetzt, um die Entwicklung zu vereinfachen, damit aber das Produkt zu verschlechtern.

Entwickler sollten nicht solchen Pfusch abliefern. Und sich von Produktmanagern nicht dazu antreiben lassen, solchen Pfusch abzuliefern.

Entwickler sollten ihre Arbeit nicht so verstehen, sich selbst das Leben so einfach wie möglich zu machen. Sondern das Leben der Nutzer. Wie Jeremy Keith sagt: “In case of conflict, I will always value user needs above developer convenience. That’s called ‘work’.”

LLAP 🖖

[dedlfix]

Tach!

Ich will hier aber keinesfalls den Sinn von Frameworks/Bibliotheken infragestellen. Wenn sie mit Bedacht eingestzt werden, sind sie eine gute Sache.

Den Aspekt vermisse ich meist in deinen Postings, wenn jemand Frameworks einsetzt.

Die Frage ist, wie man das einsetzt. Zunächst einmal, ob man ein Framwork deshalb wählt, weil es zu dem jeweiligen Projekt passt. Und nicht wegen obigen 1, 2, 3.

Besonders diese Frage stellst du nicht - zumindest erinnere ich mich nicht daran -, sondern lieferst üblicherweise gleich native Lösungen. Es ist ja nicht verkehrt, Leute aufzuwecken, wenn sie in 1,2,3 verfallen sind. Aber ohne Hintergründe zu kennen, anscheinend gleich anzunehmen, dass 1,2,3 vorliegt, finde ich gewagt. Wenn du etwas bekämpfen willst, musst du das System verstehen, dazu die Leute und ihre Lage, und dann solltest du für sie eine Lösung finden und nicht gegen sie.

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer.

Na sieh mal da! In dem Fall sind die Fragesteller deine Nutzer.

Wie Jeremy Keith sagt:

Diese Aussagen in Zitaten haben für viele Leser nicht die Bedeutung, die du ihnen beimisst. Wenn man die Personen nicht kennt, hat man keine Anhaltspunkte anhand einer Reputation eine Qualität abzuleiten. Man kann dann nur ihren Inhalt selbst bewerten, wofür man aber das notwendige Fachwissen braucht, um ihn verstehen und einordnen zu können. In dem Fall kannst du die Aussage auch mit eigenen Worten wiedergeben. Das gibt zudem die Möglichkeit, sie an das angenommene oder durch Rückfragen ermittelte Wissensniveau des Probleminhabers sowie an das Problem selbst anzupassen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich will hier aber keinesfalls den Sinn von Frameworks/Bibliotheken infragestellen. Wenn sie mit Bedacht eingestzt werden, sind sie eine gute Sache.

Den Aspekt vermisse ich meist in deinen Postings, wenn jemand Frameworks einsetzt.

Das könnte daran liegen, dass ich meist den Bedacht vermisse, wenn jemand Frameworks einsetzt.

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer.

Na sieh mal da! In dem Fall sind die Fragesteller deine Nutzer.

An der Stelle hast du etwas gründlich missverstanden. Die Nutzer sind die Nutzer des Fragestellers. Das sind die Nutzer, die ich im Auge habe. Alles andere wäre widersinnig.

LLAP 🖖

[dedlfix]

Tach!

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer.

Na sieh mal da! In dem Fall sind die Fragesteller deine Nutzer.

An der Stelle hast du etwas gründlich missverstanden. Die Nutzer sind die Nutzer des Fragestellers. Das sind die Nutzer, die ich im Auge habe. Alles andere wäre widersinnig.

Ich glaube nicht, vielleicht habe ich mich missverständlich ausgedrückt. Mein Anliegen ist, dass du in deinem Auge auch Platz lässt für die Fragesteller. Dein Anliegen ist, und das ist ja nicht verkehrt, den Nutzern von Webseiten das bestmögliche Erlebnis zu bieten. Das machst du mitunter ziemlich missionarisch, auch dann wenn du über den Anwendungsfall des Fragesteller nicht viel weißt. Damit ignorierst du die Nutzer deiner Antworten, also die Fragesteller. Und das sehe ich im gewissen Maße als Äquivalent zur Unachtsamkeit der Webseitenautoren gegenüber deren Nutzern.

"Ziel dieses Forums ist es, die Qualität von Webseiten zu steigern" ist der eine Satz des verlinkten Zitat. Um dieses Ziel zu erreichen, muss man aber die Qualitäten der Webseitenersteller steigern. Und dazu muss man sich zusammen mit ihnen auf den Weg begeben.

Mal ein übertriebenens Beispiel: "Das Eingabefeld ist kaputt. Das ist unbedienbar, da fehlt ein Label." Damit würde man mich nicht wirklich überzeugen. Es ist ja bedienbar - zumindest aus meiner Sicht. "Die Bedienbarkeit des Eingabefeldes kann man verbessern, wenn man für die Beschriftung ein Label-Element verwendet." Dazu eine Erklärung (verlinken), welche Vorteile so ein Label mit sich bringt. So dargestellt hat auch der Fragesteller gleich eine Vorlage, wie er das als Verbesserung gegenüber seinem Chef/Auftraggeber verkaufen kann. Die müssen ja auch überzeugt werden von den guten Dingen. An die kommen wir jedoch nicht direkt ran, aber wir können versuchen, dass die Fragesteller die Dinge für uns verkünden, dass sie also mit uns den Weg gehen. Bezogen auf die Frameworks heißt das unter anderem, dass man sie nicht mit abwertenden Umbenennungen à la Bootcrap oder Windoofs verunglimpft, sondern die Vorteile der besseren Methoden anpreist, sowie einen Weg sucht, den der Fragesteller gehen kann. Wenn das Framework für ihn nur eine Krücke ist, weil er sonst nicht weiß, wie er richtig laufen kann, dann ist es nicht sinnvoll, sie wegzureißen, auf dass er nun am Boden liegt. Dann lieber schauen, wie man mit dem Framework eine Verbesserung erzielen kann. Und das ist keineswegs widersinnig.

Ich beispielsweise bin künstlerisch wenig begabt. Ohne Bootstrap sind meine Webseiten technisch gesehen tiptop, aber sie sehen nach nichts aus. Bootstrap ist für mich ein Werkzeug, mit dem selbst ich ein recht ansehnliches Ergebnis hinbekomme, wenn ich keine Vorlage für eine Gestaltung habe. Prinzipbedingt habe ich dann zwar im Code ein paar Klassennamen mehr als eigentlich notwendig, aber das ist dann eben der Komprimiss.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

"Ziel dieses Forums ist es, die Qualität von Webseiten zu steigern" ist der eine Satz des verlinkten Zitat. Um dieses Ziel zu erreichen, muss man aber die Qualitäten der Webseitenersteller steigern. Und dazu muss man sich zusammen mit ihnen auf den Weg begeben.

Ja. Und ja.

Mal ein übertriebenens Beispiel: "Das Eingabefeld ist kaputt. Das ist unbedienbar, da fehlt ein Label." Damit würde man mich nicht wirklich überzeugen. Es ist ja bedienbar - zumindest aus meiner Sicht.

Da haben wir wohl eine unterschiedliche Vorstellung von Bedienbarkeit.
Deine: Etwas ist bedienbar, wenn es für mich bedienbar ist.
Meine: Etwas ist bedienbar, wenn es für alle bedienbar ist.

Ich halte deine für falsch.

Ziel von SELFHTML sollte es sein, inklusives Design (d.h. von allen benutzbare Webseiten) zu vermitteln. Sonst hätte sich SELFHTML nicht verdient, sich die blaue Mütze aufzusetzen.

"Die Bedienbarkeit des Eingabefeldes kann man verbessern, wenn man für die Beschriftung ein Label-Element verwendet."

s/verbessern/erreichen

Dazu eine Erklärung (verlinken), welche Vorteile so ein Label mit sich bringt.

Gewöhnlich verlinke ich sogar ins SELFHTML-Wiki. Auch wenn die Beschreibung da noch zu wünschen übrig lässt. Ich hab da zumindest mal den Konjunktiv rausgenommen. Und auch andere Fehler.

So dargestellt hat auch der Fragesteller gleich eine Vorlage, wie er das als Verbesserung gegenüber seinem Chef/Auftraggeber verkaufen kann. Die müssen ja auch überzeugt werden von den guten Dingen.

Müssen sie? (Aber besser wär’s schon.)

Wenn das Framework für ihn nur eine Krücke ist, weil er sonst nicht weiß, wie er richtig laufen kann, dann ist es nicht sinnvoll, sie wegzureißen, auf dass er nun am Boden liegt.

Natürlich nicht. Das tu ich auch nicht.

Ich beispielsweise bin künstlerisch wenig begabt. Ohne Bootstrap sind meine Webseiten technisch gesehen tiptop, aber sie sehen nach nichts aus. Bootstrap ist für mich ein Werkzeug, mit dem selbst ich ein recht ansehnliches Ergebnis hinbekomme, wenn ich keine Vorlage für eine Gestaltung habe.

Ich fühle mich gerade an „Design is not veneer“ erinnert.

LLAP 🖖

[dedlfix]

Tach!

Mal ein übertriebenens Beispiel: "Das Eingabefeld ist kaputt. Das ist unbedienbar, da fehlt ein Label." Damit würde man mich nicht wirklich überzeugen. Es ist ja bedienbar - zumindest aus meiner Sicht.

Da haben wir wohl eine unterschiedliche Vorstellung von Bedienbarkeit.
Deine: Etwas ist bedienbar, wenn es für mich bedienbar ist.
Meine: Etwas ist bedienbar, wenn es für alle bedienbar ist.

Ich halte deine für falsch.

Es geht hier nicht im meine Vorstellung, sondern um die des Fragestellers, dessen Position ich für dieses Beispiel eingenommen habe. Natürlich ist diese Vorstellung falsch. Nein, anders, sie ist verbesserbar. Und für mich ist es bereits ein Fortschritt, wenn auch noch lange kein Ruhekissen, wenn der Fragesteller sich auf den Weg begibt.

"Die Bedienbarkeit des Eingabefeldes kann man verbessern, wenn man für die Beschriftung ein Label-Element verwendet."

s/verbessern/erreichen

Da war es wieder, das Auge, das nur den Nutzer im Blick hat.

So dargestellt hat auch der Fragesteller gleich eine Vorlage, wie er das als Verbesserung gegenüber seinem Chef/Auftraggeber verkaufen kann. Die müssen ja auch überzeugt werden von den guten Dingen.

Müssen sie? (Aber besser wär’s schon.)

Ein bisschen Einsicht ist ja schon vorhanden.

Ich beispielsweise bin künstlerisch wenig begabt. Ohne Bootstrap sind meine Webseiten technisch gesehen tiptop, aber sie sehen nach nichts aus. Bootstrap ist für mich ein Werkzeug, mit dem selbst ich ein recht ansehnliches Ergebnis hinbekomme, wenn ich keine Vorlage für eine Gestaltung habe.

Ich fühle mich gerade an „Design is not veneer“ erinnert.

Das Gefühl lasse ich dir gern, aber mit dem Artikel erreichst du mich in meiner Situation nicht. Du kennst sie nicht, und hast sie auch nicht zu ergründen versucht. Die Zielgruppe, wenn ich keine Vorlage bekomme, (von Ausnahmen abgesehen) bin ich. Ich muss für mich kein professionelles Design erstellen, dass ich ohne Anleitung bedienen können muss, und keiner hat einen Nachteil bei meiner Vorgehensweise in solchen Fällen, weil niemand außer mir das Ding bedienen muss. Aber es könnte gut sein, dass du mich verloren hast, und ich deinen Ratschlag auch dann nicht berücksichtige, wenn sich mal eine entsprechende Situation ergibt.

Um mich musst du dir aber keine Sorgen machen, ich war hier nur ein stellvertretendes Beispiel.

dedlfix.

[Camping_RIDER]

Aloha ;)

Mal ein übertriebenens Beispiel: "Das Eingabefeld ist kaputt. Das ist unbedienbar, da fehlt ein Label." Damit würde man mich nicht wirklich überzeugen. Es ist ja bedienbar - zumindest aus meiner Sicht.

Da haben wir wohl eine unterschiedliche Vorstellung von Bedienbarkeit.
Deine: Etwas ist bedienbar, wenn es für mich bedienbar ist.
Meine: Etwas ist bedienbar, wenn es für alle bedienbar ist.

Ich halte deine für falsch.

Ziel von SELFHTML sollte es sein, inklusives Design (d.h. von allen benutzbare Webseiten) zu vermitteln. Sonst hätte sich SELFHTML nicht verdient, sich die blaue Mütze aufzusetzen.

Das erinnert mich im Kern dann doch an die Debatte bezüglich des Tic-Tac-Toe, die du mit @Felix Riesterer geführt hattest. Dabei ging es (man möge mir verkürzende oder inakkurate Darstellung verzeihen) darum, dass du zum Grundsatz erhoben hattest, dass ein Tutorial in allen Aspekten von Anfang an Prinzipien von gutem Webdesign komplett umfassen müsse, während Felix zum Grundsatz erhoben hatte, man müsse die Leser, wenn nötig auch unter bewusster / angekündigter Nicht-Beachtung von best practices, zuerst einmal abholen und durch die dadurch verringerte Komplexität motivieren.

Analog dazu wirbt dedlfix hier nach meinem Verständnis dafür, den Fragesteller nicht vor den Kopf zu stoßen (selbst wenn der Kopfstoß aus aufgeklärter Sicht gerechtfertigt wäre), sondern den Fragesteller dort abzuholen wo er steht^[1] und ihm eine goldene Brücke zum Ziel zu schlagen, selbst wenn das bedeutet, dass man unterwegs zu schwammigeren Definitionen als den vom Wissenden-Standpunkt Richtigen greifen muss.

Beide Standpunkte haben ihre sinnvolle Begründung; ich persönlich stehe eher hinter zweiterem; der erstere erscheint mir ineffektiv was das Ziel angeht, den Fragesteller weiterzubilden und auf dem Weg zur Lösung mitzunehmen, nicht zuletzt weil dabei für mich auch eine Indoktrination anklingt, die den ein oder anderen Fragesteller womöglich schon für sich dazu bringt, den Ratschlag auszuschlagen. Aber nochmal: das ist meine persönliche Meinung; beide Standpunkte haben ihre sinnvollen Gründe und keiner davon ist falsch.

Grüße,

RIDER

---

1. auf "nicht-bedienbar" steht er von sich aus nicht, sonst hätte er es nicht so umgesetzt ↩︎

[Christian Kruse]

Hallo Gunnar,

Ich fühle mich gerade an „Design is not veneer“ erinnert.

Ich habe nach dem Einleitungssatz den Artikel wieder zugemacht.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Ich fühle mich gerade an „Design is not veneer“ erinnert.

Ich habe nach dem Einleitungssatz den Artikel wieder zugemacht.

Das ist bedauerlich. Vermutlich gehörst du zur Zielgruppe.

Vielleicht gibst du ihm eine zweite Chance?

Mit „Einleitungssatz“ meinst du den kursiv gesetzten? Was hat dich daran abgeschreckt?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Das ist bedauerlich. Vermutlich gehörst du zur Zielgruppe.

Nein, da bin ich nahezu sicher. Ich entwickele keine Webseiten und hab mit Design nichts am Hut.

Mit „Einleitungssatz“ meinst du den kursiv gesetzten? Was hat dich daran abgeschreckt?

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

Hm, ich kann darin nichts Herablassendes finden.

LLAP 🖖

[dedlfix]

Tach!

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

Hm, ich kann darin nichts Herablassendes finden.

Wenn du dieses Manko als Teil des Problems erkennst, kommen wir einen Schritt vorwärts.

dedlfix.

[Christian Kruse]

Hallo Gunnar,

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

Hm, ich kann darin nichts Herablassendes finden.

Ich denke, dass das ein Teil des Problems ist?

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

Hm, ich kann darin nichts Herablassendes finden.

Ich denke, dass das ein Teil des Problems ist?

Hat euch die Erdstrahlung erfasst?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Hat euch die Erdstrahlung erfasst?

Das Zitat ist geklaut aus den BOFH excuses.

Was das inhaltliche angeht: shrug ich will dir nicht auf die Füsse treten, ich habe nur versucht darzulegen, wie sich der Artikel aus meiner Sicht (kein Designer) darstellt. Was du daraus machst musst du selber wissen 😊

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Was das inhaltliche angeht: shrug ich will dir nicht auf die Füsse treten, ich habe nur versucht darzulegen, wie sich der Artikel aus meiner Sicht (kein Designer) darstellt. Was du daraus machst musst du selber wissen 😊

Ohne Begründung, warum sich der Artikel aus deiner Sicht so darstellt: gar nichts.

LLAP 🖖

[Mitleser]

Nein, ich meinte den ersten Absatz, Einleitung war der falsche Begriff. Abgeschreckt hat mich der Ductus/Ton. Ich habe keine Lust auf solche herablassenden Rants.

Hm, ich kann darin nichts Herablassendes finden.

Ich denke, dass das ein Teil des Problems ist?

Hat euch die Erdstrahlung erfasst?

Tatsächlich musste man hier Angst um Dich haben, dass Dich der böse Geist der differenzierten Sichtweise und Argumentation ergriffen hat. Danke für Deine nachfolgenden Darlegungen, Du scheinst das ja schnell wieder in den Griff bekommen zu haben.

[dedlfix]

Tach!

Wenn das Framework für ihn nur eine Krücke ist, weil er sonst nicht weiß, wie er richtig laufen kann, dann ist es nicht sinnvoll, sie wegzureißen, auf dass er nun am Boden liegt. Dann lieber schauen, wie man mit dem Framework eine Verbesserung erzielen kann. Und das ist keineswegs widersinnig.

Da fiel mir doch noch ein schöner Vergleich ein. Wenn ohne die Krücke nur noch schlimmere Ergebnisse zustandekommen, dann ist es vielleicht sinnvoll, die Krücke zu verbessern und zu einem Exoskelett auszubauen. Das gibt die Chance, auch mit der nicht totzubekommenden Arbeitsweise bessere Ergebnisse zu erhalten, das erhöht die Lebensqualität der Betroffenen und gibt den fortgeschrittenen Technikern eine Aufgabe. Diese Strategie ist übrigens nicht neu und im Allgemeinen auch nicht erfolglos. Es ist die: Wenn du sie nicht schlagen kannst, verbünde dich mit ihnen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Da fiel mir doch noch ein schöner Vergleich ein. Wenn ohne die Krücke nur noch schlimmere Ergebnisse zustandekommen, dann ist es vielleicht sinnvoll, die Krücke zu verbessern und zu einem Exoskelett auszubauen.

Vielleicht. Es bleibt aber eine Prothese.

An anderer Weg für den Betroffenen mag eine Physiotherapie sein, damit er wieder auf die Beine kommt – auf seine eigenen.

Und für diese Therapie wird man einen darauf spezialierten Physiotherapeuten aufsuchen, nicht zum Orthopädietechniker gehen.

Zurückübertragen auf die Webentwicklung heißt das: Software-Entwickler sollten keine Nutzerinterfaces gestalten, sondern das Leuten überlassen, die was davon verstehen. (Es mag wenige geben, die in Personalunion beides können; die sind aber die Ausnahme.)

Es ist natürlich OK, wenn sich jemand für sein privates Projekt keinen solchen Spezialisten leisten kann und es deshalb selbst machen muss – so gut er eben kann, auch unter Zuhilfenahme von Dingen wie Bootstrap.

Es ist aber nicht OK, wenn Unternehmen, die nicht gerade am Hungertuch nagen, sich keine solchen Spezialisten leisten (Freelancer, aber am besten festangestellt). Aber auch das habe ich schon mehr als einmal erlebt.

Technologiegetriebene Entwicklung sucks. Da kommt kein vernünftiges Produkt bei raus. Produktentwicklung muss designgetrieben sein: nutzerzentriert. Und das sage ich als Entwickler!

LLAP 🖖

[dedlfix]

Tach!

An anderer Weg für den Betroffenen mag eine Physiotherapie sein, damit er wieder auf die Beine kommt – auf seine eigenen.

Und für diese Therapie wird man einen darauf spezialierten Physiotherapeuten aufsuchen, nicht zum Orthopädietechniker gehen.

Mal Hand aufs Herz, in welcher Rolle siehst du dich in diesem Szenario?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

An anderer Weg für den Betroffenen mag eine Physiotherapie sein, damit er wieder auf die Beine kommt – auf seine eigenen.

Und für diese Therapie wird man einen darauf spezialierten Physiotherapeuten aufsuchen, nicht zum Orthopädietechniker gehen.

Mal Hand aufs Herz, in welcher Rolle siehst du dich in diesem Szenario?

In der Vermittlerrolle.

Falls jemand ein Unternehmen/eine Organisation kennt, denen bewusst ist, dass sie einen solchen Vermittler brauchen, würde ich gern davon hören.

LLAP 🖖

[dedlfix]

Tach!

Zurückübertragen auf die Webentwicklung heißt das: Software-Entwickler sollten keine Nutzerinterfaces gestalten, sondern das Leuten überlassen, die was davon verstehen. (Es mag wenige geben, die in Personalunion beides können; die sind aber die Ausnahme.)

Es ist natürlich OK, wenn sich jemand für sein privates Projekt keinen solchen Spezialisten leisten kann und es deshalb selbst machen muss – so gut er eben kann, auch unter Zuhilfenahme von Dingen wie Bootstrap.

Es ist aber nicht OK, wenn Unternehmen, die nicht gerade am Hungertuch nagen, sich keine solchen Spezialisten leisten (Freelancer, aber am besten festangestellt).

Sehe ich das richtig so, dass das eigentliche Problem ist, dass die Leute keine Spezialisten zur Seite gestellt bekommen und deshalb nach allem greifen, was ihnen zielführend erscheint? Ist das dann immer noch eine passende Strategie, den Leuten ihre Tools auszureden? Führt das dazu, dass Spezialisten angeheuert werden?

Technologiegetriebene Entwicklung sucks. Da kommt kein vernünftiges Produkt bei raus. Produktentwicklung muss designgetrieben sein: nutzerzentriert. Und das sage ich als Entwickler!

Deswegen plädiere ich ja dafür, die Problematik mit den Frameworks auch nutzerzentriert (die Nutzer des Frameworks meine ich, nicht die Nutzer es damit hergestellten Produkts) zu betrachten und nicht nur technologiegetriebene Problemlösungen zu suchen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Es ist aber nicht OK, wenn Unternehmen, die nicht gerade am Hungertuch nagen, sich keine solchen Spezialisten leisten (Freelancer, aber am besten festangestellt).

Sehe ich das richtig so, dass das eigentliche Problem ist, dass die Leute keine Spezialisten zur Seite gestellt bekommen und deshalb nach allem greifen, was ihnen zielführend erscheint?

Nein. Das eigentliche Problem ist, dass die Leute keine Spezialisten zur Seite gestellt bekommen. Punkt.

Das ist keine Entscheidung von Entwicklern, sondern eine Management-Entscheidung. Entwickler können diese aber beeinflussen, indem sie klar artikulieren, dass sie einen Designer zur Seite brauchen; dass sie auch „nach allem greifen“ und das Produkt auch ohne einen solchen entwicklen könnten, es dann aber Kacke wird.

Nur bräuchte es dazu bei Entwicklern zweierlei:

1. die Einsicht, dass sie eben das Produkt nicht ohne Designer entwickeln können/sollten
2. den Arsch in der Hose, das dem Management auch zu sagen (wozu eine Unternehmenskultur gehört, in der das überhaupt möglich ist)

Oft fehlt es Entwicklern aber schon an ersterem.

Technologiegetriebene Entwicklung sucks. Da kommt kein vernünftiges Produkt bei raus. Produktentwicklung muss designgetrieben sein: nutzerzentriert. Und das sage ich als Entwickler!

Deswegen plädiere ich ja dafür, die Problematik mit den Frameworks auch nutzerzentriert (die Nutzer des Frameworks meine ich, nicht die Nutzer es damit hergestellten Produkts) zu betrachten

In anderen Worten: entwicklerzentriert.

und nicht nur technologiegetriebene Problemlösungen zu suchen.

… also doch technologiegetrieben.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Deswegen plädiere ich ja dafür, die Problematik mit den Frameworks auch nutzerzentriert (die Nutzer des Frameworks meine ich, nicht die Nutzer es damit hergestellten Produkts) zu betrachten

In anderen Worten: entwicklerzentriert.

und nicht nur technologiegetriebene Problemlösungen zu suchen.

… also doch technologiegetrieben.

Seit wann sind "Entwickler" denn "Technologie"^[1]? Du scherst hier zu viel über den selben Kamm, wenn du mich fragst. Machts natürlich einfacher, aber ob dieser Haarschnitt dann auch noch die gewünschte Wirkung hat...?

Grüße,

RIDER

---

1. Ja, mir ist auch klar, dass Entwickler mit Technologie umgehen und deshalb eine entwicklerzentrierte Betrachtung auch eine technologiezentrierte Komponente enthält. Du ignorierst hier aber einfach, dass es eine echte Teilmenge darstellt und setzt die Begrifflichkeiten trotzdem gleich. ↩︎

[Gunnar Bittersmann]

@@Camping_RIDER

… also doch technologiegetrieben.

Seit wann sind "Entwickler" denn "Technologie"[^1]?

„Technologiegetrieben“ meint: von der Technologie-Abteilung, von der IT. Da, wo sich die Entwickler tummeln. Also von den Entwicklern.

Du scherst hier zu viel über den selben Kamm, wenn du mich fragst.

Nein, wenn du mich fragst.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

… also doch technologiegetrieben.

Seit wann sind "Entwickler" denn "Technologie"[^1]?

„Technologiegetrieben“ meint: von der Technologie-Abteilung, von der IT. Da, wo sich die Entwickler tummeln. Also von den Entwicklern.

Hm, okay - für mich bedeutet das Wort etwas anderes; gut, dass wir darüber geredet haben.

Dann bleibt mir aber der jumping point irgendwie verborgen.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Hm, okay - für mich bedeutet das Wort etwas anderes; gut, dass wir darüber geredet haben.

Dann bleibt mir aber der jumping point irgendwie verborgen.

Technologiegetrieben:

Entwickler beschließen (womöglich gar nicht im Team, sondern der CTO gibt vor): Wir setzen Framework X ein. Wegen ha’m wa vorher schon so gemacht und machen andere auch so (Punkte 1 und 2 – ganz oben auf meiner Liste). Die Entscheidung wird gefällt, bevor überhaupt völlig klar ist, was denn eigentlich genau entwickelt werden soll.

Designer kommen dann und sagen: Wir hätten’s gern so und so. Entwicker: Nee, geht nicht, könn’ wa nicht. Das gibt unser Framework nicht her.

Aus der Luft gegriffen? Leider nein. Ich hab das so erlebt.

Designgetrieben:

Durch Analyse der Bedürfnisse unserer Zielgruppe und Nutzertests mit Prototypen sind wir zu dem Schluss gelangt, dass das Produkt so und so aufgebaut sein soll, so und so aussehen soll, sich so und so verhalten soll. Das kriegt ihr doch hin, oder?

Entwickler: Hm, mit dem Framework X (was wir fürs vorige Projekt genommen haben) wird das nichts. Aber Framework Y könnte hierfür passend sein. Wir werden uns da reinarbeiten.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Danke für die Klärung - jetzt verstehe ich den Punkt.

Wobei das...

Aus der Luft gegriffen? Leider nein. Ich hab das so erlebt.

...bedauerlich ist, aber nicht zwangsläufig passieren muss.

Es gibt durchaus noch die Abstufung, dass Entwickler im Fall absoluter Inkompatibilität des ihnen geläufigen Frameworks dann doch noch ein anderes wählen, statt die Arbeit sinngemäß zu verweigern (oder bewusst schlecht umzusetzen).

In meinen Augen ist das Ganze welches-Framework-benutzen-wir-Dingens ein Trade-off zwischen Einarbeitungszeit sowie Entwicklererfahrung auf der einen Seite und der Problemkompatibilität des zu verwendenden Frameworks auf der anderen Seite.

Trade-off bedeutet dann aber auch, dass extreme Maßnahmen auch keine sinnvollen Ergebnisse liefern: Wenn Framework X optimal dazu geeignet ist, Problem Y zu lösen, die damit betrauten Entwickler aber bisher nur Framework Z können, kann es durchaus sein (sofern Z mit Y vielleicht nicht optimal, aber dennoch eingeschränkt kompatibel ist), dass das Ergebnis, das durch Anwendung von Framework Z entsteht, besser und wirtschaftlicher ist als das Ergebnis, das durch Anwendung von Framework X entsteht - ich messe der Einarbeitungszeit sowie der erfahrungsbedingten vorausschauenden Umschiffung von Klippen eine nicht-geringe Bedeutung zu, was Kosten und Qualität der Software angeht.

In dem Fall sind die Extreme die worst cases - und der von dir zurecht kritisierte Fall, dass X inkompatibel zu Y sein könnte, aber dennoch eingesetzt wird, ist in etwa genauso dramatisch wie das andere Extrem, nämlich, dass Z ohne absolute Notwendigkeit eingesetzt wird und die damit entstandene Software mangels Entwicklererfahrung sowohl teuer als auch ineffizient und problembehaftet ist.

Das zweite Extrem hast du mMn bisher eher unter den Tisch fallen lassen. Ich gehe davon aus, dass (Wortwahl gemäß deiner obigen Definition) weder designgetriebene noch technologiegetriebene Entwicklung für sich zum bestmöglichen^[1] Ziel führt - der optimale Weg wird irgendwo dazwischen liegen^[2].

Ich verstehe auch @dedlfix Einlassungen zum Teil so, dass ihm die Betrachtung zu einseitig ist (auch wenn ich mir die Polemik, die du zurecht kritisierst, nicht zu eigen machen will).

Grüße,

RIDER

---

1. Natürlich unterliegt bestmöglich wieder den Zielen der Softwareentwicklung. Naturgemäß ist das eine Balance zwischen Kosten und Softwarequalität (die insbesondere Fehlerdichte, aber auch andere Gütekriterien, z.B. designbezogene, umfasst). ↩︎

2. Natürlich ändert sich das, wenn man andere Ziele der Softwareentwicklung zugrundelegt. Es ist aber aus gutem Grund sicher alles andere als konsensfähig, die Waagschale hier deutlich auf eine Seite zu verschieben. ↩︎

[dedlfix]

Tach!

„Technologiegetrieben“ meint: von der Technologie-Abteilung, von der IT. Da, wo sich die Entwickler tummeln. Also von den Entwicklern.

So kommt mir die Argumentation vor. Sie wird davon getrieben, dass Frameworks Mist seien und die Leute keine Ahnung haben, ordentliche Ergebnisse zu erstellen. Das sehe ich als den technikgetriebenen Ansatz an, das Problem anzugehen. Die Ergebnisse müssen besser werden, aber die Hersteller (=Entwickler) brauchen wir dazu nicht, lasst mal die Designer ran. <del>Ist das das Ziel, dass die Designer mit an den Tisch wollen? Entschuldigung, den Aspekt streiche ich wieder, der geht mir zu sehr in Richtung Verschwörungstheorie.</del> Vielleicht sehe ich das auch zu schwarz, ich habe diese Thematik nur am Rande verfolgt, wenn sie zufällig an mir vorbeilief. Aber das sehe ich ebenso als Teil des Problems an, sie erreicht mich nicht. Ich sehe das Problem, aber sie kümmert sich nicht wirklich um mich, was soll ich mich da um sie kümmern? Meine Lebensrealität sieht so aus, dass sich das Produkt auch so verkauft. Ist ziemlich ignorant von mir, ich weiß.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

So kommt mir die Argumentation vor. […] Ist ziemlich ignorant von mir, ich weiß.

Enthält das Posting irgendetwas außer mir in den Mund gelegte Worte, die ich so nicht gesagt habe, und Polemik? Wenn, dann ist mir das entgangen.

LLAP 🖖

[dedlfix]

Tach!

Enthält das Posting irgendetwas außer mir in den Mund gelegte Worte, die ich so nicht gesagt habe, und Polemik? Wenn, dann ist mir das entgangen.

Das ist nicht meine Absicht, ich wollte nur beschreiben, wie ich das empfinde oder wie das einer der Entwickler empfinden könnte. Kommunikation ist ja nicht nur das was gesagt wird, sondern auch das was gehört wird.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

Das ist nicht meine Absicht, ich wollte nur beschreiben, wie ich das empfinde oder wie das einer der Entwickler empfinden könnte. Kommunikation ist ja nicht nur das was gesagt wird, sondern auch das was gehört wird.

Eigentlich nur letzteres.

Aber ich kann Gunnar schon verstehen. Firmen, die eigentlich genug Geld hätten, um beispielsweise ihren Internetauftritt wirklich barrierefrei zu gestalten, tun dies nicht. Aus Gründen, die imho wohl immer nur auf Profit hinauslaufen.

Bis demnächst
Matthias

[dedlfix]

Tach!

Aber ich kann Gunnar schon verstehen. Firmen, die eigentlich genug Geld hätten, um beispielsweise ihren Internetauftritt wirklich barrierefrei zu gestalten, tun dies nicht. Aus Gründen, die imho wohl immer nur auf Profit hinauslaufen.

Dieser Meinung kann ich mich anschließen. Üblicherweise wird man das auf diesen Grund herunterbrechen können. Wenn sich kein Vorteil daraus ergibt, wird es nicht gemacht. Wenn Entwickler ebenso denken, wer kann es ihnen verwehren?

dedlfix.

[1unitedpower]

Die Gründe für deren Einsatz sind allzu oft:

1. Andere setzen dieses Framework auch ein. Und Million Fliegen können ja nicht irren.
2. Unsere Entwickler kennen sich mit diesem Framework aus. Und mit keinem anderen.
3. Unsere Entwickler können Aufgaben ohne dieses Framework gar nicht mehr lösen.

1 und 2 habe ich selbst schon erlebt. 3 ist das, wovor Zeldman eindringlich warnt.

Ich habe alle drei schon erlebt. Den ersten Grund finde ich aber völlig legitim. Einen bedeutsamen Teil meiner Arbeit verwende ich darauf, Trends in der Entwickler-Szene zu evaluieren. Der produktive Einsatz von neuartigen Technologien ist dabei eine unverzichtbare Investition, um ein vollständiges Bild zeichnen zu können. Das impliziert natürlich immer auch ein gewisses Wagnis; Experimente können schief gehen und dann sollte man gewappnet sein. Meine persönlichen Erfahrungen sind da durchaus gemischt: jQuery habe ich zu früh abgekündigt, WebComponents habe ich overhyped, React+Redux habe ich erfolgreich an meinem Arbeitsplatz etabliert. Wenn ein Experiment droht aus dem Ruder zu laufen, wird es richtig schwierig, dann gilt es Schadensminimierung zu betreiben. Besonders unangenehm wird es, wenn man bei seine(m/r) Vorgesetzten dafür Rechenschaft ablegen muss und die nötigen Mittel für eine Korrektur nicht bewilligt werden. Das löst innere Konflikte aus: Verrate ich meine Ideale zu Gunsten von Wirtschaftlichkeit oder akzeptiere ich den Fehlschlag und nutze ihn, um meine Ideale in Zukunft aus einer gestärkten Position verteidigen zu können? Ich glaube darauf lässt sich keine exklusive Antwort geben, man wird stattdessen einen Kompromiss finden müssen.

[Camping_RIDER]

Aloha ;)

Zukunftskompatible Ideen im produktiven Umfeld durchzusetzen ist nicht möglich, weil deren Entwicklung viel zu lange dauern würde.

Da wage ich mal zu widersprechen. Entschieden.

Mitunter wird „agile Software-Entwicklung“ so verstanden, dass man sich Scheuklappen aufsetzt und nur das macht, was gerade ansteht, ohne in die Zukunft zu blicken. Wenn sich in Zukunft was ändert, überlegt man halt dann neu – und fängt von vorne an.

Ich halte das für Bullshit. 💩

Erfahrungsgemäß kommt die Zukunft eher früher als später.

Ich glaube hier liegt (hinsichtlich der Zielsetzung) ein Vergleich zwischen Äpfeln und Birnen vor. Agile Softwareentwicklung entspringt zu extrem großen Stücken der modernen Wahrnehmung der Softwaretechnik als Ingenieursdisziplin (Software Engineering). Dementsprechend handelt es sich dabei im Kern um die Anwendung von Ingenieursprinzipien - Ziel dabei ist nicht, ein perfektes Stück Software zu erhalten, sondern mit möglichst wenig Aufwand ein Stück Software zu erhalten, das bei gleichzeitig möglichst wenig Fehlerbehaftung die formulierten Anforderungen möglichst gut erfüllt. Wenn Barrierefreiheit / Zukunftssicherheit / ... keine entsprechend priorisierte Anforderung im Entwicklungsprozess ist, so wird diese im Endprodukt auch nicht berücksichtigt sein - völlig zurecht aus der Warte der Ingenieursdisziplin.

Die Softwareentwicklung als Ingenieursdisziplin zu begreifen und entsprechende Prinzipien in selbiger anzuwenden ist ja eine Lehre aus der Softwarekrise um Softwareentwicklung wirtschaftlich machbar zu halten.

Traditionelle Softwareentwicklung, die hier nach meiner Lesart den unausgesprochenen Gegenpol darstellt, tickt anders. Da versucht man am Ende ein Stück Software zu erhalten, das möglichst perfekt ist und möglichst viele positive Eigenschaften (z.B. Barrierefreiheit) hat, auch wenn diese nicht explizit gefordert waren - da traditionelle Softwareentwicklung den Ingenieursprinzipien modernen Software-Engineerings eben nicht folgt.

Das ist quasi Ingenieurstechnik vs. Handwerkskunst und ziemlich unvergleichbar. Für das Bauen einer Holzbrücke über einem Tal beauftrage ich vielleicht lieber einen Ingenieur als einen Schreiner - während der Ingenieur sicher nicht die erste Wahl ist, wenn ich einen neuen Esszimmerstuhl anfertigen lassen will.

Grüße,

RIDER

[pl]

Die Frage ist, wie man das einsetzt. Zunächst einmal, ob man ein Framwork deshalb wählt, weil es zu dem jeweiligen Projekt passt. Und nicht wegen obigen 1, 2, 3.

Ein Framework lohnt sich immer dann einzusetzen, wenn die zu programmierenden Abläufe immer wieder dieselben sind. Und genau das ist bei jedem Request-Response-Zyklus der Fall, woran auch bestimmte Request-Parameter nichts ändern -- sie führen allenfalls zu Verzweigungen.

MfG

[Rafael]

Hallo!

Mitunter wird „agile Software-Entwicklung“ so verstanden, dass man sich Scheuklappen aufsetzt und nur das macht, was gerade ansteht, ohne in die Zukunft zu blicken. Wenn sich in Zukunft was ändert, überlegt man halt dann neu – und fängt von vorne an.

Man fängt nicht von vorne an. Man ändert bloss seine Strategie wenn Bedingungen und Anforderungen sich ändern.

Sondern an Frameworks, die gerade hip sind: Angular, React, … Und nächste/n/s Woche/Monat/Jahr wird die nächste Sau durchs Dorf getrieben.

Angular ist 6 Jahre alt. React ist "erst" 3 Jahre alt, wird aber schon seit 2011 im Newsfeed von www.Facebook.com eingesetzt. Beide sind etabliert und im breiten Einsatz.

6 Jahre sind in der IT eine sehr lange Zeit. Zum Vergleich: "Responsive Design" ist auch "erst" 6 Jahre alt. R.D. ist heute nicht mehr weg zu denken. Bezeichnest du das auch als "gerade hip"??

Ich denke dir fehlt die Fähigkeit die Anwendungsreife einer Software einzuschätzen. Verstehst du denn die Merkmale dieser Frameworks gegenüber vorherigen Arbeitsweisen? Und damit meine ich nicht Einfachheit für Entwickler.

Die Gründe für deren Einsatz sind allzu oft:

1. Andere setzen dieses Framework auch ein. Und Million Fliegen können ja nicht irren.
2. Unsere Entwickler kennen sich mit diesem Framework aus. Und mit keinem anderen.
3. Unsere Entwickler können Aufgaben ohne dieses Framework gar nicht mehr lösen.

1 und 2 habe ich selbst schon erlebt. 3 ist das, wovor Zeldman eindringlich warnt.

Möglicherweise hast du in den letzten Jahren einmal in die IT-Stellenanzeigen geschaut. Selbst jemand, der zwei-drei verbreitete Programmiersprachen beherrscht, wird in 95% der Anzeigen nichts passendes finden. Das liegt daran dass immer Kenntnisse in bestimmten Tools und Frameworks gefordert werden. Ein Arbeitnehmer muss sich spezialisieren.

Das ist normal und auch sinnvoll. Eine Firma entscheidet sich für einen Stack und bleibt dann erst einmal dabei. Dass andere Firmen denselben Stack einsetzen ist in der Tat ein wichtiges Kriterium! Das Erlernen eines Frameworks erfordert Zeit. Mitarbeiter müssen geschult werden. Eine Migration zu anderen Frameworks macht man nicht im Handumdrehen.

Ich sehe auch kein Problem an Punkt 3. Man verwendet doch gerade fremde Software damit man das Rad nicht wiedererfinden muss.

Ein guter Programmierer in einem guten Team kann sämtliche Aufgaben "from scratch" lösen. THEORETISCH. Je nach Aufgabe erfordert das ein langjähriges Studium, die Lektüre von Fachliteratur und jahrelange Arbeit. Und dann ist es nicht einmal halb so gut wie existierende Lösungen. Es ist also PRAKTISCH unmöglich. Nebenbei wäre es heraus geworfenes Geld.

Als Programmierer verwenden wir den ganzen Tag Code, den andere geschriebem haben und den wir PRAKTISCH nicht selbst schreiben können. Es ist weder möglich noch erstrebenswert in der heutigen IT alles verstehen zu wollen oder sogar selbst programmieren zu wollen.

Ich will hier aber keinesfalls den Sinn von Frameworks/Bibliotheken infragestellen.

Das machst du aber mit deiner Kritik.

jQuery hat damals™ die JavaScript-Entwicklung schon revolutioniert. Und sicherlich Einfluss auf natives JavaScript gehabt: jetzt gibt es querySelector/querySelectorAll (und damit einen Grund weniger, noch jQuery einzusetzen).

Es gibt auch heute noch gute Gründe die für jQuery sprechen. querySelector hin oder her.

VG

Rafael

[pl]

Es gibt auch heute noch gute Gründe die für jQuery sprechen. querySelector hin oder her.

Vor Allem ein einheitlicher Code für verschiedene Browser ;)

[Gunnar Bittersmann]

@@pl

Es gibt auch heute noch gute Gründe die für jQuery sprechen. querySelector hin oder her.

Vor Allem ein einheitlicher Code für verschiedene Browser ;)

*gähn* Du bist bei DHTML stehengeblieben?

LLAP 🖖

[pl]

@@pl

Es gibt auch heute noch gute Gründe die für jQuery sprechen. querySelector hin oder her.

Vor Allem ein einheitlicher Code für verschiedene Browser ;)

*gähn* Du bist bei DHTML stehengeblieben?

Nein ganz im Gegenteil. Für rückständige Browser eine extra Wurst zu braten war noch nie mein Ding.

[Gunnar Bittersmann]

@@Rafael

Zum Vergleich: "Responsive Design" ist auch "erst" 6 Jahre alt. R.D. ist heute nicht mehr weg zu denken.

(Ich denk mir mal die zwei falsch gesetzten Leerzeichen weg.)

Und du irrst, responsive web design ist nicht erst 6 Jahre alt, sondern wesentlich älter.

Der Begriff mag 6 Jahre alt sein – zum ersten Mal verwendet von Ethan Marcotte in seinem gleichnamigen Artikel. Aber was finden wir dort gleich am Anfang? Den Bezug auf John Allsopps Artikel „A Dao of Web Design“ aus dem Jahr 2000!^[1]

Darin heißt es: “It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.”

Mit anderen Worten: Responsive web design.

Der Anfang von responsive web design liegt aber noch mal 10 Jahre zurück – als Tim Berners-Lee die erste Website ins Netz stellte.

Das Web ist von Natur aus responsive. Es waren Designer/Entwickler, die das Web als flexibles Medium nicht verstanden haben und das Responsive erst weggenommen haben.

“Instead of making websites responsive we have to make sure to keep them responsive.” —Jeremy Keith

Responsive web design ist nichts neues, sondern zurück zu den Wurzeln.

LLAP 🖖

---

1. In meiner Präsentation auf dem UXcamp Europe 2015 hatte ich den Zeitstrahl von heute zu Ethan Marcottes Artikel und von dort zurück zu John Allsopps Artikel animiert. Die Folien geben das nur statisch wirder. ↩︎

[Rafael]

Und du irrst, responsive web design ist nicht erst 6 Jahre alt, sondern wesentlich älter.

Der Begriff mag 6 Jahre alt sein

Das ist richtig. Und ich habe auch nicht bezweifelt dass die IDEE noch älter ist.

Die IDEEN von Angular und React sind ebenfalls älter als diese Frameworks. Und übrigens von diesen Frameworks unabhängig. Deshalb meine Frage ob du diese IDEEN verstanden hast.

VG

Rafael

[Gunnar Bittersmann]

@@Rafael

Möglicherweise hast du in den letzten Jahren einmal in die IT-Stellenanzeigen geschaut. Selbst jemand, der zwei-drei verbreitete Programmiersprachen beherrscht, wird in 95% der Anzeigen nichts passendes finden. Das liegt daran dass immer Kenntnisse in bestimmten Tools und Frameworks gefordert werden. Ein Arbeitnehmer muss sich spezialisieren.

Das ist normal und auch sinnvoll. Eine Firma entscheidet sich für einen Stack und bleibt dann erst einmal dabei.

Da sind wir wieder beim Punkt: Es ist verbreitet, dass erst die Tools gewählt werden und dann geschaut wird, was man denn damit zu bauen in der Lage ist.

Technologie-getriebene Entwicklung. Sucks.

Das muss endlich mal aufhören. Nicht das Pferd von hintenaufzäumen, sondern erst schauen, was man denn bauen will, dann die dazu passenden Tools auswählen!

LLAP 🖖

[dedlfix]

Tach!

Da sind wir wieder beim Punkt: Es ist verbreitet, dass erst die Tools gewählt werden und dann geschaut wird, was man denn damit zu bauen in der Lage ist.

Auf welchen prüfbaren Fakten basiert eigentlich diese Aussage?

Das muss endlich mal aufhören. Nicht das Pferd von hintenaufzäumen, sondern erst schauen, was man denn bauen will, dann die dazu passenden Tools auswählen!

Ich sehe nicht, wie dieses Ziel erreichbar sein soll. Das geht für mich an der Lebenswirklichkeit vorbei. Wieviele Tools soll man denn da als Einzelner oder als Gruppe so gut beherrschen, dass man das exakt entscheiden kann, und wieviel Geld bist du als Kunde bereit zu zahlen, damit die Entwickler den Umgang mit all diesen Tools erlernen? Oder anders, wie sehr wärst du als Firma bereit, ständig die Spezialisten zu tauschen, nur um bestmögliche Ergebnisse zu erzielen? Das Wissen und Können der Spezialisten ist ja auch nicht alles, was zum Erfolg beiträgt. Da müssen auch noch die zwischenmenschlichen Reibungsunkte immer wieder neu kalibriert werden. Und nebenan arbeitet die Kunkurrenz weiter nach bisherigem Schema und kann die Produkte günstiger und mit für die meisten Kunden ausreichender Qualität auf den Markt werfen.

Wie passt das Ziel eigentlich zu dem Universalwerkzeug Browser? Müsste man den nicht eigentlich einstampfen und jeweils spezialisierte, direkt auf das gewünschte Ergebnis angepasste Anwendungen entwicklen?

Wie passt das Ziel eigentlich auf das Universalwerkzeug Computer? Müsste man die nicht eigentlich einstampfen und jeweils spezialisierte, direkt auf das gewünschte Ergebnis angepasste Geräte entwicklen?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Da sind wir wieder beim Punkt: Es ist verbreitet, dass erst die Tools gewählt werden und dann geschaut wird, was man denn damit zu bauen in der Lage ist.

Auf welchen prüfbaren Fakten basiert eigentlich diese Aussage?

Berufserfahrung. Und nein, meine Erfahrung kannst du nicht nachprüfen.

Das muss endlich mal aufhören. Nicht das Pferd von hintenaufzäumen, sondern erst schauen, was man denn bauen will, dann die dazu passenden Tools auswählen!

Ich sehe nicht, wie dieses Ziel erreichbar sein soll.

Ein erster Schritt wäre es, wenn Designer und Entwickler an einem Tisch siten und miteinander reden.

Und wenn Entwickler aufhören, sich selbst die Hucke vollzulügen, sie würden agile Entwicklung betreiben. Solange zwar das Code-Schreiben agil ist, aber im Großen noch Wasserfall Wireframes–Grafikdesign–Code herrscht, ist die Entwicklung nicht agil. In meiner Session „Responsive mindset“ auf dem UXcamp Europe 2015 hatte ich das angesprochen: Folien 12—20

LLAP 🖖

[dedlfix]

Tach!

Das muss endlich mal aufhören. Nicht das Pferd von hintenaufzäumen, sondern erst schauen, was man denn bauen will, dann die dazu passenden Tools auswählen!

Ich sehe nicht, wie dieses Ziel erreichbar sein soll.

Ein erster Schritt wäre es, wenn Designer und Entwickler an einem Tisch siten und miteinander reden.

Und dabei stehen Frameworks im Weg? Was ist mit Kaufleuten und anderen Berufsgruppen, die an der Produktentstehung beteiligt sind? Was ist mit Anwendern?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ein erster Schritt wäre es, wenn Designer und Entwickler an einem Tisch siten und miteinander reden.

Und dabei stehen Frameworks im Weg?

Weder ich noch Zeldman haben so etwas behauptet.

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

Und nebenan arbeitet die Kunkurrenz weiter nach bisherigem Schema und kann die Produkte günstiger und mit für die meisten Kunden ausreichender Qualität auf den Markt werfen.

Man kann sich von der Konkurrenz auch damit abheben, nicht mitzuschwimmen, sondern den Kunden Produkte anziebieten, die vielleicht(!) teurer sind, aber bessere UX bieten. Die Kunden heben sich damit von ihrer Konkurrenz ab.

LLAP 🖖

[Rafael]

Nicht das Pferd von hintenaufzäumen, sondern erst schauen, was man denn bauen will, dann die dazu passenden Tools auswählen! Ich sehe nicht, wie dieses Ziel erreichbar sein soll. Das geht für mich an der Lebenswirklichkeit vorbei. Wieviele Tools soll man denn da als Einzelner oder als Gruppe so gut beherrschen, dass man das exakt entscheiden kann, und wieviel Geld bist du als Kunde bereit zu zahlen, damit die Entwickler den Umgang mit all diesen Tools erlernen? Oder anders, wie sehr wärst du als Firma bereit, ständig die Spezialisten zu tauschen, nur um bestmögliche Ergebnisse zu erzielen?

Genau so ist es! In einer idealen Welt mit unendlich Resourcen kann eine Firma bei einem Feature den gesamten Stack in Frage stellen und eine neue passende Software auswählen. In der Praxis würde das in kurzer Zeit in den Ruin führen.

Manchen hier fehlt scheinbar die betriebswirtschaftliche Perspective. Sie mussten noch nie die Entscheidung treffen welcher Stack verwendet wird. Sie kennen nicht den Rattenschwanz der dranhängt. Es ist eine langfristige Investition. Manche meinen gar "kein Framework" wäre eine Lösung. Ohne die Mehrkosten für eigene Entwicklung einzupreisen.

Man muss sich nur die Unternehmenslandschaft in der IT ansehen. Jede Agentur hat einen bewährten Stack pro Domäne. Z.B. ein Java Application Framework, ein CMS, ein Frontend Stack. Bei einem neuen Projekt wird allenfalls eine Komponente gewechselt. Der gesamte Stack wird vielleicht ein Mal in 10 Jahren gewechselt.

selbstverständlich ist dieser Stack ist nicht allen Anforderungen gewachsen. So versuchen manche eine Schraube mit dem Hammer reinzudrehen! Dennoch ist es weltfremd zu glauben man könnte immer die GENAU PASSENDEN Tools auswählen.

VG

Rafael

[pl]

jQuery hat damals™ die JavaScript-Entwicklung schon revolutioniert. Und sicherlich Einfluss auf natives JavaScript gehabt: jetzt gibt es querySelector/querySelectorAll (und damit einen Grund weniger, noch jQuery einzusetzen).

JS Template Engines liegen im Trend. Ganze Bäume kannste damit austauschen ohne bis zum letzten Blatt selektieren zu müssen: Platzhalter statt Selektor.

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer. Man kann eine SPA (singe page application) so bauen, dass der Nutzer sekundenlang nichts zu sehen bekommt bis das Framework geladen ist. Man kann eine SPA mit modernen Frameworks aber auch so bauen, dass die vom Nutzer aufgerufene Seite serverseitig gerendert und sofort übertragen wird und erst danach das Framework geladen wird.

So isses. Und genau das ist nicht die Frage "Welches Framework oder keins" sondern stets eine Frage der Zweckmäßigkeit. Das war schon immer so.

Schönen Sontag.

[encoder]

Wohl wahr, wohl wahr. Wer am lautesten schreit kann nur im Recht sein?
Wenn ich so sehe welche Säue immer wieder durchs Dorf getrieben werden. Irgendwas neues das für alles was es "mehr" kann als andere auch wieder etwas nicht kann, nur weil der Erfinder es für sein Hello-World Projekt nicht brauchte...

Frameworkistas gibt es auch in anderen Teilen als Web. Für jeden Schritt wird ein "snippet" gesucht, was für ein hippes Wort übrigens, statt sich selbst zu überlegen wie mans machen könnte. Oder gleich ein ganzes Framework, so dass mit Suche und Einarbeitung ein Tag vergeht statt zwei Stunden etwas selbst zu machen. Was das Framework nicht kann wird ignoriert, kann ja nicht so sehr wichtig sein.

[Gunnar Bittersmann]

@@encoder

Frameworkistas gibt es auch in anderen Teilen als Web. Für jeden Schritt wird ein "snippet" gesucht, was für ein hippes Wort übrigens, statt sich selbst zu überlegen wie mans machen könnte. Oder gleich ein ganzes Framework, so dass mit Suche und Einarbeitung ein Tag vergeht statt zwei Stunden etwas selbst zu machen. Was das Framework nicht kann wird ignoriert, kann ja nicht so sehr wichtig sein.

Bleiben wir noch beim Web. Eklatantes Beispiel: Fukol.

Wie ich dazu wohl nicht untreffend bemerkte: Sag Leuten „Mit den neuen Features in CSS (Flexbox, Grids) braucht man kein CSS-Framework für ein Grid-Layout mehr“ und sie kucken dich blöd an. Stelle einen Einzeiler auf Github und nenne das Framwork und sie sind aus dem Häuschen: „Geil, ein neues CSS-Grid-Framework!“ WTF‽

Da hat Heydon Pickering ganze Arbeit geleistet, diesen Missstand zu karikieren. Ich vermute aber: Diejenigen, die das durchschauen, lächeln müde; und die anderen kriegen gar nicht mit, wie sie verspottet werden.

So weit klafft die Schere zwischen Entwickler und „Entwickler“ mittlerweile auseinander.

LLAP 🖖

[dedlfix]

Tach!

Diejenigen, die das durchschauen, lächeln müde; und die anderen kriegen gar nicht mit, wie sie verspottet werden.

So weit klafft die Schere zwischen Entwickler und „Entwickler“ mittlerweile auseinander.

Ich bin ja nicht der Meinung, dass Spott ein geeignetes Mittel ist, den Abstand der Klingen zu verringern. Auch Elfenbeintürme haben eine Treppe nach unten.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich bin ja nicht der Meinung, dass Spott ein geeignetes Mittel ist, den Abstand der Klingen zu verringern.

Vermutlich nicht.

Auch Elfenbeintürme haben eine Treppe nach unten.

Es gibt auch Treppen nach oben. Nur dass etliche „Entwicker“ gar nicht willens sind, den Weg zu gehen. Mit Frameworks schlagen sie sich ja auch so durch. Und die Industrie gibt wenig Anreize aufzusteigen. Da wären wir wieder bei dem, was Zeldman beklagt.

LLAP 🖖

[pl]

hi,

Was das Framework nicht kann wird ignoriert, kann ja nicht so sehr wichtig sein.

Was ein Framework kann oder nicht kann, war für mich nie die Frage. Vielmehr war die Frage aus meiner Sicht immer die der Zweckmäßigkeit! Beispiel: Jede Response hat einen Header Content-Type -- Dem entsprechende Anweisungen kann jeder Anfänger tippen.

Und so ergäbe sich die Frage, ob ein Praktikant, der 1000 Scripte schreibt, auch tausend Anweisungen header('Content-Type: ...') tippen muss oder ob man da vielleicht irgendwo einen Default setzen könnte.

[dedlfix]

Tach!

Anlässlich des bevorstehenden Blue Beanie Day (Was’n das?) hat Jeffrey Zeldman einen unbedingt lesenswerten Artikel geschrieben:

Nun hab ich auch mal nicht nur deinen Auszug hier, sondern auch die verlinkten Seiten gelesen und ich bin nicht der Meinung, dass ich diese Aktion, so wie sie sich gerade darstellt, für unterstützenswert halte. Das eigentliche Ziel war doch Webstandards und deren Einhaltung zu propagieren. Ist das etwa kein technikgetriebenes Ziel?

Diese Unterstützung sehe ich auch als wichtig an, damit eine Interoperabilität sowie eine Benutzbarkeit für möglichst viele erreicht werden kann. Nun kommt jedoch das große Aber: Was aber hat das denn mit der Nutzung oder Nichtnutzung von Frameworks zu tun? Die Frameworks haben doch daran keine Schuld, wie das Ergebnis aussieht? Ich sehe im Gegenteil, zum Beispiel bei Bootstrap, dass da sogar viele ARIA-Attribute drinstecken. Das müsste doch viele Webseiten sogar bereichern, wenn der Entwickler die dortigen Vorlagen kopiert und nicht das Ganze zu Fuß anfängt, ohne dass er von ARIA eine Ahnung hat. Auch andere von Frameworks gelieferte Vorlagen haben Dinge drin, die nützlich sind, aber von denen in ihrer Vielfalt vermutlich kaum einer Ahnung hat.

Ich verstehe die Aufregung um die Frameworks nicht, und wie es möglich sein soll, bessere Ergebnisse zu erzielen, wenn man auf sie verzichtet. Als Entwickler werde ich doch kein besserer solcher, mit Beherrschung aller notwendigen Dinge, nur weil ich damit beginne, ein Werkzeug beiseite zu legen, das mir bereits jede Menge Struktur und Hilfsmittel ins Projekt bringt, die ich ansonsten in mühevoller Kleinarbeit erstellen müsste. Bekomme ich dadurch mehr Zeit, mich in die anderen Dinge einzuarbeiten?

Wie arbeitet denn jemand, der keine Frameworks nutzt und auch nicht gerade ein Genie in der Beherrschung aller Webstandards ist? Der innere Schweinehund sagt da zum Beispiel: Nimm mal das Projekt von eben, schweiß den Inhalt raus und fertig ist das Grundgerüst für das nächste. Framework very light.

This year more than ever, Blue Beanie Day matters

Darin beschreibt er gegenwärtige Fehlentwicklungen in der Webbranche und das Problem, das „Frameworkistas“ dabei darstellen.

Nicht nur das. Er bezieht sich zum großen Teil auch auf die amerikanische Präsidentenwahl und dass ein Teil der Bevölkerung von der bevorstehenden Donald-Trump-Regentschaft benachteiligt wird. Ist das (dieses Jahr) lediglich ein amerikazentriertes Ereignis? Sehe ich da etwas politikgetriebenes durchschimmern und die Nutzer sind nur Beiwerk?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Nicht nur das. Er bezieht sich zum großen Teil auch auf die amerikanische Präsidentenwahl und dass ein Teil der Bevölkerung von der bevorstehenden Donald-Trump-Regentschaft benachteiligt wird. Ist das (dieses Jahr) lediglich ein amerikazentriertes Ereignis?

Ist ein Präsident eines so großen Landes wie den USA, der den globalen Klimawandel leugnet, lediglich ein amerikazentriertes Ereignis?

Ist ein Irrer an den Knöpfen für Atomwaffen lediglich ein amerikazentriertes Ereignis?

Merkste selbst, ne?

LLAP 🖖

[dedlfix]

Tach!

Ist ein Präsident eines so großen Landes wie den USA, der den globalen Klimawandel leugnet, lediglich ein amerikazentriertes Ereignis?

Zusammenhang zur Bedienbarkeit von Webseiten ist welcher?

Warum hab ich dich eigentlich in dieser Diskussion verloren? Warum hast du es nicht geschafft, mich, als einen Teil der Zielgruppe, zu erreichen?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ist ein Präsident eines so großen Landes wie den USA, der den globalen Klimawandel leugnet, lediglich ein amerikazentriertes Ereignis?

Zusammenhang zur Bedienbarkeit von Webseiten ist welcher?

Der Schnittpunkt ist: Verantwortung. (Wie in Verantwortung.)

Warum hab ich dich eigentlich in dieser Diskussion verloren? Warum hast du es nicht geschafft, mich, als einen Teil der Zielgruppe, zu erreichen?

„Sag du es mir!“

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Ist ein Präsident eines so großen Landes wie den USA, der den globalen Klimawandel leugnet, lediglich ein amerikazentriertes Ereignis?

Geht los: Trump transition team for Energy Department seeks names of employees involved in climate meetings

LLAP 🖖

[mermshaus]

@Gunnar Bittersmann

Blue Beanie Day (Was’n das?)

Ich habe prinzipiell nichts gegen die Aktion, aber das könnte für mich durchaus weniger wie ein interner Witz für Jeffrey-Zeldman-Kenner wirken. Wer Zeldman kennt, ist eh im Thema, und warum sollte diese indirekte Präsentation des eigentlichen Anliegens groß jemanden interessieren, der Zeldman nicht kennt. Mir kommt das unnötig umständlich und dadurch in der Wirksamkeit beschränkt vor. Aber wenn es der Sache dient.

Die deutsche Übersetzung ist stellenweise leider etwas ungenau. Das Original ist spürbar gemäßigter, was die Vorwürfe von „Unbenutzbarkeit“ und dergleichen angeht. Ich würde auch „benutzbar“ nicht unbedingt für die passende Übersetzung von „accessible“ halten.

Der Kritik an JS-Frameworks kann ich auch nur eingeschränkt was abgewinnen. Ich widerspreche nicht vehement (und ich bin jemand, der JS-Entwicklern Pi mal Daumen eher nicht über den Weg traut), aber ich glaube nicht, dass das per se an den Frameworks liegt. Ich glaube auch nicht, dass es heutzutage noch realistisch ist, JavaScript nicht als Teil des Stacks zu begreifen. Die „If site content doesn’t load through curl it’s broken“-Philosophie (Ben Ward, 2011, zitiert nach isolani.co.uk) hat sich dahingehend überlebt. Ich persönlich kritisiere das durchaus noch in Bezug auf so manche Anwendung, weil ich JavaScript für eine heftige Abhängigkeit halte (etwa wegen Websuche), aber: Der Zug ist wahrscheinlich abgefahren. HTML ist tot, lang lebe das DOM.

Am Rande: Ich glaube nicht, dass derlei Probleme, die Zeldman beschreibt, ein Schuh sind, den sich Backend-Leute anziehen müssen. Meines Erachtens ist das seit Flash und Tabellenlayouts ein Frontend-Problem. Das Frontend hat sich in meiner Wahrnehmung nie groß um Standards oder Semantik gekümmert. Im Frontend musste es halt immer nur „richtig aussehen“, während es im Backend auch immer schon richtig funktionieren musste, weil man sonst schnell mal gehackt wurde.

Was ich an Zeldmans Artikel etwas fragwürdig finde, ist zudem dieser Teil:

Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.

Ich finde es etwas ungerecht, Leute schon mal vorauseilend für die Nicht-Nutzung von etwas zu kritisieren, das de facto noch nicht genutzt werden kann.

Die HTML-/CSS-Entwicklung wird in der Hinsicht durchaus auch von der JS-Entwicklung getrieben.

[mermshaus]

Sorry, falls es schon verlinkt wurde, aber vielleicht noch ganz interessant zu dem Thema:

• Marco Zehe: JavaScript is not an enemy of accessibility!

[pl]

Sorry, falls es schon verlinkt wurde, aber vielleicht noch ganz interessant zu dem Thema:

• Marco Zehe: JavaScript is not an enemy of accessibility!

Richtig, ganz im Gegenteil! Wer an einer längeren Geschichte schreibt im Browser, der wird sich ohne JavaScript spätestens nach dem drittenmalspeichern gefragt haben warum dafür die ganze Seite neu laden und er wieder ganz nach unten scrollen muss.

Besonders schön sind auch JS-freie Kommentarfunktionen ganz unten mit Fehlermeldungen die nach dem Neuladen der Seite dann ganz oben rauskommen... aber nicht dass mir jetzt einer kommt mit Anker setzen und so ;)

PS: Meine Backends fürs Management bau ich nur noch mit JS.

[Gunnar Bittersmann]

@@mermshaus

Sorry, falls es schon verlinkt wurde,

Wurde noch nicht; Asche auf mein Haupt.

aber vielleicht noch ganz interessant zu dem Thema:

• Marco Zehe: JavaScript is not an enemy of accessibility!

Ja! Über Twitter hatte ich (auch als @SELFHTML) den Artikel auch schon längst geteilt. Das hatte ich auch hier im Forum vor; wollte vorher nur nochmal bei Zeldman nachlesen, ob er wirklich gesagt hat, dass JavaScript ein Feind von Barrierefreiheit wäre … Das steht noch an.

LLAP 🖖