Welcome to Part 3 of this series, where we are going to kick it old school! In Parts 1 + 2, (paper prototyping and faux prototyping, respectively) we talked about super fast, no code ways of prototyping your web project for user testing. In this post, we step up to prototyping with code…kinda/sorta.
In the late 1990s, I was a happy Adobe Flash camper—I had a ball creating animated, interactive content and had grown spoiled by all of the cinematic capabilities of that program. Web pages and the internet were an ever-growing storm on everyone’s radar, and I could sense the inevitability of the looming web tsunami. As much as I knew instinctively that I had to learn to build my own web pages, I was intimidated by HTML, by the concept of “coding.” The fact that I could create web content with Flash kept me placated and delayed my entry into the world of the “hand crafted” web. I would quickly learn that those fears had been laughably overblown.
The acronym HTML stands for hypertext markup language, and the term markup is the giveaway that we aren’t dealing with sophisticated code here. We are simply marking up what we want in a way that a browser will understand. We are essentially translating from English to Browser-speak, just like we would if we were translating from English to Spanish or French. But even that language comparison is too fancy, because HTML is a very simple structure to learn. A better analogy would be to say it’s like translating English into Pig Latin. Once you get the hang of it, it becomes real easy, real quick (iece-pay of ake-cay)!
And it keeps getting better; the release of HTML 5 in 2008 and its subsequent improvements in 2014 have made it even easier to use, more semantic, and more powerful. Ironically, it was the release of HTML 5 combined with Apple’s relentless attacks on Adobe’s plug-in structure (and security issues) that ultimately killed off Flash for good.
All of which is my gabby backstory for this post’s primary claim: HTML is a fantastic prototyping tool. Easy to learn, fast to write, and—to steal a certain computer company’s tagline—it just works. An HTML file can be shared with anyone, on any platform, and will run in any browser. How sweet is that?!
Don’t get me wrong, I’m a fan of many of the latest, greatest tools which do a lot of the heavy lifting for you–Part 4 of this series will look at some of those tools in detail—but having lived through the meteoric rise of javascript and the subsequent boom of js libraries and frameworks over the past decade, it sometimes feels like we’ve collectively leap-frogged over HTML altogether. These new tools fulfill our growing hunger for speed of development, but we tend to gloss over the trade-offs that can come with them. Many modern tools create pesky compatibility issues, introduce code bloat, or rely on a narrowly defined work process.
To my older eye, these newer tools, with a growing emphasis on WYSIWYG style constructions to better accommodate non-developers, prevent a greater understanding of underlying web structures. (And, as I said earlier, HTML structure just isn’t that hard. Honest!)
I’m willing to concede that this could be my gray hair talking. The corollary that leaps to mind is that of new makers/creators who don’t know anything about carpentry, but who can create rapid structures using 3D printing or CNC machines. Time may prove them right, but that doesn’t necessarily diminish the value of knowing how to make a tight mortise and tenon, right?
Perhaps a better perspective to use is the lens of Atomic Design as proposed by Brad Frost. We’ve all begun to recognize the logic and efficiency of thinking of web elements as simply modular building blocks for larger structures. For me, in the atomic design universe, HTML is the chemical system that binds all the pieces together. Without it, none of the other building blocks, big or small, would be possible.
The big takeaway: HTML is dead easy and super useful. BUT…it is really only half the story—the body, if you will, of any given webpage. The fun stuff, at least for us designers, is the CSS, a.k.a. the cascading style sheets.
If HTML is the body of a web page, then CSS is the clothing. And just as in the world of fashion, style is in the eye of the beholder, which can introduce some subjective heartburn. (History has not been kind to mullets and Hammer pants!) The important point here is that CSS is how you control the look and feel of any given HTML element: size, color, layout, opacity, etc. If you want your prototype to mimic a wireframe, then a few simple lines of CSS will give you that stark boxes and arrows look, easy-peasy.
So, I hear you saying, CSS sounds like the cool, stylish member of this particular power couple…and its structure is identical to HTML, yes? Uhhh, no. Sadly, CSS has its own way of doing things, but again, it’s not super complicated (more complicated than HTML, I’ll admit, but that’s only because HTML is so crystal clear) but for the kinds of things you’ll be doing for a basic testable prototype, you’ll be able to sling your own CSS in no time at all.
The powerful relationship between HTML and CSS was brought home to me in an especially impactful way back in the early 2000s through a website called CSS Zen Garden by Dave Shea. Shea’s exercise brilliantly demonstrated the concept of strictly separating content and style, which I could argue was the first baby step toward the whole Atomic Design idea of modularity that we accept today. I was happy to find that the site is still up and running; downloading the HTML and writing your own zen garden style sheet is still a great way of truly understanding just how fun and forceful a tool CSS can be.
I sense that you are still not convinced. Yeah, yeah, you say…building web pages is quaint and all, but why shouldn’t I use a tool that does all that for me behind the curtain? What’s HTML + CSS done for me lately? For me, based on my own experience, I come back to the “it just works” argument I stated earlier. It is the native language of the web: not only does it work, but it works everywhere. That may seem like a negligible point but I can’t tell you how many developers I’ve worked with over the years who were overjoyed to find that I had built my prototypes in HTML. While my implementation of CSS almost always needed some tweaking to be brought into alignment with the broader enterprise systems*, there is a copy/paste power to this approach that can save developers time and frustration. And saving your coworkers time and frustration is always a good thing. (When was the last time someone did you that favor in your job? Aren’t you always excited when you can lift something and place it directly into your own solution with only minimal tweaking?)
*Of course, if you have access to your client’s style guide or design system docs, you can adopt the appropriate styles right from the get-go in your prototypes, potentially saving your dev team even more hassle.
AND it provides true interaction within a browser, which, for testing purposes, is huge. Buttons, hyperlinks, and call-to-action items can all be clicked through and acted upon for-the-reals. No fakery, no smoke-and-mirrors. The browser back button is your friend! Just as some say there’s nothing like home cooking, there is something especially sweet about a prototype made from hand-crafted markup.
One final point: in Part 2 I spoke about using screengrabs when constructing prototypes in presentation software to mimic web interfaces. You can absolutely do the same thing with an HTML prototype. Painting your backdrop with a screengrab of an existing webpage is a quick way of setting the stage, on top of which you can build the interactive HTML elements you wish to test.
It’s probably pretty apparent by now that I really love building stuff with HTML + CSS. Just as I geek out over videos of folks folding origami animals or trying out fancy joinery techniques in carpentry, there is a deep satisfaction to building something from scratch in code. And because of its bedrock presence in all web pages, HTML + CSS can pay big dividends to anyone seeking to understand web structures in a deeper way. The next time you are wireframing a solution early on in a web project, try building out those wireframes in HTML and using CSS to control them within the browser. You might just get hooked, too, and find yourself lost in your own digital zen garden.
For those wanting to learn more CSS goodness, CSS Tricks has been one of my favorite websites for a long while now, and one of the first places I go when I’m trying to figure out a new approach to style. Check it out!
I’m also a big fan of Kevin Powell and his YouTube videos on CSS. He’s got lots of great examples presented in an easy to understand and follow-along-with style. For those visual learners in the crowd, he is a fantastic resource.
Coming up in Part 4: a closer look at some of the more sophisticated tools out there.