mikemo

Even if you aren’t a Mac user, please do this to your Flex apps.

Even if you aren’t the kind of person who uses the scroll wheel on your mouse or two-finger scroll on your trackpad, please do it.

If you do, you will make some of your users very very happy.

Suppose you are trying to set up a nightly build system — your developers use Flex Builder during the day, and you are creating an Ant task that runs every night. And you want the Ant task to use exactly the same build settings that are used by the developers.

mxmlc and compc have a -dump-config option to dump all settings to a file. Later, the settings in that file can be read back in with -load-config.

So, do this:

• In Flex Builder, do Project Properties
• Click the “Flex Compiler” tab
• In the “Additional compiler arguments” box, add “-dump-config full-path-to-output-file“. For example, on Windows, “-dump-config C:\myconfig.xml”; on Mac, “-dump-config /Users/myname/myconfig.xml”. (If you use a relative path, the file will be put in some odd hard-to-find place.)
• Click OK.  If Build Automatically is on, just clicking OK will cause the file to be built; if it is off, do a build now.
• Now that the settings have been dumped, go back to your project settings and remove the -dump-config option.
• Tweak the settings file as necessary (one thing you will almost certainly want to do is change <debug>true</debug> to <debug>false</debug> if your nightly build is supposed to do a release build), and use it in your nightly build script.

Please be aware that this only captures compiler settings; it doesn’t capture all the other little things that Flex Builder does for you, like compiling Flex library projects that your project depends on, copying non-embedded assets to the output directory, optimizing modules for the application, extracting RSLs, copying the HTML template, and so on.

More info here. Please read that, it has additional info you will probably need.

I’m sure this has happened to you once in a while: You’re doing several things at the same time on the computer, e.g. perhaps you click to launch some slow program, and while that is launching you go over to your web browser to kill a few seconds reading something.  You try to click a link, but oops – just when you were about to click it, the other program finishes loading, and you have accidentally clicked something in it.

A variation of that happened to me just today.  I decided to try Yahoo Chess (and I’m proud to say I won my game).  You enter a room, e.g. the beginner room, and then there is a list of tables; you click to join a particular table.  But every few seconds, the list of tables keeps refreshing, so the button you were about to click could have suddenly disappeared — or worse, turned into a button for a different table you didn’t intend to join.

What’s interesting to me (I don’t know why, maybe because I’m a geek) is that this is a real-life version (if using the computer is considered real life) of the sort of race condition horribleness we all run into when we write multithreaded code. Thread 1 tries to increment a variable, but oops, thread 2 sneaks in there and changes it!  Urgh.

Does this ever come up in real real life (as opposed to real life while using a computer)?  Yes, of course — one good example is the awkward little dance we all do once in a while when trying to walk past someone else who is coming the other way. Both step to the right, oops, both step to the left, oops!

In the case of computer UI, I can think of two ways to alleviate this problem (I am not claiming any incredible insight here, I think these are pretty obvious):

1. Animation can help. E.g. in the example of the Yahoo Chess list of tables, when the list redraws, rather than having it redraw instantly as it does now, maybe the individual rows of the list should slide to their new positions.  That gives a person’s eye the visual feedback, “Wait, don’t click just now.”  Animation is sort of the computer equivalent of what usually helps avoid this problem in real-life scenarios: Most of the time, the fact that you can see the other person moving and adapt to their movement gives your brain enough time to avoid a collision.
2. Maybe disable the mouse (and keyboard if appropriate) for a fraction of a second, e.g. maybe 1/4 second, immediately after a change, e.g. immediately after the list of chess tables was updated, or immediately after a program opens a new window or dialog.

Of course, it would often be appropriate to combine both of those techniques: disable the mouse, do the animation, and then re-enable the mouse.  If done that way, the mouse could be immediately re-enabled when the animation was done — no need to wait for 1/4 second more after the animation is done, because the person has already had sufficient time to process what is happening and avoid an accidental click.

What do you think?  I’m sure none of this is terribly original — I imagine lots of research on this topic has been done.  I just haven’t come across it.  (Sometimes blogging scares me, because the Internet is so huge that no matter how original a particular thought of mine might be, the odds are extremely good that someone else has already had it, and has said it on the Internet, and thus it’s already in the Google index, and so should I really bother.  Reminds me of a joke that A. Whitney Brown made many many years ago in Saturday Night Live: “There are a billion people in China.  Think about that.  That means if you’re a one-in-a-million kind of guy, there are a thousand other people exactly like you.”)