UI Priorities

[bradfrost]

Here's a basic list of UI priorities for me:

• Light theme - creates a white background version of PL's header/modal
• Density themes - creates comfortable and cozy themes that make PL's header more prominent
• Sidebar theme - transforms PL's header to a sidebar
• Style guide theme - Creates a UI that's more attractive to a general audience. Exposes all pattern info by default, removes some workshop-specific features, only shows completed patterns, etc.
• Custom stylesheet support - allows user to define their own CSS to be included in PL's header
• Logo support - allows user Add optional logo setting #75
• Create UI for pattern variations create a better experience around viewing pattern variants / pseudo-patterns #73
• Explore UI for filtering by pattern state/tag [EPIC] vNext #66

If there are other things you're looking to have me take a look at, lemme know.

[bradfrost]

Oh! And of course, the JSON schema functionality is a huge thing.

[evanmwillhite]

The frontend team at my company has been discussing creating a new UI for Pattern Lab this year. I wasn't necessarily thinking this would be the UI, just a UI that we could offer to the Pattern Lab community. Before we start on a separate project though, is there work being done that we should tap into? Where have these items with checkmarks above been done? Thanks!

[bmuenzenmeyer]

hi @evanmwillhite good to hear from ya!

The PL Node space now offers support for multiple UIs to be built from a single set of base patterns. We call them UIKits. Learn more about them at pattern-lab/patternlab-node#840

You'll see that in an attempt to kickstart users in their UI journeys, I created https://github.com/pattern-lab/uikit-bare which attempts to give you a clean starting point. There are a number of files in there I'd consider integral to the current scheme, but as the PR and that repo / wiki will attempt to clarify, you can do whatever you want atop the expected templates and data.

Feedback is welcome in order to make this as easy as possible.

[evanmwillhite]

Thanks @bmuenzenmeyer! I am excited to jump into this. Is this something we could (/should?) port to the PHP ecosystem or is that going away?

[sghoweri]

@evanmwillhite fwiw, our design system team is operating under the idea that at some point Pattern Lab PHP and Pattern Lab Node will eventually merge together once a lot of implementation details are worked out — full support of PHP-written Twig extensions + Twig namespaces being two of the larger ones.

That said, “eventually” doesn’t address a lot of the friction the current iteration of the UI has stirred up internally so we’re focusing a lot of our efforts on work that can be ported over (ex. Schema validation via a couple Twig extensions, rewriting the Styleguidekit UI to use NPM, porting JS Logic over to use Custom Elements, updating the Twig Starterkit Templates to work with the latest versions of the Workshop UI code in PL Node, etc etc.

Basically, make stuff better and try to be as nimble as possible so we can share this work with the community!

[evanmwillhite]

Hey @sghoweri! This sounds good, and it makes me wonder if we should help with this work you've described instead of creating a new UI. Any specific issues you think the Four Kitchens team might be able to help with?

[bradfrost]

Heya! Just hopping in here to say I'd love to be a part of these conversations. What we're trying to do is create a flexible UI architecture that allows teams to customize UIs to their needs. I wrote more about that initiative over here: pattern-lab/the-spec#38

So yeah! I'd love to hear/see what everyone's wanting to accomplish, and let's find a way to put our heads together to make that happen.

[bmuenzenmeyer]

@evanmwillhite

I am excited to jump into this. Is this something we could (/should?) port to the PHP ecosystem or is that going away?

I have no intention of doing this, but as @sghoweri mentioned people are welcome to continue contributing to this repo should they find value in its featureset and stability. I am more focused on stabilizing the PL Node 3.0.0 release, which includes consuming this repo in our monorepo as uikit-workshop. I have ported and will continue to port substantive things from here into there as needed. I'd love it if the majority of work moved there over time, however!

I also hope that people will give UIKit development a try and provide more feedback. Things are a bit rough around the edges yet - but we are nearing stability.

[sghoweri]

I think I could use a bit of feedback on where we’re at so far before doing anything too crazy 😉

For example, the first round of things I’ve been chipping away at is meant to give us a solid base to work off of first, before digging into the fun net new stuff (like porting over some of the UI to be custom elements)... just not sure if this stuff is valuable enough to get some RFCs up or better to wait till a bigger example or two is in place.

Pattern Lab Refactor (So Far)

Templating

• Updated the PHP’s Styleguidekit Twig Default repo Twig templates to match changes recently made to the mustache templates (broken otherwise)
• Switched tabs UI from using links to buttons in the markup while retaining same class names

JavaScript

• Broke apart the original JavaScript in PL’s Styleguidekit Assets original Pattern Lab JS scripts into separate standalone component folders + shared JS utilities without a total rewrite
• Fixed many many JavaScript errors due to non-existent / undefined / lack of variable scope.
• Updated components to now use legit dependency management (via package.json files added per component)
• Switched PL JavaScript to use ES6 imports and exports (especially important given how many of these parts talk to one another)
• Replaced abandoned jwerty library with Mousetrap, re-wired up to use existing logic for the time being (no config changes, etc).
• Patched the typeahead logic so it doesn’t automatically init more than once (aka duplicate typeahead menus)

Dependency Management / Performance

• Updated Pattern Lab components and utils to use the @pattern-Lab NPM org namespace.
• Add Lerna to help manage shared dependencies (specifically Lerna + Yarn workspaces)
• Removed Bower + Bower configs; switched everything over to use NPM dependencies
• Removed render blocking script tags calling Bower dependencies in the markup

Sass

• Fixed Sass so the top level dropdown text items aren’t wrapping (flexbox issue)

Build Tools

Removed the need to have a separately managed and maintained Gulp build process; switched everything over to use Bolt’s own @bolt/build-tools build with only a few lines of config:

https://github.com/bolt-design-system/bolt/blob/f047dffc9650a0895efd999af8331469a955b1f5/apps/pattern-lab/.boltrc.js#L112

//.boltrc build config

// individual bundles to compile
    individual: [
		//...
      {
        name: 'patternlab-pattern',
        js: '../../packages/styleguidekit-assets-bolt/src/patternlab-pattern.js',
      },
      {
        name: 'patternlab-viewer',
        js: '../../packages/styleguidekit-assets-bolt/src/patternlab-viewer.js',
      },
      {
        name: 'pattern-lab',
        scss: '../../packages/styleguidekit-assets-bolt/src/sass/pattern-lab.scss',
      },
    ],

Sass

• No more need for a separate Sass build process — now compiles using Webpack 4 + fast-sass-loader + autoprefixer.

JavaScript

• No more need for a separate JS pseudo build process (including @require comments) — now using Webpack, Babel and Uglify.

Templates

• No more need to have separate build for assembling the HTML Pattern Lab’s UI uses. Still using Hogan on the client for now — renamed template files to Twig + wrapped actual mustache templates in {% verbatim %} tags for the time being

• Re-assemble PL’s templates using Webpack HTML Plugin + Twig loader (mustache logic intact)

• Finish initial round of cleaning up HTML templates

• Async load PL CSS and JS

• Remove jQuery dependency

• Replace syntax highlighting with the <bolt-code-snippet> Web Component.

• Expose config option for keyboard shortcuts

• Switch Hogan client-side templating over to use HyperHTML or Preact-powered custom elements (ex. <pl-tabs>, <pl-nav>, and <pl-dropdown>)

• Update how JS pulls in external JSON data to be asynchronous and non-render-blocking

[bradfrost]

@sghoweri There's a lot here, and thanks for doing all this!

I'm very much invested in the UI-specific stuff, and just want to make sure that any of this work (for instance changing tab links to buttons) is done across the board and works with the architecture @bmuenzenmeyer put in place.

As I see it, the JS stuff is all well out of my grasp and I realize there's a lot to untangle there. But I'm super interested in all changes to the HTML & CSS, so would be happy to learn more about these changes!

[sghoweri]

@bradfrost most certainly - totally agree!

Ensuring compatibility with the rest of the ecosystem is one of my top priorities here so naturally I'll want to make sure we test the crap out of this (and refactor anything if need be) before putting together a formal PR for all this.

We're still iterating like crazy on the UI we're pushing to have Pattern Lab work hand in hand with for our own design system (Bolt) -- out of the box Pattern Lab + with any of our own customizations as necessary -- but in case you were curious, here's an early sneak peak of the designs... 😉

And our current button component page in PL for reference: https://boltdesignsystem.com/pattern-lab/?p=viewall-components-button

[bradfrost]

@sghoweri YEAH BUDDY. That looks fantastic, congrats! And absolutely looking forward to working with you to get all this great stuff into the PL project.