We first launched our in-browser prototyping platform, Huron, eight months ago and it’s become instrumental in streamlining our design and development process. We’re proud to announce our latest version (2.1.1) is now available on npm as an open-source tool.

Huron has evolved from a specialized proof-of-concept into a robust and flexible in-browser design framework. The idea for Huron came from our decision to move towards a browser-centric design process. Our new process meant that we needed to deliver in-browser prototypes to our clients during the design phase of each project. To accomplish this, we filled WordPress page templates with sample markup and presented them to the client. This process, however, revealed its shortcomings during the transition from the design phase to developing the WordPress theme.

It didn’t make sense to keep the prototype page templates in GitHub, where they would eventually end up on the production site, so we quickly had to find a way to generate prototypes outside of WordPress and PHP while maintaining DRY componentized markup. We took this replatforming as an opportunity to integrate the prototypes more tightly with the style guide we were using at the time, SC5 Style Guide Generator. The result was a Node command line interface to generate web components from static sample markup in KSS documentation. With this integration, we were able to use the same markup source for the style guide and prototypes. We were also able to host these files together on the client’s CDN, where they wouldn’t be tied to the production deployment process for the WordPress theme.

We continued developing our in-browser design practice on a subsequent project, and included Huron in that process. In that project we discovered we needed many varied samples of a single piece of markup. The version of KSS used in the SC5 Style Guide Generator didn’t support this and, since Huron was so tightly integrated with the Style Guide Generator, we were locked into its tool ecosystem. The result was numerous hand-built versions of each component with minor content or layout variation; a process that severely diminished the utility of Huron and defeated its original purpose.

Our design team at Alley committed to beginning every new design project with in-browser prototyping and further diminishing our reliance on static mock-ups. As a result of our experience and the changes in our process, we decided to fully rebuild Huron. One of the goals for this rebuild was to create a platform flexible enough to allow use of variables and template logic, but simple enough for our more tech-savvy designers to contribute to the prototyping effort on future projects. We removed its dependency on the SC5 Style Guide Generator in favor of  the more flexible kss-node, and integrated the CLI with Webpack, which is Alley’s current standard for front-end builds and tooling.

The result is a tool that allows us to create a pattern library and style guide of site components that are linked closely to their related assets. This allows us to build and manage variants of those components, and to work efficiently in the browser to produce them. There are at least a couple existing tools with a similar purpose and functionality; React Storybook (for React) and Devcards (for ClojureScript). In fact, we took quite a bit of inspiration from these tools when building Huron 1.0. Hot Module Replacement was a major focus of our efforts and allows REPL-like interactive live development by swapping in new module versions without a page refresh. Huron 2.X allows Alley to integrate in-browser prototyping completely into our design and development process. We hope others can use it to implement similar processes into their own work. Check out Huron at Alley Interactive’s GitHub and, if you’re a developer, head on over to the issues list and start contributing!

The Latest news

01
02