This is actually an old version of danielmall.com. For the latest and greatest, check out the new site.
 

Programming Like a Designer, Part 1

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.

But where do you get started? This primer is designed for people that are just starting to program in (close to) object-oriented languages, such as C++, Actionscript, or Javascript, but even experienced programmers may appreciate this as a high level perspective on coding. For the purposes of this demonstration, let’s use a hypothetical situation that you’re building a portfolio site in Flash. These techniques will use Flash syntax, but the concepts can easily be applied to any language. Let’s assume that the design is done and ready to be built. Where should you begin? What steps should you take?

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.

Comments

Rob Weychert said:

Handy tips, Dan, especially for someone like me who has had no formal training in programming. As obvious as starting with plain English is, itís an easy idea to overlook.

Posted on August 5, 2005 11:43 PM

Jon Aldinger said:

Mmmmmmm, recursion. I think it may help those starting out if you create an expression in plain English and then show the syntax of that expression in the example languages; just to give a visual representation of what syntax actually is and how it is translated from English to one programming language to the next.

Posted on August 5, 2005 11:43 PM

Jervis Thompson said:

Great article Dan. I would just like to add one item based on my humble years of experience. Under "Write syntax" please add, "test as you write". You can cut your development time in half using a simple output commands (i.e. "alert" in JavaScript, "trace" in ActionScript, and / or "put" in lingo) to confirm that your code is working the way you want, as you write it. I've seen new as well as experienced (dare I say) programmers write 50 plus lines of code and then spend hours rewriting their code to try and get it to work correctly only to find out that the "function / event" that they put the code in was not even being called in the first place.

// actions for clicking on a button
on (release) {
trace ("zoom button released");
//blah blah lines of code;
}

I hope this helps. Keep it coming Dan 8-)

Posted on August 5, 2005 11:44 PM

Dan Mall said:

Great suggestion, Jervis. I'll definitely add "debugging" to the list of examples for part 2 of this article.

Posted on August 5, 2005 11:48 PM

Avis Grandon said:

If you have a newsletter I sure would like to get it.

Thanks,
LadyAvis

Posted on August 5, 2005 11:50 PM

Sorry: comments are closed.