by Dan Perrera
Earlier this year, I found myself preparing to teach a class on interactive design at Boston University and was faced with an interesting question: how do you teach interactive design in 2017?
When I was an undergrad in the early 2000s, the comparable class taught Adobe Flash. I took printmaking instead. I did, however, buy a book on Flash and taught myself how to use it so as not to fall behind.
This past winter, as I was preparing my syllabus, it struck me that a course covering HTML and CSS 13 years ago would have taught me skills that I’d still be using today so I decided to teach the class I wish I’d had (albeit a much nicer experience after a decade of progress on the web).
I decided I’d focus on using web technologies as design tools since they’re ubiquitous, not to mention that it’s downright fun to get immediate results from typing some code into a document and seeing it appear in your browser.
I’m not trying to rehash the “designers should code” argument but ponder why some designers feel like coding is outside their domain, tease apart why front-end development seems so intimidating, and, if you’re a reluctant designer, maybe convince you to give coding a try.
At the start of my class at BU this year, I asked who was nervous about writing code and, understandably, nearly every hand shot up. Designers today are used to manipulating design software like Adobe Illustrator, Photoshop, or Sketch to achieve their designs and stripping away a graphical user interface is like taking away a security blanket — at least it was for me when I first started.
This fear isn’t isolated to students either. It stills surprises me when I speak to colleagues who describe themselves as knowing a bit of HTML but who don’t feel capable of writing “production code.”
I think everyone is selling themselves short and probably falling prey to a few common misconceptions:
We understand coding to be inherently complicated — which it can be, as anything is when you’re first starting out. I think designers often conflate front-end development with computer scientists or hackers but that couldn’t be farther from the truth.
To be honest, the software designers use on a day-to-day basis is far more complex than HTML and CSS. HTML is merely a structured outline of your content and CSS is a description of the styling and layout you’re aiming to achieve. Your web browser is built to read these instructions and interpret them into a design and once you understand the rules, you’ll be able to write those instructions yourself.
The other thing that is frequently misunderstood is the idea of “production code” or code that has been magically optimized for distribution. It’s always a good idea to optimize your code but the fact is, it’s a game of shaving milliseconds off of load times. This is critical for big businesses but for the great majority of us, it just isn’t that big of a deal.
For some, there is a secondary pressure that the quality of your code might be judged by your peers but this virtually never happens. If your design looks good in the browser, it’s a success. If it looks broken, it’s not. This isn’t to say that you shouldn’t optimize your website but you can achieve incredible results by only optimizing your images and leaving your code alone.
This isn’t totally false but I’m guessing that you don’t know how everything in your graphics editor works either. (Who does?)
HTML and CSS are pretty extensive and nearly impossible to learn completely by heart but the good news is: you don’t need to. You could build a website with only a handful of HTML and CSS tags and it would totally work. It’s far more important to understand the concepts of the technology rather than it’s entire specification.
Working in code is all about breaking your problems down to their tiniest pieces and solving each piece to achieve your design goal. As you do this, you’ll quickly learn how these tools work.
And if you do get stuck, there are plenty of references, online and off, to get you unstuck.
Remember all those students in my class who were afraid of code? Fifteen weeks later, every student walked away with two websites under their belts and skills they can build on for the rest of their careers. They embraced the challenge of making design decisions in the browser and found joy in the small successes along the way. You can do it too so the question remains: why not learn to code?
If you’re looking for a place to start, I’d suggest this fantastic getting started guide from Mozilla .