Ich habe in den letzten Jahren unzählige Webseiten mit React, Vue oder anderen Frameworks gebaut. Was all diese Seiten gemeinsam haben? Sie mussten ständig aktualisiert werden, um mit den neuesten Trends und Updates Schritt zu halten.
Und dann gibt es da die paar Seiten, die ich vor Jahren mit Web Komponenten testweise erstellt habe. Wisst ihr was? Sie funktionieren immer noch – und nicht nur das: Sie haben sogar an Funktionsumfang gewonnen! Dank der kontinuierlichen Unterstützung durch immer mehr Browser haben sie sich fast von selbst weiterentwickelt.
Es gibt schlicht keinen Grund mehr, auf Web Komponenten zu verzichten. Vielleicht bist du skeptisch oder hast Angst vor „Neuem“? Aber mal ehrlich, so neu sind sie nicht. Schon 2019 habe ich in Blogposts dafür geworben, endlich Web Komponenten zu nutzen.
Was meint ihr? Sollten wir die ganzen Frameworks mal für eine Weile in den Urlaub schicken und das Web so gestalten, wie es gedacht war?
Irgenwie trage ich immer mal wieder was vor oder halte Präsentationen. Dabei vergesse ich immer diese für mich festzuhalten. Vor allem ist es praktisch, wenn du einfach schnell auf ein Backup zurückgreifen kannst. Ich digitalisiere gerade einiges was ich vorliegen habe und es wird immer mehr.
Some months back I created for my current employer a blog post on Design System Managers, and this evolved over time. This is the natural continued post.
In the subsequent sections, we present our comprehension of your requirements, outline our recommended strategy for this product, and describe the potential workflow based on our in-depth deliberations.
1. Initiating the Journey
Starting point & challenges
A brand relaunch at our client prompted the development of an online Brand Style Guide. This guide encompassed all the necessary information for crafting a brand-compliant digital experience across their digital landscape.
A Figma Master served as the definitive source for design elements. In the past, each design team developed its components based on their needs, building on the existing library.
This resulted in design inconsistencies. Developers established code libraries derived from these designs. However, the output varied significantly, leading to inconsistencies across digital touch-points and hindering the achievement of a cohesive look and feel.
Our approach involves employing Publicis Sapient’s best practices to develop a distinct and user-friendly toolkit for both designers and developers.
Team up and let‘s go
Initially, we assembled a dedicated team focused on constructing a Continuous Experience Pipeline in both design and code. This pipeline supports the brand design guidelines and functions as a reliable source of truth. All stakeholders involved in developing projects for the brand must adhere to this framework.
Subsequently, we shifted into problem-solving mode to assess the current situation, identify gaps, and address existing issues. We devised the workflow for a reusable product that can be easily implemented in various projects.
2. Defining Our Mission
Establish a unified comprehension and a definitive source for UI assets and code to ensure a cohesive and streamlined user experience across all digital interactions.
Upon consolidating the insights, we formulated a mission statement to guide our efforts towards our overarching objective.
To achieve this, we went beyond merely developing a library with reusable code.
Through a distinctive toolkit, a specialized workflow, and a structured process, we crafted a supportive solution for both designers and developers. This approach simplifies communication and effortlessly ensures consistency with the brand’s look and feel.
3. Crafting Our Strategy
Let‘s do this!
Considering the participants‘ requirements, we have established quality benchmarks and optimized the process and workflow across all actions. Key features include a centralized system that integrates cutting-edge design with efficient code and an easy-to-understand, streamlined process. You will be able to contribute design and code components while utilizing the assets from the Continuous Experience Pipeline.
4. Developing Our Process
How we make it happen
The procedure involves a collaborative effort from all contributors and disciplines, including designers and technical personnel. In adherence to brand design principles, we examine, enhance, and develop UI (User Interface) components to address the challenge of inconsistent design across touch-points.
5. Establishing Workflow Fundamentals
The How
We have established ‚workflow fundamentals‘ for our product, supporting the continuous experience pipeline:
Foundation: Initially, we examined various code and design outputs from different teams. The most effective elements from both domains form the basis of our work.
Standards: Our focus is on four key aspects: information should be Perceivable, interfaces should be Operable, content should be Understandable, and the significance of the content should be Robust to accommodate changes in the way it is accessed.
Design Tokens: We define all fundamental components of the design system in a structured and user-friendly manner. Design Tokens enable us to implement and modify these basic rules as needed.
Single Source of Truth: In accordance with brand design, we maintain a master file for all components and apply design tokens to it. Developers can utilize these token definitions to generate code that adheres to user experience and accessibility standards.
6. Implementing Tools & Streamlining Workflow
Good alignment between Experience and Engineering
Tools in design
Figma — Design System in design
Token Studio— A design token is a design decision
Tools in design
Tools in code
Web Components— Stencil Library
Bitbucket — Git code management
Storybook— UI development, testing
Docusaurus – documentation
npm— JavaScript package provider
Tool setup and workflow
Integrated working between Experience and Engineering
We integrate tools to create a robust and efficient Continuous Experience Pipeline.
To ensure the highest quality across all disciplines, we have implemented approval processes overseen by gatekeepers.
If you have an alternate tool-set or environment, adjustments should be made to accommodate your specific requirements.
7. Fostering Collaboration
Team up
We collaborate to contribute and utilize design and code elements effectively.
As product owners, we actively engage with consumers, partners, and stakeholders, constantly enhancing the quality of our deliverables. The Continuous Experience Pipeline is accessible to any team interested in adopting the same process.
We provide guidance and support through team chats, issue tracking, and regular feedback sessions conducted by our specialists.
8. Realizing the Benefits
What comes with it…
Optimized Component Toolkit / Unified Source of Truth in UX, Design, and Code / Time and Cost Efficiency / Seamless Integration and Contribution / Simplified On-boarding / Rigorous Quality Standards / Regular Updates
9. Achieving the Results
Satisfied Customers: Experience a consistent brand design across all touch-points, ensuring a cohesive user experience.
Content Clients: Streamlined on-boarding and workflow reduce time and costs, making project execution more efficient.
Delighted Designers: Rely on a single source and process with ready-to-use components to accelerate your workflow.
Avoid Shortcuts: Often, the quickest solution isn’t the best one. We prioritize thorough approaches over shortcuts to address challenges effectively.
Make Decisions and Commit: Effective solutions are based on clear reasoning. Our decisions are driven by well-founded rationale.
Build Alliances: In large organizations with global business units, communication can be complex. To gain momentum for your project, forge partnerships with supportive allies.
Implement Design Tokens: Streamline your design system’s foundation to improve the handover process between designers and developers, making it more efficient and faster.
Value Feedback: As the Continuous Experience Pipeline is a product, feedback is invaluable. Embrace it and strive for immediate improvements.
Promote Collaboration: A dynamic library requires a collective effort. We continually encourage participation and teamwork among all stakeholders.
Get in touch in case of any question. We’d love to work with you.
Designsysteme sind zu einer wesentlichen Komponente in der Welt des Web- und Produktdesigns geworden. Sie bieten eine gemeinsame Sprache und eine Reihe von wiederverwendbaren Komponenten, die Konsistenz, Effizienz und Skalierbarkeit fördern. In diesem Blog-Beitrag erörtere ich, wie ich Tag für Tag einen Designsystem-Manager entwickle. Dabei werden Schlüsselaspekte wie Design-Token, Responsive Design, atomares Design, Barrierefreiheit, Belastbarkeit, Kostenreduzierung und verschiedene Tools wie Figma, Token Studio, Docusaurus, Webkomponenten und natives CSS angesprochen.
Design-Token
Design-Token sind eine Möglichkeit, Design-Entscheidungen zu speichern und zu verwalten, z. B. für Farben, Typografie und Abstände. Sie bieten eine einzige Quelle der Wahrheit, die leicht aktualisiert und plattformübergreifend genutzt werden kann. Bei der Entwicklung meines Design System Managers verwende ich Tools wie Token Studio, um meine Design-Token zu erstellen, zu organisieren und zu verwalten. Dies trägt dazu bei, die Konsistenz zu wahren und Aktualisierungen zu optimieren.
Responsive Design
Responsive Design ist die Praxis der Erstellung von Designs, die sich an verschiedene Geräte und Bildschirmgrößen anpassen. Bei der Arbeit am Design System Manager stelle ich sicher, dass die Komponenten flexibel sind und sich nahtlos an verschiedene Bildschirmauflösungen anpassen. Dazu verwende ich Responsive Design-Techniken wie Media Queries, Fluid Grids und flexible Bilder, um ein konsistentes Nutzererlebnis auf verschiedenen Geräten zu gewährleisten.
Atomic Design
Atomic Design ist eine Methode, bei der das Design in kleinere, wiederverwendbare Komponenten, so genannte Atome, Moleküle und Organismen, unterteilt wird. Dieser Ansatz vereinfacht den Designprozess und fördert die Konsistenz des gesamten Systems. Bei der Entwicklung meines Design System Managers nutze ich die Prinzipien des atomaren Designs, um eine modulare und skalierbare Struktur zu schaffen, die es einfach macht, Komponenten nach Bedarf hinzuzufügen, zu entfernen oder zu ändern.
Zugänglichkeit
Barrierefreiheit ist von entscheidender Bedeutung, um sicherzustellen, dass alle Benutzer, einschließlich Menschen mit Behinderungen, digitale Produkte effektiv nutzen und mit ihnen interagieren können. Bei der Erstellung des Design System Managers lege ich Wert auf Barrierefreiheit, indem ich bewährte Verfahren wie korrektes semantisches HTML, die angemessene Verwendung von ARIA-Attributen und die Einhaltung der WCAG-Richtlinien einbeziehe. So wird sichergestellt, dass die Komponenten des Designsystems für jeden zugänglich und nutzbar sind.
Ausfallsicherheit
Resilienz im Design bezieht sich auf die Schaffung eines Systems, das Veränderungen standhalten und sich an verschiedene Szenarien anpassen kann. Im Kontext eines Designsystemmanagers bedeutet Resilienz, Komponenten zu bauen, die flexibel, modular und einfach zu warten sind. Ich erreiche dies, indem ich Webkomponenten und natives CSS verwende, um wiederverwendbare Elemente zu erstellen, die leicht angepasst und auf verschiedene Situationen eingestellt werden können.
Vorteile und Kostenreduzierung
Designsysteme bieten zahlreiche Vorteile, darunter schnellere Designprozesse, verbesserte Zusammenarbeit und geringere Wartungskosten. Durch die Entwicklung eines robusten Designsystem-Managers kann ich sicherstellen, dass mein Team Designs effizient erstellen und überarbeiten kann, während gleichzeitig ein konsistentes Benutzererlebnis erhalten bleibt. Dies wiederum führt zu Kosteneinsparungen, da der Bedarf an umfangreichen Designüberarbeitungen und -aktualisierungen sinkt.
Werkzeuge
Während der Entwicklung des Design System Managers verwende ich eine Vielzahl von Tools, um den Prozess zu vereinfachen und die Zusammenarbeit zu verbessern. Figma, ein kollaboratives Designtool, ermöglicht es meinem Team, in Echtzeit gemeinsam an Entwürfen zu arbeiten. Docusaurus ein Open-Source-Tool für die Dokumentation von UI- und Softwarekomponenten, hilft mir dabei, Komponenten zu visualisieren und isoliert zu testen, um sicherzustellen, dass sie in verschiedenen Kontexten korrekt funktionieren.
Fazit
Der Aufbau eines Designsystem-Managers ist eine fortlaufende, tägliche Aufgabe, die eine ständige Verbesserung und Verfeinerung erfordert. Indem ich mich auf Schlüsselaspekte wie Design-Token, responsives Design, atomares Design, Zugänglichkeit, Belastbarkeit und Kostenreduzierung konzentriere, kann ich ein robustes und effizientes System schaffen, von dem sowohl Designer als auch Benutzer profitieren. Mit Werkzeugen wie Figma, Token Studio, Docusaurus, Webkomponenten und nativem CSS kann ich vieles vereinfachen und sicherstellen, dass der Designsystemmanager flexibel und skalierbar bleibt und sich an die sich ständig weiterentwickelnde Welt des digitalen Designs anpassen kann.
Letze Woche stellte ich fest, dass ich in über 20 Jahren Internet-Aktivitäten als Web Developer für viele Marken gearbeitet habe. Heute dann die Idee, dass ich diese einfach mal liste.
Das ist nicht chronologisch noch alphabetisch, sondern einfach nur wie sie mir einfielen.
Herta
Nestlé
Pritt
B&O
IMD
Celerant
Fraport
Commerz Netbusiness
Lufthansa
MSH
BSH
Marcs & Spencer
Ladbrokes
Vodafone
Telekom
1und1
Ticona
DHL
McDonald’s
HSBC
John Hancock
Siemens
Carnival
Fleurop
O2
Daimler
Mazda
Audi
Volkswagen
Bob Bomliz Group
Red Bull
Aegean Airlines
ProSieben
Katjes
MLP
EnBW
Swisscom
Jive
Dept of Health-UK (NHS)
Hansgrohe
VisitBritain
Sky
Mars
Kia
Richemont
Bausch & Lomb
Hugo Boss
Sanofi
Unilever
VF Corporation
Globetrotter
Sonepar
Es waren sicherlich noch mehr dabei, diese hier sind mir nur beim kurz darüber Nachdenken eingefallen.
Content Management Systems as we use them today go back to the times when the Internet was invented by Tim Berners-Lee in 1990. Data and Content had to be stored somewhere — and even more important — had to be maintained and updated. Initially, most contents were created like documents, edited, and stored as static pages. This is enhanced with the need for dynamic content, interaction like commenting, or linking.
First CMS were still providing static HTML pages, that were rendered server-side by Script Languages like PHP, JSP, ASP, or other template languages or engines that have been created like TWIG, HTL, or Freemarker. Allowing to interact with the pages with added forms. Nowadays with Node as JavaScript (we cover this later)
This came with some problems as to how HTML is used, contents were only available in one format, and the source was created on a server that did not know anything about the device it was rendered on. With upcoming Mobile, but also other IoT devices it was hard to render this content appropriate on all devices.
CMS and technology timeline
What does this mean?
While the content was rendered into a unique layer of HTML on the server-side, only CSS was able to design this output. There was a hard binding from Content to HTML. This caused less flexibility and relaunch. Or re-using of content created effort in re-creating the server-side rendering. CSS could always re-create new designs with existing content if HTML is written properly. (Examples like CSS Zengarden are showing this for decades) But this heavily depends on semantic Markup and no Elements used that cause already design (like line breaks, <div> containers that represent design or similar).
Nowadays we can adjust layout and design with CSS and Media Queries. There were times when browsers were not supporting this well.
How do traditional CMS monoliths work?
A traditional CMS is a software that you either install and manage yourself or in a managed server environment. Traditional CMS is also known as “monolithic” because they contain all functions and assumptions for working in a single system. Traditional CMS often offers a visual authoring interface for editing content (WYSIWYG), as they only have one context for displaying the content — usually a website. The system normally offers a direct editing layer on an existing rendered layout.
Headless vs monolithic
The headless CMS only contains a data layer and authoring. They provide an API for a headless rendering layer that consumes the data. The aforementioned is also one of the challenges. How can you render a WYSIWYG experience when your authoring system does not know about the rendering?
A new generation of CMS were invented. These often offer additionally Headless on existing systems, like CoreMedia for example, where besides Freemarker Template, a Headless GraphiQL server exists.
How to consume headless data
Headless also provides the possibility to get a content hub to ensure “Content first” implementation. Your one base of content will be able to maintain a bucket of additional endpoints.
The CMS as Content Hub
This data will be consumed via APIs — below are some examples.
Representational state transfer (REST)
Rest API
REST is a software architecture style that defines how to create web services. Web services, which conform to the REST architectural style and are known as RESTful Web Services, provide interoperability between computer systems on the Internet. RESTful web services allow the requesting systems to access and manipulate web resources using a set of stateless operations.
GraphQL
GraphQL
GraphQL is a query language for your API. Also, a server-side connection for executing queries belongs to a type of system to use for your data management. GraphQL is not tied to a personal database or storage engine and is driven by hidden code and data management.
A GraphQL service will have types and fields for those types. There are functions for each field from each type.
This is the rising star, as it offers flexibility not known before.
GROQ
I mention GROQ though it is not really widely used, but as I see similarities to GraphQL worth sharing.
Advantages
Use cases for headless CMS can be the following: You need to build a website with a technology you are familiar with, or web apps that use JavaScript frameworks like VUE, React, Svelte, Web Components, or Angular. Native mobile apps for iOS or Android can be directly consuming content. As you have seen, it’s not limited to websites.
Where headless helps:
Your team is familiar with a special UI Technology.
There is a need for A/B tests
If you require a client-side rendered Framework like VUE, React, etc
Editing your content can be harder for authors on headless systems. Your System is depending on a second screen/system.
Websites created with traditional CMS, allow customizable zones, and authors can resize and rearrange dynamic content easier. They are not limited to edit dynamic data in a fixed zone. They are enabled to share content easier.
With headless, authors often can’t customize the placement or presentation much beyond given forms, without implementing configurable content grids. Dragging and dropping components is getting harder, as the components only exist as data and rely on a presentation layer.
It can be more expensive to implement and the share of costs can get more complicated when only one unique source exists, but multiple layers consume it.
Search Engine Optimization can also be trickier. Server-side Rendering (SSR) needs to be implemented for deep linking. SSR makes it even more complex. There are some advantages with server-side rendered JavaScript, but it is still an effort to consider. Think twice before considering headless. There can be use-cases where all of the above is not relevant. Usage depends.
Conclusion
There is no black and white decision possible. It depends on your team’s skills, your client’s or customers‘ needs, your project setup, and so on. Just make the right decision in the beginning.
At my current employer we do all kind of Web Applications. We call it Experience Technology. These customer user experiences have different needs. Sometimes we do static content deliverables like temporary marketing campaign pages, or knowledge bases that never get touched again. More often we do enterprise shopping experiences, catalogue maintenance, and other e-commerce platforms.
Asking someone of my team how to build their next customer user experience I get named: React, VUE, Svelte or at last, Angular. Normally no one tells me yet: Let’s do it native, let’s use Web Components.
Do I know why?
Maybe
Why the frameworks are so common and preferred is having some reasons:
They offer a community
Searching for an issue or supporting library for sure returns an Stackoverflow entry or an NPM library
There is great support by someone that has „already done this“
For Business: It is good to have something to sell that everyone knows
A quick poll
Doing a quick poll with our experience technologists hardens the opinion.
Showing React 58%, Angular 3%, VUE 15%, Native Web Components 7%. Other 13%
Observing the obvious
Using frameworks and libraries for everything, causes problems that could be prevented. Average weight of a page is increasing. Complexity of generated code too. Views of common frameworks and libraries are often ridiculous complicated and deep nested and adding libraries and grid systems is done with a click. Importing without seeing the direct deeper effect. On top of that, Designers create complex animations and placeholders and forget that we still have low-end devices to support and not an ideal-world fast internet. Accessibility and search, like find-ability is getting worse. When useless containers are nested and semantics are getting lost.
On top of all, GDPR compliance is bad to achieve as of often third parties are used in a way that makes it hard to know where your customers details are getting shared.
This directly leads me to the this ask: Do we at all need to use a framework or library? Can’t we use Web components?
Webcomponents.org tells a clear use case, but why does still no one considers it first place to use it as base in their projects?
Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML. Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behaviour.
Webcomponents.org
Would there be any advantage when using them instead of a framework? Long-term for sure. Imagine a situation where Facebook stops support for React, or Google for Angular. Sooner or later libraries might get outdated. The community for sure support it for some years, but it can stop. There is no guarantee that it works long. There are also new Libraries popping out every day.
As we started writing decoupled user experiences, using micro-services and micro-frontends, we forgot to enable us to create long lasting frontend code, that is maintainable. Instead of using native functionalities, write proper markup and getting accessible and search engine friendly.
We now create a dependency to a framework that is maybe out-dating soon. Any reason to do so?
Not really!
Frameworks and libraries should help us organizing and writing our code and deliverables, but not overtaking our thinking and tooling. It is not reasonable that we deliver whole applications to clients browsers, when the contents never or only every view months change. We should instead build more meaningful smaller applications. We even need to render server side, using JavaScript.
A quick excursion on what Web Components are
Using Web components would allow us to get back to standards, using browser supported simple tooling.
So why should you consider Web components as complement for frameworks and libraries?
Web components are the wrapper name for a set of techniques that create browser rendered interfaces. They are created through custom elements, shadow DOM, HTML templates and HTML modules. The latter is yet not widely adopted by browsers.
Custom Element
Setup a JavaScript file that contains the code for your custom element.
With your custom element you can add coloured text in the context of other text paragraphs. You can capsule your styles that only belonging to the needed node.
Stay DRY. Use HTML templates. Look at the the above example. If you want to render more paragraphs, you can repeat your <p> or just use a <template>. It is obvious what is wet and what is dry.
You can use them together with custom elements and shadow root, or alone.
Take also into account that all is maintained in a component library. Handled in a DSM provided by InVision, Figma, or Design Kits like Sketch. We need to ensure to reuse our code and Styles. Design Tokens help here. Amazon has Style Dictionary, but there are others. And ideally, have a direct connect to your repository. (More would be subject of a full own post)
But my client has IE11 as standard browser!
Ask them why! Seriously!
If they still insist, and maybe even have a dated soon to be replaced Edge: there are Polyfills available, they render the components as HTML for you.
Any other input?
More and more Frameworks and libraries arise that help generating your applications with Web components. They offer build in test ability, design libraries, pattern libraries and more. There are well established ones like Polymer or Stencil. You can find more on the web component page list. So if you do not want to do it manually. Use provided tools.
What to do
There is no golden hammer that makes all your problems a nail. But you should consider re-usability, need of the current implementation, and how long it will exists. Then it can help you making a decision.
Static rendering for interims campaign pages, knowledge bases, and so on can improve SEO, size, and customer experience. Full blown SPA with a checkout or profile management, and a healthy mixture for catalogue can do their part on this.
But the base of all should be a Web component. Just do it.
Ha, das hat gedauert und der Mitarbeiter an der Hotline meines „Platinum Supports“ wusste es auch nicht.
Wenn ihr bei 1und1 ein Paket mit SSH Zugang und Cronjobs habt und diese (wie ich) auch ordentlich nutzt, dann muss man immer aufpassen, dass diese auch durch die letzte aktuelle PHP Version angetrieben werden.
In den Cronjob FAQ bei 1und1 wird da nicht sehr ausführlich darauf eingegangen, dort wird sogar noch PHP4 referenziert. Daher hier ein kleiner Tipp:
Soll der Cron nicht unter PHP 5.2 laufen, dann müsst ihr im Pfad wie folgt zur PHP Version diese angeben – also z.B. für PHP 5.4 /usr/local/bin/php5.4 dieser wird also einmal am Tag um 00:01 ausgeführt:
Wenn man ein Webinterface zum Registrieren von Nutzern baut, ist es immer sehr schwer den Nutzer zu motivieren ein langes Passwort einzugeben. Die Nutzer ignorieren normalerweise was man unter die Felder schreibt oder in irgendwelche kontextuelle Hilfen. Erst nach dem Absenden kommt dann die Fehlermeldung dass das Passwort zu kurz war. Da hilft das Plug-in Nacked Password. So lange der Nutzer tippt zieht die Dame Kleidungsstücke aus. Da man die Bilder selbst einstellen kann, sogar jugendfrei. Man kann es beim Einbau auch modifizieren. Ich finde toll.
Sehr schöne nützliche Seite zu Kompatibilität von aktuellen und früheren Browsern, Hilfe und Unterstützung beim Integrieren von Funktionalität und auch einfach Weglassen von kleineren Funktionen in älteren Browsern. Wer sich mit dem Thema beschäftigt wird Spaß dran haben.
Ich habe schon öfter mal über HTML Mails geschrieben, und dabei auf die Risiken hingewiesen. Wenn jetzt noch ein großer Softwareproduzent und Fast-Monopolist sein proprietäres System einsetzt um E-Mails zu generieren, dann kann das nur schief gehen. Kämpft dafür, dass es repariert wird. Igitt!
