Open bradfrost opened 6 years ago
This is great Brad! ⚡️ the workshop and the storefront is a great distillation of primary use cases for a design system.
I think your proposal captures the essence of what we've wanted to accomplish, and also explains the vision behind some of the actions we've made more recently - like theme customization, and changing the styleguidekit
templates.
In PL Node 3.X I tried making the frontend more customizable by allowing users to override templates (some but not all) via configuration within patternlab-config.json.
With this storefront vs workshop concept taking on increasing weight, I think I can take this all a step further.
What I envision, from a technical level, is that a Pattern Lab Node Core "build" basically does all the pattern gathering and rendering to HTML as it does now, but DOESN'T write anything to disk. That writing to disk would be deferred to an enhanced ui_builder, which will build as many ui's as the user has configured. We would then pre-package Pattern Lab editions to ship with the current ui, let's call it patternlab-web-workshop
for now, and the new patternlab-web-storefront
. I know you mentioned making sure the both teams can still work effectively, even down to commands that they run. I am confident we can hit that mark. Keeping them separate allows us to develop them independently, AND allow users to add a third or a remove one at will. This achieves the grand-vision Dave had with the ui separation, but I hope in a better-executed fashion. I'd need to change a few things up to make this work, but I think it's the best way forward. Putting all the code in a single repository (monorepo) will help too - something @geoffp and I are doing during an upcoming Hackday. Another key will be documenting exactly what Pattern Lab has in memory post build and what data we expect people to write. We've never really documented this because we've had working code - but I think this will be an inevitable need.
I hope you like my idea to package storefront and workshop as separate build-able UIs, I think we can really hit the mark.
My vote: 👍
Next steps:
@bradfrost I've started designing this within https://github.com/pattern-lab/patternlab-node/issues/811
The purpose of this post is to describe the vision for using Pattern Lab as a proper style guide website (a storefront) in addition to continuing to serve as a dev environment (a workshop) for designing/building UI design systems.
The Workshop and the Storefront
A while back, I wrote a post that laid out the differentiation between workshop and the storefront environments when it comes to design systems. I encourage you to read the post to get a full understanding of the terms "workshop" and "storefront", but here's the gist.
The workshop is an environment designed for the teams working on designing/building the system's components. Pattern Lab as it currently stands is a workshop environment. The Pattern Lab UI is muted, small, and skinny; it's designed to get out of the way so the working team can focus on the UI they're developing.
The storefront on the other hand is where all the ingredients of the design system (components, design guidelines, design principles, links to tools, resources, contribution guidelines, et al) are put out on the shelves for everyone to see. That place is the style guide website, which you can see in the wild with sites like Lightning Design System and Carbon Design System.
The purpose and audience for the style guide website is different than the dev environment in a number of ways:
The Problem
These differences between the workshop and storefront environments are real and justifiable. That's why many (most?) organizations maintain two separate environments for their workshops and storefronts. Teams will have an instance of Pattern Lab or Storybook or whatever to do their work, and then maintain a separate site where finished components are imported and documentation is written.
This workflow works for the most part, but at the same it creates duplication of effort, puts a burden on the team to figure out how to import the components into the style guide and keep everything in sync, and requires standing up and maintaining two separate UIs. Wouldn't it be nice to be able to manage a single source of truth for the design system's components and documentation, then have it build out both a workshop and a storefront?
The Proposal
I propose creating the ability to generate a storefront view from Pattern Lab in addition to continuing to support the current workshop view. This would create a true single source of truth for the design system's components and documentation, and would help teams stand up a fully-functional (and—notably— beautiful!) style guide with a snap of their fingers.
It's important to note this would be a different separate build process than the existing workshop process. It's using the same core ingredients to build two separate things that achieve different goals.
Making It Happen
Different templates?
We've done a big refactor of the Pattern Lab UI to clean up all the frontend code, create themes (such as switching between a top navigation bar and a side navigation), and so on. The thought is this could build upon this foundation to generate the style guide.
However, I think that trying to do it all within one template, especially one that involves a giant
iframe
, wouldn't yield the best results. I think it makes sense to have separate templates for the style guide views so that we have maximum flexibility to display storefront information in a way that makes the most sense. I suppose one way of thinking about this is running Pattern Lab's data, content, and patterns through something like Style Guide Guide's code and yielding a result.Another interesting wrinkle to all this is that it would be cool if teams could dogfood their own UI components to build the style guide. That might be logistically crazy to accomplish, but it's worth pointing out that it's often a good idea to build the style guide from your own components.
Build Process
Using Node Gulp vernacular, the build process could look something like this:
And it could generate the style guide website into the root of the project under the name
/style-guide
or something. (I realize though we're unfortunately using the name "styleguide" elsewhere in the codebase).Keeping it a separate process means that it could get deployed and built to the style guide website using that command, while the working team can continue to use the normal build process to generate the default workshop view.
The Questions
So that's that. I don't want to wade too far into the implementation details just because that's out of my depths. I'm curious to hear how we'd go about achieving this, and even more curious to hear answers to these questions:
So that's that! I'm curious to hear what people think about all this.