Schlagwort: CSS

  • Präsentationen und Vorträge

    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.

    Ich lade es dann hier hoch: (es wird mehr)

    https://present.polente.de/

  • A Continuous Experience Pipeline…

    …evolved

    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.

    Flow Chart showing Brand Design, UI Components in Design and UI Components in Code in the middle and Design of touch-points on the right

    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 and Figma Token Studio Relation
    • Figma Design System in design
    • Token Studio  A design token is a design decision

    Tools in design

    Tools in code

    Webcomponents, Bitbucket, NPM and Storybook to Docusaurus Relations
    • 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.

    Full flow of the described tools above with some Gatekeepers in between

    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.

    Pleased Developers: Comprehensive documentation and efficient code ensure rapid, high-quality results.

    10. Gaining Insights & Knowledge

    We learned a lot

    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.

    The people behind: A dedicated team of Developers and Designers lead by Holger Hellinger (Director Technology) and Michael Brandt (Design Lead) at Publicis Sapient, Cologne.

  • Aufbau eines robusten Design System Managers: Eine Reise

    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.

  • How does a Headless Content Management System (CMS) work

    History of Content Management Systems

    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 TWIGHTL, 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. 

    From Static Pages to Headless CMS, From HTML to Modern Layout techniques
    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.

    Showing a Headless flow, with an API layer and a Monolithic setup where Rendering, Data and Authoring is in one layer
    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

    Flow: Client, GraphQL Server, Data
    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
    • Personalization of Content
    • If you have static side generators in place (Gatsby, Jekyll, Middleman, Next, Nuxt, or Eleventy)
    • Mobile Apps or IoT
    • If you need to enhance your E-Commerce data.
    MonolithicHeadless
    Simplicityoo
    Localization++
    Plug-in Uncertainty+
    Cross-Platform+
    Technology Freedom+
    Developer first+
    Comparison of Advantages

    Drawbacks and Challenges 

    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. 

  • Es gibt keinen Grund mehr CSS Grid nicht zu verwenden

    Ich kann mich nur wiederholen. Flex für spezielle kleine Anpassungen. Grid als Gerüst für deine Seiten. Keine Ausreden mehr, wenn man selbst Einfluss auf das Gerüst und die Basis der Webseiten hat.  (und ja, WordPress benutzt auch nicht das letzte Layout das möglich wäre)  https://css-tricks.com/snippets/css/complete-guide-grid/

  • Wann kann ich was verwenden…

    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.

  • eBay springt auf den Web 2.0 Zug auf…

    Juhu, endlich auch eBay. Wieso nur? ich weiß es nicht. Auf jeden Fall sieht eBay seit heute einfach schrecklich aus. „Runde Ecken“ wohin man schaut, JavaScript-abhängige Features, die bei mir jetzt zu einem Klick mehr führen, wenn ich mal wieder JavaScript deaktiviert habe, usw. Was die Umgestalter der Seite aber immer noch nicht geschafft haben, ist es der Seite eine definierte Hintergrundfarbe zu geben. Bei mir liegt alles auf einem herrlichen grau.

    Ich hatte die Seite ein paar Minuten im im Firefox offen und plötzlich begann dieser wild zu reloaden, ich habe noch nicht erkannt an was es lag. Witzig auch der Test mittels eines „Meta Refreshs“ im noscript Tag ob jemand JavaScript aus hat. (Weitergeleitet wird auf: http://www.ebay.de/?_js=OFF) Da mein Firefox keine Meta Refreshs ausführt, völlig für die Katz.

  • Mini CSS Framework

    Ich frage mich ob es eine sinnvolle Verwendung eines CSS Frameworks geben könnte, oder ob es überhaupt angebracht wäre so etwas aufzusetzen. Mir kam die Idee bei der Diskussion um JavaScript Frameworks wie Prototype, mootools oder deren Erweiterungen wie scriptaculous. Irgendwie setzt man bei jedem Web das neu entsteht, vieles immer wieder um, und schreibt oder kopiert damit vieles neu, das eigentlich wieder verwendet werden könnte. Yaml bietet hierfür einen ganz guten Ansatz. Leider ist für meine Ansprüche die Vielfalt der vorgegebenen Stylesheets und die Größe mittlerweile wieder nicht mehr annehmbar. Der unbedarfte Nutzer wird sicherlich „vorsichtshalber“ erst alles laden. Was nicht nötig ist. Meine Styles sind daher nichts neues, sondern eben nur ein Neubeginn für mich. (mehr …)

  • Web 2.0 und JavaScript ohne Fallback

    Es ist immer wieder schade, dass man Webseiten ohne Fallbacklösung sehen muss. JavaScript wird vorraus gesetzt. Gerade große Firmen sollten und können es sich nicht leisten. Im derzeitigen Hype (oder eben auch Wunsch) nach usergenerierten Inhalten und Anwendungen, die sich wie am Rechner zu Hause bedienen lassen, wird aber immer öfter vergessen, dass diese dann nicht mehr bedienbar sind, wenn man JavaScript nicht unobtrusiv einsetzt. (mehr …)

  • 500 Jobs bei MLP

    Seit Mittwoch können Sie sich als MLP Berater bewerben. Eine Job Inititative von MLP. Wir haben die Seite in .NET 2.0 und validem HTML umgesetzt. Die Startseite ist mit einer Animation in unobtrusiven JavaScript aufgesetzt und kann daher auch mittels der CSS Mousevover ohne aktiviertes JS bedient werden. Die Startseite zeigt in Abhängigkeit der Bewerbungen die offenen Stellen exemplarisch an. Sind Sie bereit für eine neue Herausforderung bei MLP? Dann bewerben Sie sich. (mehr …)

  • Alt-Attribut vs title-Attribut

    Der Alt-Text ist eine Alternative, kein Tooltip!

    Es erscheint immer wieder ein Problem zu sein und bei Entwicklern von Webseiten, sowie Browserherstellern für Verwirrung zu sorgen. Das alt-Attribut stellt alternative Texte für Bilder und nicht textlich dargestellte Inhalte dar. (mehr …)