Develop a Better Initial State That Doesn't Require Nuking All The Things

[dmolsen]

While core/source/ is a nice starting point for the demo it can be confusing to others on what can and can't be used. It might be better to have an amazingly slim core/source/ as a starting point and then save current core/source/ as a custom boilerplate we use to generate the actual demo.

/cc @joshrcook

[bradfrost]

I'll be honest, I haven't been able to get the difference between core/source and /source. I haven't read the docs, but I'd be happy to have a think about how to make a smarter default for people.

[dmolsen]

@bradfrost -

The difference between core/source/ and source/ is that core/source/ isn't supposed to be edited ;) core/ is designed to make upgrading easier and is supposed to be the base install/distribution of the system including the builder. Literally, I want people to simply copy core/ out of a ZIP download, copy it into their install of PL, run php core/builder.php -g and be up and running with the new version and new assets. As of v0.7.0 the builder/, listeners/, and scripts/ directories were deprecated. All of that stuff is now in core/.

On install/upgrade things are auto-magically copied from core/ into the appropriate locations around the system using migrations. During install this would be the copying of core/source/ to source/. On an upgrade it can be any new items (e.g. 00-meta/) from core/source/ to source/.

So source/ right now after an install is the full-on demo because that's what's in core/source/. The question is what do expect people to do what with it? It's not really supposed to be a base but we've copied it over as if it were. I think the demo is useful for demo.pattern-lab.info. Just not sure it's right for distribution.

This is all stuff we can talk over when you're back in the 'burgh. It just came up in a discussion here with a new hire who was trying to use PL.

[aarongustafson]

I agree this needs to happen. Perhaps the "demo" could be a separate download that could be dropped into source as an example?

[bradfrost]

This is super insightful. The question I'd like to help tackle is: what is that lightweight baseline? My initial thought is that the basic atoms are still beneficial as it would be a pain in the ass to have to recreate every basic HTML element. Having empty meta elements (head, foot, etc) is also probably a good idea. And lastly, it might still be a good idea to have at least one instance of each stage (molecule, organism, template, page). I think it makes sense to have empty CSS, JS, and assets folders.

On Thursday, February 13, 2014, Aaron Gustafson notifications@github.com wrote:

I agree this needs to happen. Perhaps the "demo" could be a separate download that could be dropped into source as an example?

Reply to this email directly or view it on GitHubhttps://github.com/pattern-lab/patternlab-php/issues/117#issuecomment-34914589 .

---

Brad Frost http://bradfrostweb.com http://twitter.com/brad_frost

[dmolsen]

@aarongustafson -

I've been playing with the idea of "boilerplates" for PL. I think the "demo" could be an example of that but I'm not sure if that's still putting too much on the "demo" as a starting point when it really isn't.

@bradfrost -

How do you see atoms in PL? In the past you've hinted that they're not really to be used in other patterns. So they're just pure style guide elements? A good example of where my head breaks on atoms is in not having h* tags as separate patterns. That said, I think the one instance and maybe an example of a pseudo-pattern is about all one would need.

Oh, the files in 00-meta should be required. They're essentially hardcoded into the PL builder.

[aarongustafson]

We just used Pl for the first time and the Atoms designation was a tough one for us. Brad's example in the Atomic Design talk (field, label, button) is super easy to follow and makes sense, but we had a hard time breaking things down that far because some elements require more pieces to lay out consistently, etc.

Where we ended up was Atoms as a laundry list of what the building blocks were (in some cases, multiple form controls per "atom", wrapped in list items as part of an ordered list). Molecules and organisms were the re-usable things that appeared in higher order bits.

It was a bit of a struggle for us to not really have "atoms" be tiny bits, but the sheer number of atoms would have made the system unusable if we'd gone that route.

Oh, and apart from the colors setup, we jettisoned all of the "atoms".

[bradfrost]

I like the idea of boilerplates. I was even thinking it would be interesting to create boilerplates for Bootstrap, Foundation, and other popular frameworks just to show that PL is platform/requirement independent.

Re:atoms, in my experience most atoms are there for reference, so teams can view and test their global styles laid out in a list. You could split headings up and include them in molecules and organisms, but I feel like for a lot of cases that's really extreme. For example, starting a new molecule and typing {{> atoms-h1 }} doesn't really add too much value, when instead you can just add a simple <h1> tag.

Where atoms do come in handy to be included are for things like image types. It's massively helpful for design teams to know what image types are being used throughout an experience, and it's helpful for integration teams to know what crops/cuts/sizes/formats their systems need to support. So we have atoms like logo, hero-short, hero-full thumb-large, thumb-small, thumb-square, brand logo, etc that are included in molecules and organisms.

But yeah, for the most part the atoms mostly serve as a reference/style guide.

These types of stories are why I'm so happy with this tool. Because it doesn't jam too many restrictions down your throat you're able to customize it to fit your needs.

[dmolsen]

FWIW, I think the updated starter kit should use vanilla CSS. At the very least, we shouldn't distribute Sass files with it. That's also been confusing.

[aarongustafson]

Agreed. Maybe a boilerplate w/ SASS, Vanilla & Less would be good.

SASS compilation could also be extracted, which would resolve my Grunt issues.

[joshrcook]

I second everything being said here. I think that would make it that much easier to work with from the start. I've seen other tools that have just had a /demo folder, which if you ask me, makes a ton of sense in this case. Just have a pre-compiled demo in that folder.

[jaicab]

A Modernizr-like custom boilerplate generator would be much appreciated. I would love to help with that. I'm trying to integrate Pattern Lab as part of the front-end workflow at my company and although we have a basic boilerplate we feel like there is a need for this.

Checkboxes could determine whether to use Sass / LESS / Vanilla CSS, Grunt and which patterns to include, for example.

[dmolsen]

@jaicab -

I think the current game plan is to rely on a Yeoman generator for that. Some folks put together Yeo+Lab which I think is an interesting solution to this problem. I've already put together a thin edition of PL2 to better serve the Yeo+Lab project. Alternatively, groups could create their own editions of PL2 that included their own StarterKits (example) so they could start projects on the same page. PL2 is a work in progress as I'm still solidifying the plug-in architecture. It works though.

[coxrichuk]

Just to put my cents in ....

We have used PL as a base framework for our complete front-end workflow and found ourselves just stripping out the majority of what was included by default and ended up just including one "demo" pattern per type for anyone new coming to the framework.

This also allows us to reuse commonly used patterns (how many of us continuously reuse the same menu html structure time and time again !).

The boilerplate is then controlled using a mixture of Yeoman, Grunt and Bower.