Author Archive

Implementing Modular Web Design: Part 2 – How?

March 29, 2011

Modular Web Design by Nathan Curtis and Web Anatomy: Interaction Design Frameworks that Work by Robert Hoekman Jr. and Jared Spool are great resources for UX developers. They focus on the theory, philosophy and process of designing modularly. Unfortunately, these books don’t go into any detail about how to actually implement, in code, a modular web design system in a web app. Some excerpts in Modular Web Design hint at what other companies have done, but there are no concrete steps to guide the process of implementation.

In this post I hope to outline a global strategy that is programming-language agnostic, easy for the end-user (in this case other developers) to implement, and hopefully elegant in its abstract design.

As a UX Engineer I approach code architecture the same way I approach a wireframe design. I start with what I want the end use case to look like and work my way back through the details. In this case my end users are my fellow developers and the goal for them is a super-easy implementation of reusable components that borders on the magical. Think jQuery’s “write less. do more.” motto on steroids.

I want developers to be able to write one line of code anywhere in the view tier of the web app and have that magically transformed into a fully functional component complete with CSS and JS wirings when the page is actually rendered by the server.

The end goal is one line code snippets that transform into HTML, CSS, and JS at runtime.

In order to achieve this, you need something in the request cycle that’s looking for these one-liners and triggering the component engine that renders the HTML, CSS, and JS to spring into action. Ideally this is some kind of string parser connected to your view composition engine, preferably pretty late in the composition cycle so the components will be one of the last things rendered by the server before the user sees the page.

The high level request diagram looks something like this:

Once the ability to detect snippets and return components in their place has been enabled, you can begin to break down the input and output processes further.

At some point in the input process the snippet that the output parser is scanning for will need to be broken down into arguments that can be passed to the component engine.  The syntax of the snippet will be discussed in a later post, but for now let’s assume that snippet is transformed into something the component engine can understand. We may also want to add rules at the input stage to check for things like component dependencies, or to ensure that there aren’t too many of one type of component on the page, (i.e. more than one site wide navigation component, probably not a good idea).

The component engine receives the appropriate arguments, works its magic, and returns HTML and paths to static assets. The HTML will need to be inserted in the same location that the snippet was previously. The static assets will require some more advanced routing.

Best practices are to have CSS references in the head and any static JS files referenced immediately before the closing body tag. There will need to be something at the output stage that can manage the creation and injection of the necessary <link> and <script> tags.

That’s pretty much it for the high-level overview. Obviously there’s more complexity that can be added like preventing the addition of duplicate JS and CSS files or combining those static assets into one file to lower the number of http requests, but that’s my vision for a basic implementation. A one line snippet becomes HTML, CSS, and JS all wired together. It’s modular, reusable, and wicked fast for implementation.

In my next post I’ll discuss the syntax of the invocation snippets. Specifically, strategies to prevent naming collisions, how to efficiently pass configuration parameters, and more. What are your thoughts on this high-level implementation? Would you do something different? Have you implemented something similar? If so, post a comment below.

Implementing Modular Web Design: Part 1 – Why?

January 28, 2011

Having read Web Anatomy: Interaction Design Frameworks that Work by Robert Hoekman Jr. and Jared Spool and Modular Web Design by Nathan Curtis, I was super excited about the prospect of creating a component library for the developers here at Lampo. What’s so cool about component libraries? Let me tell you.

Imagine never having to hand-code a contact form ever again. Now I hear you, you’re saying “Kevin, I’m an awesome developer, I don’t hand-code contact forms, I’ve got code snippets, templates, and frameworks that allow me to quickly implement contact forms, why would I want a component library?” The problem with snippets, templates, and frameworks are three words that make every developer cringe: “copy and paste.”

Imagine working on a site that has 20+ contact forms all for different business modules within the company. Now imagine that you need to change something about all 20 of those forms. Now you’re saying, “But Kevin, CSS rocks my socks off, I reuse stylesheets like a champ!” To which I say, what if you need to alter the markup? What if you need to attach a bit of javascript to transform your contact forms for mobile devices? With copy and paste there’s just no global hook at the component level.

Another argument is for existing component libraries. Most of these are javascript based: jQuery UI, YUI, LivePipe etc. They’re great, but there’s still a good deal of configuration involved. You need to write the markup, create the js bindings between markup and the library, and then download a theme or write some CSS to make it all look pretty. The type of component library I’m talking about does all these things for you.

One line of code gets you markup, JS, and CSS. All wired up to work beautifully together and provide you with usability-tested, consistent, semantically-correct components to use throughout your web app. Plus you have the control to change and upgrade components on the fly and all users of your components will receive the updates. No need to do a search and replace (AKA search and destroy). It just happens.

Have I sold you yet? Do you want to build one of these? Does it sound as amazing as a triple rainbow unicorn?

Well it did to me. So how do you implement something like this? Hoekman and Spool’s book provided me with some great theory, but nothing code based. Curtis’s book does an awesome job of describing implementation for a design department (another benefit, another post), but also left me hanging when it came to coding.

So that’s where we begin. In the next post I’ll discuss how we approached the problem of actually implementing the Lampo component library lovingly known as “Gutenberg UX.”

That’s the origin story for our component library.  Have you implemented something similar or experienced any drawbacks implementing jQuery UI or another javascript component library?  Comment on this post and share your story with us!