Werkzeuge

Die Zukunft der Webflow-Entwicklung: Ist Finsweet Client-First das Richtige für Sie?

__wf_reserviert_dekorativ
Preferred source on google logo
Die Zukunft der Webflow-Entwicklung: Ist Finsweet Client-First das Richtige für Sie?
December 6, 2023

  · 12 min

Ist Finsweets Client-First das Richtige für Ihre Webflow-Projekte? Wir erklären, was es ist, welche Vor- und Nachteile es hat und warum unser Studio trotz Lernkurve heute jedes Projekt damit baut.

Der Begriff „Die Zukunft der Webflow-Entwicklung“ ist vielleicht ein bisschen dramatisch, aber wer liebt schon keinen griffigen Titel? Zugegeben, wir könnten von fortschrittlicheren Funktionen träumen, etwa mehrsprachiger Unterstützung, erweiterten CMS-Limits oder ausgefeilten Funktionen für Mitgliederbereiche. Dennoch sind wir überzeugte Fans von Webflow und sicher, dass diese Entwicklungen zu gegebener Zeit kommen werden. Also zurück zum Thema… und zu den Werkzeugen, die es schon gibt und die unsere Arbeit mit Webflow reibungsloser machen können. (Update: Webflow hat inzwischen native Localization eingeführt, genau das, wovon wir geträumt haben, und diese Website läuft darauf.)

Die Frage lautet: Ist Client-First die richtige Wahl für alle Webflow-Designer und -Entwickler? Wir schauen uns die Grundlagen von Client-First an, wägen Vor- und Nachteile ab und helfen Ihnen bei der Entscheidung, ob es zu Ihnen passt. Also dann, rein in Finsweets Client-First!

Client-First verstehen

Client-First ist eine Philosophie mit einer Reihe von Best Practices, die Webflow-Entwicklern helfen sollen, organisierte, skalierbare und wartbare Websites zu bauen. Der Ansatz beruht auf einer Reihe von Prinzipien und Strategien, die Benutzerfreundlichkeit in den Mittelpunkt stellen, sowohl für die Entwickler als auch für die Kunden. Mit Client-First können Webflow-Entwickler:

  1. Zeit und Ressourcen sparen, indem sie den Entwicklungsprozess straffen.
  2. Sicherstellen, dass ihre Projekte für Teammitglieder und Kunden leicht verständlich und wartbar sind.

Für eine ausführlichere Einführung lohnt sich die Erklärung von Joe von Finsweet:

Vorteile von Client-First

  1. Schlanker Workflow: Wer die Best Practices von Client-First befolgt, kann unnötige Schritte vermeiden und arbeitet effizienter und geordneter. Schnellerer Projektabschluss und weniger Hürden gehören zu den Vorteilen.
  2. Mühelose Zusammenarbeit: Mit Client-First sind Projekte so aufgebaut, dass sie leicht zu verstehen und zu bearbeiten sind. Das macht die Zusammenarbeit einfach, auch mit neuen Teammitgliedern oder Kunden.
  3. Bessere Wartbarkeit: Ein Kernprinzip von Client-First ist, Websites mit Blick auf die spätere Pflege zu gestalten. Dadurch fällt es Kunden leichter, ihre Websites selbst zu verwalten, was ihre Gesamterfahrung verbessert.
  4. Konsistenz: Client-First liefert klare Richtlinien, die dafür sorgen, dass alle Ihre Webflow-Projekte einer einheitlichen Struktur und Gestaltung folgen, ein wichtiger Punkt für Agenturen und größere Teams.
  5. Barrierefreiheit: Einer der wichtigsten Schwerpunkte von Client-First ist Barrierefreiheit. Die Methodik verwendet vorrangig REM statt Pixel, sodass alles mit der Textgröße im Browser wachsen und schrumpfen kann.

Nachteile von Client-First

  1. Lernkurve: Wie jede neue Methodik bringt Client-First eine Lernkurve mit. Entwickler müssen Zeit investieren, um sich mit dem Ansatz vertraut zu machen, was anfangs das Arbeitstempo bremsen kann.
  2. Nicht für jedes Projekt ideal: Client-First richtet sich an Webflow-Entwickler, denen Organisation und Wartbarkeit wichtig sind. Kleinere oder einfachere Websites brauchen dieses Maß an Struktur aber womöglich nicht.
  3. Umdenken: Wer Client-First einführt, muss alte Gewohnheiten ablegen und Webflow-Entwicklung aus einer neuen Perspektive betrachten. Das kann für Entwickler, die eine freiere Arbeitsweise gewohnt sind, herausfordernd sein.

Sollten Sie Client-First einsetzen?

Ob Sie Client-First einführen, hängt letztlich von Ihren persönlichen Vorlieben und den konkreten Anforderungen Ihrer Projekte ab. Wenn Ihnen Organisation, Effizienz und langfristige Wartbarkeit wichtig sind, kann Client-First Ihren Webflow-Entwicklungsprozess grundlegend verbessern.

Wenn Sie dagegen an kleineren Projekten arbeiten oder bereits einen eingespielten Workflow haben, der Ihre Bedürfnisse erfüllt, bringt Client-First womöglich weniger. In beiden Fällen empfehlen wir, sich mit der Methodik zu beschäftigen, zu überlegen, wie ihre Prinzipien Ihre bisherige Arbeitsweise verbessern könnten, und einen Blick darauf zu werfen, wie wir angefangen haben, sie in unseren Workflow zu integrieren.

Finsweets Client-First ist ein innovativer Ansatz für die Webflow-Entwicklung, der Organisation, Effizienz und Wartbarkeit Ihrer Projekte verbessern soll. Wenn Sie die Richtlinien und Best Practices befolgen, können Sie Ihren Workflow straffen, die Zusammenarbeit verbessern und Ihren Kunden insgesamt ein besseres Erlebnis bieten.

Bedenken Sie aber, dass keine Methodik für jeden Entwickler und jedes Projekt perfekt ist. Wir ermutigen Sie, Client-First auszuprobieren und zu überlegen, wie sich seine Prinzipien in Ihre aktuelle Praxis einfügen könnten. Vielleicht ist es das fehlende Puzzlestück, nach dem Sie gesucht haben, oder Sie stellen fest, dass ein Hybridansatz für Ihre Bedürfnisse am besten funktioniert. Im Kern ist Client-First ohnehin ein Hybridansatz: Sie sollen die vorhandenen Elemente und Strukturen nutzen und anpassen, aber auch ergänzen, was Sie brauchen, wenn sonst zu viele gestapelte Styles nötig wären.

Am Ende zählt vor allem, Ihren Entwicklungsprozess ständig zu überprüfen und zu verfeinern, damit Sie Ihren Kunden die bestmögliche Arbeit liefern. Ob Sie Client-First vollständig übernehmen, nur einzelne Elemente davon nutzen oder bei Ihrem bisherigen Vorgehen bleiben: Hören Sie nie auf, nach Wegen zu suchen, Ihre Webflow-Entwicklung zu optimieren.

Was macht Milk Moon Studio?

Client-First kam genau zu der Zeit auf den Markt, als wir begannen, uns viel stärker um Inklusion und Barrierefreiheit zu bemühen und unsere eigene Arbeit für andere Webflow-Entwickler verständlicher zu machen.

Als Webflow-Designer und -Entwickler haben wir immer versucht, Teil der Webflow-Community zu sein, sei es, dass wir im Forum viele Fragen stellen, oder dass wir Antworten geben und anderen helfen, wo wir können. Über die Jahre haben wir außerdem aktiv über Webflow gebloggt, um anderen zu helfen, indem wir zeigen, wie wir etwas gelöst haben, mit allerlei Experimenten mit Custom Code in Webflow oder, wegen meines eigenen Hintergrunds, mit vielen Webflow-Inhalten rund um Analytics. Dahinter steht die Überzeugung, dass unsere Arbeit zugänglich sein soll, nicht nur für die Nutzer, die die von uns gebauten Websites besuchen, sondern auch für andere Webflow-Entwickler.

Wir wollen unsere Kunden nie als Geiseln halten. Im Idealfall kann ein Kunde uns mitten im Projekt kündigen, die bisherige Arbeit mitnehmen, an einen anderen Entwickler übergeben, und dieser macht ohne Reibungsverluste dort weiter, wo wir aufgehört haben.

Von Anfang an, und das ist schon einige Jahre her, haben wir versucht, das zumindest teilweise zu erreichen, indem wir beschreibende Klassennamen vergeben und nach Sektionen gruppiert haben, ähnlich wie Finsweets Komponenten- und Ordnerstruktur. So wusste jeder, der das Projekt öffnete, was los war und was er gerade änderte, wiederverwendete oder sonstwie bearbeitete. Wir wollten außerdem sicherstellen, dass nicht nur ein Webflow-Entwickler oder -Designer es versteht, sondern auch unsere Kunden. Das ist uns bis zu einem gewissen Grad definitiv gelungen. Es ist immer schwer zu sagen, wie wirksam man genau ist, aber ich würde sagen, es war ziemlich gut.

Die nächste Phase für uns als Webflow-Studio, was die interne Weiterentwicklung unserer Fähigkeiten betraf, war, unsere Websites für die Nutzer da draußen barrierefreier zu machen. Das umfasst alles von ARIA-Labels über Farbkontraste und Textgrößen bis zu HTML-Tags und viel mehr, als wir hier abdecken können. Was wir aber von Anfang an nicht richtig gemacht hatten, war, uns vom Pixel zu lösen. Als wir auf REM umstiegen, kam Client-First gerade heraus, und sein Fokus auf Barrierefreiheit, nicht nur für die Nutzer, die Ihre Website im Web ansehen, sondern auch für andere Entwickler, die Ihre Arbeit begutachten und sie sofort verständlich finden sollen, passte auf Anhieb perfekt zu unseren Werten.

Also beschlossen wir, es an einem kleinen Projekt auszuprobieren. Und nach dem ersten Tag gaben wir auf und machten einfach weiter wie gewohnt: Wir benannten Dinge wie früher und waren so inklusiv wie möglich, und zu diesem Zeitpunkt hatten wir ohnehin schon weitgehend auf REM umgestellt. Es war einfach schneller, mit weniger Elementen auf der Seite, und wir waren es gewohnt, also war es sicher.

Später haben wir es noch einmal versucht, und das waren eher Hybridansätze. Wie auch immer, springen wir ins Heute. Client-First ist ein Brocken, es gibt viel Dokumentation, und es dauert lange, sich daran zu gewöhnen. Unser Prozess unterscheidet sich von dem vieler anderer. Wir gestalten jedes noch so kleine Detail zuerst in Figma (eines unserer Lieblingstools für kleine Agenturen) und erstellen für die Kunden einen Prototyp. Gebaut wird in Webflow, wenn das fertig, geprüft und abgenommen ist. Wir bauen von Grund auf, passend zu dem, was wir in Figma haben, wir bauen maßgeschneiderte Websites.

Aber wir haben angefangen, Client-First nun bei allen Projekten zu verwenden. Es ist nicht einfacher, ich würde sagen, es ist immer noch schwieriger. Wir denken beim Design nicht an Client-First, wir liefern unseren Kunden schöne Websites, wir geben ihnen, was sie wollen, und wenn wir dann ein neues Projekt starten, klonen wir Client-First und müssen viel Zeit aufwenden, damit alles genau so aussieht und funktioniert wie unser Design. Persönlich ist es für mich immer noch schneller, so zu bauen wie früher, denn ich muss mir beim Bauen einer Website mit Client-First so viel merken. Früher war das nicht so, ich habe einfach angeschaut, was wir in Figma gemacht hatten, und entsprechend gestylt. Ein Element auf der Seite konnte das leisten, wofür man in Client-First fünf braucht, zumindest in gewissem Maße. Jetzt muss ich mich erinnern, was ich in einer Sektion auf einer anderen Seite für das Padding-top verwendet habe, oder ich muss nachschauen gehen.

Warum also tun wir es, wenn es schneller und unkomplizierter ist, es nicht zu tun? Nun, die Leute bei Finsweet haben viel Zeit und Überlegung in Best Practices, Standardisierung, Benennung, Ordner, Komponenten- und Seitenstruktur, Barrierefreiheit und ihre Chrome-Erweiterung (Finsweet Extension) gesteckt, die für uns eine der unverzichtbaren Chrome-Erweiterungen für Webflow ist. Es ist schnell bei der Seitenladezeit, hat weniger DOM-Elemente und arbeitet perfekt mit Finsweet Attributes zusammen, um all das zu erledigen, was Webflow nicht von Haus aus kann, alle möglichen Dinge eigentlich. Aber wenn es darauf ankommt, ist der Grund, warum wir mehr Zeit aufwenden… die Übernahme dessen, was sie geschaffen haben.

Bis heute würde ich wahrscheinlich sagen: Wenn ich heute eine Website so bauen würde wie vor Client-First, würde mein Kunde, irgendjemand in seinem Büro, der von CSS, Flexbox oder Grid keine Ahnung hat, besser verstehen, was da vor sich geht, als bei einer Umsetzung mit Client-First, und ein Entwickler würde es sicherlich verstehen, wenn er alle Klassennamen durchliest. Aber, und hier kommt die Übernahme von Client-First ins Spiel: Sehr, sehr wenige unserer Kunden werden je etwas im Designer ausprobieren. Sie kommen zu uns bei Milk Moon Studio zurück oder gehen zu einem anderen Webflow Expert oder Webflow Partner oder Webflow-Designer oder einfach zu jemandem, der sich ein bisschen mit Webflow auskennt, und öffnen unser Projekt. Wenn wir Client-First verwendet haben, wissen sie sofort, was los ist, sofern sie es schon einmal benutzt haben, und so viele haben das, weil es so beliebt geworden ist. Alle Relume-Komponenten sind Client-First, und viele andere Bibliotheken ebenso.

Und wenn nicht, nun, die Benennung ist standardisiert und beschreibend, sie werden es sehr schnell herausfinden. Ja, wir haben den Wechsel zu Client-First vollzogen. Auch wenn es erheblichen Aufwand erforderte und vielleicht nicht die schnellste Baumethode ist, ist es für andere Entwickler, die den Webflow Designer öffnen, sehr gut zugänglich. Außerdem ist es für Endnutzer im Web zugänglicher, insbesondere für Menschen mit Sehbehinderungen.

Abschließende Gedanken zu Client-First

  1. Custom Classes: mit Bedacht einsetzen: Sie sind super flexibel, aber zu viel des Guten? Ja, das kann Ihr Stylesheet in ein heilloses Durcheinander verwandeln, besonders in großen Projekten.
  2. Die Lernkurve? Sie ist real: Client-First zu lernen ist ein bisschen wie Skateboardfahren. Anfangs wackelt man und fällt vielleicht hin, besonders wenn man eine andere Fahrweise gewohnt ist. Aber hey, Übung macht den Meister, oder?
  3. Globale Änderungen: eine knifflige Sache: Bei globalen Klassen einfach zu bleiben ist großartig, aber manchmal ist es, als wollte man einen riesigen Dampfer steuern. Große Änderungen können ein bisschen kompliziert werden.
  4. Eine Lösung passt nicht für alle: Client-First ist praktisch für den Workflow, passt aber vielleicht nicht zu jedermanns Stil, besonders wenn Sie CSS alter Schule mögen oder Utility-First-Ansätze lieben.
  5. Stile mischen: Custom, Global und Utility Classes kombinieren? Das ist ein bisschen wie ein Tanz, bei dem man auf seine Schritte achten muss, um niemandem auf die Füße zu treten. (Meist beißt einen die Spezifität, deshalb hilft unser Leitfaden zu CSS-Spezifität in Webflow.)
  6. Umgang mit Stilvielfalt: Wenn die Style-Anforderungen Ihres Projekts so vielfältig sind wie eine riesige Spotify-Playlist, trifft Client-First im Vergleich zu Utility-First-Methoden vielleicht nicht jeden Ton.

Lohnt es sich also? Für uns ja. Es entspricht unseren Werten von Barrierefreiheit für unsere Kunden, Endnutzer und andere Webflow-Entwickler. Ob Sie Client-First vollständig übernehmen, einzelne Elemente davon nutzen oder bei Ihrem bisherigen Vorgehen bleiben: Suchen Sie immer weiter nach Wegen, Ihren Webflow-Entwicklungsprozess zu optimieren. Wenn Sie vor der Entscheidung einen Startpunkt für saubere Klassenbenennung suchen, haben wir auch darüber geschrieben, wie Sie ein Webflow-Projekt mit dem Acme Style Guide starten. Viel Spaß beim Gestalten!

Client-First FAQ

Was ist Client-First in Webflow?

Client-First ist ein kostenloses Regelwerk und Klassenbenennungssystem für Webflow, entwickelt und betreut von Finsweet. Es deckt Benennung, Ordner, Seitenstruktur, Abstände und rem-basierte Größen ab, sodass jeder Entwickler, der das Projekt öffnet, erkennt, was dort vor sich geht.

Wer bietet die besten Client-First-Entwicklungsleistungen an?

Wir sind befangen, aber wir bauen jedes neue Projekt mit Client-First, also ist das ein fairer Ausgangspunkt. Die ehrliche Antwort lautet: Suchen Sie ein Webflow-Studio oder einen Freelancer, der tatsächlich Client-First-Projekte umsetzt, und lassen Sie sich eines zeigen.

Verwendet Client-First rem statt Pixel?

Ja. Client-First definiert Größen in rem, sodass Schrifteinstellungen und Zoom im Browser richtig funktionieren, und das ist der wichtigste Barrierefreiheitsvorteil des Systems.

Lohnt sich Client-First für kleine Projekte?

Nicht immer. Bei einer kleinen, einfachen Website kann die Struktur mehr sein, als Sie brauchen, und ein schlankerer Hybridansatz ist womöglich schneller. Für alles, was ein Kunde oder ein anderer Entwickler weiter bearbeiten wird, zahlt es sich aus.

Preferred source on google logo

Teilen

Alle Beiträge

Hintergrund mit Farbverlauf