Multi-source Support and Custom Starter Kits

[pattern-lab]

Multi-source Support and Custom Starter Kits

[umesh-velir]

@dmolsen - wondering if there is a documentation to configure PL, the twig version for multi-site support?

[mikes000]

This pattern for having multiple folders for client projects makes sense to me.

I like the idea of having the core/ custom/ folders as we plan to have a base set of patterns that may be used across multiple projects.

I have an interesting idea floating around in my head... What if there was a global-pattern folder that was accessible by all project folders (wvnano, english..) A pattern could exist inside the global directory, and be used on the wvnano project as well as the english project without existing in the project directory. Changes to this pattern inside the global directory would be reflected on both the wvnano project as well the english project.

If you wanted to overwrite the pattern for the admissions project, You would create the pattern with the same directory and file name inside the admissions project folder and it would override the global pattern on the admissions project.

Pros to this:
Patterns used across multiple projects would be maintained in the same place
If a bug was found with a pattern it the fix would automatically be present in other projects
New global patterns would be available for use in past projects

Some cons to this:
Changes to global patterns may break something unintentionally on another project
If a global pattern is not used in a project does it make sense that its listed in the projects patterns

What do you think?

[patternlab]

I'm a little cautious of the idea of having multiple clients on one build,
mostly for this reason:

Changes to global patterns may break something unintentionally on another

project

This tool is meant to create a tailor-made design system for a specific
project, so I'm not sure if re-use is of utmost importance here. Maybe
keeping a separate pattern folder outside of all projects is the best way
to start with some pre-made patterns?

Another concern I have is managing clients. I get that this would be local,
but I would be afraid one client's work would somehow bleed into another.
Or that they would see the name of another client.

On the other hand, maybe it would be useful for a larger organization with
lots of Web properties (like a university). Dave, is that sort of what you
had in mind?

---

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

On Tue, Nov 19, 2013 at 2:49 PM, Mike Gibbons [email protected]:

This pattern for having multiple folders for client projects makes sense
to me.

I like the idea of having the core/ custom/ folders as we plan to have a
base set of patterns that may be used across multiple projects.

I have an interesting idea floating around in my head... What if there was
a global-pattern folder that was accessible by all project folders (wvnano,
english..) A pattern could exist inside the global directory, and be used
on the wvnano project as well as the english project without existing in
the project directory. Changes to this pattern inside the global directory
would be reflected on both the wvnano project as well the english project.

If you wanted to overwrite the pattern for the admissions project, You
would create the pattern with the same directory and file name inside the
admissions project folder and it would override the global pattern on the
admissions project.

Pros to this:
Patterns used across multiple projects would be maintained in the same
place
If a bug was found with a pattern it the fix would automatically be
present in other projects
New global patterns would be available for use in past projects

Some cons to this:
Changes to global patterns may break something unintentionally on another
project
If a global pattern is not used in a project does it make sense that its
listed in the projects patterns

What do you think?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-28826181
.

[dmolsen]

I think we have two ideas at play here:

1. Multiple clients in one build that use a common core or boilerplate when starting a project (my starting point for this issue)
2. Multiple clients sharing, in "real-time", a common core which can be overridden in specific instances ( @mikes000 idea)

While I'm intrigued by number 2 I think it might be a pre-optimization of Pattern Lab. Part of me wants to do it because I'd rather get a big rewrite, which would be needed to implement the idea, out of the way. At the same time... it's a lot of work for something that, as @bradfrost notes, might backfire. I'd rather let number 2 gel a bit more and see some more use cases before going after it.

At our U we could use number 1. We have a common set of starting files (logo, JS libs, reset CSS). That said, after that initial starting point the designs can and do go in any direction. For good or ill we stay away from an overly common look. Other than a common header I think most of the patterns would end up tweaked at some point. I also think we'd start with a really pared down set of patterns. So in my scenario number 1, it'd be a common starting point but each design would be sandboxed from one another. It would also be easier for us to "upgrade" that single instance (just copy source/ with its multiple projects to the latest download of PL).

I think number 2 is good to keep in mind but I'd rather see some more use of PL and get more feedback before implementing it.

[mikes000]

The benefit that I see to having a common core elements is that a lot of the core atoms and molecules seem like they would be reused across many sites. Building up a repository of reusable molecules would help develop a project quicker.

For example, I was working on three different molecules for pagination today. We plan to try each of them out and see which one functions best on a variety of different devices. After doing this for a few projects we will have a collection of molecules for pagination to try out on future projects.

If there was a shared library for these molecules I would able to just swap them out and try a few different ideas very easily just by changing the name in the template for the current project I am working.

To make this process as seamless as possible, It would require that certain CSS and JS files would need to be associated with an element if it does not function correctly without them. When a global element is used in another project, its additional assets would need to be pulled in and compiled with the other existing CSS and JS files for that specific project. That way the project would only contain code that is required for the elements used in it.

I think its an interesting idea, but I'm not sure if it just makes things too damn confusing... Could I be onto something here, or completely off my rocker?

It might just be easier to have a separate folder with reusable elements inside of it. Then when you want to use them in another project, just copy them stuff you need into the other files and folders.

[dmolsen]

@mikes000 wrote:

Building up a repository of reusable molecules would help develop a project quicker.

I agree. In the short-term I don't think this needs to be a real-time shared repository. The idea of a custom/ with set and tested patterns can fill that need. But I understand the tension that we're facing. It's highlighted here:

To make this process as seamless as possible, It would require that certain CSS and JS files would need to be associated with an element if it does not function correctly without them. When a global element is used in another project, its additional assets would need to be pulled in and compiled with the other existing CSS and JS files for that specific project. That way the project would only contain code that is required for the elements used in it.

At the moment this seems like a rabbit hole. It's almost asking for a pattern plug-in/packaging system. e.g. a pattern has dependencies and make sure they're loaded. For JS and mark-up this isn't a problem. For CSS it very much is. We've chosen not to make a pre-processor a dependency. This means, admittedly after not thinking about it too hard, that including small bits of CSS becomes problematic. Use @include? Literally append it to a plugin.css file? What if load order is important (the whole cascading part)?

At some point I'd love to get to a package manager. It's an idea I played around with early in the project but kept coming back to modularized CSS as an issue. Maybe it's just a matter of picking a CSS convention. A package manager would always have to be a bonus and not necessary to use PL. Maybe adding a requirement to use a convention would also work. Also, I haven't looked at Bower or anything in any depth. Maybe they have the problem licked.

Could I be onto something here, or completely off my rocker?

You're onto something. I know I don't have the complete answer yet. Seriously, thanks for taking the time to write up your thoughts. Keep it coming :)

[dmolsen]

Starter kit support is in dev. Still need to add "multi-site" support.

[dmolsen]

Realized that with the config changes I made multi-site support is already done. Bonus I guess.

[benedfit]

@dmolsen - Do you plan to include the mustache starter kit by default, or will choosing a starter kit become an additional installation step?

[dmolsen]

@benedfit -

If using -g and source/ is empty my default behavior will be to install the Mustache-based demo starter kit. Someone could always fetch another starter kit before using -g.

[benedfit]

Thanks