I've been working on CoreDogs patterns lately. There's a lot of work yet to do. I wanted to share some thoughts about why patterns are in CoreDogs.

What are patterns?

A pattern is a recipe for doing a task or solving a problem, that people have found works well. Some patterns are simple. For example, if it's hot, sleep on a cool floor inside the house, and make the humans step around you.

Some patterns are more complex. They are composed of other patterns. Take this:

This a common layout; you've seen a bazillion variants of it. To make a page like this, you could use the following pattern:

• Make a skeleton HTML file.
• Add a header region.
• Add a horizontal nav bar.
• Add a footer.

Each of these steps is itself a pattern. For example, to create a header region:

• Add a <div> with an id like header.
• Add a logo inside the <div>, floated left, with some padding.
• ...

Notice that something like "with some padding" is another pattern. Patterns inside patterns inside patterns.

There's much research on patterns, and related concepts like schemas and scripts. Some bits:

• Patterns reduce the effort needed to design things.
• People use patterns for design in all domains. Architecture, programming, cooking, ...
• Experts have thousands of patterns.
• Part of gaining expertise is learning patterns, and how to use them.

Patterns in design

Patterns are in CoreDogs because they help people learn how to design things. Design is about having a goal, like making a Web page, and figuring out how to put together lots of HTML and CSS tags to meet that goal.

Knowing the pieces is not enough. Knowing how to put them together is a separate skill.

Decomposition is key to design. Break a big design goal into smaller subgoals. Take the first subgoal and break it into subsubgoals. Repeat, until the subsubsubsubsubgoals are small enough so that each one can be met by one or two HTML/CSS tags. So each tiny subsubsubsubsubgoal has a tiny subsubsubsubsubsolution, made up of real tags.

Come to think of it, let's use the words "subgoal" and "subsolution," no matter how big or small they are. This subsubsubsub stuff is too hard.

The subsolutions are not independent. They're interdependent. Take this pattern again:

• Make a skeleton HTML file.
• Add a header region.
• Add a horizontal nav bar.
• Add a footer.

The three regions have to look good together, so their colors and fonts need to be coordinated. A constraint in the header (e. g., using a logo that has a particular color scheme) limits the choice of nav bar colors.

Design is hard to learn, and hard to teach. If you open a book on Web tech, or programming, often the decomposition process is not even talked about, not explicitly. It's there, of course, in the examples. But learners are expected to figure decomposition out on their own. They look at examples experts created, and try to infer why the solution is structured the way it is.

Some learners figure decomposition out on their own. But many don't. They know what the tags are, but when it comes to using them, they're stuck. They don't know where to begin.

Making patterns explicit

CoreDogs makes patterns explicit. There are lessons about them, like here and here. There's a pattern library, to help learners use patterns on their own projects. When new pattern is defined in a lesson, you'll something like this:

Patterns help learners get into the habit of asking, "How do I break this problem into chunks?" But CoreDogs doesn't explain decomposition in an abstract way, talking about goals, subgoals, and interdependence, as I've doing here. CoreDogs patterns are functioning solutions to concrete problems.

When learner sees a dozen patterns or so, hopefully they figure out that problem decomposition is a Good Thing. Not by telling them directly; the concepts are too abstract. Learners will have seen decomposition in action again and again.

Patterns need customization

You might be saying to yourself:

Not so, Buster! Or whatever your name is.

Patterns are not plug-and-play, at least not usually. Patterns are general solutions, yes, but they need to be customized for each use case. For example, the code for the header pattern needs to be changed for every site, to include the right logo, the right text, the right fonts, the right colors, etc.

You have to understand a pattern before you can customize it. If you don't know how the header pattern uses CSS classes, you'll have a hard time changing the logo's padding.

Summary

A pattern is a problem solution that people have found useful. Experts - and regular people - use patterns in every domain. They're a natural part of problem solving.

CoreDogs uses patterns to help people learn the design process. Particularly decomposition. People learn by using patterns, not by learning about abstract words like "decomposition."

Patterns are not plug-and-play. You need to understand how and why they work before you can apply them to a particular use case.