Advertisement
Advertisement
ATD Blog

On Templates

Tuesday, September 4, 2012
Advertisement

Last week, I had the opportunity to hang out at the Chicago School of Mold Making (http://www.chicagomoldschool.com). Mike Joy, who runs the school, has been doing food-grade silicone molds for years. He’s pretty much the best guy in the entire culinary world for what he does, and he was talking about how the business around these molds work.

Many dessert and pastry chefs like to do things with the presentation of their food to promote a certain design aesthetic in the plating, or presentation, of their dish. Some chefs would do this by hand because they look at it as an artisan skill. But most chefs don’t have the time—and some lack the talent or skill—to produce a visually appealing (and edible) centerpiece on their own. So, they rely on these molds.

Some molds serve one purpose; some molds are part of a larger set to construct a centerpiece. When I see such edible centerpieces in banquets or weddings, I’m impressed with the novelty of it, but I never really paid attention to the design aesthetic of what I see. I looked through a catalog that Mike offered me, and many of the examples of what his molds can help produce seemed very dated looking.  They made me think that every hotel brunch I’ve been to is using the same molds to make the same centerpieces.

Mike and I discussed that perhaps there’s a different type of template we should be designing. The individual molds MIke produces are part of a predefined set. What we “ideated” about was that molds might be used for different purposes; perhaps they could be combined—like how Legos work at multiple levels from the individual brick and combine in lots of ways.

There are so many parallels to e-learning that it got me thinking.

The content templates we have assume that information is always going to “display” the same way. We’re not thinking about the templates behind the kind of information we may always be looking for... the interaction patterns. Those could be templates, too. Such a template would work almost backwards: a template for what we want the learner to do vs. what we want to show to them.

I think in the e-learning world, we’ve spent too much time designing templates for information to be shared in certain, pre-defined ways. My opinion here is that as a trade, we’ve considered the alternative to be something that has to be done completely from the ground-up—free of templates at all. 

Advertisement

What I’m suggesting are templates for interaction patterns: the things we as designers want to observe from people’s experience with their tools, their experience with the content we produce, and their interactions with each other. These interactions have patterns (and sometimes sequences) that we can design for and with.

Such things can be templates, and the presentation of the content and the entire experience can be tailored for the individual and the group they are part of. It’s not good enough to simply guess at what these human interactions are, design for them, and call it a day. We will need to conduct real research to produce a set of templates for a single experience.

Learning is a social activity, even when you think you’re learning on your own.

This is the kind of thing for which the Experience API (Tin Can) is well-suited: It shares across multiple systems what a person does, in language precisely tailored to the type of interaction being “tracked.” The patterns you define in such experiences are exactly what you can track (in a traditional, SCORMy sense). AND these interactions, when aggregated across lots of experiences, demonstrate what’s really happening versus what you, as a designer of an experience, expect to happen.

Advertisement

This allows us, as designers, to continuously improve the design and “presentation” of a given experience.

It’s the key difference I see in how we work with content in a Tin Can world; we’re continuously improving. We may still create content, and it will be a production process that is different from the annual review of a “course.” It will be the constant tinkering that iteratively and progressively helps people perform better... because data will be present to point to what specifically can be tweaked.

Learning is happening everywhere. 

As designers and developers and producers of materials and experiences through which people learn, we should be doing things that embed some real-time data collection (instead of relying just on the assessment or evaluation we slap on at the end of a course). This makes it possible for any of us to pay attention to the patterns of activity, within some context, on how we perform. Ultimately, that’s what we want to know anyway—whether we’re a manager, a teacher, a parent, or directing our own learning.

This is how we become self-aware and become a part of the kinds of communities and organizations that succeed and grow.

About the Author

Aaron Silvers is an active leader in the evolution of online learning. He was the lead developer for Advanced Distributed Learning (ADL) responsible for determining how content could be built for SCORM system and over the last five years led the specification (and now standards) effort developing the Experience API. He chairs the IEEE xAPI Study Group.

Through his consultancy, MakingBetter. Aaron accelerates learning and builds capacity in organizations. He evaluates systems and tools, leverages LEAN methodology to innovate and continuously improve learning and development functions, designs learning experiences and develops learning analytics and reporting capabilities.

Aaron co-created the “Up to All of Us” community and annual gathering with partner Megan Bowe in 2011. Up to All of Us catalyzed a new community-of-practice that reconsidered design, workflow, tools and practice. He continues to encourage the development of more effective design practices and better tools through partnership for the Experience API community with the forthcoming events, Connections: xAPI.

Be the first to comment
Sign In to Post a Comment
Sorry! Something went wrong on our end. Please try again later.