I always make these more complicated than they need to be, but it’s so much fun, I can’t help it. Regardless, here is an example of 2 login forms built in Flex 2. One uses simple states to represent the main, logging in, and error states that a typical login form can show. The second one does the exact same thing, based on almost the exact some code, but has the addition of transitions. Where “states” are changes to the component when it is a different circumstance, “transitions” are changes between those states. A Flex component that has states, but no transitions immediately changes from one state to the next visually. If you add transitions, you have control over how a state changes from one to the next.
Both examples below are simple. If you click submit, it’ll disable the fields, and then go to an error state. After 2 seconds, it’ll reset. If you fill in something for the username and password fields, it’ll go to a success state instead of an error state instead. The top one uses state tags inside an MXML component. The bottom does the same with the addition of transition tags to animate between those states.
As mentioned, the code base is exactly the same with 3 modifications between Login.mxml, and Login2.mxml.
- I removed the setting of the border color to red from the error state tag, and put it in the transition instead since I wanted timing control of when it turned red.
- The logging in state in Login2.mxml adds a SWFLoader that loads an animation.
- The Login2.mxml doesn’t reset itself 2 seconds after the error state is shown. Instead, I have the ending of the transition call a function to do it instead. This gives the transition enough time to finish before a new state is shown.
We had to use ViewStacks or destroy & create this stuff manually, with no DisplayList mind you, in Flex 1/1.5. The ability to have the same component represent its state declaratively as well as have control over how those states change is awesome! In an ideal world, you can comment out the transition tags, and the component will still work just fine; it’ll just have abrupt changes. To me, if you get a proper designer / information architect involved, the experience in having appropriate transitions to guide the users attention vs. abrupt GUI changes without them is night and day.
Why blur things out? Degrade importance, and allow the depth of field effect to allow the user to focus on the most forefront content.
Why show loading animations? To build the user’s confidence that the application is “doing something” vs. appearing broken.
There are various proven tested techniques you can implement, none of which I probably show correctly.