The example text for vf-text--body-r is "extra regular" and vf-text--body-l is "extra large". Presumably this should just be "regular" and "large"?

@markboulton has reworked the grid system (specifically the embl-grid) so that it has:

• a small initial column
• larger grid-gaps
• the first grid-gap is larger than others
• a smaller sidebar column
• adds (potentially) another embl-grid--variant that has the initial column and three equally sized columns.

I've worked on a quick demo in codepen.

Some questions, thoughts around this:

As found with the initial Cancer landing page I believe the embl-grid also needs to denote the columns with their own naming convention. We have discussed this in #13

Because the grid could also be used for long form article content - the `vf-container__heading' doesn't make sense as a name because the column contains meta information regarding the article (author, date, categories, etc).

I think we're also potentially 'limiting' the vf-container__sidebar with the term too - especially as on smaller devices there is not 'sidebar'.

I propose the column naming convention inside the embl-grid should therefore be:

• vf-container__prime
• vf-container__main
• vf-container__extra

Other things to consider:

We will need to amend the vf-grid and vf-page-grid to use the same generic grid gutter spacing.

Blocks, Containers, Elements, Design System, Components, Visual Framework...

I think it would be a good idea to have a page of terms that explain what they are and what they mean when they're discussed within the Visual Framework.

We will be adopting the branch naming convention previously used:

type/good-name

but we should clarify the type a little better. In the aim to have this documented somewhere.

1. feature - to be used when working on a new component. Is feature the right word here, maybe new-item or something?
2. fix - to be used for ... fixes. Do we want to split this and add hot-fix for things for the master branch?
3. docs - for anything to do with documentation. Content or code.
4. updates - when we update anything - is this a good enough term? What about refactor as that is mainly that updates have been used for.

Are there any more we can think of?

I'm think this pattern:

Would be something that works 'where you put it' on the grid system. So rather than be over specific with something like vf-article-meta-information I have gone for vf-meta-information.

This Issue will be a thread of questions.

To make it a little easier and consistent we should look at adopting some templates for issues and pull requests.

• here's the GitHub blogpost about them
• here's a repo with some examples

As it stands, the grid system has a 16px gap betwixt any columns.

When using the embl-grid it looks (to me) like it's a little tight, considering the space we give the content (vertically) to breath.

Do we need to take another look at the grid-column-gap for the embl grid with header, with sidebar, and with both?

This really needs some design input.

As the version of a pattern can be important, we should show it in the web interface.

I know this is set/incremented by lerna in pacakge.json and I believe Fractal would need a version number stated in the pattern.config.yml...

Options:

• We could manually add version to pattern.config.yml ... tedious and error prone!
• Maybe lerna can update the yml?
• Some sort of post-commit magic?

I know we're not there yet, but we should work out how we're going to depreciate patterns.

1. add a label to the component, for example:

2. look as Sass deprecate

We need to create/replicate the GDPR data protection banner for use across all EMBL sites.

Currently the pattern can be found here.

the existing pattern uses data attributes for the recreating the content using the CSS content selector.

This does not get read by screen readers (VO on MacOS tested), so we need to use 'actual content' moving forward. I don't see this as a problem? A WP plugin(?) could be created for just this thing? For example.

Also from an accessibility (a11y) viewpoint it needs to be near the top of the DOM on page load, so this is something we would need to add to documentation for people who would be implementing this.

1. What does it mean for pattern "deprecation"
2. How to deprecate a pattern
3. Put that documentation somewhere

What:
List out our core user types

Why:

• Reminds us who our users are
• When someone asks "why have you done x?" or "why won't you do x?" this would be helpful
• Informs how we should build vf-core and whatever other repos

As we enter the alpha releases we should start getting wider consensus on the approaches of the VF (note this is seperate from the EMBL brand).

So we should have some kind of governance, documented procedures, and some sort (or advisory group) that provides feedback and buyin, and results in some sort of documentation on:

1. What was agreed
2. Why it was agreed
3. Forever-hold-your-peace

So we need to:

1. Clarify the remit
2. Find some core members (might expand later, better too few than too many)
3. Set up a first date
4. Establish frequency (bi-monthly? quarterly?)

At some point, I thought it was a good idea to add a little padding to the iframe (I think it's mainly because I don't like the border).

Looking at certain patterns - that choice looks completely silly. This should be removed.

package.json includes:

"repository": {
    "type": "git",
    "url": "https://git.VF.de/grp-stratcom/visual-framework-tooling-prototype.git"
  }

Referencing old/unreachable repo.

For the vf-badge pattern, I don't think we need:

.vf-badge--square {
...
  display: inline-block;
..
}

Causes vertical alignment issues and letter the --square inherit display: inline-flex; seems ok, or am I missing why it needs to be inline-block?

We need to make sure we start adding visual regression tests so that we confidently update patch, minor, and breaking changes.

As we will also be hosting a CDN version of the styles.css and scripts.js file that will depend on the file path altering when we make a major version change we need to include VRTs as part of the develop and/or build step(s).

There are several resources for this, both paid and completely open-source. I have used [BackstopJS[(https://garris.github.io/BackstopJS/) previously.

Is this something that can be part of the CI build?

Looking at the landing page sketch file there is a thin, light grey, vertical rule when a container has a sidebar.

This should be some fun pseudo class CSS - as, surprise surprise, CSS Grid does not let you do this easily.

now we've moved to GitHub can we use something like this - https://github.com/github-changelog-generator/github-changelog-generator - and automate the release notes a little more?

UPDATE: Released https://github.com/visual-framework/vf-core/releases/tag/v2.0.0-alpha.1

2018 is ending so it's probably time to cut our first alpha of the VF 2.0. Let's aim to try and get these done by Wednesday (19th) and cut the release on Thursday.

The to-do and wishlist

• Reinstate responsive grid/design
• Clean up documentation in this repo and at http://dev.beta.embl.org/guidelines/visual-framework/ (that's one for @khawkins98)
• Delete any old cluttered branches
• Crack a mini-roadmap for v2.0.0-alpha.2 (#108)

Draft release notes

v2.0.0-alpha.1 overview

Alpha 1 represents the beginning of the end for the exploration of how the VF 2.0 should be built to achieve its aims.

What is the VF 2.0?

A modular, compatible framework for life science websites and services. Need to know more? Read this

What's in the alpha?

As the first alpha has massive amounts of change, we won't present a detailed changelog, but rather some high level notes on where we are and what got us here.

🚨WARNING! 🚨

This is our first alpha and captures the first step on a road ... we still have much to do everywhere ranging from patterns, documentation, guides, technical tooling, governance and so on.

📚History

• Initial conceptual planning of the VF 2.0 began in summer 2017 and we starting writing code in July 2018.
• In November 2018 we moved from the EMBL GitLab server to GitHub for better technical integration and collaboration
• Outreach remains a priority (there's the issue queue on GitHub and Slack)

⚙️Technical improvements

• Visual Framework 2.0 patterns are now available as standalone npm packages
• The pattern library is online
• We have a very developer-oriented README.md available

🖼Visuals

• We've switched the default font from IBM Plex Mono to Sans 👀
• Tools for spacing and the default look of things is much better
• Responsive design is back
• The look of the VF is very "EMBL" out of the box, this will change over time as the VF is separate from any one brand

📒Documentation

• We're still working on a quick start to building sites with the VF (but there are boilerplate pages available)
• We're working on a guide for integrating VF 2.0 patterns in your code base -- as either a ground-up nw framework built with VF patterns, or integrating just one or two patterns from the VF

👉See a full list of issues and branches in the alpha.1 milestone

What's next?

• A lot of documentation, howtos, and outreach
• More patterns
• Optimisations
• EMBL.org specific tooling
• Divide the vf-core look from vf-embl
• See the Alpha 2 roadmap

Release to-do script

1. Finish up outstanding ticket/tasks for alpha 1
2. Do release notes
3. Push to npm (lerna)
4. Merge to master
5. Tag release on master

A slot is a full-width component that:

• can either be at the top or bottom of a page.
• can be permanent or removable.
• can include text, a link, an inline link (a link within text), and buttons.
• content is centred within the grid system.
• text is left aligned with buttons right aligned.

Standard questions

• In a few words, what does this pattern look like?
  A coloured bar with text, link, buttons at the top or bottom of the page.

• In a few words, what does this pattern do?
  It relays information regarding the page and/or website. This message can either be permanent or dismissible.

• Can other websites use this pattern? Or is it only useful in your organisation or website?
  Yes

• Do you have any designs or concepts?
  We already have this in place as the data protection banner

• Have you done any user testing already?
  no

• How often do you expect to make use of this pattern?
  This will be used for the data protection banner (as it is now) but also for permanent messages - like 'this page is an alpha'

• Can you list out major elements in this pattern?
  text,
  link,
  button

• Will all elements of this pattern be used every time?
  the buttons would only be used if it's a dismissible component.

• Does this pattern contain other patterns?
  vf-data-protection-banner,

Somehow we lost the code that use the CDN on deploy, need to bring it back.

We still have yet to come up with our approach to supporting React, Angular, [insert framework here].

There's probably some inspiration to be had from IBM's Carbon: https://next.carbondesignsystem.com/getting-started/developers/other-frameworks

Will the Carbon Design System support other frameworks in future?

We are open to the idea of providing core support for additional frameworks in future. We added Angular support in the summer of 2018.

For the Carbon Design System to incorporate additional frameworks into our core offering, those frameworks need clear, guaranteed, ongoing resources to maintain and support that option. If a team built a product using a Carbon version of Vue.js, for example, but had no plan to support that solution outside of their product, that couldn’t become a core part of the Carbon Design System.

After some initial research, thinking, and reflecting on what services are asking of us. Maybe the best approach will be to:

1. Support Vanilla JS very well
2. Offer guidance and demos on integrating VF patterns with Framework X
3. As we get support+time commitments nominate maintainers for, say, the "VF 2.0 Angular edition"
4. Perhaps some specific Angular or React support for critical EMBL JS-powered patterns (Data Protection banner, announcements, etc.)

☝️ That thinking loops me back into focusing on two big priorities:

1. Make a VF 2.0 that doesn't break other code (we're doing this well so far)
2. Offer strong guidance on how things should look/behave/feel

What's next?

1. Explore the above ideas
2. Get feedback from the to-be-created VF Working Group (a separate thing from any EMBL brand group) See: #114

steps taken to get to this:

git fetch origin
git reset --hard origin/develop
npm prune
npm install
gulp dev

navigate to the vf-summary pattern

expected behaviour:

clicking on a variant shows that variant
clicking on a resource tab shows that file

neither work

For EMBL, we have a who-what-where concept that we can use to template the logic for the navigation in the masthead and breadcrumbs, and enable cross-silo exploration.

A lot of this is still in my head and has been explored with many in the Comms team in separate conversations ... so a task for me to put together some functional code to explore this.

In bullets:

1. Use meta-properties to describe pages
   • the embl-content-meta-properties pattern
2. Meta properties come from our taxonomies
   • done(ish)
3. Those taxonomies are linked in a who-what-where ontology
   • done(ish)
4. On pages specify the primary taxonomy in use
   • a PR coming for the embl-content-meta-properties pattern
5. Derive primary navigation ancestors (breadcrumbs)
   • a new embl-meta-breadcrumbs(?) pattern
   • this would also apply to the vf-masthead, but that could wait for the next alpha of the pattern
6. Derive secondary navigation paths
   • part of the embl-meta-breadcrumbs pattern

Following up on some issues with tabs (#123) it raises a question about how much JS we should be writing... is there some sort of lightweight framework that can do things like tabs for us?

Here's what we'd need:

• Something flexible enough that we could use our class names
• Non-opinionated enough that it won't feel alien as we add our own JS
• A wide set of common js stuff ... tabs, modals, dialouges, etc.
• Open licence
• IE 11 support
• Smallish ... less than 20KB?

Taking a look at the landing page demo we can see that the intended vf-body class is not on the <body> element.

At the moment there are a few things that rely on this (vf-global-header) for one.

Because of this - there's two options

1. As we cannot rely on it being on the body, remove it and adjust the vf-grid and embl-grid accordingly

2. Make it a requirement that the <body> has a vf-body class tacked on to it.

3. Do something else.

Picking back up on issue #28 ("Do we publish patterns independently or as part of one big release?") which went a bit sprawling.

I think we've agreed that the patterns and vf-core can be published independently, so now the main question is how do we version the two aspects?

The status quo of versioning:

1. [email protected] the "build environment" for the pattern library, gulp and sass config follows largely semantic versioning from a v2.0.0 start.
2. [email protected] the patterns being incremented from v0.0.0 with the intention of semantic versioning.
3. [email protected] For users rolling custom look/feel there will probably be some started template like this based off a trimmed version of vf-core and should probably follow the vf-core versioning ... [email protected] is based off [email protected]
4. 🙃Bonus note: while patterns are their own thing/version on npm, vf-core patterns (there hopefully will be popular 3rd party ones from other repos) will be baked into the newest release ... [email protected] will only appear on the next release, say, [email protected]. This should be a non-issue as people won't be intended to clone the vf-core repo, rather to clone vf-child-theme-template and then pick whichever pattern+version from npm.

How will things be?

A table to illustrate where we're thinking/at:

Questions and user stories we need to satisfy

1. Will certain patterns be compatible with certain version of the build environment vf-core? For example if in, say, [email protected] we:
   • add a new required variant option to patterns' .config.yml?
   • change the sass compiler to add/remove certain options?

If patterns are based off v0.0.0 then they would need to note any compatibility issues, a la:

• [email protected] is compatible with [email protected]
• [email protected] requires vf-core@^2.1.x

2. Interoperability between patterns

• [email protected] requires pattern vf-pattern-y@^8.1.0

To me, I'm not seeing a hard reason why we can't go with the above, de-coupling of pattern version from vf-core versions.

Through several discussions via slack, zoom, etc we discusses changing the terms of the embl-grid as well as the sections available in a container.

A container is one (of many) vertical 'strip(s)' of a page.

It can have a header, main, and aside section.

So we would rename the grid options as follows:

embl-grid--with-label == embl-grid--with-header
embl-grid--with-sidebar == embl-grid--with-aside
embl-grid--labeled-with-sidebar == embl-grid--with-header-and-aside

This then has three 'sub containers' within a container to easily position things on the grid.

vf-container__header
vf-container__main
vf-container__aside

In full we would have mark up like this:

<section class="vf-container vf-news-container | embl-grid embl-grid--with-header-and-aside">
  <div class="vf-container__header"></div>
  <div class="vf-container__main"></div>
  <div class="vf-container__aside"></div>
</section>

Fractal allows you to pick and choose if you want to hide folders and things that have a .config.yml file by having a hidden: true/false in the frontend matter of the .yml

Since changing templates - this is no longer working.

Now that we've begun to implement the vf-data-protection-banner, it surfaces some thoughts that will be common across many types of messages on sites:

1. Methods to show site wide messages in a "vf-site-messaging" container
2. Check if a message is displayed/should be displayed
3. Show local site messages and/or remote messages (EMBL specific sub-pattern?)
4. Handled message priority (notice | alert | warning | action-required)
5. Cookie management
6. Mechanisms for local sites to override any/all

Each of those might be sub-tickets...

The <hr class="vf-divider"> looks too dark, this could be because it is 2px high.

It also not 100% wide of it's containing box. This looks wrong when used, for example:

http://dev.beta.embl.org/cancer/

The idea is to put all components on npm as their own little npm package.

This way users of the VF can pick and choose what to install rather than the whole kitchen sink.

To get the ball rolling I am unsure if we really need every component on NPM?

We would need the basics: the Sass variables, maps, functions, mixins as well as Elements as they're needed for blocks and containers...

But do we need all blocks and containers?

What would be a good, small set of components to start adding to test the water of this?

• Sass code
• Elements
• Factoid?
• Data Protection Banner?
• Anything else?

Fractal is great at allowing many ways to expose variants to the component library.

We are currently creating a separate .hbs for any variants and, when applicable, setting the collation to true in the overarching config.yml file for the component.

For something like buttons (everything starts with buttons) it would be better to continue with what we have done with buttons.

1. create all the variants as separate .hbs files.
2. set collated: true in the config.yml file.
3. create a buttons-example.hbs file.
4. set all variants and default to hidden: true except for - name: examples in the `config.yml file.
5. within the component-examples.hbs make use of {{render '@component'}} for each variant.
6. make use of existing components to create a better representation of all the variants.

This allows us to create a better designed 'list' of the variants. Adding 'inline' documentation where needed rather than leaving it possibly missed in the README.md which lies underneath the iframe.

We will be making use of Lerna to help publish the components of the visual framework to NPM.

One decision that needs making...

Do we allow each component to be published independently?
ie: if we update the buttons we can push the new version of that package up with it's version bump

Or do we publish the component library as a whole(fixed)?
ie: if we update the buttons we push a version bump to all packages.

A part from 'hot fixes', would it be better for our audience to 'schedule' releases (in time) which means a 'publishing as a whole' would work better?

Another idea is we could start with indepentently (as we're in alpha) and move to fixed when the VF is at Beta or live?

As dicussed in #126 (review)

The js for vf-tabs will generate an error if matching html isn't found:

The code (vf-tabs.js#L5)

  const tablist = tabbed.querySelector('.vf-tabs__list');

Can result it (when no tab pattern is present):

  Uncaught TypeError: Cannot read property 'querySelector' of null

You can see it anywhere the script.js is being used.

I'm not quite sure the best way to deal with exiting when no content found, but probably something like:

(function() {
  // Get relevant elements and collections
  const tabbed = document.querySelector('.vf-tabs');
  const tabbedContent = document.querySelector('.vf-tabs-content');
  if (tabbed === null || tabbedContent === null) { 
    console.log('tabs or content not found');  // we probably need a vfIfDebugOn?
    return;
  }
  const tablist = tabbed.querySelector('.vf-tabs__list');
  const tabs = tablist.querySelectorAll('.vf-tabs__link');
  ...

At the moment the vf-tags pattern is all in one .hbs file. We need to:

• make sure that the content of the tag is using data from the config.yml file.
• separate the variants to separate .hbs files
• create a vf-tags--examples.hbs file similar to the vf-buttons-examples.hbs file

Draft release notes

v2.0.0-alpha.2 overview

One month after alpha.1, alpha.2 is here and brings new features, patterns, more documentation, fixes, optimisations and more, on a relatively settled architecture.

As the second alpha has much change (though far less than alpha.1), we won't present a detailed changelog, but rather some high level notes on where we are and what got us here.

• What is the VF 2.0? A modular, compatible framework for life science websites and services. Need to know more? Read this

📚History

• Initial conceptual planning of the VF 2.0 began in summer 2017 and we starting writing code in July 2018.
• There are few (if any) major architecture changes and small refinements to make the directory structure more consistent (#145).
• Outreach remains a priority (there's the issue queue on GitHub and Slack)

⚙️Technical improvements

• Approach for JS Framework support #115
• The folder structure has been simplified #145
• More EMBL.org specific tooling, include EMBL Breadcrumbs and ContentHub imports
• The pattern library is now also available on GitHub pages in addition to the beta.embl.org URL. In alpha.3 we expect to have a better approach for where global and local patterns show
• You set the pattern library name and prefix in through package.json in vfConfig
• CSS stats are available on Wallace (updated with each commit to dev)
• Multiple tabs are now supported #123
• SVGs are automatically optimised #140
• Margins on the mixin set-type are now more flexible #141
• An alpha vf-child-template is now available
• The vf-banner pattern is much improved and allows more modular control of look, JS dismissal and cookie-based hiding of seen messages

📒Documentation

• The README.md has been greatly improved to make getting started easier
• Guidance on how to use and write VF JS
• Compiled CSS is available for each pattern

🥙All the things

👉See a full list of issues and branches in the alpha.2 milestone

What's next?

Alpha release are planned for the last Thursday of each month.

• Further work on the vf-child-template
• Finalising versioning approach for patterns #119
• Further separation of patterns by 'ownership' #179
• More patterns, including and EMBL notification system #169
• Further work on "blog" type patterns and the nested vf-inlay pattern
• Further directory structure optimisations #170 #128
• Visual regression testing #31
• List core audiences/user types #127
• VF Working Group #114
• A lot of documentation, howtos, and outreach

🗂 See all issues tagged for alpha.3

Release to-do script

1. Finish up outstanding ticket/tasks
2. Do release notes
3. Push to npm (lerna)
4. Merge develop to master
5. Tag release on master

Currently the max-width is 80em it needs to be 81.25 with additional 16px grid-gap

This also means we need to remove the left and right grid items on displays that are ???px and below so that we don't get left and right padding being, effectively, double.

At the moment most, if not all, patterns have 'hard coded' content/data into the patterns .hbs file.

To make it easier for developers using the visual framework it would be better to move any of this content/data to the .yml file that each component has.

• remove all 'hard coded' content/data from patterns and put it into data
• make use of {{> '@component'}} rather than {{render '@component'}}
• add documentation about how to add content/data for a pattern within a pattern

questions:

do we want to start making use of any handlebars sugar for {{each}} for anything like lists?

Now that we're planning regular release we should:

• Switch the default branch back to master
• Deploy all commits on develop to dev.assets.emblstatic.net/vf/
• Deploy all commits on master to assets.emblstatic.net/vf/
• Deploy all tags on master to assets.emblstatic.net/vf/{tag}
  • e.g. assets.emblstatic.net/vf/v2.0.0-alpha.1

This was already partly discussed in #28

Add a one sentence summary of what it is you need it to do.
[An image gallery that shows one large image+caption, and thumbnails of more images. Clicking any image starts a slideshow]

Standard questions

• In a few words, what does this pattern look like?
  [An image gallery with big impact]

• In a few words, what does this pattern do?
  [Allows users to browse images, possibly clicking on links]

• Would a rebrand change the structure or layout of this pattern?
  [Possibly we could move from one main image to a grid of images]

• Can other websites use this pattern? Or is it only useful in your organisation or website?
  [Others could use]

• Do you have any designs or concepts?
  [yes, they're attached]

• Have you done any user testing already?
  [no]

• How often do you expect to make use of this pattern?
  [fairly often, not on every page, but we expect many EMBL teams and some news articles could use this]

• Can you list out major elements in this pattern?
  [main image, caption+links, credit+link, thumbnails, lightbox and navigation elements]

• Will all elements of this pattern be used every time?
  [Generally yes]

• Does this pattern contain other patterns?
  [vf-credit, vf-caption]

Any further thoughts?

When there is a vertical group of job descriptions there needs to be some vertical spacing between each post.

So far we have used z-index in three places:

vf-form__input
vf-masthead
vf-data-protecion-banner

These are based on my novel way of using z-index but I think we should move towards something that makes use of Sass, it's variables, functions, and maps.

Something like this

So that we call the z-index with a function that references the map of variables.

I guess for now, we only need to look at the ones we currently have, and we can add and adapt as the component library fills out a little more.

Thoughts?

Would be good if we can increase the width of the pattern library's pattern preview area to be [--- full width --] and escape the grid and pinch of the sidebar.

I'll work up a PR and some screenshots.

Add a one sentence summary of what it is you need it to do.
[An image gallery that shows one large image+caption, and thumbnails of more images. Clicking any image starts a slideshow]

Standard questions

• In a few words, what does this pattern look like?
  [An image gallery with big impact]

• In a few words, what does this pattern do?
  [Allows users to browse images, possibly clicking on links]

• Would a rebrand change the structure or layout of this pattern?
  [Possibly we could move from one main image to a grid of images]

• Can other websites use this pattern? Or is it only useful in your organisation or website?
  [Others could use]

• Do you have any designs or concepts?
  [yes, they're attached]

• Have you done any user testing already?
  [no]

• How often do you expect to make use of this pattern?
  [fairly often, not on every page, but we expect many EMBL teams and some news articles could use this]

• Can you list out major elements in this pattern?
  [main image, caption+links, credit+link, thumbnails, lightbox and navigation elements]

• Will all elements of this pattern be used every time?
  [Generally yes]

• Does this pattern contain other patterns?
  [vf-credit, vf-caption]

Any further thoughts?

In the code we have quite a bit of // @if $global-font-family != $vf-typography--monospace { logic that we've stopped using.

I think there are two paths:

1. Put it back in action:
   • The idea of some kind of global mono/sans split is still useful valid so we should figure out how to get it working again
     B) Remove it:
   • Sans/mono swapping just has too many edge cases and when a font is changed the Design Tokens should be updated

Thoughts?

This should help with onboarding and just be useful in general. Probably for the README.md.

Probably we'd want to use tree, here's a command I got to in a few minutes:

• tree -L 2 . -I 'node_modules|cache|test_*|.git|.github|bin' -a

Which gives (+some manual annotation)

Filesystem notes

├── .editorconfig
├── CHANGELOG.md
├── CONTRIBUTING.md
├── README.md
├── SETTINGUP.md
├── assets  (your global Sass assembly file)
│   └── scss 
├── build  (dynamic folder used for rendering of static pattern library)
├── components  (all the components you wish to use)
│   ├── _previews (templates for the web pattern browser)
│   ├── vf-activity-group
...
│   └── vf-video-teaser
├── docs (documentation files for the web interface)
│   ├── changelog
│   └── guidelines
├── fractal.js (configuration for the web pattern library)
├── gulpfile.js
├── lerna.json 
├── package.json
├── public  (dynamic folder used for rendering of global CSS, JS, pattern assets)
└── tools 
    ├── component-generator (make new components)
    ├── css-generator (build requirement)
    ├── frctl-mandelbrot-embl-subtheme  (embl web interface)
    └── frctl-mandelbrot-vf-subtheme ( vanilla web interface)

☝️ this is probably less important for the vf-core and more so for the child theme template.