A streamlined tool for developing, documenting and presenting UI pattern libraries.
Home Page: https://cloudfour.com/thinks/introducing-drizzle/
License: MIT License
A streamlined tool for developing, documenting and presenting UI pattern libraries.
npm start
Latest version is 0.2.0.
If history repeats itself, our patterns will tend to fall into a structure similar to this:
src/patterns/ (includes collections)
├─ components/ (includes collections)
│ ├─ button/ (includes patterns)
│ ├─ dropdown/ (includes patterns)
│ └─ grid/ (includes patterns)
└─ typography/ (includes patterns)
Currently, there does not appear to be a concise way of building that entire nav tree in the desired order without marking up top-level and deeper pattern groups separately, like so:
I'd love if there were a better way of doing this, either a way of looping over all the collections and telling when a parent had started, or some special nav-specific group to loop through that separated stuff out. I dunno, it just seems weird the way it currently is. Maybe it's just me! ¯_(ツ)_/¯
Apologies if this is specific to cloudfour.com-patterns (happy to close this issue if so), but I've been encountering behavior I don't really expect.
If I create a pattern called foo-bar.hbs, my expectation is that it's default name (if I fail to provide one) will be "Foo Bar." I'd say about 50 - 75% of the time, replacing - with and capitalizing each word in the result will give the desiredname.
But currently, if I fail to provide a name, it won't output any heading at all. 😕
Create and add 'em.
For example,
src/patterns/foo has two patterns, both of which should be hidden.
Adding a collection.yaml to this directory with the contents of hidden: true should make the Foo collection hidden from iterators, etc.
Currently, attempting to do this results in an error with the builder:
[10:45:18] Starting 'drizzle'...
[10:45:18] Starting 'css:drizzle'...
[10:45:18] Starting 'css:toolkit'...
[10:45:18] Starting 'js'...
[10:45:19] Starting 'assets'...
[10:45:21] Finished 'css:drizzle' after 2.6 s
[10:45:22] 'drizzle' errored after 3.8 s
[10:45:22] Error
at Error.DrizzleError (/Users/aileen/Desktop/jedec/node_modules/drizzle-builder/dist/utils/error.js:9:16)
at Function.DrizzleError.error (/Users/aileen/Desktop/jedec/node_modules/drizzle-builder/dist/utils/error.js:26:13)
at /Users/aileen/Desktop/jedec/node_modules/drizzle-builder/dist/parse/patterns.js:242:27
[10:45:24] Finished 'js' after 5.14 s
[10:45:24] gulp-imagemin: Minified 0 images
[10:45:24] Finished 'css:toolkit' after 5.41 s
[10:45:24] Finished 'assets' after 5.36 s
/CC @aileenjeffries @mrgerardorodriguez
Or maybe a Drizzle logo? ¯_(ツ)_/¯
This applies mostly to https://github.com/cloudfour/core-gulp-tasks, but it would be nice to get descriptions with gulp --tasks.
Things noticed recently:
</a> within a lines of text
I am really excited to check out your project! However, when running npm start or npm install it bombs out when trying to install the @cloudfour/gulp-tasks and @cloudfour/hbs-helpers modules because of an invalid module name.
npm ERR! Darwin 15.4.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "i"
npm ERR! node v5.6.0
npm ERR! npm v3.6.0
npm ERR! Invalid name: "@cloudfour/hbs-helpers"
I am using a Mac Mini (late 2014) on OS X 10.11.4 I also tried installing using node v4.0.0 with the same problem.
Am I the only one running into this issue?
Currently, these are in the generator. It makes more sense to bundle them into this repository.
It'd be nice to be able to link to a specific pattern heading on a collections page using a # hash URL.
One issue we've experienced a few times is a hesitance from collaborators to use our environment because the Terminal can be scary when you aren't used to it.
I mentioned this idea in #31, but having seen that Electron reached v1.0.0 today, I thought I should document the idea of creating some sort of Drizzle app that might simplify the process for clients and skittish collaborators.
No idea if this is even possible (or worth pursuing), but I'm thinking the app might consist of:
If the page "Overview" is at index.html, navigating to /index.html will highlight it in the nav (applying the .is-active class), whereas navigating to / will not.
Related: #3
We need a publicly-accessible demo! 😃
This could be a Netlify site, or we could use something like gulp-gh-pages to use GitHub pages.
I was reminded of this by this Smashing post that @megnotarte shared. Specifically:
One way to display the output better is by using a project hub — one central place with all the important assets all collected in one place, sorted chronologically, and always up to date. As a result, the client can come to the site at any time and see the progress right away.
Right now, our "Overview" page is pretty useless. It gives a partially redundant introduction to the platform, repeats the navigational elements, and sometimes dumps the color palette there. I think there's an opportunity to treat the introductory piece more as a "hub" than it is currently.
Food for thought! 🍔
The typographic specimens are awesome. But I also need this sorta stuff on most (if not all) projects:
It'd be pretty great to have some of that included and ready to go, even/especially if it just gets edited to suit project needs. It might also help demonstrate that the data/ folder can incorporate as many files as one might like.
Right now, many of the Drizzle CSS components rely on custom properties like --color-blue. It would be nice if these all relied on a small selection of base variables to make customization of the style even simpler.
After have run the simple npm start and installed all packages, and then added a new component file, i try to build the project, when running npm run build i get and npm error:
> [email protected] build /Users/larsfalcon/Downloads/drizzle-master
> npm prestart && gulp
Usage: npm <command>
where <command> is one of:
access, add-user, adduser, apihelp, author, bin, bugs, c,
cache, completion, config, ddp, dedupe, deprecate, dist-tag,
dist-tags, docs, edit, explore, faq, find, find-dupes, get,
help, help-search, home, i, info, init, install, issues, la,
link, list, ll, ln, login, logout, ls, outdated, owner,
pack, ping, prefix, prune, publish, r, rb, rebuild, remove,
repo, restart, rm, root, run-script, s, se, search, set,
show, shrinkwrap, star, stars, start, stop, t, tag, team,
test, tst, un, uninstall, unlink, unpublish, unstar, up,
update, upgrade, v, verison, version, view, whoami
npm <cmd> -h quick help on <cmd>
npm -l display full usage info
npm faq commonly asked questions
npm help <term> search for help on <term>
npm help npm involved overview
Specify configs in the ini-formatted file:
/Users/larsfalcon/.npmrc
or on the command line via: npm <command> --key value
Config info can be viewed via: npm help config
[email protected] /Users/larsfalcon/.nvm/versions/node/v4.0.0/lib/node_modules/npm
npm ERR! Darwin 15.3.0
npm ERR! argv "/Users/larsfalcon/.nvm/versions/node/v4.0.0/bin/node" "/Users/larsfalcon/.nvm/versions/node/v4.0.0/bin/npm" "run" "build"
npm ERR! node v4.0.0
npm ERR! npm v2.14.2
npm ERR! code ELIFECYCLE
npm ERR! [email protected] build: `npm prestart && gulp`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script 'npm prestart && gulp'.
npm ERR! This is most likely a problem with the drizzle package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! npm prestart && gulp
npm ERR! You can get their info via:
npm ERR! npm owner ls drizzle
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /Users/larsfalcon/Downloads/drizzle-master/npm-debug.log
But running the npm prestart runs the npm install fine and calling the npm start calles the gulp --dev it starts up the server with the correct stuff inside :)
Im creating a easy fix for this guys! Other than that this Drizzle thing looks cool
This is a follow-up to my misguided cloudfour/drizzle-builder#81 issue.
The current blank.hbs layout looks like this:
The trouble is that if you want to extend this template and append things to body like so:
It will not work. This appears to be because the body block is nested within the wrapper block.
My feeling is that we should restructure blank.hbs so there's more consistency between the HTML class, body class, head and what are essentially "foot" assets:
This would allow us to specify bodyclass the same way as htmlclass, and we could pass along <script> elements and other resources with {{#content "foot"}}{{/content}}. But there may be other ways to pull this off!
@mrgerardorodriguez @erikjung
Re: cloudfour/core-hbs-helpers#40, cloudfour/core-gulp-tasks#46
devDependencies to replace helpers packagedevDependencies to replace tasks packageCurrently, creating new toolkit scripts requires you to create a new file, then add a somewhat redundant item to config.js:
'drizzle/scripts/drizzle': './src/assets/drizzle/scripts/drizzle.js',
'toolkit/scripts/toolkit': './src/assets/toolkit/scripts/toolkit.js',
'drizzle/scripts/some-page': './src/assets/toolkit/scripts/some-page.js'
It seems like this could be simplified, at least so that the toolkit/scripts directory doesn't need a new entry for every single root JS package. But I might be missing something.
If you attempt to run this repo on Windows, you'll get complaints about missing partials (specifically drizzle.swatch for me). Possibly something unix-centric about the way partial paths are generated?
Probably my fault. 😅
The blue highlight should rest against the edge of the viewport here:
Sometimes we may want to add a class like u-spaceChildren or u-rhythm to the example output w/o adding additional markup to the source preview. Other times, it's better to keep things simple. It would be nice if we could specify classes via pattern frontmatter and have them appended to the pattern container.
Currently these pages tend to bleed together. Can we make them more distinct? Could we auto-generate preview thumbnails? Lots of opportunities to make these real nice. 👌 😉
@tylersticka made a great suggestion in this conversation:
(I actually wish
wrapperwere namedbodyandbodywere namedmain. But I'm pretty sure that change is too low-level to prioritize now.)
This will include updates to drizzle-builder.
There seems to be no way of adding a new folder or using other folder names aside from 'Components' and 'Elements'. I tried changing the folder names to 'Atoms', 'Modules', 'Organsims', re-run gulp --dev but sidebar still shows 'Components' and 'Elements' at the side.
It's not always clear where one pattern starts and another stops. The <hr> may be too subtle... we should experiment with rules and whitespace.
We should totally have these! :)
Awesome work Cloud Four team 👏
Thought I'd toss out a question I receive a lot when using Fabricator - I'm often asked if there is a way to easily bridge the gap between Fabricator and a back-end system. I designed Fabricator to be agnostic of whatever system it might be integrated into, but often its used as an initial phase of development for a single site, not a suite of sites that use a shared design system.
Many teams want to reduce the wasted effort that comes with maintaining two separate projects. When a pattern is updated in Fabricator, they want the corresponding pattern in their .NET, Java, PHP, etc project to be updated as well. It becomes burdensome to make a change in Fabricator, then make the same exact change in the integrated code.
Have you heard the same? Any ideas on how to solve the issue?
Maybe it's a good idea to add in Modular Scale to the boiler plate?
The only two projects that use Drizzle so far have both restored the color swatches. That suggests to me that we should consider adding them back.
I'd like if we abandoned the design we inherited from Fabricator. Some ideas for improvement might be:
Food for thought! 🍔
<ul> currently).Comment on Drizzle blog post:
The ‘e’ in Drizzle is cut off in the svg.
http://blog.cloudfour.com/introducing-drizzle/comment-page-1/#comment-235006
From @tylersticka:
I'm guessing based on his email that this problem is symptomatic on Linux.
Hey Folks!
The name and order properties inside of collection patterns seem to be working great, however note isn't rendering anything for me. I saw that this was defined in the example, so I figured it was possible.
We need more. 😁
If {{title}} is undefined, we should use the current collection title, or fall back to the project title. It might also be nice to have the project name appended to the title anyway.
"Drizzle" represents the project name...
<!-- If {{title}} is defined: -->
<title>Overview - Drizzle</title>
<!-- Else if collection title is defined: -->
<title>Button - Drizzle</title>
<!-- Else: -->
<title>Drizzle</title>Original issue: cloudfour/drizzle-builder#63
dest paths for pages, patterns, etc. all assume a common root folder (e.g. ./dist)I know, I know, I've already talked a ton about this in cloudfour/drizzle-builder#31. But it's still not working the way I'd like it to, and I thought I'd document that (even if it has to wait for a future version to be resolved).
Here's a hypothetical collection of patterns:
- disabled.hbs
- group.hbs
- overview.hbs
- style-variations.hbs
By default, these will show up in the same order as above... whatever the file system determines "alphabetical" means for these files.
Let's say I want "Overview" to be the first pattern. Currently, that's really easy. I just add the property to my Frontmatter:
And the order changes:
1 overview.hbs
- disabled.hbs
- group.hbs
- style-variations.hbs
Simple.
But what if I want a pattern to sort to the end?
For example, maybe the group pattern should go after all of the patterns pertaining to individual instances.
Currently, that would require that I specify an order for every file:
1 overview.hbs
2 disabled.hbs
3 style-variations.hbs
4 group.hbs
Alternatively you could give everything after overview the same order value. But you'd still have to specify for every single pattern, as any pattern lacking an order property will show up after everything else.
This use-case is why I recommended (and prototyped) that we mimic the CSS order property in structure. Specifically its initial value of 0.
Having an initial value means negative numbers show up earlier than the default, positive numbers show up later.
This means you'd only need to specify the order property for the patterns you wanted to move, regardless of which direction they moved...
-1 overview.hbs
- disabled.hbs
- style-variations.hbs
1 group.hbs
It also seems intuitive given our target audience to make our order property behave in a manner similar to an order property they're familiar with.
The simplest method of including favicon.ico is in the root directory, which also avoids any 404 requests in the browser. Many static generators have an htdocs or static directory for assets that should be copied over verbatim. It would be nice to not have to specify <link> elements for this info.
I think this mostly boils down to gulp.watch being not nearly as awesome as gulp-watch. I messily fixed this in our fork [1], but you'll probably want to keep the separation of config and tasks somehow (or not; I certainly didn't feel the need to do so).
[1] - https://github.com/cloudfour/veelo-patterns/pull/4/commits/50a4b972c38b5fc9a6ce5f71f5c6baf76250b300
Currently, the "current page" is identified using some JavaScript on the client side.
It'd be nice if this could be determined during compilation, so while iterating through nav objects we could check for an attribute (current or active or whatevs) and style things that way.
Low priority, just a thought!
Linked headings with labels recur in multiple partials now (item.hbs and page-item.hbs). There may be an opportunity to make things more DRY by moving this stuff into a partial.
Originally pointed out by @erikjung on #21 (comment).
See also: cloudfour/drizzle-builder#82, cloudfour/core-hbs-helpers#20
Currently, the assets task from https://github.com/cloudfour/core-hbs-helpers is present as a dependency, but is not registered or configured in gulpfile.js or config.js respectively.
Since it's common to need images and other static assets copied into dist, this task should probably be enabled and ready to go.
src/assets/toolkit/ before, but is that what we want as a default?Consider using a bottom-border or something similar.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.