Usability of custom cursors in Flash and Flex
Custom cursors offer tactile feedback to users of an application about what operations are possible on the underlying component as well as the state of the application. The busy cursor encourages the user to wait for an operation to complete while the hand cursor informs them that this user interface component will respond to their mouse clicks. However, there are unique problems with the custom cursor implementation in the Flash player.
The Flash player utilizes a rendering pipeline that is affectionately referred to as the elastic racetrack. The racetrack represents an infinite loop of processing in which one lap around the racetrack represents a single frame of animation. The Flash player is deliberately single threaded and therefore if an operation takes up a significant portion of time the racetrack can lengthen, the framerate will decrease, and users will notice the application becoming unresponsive.
Most rendering pipelines have an issue such as this, however the Flash player's single threaded nature and the general difficulty of deferring work from one frame to the next causes this to be particularly noticeable. A typical desktop application may also enter a long period of single threaded processing, however this behavior does not negatively impact the mouse cursor. The reason is that most desktop applications modify the system cursor which is not rendered by the application's render loop, but is handled by the operating system in a more robust fashion. Flash player, however, renders its custom cursors using its own render loop - so a long running operation will cause the mouse cursor to stick, jump, and disappear.
This is obviously a very jarring and frustrating experience to most users. Due to the typical behavior of desktop applications, most users will interpret the jumping or nonexistent cursor as an application crash rather than simply a long running operation. This is particularly complicated in the Flash player as the busy cursor is also rendered by the Flash render loop and also suffers from these limitations.
There are two ways to address this problem. The first is to pay careful attention to the processing time of any code in your application. This is a common suggestion, but one that is not trivial for most developers. This is complicated further by the issue that even if an operation is determined to be taking too long there are limited options available to the developer. The developer can first try to optimize the operation as much as possible so that it does not take so much time. This is the most direct approach and often leads to good results. The next approach is to try to spread the operation over multiple render loops. This is often nontrivial and not obvious. This can be further aggravated by the delayed and queued rendering behavior of most Flex components. If a Flex component is not provided with its data during its first frame of existence it may be rendered during that frame in a partially complete manner, which can often cause significant visual jarring in the application when it resolves to its correct state.
This visual jarring can be reduced by causing the component to wait to render itself until all of its data is available, but this is not a common practice and it is not immediately obvious how to achieve this using the Flex framework.
The performance lag can also come from other sources such as an extended service call (which should not itself slow down the framerate of the Flash player), parsing large amounts of XML or other data, or rendering complicated graphics. The Flash player parses XML data when it is returned from a service call into XML objects and with significant data sizes this can cause a lurch in the Flash player. The Flash player also typically renders the entire visual representation during one frame and complicated visuals - which may perform adequately after their initial rendering - can cause a pause.
The second way to address this problem is by altering the use of custom cursors in the Flash player. Since the movement of the cursor is governed by the framerate of the Flash player this can be beneficial even when there are no significant performance barriers. Users will be accustomed to their cursor moving at near the refresh rate of their monitors - usually above 60 frames per second, or 60 Hz. Flash movies and Flex applications typically run at framerates of 24 Hz, although developers can override this setting. If you are developing an application where smooth animation and cursors is a necessity, it would be wise to raise the framerate somewhat, however, problems have been reported with server calls when the framerate is set too high.
Thankfully, there is a compromise possible between abandoning custom cursors altogether and using them in the typical manner. This compromise is to decorate the system cursor rather than replacing it completely. Decorating the system cursor involves attaching a Shape or Sprite to the current mouse position and avoiding operations which set the Flash cursor directly. This decoration may at times lag behind the system cursor, but it will at least allow the user to move their mouse with confidence across your application.
Decorating the system cursor can also be a significant help when the user is performing precise manipulations such as in image editing or layout. Since the system cursor will still render at full speed the user can be confident in their motions, even though the Flash player may lag in updating the user interface.
Observing users is, as always, one of the best ways to identify usability problems with your application, and should be relied upon to focus your efforts on important problems. However, attention to detail will always be appreciated by users even when they cannot specifically identify the problem they are experiencing. Unhappy users are more likely to simply quietly disappear than to register their complaints, and you may lose them quickly if they feel your application is unresponsive. Most users will equate an unresponsive application with a broken application. If your application is involved in selling anything to users this can lead them to question whether your application is safe enough to enter their financial information into and result in abandonment.