A question that has been debated for a long time in professional web-design circles is “Do designers need to learn code (HTML/CSS)?” Many articles have been written on this topic, and the debate will surely go on. Here are a few article examples:
• How Much Code Should Web Designers Need to Know?
• How Much Code Should Designers Know?
• Why Designers Should Learn How to Code
Annabelle Gould wrote a great article on the AIGA Design Educators Community web site titled “What We Don’t Teach—But Should”. In her fifth talking point, Des007 (Design + Technology), she wrote: “But many attempts to introduce coding and basic programming have yielded mixed results. It takes time to learn code, which, depending on how you look at it, might be better spent developing stronger visuals or better concepts.”
Gould makes a great point that when coding isn’t taught in a design curriculum, it is often sought out somewhere else. I see it all of the time: design educators teach aesthetics primarily grounded in print design and then send their students to a computer-science class to learn code. At some point, like a peanut butter and jelly sandwich, the student is supposed to slap the two together and—poof—web design. Best-case scenario: the classes are taught at the same time and the professors actually work with each other during this process. At the other end of the spectrum, students complain that the computer-science teacher doesn’t understand design, or coding was too difficult, and then their portfolios end up lacking any true interactive designs.
I believe design educators can discuss interactive theory without becoming coding experts and still allow students to embrace interactive design. First, we need to redefine the term code. I like to refer to HTML/CSS as a basic markup language. Coding (C++ or Java) to me is something that a computer-science student uses to program applications. In my personal opinion, markup language should be taught somewhere in the design curriculum, not just in computer science. In general, design students learn HTML/CSS to understand the limitations of web design. However, a course solely about HTML/CSS does not reinforce principles of interactive design—principles that students can take with them long after markup language standards have evolved. A lot of these principles are being taught in design courses right now; these principles just have to be applied to an interactive context. The following are just a few of the interactive theories that can be discussed before any markup language is written.
Design Constraints
Design constraints help shape the boundary of the process and materials in which a project can be produced. Constraints can be found in many different ways: cost, materials, time, or even the amount of people available to produce. In print design, a constraint can be the amount of colors in a design that reflects the cost. The more colors you use, the more costly to produce. Some companies and organizations cannot afford a four-color process design, so many design educators define projects with only two colors. This activity forces students to think about the limitation of colors, and the effects on printing and branding recognition. Similarly, within web design, I often discuss the theory of normal document flow to communicate the design constraint for the web. A browser renders information from top to bottom, unless tags are used to float elements to left or right of another element. This explanation is one of the reasons why web pages are structured into column-based layouts. Discussing design constraints in web-design classes in relationship to print-based projects can help transition the mindset of a student from static to interactive design.
Here is an example of normal document flow in a web page. The image on the left has no page styling, and all the content is flowing straight top to bottom. The image on the right has page styling with division of areas floated next to each other, breaking up the normal flow of content.
Functionality
Package design is a traditional class that many design programs have and forces students to think in multiple dimensions. The designer must understand how each side relates to one another, how the folds and tabs interact, and how the package is placed in context. While professional package designers deal with type, color, and layout, they won’t actually print each package, fold, and build it. Similarly, in many cases, a web designer may never actually touch a piece of HTML/CSS and will only develop a mockup in Photoshop to hand off to a developer to build. However, if there isn’t a proper understanding of functionality, we return to the peanut butter and jelly analogy, slapping two things together and hoping they work. Again, I have seen this turn out badly, where the developer fills in all of the blanks and the designer is upset how it didn’t turn out the way he envisioned.
An example of functionality that I introduce to my interactive classes is button states. The static/up state is when the button is untouched. The hover/rollover state is when the mouse interacts with the button. The click state is when the mouse is actually being clicked down. The visited state is the user returns to that page, and the button/link shows a different color that has been viewed. The designer should always specify these states in the design document, review it with a developer in the hand-off meeting, and show it in context with a mouse/hand, so that it is not missed. Even though my students code their own web sites, I have them mock in mouse interaction to show functionality in all stages of the design to reinforce good practice.
Web Standards
In wayfinding, designers must recognize ADA standards when developing signs, type sizes, and placement; these standards do not mean designers have to limit their creativity—they just have guidelines to follow to direct the users that will be interacting and exploring the building. Similarly, the web community has a set of web standards developed by the Wc3. I have to be honest—these standards are a source of debate in the web-design community. Some companies hold tight to web standards recommended by the governing agency Wc3, and others use new technology well before they are approved for web standards. The major point of web standards is to guide the web community on what to use and when. If a designer decides to ignore basic web standards, then he runs the risk of his designs not working in certain browsers.
I can’t stress it enough that interactive theories have to be addressed and that a design educator can’t assume that other educators will explain these theories. We can’t separate design and technology; interactivity brings both together, and that is the way we have to teach, like it or not. In many ways, we have been teaching design constraints, functionality, and design standards for a while now. We just have to adapt a little.
What type of theory do you discuss in your interactive projects? How do you handle merging design and technology in your curriculum?
James Pannafino is an associate professor at Millersville University, Pennsylvania in the Art and Design Department where he teaches graphic and interactive design courses. James recently published Interdisciplinary Interaction Design: A Visual Guide to Basic Theories, Models and Ideas for Thinking and Designing for Interactive Web Design and Digital Device Experiences. www.interdisciplinaryinteractiondesign.com