Pattern Lab Thoughts

pattern-lab.md

I love PL and the work that Dave and Brad have been doing. This is just random bullshit I've been thinking after a week of Pattern Lab use. Just

1. Just a source directory?

I've found that working on my current Pattern Lab, the only directory I really need is the source directory. That makes me think that all the config|core|extras|etc folders could not exist or be hidden from the user. That way a generic Node process that could be used by grunt, gulp, broccoli, etc might be beneficial. The "engine" is hidden from the user. Then updates could be seamlessly injected where now it'd be a bit of a manual process.

I think the simplicity of just having the files you're working on decoupled from the technology would be great for onboarding new users. Edit your source files (now at the project root) and point a nodeapp/grunt/gulp task at it.

It feels like a question of do you want it to be WordPress for patterns (engine coupled) or a Jekyll for patterns (engine decoupled/hidden).

Relevant links:

• PatternLab Jekyll

2. YAML/JSON instead of Ordinal Folders?

I've wondered if it's easier to just update some JSON instead of keeping folder and file names numerically prefixed. If you delete a pattern, it's a bit of work to re-ordinate all the other files (lots of git changes, etc).

This would maybe help in up-cycling patterns into a larger system (which is a lot of people's dream). I can then tell a backend developer to include() the molecules/global/pagination.mustache instead of molecules/02-global/03-pagination.mustache/, where the numbers seem subject to change. PL could then start existing within a directory of a larger system.

3. Extensions?

I talked with Brad about this, I know it's on the roadmap. I wonder if Jekyll's _plugins structure might be good here, and those are little web components (HTML/CSS/JS ... Polymer?) that inject features in to the style guide header. Extensions could be included/excluded using YAML/JSON as well.

while finding balance between approachability (see here) and cutting with the grain of current front end dev practices.

Well said, @bmuenzenmeyer. This balance is something that @dmolsen and I have taken very seriously right out of the gate. There is certainly the potential to make a really robust Pattern Lab that relies upon relatively advanced tools. But in doing that, you end up giving up that approachability to a whole lot of folks. Kudos to @dmolsen has done such a good job at keeping the dependencies to a minimum (it only requires PHP, nothing else).

What I would love to try to solve is a way to create as robust a system as humanly possible while still being approachable to folks who aren't fluent in Bower, Grunt, and the like. I enjoy playing the part of the idiot, largely because I am one :) So the goal is to create a tool that's simultaneously advanced yet approachable to beginners. I like that challenge.

IMHO PL is the patterns, not a build system (or shouldn't be), when there are much better existing alternatives that can accomplish what you need. So if the goal is to help PL become a better build system, I'm happy to give feedback if it's desired. But there probably isn't much more I can offer.

Every single thing that has been listed on this gist can be done by Assemble out of the box. Just as PL is about the patterns, Assemble is focused on being able to build components into any pattern you need. If you want to build PL with Assemble, just use the PL helpers. If you want to build YUI docs, use a YUI plugin, if you want to build OOCSS, use a plugin, and so on.

Shifting gears, on the topic of deps, IMO keeping dependencies to a minimum isn't a goal unto itself, it needs to be balanced with what needs to be accomplished. Just as developer convenience is more important than micro-performance, shaving off a couple of dependencies at the cost of losing access to context in deeply nested components would be a bad trade-off. I guess my point is that deps shouldn't even be a part of this discussion. Not until the goal is reached, then we can look for ways to optimize. just my 2c

Hi Guys! I'm just building a styleguide system similar to pattern lab.

TL;DR:
Everything is a remix. Pattern Lab was almost exactly what I needed, and what the OP is asking for is just what I built over the last few weeks - without knowing about PL when I started. Seems like we all share the same mindset and ideas...

The aims I had in mind was to recreate the structure of a "classical" styleguide without its drawbacks and with maximizing the benefits of real code, so:

• address the needs of the client, template devs and designers
• document how things work in real-life - with interaction => for the client
• document how to build HTML so it uses existing modular styles => devs working with templates
• document what building blocks are already there and how they work together, to enforce consistency of the design and help => designers
• make the whole thing really easy to maintain for us frontend devs
• and: use it as a build-tool for frontend development (like Grunt/Gulp, with things like browserify, less, sass, icon font generating etc. easily added)

Trying to build a living styleguide, I first stumpled across StyleDocco, KSS, Sassdown and the likes. Easily integrated into Grunt/Gulp, but the output was too technical to recreate the structure of a "classical" styleguide. Also, it documents the CSS rather than how to build the HTML.

So I started thinking about a usable structure. I still didn't know about Pattern Lab then:

• have a folder structure which will represent the styleguide navigation (like PL)
• organize the order of items - with TOC files or via file name prefixes (also like PL)
• provide a way to test patterns in different viewports for responsive design (hello again, PL)
• have the documentation right along with the pattern (buttons.html + buttons.md) to document the usage (like @davatron5000 suggests)
• optionally: modify single patterns with custom CSS for creating styleguide-only things (like color swatches, grid mixin documentation, font listings etc.) => I use an Iframe for each pattern to encapsulate the CSS (like StyleDocco et al)

So: each pattern consists at least of an HTML sample rendering, HTML source, and optionally usage documentation as markdown text and/or CSS.

I built the whole thing based on gulp-webapp and implemented all of the things. THEN I stumbled across Pattern Lab! Whoa! Someone did it before! And it's the brainchild of Brad Frost :) - how could I miss that!? Atomic Design FTW! The PL concept is basically the same. I just didn't think of nesting patterns inside of each other. So I added that. But there were things I missed in Pattern Lab - basically things the OP thinks about:

• the documentation is too separated in JSON files
• no frontend build tooling
• some essential design differences

Now: should I contribute to Pattern Lab? Yeah, basically I should. But it's not that easy: I'm a PHP analphabet. So: patternlab-node? Hm, the PL structure is too different and my attempt already had reached a similar progress. Fork it and bend it to a whole new direction? It would be too different, so I continued my thing.

Now that I see that our needs and ideas are so similar, I will open-source my work and see how we could make one big thing out of it!

Thanks @bradfrost, @dmolsen and @bmuenzenmeyer for your inspiring work! In the end I copied a lot from you - well, you got it just right in so many points!

Sorry for the long post, I just couldn't resist.

Cheers!

Here it is: https://github.com/levito/living-styleguide

I'd love to hear your feedback!