Blog

  • Table Topics RIA

    I used this as an example in a Flashcoders post yesterday, and after searching my blog in vain, realized I never blogged it. I completed this over a year ago!

    :: smacks head ::

    Table Topics – Table Designer: A Rich Internet Application

    Or, to see it in the actual website (which I didn’t build, nor was I involved with):
    – go to tabletopics.biz
    – click on the “Virtual Designer”, highlighted in yellow

    Background

    In the Fall of 2003, I was asked by a friend and fellow contractor, Jason Key (who worked on Delgo @ Fathom Studios, the entertainment division within MacQuarium here in Midtown, Atlanta) (he’s also with Mental Models), if I could work on a Flash application he was contracted to help on. At the time, I was deep in learning the then newly released Flash MX 2004, so naturally I was all over anything that was allowing me to code in ActionScript 2.0 since my job at the time had strict requirements for ActionScript 1.0.

    Also, Jason sold me on the project because he was excited, passionate, and a designer. I hadn’t worked with real designers on projects for about a year and a half at that point, so was suffering some serious withdrawal.

    Basically, Georgia Tech funded money to Table Topics for their app. Table Topics had Zoom(or was it Xoom?) Design build them an entire Flash site. For the application part, they contracted Jason. Jason Keys then contracted me to do the Flash Programming. Noooooooooowwww do you see why networking is an important skillet to learn?

    What did the client want? An application to allow customers to pick and choose the table design they wanted. They were plagued with the problem of customers feeling they were locked into specific designs and cuts for tables. Table Topics knew they had the capability to create just about any table combination from their available materials, but wasn’t sure how to best communicate that online.

    Enter Zoom Design + Jason Keys + JesterXL + Flash.

    Technicalities

    Jason ended up doing 5000+ JPEG’s for the application. The gist was, every table’s frame, inset, and trim had to be modeled and textured in 3D, and then exported out and cleaned up in Photoshop. Two versions of these had to be done for the 3 different views in the app. Jason had some mad 3D skillz, and wrote a lot of Photoshop batch actions to expedite his development time.

    He also managed ALL contracting interactions, which was great. I didn’t have to deal with anyone but him; he did a great job at managing me, managing the project when technical issues arose, and keeping scope creep at bay with an iron fist.

    I worked from home, he worked from home, and we met in person about 6 times over the course of 3 months (November to March total communication, December to end of February total development time), and had numerous phone and email conversations. That was a blast balancing with a full-time job.

    Flash Part

    Although I wrote it in Flash MX 2004, I made the call (which I had the authority to do which felt awesome) to target the lowest common denominator, Flash 6.0.41.0. There were some other minor fixes in Flash Player 6.0.41.0 that I wanted beyond the device text masking, but I felt that this was a great install base at the time.

    I still wrote everything in AS2, but did not use package paths (didn’t know them at the time), and everything pretty much inherited from MovieClip (wasn’t comfortable with UIComponent at the time). This was one of the great deployment features Macromedia put into Flash MX 2004; the ability to work with the latest syntax, but compile to an older player.

    This was also the last project I ever used SharedLibraries on. The catch 22 with Flash MX 2004 was, the more AS2 compliant you were (using private & public, type-casting), the slower your compiling became. I thought at the time SharedLibraries would expedite my development time since I’d be compiling a bunch of smaller components making unit testing easier, but it was a management nightmare the minute I changed my mind on a setup, or wanted to move things around a bit. I also only used 1 component in more than 1 place, but considering it was all still compiled to 1 SWF, it was a pointless endeavor in retrospect (I only learned this at the end of the project, naturally).

    I utilized the Flash MX components updated to AS2 so I could still work with AS2, but compile to a Flash app that “looked” like a RIA from the time. The Flash MX 2004 components also had a bigger file size footprint, and even with preloading, the updated Flash MX ones were smaller, less overhead, and had a more consistent look.

    I created 1 XML file to load in all of the images. Basically, 1 XML file listed all frames, insets, and trims, and each image had 1 large version, 1 medium version, and 1 texture thumbnail, resulting in 5000+ images (poor Jason, I know). The XML file was a single node, attribute holding an image tag which described all of the images. This was done to expedite parsing. Flash Player 6’s XML parsing was phenomenally better than Flash 5, but I wanted to be conservative as testing on slower machines, you could still see a noticeable hit. It was definitely acceptable by Jakob Nielsen standards.

    The image filenames were used to determine what type they were, what size they were, and what section they went under. This was agreed upon and tested by Jason and I upfront. This parsing of string filenames to a usable object structure is actually what the main bottleneck in the entire application was. The 256k XML file took about 600 milliseconds to parse, but the string to object parsing took up to 2 seconds.

    Loading 5000+ external JPEG images on the fly? No problem, says Flash, I got you, twice on Sundays. This effectively allows the user to configure over 2 million combinations of tables, making Table Topics very happy. Go Flash.

    To add new categories, all Jason had to do was do this via the filenames. Since the client was STILL photographing pictures whilst in production, Jason wasn’t getting textures and profile shapes till late in the game. This setup allowed him to work independently, and confidently, without me. This became very important later on when Jason started working at Fantom studios, and had very little time for the project or to interact with me. Freeing him from needing me was a good thing.

    Why No Content Management System?

    Why no CMS? I tried building a GUI front-end to allow the client, Jason, anyone, to drag and drop images onto their respective sections (Large, Medium, and Thumbnail), give them a category name, and export this out to XML. It was taking too long, however, and this time wasn’t in the project budget, whether an offline Win32 app (Flash + Screenweaver), or online using PHP & MySQL. I did use Screenweaver, however, to auto-generate the XML file for the images. Basically, you’d open the app, drag the folder full of updated JPEG’s on it, and it’d read the directory, and auto-generate the XML, and then write it to an XML file in the same directory. Quick and easy for anyone to update the images used in the app without needing to recompile Flash.

    We also had a blast getting the “soft mask” effect, where instead of a cut and dry mask, it has a gradient. This took a ton of phone calls, exact pixel measurements in 3D, Photoshop, and Flash, the drawing API to help see where things really were, and tons of trial and error, but damn did we ever get it, and drank merrily when we did!

    The Famous “Last 10%”
    Naturally, the client started upping the left-fields once they saw what was possible. This, in my eyes, happened because of the long chain of communication, which is totally fine, but being me and always wanting to please everyone, this was hard. For example, the first thing is they wanted to take this “built for the web app” on sales calls via a laptop. Uh, ok, here’s the files, burn to CD. Go Flash, again!

    The second thing was rules… this is where things got reallllly hard. Like, currently, you just have all images fall into their respective types and categories. But, only some frames work with some profiles… some are limited time, some only in specific colors or textures, etc. I tried adding some, but the way it was designed wasn’t meant for rules; it was a dumb system, on purpose, made simplistic for easy updating. I had specifically asked in the very beginning if this was needed, and all of us had heard “no, the client won’t need to update this, nor will they have rules”, but in retrospect it was very unfair to the client.

    First off, if you don’t know what “updatable” means, you can’t really communicate it to the client. Therefore, since I didn’t have the opportunity to actually sit with the client, and explain potential development paths with pros and cons, no one at the time could effectively communicate it anyway.

    Secondly, if you don’t know what’s capable, you can’t really envision building atop that vision. If you don’t know what you can really do on the web, then how can you realistically be asked and held accountable for decisions made? You can’t, that’s unfair, and being setup for failure. What I should of done was cite other sites and application examples to the client so they could understand what I was talking about. If I had done this, I would of felt confident in Jason & Zoom Design’s ability to communicate this without me there.

    Finally, there were some technical challenges for the design studio to implement my application in their web environment. I worked with them via phone, providing most of the needed JavaScript, HTML, and ActionScript to ensure an easy as possible deployment scenario. Another, totally independent, developed separately, Flash website had to launch my app. This ended up being very easily implemented and communicated once I got on the phone with the Flash designer in charge; email didn’t work at all. Go Flash for the third time!

    Future Version

    So, of course, the client wanted a round 2 quote since I refused to implement any additional hard coded rules into the application. Debugging was becoming a nightmare, exponential in time for each new rule implemented, and it wasn’t fair to them, nor me given the current architecture. I had 2 meetings, each 2 months apart with different companies on the possibility of a rewrite. I talked about functionality, debated and discussed feature sets and how they worked, and quoted the whole project and had both quotes initially accepted.

    …however, I was out of time. I was then writing some chapters for the Flash Communication Server Bible, and involved in all kinds of extracurricular projects, offline and on, tech editing books, and was about to start school again.

    Conclusion

    Regardless, that was a fun and successful project. I learned a lot, gained a lot of experience, and most important of all the client was extremely pleased. More proof that RIA’s help businesses’ provide better experiences to their customers online… and off!

  • D&D Dice Roller v2

    I re-did my old Central Dice Roller using Flex. Basing it off of the one Wizards of the Coast did, I improved on what they had. I also improved my old one, and included it.

    I’ve been “salvaging” code all weekend; where you go through old and current projects, and look for code that you could easily encapsulate into resuable tools. The Dice Roller was one of the only things that could stand alone without Flashcom from my D&D Tools set, so it was very easy to pull out, clean up, and post. I’ve submitted to Wizards of the Coast forums; I hope they like it since they never saw the old version.

    Flex D&D Dice Roller – See It | Download Source (ZIP)

  • Flex Chronicles #10: Installing Flex on Windows XP Using Tomcat & Apache

    I can’t believe it, but I got it to work with some major help from Flexcoders (thanks Andrew Spaulding and Simon Jenkins!).

    I’ve never installed, re-installed, toggled services on & off, and tweaked my router & networking settings so much in my life. I can’t believe server people actually like this stuff. I just want a SWF…

    Another night of gaining respect and appreciation for server-side Java developers, amen.

    • First, I downloaded Flex 1.5, installed with my Non-Commercial Serial Number.
    • Second, I installed Apache Tomcat 4.1.30 (since 5.5.x, and 5.0.x wouldn’t start). Additionally, I had already installed the Java 1.4.2_06 J2E… runtime thing, and the JAVA_HOME was already an environment variable.
    • I copied my flex.war and samples.war to the Tomcat/webapps folder and it automatically extracted them.
    • I then tested my local samples via http://localhost:8080/samples, and it worked cool (I actually typed about 50 combos till I found the right port)
    • However, my server computer wouldn’t accept web traffice from my Alienware, which are both behind my router. So, I port forwarded 8080 on my router to point to my server box.
    • Then, I turned my Windows XP firewall off on my server box.

    She works, but my server is sooooooooo slow to compile my Flex apps vs. my Alienware running JRun. At least now I’m legal.

  • Flex Chronicles #9: No Library? No Worries.

    Someone who uses ActionScript heavily in Flex, I embed my graphics in Flex (since it doesn’t have a Library like Flash) using code, like so:

    [Embed(source="../../../images/dice.swf" symbol="d4")]
    static public var d4_img:String;

    If it was just a PNG or JPEG, I could remove the symbol attribute. That is for SWF files, which I like to use heavily; it removes the amount of images I have in my Flex application folders; 1 SWF vs. dozens of images folders containing dozens of images.

    The other way is to merely embed it on the image itself:

    <mx:Image source="@Embed(‘../../../images/dice.swf#d6’)" width="41" height="46" />

    The problem is, combining these techniques will cause collisions; Flex will not compile your app saying that the image was already imported.

    To solve this, I created a library of my own, in ActionScript. The technique goes something like this. You should not use _global variables in Flash, thus, you use static classes with static, public variables. All you then have to do is import the static class, and you can then access it’s variables. If you make 1 class, called “Library”, and do all of your image embedding in it, you can then consolidate, and self-contain all of your image assets into 1 file, thus avoiding collisions where other files try to embed assets already embedded elsewhere.

    So, an example class would be:

    class com.jxl.Library
    {
            [Embed(source="../../../images/dice.swf" symbol="d4")]
            static public var d4_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d6")]
            static public var d6_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d8")]
            static public var d8_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d10")]
            static public var d10_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d12")]
            static public var d12_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d20")]
            static public var d20_img:String;
            
            [Embed(source="../../../images/dice.swf" symbol="d100")]
            static public var d100_img:String;
    }
    

    Example usage for ActionScript:

    import com.jxl.Library;
    
    private var image_ldr:mx.controls.Image;
    image_ldr.contentPath = Library.d4_img;

    Example usage for Flex tags:

    <mx:Image source="{com.jxl.Library.d4_img}" width="39" height="46" />

    This will hopefully help prevent collisions, keep your library assets organized, and make them easily accessible.