I had an epiphany this morning in regards to a piece of functionality I’m developing at work. I like to challenge myself, and I find tackling really complicated forms satisfies that need. I have to not only meet the business requirements of saving the data to the pre-determined data model, presenting the forms in a useable fashion so the user feels like they are real forms, but also integrate some of the features Flex/Flash have into that old format.
Forms are typically presented in a linear format, and each filled out form is submitted, with either a success or error, very wizard-like. With Flex/Flash, you have a bunch of added benefits. Flex automatically handles the tabbing (where it’s a pain in the neck in Flash), but both allow ALL data to be saved and created into the data-model in real-time with the added ability to hand that data model off to the server-side in something it can easily understand without the page refresh, something AJAX currently cannot do without a lot of overhead parsing. You can cache the data locally in case occasional/disparate connectivity is an issue, and post later if needed, just like cookies are used in HTML forms, but with the added feature of treating it as a native object; something more easily understood with no parsing required.
Where things really shine, however, is the ability to more easily and quickly create a GUI that matches the designer and architect’s idea of how the interface should be and work. And there-in lies the problem. We developed a really powerful way to obtain some very complex data from the user, which thankfully, they will know ahead of time what type the data is, how it will be viewed, and will have preconceived notions about the verbage of how that data is displayed. This is great because it makes meeting those expectations in the GUI easy, and the client can more easily enter in data the way they want it to… which is why the whole CMS business pays my salary, regardless of employer.
…however, that’s also the problem. Because things are so easy to match, visual designers are given more leeway in their UI, and do not have to worry about technical restraints as much. “Will this design be able to render friendly and degrade in a variety of browsers? Will my vision of how this is supposed to work really be achievable by the front end and back-end developers?”
Naturally, being who I am, my resounding answer is, “BRING IT ON!!!”. And that was my downfall. Give me enough time, and I’ll code anything. Granted, I can see pointless endeavors such as trying to get Flash 7 to render 10,000 records in a DataGrid, even if that means re-writing your own DataGrid. What’s the point? There are more powerful ways to display data than just dumped in a DataGrid, and technical ways to cache and page the data. But as you just read, I still attempted to solve it in a more pragmatic way. Can Flash Player 7 display 10,000 records at a reasonable speed on a reasonable target platform? Yes. Is it worth doing? No.
I have a form at work that is a base class for a bunch of other forms. In 90% of the use cases, it works great. Dynamically allowing the user to create as much data as they want, to be able to scroll through and edit that data quickly is really powerful and makes me proud to create such things with my fellow developers.
However, there is one niche case where it is being pushed beyond a simple form. The data is so complex, that you start to get into a forest for the trees complex. Making a simple, multi-form base to work with extremely complicated forms, each having extremely deep and nested data is a challenge upon itself. And herein lies the divergence: You can either succeed on the fringe use case, and have an extremely powerful way to enter and display complex data for creation & editing in the CMS, or break it down in smaller, more manageable chunks, which will take less time to do, but have less emotional impact. Both satisfy the same overall goal of CRUD operations (Create/Read/Update/Delete), but the former is extremely impressive, showcasing the best of what Flex/Flash have to offer where the later barely beats HTML.
However, there are 2 key factors here which are now abundantly clear; if you satisfy the goal in less time, does it really matter? Yes, we have the potential to really knock this specific piece of functionality out of the park, scoring a homerun impression. However, at what cost? Could we get a lesser effect within an extremely more reasonable timeframe? Yes.
Bottom line, a “well done” for 1 weeks’ worth of work is better than a “NICE JOB!!!” for 4 weeks worth. We as Flex/Flash developers are already showcasing the cream of the crop in form based applications. The temptation for those who are ambitious as well as perfectionists to not only impress the client, but blow them out of the water has a cost. Hopefully I’m getting more pragmatic, or maybe it’s just cynical, but from now on, I’m shooting for what is awesome, but immediately body checking those expectations with the time cost. Does that extra week gain the client anything? Yes, I’m extremely proud of myself after 2 weeks instead of 1, knowing that that extra week paid off in the architecture, but did it pay off for the client, and ultimately the end user?
Translating my time’s development cost, the time estimations for each projected functionality goal, and providing optional solutions is tough, even more so when trying to suppress my natural developer’s urge to “make it cooler”. I guess this is why they call it “learning”.
