Der Schweizer-Taschenmesser-Effekt komponentenbasierter Websites

    Eine komponentenbasierte Website mag der Traum aller Content-Manager und Webmaster sein, die Vielseitigkeit birgt aber auch einige Gefahren. Erfahren Sie, wie leicht die Komponentenautonomie Ihr Website-Design durcheinanderbringen und die User Experience beeinträchtigen kann.

    Abonnieren Sie unseren Blog

    Komponentenbasiere Plattformen gehören zu den aktuellen Lieblingen der Website-Entwickler und -Designer. Wie ein „Schweizer Taschenmesser“ scheinen sich ihre anpassungsfähige Webarchitektur und das flexible Design ganz leicht an die Bedürfnisse aller anpassen zu können. Aber ist es wirklich so einfach? Zahlt man einen Preis für diese Vielseitigkeit? In diesem Blogpost erfahren Sie aus erster Hand von den Vor- und Nachteilen bei der Arbeit mit komponentenbasierten Websites.

    Der glücklichste Junge der Welt

    Meine Mutter hatte einen sehr besorgten Gesichtsausdruck, aber ich war gerade 10 geworden und versprochen ist versprochen! Der Verkäufer legte das glänzend rote Schweizer Taschenmesser feierlich in meine zitternden kleinen Hände und das Geld wurde übergeben. Auf der Heimfahrt im Auto fühlte ich das Gewicht des Objekts in meiner Tasche und stellte mir vor, was ich alles damit machen könnte. An diesem Tag war ich der glücklichste Junge der Welt.

    Aber es dauerte nicht lange, bis mir klar wurde, dass mein wunderschönes Schweizer Taschenmesser vermutlich eines der unpraktischsten Dinge war, die der Mensch jemals erfunden hatte. Es ist vielseitig, so viel muss ich zugeben. Sein wunderschönes und geniales Design wurde raffiniert vermarktet. Aber als Werkzeug ... taugt es zu gar nichts! Als Schraubenzieher hat es selten die richtige Größe, als Säge ist es viel zu kurz, als Messer zu stumpf und als Korkenzieher auf gefährliche Weise unhandlich.

    Die naive Aufregung eines Jungen

    Als ich begann, mit komponentenbasierten Website-Plattformen zu arbeiten, spürte ich dieselbe Art naiver Aufregung, die ich damals als kleiner Junge empfunden hatte. Ein „Designer“ übersetzt mein Customer Branding in ein ansprechendes, immersives Design, das auf allen Geräten gleich gut funktioniert. Ein „Komponenten-Entwickler“ (wie ich) nimmt das Design und baut einen schönen Werkzeugkasten aus Komponenten dafür. „Content-Autoren“ platzieren diese Komponenten schließlich durch einfaches Drag-and-Drop auf Seiten und stellen sich so die Website zusammen, die sie gerne hätten.

    Die meisten Komponenten stehen für einfache Website-Grundelemente, wie zum Beispiel einen Textabschnitt, ein Bild oder eine Überschrift. Andere Komponenten sind etwas komplexer, wie zum Beispiel ein Twitter-Feed oder ein eingebettetes YouTube-Video.  Und schließlich gibt es auch noch Container-Komponenten. Diese fungieren, wie es der Name schon suggeriert, als eine Art Container, mit dessen Hilfe andere Komponenten in Listen, Spalten, Karussells usw. angeordnet werden können. Man kann zum Beispiel mehrere Bilder-Komponenten in eine Listen-Komponente hineinziehen und so werden sie ganz automatisch ... als Liste angezeigt. Traumhaft einfach!

    Komponenten, die sich verändern und nicht mehr das tun, was sie sollten

    Genauso wie damals in meiner Kindheit habe ich rasch verstanden, dass dieser Traum sehr schnell zu einem Albtraum werden kann. Deshalb begann ich, über etwas nachzudenken, dass ich gerne „Schweizer-Taschenmesser-Komponenten“ nenne. Diese funktionieren zunächst wie gewünscht, fangen aber plötzlich an, Probleme zu bereiten, was zur Frustration bei Content-Autoren führt , den Blutdruck von Komponenten-Entwicklern steigen lässt und Niedergeschlagenheit bei den Designern hervorruft.  Dieses Phänomen kommt häufig bei den einfachsten Komponenten vor, zum Beispiel bei Textkomponenten. Der Auslöser ist fast immer ein Content-Autor, der eine zusätzliche Funktion haben möchte. Zum Beispiel die Möglichkeit, eine Farbe oder Schriftart auszuwählen. Und der Katalysator ist immer ein Komponenten-Entwickler, der es den Content-Autoren, die seine Komponenten nutzen, recht machen möchte.

    Die Täuschung, das Chamäleon und der Rüpel

    Die problematischen Komponenten können für lange Zeit unauffällig vor sich hinarbeiten, bevor die ersten unschönen Symptome auftreten. Dann wird eines Tages eine Designänderung angefragt. Zum Beispiel eine Änderung des Farbschemas, damit es zum aktualisierten Corporate Branding passt. Auf einmal berichten die Content-Autoren von Textabschnitten, die einfach verschwunden sind ... auf einzelnen Seiten ... auf der ganzen Website ... auf der Produktionsumgebung! Das nenne ich den Houdini-Effekt.

    Was passiert ist, lässt sich ganz einfach erklären: Content-Autoren beginnen, die neue Funktion in der Textkomponente zu nutzen. Sie mögen die zusätzliche Flexibilität, mit der sie hier und da die Standardfarbe von Textabschnitten auf der ganzen Website ändern können. Durch diese Änderungen verändern sie unwillentlich das Design, und wenn das Design aktualisiert wird, sind die Überschreibungen noch zu sehen. Manchmal ist die neue Farbe dieselbe wie die Hintergrundfarbe der Container-Komponente im neuen Design. Die perfekte Täuschung: Der Text scheint verschwunden zu sein.

    In einigen Fällen ist die neue Farbe vielleicht nicht dieselbe wie die Hintergrundfarbe, passt aber ästhetisch einfach nicht zum aktualisierten Design. Dasselbe gilt für überschriebene Schriftarten und andere Textattribute. Seiten, auf denen ein Content-Autor auf der Suche nach der besten Lösung Stunden verbringt (um Farben, Schriftarten und andere Texteigenschaften anzupassen), werden völlig zerstört. Der gute alte Chamäleon-Effekt.

    Manchmal kann es auch mit einer eigentlich guten Komponente Probleme geben, einfach, weil sie sich mit den „falschen Freunden“ umgibt. Eltern kennen diesen Effekt, ich nenne ihn den „Rüpel-Effekt“. Nehmen Sie zum Beispiel eine einfache Überschriften-Komponente, die bis dato immer unkompliziert und zuverlässig war, wenn man sie auf einer Seite platziert hat. Wird sie jedoch innerhalb einer Listen-Komponente platziert, kann es passieren, dass sie sich völlig untypisch verhält! Auf einmal wird sie zum „Rüpel“, schubst Absätze herum und überlappt „wehrlose“ Bilder. Warum? Weil es vom Designer nicht vorgesehen war, dass eine Überschriften-Komponente innerhalb einer Listen-Komponente platziert wird. Folglich gibt das Design, das er konzipiert hat, Text-Komponenten und Bilder-Komponenten innerhalb einer Liste nicht genügend Gewicht, um sich gegenüber einer „schweren“ Überschriften-Komponente „durchsetzen“ zu können. Der Komponenten-Entwickler war sich dessen nicht bewusst oder einfach etwas nachlässig. Er hat nicht dafür gesorgt, dass ein Autor eine Überschriften-Komponente nicht in einer Listen-Komponente platzieren kann. Es ist ein bisschen so, wie wenn Eltern es versäumen, ihren Kindern zu sagen, mit wem sie ihre Freizeit verbringen dürfen.

    Mühsame Arbeit

    Bei alldem ist es wichtig, sich vor Augen zu führen, welch mühsame Arbeit der „Designer“ auf sich genommen hat, als er ein Design für eine komponentenbasierte Website-Plattform entworfen hat. Sein Ziel war es, so wenige Komponenten und so einfache Komponenten wie möglich zu erstellen. Er tat dies in dem Bemühen, ein reibungsloses und intuitives Autorenerlebnis und ein angenehmes und immersives Besuchererlebnis auf jedem Gerät zu ermöglichen. Er hatte immer im Blick, dass die Bildschirm-Ausrichtung sich ändern kann, wenn ein Besucher sein Gerät dreht. Ebenso dachte er an Besucher mit Seheinschränkungen, die auf spezielle Bildschirmlesegeräte angewiesen sind. Er dachte sogar an die hoffnungslosen Fälle, die heutzutage immer noch den Internet Explorer und andere exotische oder veraltete Browser verwenden.

    Der Preis, den man zahlen muss

    Der ehrenwerte Designer hat sich so elegant um so viele Probleme gekümmert, um sowohl den Komponenten-Entwicklern als auch den Content-Autoren das Leben leichter zu machen. Und der Preis, den man für dieses Glück zahlt?

    Wenn Sie Content-Autor sind, müssen Sie dem Drang widerstehen, jedes winzige Detail auf den Seiten, die Sie erstellen, kontrollieren zu wollen. Was Ihnen wie ein Mangel an Flexibilität vorkommt, ist vermutlich das Ergebnis eines sorgfältig abgewogenen Kompromisses. Wenn Sie es akzeptieren können, innerhalb der Grenzen des Designs zu arbeiten, müssen Sie nicht stundenlang an Farben, Textausrichtung, Schriftarten und vielem mehr herumbasteln. Und das alles für ein Ergebnis, das am Ende wahrscheinlich ohnehin nicht so aussehen wird, wie Sie es sich vorgestellt haben. (Wenn es am Ende tatsächlich gut aussieht, dann haben Sie Ihre Berufung verfehlt und hätten Webdesigner werden sollen). Kümmern Sie sich lieber darum, fesselnde Inhalte zu erstellen, dank denen Besucher gerne wiederkommen, und überlassen Sie das Designen dem Designer.

    Wenn Sie Komponenten-Entwickler sind, müssen Sie lernen, manchmal auch nein zu sagen. Wenn Sie einen Satz hören wie: „Können Sie diese Funktion zu dieser Komponente hinzufügen, damit ich mehr Kontrolle habe über …?“, sollten Sie sich in Ihrem Kopf sofort schreckliche Bilder ausmalen, wie Sie Nachtschichten schieben, um die Scripts zu bereinigen und den Schlamassel wieder in Ordnung zu bringen. Sprechen Sie immer zuerst mit Ihrem Designer, versetzen Sie sich in seine Lage und lernen Sie, eine Website durch seine Augen zu betrachten. Halten Sie Probleme getrennt und hüten Sie sich vor Designs, die sich heimlich ihren Weg in den Content Ihres Autors oder in Ihren Code bahnen. Finden Sie einen tragfähigen Kompromiss. Dieser kann ganz simpel aussehen und zum Beispiel darin bestehen, dass Autoren die Möglichkeit haben, auf Seiten- oder Container-Komponenten-Ebene zwischen zwei oder drei (vom Designer erstellten) Themen auszuwählen.

    Veröffentlicht auf 30/04/18    Zuletzt aktualisiert am 07/01/19

    #CMS, #Content Management, #Digitale Strategie, #Webentwicklung

    Über den Autor

    David Van der Elst is Digital Experience Consultant at AMPLEXOR based in Belgium. David is passionate about ICT in general and the Java platform in particular. Specializing in Adobe Experience Manager, he has over 12 years of experience in J2EE analysis and development.

    ABONNIEREN SIE UNSEREN BLOG

    Beteiligen Sie sich an dieser Diskussion