Good programmers like patterns. Good designers like patterns, too. Patterns establish familiarity and encourage re-use. SMACSS is about identifying the patterns in your design and codifying them.
A prototype should assist in viewing components in part or in whole and to allow the codification of the design language into building blocks. The web design industry likes reusable components and can be seen in many of the frameworks like Bootstrap (for a variety of site components) and 960.gs (for layout grids).
At Yahoo!, the prototyping team creates these building blocks and use them for production. This allowed for greater consistency across multiple products since they were all based on exactly the same foundation.
Goals of a prototype
A prototype can serve multiple goals:
- show states
- review localization
- isolate dependencies
From the default state to collapsed states to error states to whatever states you have defined, it is important to be able to visualize each of these states and make sure that the module is built accurately.
If a module is data-driven then real or mock data can be used within your prototype to test that it will render correctly.
For projects that need to support multiple locales, it will be valuable to be able to test modules using strings from the different locales to ensure layouts don’t break as a result.
At Yahoo!, modules are isolated into individual CSS files and are bundled using a combo handler when needed. For example, when the inbox loads, it combines CSS files together for buttons, message list, sidebar, tabs, and the header. The moment the user requests the Search page, the combo handler combines search-specific styles and delivers them over the pipe. Search uses a variation of the default message list and sidebar which means it only has to load the sub-classed modules.
Pieces of the puzzle
At Yahoo!, we built a prototyping engine to help facilitate this process. Whether you need something similar will depend on the size of your project.
In the case of our prototype engine, some state management is handled before the module gets rendered. This handles conditional items, data filtering and anything else that might normally be handled via server-side processing. State management isn’t always just a case of applying a class name to an HTML element.
Having a full-blown engine to compile your modules could very well be unnecessary, especially for a small site. It is still advantageous to isolate your components into an easy-to-review format. MailChimp, for example, has an internal cheat sheet of design patterns that they use to build the site. This documents various modules that are used throughout the site and the code required for each module.
Remember, patterns are good. Codifying those patterns is also good. Having a process in place to review and test those patterns is great!