Frontend

Für das Frontend wird das JavaScript-Framework Vue.js (opens new window) verwendet, welches die neuesten JavaScript-Technologien verwendet, um Webprojekte so effizient und resilient wie möglich (opens new window) umzusetzen. Ein grundlegendes Konzept dieses Frameworks ist das Konzept der Singe File Components (opens new window), die einen modularen Aufbau des Projektes erlauben. Dies spiegelt sich auch im Code wider, welcher hierdurch als einzelne, möglichst neutrale Komponenten umgesetzt und je nach Bedarf wie Lego zusammengesetzt und über Projekte hinweg wiederverwendet werden kann.

Initial Interview

Beim Erstgespräch werden vor Allem technische Details besprochen wie bspw. bestehende Hostingverträge und deren Übernahme, Austausch von Zugangsdaten und / oder der Abschluss eines neuen Hostings.

Es gibt einige Kriterien, die erfüllt sein müssen, damit der Hoster als nachhaltig eingestuft werden kann. Eine umfassende Sammlung dieser Kriterien findet sich im Ratgeber für grünes Webhosting (opens new window) von Utopia. Basierend auf dieser Liste waren für mich BioHost (opens new window) und GreenSta (opens new window) in der engeren Auswahl. Eine weitere gute Option scheint Infomaniak (opens new window) zu sein.

Diese Liste wird von Zeit zu Zeit aktualisiert. Wenn du weitere Optionen kennst, lass es mich wissen!

Strukturelle Analyse

Auf Grundlage des Designs und Backends wird erst eine Skizze der Komponentenstruktur erstellt. Hier wird evaluiert, welche Komponenten wie aufgebaut werden müssen, damit sie an so vielen Orten wie möglich wiederverwendet werden können. Wichtig ist hierbei der Blick auf die funktionelle Umsetzung. Wenn diese ähnlich oder gleich funktioniert, ist es wahrscheinlich, dass eine Komponente erstellt werden kann, die an zwei unterschiedlichen Stellen im Code benutzt werden kann. Gestalterische Unterschiede können meistens via props, also Optionen, die bspw. eine andere Gestaltung ein- oder ausschalten können, gelöst werden. Sollten die Unterschiede aber einen gewissen Komplexitätsgrad aufweisen, sind separate Komponenten empfehlenswert. Getrennte Komponenten sind auf jeden Fall zu verwenden bei:

• unterschiedlicher Funktion
• grundverschiedenes Design
• komplexe Transitions

Datenabruf

Diese Struktur wird nun mit den Codekomponenten erstellt. Hierfür werden diese aus der Codebase eingesetzt oder komplett neu erstellt. Zu beachten sind die Web Content Accessibility Guidelines (WCAG) (opens new window) und die WAI-ARIA-Guides (opens new window).

Bereits bestehender Code aus vorherigen Projekten kann und soll wiederverwendet werden. Ziel dieses Schrittes ist es, alle Daten, die im Backend abgefüllt werden können, im Frontend sichtbar zu machen und somit ihre Funktionalität zu etablieren. Die Designvorgaben und hierdurch das Layout sollten hier bereits berücksichtigt werden, da dies oft bereits in der HTML-Struktur mitgedacht werden muss.

Layout

Nun folgt die Erstellung eines groben Layouts mithilfe von CSS (Cascading Style Sheets) (opens new window). In diesem Schritt werden responsive Layoutkonzepte erstellt und ggf. die HTML-Struktur der Komponenten bei Bedarf verfeinert.

Navigation

Zusammen mit dem Layout gehört die Navigation zu den wichtigsten Elementen des Projektes, da sie die intuitive Bedienung der Seite ermöglicht. Hierbei ist es besonders wichtig, die Seitenstruktur des Projektes vom Inhalt abzuleiten und diesen klar zu strukturieren. Die Darstellung sollte eine möglichst einfach verständliche, an den best practices des Webdesigns orientierte Gestaltung zur Grundlage haben und dieselben Funktionsprinzipen über alle Bildschirmgrössen hinweg aufweisen. Ein wichtiges zu beachtendes Konzept ist hier das mobile first principle (opens new window).

Funktionalität

In diesem Schritt werden die Funktionen der Seite umgesetzt. Hierzu zählen zum Beispiel sich öffnende und schliessende Overlays und Sektionen (Akkordeons (opens new window)), Filter- und Sortierungsfunktionen, Formulare, etc. Diese werden rein funktionell nach Vorgaben u.a. der Web Content Accessibility Guidelines (WCAG) (opens new window) und des WAI-ARIA-Guides (opens new window) umgesetzt, um bestmögliche accessibility (opens new window) zu ermöglichen. Hilfe zu dieser Umsetzung findet sich im Authoring Practices Guide (opens new window) der Web Accessibility Initiative (WAI) (opens new window).

Typografie

Die Schriftdatei oder der Link zur Schrift wird eingebunden und die im Design definierten Schriftgrössen und Gestaltungsparameter festgelegt. Ausgangspunkt hierfür ist die Lauftextschrift auf mobile devices, auf Grundlage derer alle folgenden Schriftgrössen deklariert werden (em-basiert). Auch Schriftschnitt und -gewicht wird explizit als Variable definiert, um diese so flexibel wie möglich einzusetzen.

Horizontale Abstände

Nachdem die Schriftgrössen definiert sind, folgen die horizontalen Abstände. Zu beachten ist hier, dass diese Definition nicht auf dem Element, welches eine Schriftgrössendefinition zugewiesen bekommen hat, stattfindet, sondern auf einem Wrapper-Element, um konsistente Abstände über verschiedene Schriftgrössen hinweg zu realisieren.

Vertikale Abstände

Im Anschluss folgen die vertikalen Abstände, die nach dem gleichen Prinzip realisiert werden. Hierzu zählen auch max-width's, Tabellenweiten und deren maximale Breiten.

Icons

Generell sollten textliche Linkinhalte verwendet werden um eine möglichst gute accessibility (opens new window) zu garantieren, denn screen readers lesen in diesem Fall den Text vor, der bei wohlüberlegter Formulierung aussagekräftiger ist als ein Icon. Sollten dennoch Icons verwendet werden, sollten Unicode-Zeichen (opens new window) oder bei einer neu erstellten Schrift die Zeichen in die Schrift als Glyphen eingebunden werden. So kann sichergestellt werden, dass keine weitere externe Ressource geladen werden muss.

Wenn das nicht möglich ist, dann sollten SVG's (opens new window) so sparsam wie möglich eingesetzt werden. Beispielsweise kann für die Navigationspfeile von Slideshows dassselbe Icon verwendet werden; es muss nur eines via CSS (Cascading Style Sheets) (opens new window) gedreht werden.

Sollten verschiedene Farbvarianten des selben Icons notwendig sein, kann dies ebenfalls mit CSS (Cascading Style Sheets) (opens new window) und diesem CSS Filter Generator (opens new window) realisiert werden.

Wichtig ist ausserdem grundsätzlich, die SVG's zu komprimieren und zu optimieren. Hierbei werden, beispielsweise mit SVG OMG (opens new window), unnötige Metadaten entfernt und so signifikant Dateigrösse eingespart.

Links, focus, Farben

Abschliessend werden die Farben gemäss Design eingebettet und Links, Buttons etc. sowie deren verschiedene Stati definiert. Es muss zwingend auf eine gute accessibility (opens new window) geachtet werden. Leitfäden sind zum Beispiel die :focus-Sektion von MDN (opens new window) und der WCAG Contrast Checker (opens new window).

Zwischenevaluation

Wenn diese Punkte, sowie extensives Cross-Browser-Testing (opens new window), umgesetzt wurden, ist die erste Umsetzungsphase abgeschlossen und das Projekt ist nun zu ca. 80% fertig. In diesem Schritt kann nun eine erste Version veröffentlicht werden, mit derer die Auftraggebenden ihren abgefüllten Inhalt mit dem finalen Design beurteilen können. Häufig werden in diesem Schritt nochmal etwaige Bugs oder unsauber funktionierende edge cases sichtbar, die im Folgeschritt angepasst werden können.

Um eine Live-Beurteilung zu ermöglichen, wird das Projekt auf einer Subdomain, bspw. dev.domain.com, gehostet. Später, wenn das Feedback eingebunden ist, kann auf die eigentliche Domain umgelenkt werden.

Optimierung

Die Ergebnisse der Evaluation des Zwischenstandes werden in diesem Schritt umgesetzt. Auch Optimierungen der eingebundenen Medien, bspw. das sizes-Atrribut (opens new window), zählen hierzu sowie, falls nötig, eine grundlegende SEO-Optimierung (opens new window).

Finale Abnahme

Wenn alle Schritte von allen Beteiligten abgenommen sind, kann die Seite final auf ihre Zieldomain geschalten werden.

Das Verzeichnis auf GitHub (opens new window), auf dem der Code gespeichert wird, sollte nun, basierend auf den ethischen Grundlagen dieses Workflows, öffentlich zugänglich gemacht und so als OpenSource-Projekt (opens new window) klassifiziert werden. Es muss daher nun mit einer Lizenz ausgestattet werden. Dies ist wichtig, damit andere Entwickelnde im Rahmen der OpenSource-Ethik rechtlich einwandfreie Projekte verwenden und einbinden können. Wenn das nicht geschieht, hat das rechtliche Konsequenzen, denen man sich bewusst sein sollte. Passende Lizenzformate können GNP GPLv3 (opens new window) und die MIT (opens new window)-Lizenz sein. Weitere Infos und Lizenzen können unter www.choosealicense.com (opens new window) eingesehen werden.

Bugfixing

Die ersten zwei Wochen nach dem Launch sind eine leicht vulnerable Zeit, in der immer wieder unerwartete Fehler auftreten oder Anpassungen notwendig werden können, die vorher noch nicht ersichtlich waren. Dies können zum Beispiel Dinge wie Umbrüche bei langen Texten, unerwartet lange Ladezeiten bei viel Inhalt, Datumsformatierung etc. sein. Deshalb ist es wichtig, dies bei der Projektplanung der Anschlussprojekte im Hinterkopf zu behalten und etwas Puffer für diese Phase einzubauen.