DEV Community: kickstartDS

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.

Unlocking the frontend – a call for standardizing component APIs pt.2

Jonas Ulrich — Tue, 05 Mar 2024 15:56:55 +0000

#tldr Why Design Systems, and a more structured approach to frontend engineering in general, might be key to a more shared frontend ecosystem. And how this thought might hit an interesting inflection point rather sooner than later, with the advent of production-ready Web Components as a shared technical standard and foundation for interoperability.

So what are the missing pieces? And how could our latest release, and the accompanying schema tooling open sourced with it, play into this? And what would a blog post be today, without tying it into AI? Buckle in: this will be a long one!

Status Quo

Sometimes, at least to me, the current Status Quo in the frontend world feels more fragmented then ever before. Between Tailwind UI and the likes, CSS-in-JS, and a multitude of (differently) opinionated frameworks fighting for our attention “for all the right reasons”.

Meanwhile, web standards seem to rapidly catch up… with native nesting and @layer in CSS and, to name just two great features we’ve won on that front lately, web components getting Declarative Shadow Dom, the Design Token standard rapidly approaching, React finally merging web component compatibility for React 19 it seems, the list goes on.

Nonetheless, we’re still mostly redoing a lot of work, especially those trying to craft bespoke frontend solutions… and not just hitching their wagon to something like Material UI / MUI, and calling it a day.

Does this have to be so fragmented? Don’t we all, in the end, “just” build interfaces based on HTML, CSS and JavaScript… that happen to mostly run in the browser?

via [GIPHY](https://giphy.com/gifs/q9AgIEA8kKWWI2paHT)

Finding universality

Thinking about it… what actually is universal in components? I’d say: They all have an API. Call it Component Props like React, Vue and Svelte do, or Property Binding in Angular, Variables in Figma, or even the structure of Frontmatter typically found in an 11ty code base.

Currently definition of those structures is dominated by either a backend system / API, leaking a backend view of the world into the implementation, or Figma / Sketch / etc design prototypes which attempt to model them, which can skew the focus into a too visually reductionist direction. Either way, it gets really hard to reuse stuff, because you have to re-adapt your code every time a change occurs. You’re “downstream” from the decisions being made and their resulting changes affecting you; and now imagine how people working with the resulting interfaces on a daily basis must feel 😱.

Why else might this be a problem? It shouldn’t be (solely) developers or designers who own this type of API. And this is where we think Design Systems enter the picture, as they establish a collaborative process of component API creation. Nathan Curtis describes this quite nicely:

A design system aspires to achieve a shared vocabulary between designers and developers. As we build visual style and UI components, we make many decisions about how a feature is composed and configured.

Nathan Curtis

I’d add content editors and select stakeholders to that process. Having enough context matters, especially when creating a Design System. I really liked Eduardo da Silvas article on “Sociotechnical architecture”, and I think it very much applies to the introduction of a Design System into an organization!

When also taking into account the structure of most every headless CMS out there, many of those having themselves adopted a component based approach for their content modeling, you start to notice that there already seems to be something like a standard, and shared way, to express this: JSON!

So why do we still have to chase the ball when creating frontend code? Why reinvent the wheel for every project… painstakingly redefining everything, remapping it to CMS and backend systems, and so forth. Can’t we take more control of this process somehow? And wouldn’t it, as a concern, be better handled in something like a Design System anyways?

So how could such a standard look like?

Enter the world of JSON Schema

As luck would have it, there’s JSON Schema… let me quote their central mission statement:

Build more. Break less. Empower others. JSON Schema enables the confident and reliable use of the JSON data format.

https://json-schema.org/

Already embedded deep into quite a few development workflows (either through the Open API standard, where it is used for model definitions, or something like Postman to build APIs collaboratively) this immediately enables safer, greater and more meaningful interactions between frontend engineers, backend engineers and those working on APIs / microservices. It’s also already in use in some Design System tooling (like Knapsack), or behind the scenes in headless CMS systems.

For a more in-depth intro, give Ben a listen on his great video here:

Again: I’m pretty convinced that this layer could be universal!

If, additionally, you decouple the Design System as a rule-based framework for design, component, UI and product creation from specific implementation choices taken for components, or a component library as part of your Design System, the value gets more obvious. You start differentiating between the structure and function of a component, and its implementation. Or even multiple implementations when supporting different frontend technologies simultaneously. A mix of components from different frameworks, or different component libraries inside the same framework, starts to become an implementation detail, while everything stays unified under the umbrella of your Design System.

An idea brewing for quite a while already

As our roots stem from 20 years of agency business, we’ve early on started trying to find ways to reuse frontend code, and better decouple frontend from backend engineers in the process. Back then, for us, this meant integration of independently developed frontend code into (mostly) PHP based backend systems like TYPO3 and WordPress (being an “integrator” was an actual job profile in places, with certifications and everything).

Through integrated templating engines (like Fluid for TYPO3) we started exploring better abstractions for reusable frontend code, and ways that could help map it to a backend system.

While this helped ease integration work, in parallel to that we also started exploring more systematic approaches on the frontend side itself. With the advent of Brad Frost Atomic Design, and tools like Pattern Lab, we started using a more component-centric approach. This included colocating all styling (CSS), behavior (JavaScript) and semantic structure (HTML) for a component, and way better encapsulation as a whole. And most influential for us, it turns out, it meant documenting all our expected variants of a component as JSON data:
https://patternlab.io/docs/overview-of-data/

This left us with a pretty extensive, reusable frontend component library, as most of the projects at the time had pretty similar base requirements, especially when it comes to creating content-driven websites (I’d argue even more so today).

When finally deciding to end our journey as an agency in 2021, to instead transform to an Open Source, product-led business with kickstartDS, this meant we already had a great starting point and a heap of experience with creating complex, modular and reusable frontend setups (we’ve also built some early Design Systems for German DAX listed enterprises around 2013-2016, for good measure).

The first thing we did was a complete rewrite of our code base, with everything we had learnt so far in mind. We ditched Pattern Lab for Storybook, replaced Handlebars with React (but only for its templating capabilities in JSX, everything still usable as pure HTML), updated all client code to vanilla ES6, but most importantly: we ported all of our existing Pattern Lab components and variants by encoding their data.json files into JSON Schema backed component definitions, or component APIs as we like to call them today.

via GIPHY

JSON Schema was something that had accompanied us for quite a while already by then. Back in 2013 we started experimenting with using it to structure data for static site generation. A colleague of mine, over 10 years ago 🤯, even wrote quite a nice (somewhat foreshadowing?) article about it:
https://pascalhertleif.de/artikel/silicon-zucchini/

This also marked our first time experimenting with generation of editor interfaces for content, based on our already existing JSON Schema definitions. Which ultimately lead to the release of our kickstartDS low-code CMS starters, and the tooling behind it, today!

What did we build?

We’ve built out tooling that can take component APIs as JSON Schema definitions, like those used in kickstartDS, and process and convert them to other useful formats.

What’s a format, you might ask. For us, currently, this can mean one of two things:

Development: Mainly pure TypeScript types for your components, and other related, generated output like GraphQL fragments or dereferenced JSON Schemas definitions
Integration: Headless CMS configuration; processing and mapping your Design System to the concepts of a specific content authoring solution, like Storyblok

That second part is what enables our CMS starters. They use this to take the Design System for design-system.agency and transform it to respective CMS configuration (for Static CMS, Storyblok and Netlify Create / Stackbit as of today) that can be used to start building a website based on such a Design System immediately. Everything demoed with those starters works the same for every Design System built with kickstartDS. To be more precise: it should work with every Design System that decides to encode its component API in JSON Schema. It’s completely generalized!

https://github.com/kickstartDS/schema

And if compatibility with every kickstartDS based Design System is one important dimension of creating the starters and converters, in the process building out the concepts and tooling to make creating connectors easier might actually be the more impactful one. The starters, and their respective connectors, are mainly meant as a demo on how powerful a strong JSON Schema-backed Design System can be. We hope it inspires others to build their own like-minded integrations for their (rightfully so) super specific needs. Hopefully our tooling can aid people in implementing those!

But after all… this is still mostly our own silo. This doesn’t unlock any greater effort, yet…

via GIPHY

And why might this matter!

I hinted at this in the very intro to this lengthy post. Web Components seem to be leaving behind their growing pains. With Declarative Shadow DOM arriving, one of the last missing pieces seems to finally complete the picture there.

With React (it seems) finally moving to support everything needed (they are the last major framework lagging behind substantially), too, we might be moving to a world post-framework discussions, and real interoperability on a technical level. I think Jake Lazaroff motivates this beautifully with his articles “Web Components Eliminate JavaScript Framework Lock-in” and “The Web Component Success Story”.

Brad Frost also recently wrote about his dream of a global Design System, and Web Components play a vital role there, too:

Given the above principles, I think it would make sense for the Global Design System to be a library of Web Components. Web Components are part of the web platform and are interoperable (in theory at least) with any web-based tech stack.

Brad Frost, A global Design System

In another great article of his, “The Design System Ecosystem”, you’d probably recognize it when he talks about the “core design system”. And some frameworks, like Astro, experiment with similar ideas about composition and collaboration, irrespective of specific frameworks, already.

If you now couple this with a shared way of documenting features and properties for shareable components (🗣️ JSON Schema), you can truly unlock the compositional potential the frontend should have.

We actually think people should build their own tailored casings around different component libraries, frameworks, and standards as they see fit for their requirements, there should be no lock-in:

Design: Connect your Design Tokens to a MUI theme to cover for your backoffice dashboards, or to Figma to enable a better designer-developer-workflow
Implementation: Integrate specialist libraries for specific requirements, like we do with Bedrock Layout Primitives for layout needs in kickstartDS itself
Structure: Use JSON Schema to add structure for interoperability with other systems and integrations (referencing could bridge and connect different systems through URIs)
Content: Use our kickstartDS Content module to fill gaps in your coverage of modern content page requirements

Add automation to leverage all of that to automatically, or at least more easily, connect and integrate your adopting systems. kickstartDS was built with those assumptions deeply embedded, and can serve as a great starting point to achieving the same for your Design System!

via GIPHY

A call to reverse roles

When building a Design System as described, you invest effort upfront, and justifiably so. If done right, this should not become a throwaway product. It shouldn’t die with a rebrand or redesign… or the change of CMS / backend. In my opinion it should be even more long-lived than every other aspect of your digital toolchain. Especially with the rise in composable and MACH architectures it will be increasingly important to have such a cornerstone in place.

How you interface with your users, customers or editors as a business should not be dependent on technological decisions. Only changes to your organization, or its embedded processes, should necessitate changes to your technical approach and ultimately the stuff you build, not the other way around.

And if your business, or some of your use cases, change or expand, having it set up like this can dramatically reduce the effort needed to reflect those changes downstream in your stack. A change of CMS for a some of your editors can be as easy as switching the integration you use.

This way we can realize the true potential of Design Systems, as the stabilizing core of your digital ecosystem.

via GIPHY

How this relates to AI

There’s a lot of buzz around AI in Design Systems currently (to be fair: this is probably the case for every imaginable niche out there).

With tools like Hermae (your custom Design System assistant) or Magic Patterns (your copilot for UI creation) launching, packaging existing ideas and workflows into an easy-to-digest form factor, while others like Jonathan of Roboto Studio show how this can also work by just using the right IDE, there’s still a lot of finger-crossing and LLM-wrestling involved when working with the results.

In the end, someone has to define what your org needs, and how its processes look like. AI can’t (I mean: it shouldn’t) do that. This is where you can use the human element to your advantage, as leverage for (generative) AI. If you know what you need, and you should have made sure that you do (remember the article I mentioned earlier about “Sociotechnical architecture”), encode it in a way that it can also be used for guided generation / Gen AI!

And I think “just” Markdown doesn’t quite cut it for safe guidance. For example: directly generating content for your components. But I’m really excited about tooling like outlines appearing, with a greater focus on guided generation for structured data. Because this is often what we actually need!

Taking outlines: as a coder you could easily plug your Design Systems JSON Schema into it… immediately getting complete safety on the data being generated actually being compatible to your component APIs. Or you could opt for .json, by the authors of outlines, to use the same capabilities through their API, even without deeper technical knowledge.

This is the strength we see in JSON Schema as a guiding factor in structured generation, good docs automatically serving as semantic context for the AI model / LLM.

via GIPHY

Looking forward

What does this mean for us? We’ll keep a good eye on Web Components, as this seems like the next evolution to go through. Replacing our React templates with pure Web Components, gaining even more framework-independence, seems like a pretty sure thing to happen.
We’ll also keep exploring ways of content generation, using tools like outlines. We already have encoded the concepts of website settings, content pages and blog posts into JSON Schema, powering our CMS integrations today. It would be a logical next step, to have guided content-generation, independent of headless CMS in use: “Please draft me content for a page about our upcoming release, use our Design System components for guidance”.

We also foresee a need for better general migration support (e.g. when changing a component in a breaking release), and ways of more flexibly mapping / connecting data to component APIs, or gluing together different component APIs for compatibility (e.g. when integrating with third party libraries).

And in general, I sincerely believe that at the intersection of Web Components and JSON Schema lies the potential to unlock the full power of a shared frontend ecosystem!

What do you think? Let me know on Twitter at @tsnmp or Bluesky at @tsnm.bsky.social. You can also connect with me on LinkedIn here!

Or join our community on Discord: https://discord.gg/mwKzD5gejY

Launching the Design System Concierge

Jonas Ulrich — Mon, 01 May 2023 22:16:28 +0000

Introduction

We’re thrilled to share the Design System Concierge with you! You can reach him here as of today: https://www.kickstartDS.com/concierge/

Watch a small dramatization of what interacting with our Concierge looks like:

Support us on Product Hunt for our launch:

Design System Concierge - Your AI-powered Design System assistant | Product Hunt

Get Design System answers, fast! Our AI-powered Concierge offers insights from our vast Design System database sourcing expert content only. Ask any question, get pointed to the right source. Your ultimate Design System assistant.

producthunt.com

Why build the Design System Concierge?

As Design Systems gain more and more traction these days, the amount of available content can be overwhelming, making it difficult to know where to start. Our AI-powered Design System Concierge can help by providing expert guidance and pointing you towards the right resources, whether it’s implementation guides, architecture documents, adoption strategies, or other content.

Talking to the Design System Concierge

To get the best possible help from our Design System Concierge, we recommend asking detailed questions instead of engaging in a chat. The Concierge provides quick and transparent answers by summarizing the most relevant content sources. Every answer includes underlying sources that you can easily check and visit. Trust us to deliver accurate and reliable information for all your Design System-related queries.

It’s important to note: The final answer is generated by Open AI GPT-3, and even if we take great care to reduce wrong answers you should always dive deeper. The answer given is not really meant as the end of your interaction. You can, and should, dive deeper into the sections most relevant to your question… as the Concierge is great at giving directions, but not really an expert himself (just like in real life!).

Why use it

Using it is free

Asking questions to the Concierge is completely free of charge for you. We’ve developed, and are now hosting, it, because we want to help lower barriers of entry when it comes to Design Systems. After all our mission is to “Democratize Design Systems”.

Additionally it’s a great opportunity for us to learn what you, as a user, actually want to know more about when it comes to Design Systems… or features that you’d expect from a Design System. This in turn can inform us on features to develop for kickstartDS, articles to write, or documentation gaps to fill in.

It’s specialized for Design Systems

Though the final answer is generated by Open AI GPT-3, all input given to it as context is completely controlled by us, and our integration. Only carefully selected sources (= domains with content relevant to Design Systems) are added to the Design System database, backing the Design System Concierge. This ensures answers will be relevant to the topic, and hallucinations are minimized. If there’s no relevant content in the database, no answer will be generated!

Additionally, by providing the exact sources the answer by the Concierge was based on, you should always verify it for yourself by diving deeper.

It promotes great content & creators

Sometimes it’s tough to just “google” your answer, especially when faced with highly individual and specialized questions… the ones you’d typically have when starting out, or when facing new challenges. Good content gets drowned out by a sea of content farm spam. By asking the Concierge instead, you get a highly curated set of content as the backbone. Best case: you discover a new blog author, content creator, or a specific Design System example to follow, helping inform your Design System journey.

How to use it

For a quick overview, have a look at the following, short animation:

1. Ask a question

Enter detailed, natural questions instead of trying to engineer your way out of a thick jungle of content spam, only armed with the waning powers of Google-Fu:

2. Get initial answer

Receive an initial answer instantly by the Concierge. This should be taken as a first summarization by an enthusiastic, helpful assistant… not as the final expert answer to end all answers:

3. Dive into sources

Even more useful then the initial answer are the sources provided by the Concierge. Those are the sections of text in our database that were found to be most relevant to your question. This should provide full transparency, and enables using the Concierge as a great guide-post to the real content:

How it’s done

Database of expert content

The Concierge is backed by a vast database of content curated, prepared and catalogued specifically by us:

For a full list of sourced domains, go to the Concierge. All domains are listed in the section “Knowledge database” over there.

Behind the scenes

The implementation is mainly following the great blog post (and example code) provided by Supabase. Their post was also the main reason for me to use Supabase with their PostgreSQL + Edge Function for the main hosting in the end. It’s a super nicely packaged solution, was just loving the DX!

Going into all the nitty gritty details would go beyond the scope permitted by such a blog post as this one (Spoilers: it includes non-Open AI SBert embeddings, a Fly.io Python- / Flask-Webservice for runtime embedding of questions, spliced and transformed Server Sent-Events streams, pgvector for database support of embeddings, etc, etc). Feel free to join us on Discord to discuss further… and for all the quiet explorers among you, I’ve made a Miro board outlining how everything works, over here:
https://miro.com/app/board/uXjVMdpB0ao=/

Alternatively, you can just go to the Github repository for the Concierge. All the code is public and Open Source here:
https://github.com/kickstartDS/concierge

Conclusion

We really hope the Design System Concierge can help you along your personal journey through the Design System space. We’re thrilled to see all the questions you’ll try on him, and what the overall reaction will be. We already have a truckload of ideas to explore further, if this resonates with the community!

If you want to give feedback to us, have ideas on what to improve or add, or just want to tell us what cool answers you’ve received… we’d love for you to join our small Discord community. Or maybe the Concierge was completely missing the mark for you? We’d especially like to hear about those cases, too!

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.

kickstartDS is Open Source now. Let’s start to democratize Design Systems today

Jonas Ulrich — Tue, 15 Nov 2022 11:26:26 +0000

Finally, the wait is over … today we are very proud to announce the Open Source release of kickstartDS. It’s been roughly one year since we started to go to market by publishing our first website, and we are thrilled to now share the kickstartDS core with everyone in the Design System community.

We’re also officially live on Product Hunt! Feel free to drop as an upvote 🎉
https://www.producthunt.com/posts/kickstartds

Why have we decided to go Open Source?

Some of you might have read my post on why we are creating kickstartDS. Today, I can proudly say that we reached the next big milestone of our mission to democratize Design Systems. Last year we started to implement kickstartDS for selected pilot customers, keeping the source behind closed doors. We wanted to validate technical decisions taken, and learn how developers interact and adapt kickstartDS.

During that time, while doing user research, presenting our ideas and solutions to developers, we often heard that they really like it… and that they would love to test it by directly installing “the package”. Well, who would go for a no-name, closed solution to build up something highly important like their Design System?

Open Source is the way! A couple of months ago we took the decision to share all our learnings and practices, wrapped up in the baseline of what kickstartDS is today. We want to continue that learning journey. That will be even easier with people working with kickstartDS independently, who hopefully also share their experiences and stories with us in the process. That is what we’d like to encourage users to do. Just try our setup guide… and once you own your Design System based on kickstartDS, really make it your own. Tell us how you adapted it towards your individual needs, even how you named your components, how you get along with it adoption are super interesting to us! So please share it with us and the community.

Help democratize Design Systems!

The term Design System describes a broad topic, growing more and more momentum. Where large organizations today mostly have problems with the adoption or governance of theirs, in small to medium enterprises the problem often already is to get a Design System started at all. For example, when standard frameworks are too difficult or complex to adapt, when stakeholders need to be won in a time when frontend experts are a rare good. The approach is doomed and will lead to compromised technical solutions; consuming even more time and budget.

Today quite some companies are already tackling similar problems. Talking of Knapsack.cloud, Backlight.dev, Specify, Supernova and many more, here. They all deliver value to simplify workflows for setup, integration, documentation and management of Design Systems. This is all super helpful in spreading the love about Design Systems to teams out there, and is a huge benefit to the process side of things. But you usually still need to create or import all of your components, which means that you still have some hard work before to you yourself, before finally benefitting from these tools. There’s also a lot (knowledge and work) going into the setup of a Design System (semantic tokens, hardened components, etc) that’s not solved by those tools, yet.

Setting up a code first Design System has never been easier

Developer Documentation

Visit our GitHub

To help you getting started quickly, we created documentation guiding you through the installation process of your first Design System built with kickstartDS… in just 5 rather simple steps.
The main steps will go as follows:

Start your Design System
Design Application
Configure Storybook
Add Components
Publish your Design System

Although the resulting Design System will obviously not be finished by finishing these steps, you’ll have everything set up to start on the real work.

The essential part

At that point you already got rid of some of the core challenges. Plus, this might even give you the mental freedom to tackle the unique components to your organizations actual needs.

Thinking of such components … usually, every company has content to display. On their website, on marketing or landing pages, in their intranet or documentation, you name it. You can now start developing the perfect “Hero Visual Component” with our basic Open Source components or you can skip even that by relying on our complex content components, which you can easily buy for a few bucks to add as additional building blocks for your freshly created Design System.

That package, additionally, really puts you in the driving seat… speeding up the ride for even the most individual and complex cases you’ll want to solve, the “next component your organization needs”. (this refers to Dan Mall’s talk on Converge’22, available through their registry here)

What’s next?

Now that kickstartDS is public we look ahead to its future with an open mind. We still have to work on many details to let our documentation really shine, for example. As we want to explain the underlying concepts in-depth. And since everyone is now free to install, test and use kickstartDS we believe in the great openness of the Design System community. We rely on your feedback by adapting to your needs, so that kickstartDS will really become the Design System starter digital teams like to work with.

Releasing kickstartDS doesn’t mean that the development is completed. We have lots of ideas in mind. Features or modules which may find the way into the portfolio, thinking of telemetry, adapters, transformers and much more based on our Component API.

Not to forget: a Design System is nothing without systems using it!

A Design System is there to generate value, to support the organization to better reach its objectives. Naturally there will be product or feature teams using it. About that, a 6th Step could and maybe even should be added to the setup process of the Design System.

Step 6: Apply your Design System

Whilst setting up kickstartDS you made quite a lot of decisions adapting the library to your organizations’ specific needs. You decided which properties every component needs, how to name components, and much more. What would you say if we told you: you can even add a CMS, using these exact Design System components, with just a handful of clicks? Where your editor immediately benefits from all your decisions, because the properties of components in the editor UI are always aligned with those from your Design System.

We offer adapters for some well-known content management systems already, e.g. Sanity.io, NetlifyCMS, Storyblok, Contentful and even WordPress.

One more reason why we think: relying on kickstartDS when building your Design System is of huge value for you and the Open Source community, who can start building more adapters and implementations on top of kickstartDS to simplify the process of applying Design Systems.

The importance of the growing Design System community

Thinking about the best thing we could achieve with kickstartDS, and as already written in this posts’ headline: do our part in democratizing Design Systems. The more people know about kickstartDS, the more organizations use it, the more developers build Design Systems based on it, the better it will become in the future. Helping organizations adopt best practices, and hopefully help everyone to get their Design System that decisive bit faster, while having fun doing it!

Join our Discord community to share feedback, ask us questions and start any discussion around kickstartDS.

Take a look at kickstartDS on GitHub, and tell us what you think.

And if you're on Product Hunt, we'd love your vote 🤗
https://www.producthunt.com/posts/kickstartds

Quarterly Design System and Frontend Podcast Roundup - Q1/22

Jonas Ulrich — Thu, 21 Apr 2022 19:07:11 +0000

#tldr Read our roundup of podcasts released in the first quarter of 2022. Everything related to Design Systems, Frontend development and headless CMS / Jamstack.

I’m listening to quite a collection of podcasts regularly, as I just love to learn about new stuff… and what others are building. And sometime at the end of last year I decided to favorite all those episodes that were really interesting to me. So this will be the obvious bias here… 😅
But maybe this turns out to be useful for others, let me know!

Podcast themes include: Design Systems, Frontend, UI, React, headless CMS, Jamstack

And I’ve added everything I starred in April so far, too… for good measure 😉

Podcasts featured:

PodRocket: https://podrocket.logrocket.com/ (12 episodes)
JS Party: https://changelog.com/jsparty (5 episodes)
devtools.fm: https://devtools.fm/ (3 episodes)
JavaScript Jabber: https://javascriptjabber.com/ (3 episodes)
That’s my JAMstack: https://thatsmyjamstack.com/ (3 episodes)
JAMstack Radio: https://www.heavybit.com/library/podcasts/jamstack-radio/ (2 episodes)
Front End Happy Hour: https://www.frontendhappyhour.com/ (2 episodes)
Console DevTools Podcast: https://console.dev/podcast/ (2 episodes)

This also means (at least for me) that PodRocket takes the crown for most listened podcast of the quarter… and by quite the margin, too! 🚀

On to the monthly overview:

April

April 15th, 2022

PodRocket: “Remix with Chance Strickland”

Hosts: Kate Trahan, Kaelan Cooter
Guest: Chance Strickland
Length: 26m 8s
Link: https://podrocket.logrocket.com/remix

April 14th, 2022

devtools.fm: Episode #28 “Steve Sewell – Builder.io, partytown, Qwik, mitosis”

Hosts: Andrew Lisowski, Justin Bennett
Guest: Steve Sewell
Length: 01h 06m
Link: https://devtools.fm/episode/28

April 14th, 2022

JAMstack Radio: Ep. 99 “Headless Commerce Engine with Sebastian Rindom and Nicklas Gellner of Medusa”

Host: Brian Douglas
Guests: Sebastian Rindom, Nicklas Gellner
Length: 28m 01s
Link: https://www.heavybit.com/library/podcasts/jamstack-radio/ep-99-headless-commerce-engine-with-sebastian-rindom-and-nicklas-gellner-of-medusa/

April 8th, 2022

Front End Happy Hour: Episode 147 “Debugging Asynchronous JavaScript – Awaiting My Drink”

Hosts: Ryan Burgess, Jem Young
Guest: Jenn Creighton
Length: 44m 56s
Link: https://www.frontendhappyhour.com/episodes/debugging-asynchronous-javascript-awaiting-my-drink/

April 6th, 2022

PodRocket: “Storybook with Chantastic”

Hosts: Kate Trahan, Noel Minchow
Guest: Chantastic
Length: 51m 59s
Link: https://podrocket.logrocket.com/storybook

April 5th, 2022

PodRocket: “KendoReact with Kathryn Grayson Nanz”

Hosts: Kate Trahan, Noel Minchow
Guests: Kathryn Grayson Nanz
Length: 42m 39s
Link: https://podrocket.logrocket.com/kendoreact

April 1st, 2022

PodRocket: “AgnosticUI with Rob Levin”

Host: Paul Mikulskis
Guest: Rob Levin
Length: 30m 12s
Link: https://podrocket.logrocket.com/agnosticui

March

March 29th, 2022

PodRocket: “SPAs, island architecture, and the future of development with Ryan Carniato and Dylan Piercey”

Hosts: Kate Trahan, Noel Minchow
Guests: Ryan Carniato, Dylan Piercey
Length: 51m 00s
Link: https://podrocket.logrocket.com/island-architecture

March 29th, 2022

JavaScript Jabber: React Component and State Management – JSJ 526

Hosts: AJ O’Neal, Charles Wood, Dan Shappir
Length: 01h 8m
Link: https://javascriptjabber.com/react-component-and-state-management-jsj-526

March 18th, 2022

JS Party: Episode #217 Going full-time on Eleventy

Hosts: Jerod Santo, Nick Nisi
Guest: Zach Leatherman
Length: 58m 00s
Link: https://changelog.com/jsparty/217

March 18th, 2022

PodRocket: Polaris: The Shopify design system with Alex Page and Yuraima Estevez

Hosts: Kate Trahan, Noel Minchow
Guests: Alex Page, Yuraima Estevez
Length: 50m 51s
Link: https://podrocket.logrocket.com/shopify

March 16th, 2022

PodRocket: Final Form with Erik Rasmussen

Hosts: Kate Trahan, Paul Mikulskis
Guest: Erik Rasmussen
Length: 41m 32s
Link: https://podrocket.logrocket.com/final-form

March 11th, 2022

PodRocket: Accessibility with Ben Myers

Host: Kate Trahan, Brendan Downing
Guest: Ben Myers
Length: 39m 20s
Link: https://podrocket.logrocket.com/accessibility

March 8th, 2022

PodRocket: Composing layouts with Travis Waith-Mair

Hosts: Kate Trahan, Noel Minchow
Guest: Travis Waith-Mair
Length: 40m 35s
Link: https://podrocket.logrocket.com/composing-layouts

March 4th, 2022

JS Party: Episode #215 Remix helps bridge the network chasm

Hosts: Kevin Ball, Ali Spittel, Divya
Guest: Kent C. Dodds
Length: 01h 13m
Link: https://changelog.com/jsparty/215

March 4th, 2022

devtools.fm: Episode #25 Anthony Fu – Vue, Vite, Vitest, UnoCSS

Hosts: Andrew Lisowski, Justin Bennett
Guest: Anthony Fu
Length: 52m 30s
Link: https://devtools.fm/episode/25

March 3rd, 2022

Console DevTools Podcast: Designing dev products

Host: David Mytton
Guest: Ellen Chisa
Length: 32m 45s
Link: https://console.dev/podcast/s02e09-designing-dev-products-ellen-chisa-boldstart/

February

February 25th, 2022

JS Party: Episode #214 Vitest && Slidev

Hosts: Jerod Santo, Nick Nisi
Guests: Anthony Fu, Patak
Length: 55m 00s
Link: https://changelog.com/jsparty/214

February 23rd, 2022

PodRocket: Slinkity with Ben Holmes

Hosts: Kate Trahan, Paul Mikulskis
Guests: Ben Holmes
Length: 32m 59s
Link: https://podrocket.logrocket.com/slinkity

February 11th, 2022

JS Party: Episode #212 A deep-dive on Vite

Hosts: Amal Hussein, Nick Nisi
Guest: Evan You
Length: 01h 14m
Link: https://changelog.com/jsparty/212

February 9th, 2022

That’s my JAMstack: REMIX! Tamas Piros on islands architecture, Astro and media usage

Host: Bryan Robinson
Guest: Tamas Piros
Length: 28m 52s
Link: https://thatsmyjamstack.com/episodes/tamas-piros-remix/

February 9th, 2022

PodRocket: Modern React with Paige Niedringhaus

Host: Kate Trahan, Noel Minchow
Guest: Paige Niedringhaus
Length: 50m 00s
Link: https://podrocket.logrocket.com/modern-react

February 6th, 2022

Front End Happy Hour: TypeScript migration – Strict type of cocktails

Host: Ryan Burgess
Guests: Sumana Mohan, Joe King
Length: 48m 22s
Link: https://www.frontendhappyhour.com/episodes/typescript-migration-strict-type-of-cocktails/

February 4th, 2022

JS Party: Episode #211 A Solid option for building UIs

Hosts: Ryan Burgess, Jem Young, Stacy London
Guests: Sumana Mohan, Joe King
Length: 55m 00s
Link: https://changelog.com/jsparty/211

February 3rd, 2022

Console DevTools Podcast: Devtools investing

Host: David Mytton
Guest: Ed Sim
Length: 30m 38s
Link: https://console.dev/podcast/s02e05-devtools-investing-ed-sim-boldstart/

January

January 27th, 2022

JAMstack Radio: Ep. #95, Islands Architecture with Ben Holmes of Slinkity

Host: Brian Douglas
Guest: Ben Holmes
Length: 27m 58s
Link: https://www.heavybit.com/library/podcasts/jamstack-radio/ep-95-islands-architecture-with-ben-holmes-of-slinkity/

January 26th, 2022

PodRocket: MUI with Olivier Tassinari

Host: Ben Edelstein
Guest: Olivier Tassinari
Length: 31m 43s
Link: https://podrocket.logrocket.com/mui

January 25th, 2022

JavaScript Jabber: Virtual DOM and the React Way, Part Deux – JSJ 518

Hosts: Aimee Knight, AJ O’Neal, Dan Shappir, Steve Edwards
Length: 01h 32m
Link: https://javascriptjabber.com/virtual-dom-and-the-react-way-part-deux-jsj-518

January 21st, 2022

devtools.fm: Yang Zhang – Plasmic

Hosts: Andrew Lisowski, Justin Bennett
Guest: Yang Zhang
Length: 57m 04s
Link: https://devtools.fm/episode/22

January 18th, 2022

JavaScript Jabber: Can JAMstack do REAL Web Apps? with James Q Quick – JSJ 517

Host: AJ O’Neal, Charles Wood, Steve Edwards
Guest: James Q Quick
Length: 01h 20m
Link: https://javascriptjabber.com/can-jamstack-do-real-web-apps-jsj-517

January 12th, 2022

That’s my JAMstack: Raymond Camden (REMIX) on the amazing expansion of the Jamstack ecosystem and how far we’ve come

Host: Bryan Robinson
Guest: Raymond Camden
Length: 27m 31s
Link: https://thatsmyjamstack.com/episodes/raymond-camden-remix/

January 04th

That’s my JAMstack: Salma Alam-Naylor on shipping, learning, and rendering in the Jamstack

Host: Bryan Robinson
Guest: Salma Alam-Naylor
Length: 27m 59s
Link: https://thatsmyjamstack.com/episodes/salma-alam-naylor/

And if you’re missing one from the list, one you’ve enjoyed a lot, let me know on Twitter! Always happy to add another one to my subscriptions 🙂

Setting up a working Design System in less than a day

Franz Leven — Tue, 19 Apr 2022 09:48:59 +0000

tldr: In this post I’d like to demonstrate how easy it can be to kick off your own Design System, by just applying some design tokens, and adding a sprinkle of customization, using kickstartDS. And as we’ve had some recent projects combining Sanity.io and Sanity Studio as the headless CMS, Next.js as the static site generator, and of course kickstartDS for the frontend, we thought: Might be a nice idea to simply re-build the Sanity.io landing page, as a showcase. So strap in and follow along!

Creating the template in React

The base structure was assembled rather quickly, by combining existing layouts and components. React in combination with a proper component library proved to be a really efficient combo here:

Theme and Style application

In the first step, I wanted to apply some basic style attributes that will roughly dictate the look and feel of the page. I consider this a stepping stone, to establish a first path which further token application can continue down further.

I asked myself: do I want something catchy with large fonts and lots of white space? Or do I need a slightly more dense experience, that uses spacing more efficiently, and focuses on delivering information?

Have a look at the screenshot below, to get a feel for how this looks:

Token application

With all those macro design decisions out of the way, I could now move on with customizing the individual token values, which got generated for me from the theming input I defined before. This is where structured tokens can make or break a Design System. You want a clear and concise purpose for every base level token.

What part of what component will be affected by this, seemingly insignificant, change I am making?

It is important that this is conveyed through the semantic naming of each token.

After configuring the token file for about two hours, the page was already remarkably close to the actual Sanity.io landing page:

This is great news, because so far I haven’t even had to customize a single line of code. I’ve just reused the existing structure to adapt a completely new design!

Token overrides

As seen, up until this point I could easily apply tokens without making any real design decisions, the Design System already made those for me, in a sensible and time-saving manner. However, a couple of components were still differing quite a bit from their real-world Sanity.io counterparts. This is mostly due to them having a different intention in this specific design application.

A quick example:
Let’s say you need a Teaser Box component that is supposed to really catch the attention of the user. However, kickstartDS intends Teaser Boxes to be more of in-page navigational elements. Following this intention, the Teaser Box by default has tokens that are supposed to generate muted background colors. If you want to change the background color to a more intense color, you should pick a new token representative of your intention. In this case we need a background color that is intended to signal interaction, so a good pick would be something like:

--background-color-interactive

Within this step, I’ve also integrated some of the foreign (to kickstartDS) components into my new Design System. At that point the pages were starting to look almost identical… I had to re-check the URL to make sure what page I was on 😉

Customization

If you want to step outside the foundational layer of design tokens automatically available to you, and get really creative with your styling, you can always just as easily customize the components more directly. I used this to adjust the remaining minor differences the two pages still had. These were details you probably wouldn’t even notice, if you were casually checking the page. But I still decided to adjust them.

Et Voilà, I’ve got my very own Sanity.io landing page, fully responsive and entirely done in kickstartDS. And a matching Design System to boot 🚀

All it took was:

a couple of hours of work,
58 token overrides and
70 lines of CSS

Check out the resulting page for yourself: https://bit.ly/3uGievY
And for reference, the original: https://www.sanity.io/

Wouldn’t it be nice to now also get a free, ready-to-use headless CMS integration for our newly created page, too? Start to customize with a nice, focussed editor interface… starting to build out our website? If only we had such a miraculous solution… and I wonder what headless CMS vendor would fit such a descrition 😏

Btw, did I mention? There’ll be a part 2 to this… tell us your guess on what that could possibly entail, for example on Twitter!

Unlocking the frontend - a call for standardizing component APIs pt.1

Jonas Ulrich — Sat, 26 Mar 2022 19:46:09 +0000

#tldr We're still wasting massive amounts of valuable development cycles in the frontend world by working in silos, or by to at least some extent reinventing the wheel for every project. Results suffer in the process, impacting real world results for users and content creators alike.
How did we get here, and how could a way forward look like? How we've already come a long way, and why still (so far) even Jamstack hasn't been the sole answer, either...

So what's wrong?

This is something I've been thinking about for a while now.
Way back in the day, when you wanted to build a website or digital product, you built everything yourself. You had no choice, you had to! This began with defining models and relationships, adding logic on top of it to extract the correct data to display, and implementing actions that should be triggered upon user interaction. Typically mutating server state of some sort. And then, finally, you purpose-built your frontend accordingly, for those exact circumstances.

All in all, oftentimes a very interlocked process between all parties involved. Be it between software specification and backend development, design creation & specification and frontend development or frontend and backend development.
Changes of every kind typically being costly as a consequence, leading to everyone trying to over-spec even more... a vicious cycle of ultimately missed expectations

via Columbia on GIPHY

Classic architectures

We've moved away from this by adding frameworks and new, more flexible development approaches into the mix. Mostly adopting a Model-View-Controller (MVC) approach in the process, doing some domain driven design, and as a result agreeing to a way more manageable amount of shared best practices. This happened for almost every programming language (e.g. Symfony for PHP, Rails for Ruby, Express for Node.js, Spring for Java).

In combination with adopting more agile processes to structure our development, this enabled everyone to be more resilient to often changing requirements. Because changes could be made in a more predictable fashion, and were better aligned with real needs, the resulting positive feedback loop kept converging everyone to adopting those shared best practices, fostering further exchange and standardization. Often designed into the respective frameworks from the start, as plugins, extensions or addons. Associated marketplaces further incentivizing this.

What about websites?

In parallel those conventions took hold for website development, too. Instead of general purpose frameworks (like Rails), which were still to expensive as a basis for the often repeated customer needs, content management systems (CMS solutions like WordPress, TYPO3, Drupal) took that place.

Adding already established models, and thus a specific domain for content, to the open approach of working with "just" a MVC framework. This also enabled them to create much more tailored interfaces for editors working with said content, and layering additional functionality on top; as you just knew much more about what everyone was working with.

But you still had to fine-tune it for every customer to create a truly fitting editor experience, and the frontend still got painstakingly re-implemented with every major overhaul. Additionally you had to fit everyone into the same monolithic system, increasing complexity and cognitive overhead for all different types of editors involved (news, career, marketing, blog, internal communication, the list goes on, all with different editorial needs).

via GIPHY

The first wave of ecosystems for the web

Both ways of building web interfaces (website vs application, or custom vs CMS) succeeded in establishing flourishing ecosystems around their approaches, though, allowing developers to start exchanging real code instead of just ideas or framework best practices... getting more efficient in the process, while generally also creating better results. But you were still locked into that specific ecosystem, trying to build a monolithic jack-of-all-trades, even more so if your goal was to have a consistent experience over all the different brand touchpoints a user may encounter on his customer journey.

by kickstartDS

Emancipating the frontend

For websites, lately, this mental model has been challenged again by the notion of headless content mangement systems, and more generally speaking by completely detaching the frontend from the backend in an approach now often called the Jamstack (in comparison to the LAMP stack traditionally found in a CMS).

This decoupling enables establishing a shared contract between both sides, an API. Making teams working on them more independent of each other, while also increasing stability because everyone can test against it in isolation.

With generators (Gatsby, Next.js, 11ty) being a central part of the Jamstack approach, one additional super power that's unlocked by them is the possibility to use multiple sources to feed into one resulting interface or website. Ultimately mix-and-matching backend and API solutions into one consistent experience, with everyone using the tool most suited for his daily job. The marketing team may work with WordPress to create long form content and something like Storyblok to build engaging landing pages. The main website could be built with Sanity, or other structured content-oriented solutions, as the headless CMS to really leverage connected, long-lasting content where it matters. Even other data can be spliced into the mix by adding third-party APIs as needed.

Frontend frameworks like React embrace that way of working by optimizing for composability, while tech like GraphQL helps with enabling that same composability for APIs. In combination with a lot of SaaS offerings being API based, or at least supplying really rich, well documented APIs as par of their open source strategy, this unlocked a huge potential in the space for re-use, specialization and standardization. And I'm sure we've just started experiencing the paradigm shift associated with that!

But... where's my frontend ecosystem? 😓

Unfortunately though, we still often build frontends completely isolated from each other. Creating and reinventing one-off work that suffers as a consequence, because you just can't invest the time that's needed to make something really good (in regards to performance, accessibility, responsiveness, cross browser-compatibility) in the time allotted for such frontend work. All while additionally trying to stay on top of the current trends, and changes inside our own ecosystems because of the rapidly changing landscape.

Way too often still you're confronted with some form of digital design (be it Sketch, Figma or Adobe XD) on the one hand, and data structures that are the result of decisions that were made in your absence, when choosing and building the generator and APIs on the other hand. It's your job then to create a component from that, hopefully creating something re-usable, which is expected to be universally understood by everyone to be the same thing. And did you know that the same component is supposed to work on the blog, too? But it should look and behave slightly different? A thankless job at best.

Man stands face to face with the irrational. He feels within him his longing for happiness and for reason. The absurd is born of this confrontation between the human need and the unreasonable silence of the world.

Albert Camus, The Myth of Sisyphus and Other Essays

This all, unfortunately, still makes frontend development a pain. While valuable engineering time goes into chasing problems that have been solved a thousand times before. Often even by oneself, just two projects before the current one...

Why just creating a Design System is not the answer, either

For product teams tasked with starting a Design System today, this also way too often feels like just another added thing on top, that's expected to be delivered, en passant. Neglecting that for that to work the focus would have to shift dramatically, adjusting the way frontends are architected, and enabling frontend developers to realise the potential demanded from them. And also fulfill those Design System promises like "automatic" consistency, more efficient development cycles or magically aligned stakeholders.

There needs to be a better way to foster the same exchange, longevity and interchangeability between frontend developers and the results of their work! Unlocking the frontend potential, like it has already been unlocked for other parts of the products and pages we're building! In a world of Design Systems this also means letting the frontend somewhat dictate the rules of engaging with components more, in some places inverting the way we work today.

And the attentive reader could have already spotted: we haven't even really spoken about content strategy, connected content and the influence content creators and editors should have in those architectural decisions. Which for most just reflects the way digital interfaces are built today... with the people working with the resulting software unfortunately being an afterthought. And the results suffering in the process. Only in uniting all those stakeholders in the decision making process will the end result, a tangible page or application that is generating true value for both the user and the creator, be successful.

via Gilmore Girls on GIPHY

So what now?

What was behind every major evolution of the web in the past was people rallying around shared principles, doing something in a more coordinated and repeatable way. I'm pretty convinced that for the frontend this has to mean some kind of standardization. Standardizing the way components can be compared, the way they expect and consume data, and effective ways of mapping between all of those. I'll explore those thoughts in part 2, and try to showcase how we're trying to solve for this today inside kickstartDS, for our users. And maybe, just maybe, this could someday align with a greater approach to all of this, unlocking not only the true potential of something like kickstartDS, but the potential of the wider frontend development world.

How this has impacted our work over the last 15 years? How possible solutions to this could look like? And why we think to be having some potential answers at the core of kickstartDS, today?

Read more in part 2, very soon!

Also, hit me up on Twitter at @tsnmp to exchange ideas (or to tell me where I'm possibly getting it all wrong 😋). Would love to hear others takes on this!