nerdstein / nerdstein-design-library Goto Github PK

I would use a font like Open Sans or Roboto as your heading fonts, the SansSerif matches your logo nicely :)

Check that all colors meet color contrast
Hover state of links, #18af72, is not an accessible color.

Atom: Most Used Tags Header

Molecule: Tag Cloud

Accepts both a color and a text

Content inside of a sidebar

The Narrow Font used on the Posts Listing is a bit hard to read, especially given the small Font Size.

I have the following observations from trying to get the recent commits into Drupal.

The header tag is generated twice in the page source. It should only be generate once.

Drupal uses an id="page-wrapper", not a class="page-wrapper". And, this is a parent of the header tag, not after it. We need to use the ID, not the class.

Right after the closing header tag, there is a div tag with a section. This should be eliminated as the div with id="main-wrapper" should be the wrapper of "all the things" below the header.

After the markup is cleaned up, please verify the CSS still looks right.

Atom: footer text

With styles (black bg and orange top border)

This is my first look at a pattern lab project, so I may be in over my head. Thanks to the readme I believe I am up and running, but not clear on what I should expect next.

Here is what I'm doing:

• I have gulp watching & compiling sass.
• I have the pattern lab server running.
• When I make changes to a pattern, I run php core/console --generate manually to regenerate the pattern lab
• My changes appear on the pattern lab server.

My question is: Should I be expecting the changes to also re-generate the prototype?

Maybe this is a fundamental misunderstanding of the pattern lab workflow. I'm not clear on how to go from "my change looks good in the pattern", to "replicate that change in the prototype". Should this be a manual recreation of the changes in files/css/style.css?

Thanks

Orange bar on sidebar section

The pseudo pattern named list-element~1.json is causing this php notice during pattern lab's generation/compilation due to its filename.

Hey Adam:

I spun up my fork of this repo and immediately ran into tweaks I wanted to make to the documentation which led me to a number of questions:

1. Should we exclude the html directory since it's the target of so much generation. Every time we generate new patterns, the process will make deletes, additions or modifications to that directory.
2. Why is the root level composer.json needed?
3. At first generation a lot of images are deleted, is that mistake?
4. When you first run composer install in the design-library you are prompted to merge or replace for three folders, can we default to Merge and not prompt the user? Require them to provide an argument?

Atom: logo
Atom: social media

gray background

Assortment of tags with various colors and text

😱

Combines sidebar section title and sidebar section content atoms

Rather than require the developer to run multiple commands, let's simplify this into a single gulp task that combines the following steps, and improves them by leveraging "watch" techniques where possible:

1. gulp sass
2. php core/console --server
3. php core/console --generate

An immediate improvement is to combine 2 & 3 into php core/console --server --with-watch.

Another improvement would be to change 1 to suggest the default gulp task which leverages the already-existing "watch" task: gulp

Resulting in:

1. gulp
2. php core/console --server --with-watch

This can be combined further by using the gulp-shell module, and creating a new gulp task that starts the pattern lab server as part of the default gulp task, resulting in a single command of gulp to handle all of the above.

I would add a label to those items, and give them their own place to live on the page, they seem to be floating now.

Two ways to approach it, one is to add a background color entirely, the second is to just add a horizontal rule under the tags.

I mocked up a sample with a bg behind them:

The Color Contrast of the Social Media Icons against the Blue Background of the Sidebar makes it difficult to view/look at/whatever...

Posted on date field in list item

One orange tag on the homepage listing above the blog post list element

I would have this FIXED, so it doesn't scroll, your logo and menu and all those items will always be visible when scrolling on the right side of your content.

I would take the logo out of the white box, and put the menu in a hamburger menu, and the search as just a search icon. I lined those icons horizontally centered with your tag bar on the right.

Here's a mockup of what that would look like, and what each state could look like:

I opted to add a link color in the sidebar, #bfcee2, to give a subtle cue as to what is deemed regular text (which would appear in white) and what a clickable state is (that appears in the light blue color). I'd hover to white if you choose to use this state.

My other question is, what is the difference between posts, and the feed that is in the main content area? If they are pulling from the same content, are the ones in the sidebar "featured"? If so label it "featured posts". If they are the same content, I would eliminate it from the sidebar, and just put the main menu on the page over there, instead of collapsing it on desktop.

For ease of scanning, I would display the image to the right if it has one, that way it doesn't interrupt the flow of heading reading if the image is there:

The npm library being used to start the PL server & export files has been blacklisted for using anti-patterns:
Blacklist: https://github.com/gulpjs/plugins/blob/master/src/blackList.json
Issue: sun-zheng-an/gulp-shell#55

Fwiw the author doesn't agree with this:
gulpjs/gulp#1353
sun-zheng-an/gulp-shell#82

I am testing this to replace the task, but my gulpfile is outside of the PL directory. Will submit a PR once I fine-tune how it works and change it to work from within the PL directory:

gulp.task('start-server', function() {
  var options = {
    continueOnError: false, // default = false, true means don't emit error event
    pipeStdout: false, // default = false, true means stdout is written to file.contents
  };
  var reportOptions = {
    err: true, // default = true, false means don't write err
    stderr: true, // default = true, false means don't write stderr
    stdout: true // default = true, false means don't write stdout
  };
  return gulp.src('./design-library')
    .pipe(exec('cd <%= file.path %> && php core/console --server --with-watch', options))
    .pipe(exec.reporter(reportOptions));
});

I got this from the gulp-exec readme and I'm still trying to figure out how to log the patternlab console messages that tell you that the server has been started and the localhost url to open.
Gulp docs: https://github.com/gulpjs/gulp/blob/4.0/docs/recipes/running-shell-commands.md
Gulp exec docs: https://github.com/robrich/gulp-exec

Two variants:

1. One tag
2. More than one tag

Should have the underline

I propose that we change all the individual patterns' .scss files to partials (e.g., from filename.scss to _filename.scss), so that they can be included as part of a traditional Sass file structure, inheriting variables and mixins from a set of Sass partials outside of the _patterns directory. This allows us to use Sass in a more efficient way -- partials are aware of the whole ecosystem, and can make use of global variables.

I also propose starting to conform to US Design Standards (fonts, colors, etc.), and using local placeholder images.