DEV Community: Daniel Ley

The end of the mono channel — the web has two faces now

Daniel Ley — Sat, 08 Nov 2025 23:00:00 +0000

But do websites need to be re-thought from now on?

Search engines read differently.
And soon they won’t read at all.

What used to be the crawler is now the Large Language Model (LLM). It no longer reads pages, but structures data, understands contexts, and cites brands that communicate semantically clearly.

This changes everything.

Not just how content is written, but how websites are built, structured, and delivered.

Welcome to the age of Generative Engine Optimization (GEO) and with it, the era of MCP readiness.

The end of the mono-channel web?

For decades, websites have served one main audience: people. Yes, there were always robots and crawlers in the background — but they weren’t the focus. Users visited sites through browsers, clicked through menus, and consumed content visually.

That era is ending.

Today, there are two equally important audiences:

Humans, who interact through visual interfaces
Machines, that process content through APIs, schemas, and language models

The web is splitting into two parallel realms:

The Human Web — everything users see, click, and experience
The Machine Web — everything machines can understand, connect, and reuse

Brands that continue to design only for the first will lose relevance in the second — and, ultimately, fade from the conversation altogether.

But beware: it’s not that simple. The website isn’t dead — it remains a vital touchpoint. It’s just one channel among many in an increasingly multi-layered web.

GEO — Optimization for Machines

Generative Engine Optimization (GEO) is about structuring content so it’s not just readable — it’s interpretable.

Machines don’t perceive “layouts” or emotions. They recognize patterns, relationships, and semantic depth. To communicate effectively with them, brands must embrace three core principles:

Tokens over words — Large Language Models translate language into numerical patterns. Only well-structured text is truly understood.
Semantics over style — Clean HTML hierarchies, consistent heading structures, and properly modeled data are non-negotiable.
Citability over ranking — In the world of AI, visibility isn’t about page one anymore; it’s about being recognized — and cited — as a trusted source.

GEO is no longer SEO with an AI twist. It’s the foundation that determines whether your brand still appears at all when machines start to synthesize content.

MCP-Readiness — The Communication Layer for Machines

While the frontend remains the space where people interact, a second, parallel layer is emerging — one built not for users, but for machines. This is where a Model Context Protocol (MCP) comes into play: a structural interface through which machines can communicate directly with brands and organizations — not visually, but semantically.

What MCP Does

Delivers content via structured APIs, JSON, and semantic models
Establishes a standardized communication layer between content systems and AI systems
Ensures that brand messages remain understandable, even without a visual interface

In essence, MCP-readiness is becoming a new technical and strategic discipline. Alongside the traditional website, brands must begin publishing content that is AI-compatible and machine-readable.

MCP-Readiness Is Still in Its Infancy

We’re still at the early stages of this shift. Most existing MCPs are experimental prototypes — research initiatives, proofs of concept, or early integrations. There are few real-world use cases, and no shared standards yet.

There are no fixed protocols, no common models, and no established semantics for how machine-consumable content should be structured or interpreted.

Still, the direction is clear: Brands that structure their systems modularly, semantically, and flexibly today are building the foundation to adapt quickly when these standards do emerge.

That’s why MCP-readiness is less a technology than a mindset — a strategic way of preparing for the next evolution of the web.

What Might This Look Like in Practice?

The following examples illustrate how MCPs could already be applied — even if only conceptually for now. Because MCPs rarely exist today as clearly defined products or platforms, these examples serve to clarify the underlying idea:

It’s about structuring content and services so they’re understandable, accessible, and reusable — not only for humans, but also for machines.

The goal, therefore, is not to build your own “MCP” right away,
but to prepare your systems and content so that this step becomes technically feasible and strategically meaningful in the near future.

Three Illustrative Examples of MCPs

1. MCP for Product Data

Example: A tool manufacturer provides its product information — such as dimensions, materials, and certifications — through an API.
This enables AI systems, procurement platforms, and B2B search engines to automatically analyze and interpret the data.

What happens:

The webshop remains the channel for humans
The API becomes the MCP channel for machines
AI models and marketplaces can access and process the data directly

Core idea: Structured product data becomes the semantic interface between brand and machine.

2. MCP for Complex Services

Example: An energy provider offers a fiber-optic availability check. In addition to the website where users can manually enter their address, the same service is exposed via a structured MCP interface.

This allows a voice assistant, partner portal, or AI application to check availability directly — without ever visiting the website.

What happens:

The website remains the channel for humans
The MCP provides the same service as an API
Machines — assistants, chatbots, or LLMs — can access the service autonomously

Core idea: Complex services become machine-readable, making them easily integrable into other systems or AI-driven assistants.

3. Corporate Data Hub

Example: A company consolidates its CMS, DAM, PIM, and CRM data into a single semantic API layer. This layer becomes the MCP interface for both internal and external AI systems.

What happens:

All data is maintained in one central source
Machines access it through a standardized interface
AI assistants, supplier portals, and research platforms all rely on the same dataset

Core idea: The MCP acts as the company’s central, machine-readable source of truth — a unified interface for AIs, APIs, and autonomous agents.

From Hard-Coded Content to Building Adaptive Experiences with AI

Marcelo Lewin describes a vivid example in his English-language article From Hard-Coded Content to Building Adaptive Experiences with AI .

He shows how a single CMS entry can contain two levels in the future:
a deterministic one for fixed content and a non-deterministic one for contextual instructions to AI systems.

In the example on the topic of “Setting up a smart thermostat”, the instruction text for humans is supplemented with additional, naturally worded notes that a LLM can use to adapt the content individually, for example according to device, location or user behavior.

This dual-layer logic illustrates where MCP-readiness leads: content is not only published, but also described in a machine-understandable way so that it can be reused in a context-aware manner.

The Frontend Remains — but as One of Several Channels

The frontend will remain the most visible channel for now — the familiar interface between brand and user. But from a technical perspective, it’s already just one of several output channels drawing from the same structured content.

Instead of viewing the web as two distinct layers — a graphical interface for humans and a machine layer for systems — we now design from a shared structural core. This core semantically defines content and components, independent of where or how they’re displayed.

The Paradigm Shift

The origin of a website is no longer the frontend itself, but the structured representation of its content — the layer that both humans and machines can interpret.

From this single core, every channel can be derived:

the visual frontend for human users
a potential MCP layer for machine interfaces
and other contextual outputs such as chatbots, voice assistants, documentation, or print.

This redefines frontend design. It’s no longer about building isolated surfaces, but about translating a semantic foundation into an experience.

Consistency no longer comes from synchronizing multiple systems — it emerges naturally from a shared structural source.

From Structural Core to Finished Page — A Prototype

Our prototype brings this concept to life. It uses a Large Language Model (LLM) to generate an entire page layout directly from the content stored in the CMS — not by relying on static templates, but by understanding the structural descriptions of each component.

Every component within the CMS is defined through a JSON schema. This means the model knows which data fields exist, how they relate to one another, and in which contexts a component should be used.

The LLM leverages this structure to:

select the right modules,
assemble content contextually,
and generate a complete page draft — which is then written back into the CMS for editors to review and refine.

The result is a page that:

is built from semantic structure,
renders visually consistent in the frontend,
and could, in theory, be delivered through any other channel as well.

In this model, the structural core becomes the single source of truth. The frontend and any future MCP or machine channels are simply different representations of that same foundation.

🎥 Video: Our prototype in action on YouTube

Headless as the Key — Why Structure Connects Everything

For a multi-channel model to work, a CMS must treat content not just as something visual — but as something structural.

This is where systems like Storyblok come into play. As a headless CMS, it completely separates content management from presentation and delivers content in a modular, component-based form.

This separation creates the foundation for serving different output channels — today the frontend, tomorrow potentially an MCP layer. Such a channel isn’t automatically provided by the CMS; it must be consciously designed. It’s not a visual output — it’s a semantic channel, built for machines, not humans.

Right now, this layer can’t truly be visualized — because its output will be interpreted and personalized dynamically by AI systems.

However, organizations that already structure their content stacks around the three GEO principles — tokens over words, semantics over style, and citability over ranking — are already well prepared to keep pace with what’s coming.

Our Frontend Package plays a crucial role in this. It was designed from the ground up with a structural mindset — each component is explicitly defined, both in content and in code. This ensures that CMS and frontend already speak the same language, forming a solid foundation on which future machine-readable channels can easily be built.

The Result

Content can be distributed consistently and structurally across multiple channels.
New layouts or landing pages can be assembled quickly and modularly.
Systems accessing semantic data — whether AI models or future MCPs — encounter clearly defined components.

Headless is therefore more than an architectural choice. It’s the prerequisite for a web that serves humans and machines alike from one shared structural core.

Structure becomes the common currency.
Headless delivers it, the frontend expresses it,
and AI systems understand it.

Conclusion: The Future of the Web Is Dual-Channel

The web is evolving into two interconnected worlds:

The Human Web — visual, emotional, and interactive experiences for people
The Machine Web — structured, semantic, and citable data for AI systems

Brands that invest today in GEO, Headless, and MCP-readiness secure their presence in both. They will be seen, understood, and quoted — by humans and machines alike.

Brand communication doesn’t end at the screen.
It begins where machines start to read.

What Companies Should Do Now

Structure content consistently and semantically
Prioritize headless architectures
Design frontends and content models as one cohesive system

Because MCP-readiness isn’t a project milestone — it’s a mindset for how digital brands will be built in the future.

The question is no longer whether this shift will happen — but how fast we’ll adapt to it. How is your organization preparing for a world where machines are part of your audience?

Your transition to a headless CMS made easy!

Daniel Ley — Fri, 24 Jan 2025 09:51:28 +0000

_#tldr: Our Website Accelerator is a powerful toolset designed to simplify the transition to headless architectures, offering rapid deployment, scalability, and sustainability. By integrating with platforms like Storyblok CMS and Netlify Create, it enables businesses to efficiently test new technologies and enhance development processes. This accelerator supports valuable usage scenarios, from enterprise-level tech trials to agency workflow optimization and SME website relaunches.

Read how it empowers organizations to modernize their digital strategies with reduced risk, cost, and time to value._

How a Website Accelerator drives your success

In today’s rapidly changing digital landscape, businesses are under pressure to deliver seamless and engaging experiences across multiple platforms. Many companies are eager to transition to modern headless tech stacks, drawn by the promise of increased flexibility and scalability. However, the perceived high investment and risk, especially concerning their main revenue-driving services, often hold them back. This is where a Website Accelerator comes into play. Designed to integrate seamlessly with MACH (Microservices, API-first, Cloud-native, and Headless) architectures, this accelerator offers a pathway to innovation without the typical hurdles. In this blog post, we’ll explore how our Website Accelerator can mitigate risks, reduce costs, and provide the agility needed to excel in a composable ecosystem.

Understanding the Composable Ecosystem

To fully appreciate the benefits of a Website Accelerator, it’s essential to understand the concept of a composable ecosystem. At its core, a composable ecosystem is built on the principles of flexibility and modularity, allowing businesses to select and integrate best-of-breed solutions tailored to their specific needs. This approach is embodied by MACH architecture, which stands for Microservices, API-first, Cloud-native, and Headless.

However, transitioning to such a modern architecture is not without its challenges. Organizations often grapple with several considerations:

Complexity of Integration: Moving from a monolithic system to a composable architecture involves integrating multiple services and platforms, which can be complex and time-consuming.
Skill Gaps: The shift to a MACH-based ecosystem requires new skills and expertise, which may necessitate additional training or hiring, posing a challenge for teams accustomed to traditional systems.
Data Management: Ensuring seamless data flow and consistency across various microservices and APIs can be daunting, requiring robust data management strategies.
Cost and Resource Allocation: While the long-term benefits are significant, the initial investment in new technologies and the reallocation of resources can be a barrier for some organizations.
Change Management: Adapting to a new way of working involves cultural and operational changes, which can be met with resistance within the organization.

Despite these challenges, the composable ecosystem offers unparalleled opportunities for innovation and growth. Our Website Accelerator is designed to mitigate these risks, providing a streamlined path to modernization by leveraging the power of MACH architecture. It empowers businesses to innovate and grow without the constraints of traditional monolithic systems, ensuring they remain competitive in todays evolving digital landscape.

The Role of Design Systems and Composable Frontends in Modern Digital Ecosystems

In the journey towards a modern, composable ecosystem, the concept of a composable frontend emerges as a game-changer. While design systems are crucial for maintaining consistency and efficiency across digital platforms, as detailed in our post about Design Systems for MACH architectures, the composable frontend takes this a step further by enabling unparalleled flexibility and customization.

A composable frontend allows businesses to build digital experiences by assembling pre-defined components and services, much like building blocks. However, integrating frontends or existing UI libraries into headless stacks often presents technical challenges. Many are not inherently designed for seamless integration, requiring significant manual effort to adapt them to a headless architecture.

Despite these challenges, a composable frontend offers several advantages:

Tailored User Experiences: By leveraging a library of reusable components, businesses can create highly personalized and dynamic user interfaces that cater to specific audience needs.
Rapid Iteration and Deployment: The modular nature of a composable frontend enables quick updates and iterations, allowing brands to respond swiftly to market changes and user feedback.
Seamless Integration: Designed to work harmoniously with other elements of the MACH architecture, a composable frontend ensures smooth integration with backend services and third-party tools, overcoming the typical hurdles of manual adaptation.

A composable frontend is an integral part of the Website Accelerator. It empowers businesses to deliver innovative and engaging digital experiences with agility and precision, ensuring they remain competitive in an ever-evolving digital landscape.

What is a Website Accelerator?

Our Website Accelerator is a ready-made package designed to kickstart your creation and deployment of marketing or content heavy websites, enabling businesses to swiftly adapt to evolving market demands.

The accelerator provides essential building blocks for developing modern headless marketing and e-commerce sites. It enables faster project delivery compared to traditional methods. Designed for customization, it offers a solid foundation for your projects, with full documentation and regular updates.

Hence, it acts as a catalyst for digital transformation, providing a structured approach to building and launching websites in weeks and not months.

At its core, the accelerator offers a comprehensive suite of tools and resources that simplify the complexities of modern web development. By leveraging pre-built templates and components, businesses can rapidly prototype and deploy websites, facilitating quick experimentation and iteration. This approach not only reduces time-to-market but also allows for the quick validation of new ideas, ensuring that businesses remain agile and responsive.

Furthermore, the Website Accelerator is engineered for automatic integration with Storyblok CMS or Netlify Create and can easily be adapted to more third-party tools. Its design prioritizes scalability and performance, ensuring that businesses can expand their digital offerings without compromising on user experience.

All integrated end-to-end and ready to be shipped within minutes.

Key Benefits of the Marketing Website Accelerator

Rapid Deployment with Storyblok or Netlify Create Integration

Our accelerator is deeply integrated with Storyblok allowing for seamless content management and delivery. This integration enables content teams to work independently from developers, accelerating the content update process and reducing time-to-market.

Customizable and Scalable Architecture

The accelerator is designed to be highly customizable, allowing businesses to tailor the solution to their specific needs. Its scalable architecture supports growth, enabling you to expand your digital offerings without extensive rework or disruption.

Sustainability and long-term Viability

Beyond just prototypes or MVPs, the accelerator provides a sustainable system designed for long-term use. It is engineered to scale in every aspect, ensuring your digital infrastructure can support ongoing growth and innovation.

Cost-Effective Development

By reducing development time and resource allocation, the accelerator optimizes costs, offering a higher return on investment for digital initiatives. This efficiency enables businesses to allocate resources more strategically, focusing on innovation and growth.

Enhanced Performance and UX

The accelerator is optimized for performance, ensuring fast loading times and a smooth user experience. This focus on performance is crucial for maintaining user engagement and satisfaction, which are key to driving conversions and achieving business goals.

Technical Insights

The Website Accelerator is powered by a sophisticated toolset, designed to create efficient, scalable, and customizable digital experiences. A central feature of this accelerator is the emphasis on well-defined component APIs, which serve as the official contract between the frontend layer (e.g. the design system) and the backend architecture, such as headless CMS, DXP, or DXO. These structured definitions provide stability and enable the development of automations and integrations, enhancing efficiency without compromising development speed.

At the heart of this toolset is kickstartDS, our open-source starter kit for Design Systems. It empowers businesses to create their own custom Design System while benefiting from best practices and an existing component library. By utilizing JSON Schema to document component APIs, kickstartDS facilitates seamless integration with other systems through automated conversion tooling.

The flexibility of kickstartDS allows businesses to choose their path to enable composition, whether by building a custom design system atop kickstartDS, integrating an existing one, or using one of our ready-to-go CMS starters. This adaptability ensures that the accelerator can meet diverse project requirements.

Our approach supports a gradual transition to modern digital stacks. By starting with a small, relevant pilot project, businesses can evaluate the success of the new system as a proof-of-concept. This incremental strategy allows for piece-by-piece transitions, aligning with natural relaunch cycles and fostering continuous learning and growth.

Real-World Scenarios and Applications

The Website Accelerator has proven its value across various real-world scenarios, demonstrating its versatility and effectiveness in addressing diverse business needs. Here are some examples of how it can be applied:

Testing new technologies in secondary markets

Large enterprises often face challenges when introducing new technologies in their primary markets due to high stakes and potential risks. The accelerator provides a low-investment, rapid deployment solution that allows these companies to test new tech in less critical markets. By creating a proof-of-concept that is both productive and scalable, businesses can evaluate the technology’s impact and sustainability. Successful implementations can then be adapted and rolled out to more important points of sale, ensuring a smooth transition and minimizing risk.

Digital agencies scaling development processes

For digital agencies, staying competitive means embracing modern headless technologies while managing costs. The Website Accelerator enables agencies to streamline their development processes, reducing time and resources required for each project. By cutting down on development costs and increasing efficiency, agencies can enhance their margins and offer more competitive pricing to clients. This scalability allows agencies to take on more projects and expand their service offerings without compromising quality.

Relaunches for Small to Medium Enterprises

SMEs often need to relaunch their websites to stay current, meet new accessibility regulations, or refresh their brand image. The accelerator provides a cost-effective and efficient solution for these businesses, enabling them to quickly update their digital presence. With customizable templates and components, SMEs can achieve a modern, compliant website that meets their specific needs. This approach not only enhances their online presence but also ensures they remain accessible and relevant to their audience.

Let’s wrap this up

Our Website Accelerator stands out as a vital tool for businesses looking to modernize their digital strategies. By leveraging a comprehensive toolset that includes kickstartDS and deep integrations with platforms like Storyblok and Netlify Create, the accelerator empowers organizations to rapidly deploy scalable, efficient, and sustainable digital solutions.

Whether it’s testing new technologies in secondary markets, enabling agencies to streamline their development processes, or supporting SMEs in their website relaunches, the accelerator offers a versatile and effective approach to overcoming the challenges of modern web development. Its focus on speed, scalability, and sustainability ensures that businesses can confidently navigate the complexities of today’s digital landscape.

Ready to Modernize Your Website?

We’re passionate about helping associations and corporate organizations bring their stories to life through innovative digital solutions. We’d love to learn about your unique needs and goals and explore how our Website Accelerator can support your digital transformation journey. Reach out to me and let’s have a chat to discover the possibilities. You find me on LinkedIn, our Discord, or on Mastodon.

Everything Meta! And everything matters.

Daniel Ley — Thu, 19 Jan 2023 12:18:23 +0000

#tldr: in this post Daniel explains why kickstartDS is a meta framework for Design System creation and how you can benefit from it when starting to develop a Design System.

When we made the decision to develop our pattern library into an Open Source tool, we thought about many different ways to describe what the core of it is, or at that time will become:

kickstartDS is a …

Comprehensive component and pattern library for Design System
Adaptable framework for digital Design Systems
UI framework for all your headless and legacy experiences
Low-code framework and starter kit for Design Systems
Design System Meta Framework

*All of the above is true! * When we were doing user research at that time, on a first glimpse, no one really understood what that means. Yes, our value proposition is really a tough take and in need of further explanation. That is also one reason while we came up with the rather descriptive claim “a starter kit for design systems”.

Nevertheless, whenever I meet a client to demonstrate kickstartDS, I still use the meta-description in addition, and outline: “kickstartDS it is a Design System starter, you can imagine it as a Meta Framework for Design Systems.”

If you are a developer, you are familiar working with frameworks of different kinds, and hence they can understand more easily why kickstartDS is a Meta Framework. Usually, they really like how we have created it and how easy it is to implement.

© Human Vectors by Vecteezy

Everything Meta

A meta system

is a system that is comprised of other, smaller systems that work together to achieve a common goal. One example of a meta system is the human body, which is made up of a number of smaller systems such as the circulatory system, the digestive system, and the nervous system, all of which work together to keep the body functioning properly. Another example of a meta system is a city, which is made up of a number of smaller systems such as the transportation system, the water supply system, and the sewage system, all of which work together to support the needs of the city’s residents.

A meta framework

is a framework that provides a structure or set of guidelines for organizing and developing other frameworks. The term “meta” in this context refers to the fact that the framework is concerned with the organization or structure of information, rather than the specific content of that information.

We will start by looking at the concept of a “meta framework” and how it can be used to analyze the structure and dynamics of a system. A meta framework is a tool to help understand how the components of a system interact and how they can be adjusted to improve the overall performance of the system. A meta framework consists of a set of rules or principles that are used to identify and measure the different components of a system and their interrelationships.

Example of a Meta Framework

GraphQL is an increasingly popular language for APIs. It’s also a good example of a software-oriented meta framework. It’s used to create and expose data to clients and is a powerful tool for creating a unified API layer. GraphQL allows developers to define their data schema and access rules in a single, unified layer which helps streamlining development, making code easier to integrate into existing systems and to maintain.

Transferring the idea onto Design Systems

A design system meta framework is a set of guidelines, principles and best practices that are used to create, maintain, and evolve a Design System. A Design System is a collection of standardized design elements, such as colors, typography, iconography, and components, that are used to create a consistent, high-quality user experience across multiple products and platforms.

In this sense, kickstartDS is a meta layer providing the framework for creating these design elements, using industry best practices.

The underlying concepts are based on state-of-the-art industry standards. We have taken design decisions to make it easier for you to get your Design System started quickly and without investing much energy and budget.

A tough take, it is

I can imagine Master Yoda saying this. Even within the Design System community, where you meet very knowledgeable people with broad experience and expertise in the field, explaining kickstartDS sometimes feels like talking to strangers. Maybe some of these people still do not believe that there could be something like a meta framework for Design System creation and hence just deny it already upon its idea – although everyone hates to recreate basic components over and over again – or it feels like we are too niche-y inside the already small niche of Design Systems.

Asking for feedback!

What is your understanding of kickstartDS? Do you think a meta framework is helpful to get things started and sorted out quickly or not? Please let me know either on Twitter, LinkedIn, our Discord, or on Mastodon.

Release Spotlight: Container Queries

Daniel Ley — Wed, 14 Dec 2022 06:10:00 +0000

#tldr: Container Queries are another new feature coming with the Open Source release of kickstartDS. It's a proposed feature for CSS that allows the styling of elements to be based on the size of the container in which they are placed, rather than the size of whole browser frame. This is important for Design Systems because it allows for more flexibility and modularity in the design of components.

Illustration showing the difference of Media Queries in comparison to Container Queries. Credits: Ahmad Shadeed

Container Queries are the perfect evolution

In the past everyone had to rely on Media Queries when adapting the design and layout of components, especially those displaying content. When thinking about Design Systems, everyone wants to have fully-fluid components, which automatically adapt to their surrounding layout or grid. CSS Container Queries finally take care of this long-lasting pain. Therefore we, very early on, decided to rely on the use of Container Queries, even though the support in browsers is still incomplete, as of today. We believe it won't take long until it will be fully supported natively, and until then we already smooth over the currently remaining gaps with really slim polyfills. We can also already see that it was the right decision, when thinking about a starter kit for Design Systems, in the first projects utilizing them. Lately more and more articles (like this good one) also surfaced, talking about Container Queries and their use for Design Systems.

What makes Container Queries so great?

With Container Queries frontend developers can create overarching grid layouts with components in them that automatically adjust to the size of the container they are placed in, rather than having to be restricted to (and by) Media Queries ... to apply styles based on the size of the entire viewport. This allows developers to create components, developed in isolation, that can adapt to different screen sizes and devices, making them more efficient and consistently useful. Ultimately this means that a component can be used in a greater variety of contexts. Which in turn makes it easier to create flexible, responsive designs that work and improve the user experience of a product, page or interface overall.

How we approach it in kickstartDS

Components in kickstartDS are distinct units of interface, that shouldn't make any assumptions about where they're used. They should just use up all the space given to them in a responsive and efficient way.

This makes it necessary to add dedicated layout functionality to your Design System, to help users to actually create pages and interfaces out of your offered components.

We offer the Section for this purpose, especially when constructing websites, because it has some really nice convenience features implemented to aid in that. It is comparable to an "invisible component", specialized for giving you control over the targeted layout of your page, and providing context to your components / content. You can control the Gutter and Mode. While Gutter controls the amount of spacing between components, Mode is a parameter to decide on the general layout of items inside a Section. Using Mode you can choose between different display modes for your components: evenly split in a grid-like style, what we call a tile layout, evenly stretched with the default mode or vertically stacked with the list mode. Take a look into our documentation to see some more examples.

For more general requirements, not covered by our Section, we recommend using Bedrock Layouts. It integrates nicely with kickstartDS way of thinking about token, have a look at our docs section about it to learn more about hooking those two up.

Container Queries are here to stay

We want to do everything to encourage people to create their own Design System. Our best practices and design decisions, of all different kinds, should hopefully help in simplifying the process and setup. It's why we also use semantic token as one core concept presented in last week's release spotlight. With Container Queries we now showcase the use and implementation of another future-proofing functionality with this, to get the perfect fit for your components, regardless of the layout they are placed into.

Let me quote Brad Frost's view on Layout & Grid in Design Systems before you hit our docs to check it out on your own

Design system developers create fully-fluid components and use container query syntax to manage each component's breakpoints.

Design system developers provide layout and grid components (outlined above) for common layout solutions.

Design system consumers do one of the following:\ a) Use design system-provided layout and grid components in their products\ b) Create product-specific custom layouts and grid solutions

Consumers drop design system components into ds-provided or custom layouts, and those components Just Work, irrespective of the layout they are placed into.

Try it now

I hope that sparked your curiosity, and just increases your desire to try it out on your own. The best place to start are our docs, which will get their own, final Release Note soon.

If you have any questions, just join our Discord community or drop us an email to hello@kickstartds.com

Release Spotlight: Semantic Token

Daniel Ley — Mon, 12 Dec 2022 13:07:57 +0000

#tldr: Design Token are all the rage these days. In almost every channel from the Design System space, you can feel a crispy white noise around the broad topic of Design Token. We also put in a lot of effort when refactoring our Token structure in kickstartDS for our latest release. It might look over-engineered on a first glimpse, but we understand ourselves as a meta framework for Design System creation and therefore want to provide you best practice defaults.

Branding, Design & Component Token

Token are the smallest building blocks of a Design System. Based on the values they store, they are usually used across multiple tools and platforms to ensure consistency and matching brand identity. kickstartDS differentiates between Branding, Design and Component Token. Whereas Design Token store values e.g. color, typography, spacing, animation, etc., Branding Token come in handy offering a structured approach towards applying your company’s brand identity or corporate design at one single spot with maximum efficiency. Component Token represent the properties and values that are contained in a component, e.g. controlling how its container, label text, icons, and states look.

{
  "ks": {
    "color": {
      "primary": {
        "base": {
          "value": {
            "r": 51,
            "g": 51,
            "b": 51,
            "a": 1
          },
          "attributes": {
            "category": "color"
          },
          "token": {
            "category": "Colors: Primary",
            "presenter": "Color"
          }
        }
      }
    }
  }
}

Since we are publicly open source now, the great thing is, that you can check out that structure on your own in our repo.

We fully rely on semantic token within kickstartDS

With this release we implemented semantic token, which is a rather modern concept that mainly involves naming tokens by their intended use. Some teams refer to these with names like alias tokens or purpose tokens, all describing basically the same concept of including intention in the token name, in comparison to just naming it by its current value (like “color-red”).

Example: $background-color-success vs $background-color-green

I don’t want to go into more detail in this post, as these concepts are already very much explored by well known people from the community 😉

For example Nathan Curtis article:
https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676

Other valuable reads are from Lukas Oppermann and Dannie Damato
https://uxdesign.cc/naming-design-tokens-9454818ed7cb
https://blog.damato.design/posts/tokens-as-intents/

Base scales vs Semantic Token

As described in the paragraph above semantic token are the concept we apply when building components, whereas base scales are another concept we use as the input for your semantic token. You choose your semantic token from a set of base values and scales, think of those as the painters palette, making sure there’s a lot of re-use (aliasing) in your Design Token. In turn enabling efficient, consistent changes to your semantic token. There are scales for different kinds of token, such as color or spacing for example. A base scale for these token is generated by default. You can edit the scales when applying to fully match your brand’s identity.

View our Token Figma file here

Structured token following Style Dictionary format

Taking the code perspective: token in kickstartDS are structured using JSON, following the Style Dictionary format. Style Dictionary is an Open Source tool developed by Amazon that allows you to define styles once, in a way for any platform or language to consume.

With Style Dictionary you can manage Design Token and organize them into collections of JSON files. In addition, you can export those organized tokens to many platforms, tools or integrations by using its so-called transform groups to generate technology-specific formats or deliverables.

Side note: we are eagerly awaiting the release of the W3C Design Token Group format, with the intention with following it whenever it is finally decided.

Using such an established approach with Style Dictionary in the meantime allows to benefit from its general community adoption, a lot of extensions, plugins and automation already being written for you.

Themes for Bootstrap, MaterialUI, TailwindCSS, Fiori and others

Facilitating Style Dictionary, we can use its transform groups to derive and generate themes for 3rd party component libraries such as Bootstrap, MUI or even SAP Fiori. We are working on ready-to-use examples to help you distribute your Design Token and assets into these environments. We’ve started with early tests on this, but the goal is to provide ready-made configurations. Giving you a great starting point by having best practice connections between themed solutions like MUI and your Design Token.

Style native mobile Apps through token

As you might have noticed already most of that transformation-stuff is made possible by Style Dictionary. Hence, similar configurations can be set up to apply token for their usage in native apps in Android or iOS.

CSS Custom Property transform group

Custom properties are the bedrock of our component implementation when it comes to encoding design and layout. We transform your Style Dictionary into a set of those CSS Custom Properties, which are then layered onto components in the form of Component Token. So a “Button” may use one semantic color token for its label text by default (–ks-text-color-interface-interactive), but in a different variant an “AlertButton” might be specifically layered with a semantic color token signifying a problem (one based on –ks-color-negative), while still re-using the rest of the default “Button” token mapping.

Synchronization of Design Token from Figma

Since Figma still does not offer a full, native integration or treatment of Design Token, we are working on a synchronization from Figma to JSON. You might be familiar with the Figma Token plugin or tools like Specify for this dynamic exchange between design and code. We are currently working on a solution, as a perfect addition and fit for the Token structure in kickstartDS, to also make this part of the design process efficient and easy like squeezing a lemon. Unlike hassling around with configurations to be adjusted, or concepts not quite fitting your intention, this will be opinionated and tailor-made to the way we’ve approached token in kickstartDS.

Multibrand-theming and layering with kickstartDS

You can declare Design Token for each of your brands/themes within a layered instance of kickstartDS. You or your DesignOps team can specify which component for which brand should be based on the core components, or instead be fully customized for that specific use case… keeping it from polluting the (shared) core.

And if it’s just another layer of paint for one of your sub-brands, you can even get away with just defining an additional token set. No further coding required!

Make it yours!

In reference to what I wrote in the intro of this post, kickstartDS is meant to be a meta framework for Design System creation.

Start by applying your branding and corporate design to kickstartDS in roughly two steps:

Use a reduced set of Branding Token to generate your initial Design Token set
Fine tune the resulting Design Token set to closely fit your corporate identity

Once your Design Token are generated, the Design System will already have the broad look and feel of the targeted Corporate Design. However, you probably still need to tweak some little details to make it match up perfectly with your brand requirements.

More than just adapting token, you should also adapt our base components and start making them your own. By default our components come with a huge set of properties. You choose which of these props you really need, how you want to name them, and thus how you want to synthesize it towards your own requirements. You can also create wholly new components based only on following kickstartDS’ systematic approach, without actually using base components.

Ultimately, adapt and make the default process yours

We propagate code first, when talking about the source of truth of Design Systems. Users interact with coded components, not with the (Figma, Adobe XD or Sketch) design files which are often the starting point for exploration of the component use cases or even full-page layouts to be adopted by the developers.

Depending on which handover process you have implemented and how deeply designers interact with developers, handling Design Token through Style Dictionary generates high value for both parties. It gives designers the power to keep owning their design decisions, as developers usually, for example, do not like to decide which color to use (one more reason to rely on semantic tokens). Those decisions then will be transformed into JSON, which makes those files the ultimate source of truth, working in both directions.

Try it now

I hope that we could tickle your curiosity and light up the desire to try it out on your own. The best place to start are our docs, which might get their own Release Spotlight soon.

https://www.kickstartds.com/docs/guides/create/

If you have any questions, just join our Discord community or drop us an email to hello@kickstartds.com