A Frontend Workshop Environment

Where do you build UI code? That sounds like a dumb question, but it’s a deceptively important one. There’s a few ways to do it:

  1. UI code is authored within your application environment. If you’re working on a WordPress or Drupal project, maybe you’re writing HTML, CSS, and JavaScript in your theme folder. If you’re building a UI in React or Vue.js, you’re writing that presentational frontend code in the same codebase that contains the application’s business logic.
  2. UI code is authored in a dedicated workshop environment outside of your application environment. Tools like Pattern Lab, Storybook, Fractal, VueDS, and other tools help development teams visualize components and (in many cases) construct templates and representative pages outside of the application environment.

There are merits to each approach, but I’m going to take some time to explain why authoring UI code in a dedicated frontend workshop environment makes a whole lot of sense.

Why Workshop?

I think more often than not it’s helpful to author UI code in a dedicated workshop environment instead of authoring directly inside of an application environment. Here’s why:

  • No getting sucked into dev environment hell – Application environments can be gigantic icebergs of complexity and dependencies. Setting up databases, configuring API secret keys, etc can be a hell of a lot of work. It seems unwieldy to have to wade through all that muck if your only concern is styling a button. The whole impetus for creating Pattern Lab was to have a place that I could focus on building presentational code without first having to spin up a huge tech iceberg.
  • Can quickly create real product scenarios without having to build that functionality out for real. What does the dashboard look like if the user is brand new vs a veteran user? What does the logged in header look like vs logged out header? What does this product grid look like with home accessory products in it instead of clothing products?  With a dedicated workshop environment, teams can quickly spin up a new story and pass in different props. Or create a new pseudo-pattern and pass in different data to articulate a specific scenario. Expressing these scenarios in an application dev environment often means having to build out real logic, maybe wire up some new APIs, seed a database with new content, write a bunch of business logic, or mess around inside a CMS admin. And doing so means potentially polluting the real data with a bunch of hypothetical content.
  • Don’t have to trip over implementation-specific code. In order to express a particular UI scenario, you don’t have trip over WordPress loops, API calls, and other backend considerations. You don’t have to worry about the conventions of the backend system in order to structure and style your UI.
  • More accessible/approachable to non-engineers – Asking designers to spin up a big, complicated dev environment and then warn them not to touch this, this, this, this, and this doesn’t exactly encourage participation. Because workshop tools are relatively lightweight and aren’t truly wired up to backend systems, they’re more inviting for designers and non-tech types. In our projects, we’ve trained IA designers, copywriters, and project managers to update JSON/YAML content and visual designers to own certain parts of the CSS architecture.
  • Design system thinking – Working in a dedicated workshop environment provides a clear separation between the UI design system and the specific application(s) it serves. This helps everyone think of the UI as its own entity that can power multiple applications. Creating UI code within a specific application codebase couples the UI and application code, making it harder to pull apart if and when the need comes to send that UI code to other properties.

The result of working in a dedicated workshop environment leads to a more nimble UI development process that also facilitates collaboration. Crucially, I think this setup helps UI developers become active participants in the design process.

Have your cake and eat it too

Now of course it’s incredibly important to ensure that the UI you create in a workshop environment is able to be consumed by real application environments. Ultimately templates and pages created in a workshop environment are merely representations of the real deal, and a CMS may influence how the frontend manifests itself.

It’s absolutely possible to have your cake and eat it too. There’s been a ton of great work around integrating Pattern Lab into Drupal, and setting up Storybook to articulate representative pages while still having the application be the source of truth.

So yeah! In short, I think creating UIs in a dedicated environment outside an application codebase makes a whole lot of sense. But as always, I’m curious to hear what other people think. Hit me up.