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.

  • 2
    when you say animation, you mean transitions like buttons, dropdowns or different elements, or real animations like character motion? – Devin Aug 24 '15 at 21:49
  • 2
    Related: Standard notation for describing UI – Graham Herrli Aug 24 '15 at 22:22
  • 2
    If 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. – DasBeasto Aug 24 '15 at 23:16
  • @Devin: Yes, I meant menu bars, dropdowns, logo scaling, etc. – MauF Aug 25 '15 at 13:29
  • @GrahamHerrli: Very complete, thanks. I'll see what I can use effectively from that very long post. – MauF Aug 25 '15 at 13:30

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:

A storyboard showing how an arrow should react to being hovered and clicked upon.

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. – DA01 Sep 8 '15 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. – MauF Sep 9 '15 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... – Rachel Nabors Sep 9 '15 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!) – DA01 Sep 9 '15 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... – DA01 Sep 9 '15 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. – MauF Aug 25 '15 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.

  • 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. – MauF Aug 24 '15 at 22:51
  • 1
    If 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 Ryan Sep 9 '15 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. – DA01 Sep 9 '15 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. – DA01 Sep 8 '15 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:

Streaming Activity Panel

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. – DA01 Sep 9 '15 at 1:22
  • Great point @DA01. – Brad Ledford Sep 9 '15 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.