A streamlined tool for developing, documenting and presenting UI pattern libraries.
- Download
npm start
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
Create and add 'em.
Re: cloudfour/core-hbs-helpers#40, cloudfour/core-gulp-tasks#46
devDependencies
to replace helpers packagedevDependencies
to replace tasks packageWe need a publicly-accessible demo! ๐
This could be a Netlify site, or we could use something like gulp-gh-pages
to use GitHub pages.
It'd be nice to be able to link to a specific pattern heading on a collections page using a #
hash URL.
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?
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
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.
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.
Maybe it's a good idea to add in Modular Scale to the boiler plate?
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.
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.
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!
We should totally have these! :)
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.
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?
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?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.
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! ๐
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.
Or maybe a Drizzle logo? ยฏ_(ใ)_/ยฏ
Currently, these are in the generator. It makes more sense to bundle them into this repository.
Currently, 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.
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
<ul>
currently).Original issue: cloudfour/drizzle-builder#63
dest
paths for pages, patterns, etc. all assume a common root folder (e.g. ./dist
)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
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?
We need more. ๐
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 {{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>
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
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.
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! ๐
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
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
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. ๐ ๐
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.
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. ๐
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! ยฏ_(ใ)_/ยฏ
@tylersticka made a great suggestion in this conversation:
(I actually wish
wrapper
were namedbody
andbody
were namedmain
. But I'm pretty sure that change is too low-level to prioritize now.)
This will include updates to drizzle-builder
.
Consider using a bottom-border
or something similar.
This applies mostly to https://github.com/cloudfour/core-gulp-tasks, but it would be nice to get descriptions with gulp --tasks
.
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.