UIEtips: Components, Patterns, and Frameworks! Oh My!

Jared Spool

May 20th, 2009

I think we can all agree the most fun part of any design project is coming up with something nobody has ever thought to do before. These moments of innovation are exhilarating, getting the heart pumping and the adrenaline flowing.

However, on most projects, they are few and far between. That’s because, even in the most innovative projects, the portion that counts as never-been-tried-before is only about 20% of the project.

The remainder is supporting functionality — things the new functionality needs to work. That supporting functionality doesn’t get the heart pumping or the adrenaline flowing. It’s just nose-to-the-grindstone, must-do work that is part of every project.

But what if we could reduce that work and make it possible to spend more time on the fun, exciting innovative parts? Well, that’s just one benefit of having a solid re-use strategy.

In today’s UIEtips article, we explore the use of Patterns, Components, and Interaction Design Frameworks. These critical development tools, which make up what we’re calling the Re-use Trilogy, give developers a chance to increase the percentage of time they spend on the fun stuff, while delivering better quality results. Read today’s article to see how this works.

Has your team tried building a pattern, component, or interaction design framework? What has your experience with these tools been? We’d love to hear what you’ve learned. Share your thoughts below.

On Wednesday, May 27, you’ll have a chance to learn more about Interaction Design Frameworks. Robert Hoekman, Jr will show you how this important new tool can jumpstart your designs and ensure you deliver high-quality experiences. Watch a sneak preview of the Virtual seminar.

5 Responses to “UIEtips: Components, Patterns, and Frameworks! Oh My!”

  1. Carlos Abler Says:

    Jared. This is great.

    In my opinion, learning pattern languages of components and interaction are the new due diligence. It is abundantly clear to those of us who stay on top of these things, that the practice of bringing about a common language and discourse around these “reusable” patterns, is a minimum requirement for what defines competence in interaction design. And by that “competence”, I am not just talking about the ability to create good or great interactive solutions, but a total professional project competence, along the lines of efficiency that you describe, such as not re-inventing the wheel. I have been in the role of user experience and interaction design best practices evangelist in organizations with staff not trained in the basics of these — now rather well established — practices; and it is a tough row to hoe. I am increasingly convinced that if a business is not founded on these principles that they are doomed for extinction, and that really just about anyone on an interactive project that does not have at least a working conceptual grasp of the principles that effect a projects QA and efficiency, will fall out of the market as their value diminishes. I believe this because the writing is on the wall with the dissemination of pattern language repositories and books founded on this framework. More and more design schools will have these studies as a part of the curriculum. Fewer skateboard designers will be designing interfaces with no training in interaction design. We can already see this in the increased amount of publications and teaching curriculum over the last three years. I look at the problem as the evolving intersection of HCI disciplines with the communications and marketing disciplines. For myself, I have been compiling and encyclopedia of interaction design patterns and best practices guidelines over the last few years, as have others. My current company (I am one of three owners) has them as a critical part our foundation. As we grow and hire, they are a core part of staff training and orientation. We are constantly trying to speak pattern languages among ourselves to come to an ever clearer common understanding toward rapidly solving the common aspects of interaction design problems, so that — as you imply — we can get on to the hard stuff. I think even the 20% “never done before” number you threw out is generous (re: the “innovative” aspect”). What often appears as “innovative” only appears as such because due diligence on understanding where a given “wheel” has already been invented is non-existent. In what I call “High Concept Sites” it is different, as these tend to be simple sites where “novelty” is all they are about. Like when you create a site people can get lost in that is just about a single tennis shoe. But most web sites present require very common solutions to very common problems. And most people working on projects couldn’t even give you a gut guess as to how many species of navigation menu design patterns there are. When I say there are roughly 30, often I am met with incredulity because so long as you don’t research the matter, there will continue to be some vague infinite potential number, and there is the illusion of being “inventive” when designing so long as you don’t realize what you are doing is in fact common. And worse, you don;t realize you are applying a UI pattern more appropriate for a 2 level deep marketing site, to a site that is 9 levels deep and must accommodate dozens of audience use cases. I would include among the, innovative and creative fun stuff that we will have more time to focus on when we are done reinventing the wheel, as time to put into getting content and advanced UXP right. As a final note: I think interactive design needs a Bauhaus-like holistic curiculum that included IXD patterns and best practices, but also many curricula that address the many dimensions of UXP, that for the most part are not considered essential to product development thought they are. many of these aspects of curriculum exist in advanced theater and film production, anthropology and of course anything toughing on psychology, interpretation and subjective ergonomics.

  2. Tania Lang Says:

    To build and share knowledge within our small consulting firm, we have created a pattern/design library. It is currently not very high tech and we just just use a PowerPoint pattern template we have created. Each week, each consultant has to share a good or bad website they have seen that week. This counts towards their Knowledge and Professional Development KPI which is part of their Performance Review.

    Our patterns are not true patterns strictly speaking, it is more of a design library. In our template we capture:
    - name of pattern e.g. ‘Progressive Disclosure’
    - screen shot(s) of the particular design element or page OR Video clip
    - website URL
    - Notes, context and comment
    - Rationale/Heuristics (that the design is a good example of)
    - Keywords/tages
    - File name, Author and Date captured

    We use our design library to grab leading practice examples which we may include in test report recommendations/appendices. I also use them in our training workshops as good and bad examples of design.

    Our next step is to better sort all of our patterns and make them easier to find.

  3. Jennifer Vignone Says:

    In creating a framework it is important to use elements that are not custom controls that would be a bigger burden to maintain and evolve. While you might be able to customize an environment and get buy-in in a small firm, it could seriously limit the acceptance rate of a framework throughout a mid- to large-size organization. It also increases the learning curve. At my last job, I worked in a team that was trying to sell a customized framework with custom components throughout the company (a large financial institution). While we had great functionality, the custom pieces made other Development teams shy away. In my current employment, we are again building our own framework, but this time we are using Infragistics components. In our first release, we are endeavoring to not customize elements so we can work with Infragistics to evolve them through their natural release cycle. In cases where we require different and enhanced behaviors (and we have submitted quite a list!) Infragistics is working with us to try and provide what we need. Only after this exercise we will determine what customization we will build in. This approach will help us make our components and the framework more universal, easier to maintain, and easier to learn.

  4. Rick Castanho Says:

    Very good read… we’ve done some really innovative thinking with our library that closely resembles the framework thinking. Our overall Library consists of three main sections which are the building blocks of any online app we might develop.

    The 3 sections have to do with 1. Environment, 2. Interaction and 3. Applications; and the deliverables for our UX team for each section are as follows.. 1. Layout Templates, 2. Design Patterns & IxDs, 3. Wireframes & Styleguides

    The Environment section is where we define and house the major constructors used to assemble the interface for the particular environment. Here we define Containers & Container Sets (groups of containers) with specific purpose and rules that will serve to consistently deliver global and local interaction elements into the environment… conceptually this supports a template inheritance model for the UI layer.

    The Interaction section is where we define and house Design Patterns and their supporting IxDs. Design Patterns are a good starting point for an interaction designer to get ideas and when selecting them to avoid re-inventing the wheel. We’ve broken our DPs into 3 types (Control Patterns, Compound Patterns, and Behavior Patterns). Specific interaction behaviors for each Control pattern is captured in the supporting IxD doc which states in a technology and application agnostic manner how this particular control should behave (IxD blueprints). Hence, we may have a UI control on one page built with jQuery and the same control on another page built into a Flex SWF, but they will look and behave the same for the user in seemless manner. The IxD also offers “attributes” which can we enabled and customized (within rules) when instantiating the pattern, giving the Interaction Designers and UX Developers some creative flexibility. The IxD also defines components of the control and support for “styling” they might support. This helps developers build a supporting CSS library. Compound Patterns are “collections” of Control Patterns that are designed for re-use. Other considerations such as SEO, Security, Internationaliztion, & metrics for each pattern is captured in supporting docs that are associated with each pattern. This way when a pattern (or UI component) is instantiated, core infrastucture to support different parts of the business is ensured.

    The Application section is where we design and document the specific implementation details of the Design Patterns, their IxDs and Layout Templates together to carry out the particular needs of this particular application. The wireframes “refer” to and “instantiate” patterns with specific instructions regarding attribute usage, content and data-binding, etc. based on the needs of it’s usage, and the styleguide defines the “skin” for this particular app.

    I like the concept of frameworks from a conceptual perpective and I am sure we will adopt this thinking. Our framework thinking thus far has been more along the lines of supporting an underlying application UI framework for delivery and “collecting” and re-using collections as compound patterns.

    So, a simple independent control pattern may be a “pagination” control that can be instantiated in a number of different ways depending on the application it’s going into, and another control pattern might be a “data grid”. Put the 2 of them together consistently to deliver search results and you have a re-usable compound pattern. So now search results interactions behaves similarly for any type of search across the environment. If the pagination control is later enhanced then all Search Results can simply inherit the new functionality.

    And yes, we are finding many docs to have multiple contributors and where we physically house things matters as well as having frequent and consistent reviews of designs and pattern usage to ensure proper usage. All these things help to add up to a consistent user experience, reduce design and development costs and free creative cycles for new challenges.

    We are also finding this to be a full-time discipline for a curator.

  5. Sue Braun Says:

    I particularly like the example of a component to select a date. I like the comment that these often aren’t as useful as one might think because they do not include the business requirement. Sure enough, I’m going to design a travel website someday that saves 50,000,000 human-clicks / month. It’s going to have a date selection pop-up that (for a round-trip) lets the user choose the leave and return dates at once — in a single pop-up. There are a lot of variability in these. Some of the worst seem to not not realize you can’t return before you left, or assume your most likely day to return is at least 3 weeks after you leave (or varies by the time within the month) — all weird. Why is I leave the 29th, should I need an extra click to come back on the 1st, compared to leaving the 1st and returning the 4th? Anyway, when is someone going to realize the “business requirement” for a round-trip is to enter 2 days, with user-focus required to get them straight and having a very close relationship to each other? Sounds like a single widget to me.
    Keep up the interesting articles.

Add a Comment