<div class="mod_group mod_timetable_input_form_buttonwrapper" data-timetableInputForm='button_wrapper'>
<button type="submit" class="text__primarybutton button">
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
Verbindung suchen
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
</button>
</div>
<!-- dazu kommen Referenzen zu CSS Files sowie SVG Sprites -->Anschaungsbeispiel eines kleinen / einfachen Moduls heute auf SBB.ch.
Ich gehe davon aus, dass alle bereits ein wenig HTML gesehen haben? Dieses Markup beschreibt wie ein Button auf SBB.ch aussieht. In diesem konkreten Fall beschreibt es den Button für das Absenden der Fahrplanabfrage (siehe nachfolgend).
Dazu kämen ebenfalls Referenzen zu CSS Files (die für die Darstellung zuständig sind) sowie SVG Sprites (die die Icons beinhalten) ...
All dies muss berücksichtigt werden, wenn heutzutage Markup vom Backend eingepflegt / aktualisiert wird.
Für die damalige Zeit war dies der modularste Ansatz, heute gibt es jedoch andere Lösungen.
Webkomponenten sind eine Gruppe von Web-Technologien, die es ermöglichen, benutzerdefinierte, wiederverwendbare HTML Elemente zu erstellen, deren Funktionalität gekapselt ist und damit vollständig getrennt von anderem Code.
(next Slide) ... aber was heisst das nun genau?
Welche Probleme lösen Web Components?
Wie wird dies gelöst?
Welche Probleme lösen Web Components?
DRY (Do Not Repeat Yourself) ist eine goldene Regel der Softwareentwicklung. Code sollte möglichst wiederverwendet werden. Für HTML / CSS / JS ist dies (bisher) nicht so einfach. Eben vorhin haben wir gesehen, was alles nötig ist, um ein Custom UI-Element zu erstellen (Beispiel CTA Button).
Des Weiteren sollten Implementationsdetails einer API für die Nutzer der API nicht ersichtlich sein. Z.B. wollen wir beim Nutzen einer Rest API keine DB spezifischen Konfigurationen vornehmen. Dasselbe sollte für unser Frontend gelten. Heute muss man zum Beispiel im Button ein SVG mitgeben.
Kommt die Button Komponente an mehreren Orten zum Einsatz, muss diese dementsprechend an mehreren Orten gepflegt und gewartet werden. Passen wir unsere Implementation an, z.B. ein Wechsel von SVG auf Canvas, müssen alle Bezüger des Buttons ihren Code anpassen (AEM, Fahrplan, Webshop, …). Breaking Changes kommen oft vor. Oder es wird von möglichen Verbesserungen abgesehen, da diese für die Bezüger einen erheblichen mehraufand bedeuten.
Weiter besteht die Möglichkeit, dass das Styling (CSS) unserer Komponenten von den beziehenden Seiten überschrieben wird.
Web Components bieten für diese Probleme eine einheitliche und standardisierte Lösung.
Wie wird dies gelöst?
Mittels drei Haupttechnologien die gemeinsam (oder einzeln) verwendet werden können.
<script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>Ich möchte dies noch einmal anhand eines Beispiels kurz erläutern. Keine Bange, dies ist das letzte Code Snippet, welches ich hier heute zeige.
Was sehen wir nun hier?
<sbb-cta> welches im HTML Standard so natürlich nicht existiert, aber wir mittels einem Custom Element definieren könnenMit den folgenden zwei Zeilen Code ist man also in der Lage einen benutzerdefinierten Call to Action Button, mit einem einheitlichen Design und Verhalten projektübergreifend / unternehmensweit zu nutzen
Dabei kommt dazu, dass das Styling nicht von aussen beeinflusst wird und in sich geschlossen ist (Komponenten Architektur).
<div class="mod_group mod_timetable_input_form_buttonwrapper" data-timetableInputForm='button_wrapper'>
<button type="submit" class="text__primarybutton button">
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
Verbindung suchen
<svg focusable="false" class="mod_svgsprite_icon var_cta_arrow">
<use xlink:href="#SBB_08_arrow_down"/>
</svg>
</button>
</div>
<!-- dazu kommen Referenzen zu CSS Files sowie SVG Sprites --><script src="https://cdn.app.sbb.ch/base/14.1.1/wc/sbb-ds.js"/>
<sbb-cta text="Verbindung suchen"></sbb-cta>Wie zeichnen sich Web Components aus?
Framework / Plattform agnostisch
Offener Standard (Potential für Hybrid-Apps)
Future Proof
Portabilität
Einfachere Handhabung
Einfachere Wartbarkeit der Komponente
Monitoring / Tracking der Komponenten
Potentiell verbessertes Caching
| Company | Name | in production | OSS |
|---|---|---|---|
| Lit / Youtube | |||
| SAP | Open UI5 | ||
| Salesforce | Lightning Web Components (LWC) | ||
| Apple | Apple Music | ✗ | |
| IBM | Carbon Custom Elements | ✗ | |
| Firefox | Firefox UI |
Sie sind die ideale als Basis für ein Design System (DS)
| Company | Name | in production | OSS |
|---|---|---|---|
| IBM | Carbon | ||
| Microsoft | Fast | ||
| Material | |||
| GitLab | Slippers | ||
| SAP | Open UI5 | ||
| Salesforce | Lightning Web Components (LWC) | ||
| Ionic | Ionic Framework | ||
| LocalTapiola / Turva | Duet | ✗ | ✗ |
| Swisscom | SDX | ||
| Telekom | Scale |
Was ist das ideale Anwendungsgebiet von Web Components?
zu Web Components
Was lief alles im Rahmen / unter Berücksichtigung von Web Components im 2019.
Scope
Outcome
Scope
Outcome
Umgesetzt mit Stencil (Components sowie App) und Redux
Explizit umgesetzt für die Verwendung in Chromium, andere Browser wurden nicht berücksichtigt
Explizit entwickelt für zwei Viewports
Accessibility (a11y) wurde explizit vernachlässigt
Wegen der von Anfang an gesetzten Einschränkungen können die erstellten Webcomponents nicht ohne Weiteres in anderen Kanälen (z.B. Webshop) eingesetzt werden
Für die Ansprüche des Billetautomaten ist die App aus Sicht Frontend quasi produktionsreif
Vereinfachtes Setup
Präsentation am Digitaltag / anderen internen SBB Veranstaltungen mit viel positivem Feedback / hohe Resonanz
Scope
Outcome
Ja, jetzt ist der richtige Zeitpunkt um auf Web Components zu setzen — Konsens des SBB.ch Frontend Teams.
Wir nehmen das Ganze mit viel Zuversicht in Angriff.
Bei dieser Frage gehen die Meinungen bereits auseinander und es ist nicht klar definiert, was alles zu einem Design System gehört und was nicht. Aber man sollte wohl die folgenden Punkte miteinbeziehen.
zwingende organisatorische Aspekte
Was klar ist, ist das Web Components die ideale Basis eines Design Systems sind / sich in ein Design System einfügen — dies sehen nicht ganz unwesentliche Unternehmen (IBM, Ionic, Google, ...) ebenso und haben ein Bestreben dies zu ändern falls dem nicht bereits so wäre.
Wir sehen folgende Rollen:
Für die Erstellung des Duet Design System wurden gemäss ihren eigenen Angaben 4 FTE über 6 Monate benötiget.
Daraus leiten wir die folgenden Ressourcenangaben für den Aufbau ab: 6 FTE über 6 Monate
| Rolle | FTE | Beschreibung |
|---|---|---|
| Product Owner | 0.5 | |
| Frontend Engineer | 3 | |
| Backend Engineer | 0.5 | |
| UX | 1 | |
| Operations / Dev Ops | 0.5 | Node, Build Pipeline, Monitoring |
| "Kommunikator" / Requirement Engineer | 0.5 |
Der Betrieb umfasst folgende Tasks:
4 FTE fortlaufend
| Rolle | FTE | Beschreibung |
|---|---|---|
| Product Owner | 0.5 | |
| Frontend Engineer | 1.5 | |
| Backend Engineer | 0.5 | |
| UX | 0.5 | |
| Operations / Dev Ops | 0.5 | Node, Build Pipeline, Monitoring |
| "Kommunikator" / Requirement Engineer | 0.5 |
Abbau technischer Schuld
Schnellere Entwicklungszyklen / einfachere Wartbarkeit der Komponente
Einfachere Handhabung
Portabilität
Qualitätssicherung
Effizienterer Austausch mit UX / PO / Stakeholder
Effektivere Feedback Loops
DX / UX Happiness
... evtl. hier Risiken auflisten
Mit zunehmender Verlagerung vom Backend ins Frontend kommen auch neue Bedürfnisse im Frontend auf.
Dies dient zum einen dem effizienteren Entwickeln der Anwendungen / Komponenten sowie der Qualitätssicherung der Anwendungen / Komponenten.
| Q1 | Q2 | Q3 | Q4 | |
|---|---|---|---|---|
| Design System | Team Building / Setup | Setup | Übergang Betrieb* | Betrieb* |
| WCMS | minimale Weiterentwicklung | minimale Weiterentwicklung | Betrieb | Betrieb |
| DCS | UX / IA Research | UX / IA Design | Umsetzung Features auf Web Component Basis | Umsetzung Features auf Web Component Basis |
'*' Betrieb der Plattform und keine Web Components Erstellung. Das Team unterstützt die Teams, die wiederum die Web Components / Features umsetzen.
Build Setup / Frontend Tooling
Continuous Integration / Deployment Setup / Betrieb ()
(Schätzung Aufwand: 20-40 PT)
Weiter sollte berücksichtigt werden:
Design System API / Design Token Integration
==================== neuer Slide
Mit zunehmender Verlagerung vom Backend ins Frontend kommen auch neue Bedürfnisse im Frontend auf.
Dies dient zum einen dem effizienteren Entwickeln der Anwendungen / Komponenten sowie der Qualitaetssicherung der Anwendungen / Komponenten.
Hier gibt es 3 Bereiche
zu Web Components
andere Themen