Chris Corner: The Tao of Demos¹

CodePen is a place where you can make demos. A Pen can be anything (a painting, a game, a landing page), but by and large, Pens today are demos. Why would you make a demo? Fam, why wouldn’t you make a demo? Demos are one of the most powerful tools we have as designers and developers. But the reason behind making one can be very different. That’s why it always made it hard for me to elevator pitch CodePen: I’d want to list a dozen reasons you’d want to use it, and I’d come across as unfocused. Well, too bad. I like that there is lots of reasons to use CodePen and make demos.

Let’s make an incomplete list of reasons to build a demo:

• Prove something to yourself. You’ve seen a new library, a new web platform API, or just some kinda something you wanna try. It’s one thing to read a little something about it. That’s good, it helps you slot the [new thing] into some brain bucket where you might be able to find it later. But does it really do what you think it does? Does it? Really? Prove it with a demo.
• Get everyone on the same page super quickly. I was just in a meeting the other day where a teammate of mine highly encouraged the meeting to start with the design comp. We actually had planned it the other way around. We wanted to go over the requirements and take a look at how the data structures were coming along, then see if the early design was on target. But after switching that up to see the design first, it immediately got everyone engaged and thinking about the same thing. How it ends up on the page is the end goal, after all. There is something about interactive visuals that gets everyone perked up. Come to that next meeting with a demo.
• Demonstrate a concept in the most minimal way possible. If you’re trying to learn or teach something, removing the extraneous can be an effective way to focus on the core idea. Contextual demos are useful later once the ultra-focused demo has made its point. For example, see how effective Gabi’s Flexbox Playground is. After you understand that core concept, then you can move on to real-world usage.
• Do it in a sandbox. The concept of a sandbox is usually referencing security. It’s a safe place where you can’t screw up. Cool; useful. But it also can imply that it is untethered. Like prototyping a component without the baggage of the rest of the site. Doing work free from the usual constraints can be freeing — you might think of things you wouldn’t have otherwise.
• Help fix someone’s bug or help them fix their problem. When someone is stuck while coding, answering them with code is the best. You aren’t just running your mouth, you’re putting money in it. There is a lot of good karma to be had here — answering a question or fixing a bug with a public demo will help that person today, and more people tomorrow.
• Whimsy. A coding job can be awfully serious. You’re doing important work. Work that affects people’s lives with things they are trying to do. You should take that seriously. But that doesn’t mean everything you do has to be so sober. Get loose. Get weird. Shake it up. Let it all hang out. Code doesn’t always have to be useful. A freaky demo might be just the catharsis the doctor ordered.
• Build a variation on something. Great artists steal, they say. Grab it, tweak it, make it yours. Could be anything you see on the internet (I use the browser extension CSS Pro to do this sometimes: with it, you can select an element and click a button to whisk it over to CodePen with all the HTML and CSS intact). From a design systems perspective, component libraries are most useful when they have variations you can choose from that serve the needs of anyone using the system.
• Relax. People like to knit, ya know. And crochet and cross-stitch and sew. Oh, and do crosswords and su-do-ku and that game where you spot the differences across two images. Those things require your brain to be turned on a little bit, but it’s still relaxing. It’s not weird to relax by building a little demo just for the fun of it.
• Nothing shows you care more than a reduced test case. If you need help with code, the best thing you can possibly do is showcase your problem with as little in the way as absolutely possible. Strip away unrelated code as much as you can. Not only might you solve the problem yourself that way, anyone looking to help will be appreciative that you’re respecting their time.
• Show off. The kids call it flexing, I think. Make something so cool people just have to stop and look. Everybody deserves a little vanity. You know plenty of people have gotten jobs based on demos they’ve made on CodePen, right? It’s true. Show the world what you can do.
• Treat it like school. The secret goal of schools is getting you to learn how to learn. I’ll break it to you: if you’re building demos of your own volition outside of an educational context, school worked on you. Good on ya. If you wanted, you could work through a curriculum building code demos. That’s basically what coding schools are.
• Test something. Does it work how you think it does? Is it actually possible? How do you know if it works if you don’t test it? And equally important: is it worth it?
• Prep a hiring exercise. Live coding interviews are a little controversial, but asking someone to demonstrate that they can do the job of design and/or development during the hiring process for a job that is design and/or development is a good idea. Perhaps it’s an async thing. How much would you learn about someone if you asked them to think out the considerations around a hamburger menu? What if you asked someone to spend two hours building a tic-tac-toe game playable across two browser tabs using web sockets?
• Write some code you know doesn’t really matter. There is a good chance you got into this field because you like code. A demo you know you’re going to throw away is proof you still like that journey. You’re a musician taking pleasure in practicing some scales.

If you look at all the wonderful demos above in this very newsletter, some of them will have been created for some of these reasons. But honestly, most demos are a little more throw-away than the ones that make it into The CodePen Spark. You’ll have your own reasons.

I was thinking about all of this after reading Andy’s The art of the demo, which starts:

Nothing enhances written content quite like a well-crafted demo, or collection of demos. They don’t have to be complex either — in fact, it’s better if they’re not complex. The most important thing is that good quality demos can help people really get what you’re trying to explain, especially if reading isn’t the most effective way for them to learn.

❤️

¹ Demtaos? Nah.