Copy operation between List / DataGrid

One of the great things about Flex is how much is available out-of-box. One feature that is provided out-of-box is the ability to easily drag'n'drag data from one control to another. One great example of this is to drag'n'drop data from a source List control to a destination List control and vice-versa. A example use case is where you are allowing the user to assign "users" to a "group" from an available list of "users".

This is code to implement this functionality is as follows:

[List id="availUsers" dragEnabled="true" dragMoveEnabled="true" dropEnabled="true" dataProvider="{availbleUsers}"]

[List id="assignUsers" dragEnabled="true" dragMoveEnabled="true" dropEnabled="true" dataProvider="{assignedUsers}"]

Pretty simple eh? Basically what this code is saying is that both List controls are drag sources (dragEnabled="true"), that both are drop destinations (dropEnabled="true") and that when data is dragged from the control, that the data should be removed (dragMoveEnabled="true") - since it will be moved to the destination.

In some cases, as it happened to me just yesterday, you don't want the data to go back and forth between the two controls. In my case, I need the available list of users to remain as-is and that you could assign a user multiple times to the destination list.

To accomplish this, you just need to make the following changes:

[List id="availUsers" dragEnabled="true" dragMoveEnabled="false" dropEnabled="false" dataProvider="{availbleUsers}"]

[List id="assignUsers" dragEnabled="false" dragMoveEnabled="true" dropEnabled="true" dataProvider="{assignedUsers}"]

With the changes, this will allow data to be copied from the available users list (dragMoveEnabled="false") to the assigned users and you can't go back (dragEnabled="false").

Flash Player 10.1 pre-release

Adobe has setup a page that allows you to download a pre-release version of the next version of the Flash Player. That's version 10.1, which is heavily geared for running on mobile devices; but the desktop version gets all the advantages as well.

You can view some demos on the page showing the Flash Player 10.1 running on various devices and at the bottom of the page there are some quick interviews with Adobe employees; each one talking about one of the new changes that are present in the upcoming release.

Handling change - the YouTube way

Just noticed today that YouTube changed their site a little bit - more like tweaked. No big deal really, they have added some video controls and changed others. What I do like is that at the top-right corner of the page, their is a little blue information box that allows you to "take a tour of the changes". And like it says, it uses a little JavaScript overlay to take you on a tour of the page you are looking and explains the various parts of the page that have changed and how it now works. Simple and ingenious.

Some people hate changes, even of the smallest kind (Napoleon would be outraged! - internal friendly joke). This is a good way I think of showing users that the changes are no big deal really and you can continue on using YouTube to enjoy your favorite videos as you always have and with a smile :)

Careful building hybrid Flex/HTML applications

Building a Flex application from the ground up is fun experience. But since Flex has only been around for 6 years and if your company has been around for longer than that, this means that your Flex application might have to co-exist with an existing HTML application (most likely server driven such as a PHP, JSP or ASP web site). In essence, you have a hybrid Flex/HTML application and there is pros and cons to this.

PROS:
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.

CONS:
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:

1. 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)
2. 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.

The way I see it, if your "root" page is HTML based and the sub pages are in Flex, then confusion might be minimized. If the reverse is true however, meaning the "root" page is in Flex and the sub-pages are in HTML, then when the user hits the back-button, he might go back to a Flex UI and find it not in the state he left it in (However I believe there is a way to save application state in Flex - I just thought of this actually, but hey, I've got a million things on my mind, can't think of everything at once). At my company we ended-up doing the later and in hind sight it might not have been the best decision. We basically wanted people to use the new version of the web application as soon as possible and now because it is not yet complete, then are jumping from Flex to HTML and back in some cases, and this causes confusion and frustration.

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?