UX Design Libaries

UX Magazine has an interesting article on “How to Create an Enterprise UI Toolkit”.  Unsurprising to find Bootstrap referenced.  Nathan also offers a view, but this time references by pattern library and component library.  In my view, for any sizeable UX project, you need an appropriate UX component library at a minimum that should allow the UX design to reuse components (from the library) to build new page chunks without an explosion of customized components are should have really been one and the same.  This additionally means than when going to code, the same component library can be mapped to CSS or the likes, thereby aligning UX to implementation.


~ by mdavey on September 25, 2013.

2 Responses to “UX Design Libaries”

  1. […] UX Design Libaries and UX Design Library – Investment In Time and Creating a UX Component Library (Matt Davey) […]

  2. To me, the most important step in designing a component library is getting UX on board first. It is not really possible to design a reasonable set of components for a project, in the reusable fashion discussed in Nathan’s work, if UX keeps churning out controls of slightly different shapes and sizes and styles when they make their hi-fis. Whereas if UX is cognizant of this level of reuse, things can get much easier; you can have global styles (like ones for button, input[type=”text”], input[type=”search”], h1, h2, h3, etc.) that apply across the application.

    On a side note, the line between “element” vs. “component” in Nathan’s definition, and “element” in HTML, is blurred; a h1 HTML element could easily be a full header component via appropriate backgrounds and pseudo-elements, and an input[type=”search”] has enough capabilities built in to it that it would automatically qualify as a Nathan-component even though it’s a single HTML element. With the introduction of web components, whether natively or via prolyfills like Polymer, this line gets even blurrier; even Angular’s ad-hoc custom elements blur it as well. I think the eventual goal of web components/Angular is to make it so that you never need more than one HTML tag for a Nathan-component.

    Finally, I also think it’s important to not try to design component libraries for reuse across multiple projects. That causes the abstraction to be taken one level too far, with each component growing to accommodate use cases for different teams or even just different visual styles which cause incompatible changes to the associated markup and JS. I’ve seen people attempt to solve these inevitably-resulting issues via ever-more-complicated class hierarchies, but that makes something that should be very simple—a reusable, styled component—into a nightmare of code complexity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: