- Walk through of the Liquid Fire library, demos and source for creating animated transitions
- Some limitations (when should you use the library vs CSS only transitions)
- Examples of adding animated transitions to an existing application
In an app built with Ember changes from bindings and observer trigger redrawing view which can happen fast, adding some transitions can help guide user from screen to screen.
There is enough content from the library author to dissect and present what you need to know to get started with adding animated transitions to an Ember app.
The contents of this presention are mostly highlights from the documentation, demo and tutorial content published by the library authors of Liquid Fire and Velocity.js
Audience: Developers who work with an Ember app and what to add animated transitions
- May already be familiar with Edward Faulkner’s work and presentations from EmberConf 2014 video or the video from the July Boston Ember Meetup when he launched Liquid Fire.
- Can view those talks on their own, this presentation will focus on practical examples walking the audience through the steps to implementing animated transitions in an existing app.
Liquid Fire is a toolkit for managing animated transitions in an Ember application. Like Ember itself, our goal is to cultivate shared abstractions so we're free to focus on bigger and better ideas. Good defaults. Convention over configuration.
- Transitions need to be implemented within the view layer, but deciding what kind of transition to do at any given time is a higher-level question, dependent on the relationships between different routes and models
- Three key pieces: template helpers, the transition map, and transitions
Template Helpers consult your application's transition map, and if they discover a matching transition, they give the transition control over both the old and new content simultaneously (e.g. {{#liquid-if}}
)
Transition map is analogous to your normal Ember router map. It's a single place to declaratively capture rules about how the pieces of your application relate to each other.
Transitions are implemented with a promise-based API that gives you control over all the relevant timing, including when to insert the new view into the DOM and custom transitions
Velocity is an animation engine that re-implements jQuery's $.animate() for significantly greater performance (making Velocity also faster than CSS animation libraries)
- See the Velocity.js Docs
- Velocity.js tutorial "Faster UI Animations With Velocity.js" by Julian Shapiro
Below are are points made in the tutorial by @shapiro...
- Improved feedback loops - Use patterns as much as possible since users will be subconsciously looking for them
- Seamless content transitions - Avoid contextual breaks e.g. modals fading in and out
- Filled dead spots - Diverting a user’s attention is a great way to make a pot boil faster
- Aesthetic flourishes - Refined products simply feel superior
UI effects may be chained onto each other and may take options
Effects that call attention to an element in order to heighten user experience, such as shaking an element to indicate an input error
Effects that cause an element to appear in or out of view. Every transition is associated with either an “in” or “out” direction
A few considerations
- Make them finish quickly
- Use an appropriate effect
- Use them sparingly
- Avoid extreme repetition
- Experiment
Simple Animated Bind
Animated If
Route Transition
Context Dependent
So you want to add another library to your Ember App?
- Choose either the ember-cli addon or the globals distribution of the Liquid Fire build
- Add Velocity.js
- Add Velocity.ui.js, to use pre-defined animations, e.g. shake, bounce
- You're app likely already uses CSS transitions, keep or redo?
- What is the happy path when using Liquid Fire?
- How about directly calling Velocity methods, it's a dependency anyway?
- Based on the liquid helpers you have -if, -with, -bind, -outlet
- Boolean property change animates between if/else
- With context animates between models
- Binding to a property changes animate between the values
- Animate between route changes within an outlet
- Using the helpers takes over your view's presentation a bit
- Using an -if helper with chained properties can lose context or throw errors
- "Failed to execute 'insertBefore' on 'Node': The new child element contains the parent."
- "Assertion Failed: Cannot call get with 'isDragging' on an undefined object.”
- "Error: Assertion Failed: Cannot call get with 'error.klass' on an undefined object.
- Can use the Handlebars
with
helper and useEm.computed.readOnly
in your view if needed to work around- View may need access to controller state within the -if helper
- Animate property changes (liquid-bind) with care, perhaps best with
fade
transition
- Keep your existing CSS transitions
- Add to your transistions from the Velocity.js UI pack, e.g.
bounce
,shake
- Use a state machine to make property changes that can be used to bind a css class or observed to call a Velocity callout or transition
The sweet spot for Liquid Fire is animating transition between bindings, i.e propery, model or route changes.
Use CSS only for adding transitions/motion to elements that don't change, perhaps only show/hide, i.e. a modal window (Liquid Fire does have a modal, but you already do too).
We use a droppable controller/view for users to upload text files with a list (white/black) of hashes.
- Show the upload modal view
- Drop a file into the app from your desktop
- Check for supported file types
- Upload the file
- Evaluate the contents and return results
- Save the hash list or cancel (bail out)
The file may be a small text file can can upload super fast, the user may not even notice the change from "selecting" a file to upload, and "uploading". The change to display an "error" may also appear to have skipped the "uploading" step. Following a successful upload the user sees an "outcome" (2 bad 2 good) and then may save or cancel the creation of the hash list.
Since Ember bindings and observers work so we we often use them to render the various templates in a workflow.
But is that good UX?
- Would the UX be improved to slide into the upload tool, and perhaps side out when done?
- Can we improve the workflow feedback, 1-select, 2-upload, 3-outcome, 4-save/cancel
- How about interrupting the workflow with an error? When did the error occur between select and upload? Or between upload and outcome?
- Perhaps we set a minimum transition timing between the steps
- Perhaps the contents of the upload modal can animate/transition between the steps as an indicator of progress. We love progress right? How about slide to the left (exit stage right)?
- Perhaps we shake it up when there is an error to get the user's attention. (They may do this all day)
- And how about some aesthetic highlights? Drop in a window and bounce it (like the ball on New Year's Eve).
- Liquid Fire, Docs,
- Liquid Fire demo, source
- Videos: EmberConf 2014 video, Boston Ember Meetup
- Velocity.js, Docs
- Velocity.js tutorial, UI pack
- Edward Faulkner - Liquid Fire
- Julian Shapiro - Velocity.js
- @pixelhandler
- pixelhandler on IRC: #emberjs, #emberjs-dev, #ember-cli, #orbitjs
- pixelhandler.com/about
The links under
Key Ideas
do not work (404) :(http://ef4.github.io/liquid-fire/#/helpers