Blog

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.

1. 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.
2. The logging in state in Login2.mxml adds a SWFLoader that loads an animation.
3. 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.

Login Form State & Transitions Example – View Source | ZIP

Being anonymous is l@m3. Besides, cflex.net is getting hammered. lol, 404!

1. At what stage of technology selection does Flex play in your immediate team?

– Fully committed

2. How long have you been using Flex?

– 2 years+

3. What would you consider your expertise level?

– Advanced

4. Outside of Flex, what have been and continue to be your primary technologies?

– PHP
– Flash

5. Do you use the Flex Data Services (FDS) product?

– No

6. When it comes to Flex, what did you used to struggle with, that you no longer have problems with?

– Dynamic layout. Using declaritive layout in Flex with it’s built-in LayoutManager saves me oodles of time when doing GUI’s. CSS inheritance helps too.

7. When it comes to Flex, what are you currently struggling with, or wish were improved, made better, had more of, etc…

– Integration of Flash designs.

8. How many years have you been programming in general?

– 6-10 years

9. How many developers are in your immediate team?

– n/a – unemployed (if I was, 1-5)

10. How many employees are at your company?

– n/a – (if I was employed 101-150)

11. Has Flex been adopted by your entire company/top level business unit as a primary technology?

– Yes

12. What prevents your company from taking things further with Flex?

– Nothing, we’re 100% Flex or bust!