Create a vivid user experience with animated transformations

A typical application lifetime consists of a number of states: A data entry form, a result interface, a photo album containing various images, a shopping cart with items, and so on. Often, applications perform heavy tasks by using the user to switch between these different interfaces: The new interface replaces the original form, suddenly pops the results on the screen, and the graphics and GUI objects jump out of the screen. In general, each current UI screen closes after the operation completes, and the new screen replaces its position.

The HTML application is a good example: fill in some data on a page, click the Submit button, the original page will be eliminated and replaced by another new user interface. Then you'll take a closer look at the new interface, think about what you should do and find the new Submit button.

Would it be better if an application were to create a more logical process between these different application states and bring the new user interface (UI) to the user? What if the user did not have to re-examine the new user interface, but instead used the process of the application? </p>

This is exactly what the animation translates: Creating a seamless process between these states by making the transformation of the application user interface animated. By helping users understand the combination of user interfaces, transformations can help ensure that users connect to programs.

Of course, this problem means more work for developers. Having your application eliminate an interface and display the next interface is the most intuitive way to handle this problem. Running an animation between interfaces usually requires understanding the animation process, and then writing a whole bunch of custom code to animate the elements on the interface.

This is why you write an animated transformation library: Fundamentally simplifies the flow of animation between application states, performs a reasonable default animation, and lets you focus on writing application code rather than animation code.

Demo time

Let's look at a simple demo application Fieldsoftext. The application simulates a common feature (which may also be available elsewhere), and the user can request the GUI to expand itself and provide more text fields. For example, I'm going to use a dialog like this to upload a key cartoon to my java.net blog. The application starts with only one text field, but by clicking the more or less button, you can increase or decrease the number of text fields that are displayed.

There is also a submit button at the bottom of the interface, so this type of application usually has a submit button. The button here does not actually perform any tasks, but it is the same as the other user interface elements, which is the process of displaying animation transformations.

The following code is used to display the GUI:

// Add the More/Less buttons container
add(moreOrLess);
// Next, add the proper number of text fields
for (int i = 0; i < numFields; ++i) {
　　 add(textFields[i]);
}
// Finally, add the Submit button at the bottom
add(submitPanel);

In this code, the Moreorless component is a panel that holds the more and less buttons. Textfields[] array is used to save the various text fields that will be populated into the GUI. And Numfields says the number we want to display at this point. The Submitpanel component is a panel for saving the submit button.

The following is the basic user interface for the provided user:

Figure 1. The initial interface of the application

When the user clicks the More button, a text field is added below the original text field, as shown in the following illustration:

Figure 2. The application interface after the user clicks the More button