Today, I posted an interview I did with Doug McCune on InfoQ.com. His personality and passion for development came through in his encouragement for developers to build “cool shit.” I love the sentiment, as I so often get trapped in trying to bring business value and forget that sometimes software development should just be a creative endeavor. However, as cool as that sounds, it can be challenging to bring that sort of mindset into the enterprise. With that in mind, Doug had some really interesting comments on UX within business applications:

Enterprise software is almost uniformly horrible, but there’s no reason for that. We’re seeing a “UX revolution” in RIA design, and for all the buzzword nonsense surrounding “user experience, ” there’s something real happening in terms of the overall quality of the experience delivered by RIAs. We’ve seen some really great and innovative work in consumer RIAs, with a trend toward simple and intuitive interfaces. And yet in enterprise software this trend has barely even begun, it’s all still complex. I want to see enterprise applications treated like consumer apps, with the same attention to the user experience and with a consistent drive to simplify and make everything more intuitive. Complex systems don’t have to be presented with confusing software. But it takes more work to figure out the simple, elegant solution. It’s far cheaper and faster to make bad complex software than good simple software.

I also think there’s a business intelligence breakthrough afoot that will bring these same concepts of intuitive software specifically to the BI arena. Business intelligence is just a fancy way of saying that you’re extracting value from raw data in some way. This is typically limited to your mundane set of charts, gauges, and all the other normal dashboard UI elements that are the current standard. But I think thinking about BI problems from a fresh perspective, from the perspective of someone outside the enterprise space, will lead to the invention of new visualization methods. Maybe sales performance isn’t something best shown using a silly looking speedometer gauge. Maybe there’s an intuitive way to extract more value from that heap of raw data sitting on enterprise servers. But I don’t think enterprise developers have been willing enough to experiment with new concepts. People need to start inventing.

I have to agree that enterprise software is generally poor, particularly in the user interfaces.  In addition, his comments on working toward the simple, elegant solution makes me want to scream, “Yes!”  I think the only place I differ with him on is where the blame belongs for the overall low quality of enterprise systems.  Developers do deserve some of the blame, but I think generally the challenges come from the organizations, project owners, and managers who do not understand what is now possible, or even worse never understood how to build software to begin with.

In years gone by, the platforms really limited the ability of developers to build cool user interfaces that still made sense on the budget.  I was originally drawn to Flex because it can do things that simply weren’t possible on the web only a few short years ago.  This probably factors into the decisions that even smart, experienced managers are still making today, as many of them have previous attempts at doing cool things that led to ballooned budgets and jeopardized projects.

So, there is the obvious onus on developers to sell their ideas and educate their organizations on what is possible now that the platforms have capabilities way beyond getting data in and out of the database.  However, with that said, the real limitation of enterprise software will always be that the teams building most systems are part of companies that do not exist to build software, and often just don’t understand the processes, the platforms, the code, the users, etc.  In those cases, it is unlikely that they will be able to overcome their limitations to build cool, highly usable systems.  So, while I am optimistic that the advances that have come with the RIA revolution will trickle into the enterprise, it is unlikely that they will have the same impact on business applications as we are seeing in consumer applications built by companies that exist solely to build quality software.

If you enjoyed Doug in writing, check him out in this recent Flasher Magazine video interview. Also, look for him in a future DrunkOnSoftware.com interview.

If you need to integrate a Flex application into an existing web page, you will probably want control over the amount of space that the Flex application uses on the web page. If the Flex application size never changes, you can simply set the height and width of the Flex application in the HTML code (in the Object and Embed tags). However, if the Flex application size is dynamic based upon user interaction, you will may want the HTML space allocated to the Flex application to change as the Flex application size changes. The purpose of this post is to show how this can be done.

The following Flex application has an “Add Fields” button. If you click that button, two things will happen. First, the “Add Fields” button will be removed. Second, a TextArea and another button (“Remove Fields”) will be added. This behavior will cause the height of the Flex application to grow. The Flex application will make a JavaScript call to the containing page to dynamically change the space allocated to the Flex application.

Similarly, if the “Remove Fields” button is clicked the height of the Flex application will shrink. So, again, the Flex application will make a JavaScript call to the containing page to dynamically change the space allocated to the Flex application.

In order to accomplish this, we first need to insert our Flex application into the containing HTML page:

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
	codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab
#version=6,0,40,0"
	WIDTH="1" HEIGHT="1" id="mySwf" scrolling="no">
	<PARAM NAME=movie VALUE="FlexibleGorilla.swf">
	<PARAM NAME=quality VALUE=high>
	<EMBED src="FlexibleGorilla.swf"
		quality=high
		scrolling="no"
		WIDTH="1"
		HEIGHT="1"
		NAME="mySwf" ALIGN="" TYPE="application/x-shockwave-flash"
		PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
	</EMBED>
</OBJECT>

Next, we will add the following JavaScript function to the containing HTML page:

function updateSwfSize(myHeight, myWidth) {
	var flexibleGorillaSwf = document.getElementById("mySwf");
	flexibleGorillaSwf.height = myHeight;
	flexibleGorillaSwf.width = myWidth;
}

Then, in the Flex application, we will call this JavaScript function everytime the Flex application size changes. Here is the Flex code used in the example application:

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%"
							creationComplete="create()">

	<mx:Script>
		<![CDATA[

			private function create():void {
				updateSwfSize();
			}

			private function addFields():void {
				this.addButton.visible = false;
				this.addButton.includeInLayout = false;

				this.myTextArea.visible = true;
				this.myTextArea.includeInLayout = true;
				this.removeButton.visible = true;
				this.removeButton.includeInLayout = true;

				updateSwfSize();
			}

			private function removeFields():void {
				this.addButton.visible = true;
				this.addButton.includeInLayout = true;

				this.myTextArea.visible = false;
				this.myTextArea.includeInLayout = false;
				this.removeButton.visible = false;
				this.removeButton.includeInLayout = false;

				updateSwfSize();
			}

			private function updateSwfSize():void {
				this.validateNow();

				var newHeight:Number = this.myVBox.height;
				var newWidth:String = "100%";

				if (ExternalInterface.available) {
					ExternalInterface.call("updateSwfSize",
								newHeight,
								newWidth);
				}
			}

		]]>
	</mx:Script>

	<mx:VBox id="myVBox" horizontalAlign="center" width="100%">
		<mx:Label text="Dynamic Sizing Example" />
		<mx:Button id="addButton" label="Add Fields" click="addFields()" />

		<mx:TextArea id="myTextArea" text="FlexibleGorilla.com"
					width="90%" height="100"
					visible="false" includeInLayout="false" />
		<mx:Button id="removeButton" label="Remove Fields"
					click="removeFields()"
					visible="false" includeInLayout="false" />
	</mx:VBox>

</mx:VBox>

Recently, I’ve been playing around with Degrafa in preparation for actually using it on an upcoming project at work. For those that aren’t in the know, Degrafa is a badass graphics framework for Flex. One of my favorite parts so far is the amazing leverage it brings to building custom-styled components. It’s terse and powerful, just the way I like it.

Building Buttons

With a very minimal amount of effort, I was able to create a few “web 2.0″ button skins. I just followed one of the millions of glass button photoshop tutorials, but did the work in mxml code using Degrafa’s declarative syntax. Here are my results (view source enabled):

Button Explorer

But then I decided to take it a step further and build out a Degrafa Button Explorer (with a small tip of the hat to the original Flex Style Explorer). The Degrafa Button Explorer allows you to adjust a bunch of properties and colors for all three buttons styles. It goes a step further than the original and provides not only the CSS, but also the full code of the stateful Degrafa-powered button components.

 »  Degrafa Button Explorer

Digging Deeper: I’ve been following the skinning performance issues discovered by the guys at EffectiveUI. The most recent benchmarks appear to show that stateful Degrafa skins (like those produced by the Degrafa Button Explorer) are safe to use.

I was recently developing a Flex application that needed to be integrated into an existing e-Commerce site. As part of the integration, I needed to communicate information between the Flex application and the containing HTML / JavaScript page. I don’t believe I’ve ever seen a web site that put together all of the various scenarios that I wanted in one place. So, I put together an application that contains small examples of each scenario that I was interested in. I thought it might be helpful to post these simple examples for others.

We’re pretty big on testing at Gorilla Logic, and in the world of Flex that usually means using FlexMonkey to test the UI and using FlexUnit to test the code. Alas, it is a huge pain in the ass to correctly test the many async objects and services inherent in any Flex app with FlexUnit. Enter Fluint, an superior Flex unit tesing framework by the cool guys at digital primates (no relation). Fluint is the heir apparent to take over the unit testing crown from the venerable FlexUnit. So let’s take Fluint and its enhanced async testing support for a spin.

Service Layer

First, assume we have a nice service layer in Flex that talks asynchronously to our backend. Just something simple to start:

public class MyService {
    public function getSomething(result:Function, fault:Function):AsyncToken {
        //call the backend
        var token:AsyncToken = backend.getSomething();
 
        //wire the callbacks to the result
        token.addResponder(new AsyncResponder(result, fault, token));
 
        return token;
    }
}

In this example, our service only has one method, getSomething() that takes two callback functions. It simply calls the backend method, wires up the callbacks (which get called when the backend method returns a result), and returns the token. It is absolutely critical that our callback-powered service method return the AsyncToken. The reason for this will become apparent.

We might use our service like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
        xmlns:mx="http://www.adobe.com/2006/mxml"
        creationComplete="complete()">
 
    <mx:Script>
    <![CDATA[
        import com.saturnboy.services.MyService;
        private var service:MyService;
 
        private function complete():void {
            service = new MyService();
            service.getSomething(resultHandler, faultHandler);
        }
 
        private function resultHandler(result:Object, token:Object=null):void {
            lbl.text = result.result.name;
        }
 
        public function faultHandler(error:Object, token:Object=null):void {
            lbl.text = 'fault';
        }
    ]]>
    </mx:Script>
 
    <mx:Label id="lbl" text="initial" />
</mx:Application>

We make a call our service, and then use the callbacks to alter the UI however we want depending on the result. In common usage, the fact that our service returns an AsyncToken is worthless, it might as well return void. So, why did I say this is critical? Throw Fluint testing into the mix and it’s “Show em what’s behind door number 2, Johnny!”

Fluint Testing

Fluint provides two different async wrapper methods: asyncHandler and asyncResponder. The first allows a test to be wired to an async method by events, the second allows a test to be wired to an async method by a responder. Since the service method we’re trying to test doesn’t throw any events, we’ll need to use the latter. So inside a Fluint test case, we have our test method:

public function testGetSomething():void {
    //call service with dummy callback
    var token:AsyncToken = service.getSomething(dummyResult, dummyFault);
 
    //create async test responder
    var responder:IResponder = asyncResponder(
            new TestResponder(testHandler, faultHandler), 1000, token);
 
    //wire test responder as 2nd callback
    token.addResponder(responder);
}
private function testHandler(result:Object, passThroughData:Object):void {
    assertEquals('something', result.result.name);
}

The trick is to wire a second callback via Fluint’s asyncResponder helper that actually does the testing, and just give the original service call some dummy callbacks. Note that if the service method didn’t return its AsyncToken there would be no way to wire a second callback. The Fluint async helper do two import operations: they handle the event or call the callback AND they mark the test method as an async method so the result is correctly reported by the test harness. You can read more about Async Testing in Fluint’s wiki. The rest of Fluint is your standard chain of crap borrowed from JUnit: test runner, test suites, and test cases.

Digging Deeper: It is equally critical to use dummy callbacks in the original service method call because in a failure situation they will cause Flash Player to error out instead of being caught by Fluint and reported as a test failure.

Files

The complete code is up on GitHub here: test_fluint_async. The code is MIT licensed and includes a working fluint.swc (see below) plus a mock async backend (so timeouts and faults are easily testable).

Alas, Fluint v1.1.0 was built incorrectly and is missing the TestResponder class (see issue 35). So if you want to try out Fluint in your project, I recommend you grab it from svn and build the swc yourself. Hopefully, this will all be fixed in the next release.

UPDATE: Fluint v1.1.1 was release on May 1, 2009 and fixes this issues and a few others. Download it here.