Limitations of Drag And Drop animations in Flex
Sunday, November 11th, 2007One of the key benefits of using Flex for the end user is a consistent experience when interacting with on screen elements. While the look/skin can vary greatly, the underlying behaviours remain consistent, making the site or application more usable. While Flex provides a default implementation to each step in an interaction, it generally allows customization of the visual state through the various events associated with each component type. Hence we have custom animations and transitions between states to implement the most appropriate behaviour in an individual project.
A good example of this is Flex’s inbuilt Drag and Drop. Generally on the web, drag and drop functionality varies greatly from implementation to implementation. Many cases don’t provide enough visual feedback to the user to fully utilise the benefits of a drag and drop system – easy, direct manipulation of information on screen.
Drag and Drop functionality within Flex is pretty solid. It works out of the box with inbuilt components, and adding it to custom components is relatively straight forward (once you understand the order of all the events in a drag-drop interaction by reading this PDF- http://blogs.adobe.com/flexdoc/pdf/dragdrop.pdf). It also allows for a reasonable amount of customization to the visual states during a drag-drop process, with the exception below.
Flex provides two possible behaviours when an object is dropped:
- The drop is rejected and the dragged item animates back to it’s original position
- The drop is accepted and the dragged item animates into the new position.
These behaviours are correct, however there is no means to override the actual animations that occur as a result of these behaviours, so we are stuck with the following “zoom to mouse position” transition when a drop is accepted (from mx.managers.dragClasses.DragProxy) :
// Zoom into mouse location to show drag was accepted.
var e:Zoom = new Zoom(this);
e.zoomWidthFrom = e.zoomHeightFrom = 1.0;
e.zoomWidthTo = e.zoomHeightTo = 0;
e.duration = 200;
e.play();
var m:Move = new Move(this);
m.addEventListener(EffectEvent.EFFECT_END, effectEndHandler);
m.xFrom = x;
m.yFrom = this.y;
m.xTo = parent.mouseX;
m.yTo = parent.mouseY;
m.duration = 200;
m.play();
This transition may work well when dragging data from one list to another (which is the most common use case when using the inbuilt components), but can look a bit much when dragging a large container around the screen.
You drag an object from one area of the screen to another, and when you release the mouse it scales down into obscurity before appearing in its new position. There should be a means to override this default effect.
In this example try dropping the item in the bottom right corner of one of the (white) drop areas. This transition looks wrong as the mouse coordinates are not always the intended final destination of the dropped object.
Basically there should be some way to define or override the animation that occurs on a successful drop event. It seems surprising that this animation is hardcoded within the framework, while every other visual state during the drag/drop operation is customisable.
I know it is hardly a show stopper, but I’ve submitted an enhancement request to the Flex Bug and Issue Management System (https://bugs.adobe.com/jira/browse/SDK-13472) as it is an UI issue that has already arisen in one of our commercial projects.
– D
