Designing For The Web
Delivering static design assets are no longer the norm for the web.
My first computer was a Intel 80486 (i486) with a DX2-66 Intel processor, a clock-doubling technology of 66Mhz, 32MB of memory RAM, and an incredible 200MB of disc storage. I got it from my parents as a birthday present in 1997. That was nearly 18 years ago. At that time, the web wasn’t mature (ironically, Mark Cuban had sold his company, Broadcast.com, to Yahoo for $5.9B in 1999), and still in its infancy, so the phrase “Designing for the web” had yet to be an expression used amongst web professionals. But the web was very cool. Pseudo-social networks in the form of chat (IRC) existed and were popular amongst schools throughout Brazil. And, if you wanted to be a cool kid, you had to be on IRC. The so-called cool kids in my town were on IRC on a local channel named #petrolina, and meetups happened every Saturday at the mall or someone’s house.
Aside from being a cool kid, the other cool thing to do was to build stuff on the web. Back then, the term “designing stuff on the web” wasn’t commonly used. You could design flyers, pamphlets, brochures, and billboards, but designing web pages didn’t resonate with designers. Conversely, building things on the web felt a lot like programming.
As far as I remember, there wasn’t any clear-cut distinction between designer and developer. Photoshop had just been released for photographers, and Fireworks had never seen the light of day. There were almost no tools available for web designers. If you needed to have an well-designed graphic on your landing page, you would spend more time coding than really designing your graphic, and chances were you went straight to coding because it saved you time.
At the time, how we connected to the network was terribly awful. My local internet provider offered a dial-up service with not-so-swift connections up to 56Kb per second. Every time I wanted to be online, I had to listen to an annoyingly sharp dial-up noise grinding my ears. Internet connection was nearly 70x slower than it is today, and consequently, forced builders to create lightweight web pages. Despite the lack of efficient web design tools, designing for performance was pretty much an obligation if I wanted to have an instant gratification and a sense of achievement when pages loaded on browser. (does it sound familiar nowadays?) It wasn’t fun or easy, and eventually, my interest in building on the web dissolved.
In 2006, while taking graphic design classes at Bridgewater State College, I picked up my first CSS book, Designing With Web Standards by Jeffrey Zeldman. This book completely changed the way I perceived building things on the web. Things started to take shape in my head. The way that CSS separated markup from presentation was really motivating and the possibility to eliminate tables from markup was headache-free. (I hated tables at the time.) However, the process of learning was not easy and I definitely didn’t learn it overnight. It took me years. I kept moving the needle in my learning, perhaps not in the most efficient way, but I kept myself going forward with hopes that one day, as opposed to being a laborer, I’d be building things on the web for a living. I was so intrigued with the concept of CSS that I bought myself a second CSS book, More On CSS by Eric Meyer. At the time, I was going to school and working full time as a server at the Chateau, a family-owned restaurant in Norwood, MA, and despite my insanely busy shifts, I always carried my book with me. I also started developing a strong interest in reading and writing. Consequently, I started to get involved with the web community in Boston and attended a few meetups organized by Dan Cederholm and Ethan Marcotte. These meetups were key components in boosting my curiosity on how to build things on the web. Learning how to code wasn’t as easy as I thought, largely due to being a non-native English speaker, and trust me, being a foreigner doesn’t make things easy at any scale.
The reason I’m sharing my own story here is because learning how to code as a designer was by far the best investment I’ve ever made in my career. And to be honest, in my opinion, a web designer who learns to code is just as important as learning about basic financial principles—you may not become a big-time Wall Street trader, but you’ll know how to better manage and save your money.
The Web has evolved significantly in the past several years. Companies that were once governant in the market are being governed; browsers that were dominant are being dominated (yes, IE I’m looking at you); operating systems that were once behemoths are now becoming irrelevant, and big mobile brands are evaporating relatively quickly.
The main reason I started to learn how to code was because most of the time my design was never translated well into code, and it would take days to come to fruition, if it made to the production at all. At the time, when pixel perfection was highly desirable, handing off my designs would result in a not- -so-satisfying piece of work; padding was off by 10 pixels, margin would be inconsistent, line-height would be disproportionate, and there was a bunch of designer frustrations due to misalignment in the layout. Admittedly, I felt I didn’t really own anything. I didn’t feel fulfillment or a sense of accomplishment. It was frustrating.
Learning how to code has given me the ability to understand concepts that were obscure to me. Concepts such as Ajax or asynchronous communication (request from browser to the server) was way over my head. My vocabulary has gotten much better and more robust over the years when it comes to the web. Talking to engineers no longer feels like trying to order hamburger sandwich with no pickles at McDonalds in a foreign language, and I no longer need to wait for a developer to add a semi-colon (close statement) to a function in Javascript. I’m not claiming to be a great developer; I’m far from that, but at least today, I no longer feel unfulfilled and fearful and I’m proud to say I can order a hamburger sandwich with no pickles at McDonalds with no fear of failing.
Learning how to code isn’t rocket science. It’s about setting your mind to it, spending hours in front of your text editor. It’s about saying no to some social events, and trying to do your best to understand it, and pushing yourself forward. It ain’t easy. Don’t get me wrong, it doesn’t always go smoothly, at least it didn’t for me — there were times when I would literally walk away from my computer in frustration from not getting it right. But, once you get past crawling, you can see yourself sprinting. You don’t need to be a genius. All you need is a desire to build something.
Today, employers — startups and some large corporations — are looking for people who can produce assets that are easily consumable into the application development flow. Handing off assets or half-static designs that don’t really mean anything — after all design is a hypothesis — are becoming less and less desirable.
I’m writing this essay to express the frustration and despair I once experienced as a new-comer; because I felt the frustration that many of you feel today. I’m writing this to empower and motivate anyone who feel demotivated or frightened of coding; who want to learn but maybe were mocked by friends at school or the desire to learn evaporated. I’m writing this because I believe a designer who can code, or anyone, has the power to create (prototype) things unimaginable.
Did you know that the so-cool technique of Responsive Web Design was invented by a guy who doesn’t have a degree in computer science? He learned how to code years after earning his literature degree. Yes, you can do it too. If you need help getting off the ground with coding contact me via Twitter.
Drink lots of coffee, listen to your favorite music, and code away. That’s how you do it! Good luck!
