If your company will continue to use Flex going forward, for all the good reasons, then basically you are getting ahead of the game. The parts are being built as you want them and you can eventually convert the old parts later on. Eventually you will end up with a 100% Flex built web application.
You hybrid design will cause confusion with end-users. If your web application (as an example) deals with managing user records, maybe the general page (the main page) and address page is in HTML and the contact page is done in Flex. Meaning, end-users will, in the course of administrating a user then be jumping from HTML to Flex and vice-versa. Here is a list of negative effects that this might cause:
- Users might use the browser's back-button and not get the intended result (in my example this might not seem like the case, but in a complex Flex app, you can imagine such a scenario)
- Every time the Flex UI loads, it might need to retrieve the same data over and over again (country list in this case)...so there will be a little wait time, although in seconds, some might perceive this as annoying.
Obviously if we had to do it all over again, we would have left the "root" page in HTML and built all the sub pages as Flex and then finally migrated the "root" page once all the sub pages were converted.
Also another way would have been to leave the old web application in HTML as is, build the new application using Flex, not given anyone access to it and then when it was 100% in Flex, release it to everyone. Not sure this would have worked well either because of the following reasons:
- You would have to maintain the HTML and Flex applications at the same time
- You would be getting no feedback at all on the new Flex app
- You would sell-shock users when the new Flex app would be released
So has anyone else ever have to deal with this type of issue? What did you do? How did you handle it?