Prototype Driven Development provides quick testing of UI components.

Remember how Sketch Flow was made in a way that the effort put into creating wireframes for a SilverLight project would not be throw-away work? No? Well the concept was great. Let’s do that with Prototypes for web app development.

Prototypes are more valuable than wireframes or designs. You will see that requirements change once clients can touch what it is that they have requested you build for them. “Oh it responds like that? Can you just make that different?”



A prototype will provide proof of concepts and be a source of documentation throughout the project.

Proper setup of build tools means that the code in the prototype will be the same code in production.

Example: PatternLab. Shows the single components, components in groups, and shows the code used to build them. It shows the components alone as well as next to other components. It shows if a component is ready for re-use.

single-form | comment-thread

Build System

With an enhanced build system we can build the Prototype + Style Guide alongside our project in VS.


  • Git. Needed to “Git” things from the web. - //
  • Node.js. //
    • Once installed you can “Git” other things with npm:
    • No Ruby, PHP, or Java needed
  • Gulp or Grunt or both: “Automation, performing repetitive tasks”
    • minification, concatenation…
  • Pattern Lab (node version)
  • Optional add-ons for VS (works on VS 2013):

Why not Nuget and MSBuild? Hanselman answered. “Because there’s already a rich ecosystem for this kind of thing. NuGet is great for server side libraries (and some client-side) but there are so many more CSS and JS libs on npm and bower. MSBuild is great for server-side builds but can be overkill when building a client-side app.”


We’ll need some JS Patterns to avoid conflicts so components can be reusable. If two components want to save a number to a variable named “width” then the last one to define it will win. And the app will lose.

Modular Pattern //,js,output

Or just use the jQuery plug-in format. //,js,output

Elements affected by JS should have separate css classes that look different: “js-icon” or potentially data-attributes. That way you can safely change style classes but carefully change JS classes.


  • < i class=”icon-class js-icon” data-icon=”iconJS” >
  • $(“.js-icon”).on(…);
  • $(“[data-icon]”).on(…);


As a base use the latest bootstrap. Everybody learn bootstrap. They have put much time into finding the configuration that works best for the web today. You can transfer your knowledge to other UI frameworks later.

If you want different margins then customize bootstrap before you download it. Only build something new if bootstrap does not provide it - it usually does provide it. Then when we do need to create something new use conventions. Building without a having reuse in mind is a shot in the foot.


SUIT CSS is a reliable and testable styling methodology for component-based UI development. The SUIT CSS naming convention helps to scope component CSS and make your widgets render more predictably.

  • .ComponentName “Article”
  • .ComponentName–modifierName “Article–black”
  • .ComponentName-descendentName “Article-title”
  • .u-utilityName “u-floatLeft”
  • .is-stateName “is-selected”

“The component’s name must be written in pascal case. Nothing else in the HTML/CSS uses pascal case.” SUIT CSS naming-conventions

For a full demo see: //

It is a learning curve for sure but the results are worth it. This will scale from small to large projects and make for happier teams.

SVG & Icon font opinions

No more IMG for icons.

Font icons are easy to use. Their icons pick up the font color. I very really like icomoon //

But SVG wins the cagematch: // Automated grunt task. SVG can be animated. //

All browsers since IE9 do SVG so it’s time to adopt. //

What does SVG look like in my code? //

Since you do not like that all of that SVG code move the SVG code to a re-usable block and pull it in with the USE element //

SVG sprites so the code stays clean and repurposable: // and //

How might I make a shape? //


A thought about the teams who build this. Often a “front-end” team builds the prototype and hands it off for it to be integrated into production by the “back-end” team. This might lead to the second team finding that the components have bugs after integration that were not there in the prototype. At this point either team can make necessary changes with both integration and the prototype in mind.

Comments can happen here: /blog/issues/7

[ Words: 977 ]