
I am a visual learner. This fact has made it challenging for me, and other designers, to pick up development whether it be ActionScript, JavaScript, CSS, or any language or mark up that results in a visual interactive interface. This right brain mentality is arguably why so many graphic and web designers stopped adopting ActionScript with the advent of ActionScript 3.0. ActionScript became more strict, more verbose, and prefers the use of Class-based OOP development over code strewn across the timeline.
This post isn’t about picking up development of any type of language, but more about the Math involved. Math makes sense, it has rules that can’t be broken and it is the main key for making interactive animated applications run. As a designer you know how an interface is supposed to work and how it is supposed to look. You know what needs to happen when the user presses, drags, or interacts with your interface. What you don’t know, usually, is the math to get it to do what it’s supposed to. My advice is to use what you know as a designer and open the sketch book! I solve many more math problems on paper than I do with a calculator, the visual approach works for me. I picked a random sampling from my sketch book and have posted a slideshow; this contains (mostly) sketches that have helped me solve so many walls that I’ve hit with math. I had the idea to post these when thumbing through my sketch book and noticing how many of the sketches appear very similar. Lots of boxes, dots, and lines to solve many unique and distinct problems. I came to the conclusion that all my sketches are visual solutions based on two main items. Points: the x and y positions of anything within my application. And boxes or frames rather: where an object is a one point in time, and where it needs to be at another point in time. Also, the sketches help me visualize where multiple objects are when one other object comes into view. When that visual connection is made, that is the point where I can solve the math to get an object from point A to point B and deal with all the other objects not in view.
You can have a look at these random sketches here.
Sketches and Math
I am a visual learner. This fact has made it challenging for me, and other designers, to pick up development whether it be ActionScript, JavaScript, CSS, or any language or mark up that results in a visual interactive interface. This right brain mentality is arguably why so many graphic and web designers stopped adopting ActionScript with the advent of ActionScript 3.0. ActionScript became more strict, more verbose, and prefers the use of Class-based OOP development over code strewn across the timeline.
This post isn’t about picking up development of any type of language, but more about the Math involved. Math makes sense, it has rules that can’t be broken and it is the main key for making interactive animated applications run. As a designer you know how an interface is supposed to work and how it is supposed to look. You know what needs to happen when the user presses, drags, or interacts with your interface. What you don’t know, usually, is the math to get it to do what it’s supposed to. My advice is to use what you know as a designer and open the sketch book! I solve many more math problems on paper than I do with a calculator, the visual approach works for me. I picked a random sampling from my sketch book and have posted a slideshow; this contains (mostly) sketches that have helped me solve so many walls that I’ve hit with math. I had the idea to post these when thumbing through my sketch book and noticing how many of the sketches appear very similar. Lots of boxes, dots, and lines to solve many unique and distinct problems. I came to the conclusion that all my sketches are visual solutions based on two main items. Points: the x and y positions of anything within my application. And boxes or frames rather: where an object is a one point in time, and where it needs to be at another point in time. Also, the sketches help me visualize where multiple objects are when one other object comes into view. When that visual connection is made, that is the point where I can solve the math to get an object from point A to point B and deal with all the other objects not in view.
You can have a look at these random sketches here.