Yes, yes I do.

On my previous posts, I wasn’t exactly silent about my love towards the combination that is ActionScript 3.0 and Flex. However, just like a romantic relationship, after the initial flowery period is over, you start to see the ugly side of things.

For our 3rd coding task, we are to finally get down to business and start development on the SQL Builder application. The tentative goal is to reproduce the same user interface as the one we came up with for our paper prototype and user testing phase. Since this is a major step towards the final product, we are going to treat it as the final product which means we will need to design the code structure in a coherent manner to promote readability, reusability, and extensibility. We do not want another round of throwing away code because we feel we have enough practice already. It is time for the real thing.

After some deliberation, we decided to use the Model View Controller (MVC) architecture to separate our code into logical sections. As well, we noticed that in our previous demos the code in our main file looked like angel hair pasta from the mix of markup and javascript-ish code. To rectify that, we are using a code-behind approach to leave the main file purely as mxml markup and “behind” it is all the Actionscript logic. In addition, we are going to be placing the classes in packages. Aside from the main benefit of having class structures separated properly, having the fully-qualified names of all of our classes being prefixed with edu.toronto.cs.flareflow feels strangely gratifying (import statements look cool!). Lastly, we are going to be using interfaces and abstract classes in our design to take advantage of polymorphism. This is especially useful for the many types of “boxes” that share the same basic input/output functions.

Pretty exciting stuff no? We had our concerns in implementing everything we described above, but we did research into whether or not they are feasible before going ahead. So far we are able to accomplish the first three in a relatively clean fashion. The hiccups came in when trying to get the interfaces and abstract classes going.

Having used abstract classes and interfaces from other more full-featured programming languages, when I read that it is possible to use these constructs in Actionscript, I took it for granted that they will work exactly the same way in Actionscript as they did in say, Java. I was flabbergasted when the compiler told me my classes + abstract classes + interfaces were illegal. After combing through reference manuals, I discovered these nuances about Actionscript:

1. No clean way of using singleton pattern – Constructors must be public. People online recommended throwing an exception when someone tries to instantiate the class using new and not the newInstance method … I don’t like this solution.

2. No method overloading – if I am trying to create another method of the same name with a different number of parameters in order to suit my specific class’ function better , it is not allowed.

3. No abstract classes, no abstract methods– Abstract classes in Actionscript can be “simulated” by writing them as concrete classes and then you either: A. Throw exceptions when instantiated or when unimplemented abstract methods are called. B. Write HUGE comments alerting the user to make sure to extend this class and not use it directly.

There are many “hacks” floating around the web to work around the above problems. We are still deliberating on whether to use these hacks or change our design because the hacks do result in a bit of somewhat ugly code.

The biggest problem I have with this is that it weakens the power of inheritance and encapsulation. I don’t see why I should be using inheritance when I can just encapsulate by composition. Aside from adding a bit more code per class and perhaps not making interface contracts as obvious, there doesn’t seem to be a significant downside. Hmmmmm… am I missing something?

In any case, the initial exciting period for Actionscript + Flex is over. Relationship authors call this “The Power Struggle Stage”. This is the stage when most breakups and divorces happen. Aside from noticing faults in the other party that were not apparent before, people in this stage also start to notice or seek out alternatives. So… I guess…. Hello Silverlight?

My apologies for the lack of updates lately. Just when I was about to ease into the weekly update interval, something terrible happened.

I remember I was 50 words or so into a new blog entry detailing my thoughts about our second demo. Before I could get to the part about how I managed to “gently persuade” 11 people into posing for the pictures, my screen froze. A reboot and a cup of hot chocolate later, I diagnosed my hard drive to be dead. Even though I didn’t lose too much data (huzzah for backups + svn) and Lenovo’s warranty covered everything else, I still grieved over the loss of utility time and the eventual re-installation/reconfiguration of a load of software. I was feeling very unmotivated and hence I did not finish the blog post. Boo.

Fortunately, these past two weeks did not require too much coding work. I have been using my dinky Asus EEE to tie me over until Lenovo ships me a new hard drive. For fun, I installed Eclipse on it and discovered that I needed to scroll to complete the five lines necessary to print out “Hello World”. I don’t want to imagine what Flex development would look like on it.

The next step in our project is to come up with a design for the SQL query building interface. We will be expanding on the boxes and lines concept. The approach is to let users who are unfamiliar with SQL and databases to be able to build meaningful SQL queries by simply dragging and dropping boxes and connecting them together. The design we came up with was heavily graphical, verbose, and inefficient, but it might just do the trick at allowing our target audience to take baby steps towards building their desired query. Of course, being computer scientists, we cannot trust our own judgment at determining the usability of this design because our needs are polar opposites of our target audience’s. Hence, before we invest any more time in over-engineering features that probably won’t be utilized, Greg and Diane suggested that we get our hands dirty and get a paper prototype going and run some tests on our end-users.

For the last couple of days, Bing and I have been uncharacteristically doing arts and crafts in our office. Thanks to a little help (errr… a lot of help) from our arts and crafts consultants Victoria and Eva, we were able to complete a sparkly prototype by end-of-day yesterday. Before people left for the day, we were able to capture Qi and “gently persuaded” him to try out our prototype. We were surprised at the amount of user insights we can extract from testing with a paper prototype. Perhaps more surprisingly, Qi was able to piece together all four of our test queries quite quickly. We were expecting users to not be able to complete the last query since it required a non-obvious step if it was to be expressed in SQL. Qi was able to build the query by reasoning it out using our prototype’s interface. While it is tempting to conclude that we have created something truly magnificent, we choose to postpone the celebrations. This is because even though Qi did not have any experience with SQL and databases, he is still a computer science student so his brain may be too in-synced with ours. We will have to wait until Monday to get a true assessment of the prototype’s usability when we try it out with two non-technical CS department faculty members.

Let’s hope my new hard drive arrives soon. The combination of the lack of a full-featured laptop and the arts & crafts may soon be enough to drive me to find even more alternative ways to do activities that I used to do with a computer, like… errr… *gasp* read a book in non-pdf format? Whoa.

Godspeed little hard drive, godspeed.

For our second demo, the goal was to implement an application that simulates dataflow between functions with different numbers of inputs and outputs. We achieved this by extending our first demo and adding input and output points on each box. As well, we visualized the flow of data between boxes by having each box indicate when it receives input and when it sends along output.

Very brief instructions:
1. Drag boxes from the left panel to the right panel
2. Create connections between boxes by clicking on the red circles of two different boxes on different levels
3. Click on the “Layout Mode” button to switch to Dataflow mode
4. Double click on any box to simulate data flowing through that box to its children

For more detailed usage information, click on the Instructions button on the application.

Click here to try out the demo  (Please be patient as sometimes it may take a while to load).

Tacked on message From Ming:

I just want to thank everyone who allowed me to take their pictures for this demo and more importantly, trust me enough to not post these pictures up on hotornot. You guys rock.

While maybe not as important as listeners, dragging and dropping is an action we all know and love. Remember your bewilderment the first time you dragged a chunk of a spreadsheet into your word processor and watched as a neat little table was constructed before your eyes? Do you not sometimes open up a bunch of unrelated programs and try to drag objects from one to the other in hopes that the little icon with the + sign on it will replace your mouse cursor as if to say, “Yes, you are welcomed here my friend…”? Wouldn’t it be fantastic if we can experience this delightful sensation more often? I certainly think so.

Snapping back to reality, our next task is to come up with a second demo that allows users to connect boxes together via multiple input/output points. As well, users can insert different types of boxes into the main canvas by dragging and dropping from a toolbar. There’s a lot more to it, but I’ll save that discussion for when we have completed more of the demo.

Even though the first demo did everything we wanted it to, I was still feeling a bit uneasy about advanced uses of listeners. Moreover, I needed to learn how to implement drag and drop. After researching a bit about dragging and dropping, things are fuzzy when I try to visualize how all the handler functions work together. Smartly, I decided to write a simple application to help me see it all in action…

OK, now phasing back into dreamland.

We are all drag and drop fanatics. However, most of us don’t get the chance to do it often enough. So perhaps if we can integrate drag and drop with some of our more common computing tasks, we can rely on and appreciate dragging and dropping even more. This is the need I set out to satisfy with my newest software innovation:

Click here to experience the latest breakthrough in HCI and productivity. (but it may take a while to load because UT’s webspace isn’t exactly optimized for serving webpages or handle web requests in general)

I think I will start calling up Microsoft about buying me out with some of that yummy Yahoo money… I don’t think they will want to risk dealing with a potential threat to their multi-billion dollar cash cow. Now the question is, how many zeroes do I want on my cheque? … Wish me luck!

So, here is the first demo that we showed to Greg yesterday: Demo

The demo is just a basic app that allows boxes to be created, connected to each other via lines, and dragged around the canvas. Developing this demo is the first step in moving towards the goal of our project which is to create a pipe and filter interface that allows users to select columns and rows from SQL databases and perform transformations on the data by piping it through different filters without having to write any code.

Since we were not very experienced with ActionScript 3 and Flex, the initial design we used to develop our demo was not ideal so we have since thrown away the code. We are now writing a new design document that will be used in developing the next step of our application.

Listening is a very important interpersonal skill. It allows you to understand other people’s needs and motivations. As well, it prevents you from talking for five minutes straight before finding out she doesn’t understand English. *sigh*

In UI programming terms, listening is just as important. Listeners and events allow an application to react promptly to user input without having to continuously poll each component for change. Without them, your flashy UI will be as useful and interactive as a jpeg. Hence, we can think of listeners as the hyphen in “Human-Computer Interaction”. Yes, listeners are just that important.

Now, what happens if your listeners develop hearing problems? And what if they start eavesdropping on things they are not supposed to hear? Those are the problems I experienced this week. Some of the listeners I registered for basic events were behaving oddly. Sometimes they would respond correctly, but sometimes they would not. The friendly debugger informed me that the reason why they did not respond was because they were listening to another unassigned event instead. While I am sure there’s a perfectly logical explanation for this buried within the Flash+Flex event model, I still dropped quite a few hours trying to figure it out. After stepping through nearly every line in my code (it wasn’t that long) and still couldn’t find the problem, I was beginning to think it could be the fault of the Flash+Flex framework. As I was about to dive into the event dispatching code of the framework, I recalled the wise words of one of my mentors: “If you find yourself placing breakpoints on the SDK’s code, you may end up finding the bug, but you will not find happiness.” Agreeing with what he said, I stopped debugging and started rewriting a good chunk of the code. To put it briefly, the code works now.

Coming from a Java/.NET background, having to cast doubt upon the correctness of the framework is a new sensation to me. Logically, I do not believe it was the fault of Flash+Flex because listeners are the backbone of all that is interactive. If there are any problems with their listener code, I probably wouldn’t be the lucky first person to discover them. Still, it irks me that I was not able to figure it out grrrr…. On the upside though, I did learn a lot more about the listener/event model which may come in handy later.

Gonna celebrate this happy ending by blowing up some fireworks tonight. Wee.

Starting this project armed with 5-year-old knowledge of Flash proved to be more of a challenge than starting fresh. Despite this, I am actually glad that Flash has changed so dramatically in the last few years because I was initially dreading developing with Actionscript on the IDE provided by Flash. Perhaps it was the concept of linking code to specific frames in animation and not having a coherent way of managing such code; or perhaps it was Actionscript being such a primitive and messy language that I couldn’t imagine how anyone could have built any serious applications with it. In either case, it seems I was not the only one who had these gripes because Actionscript 3.0 and Flex 3 were a quantum leap in allowing developers to build and maintain complex applications in Flash. Surely, this magnitude of change couldn’t have been possible without many angry emails and blog posts from disgruntled developers. As I was reading the books on the subject, I kept reminiscing about just how awkward some of the implementations were in the previous versions of Flash/Actionscript. Fortunately for me, this nostalgia only served as a minor distraction since I do agree with most of the changes and additions (unlike my generic journey from Java 1.4 to 1.5). Nevertheless, I would imagine someone with no prior Flash experience would have a slight advantage over me with learning this stuff. Wenbing probably may want to comment on this.

With my newly restored faith in Flash+Flex development, I am looking forward to the finished product in a few months. I am also excited about doing some nifty things with Flare, but too bad the first milestone of this project doesn’t require it. I am actually a tad bit concerned that Flare is still in alpha. Call it a superstition, but I haven’t had good experiences with early iterations of software with names beginning with “FL” (except maybe Flickr beta, but it wasn’t really a beta anyways). For the sake of this project, let’s hope this superstition has as much truth in it as my horoscopes.

The aim of this project is to build a data connectivity layer for use with the Flare toolkit (http://flare.prefuse.org). This toolkit will allow users to select tables and columns from a SQL database to feed into a transformation and visualization pipeline without writing any explicit code. This involves building a drag-and-drop pipe-and-filter interface modeled on those of Houdini, Maya, and Yahoo! Pipes for use with the Flare toolkit. Work will be done using Flash and Flex.

pipe3f is not an official name for this project (at least we hope not), but it sounded cool at the time when registering for an account for wordpress =p