How do I build a component library?
March 6, 2013 7:49 PM Subscribe
How can I build a component library so our designers and developers keep things synchronized and don't end up doing a lot of double and triple work?
I'm part of a design team for a large (and getting larger) website. After a lot of hiring, we have more designers and developers now (yay!), so there's more work going on, and we're all doing different things at the same time. Sometimes designers and developers end up doing double or triple work, designing a solution for the same problem, because we didn't know there were already existing components in random places on the site that we could have used, instead of building a new one. (e.g., hover effects, carousels, buttons, toggles, etc.)
It would be great to have a component and pattern library that contains:
> Design files
> HTML/CSS/Javascript
> Any related code/documentation
Are you currently building, maintaining, or using a component, design, or pattern library? If so, how did you build it? Are there any off-the-shelf solutions, or did you roll your own? Any relevant experience would be helpful.
I'm part of a design team for a large (and getting larger) website. After a lot of hiring, we have more designers and developers now (yay!), so there's more work going on, and we're all doing different things at the same time. Sometimes designers and developers end up doing double or triple work, designing a solution for the same problem, because we didn't know there were already existing components in random places on the site that we could have used, instead of building a new one. (e.g., hover effects, carousels, buttons, toggles, etc.)
It would be great to have a component and pattern library that contains:
> Design files
> HTML/CSS/Javascript
> Any related code/documentation
Are you currently building, maintaining, or using a component, design, or pattern library? If so, how did you build it? Are there any off-the-shelf solutions, or did you roll your own? Any relevant experience would be helpful.
One thing to look at is the JavaScript module pattern. You may already be using it (certainly you've seen it when using third-party components), but in brief, the idea is to make your JavaScript as reusable as you reasonably can, turning it into a library of modular functions.
Internally, you might create a very simple demo site akin to the Twitter Bootstrap demo site, highlighting what sort of reusable bits you've got available. Ask designers and developers to add to it. If your designers and developers often use similar editing tools, the editor may have a format like Coda Clips you can use to make sharing and inserting code snippets even easier, but I suspect that's a stretch.
Also, consider using Sass so you can define your CSS much more readably and reusably. Here's a good compilation of Sass-related projects.
posted by Monsieur Caution at 8:57 PM on March 6, 2013
Internally, you might create a very simple demo site akin to the Twitter Bootstrap demo site, highlighting what sort of reusable bits you've got available. Ask designers and developers to add to it. If your designers and developers often use similar editing tools, the editor may have a format like Coda Clips you can use to make sharing and inserting code snippets even easier, but I suspect that's a stretch.
Also, consider using Sass so you can define your CSS much more readably and reusably. Here's a good compilation of Sass-related projects.
posted by Monsieur Caution at 8:57 PM on March 6, 2013
I tried following the style of Component or Bower or Flight, but ended up settling on something a little different.
I like to use a web source preprocessor (such as Brunch) to join all the source into a single minified build file, and let js files reference each other mostly with require(), and let preprocessed css files be completely scoped to the view they are styling.
Then each component can consist of small, closely-related modules in a single folder, instead of being collated into models/views/styles/etc. So my source tree looks like this:
posted by Phssthpok at 2:29 AM on March 7, 2013
I like to use a web source preprocessor (such as Brunch) to join all the source into a single minified build file, and let js files reference each other mostly with require(), and let preprocessed css files be completely scoped to the view they are styling.
Then each component can consist of small, closely-related modules in a single folder, instead of being collated into models/views/styles/etc. So my source tree looks like this:
components/ jquery.js underscore.js backbone.js normalize.css login-panel/ readme.md index.coffee template.hbs login-panel-style.styl user/ readme.md model.coffee collection.coffee view.coffee template.hbs user-profile-style.stylSo when you are working on one component, you switch between the style, view, and template files in the same folder. I feel like this helps me separate concerns better than if the sources are collated by type. For example, if I have to go looking for the right css file to put a directive in, it's temping to try to get the same result with html or js, which would end up being less maintainable in the long run.
posted by Phssthpok at 2:29 AM on March 7, 2013
« Older Chooseing between two very good, very close job... | Recipe & shopping list app for Android Newer »
This thread is closed to new comments.
If you want something more formal, you can take a look at assets management system. There's an open-source one that runs on PHP called ResourceSpace. I'm pretty sure there are many others for the platform of your choice.
posted by crowbar_of_irony at 7:54 PM on March 6, 2013