Is there a process, tool, prefered method to describe css animations, forwards and backwards, before you start coding them? I lose a lot of time describing the animations and/or picking up feedback for them and then, if someone did not visualize them correctly or had a different idea, we have to make changes, which remain as vague as before, until you finished coding them.
6
-
2when you say animation, you mean transitions like buttons, dropdowns or different elements, or real animations like character motion?– DevinAug 24, 2015 at 21:49
-
2Related: Standard notation for describing UI– Graham HerrliAug 24, 2015 at 22:22
-
2If this is a common dilemma I suggest making a style guide/portfolio type list of common animations (spinners, bounces, fades, collapses, etc.) that way your clients or whoever you may be describing these animations to can get an idea of what it will look like and simply point to what they want and tweak as necessary.– DasBeastoAug 24, 2015 at 23:16
-
@Devin: Yes, I meant menu bars, dropdowns, logo scaling, etc.– MauFAug 25, 2015 at 13:29
-
@GrahamHerrli: Very complete, thanks. I'll see what I can use effectively from that very long post.– MauFAug 25, 2015 at 13:30
|
Show 1 more comment
5 Answers
One word for you: storyboards.
I need to write an article about this. But here's what a good storyboard looks like as a jumping off point:
Notice: two colors, one for actions, one for animations. The description below each wireframed panel describes what moves when why.
You'll work off these, and things are bound to change as you enter dev, but for documentation, you'll want to add duration, easings, and properties. These are fantastic design artifacts for communicating to dev and deferring to when incorporated in design documentation.
-
This is good, but tedious--especially when iterating, and ultimately is still open to interpretation. It can work, but I strongly suggest to people that they just dive in and built the actual interaction...it often takes the same amount of time anyways.– DA01Sep 8, 2015 at 22:03
-
Might be tedious, but never as tedious as what I currently have to endure when explaining interactions and animations to clients. This looks as my best altenative yet.– MauFSep 9, 2015 at 15:35
-
To be fair, good documentation is often tedious. But if it lets the developers get it right on the first try and keeps things consistent from team to team, it pays off in the long run. That said, I know others who go from rough storyboard, to video, to finalized storyboard with videos as co-deliverables. A tool that exports both would be lovely. Until then... Sep 9, 2015 at 22:43
-
If you're dealing with multiple teams, it's sometimes a necessary evil, but I still say "code as documentation" is much more maintainable and usable by all parties. It also allows for more flexibility for change going forward. In an agile dev environment it's especially important to keep things flexible if possible. (FWIW, I really like the style style of your storyboards!)– DA01Sep 9, 2015 at 23:09
-
As for making videos...that seems like way more work than just building things in code in the first place. But I suppose it all depends on the specifics...– DA01Sep 9, 2015 at 23:10
A good way? No. Any verbal or text description will be open to interpretation.
Methods that could work would include front end prototyping and/or pair programming.
-
I am familiar with prototyping, but not with pair programming. I'll look into it, thanks.– MauFAug 25, 2015 at 13:31
If you are trying to communicate with a developer, you might look to the documentation of whatever they are using to code the animations. For example, you could describe CSS animations in terms of keyframes, repetitions, timing, delay, etc.
I've always preferred to prototype. Using something like Axure or Hype Studio, you can approximate many animations. Even Apple Keynote can do a lot of animations. You could use drawings on paper to show the developer what you want, too.
answered Aug 24, 2015 at 21:51
-
Not bad. However, I would like to find a tool or language that developers or not, might understand. It's very likely that that langague is a very thorough description of the animations, but now you've given me an extra pointer by using the keyframes, repetition, timing and delay properties as well. Thanks.– MauFAug 24, 2015 at 22:51
-
1If you're going to talk about animation in the level of detail such that you need to talk about keyframes, repetition, timing, or delay; the best language to do that is actually CSS itself. If you need to talk in that level of detail, you might as well just build an actual prototype.– Lie RyanSep 9, 2015 at 1:55
-
I'm with @LieRyan on that. At a certain point, it makes a whole lot more sense to just build the actual interaction in the medium it's going to be used in.– DA01Sep 9, 2015 at 23:10
If it's a standard animation, use the terms from the Javascript or CSS library the developer is working with. If the animation is not covered in the library lexicon, you could look for similar animations in one of the many styleguides, for example, iOS (https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/Animation.html#//apple_ref/doc/uid/TP40006556-CH57-SW1).
If it's a really unique behavior, you could do an Axure prototype, as suggested above, or a storyboard to show each step of the animation. Developers are great at following instructions, but if you don't provide really detailed instructions, don't be surprised when you get something different than what you had imagined.
-
Axure prototypes don't work great for subtle animation. You end up making more of an 'axure' interaction than a true 'web interaction' a lot of the time.– DA01Sep 8, 2015 at 22:02
I find the quickest method is to prototype the desired effect in a tool such as Axure, Framer JS, etc. and then record an animated gif using LICEcap.
Here's an example from a recent "Streaming Activity Panel" specification I completed using Axure and LICEcap:
Then it's up to you to decide how much narrative to provide along with the actual animated image. I tend to under-specify animation timings (e.g. 300ms) and animation transition timings (e.g. ease in/out), since such details are going to be subject to scrutiny during design review.
-
Axure can be tricky, though. It's certainly a good prototyping tool, but the interactions you create in Axure tend to be 'axure interactions' and I've run into situations where developers have actually written excessive code to emulate the specifics of an Axure prototype, rather than just leveraging the interactions that were built into the UI framework they had. This, obviously, isn't the fault of Axure, but poor communication. Just be sure to be clear to developers that the Axure prototype is what you'd like, but they should work with you as needed to make sure optimal decisions are made.– DA01Sep 9, 2015 at 1:22
-