Get out your pocket protectors, cuz it’s time for some hardcore geeking. Ok, so maybe it’s not that extreme, but being able to program—at least to some extent—is a very valuable skill, especially for a designer concerned with the web. Even the term “programming” may cause you to cringe, especially if you’re comfortable inside your usual design tools, but it can effectively take your designs to the next level.
Many of us are used to the model of a separate design and development team, especially from working at various sized places that specialize in web products for clients. However, more and more young professionals are emerging with a formidable hybrid set of skills. This one-man shop mentality is taught in certain schools, which may not currently be the standard in the workplace, but will soon become appreciated and possibly even expected. Adaptation and fluidity are key for staying one step ahead, regardless of age or role.
Plan. It’s very useful to start programming, especially for those with little or no experience, by writing functionality out in prose, sentences and paragraphs. Most experienced developers usually skip this step because they can do it in their heads, but being able to verbalize (and transfer to paper) exactly what you want is a major component of being able to translate that into code. Using that same Flash portfolio example, you may need to write, “When the user clicks on this thumbnail, the thumbnail should zoon in to a full size image” or “when the user drags this scrollbar to the right, the content should slide to the left to reveal more of the content on the right.” When you can comprehend concepts at such a high level, it greatly facilitates the process of writing the actual syntax.
Comment. Here’s another concept that even the most senior of developers sometimes neglect, but is necessary for a number of reasons. Almost every programming language has some form of commenting, that is, a way to write notes in the code without the computer trying to execute it. I always begin a development project by writing comments before writing any actual code. Many programming languages use the format that any line with two slashes (//) in front of a line is a comment, and some languages allow you to comment multiple lines by enclosing them in “slash-asterisk” (/*) to begin a comment and “asterisk-slash” (*/) to close the comment. Using the same example from above of viewing a full size image from a thumbnail, my paragraph translates into comments as:
// actions for clicking on a button
// zoom in on image
Research syntax. Just because you’re unfamiliar with syntax doesn’t mean that you can’t program in it. Seriously. The first 2 steps are the hard part. Once you can visualize what the code should do, use the help files, the internet, books, and friends to help you to figure out the best way to accomplish what you’ve decided while planning and commenting.
Write syntax. Finally, dive right in. Try writing snippets of code. Even if they don’t work initially, it’s useful to become familiar with the environment that you’ll be working in. Along with learning how to comment, associate yourself with the typical ways to debug a file in the language that you’re writing in. Very seldom will a developer write clean, working code the first time around, so don’t be discouraged if it doesn’t work without a little bit of work.
Just a note: most, if not all, of these techniques are usually taught in almost any “Intro to programming” course. But, like other skills, many people forget the fundamentals as they progress in more complicated and advanced projects.
This isn’t designed as an end all guide to program, and, like anything, the biggest piece of advice is to get your hands dirty. This should get you started if you’ve been looking for a jumping off point for starting to code, and, even if you’ve been at it for a while, I hope you can find some inspiration on how to approach a project differently.
The next part of this series will be a designer’s look specifically at syntax on a conceptual level. It will be an overview of loops, conditions, functions, and recursion. Feel free to let me know if there are any other topics that I should cover in part 2.
Update: Part 2 has been posted.