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
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.
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.
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 184.108.40.206. There were some other minor fixes in Flash Player 220.127.116.11 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.
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.
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!