原文：https://medium.com/@pasql/the-state-of-interaction-design-tools-f755c6515368
The state of Interaction Design tools
The current state of tools is decent, but how they fit together is less than ideal.
Pull up a chair & get your butt cheeks comfortable, because this will be a comprehensive mind explosion.
Animation is really, bloody hard. Furthermore, the idea of using animation in the context of interactive design is really new for manyseasoned designers. As I see more people warm up to the concept ofTransitional Interfaces, I get excited, but equally frustrated. The tools are still not good enough.
My background in animation gives me the advantage of software tool knowledge, which I’ve learned to transpose over to interface thinking… but most designers don’t come from this background. As a result, it’s harder for designers to explore the fundamentals of animation. Their animation looks malnourished standing next to their outstanding static design efforts. Designers end up using wonky tools, sucking them into making generic, stiff, & mushy spring-physics driven garbage (yuck!). At the other end of the spectrum, the tools built for traditional animators are complicated power-tools for a different scope of problems, with an unfriendly learning curve.
We currently have a few major schools of thinking. They roughly fall into 3 categories: Timeline, Signal Flow & Code.
Timeline
A linear approach to animation — and the purest form. Much of timeline animation is designing states, then wrestling with a computer to design the inbetweens so it moves with a designed intention. Good timeline animation is designed animation. It is not left to the whims of a computer to simulate sensible & pleasing animation timing. It is controlled & opinionated, but comes with the cost of being non-dynamic. It’s great for illustrating the result of basic interaction, without spending the time fooling around with the intricacies of capturing a plethora of events. Wiring up the subtleties of dynamic animation makes no sense if the foundation of timing is off. In a linear method of thinking, the inherent focus is the animation timing and not much else.
Adobe After Effects
After Effects is an extremely powerful package, but is fundamentally built for video, motion graphics & compositing work. This creates The PhotoshopKitchen Sink Effect™ where the new user is punched in the eyeballs with an interface full of mostly irrelevant horseshit, that is not useful for anything. Once the user learns they only need 20% of the tools, they stop crying themselves to sleep at night like a little bitch. (That was how I learned After Effects)
Once you get over the overwhelming interface, making a composition is lightning fast, because you are immediately designing animation, with little, to no rigging. It doesn’t have to function. It doesn’t have to have logic driving it. It’s just the essence. Handing off a video render to an engineer who has basic animation understanding can get you pretty far for many common animation/interaction patterns, but not so much for ideas needing tactile interface feedback.
Adobe Edge Animate(it’s pretty terrible)
Some timeline tools do some basic triggering of timeline chunks based on conditional triggers, but the animation timing tools are weak and they spit out horrifyingspaghetti code.
- Adobe Edge Animate
- Google Web Designer
- Hype
The new timeline tools seem be missing the point. They all seem like watered down versions of Flash. As Paul Neave reminded me, the Flash era of design was a magical time which we’ve lost. Front-end developers got balls-deep in ActionScript, working in tandem with a timeline interface. We ditched it because we wanted to say farewell to a proprietary runtime, but not because of the workflow. When Flash died, so did the ideas around blending manual animation with code.
We’ve seen a huge push towards using simulated interaction tools such asQuartz Composer. Facebook Home was a significant leap in the direction of using a Signal Flow approach to designing interactions. The result is a new world of playful, and responsive animation, driven by user input.
However, in thinking about Signal Flow, one cares less about designing with good animation timing, and more about tuning knobs and dials to get a simulation right. Is this bad? To me, it’s zooming into specific, tiny details early on, rather than considering the generality.
Dynamic animation is strengthened by a foundation of good timing to drive it. Springs can be beautifully simulated, but if the underlying animation driving them is poorly timed, the whole thing falls apart. It’s a little too close to implementation than it is to design, and can be a trap to spend time towards early on. As designers fumble around with dynamic tools, I’m seeing too much simulation, and less opinionated articulation that is designed. The result is a clumsy interface with over-animated action that’s distracting. Signal Flow is powerful, but it’s just one piece of the puzzle.
Code
If you haven’t played with Framer, I thoroughly endorse it. As someone who prefers to work visually, Framer does a pretty decent job at giving me live feedback when writing JavaScript. It’s probably the only code-based tool I’ve been ok with wrapping my head around. There’s a ton of great little helpers to create animation patterns, nest things in parent/child views, etc.
Framer is great, but it comes with the high cost of having to switch mental context, away from directly manipulating objects in a spatial plane, and into the abstracted world of a DOM. You don’t get to design animation, but you get to design events. Unlike Signal Flow, you can easily define logic blocks and think in terms of OOP. Good for designers willing to wrap their head around engineering concepts, but not so much for the ones without engineering chops.
Writing code can be cumbersome when trying to solve a visual problem. It’s a big challenge to take vivid, organic ideas bouncing around the human brain, and express it with the terseness of code. It’s more natural to think about solving a visual problem in a visual context.
This other thing which doesn’t have a name
http://www.colmtuite.com/a-better-prototyping-tool
There’s also this context of thinking which doesn’t have a name yet. I’d love to know a good title for it. Perhaps an “Event Editor”? I fondly remember building games in a similar mode of thinking using Klik & Play back in Junior School. It was an expressive and easy way of describing something very complex.
So where does this leave us? Well we have a variety of contexts to think in, but no common bridge to connect the ideas together. Some problems are best served to be solved in a specific context, or a combination of contexts. We need to consider the option of using a spectrum of complementary tools, rather than just one. We don’t need a new hammer, we need a toolbox.
原文：https://medium.com/@pasql/the-state-of-interaction-design-tools-f755c6515368
The state of Interaction Design tools
The current state of tools is decent, but how they fit together is less than ideal.
Pull up a chair & get your butt cheeks comfortable, because this will be a comprehensive mind explosion.
Animation is really, bloody hard. Furthermore, the idea of using animation in the context of interactive design is really new for manyseasoned designers. As I see more people warm up to the concept ofTransitional Interfaces, I get excited, but equally frustrated. The tools are still not good enough.
My background in animation gives me the advantage of software tool knowledge, which I’ve learned to transpose over to interface thinking… but most designers don’t come from this background. As a result, it’s harder for designers to explore the fundamentals of animation. Their animation looks malnourished standing next to their outstanding static design efforts. Designers end up using wonky tools, sucking them into making generic, stiff, & mushy spring-physics driven garbage (yuck!). At the other end of the spectrum, the tools built for traditional animators are complicated power-tools for a different scope of problems, with an unfriendly learning curve.
We currently have a few major schools of thinking. They roughly fall into 3 categories: Timeline, Signal Flow & Code.
Timeline
A linear approach to animation — and the purest form. Much of timeline animation is designing states, then wrestling with a computer to design the inbetweens so it moves with a designed intention. Good timeline animation is designed animation. It is not left to the whims of a computer to simulate sensible & pleasing animation timing. It is controlled & opinionated, but comes with the cost of being non-dynamic. It’s great for illustrating the result of basic interaction, without spending the time fooling around with the intricacies of capturing a plethora of events. Wiring up the subtleties of dynamic animation makes no sense if the foundation of timing is off. In a linear method of thinking, the inherent focus is the animation timing and not much else.
Adobe After Effects
After Effects is an extremely powerful package, but is fundamentally built for video, motion graphics & compositing work. This creates The PhotoshopKitchen Sink Effect™ where the new user is punched in the eyeballs with an interface full of mostly irrelevant horseshit, that is not useful for anything. Once the user learns they only need 20% of the tools, they stop crying themselves to sleep at night like a little bitch. (That was how I learned After Effects)
Once you get over the overwhelming interface, making a composition is lightning fast, because you are immediately designing animation, with little, to no rigging. It doesn’t have to function. It doesn’t have to have logic driving it. It’s just the essence. Handing off a video render to an engineer who has basic animation understanding can get you pretty far for many common animation/interaction patterns, but not so much for ideas needing tactile interface feedback.
Adobe Edge Animate(it’s pretty terrible)
Some timeline tools do some basic triggering of timeline chunks based on conditional triggers, but the animation timing tools are weak and they spit out horrifyingspaghetti code.
- Adobe Edge Animate
- Google Web Designer
- Hype
The new timeline tools seem be missing the point. They all seem like watered down versions of Flash. As Paul Neave reminded me, the Flash era of design was a magical time which we’ve lost. Front-end developers got balls-deep in ActionScript, working in tandem with a timeline interface. We ditched it because we wanted to say farewell to a proprietary runtime, but not because of the workflow. When Flash died, so did the ideas around blending manual animation with code.
We’ve seen a huge push towards using simulated interaction tools such asQuartz Composer. Facebook Home was a significant leap in the direction of using a Signal Flow approach to designing interactions. The result is a new world of playful, and responsive animation, driven by user input.
However, in thinking about Signal Flow, one cares less about designing with good animation timing, and more about tuning knobs and dials to get a simulation right. Is this bad? To me, it’s zooming into specific, tiny details early on, rather than considering the generality.
Dynamic animation is strengthened by a foundation of good timing to drive it. Springs can be beautifully simulated, but if the underlying animation driving them is poorly timed, the whole thing falls apart. It’s a little too close to implementation than it is to design, and can be a trap to spend time towards early on. As designers fumble around with dynamic tools, I’m seeing too much simulation, and less opinionated articulation that is designed. The result is a clumsy interface with over-animated action that’s distracting. Signal Flow is powerful, but it’s just one piece of the puzzle.
Code
If you haven’t played with Framer, I thoroughly endorse it. As someone who prefers to work visually, Framer does a pretty decent job at giving me live feedback when writing JavaScript. It’s probably the only code-based tool I’ve been ok with wrapping my head around. There’s a ton of great little helpers to create animation patterns, nest things in parent/child views, etc.
Framer is great, but it comes with the high cost of having to switch mental context, away from directly manipulating objects in a spatial plane, and into the abstracted world of a DOM. You don’t get to design animation, but you get to design events. Unlike Signal Flow, you can easily define logic blocks and think in terms of OOP. Good for designers willing to wrap their head around engineering concepts, but not so much for the ones without engineering chops.
Writing code can be cumbersome when trying to solve a visual problem. It’s a big challenge to take vivid, organic ideas bouncing around the human brain, and express it with the terseness of code. It’s more natural to think about solving a visual problem in a visual context.
This other thing which doesn’t have a name
http://www.colmtuite.com/a-better-prototyping-tool
There’s also this context of thinking which doesn’t have a name yet. I’d love to know a good title for it. Perhaps an “Event Editor”? I fondly remember building games in a similar mode of thinking using Klik & Play back in Junior School. It was an expressive and easy way of describing something very complex.
So where does this leave us? Well we have a variety of contexts to think in, but no common bridge to connect the ideas together. Some problems are best served to be solved in a specific context, or a combination of contexts. We need to consider the option of using a spectrum of complementary tools, rather than just one. We don’t need a new hammer, we need a toolbox.
2262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
