Studenten wie auch Mitarbeiter der FHNW entwickeln das Toolkit Kolibri laufend weiter. Entwickler können die Open-Source-Werkzeuge einfach importieren und verwenden. Damit das Kolibri-Toolkit schlank bleibt, kommen keine externen Abhängigkeiten zur Verwendung. Mit einer VanillaJS-Codebasis bietet das Tool eine breite Auswahl an, deckt aber noch nicht alle Interaktionen ab.
Der in der Vorarbeit [1] hergestellte Fork dient als Ausgangslage. Ein Merge – des Branches experimental dieses Forks und des Kolibri-16 der originalen Codebasis – stellt die Aktualität sicher. Das SimpleInput ist eines der Tools, welches sich bei der Implementation der neuen Auswahlkomponente als hilfreich erweisen kann.
Die Vorarbeit beinhaltet sowohl einen Recherche- als auch einen Design- und Implementationsbestandteil. Die Recherche legt den Fokus auf das Prototyping und diverse Code- und Implementationsbausteine. Die Anwendung der Informationen aus den Recherchen findet sich im Weg zur Länderauswahl wieder. Mehr zum Resultat dieser Arbeit folgt im Kapitel Länderauswahl-Komponente. Der komplette Bericht ist in der Quelle [Marti und Burki, 2024] nachzulesen.
Der Zugriff auf das Tool Figma ermöglicht das Verwenden des existierenden Designsystems und der bereits eingebundenen Elemente. Der Aufbau der Elemente als Komponenten vereinfacht die Wiederverwendung. Das Ergänzen des Icon-Sets ist bei Bedarf erlaubt.
Eine weitere, wichtige Ausgangslage ist ein gemeinsames Verständnis der verwendeten Begriffe. Dies sicherzustellen, ist die Aufgabe der nächsten zwei Kapitel mit der Beschreibung der Master-Detail-View und der Zustände eines Dropdown sowie dessen Elemente. Diese Definitionen gelten im gesamten Bericht.
Die Grundlagen stellen ein gemeinsames Verständnis der Auswahlkomponente her. Dazu zählen die Zustände, welche in diesem Zusammenhang auftreten können. Ausserdem behandelt es eine Basis zu den Themen Browser und Rendering. Dieses Verständnis ermöglicht es, eine neue, konsistente Komponente zu entwickeln.
Die wichtigsten Aspekte von der Theorie über die populären Browser bis hin zum Ablauf des Renderings sind hier aufgeführt. Dabei sind nur die bekanntesten Implementationen von Belang.
Ein Webbrowser dient als Zugang ins Internet und zur Anzeige von Webressourcen wie HTML, CSS und JavaScript. Er besteht aus einer Benutzeroberfläche, einer Browser- und einer Rendering-Engine. Für eine verständliche Darstellung der Inhalte auf dem UI verwendet die Browser-Engine einen sogenannten Renderer – mehr dazu später. Die Benutzeroberfläche dient als Schnittstelle zwischen dem Benutzer und der Datenschicht. Die Rendering-Engine interpretiert die Inhalte anhand des vorgegebenen Inhaltstyps. Einer der Engines ist der HTML-Renderer. Beim UI und der Bedienung zeigen sich die Uneinigkeiten zwischen den Browser-Herstellern. Der Grund liegt darin, dass die Rendering-Engine den Code nicht gleich interpretiert. Anschliessend sind Informationen über den detaillierten Ablauf zur Anzeige eines HTML-Dokuments und die Rolle des Renderings dokumentiert.
Der Aufruf einer Webseite beginnt mit dem HTTP-Request, auf welchen eine HTTP-Response folgt. Die zuvor genannten Schritte vor der eigentlichen Datenerhebung sind in diesem Bericht nicht weiter von Bedeutung. Der Response liefert letztlich die anzuzeigenden Daten, welche in diesem Fall die tragende Rolle spielen.
Der Browser verarbeitet die erhaltenen Daten im HTML-Format weiter. Mehrere Schritte wandeln die einzelnen HTML-Elemente in sogenannte Nodes um. Aus den resultierenden Nodes entsteht durch Verknüpfungen eine Baumstruktur – der DOM. Das Document Object Model (DOM) (Abbildung 2.4 links oben) beschreibt die Eltern-Kind- und Geschwister-Beziehung der Nodes. Der Prozess des CSS Object Models (CSSOM) gestaltet sich relativ ähnlich, ist aber nicht weiter wichtig.
Der DOM und der CSSOM sind unabhängig voneinander. Der Browser kombiniert die beiden Bäume zu einem gemeinsamen Renderbaum (Abbildung 2.4 rechts). Der resultierende Baum repräsentiert nur sichtbare Elemente, wohingegen der DOM alle Elemente enthält. Der Renderbaum ist browserabhängig.
Gründe für ein erneutes Rendern [3]:
Manipulation der Elemente des DOM
Änderungen des Inhalts (auch von Formularfeldern)
Änderungen der CSS-Eigenschaften
Hinzufügen oder Entfernen der Stylesheets
Ändern des Attributs class
Ändern der Grösse des Browserfensters
Scrollen des Browserfensters oder der Elemente
Aktivieren der Pseudo-Klassen
Die populärsten Browser mit 65% Marktabdeckung basieren auf der Chromium-Basis und verwenden alle den HTML-Renderer Blink [4]. Die Entwickler dieser Rendering-Engine sind die Open-Source-Community Chromium, Google, Intel und Samsung. Zu den Browsern [5], die Blink als Rendering-Engine nutzen, gehören unter anderem Google Chrome, Brave, Microsoft Edge, Opera und Vivaldi. WebKit [6] – der Vorgänger des geläufigsten Renderers Blink – findet sich im OSX-Webbrowser Safari wieder. Diese von Apple, Google, KDE und Nokia entwickelte Rendering-Engine deckt 15% ab. Firefox und weitere auf Mozilla basierende Browser [7], die Webseiten mit Gecko rendern, sind die bekanntesten Vertreter der verbleibenden Browser. Es existieren noch weitaus mehr Renderer, welche aber eine sehr geringe Verbreitung aufweisen. Deswegen sind diese nicht weiter von Belang.
Eine Auswahlkomponente lässt sich unkonventionell in eine Master-Detail-Ansicht einteilen. Dies ist in Abbildung 2.1 ersichtlich.
Typisch für die Master-Detail-View ist, dass die Detail-Ansicht mehr Daten anzeigt als der Master. Bei der Anwendung des Patterns auf eine Auswahlkomponente ist dies nicht der Fall. Anders als bei der typischen Master-Detail-View beinhaltet die Detail-Ansicht keine weiteren Informationen. Der Master listet alle möglichen Optionen auf. Dieser View-Baustein findet sich im aufklappenden, scrollbaren Container wieder. Die dauerhaft sichtbare Komponente stellt die Detail-View dar. Dieser Container beinhaltet sowohl den aktuell selektierten Wert als auch das Dropdown-Icon. Weiteres zu den möglichen Zuständen ist im nachfolgenden Kapitel zu finden.
Dieser Abschnitt erklärt die Zustände, welche in einer Auswahlkomponente auftreten können. Als Ausgangslage dient eine Eingabemöglichkeit, die eine Master-Detail-Ansicht aufweist. Zudem sind keine speziellen Voreinstellungen getroffen.
Je nach Darstellung der Komponente kann diese offen oder geschlossen sein. Im geschlossenen Status (Abbildung 2.2) zeigt das Erscheinungsbild nur die Detail-Ansicht an. Diese zeigt mindestens den selektierten Wert an. Eine offene Auswahlkomponente wie in Abbildung 2.3 stellt beide Elemente der Master-Detail-View dar. Die Master-Ansicht zeigt alle Optionen in einer Liste an.
Bei dem normalen bzw. nicht fokussierten Status ist die Komponente nicht an- oder ausgewählt. Wenn eine Webseite diese Komponente enthält, ist dies die standardmässige Darstellung. Das neue Element zeigt keine Reaktion auf Interaktionen, welche in diesem Zustand geschehen. Als einzige Ausnahme gilt Tab, welche den Fokus auf die Komponente legen kann. In den meisten Erscheinungen ist nur die Detail-Ansicht sichtbar und der Master-Container ist ausgeblendet. Wählt der Nutzer die Komponente mit der Maus oder der Tastatur an, steht sie im Fokus bzw. ist sie fokussiert. Bedienungen über das Keyboard beziehen sich hierbei auf den Baustein. In den meisten Fällen ändert sich die Darstellung des Eingabefeldes – z. B. durch einen gelben Rahmen.
Ist ein Wert in der Master-Ansicht ausgewählt und erscheint in der Detail-View, ist dieser selektiert. Das Formular enthält beim Versenden das Value der Selektion. Eine Selektion in einer Kategorie-Spalte findet in den Formulardaten keine Berücksichtigung. Stattdessen filtert die Kategorie-Selektion die Wert-Spalte. Durch das Hervorheben zeigt sich in der Liste aller Werte eine getätigte Auswahl an. In gewissen Situationen existiert noch der Zustand, dass in der Master-View ein Wert im Highlight steht. Bestätigt der Nutzer das Highlight mit der Maus, wechselt der Status auf selektiert. Das Hovern kann den Highlight-Wert ändern. Geschieht die Navigation durch die Werte mit der Tastatur, erhält genau ein einzelner Wert die Cursor-Position. Durch das Betätigen gewisser vordefinierter Tasten ändert sich die Cursor-Position. Bei einer Bestätigung mit der Tastatur ändert sich der Wert der Cursor-Position auf selektiert. Die letzten zwei Zustandswerte haben keinen Einfluss auf das versendete Formular. Sie sind nur im Master zu finden. Nachfolgend sind noch die Details zum Thema Browser erklärt.
Dieses Wissen ist wichtig für das spätere Kapitel . Der Grund ist, dass der Browser maximal 60 Mal pro Sekunde rendern kann. Jede Änderung am Browser-DOM [2] startet den kompletten Rendering-Prozess von vorne. Zu viele Änderungen am DOM führen dazu, dass der Nutzer länger warten muss, bis die Webseite geladen ist.
Die neue Komponente soll in möglichst allen Browsern eine konsistente Erscheinung wie auch Interaktion bieten. Durch die Erklärung aus Kapitel ist klar, dass die Renderer die Unterschiede im UI bewirken. Die Bedienungsabweichungen stammen grösstenteils vom zugrunde liegenden Betriebssystem. Diese Erkenntnisse führen dazu, dass die neue Komponente auf Mac und Windows mit den geläufigsten Renderern zu testen ist. Zu den ausgewählten Webbrowsern zählen Google Chrome, Firefox (Mac und Windows), Safari (nur Mac) und Edge (nur Windows). Die Erläuterung dazu folgt im nächsten Abschnitt.
[2] Im Renderbaum verwendeter und im Browser angezeigter DOM [3] [4] [5] [6] [7]
