Gary Menzel wrote:
Yes, but someone tell me who exactly makes up an "Enterprise" corporation, because from what I have read online so far via Blogs, Forums and what not, Enterprise companies are even annoyed with the PRICE model itself.
Now that I am out of "antagonist" mode....
I admit, i had to go to dictionary.com to find out what antagonist means :D
Where I was coming from was that if you already have Flash programmers in a place then they will (or should) have established libraries that allow them to put together Flash applications quickly. It is like we currently are with CFMX. We build reusable stuff that makes doing any one job quicker and quicker each time we do it. Those companies who have a reasonable investment in Flash will probably want to continue developing with thier libraries and wont want to throw that away for FLEX.
In theory yes. In theory, we should all have our code nicely commented, tucked away in CVS. Along with nightly backups, and clear and precise project plans for all our applications along with UML diagrams to boot.
In theory..
Fact is, not a lot of Flash Developers out there don't have a clue, sorry, but majority are still grasping how OOP actually works, let alone building libraries and what not. Flash MX by itself, is a very cumbersome language to harness, and doesn't comply with existing OOP language rules and what not. Majority of the time I find myself emulating a technique that should by rights be part of the overall core engine.
The biggest flaw in FLASH development to date, is the simple fact Flash Development is bottlenecked. We plan to go the RIA path for Bestrates.com.au, now basically this site has a few CFMX programmers working on it every day (new features etc). They can share the load between another, and log the code in and out of CVS. Sadly, I can't do this, if we are to build the Flash site. Sure i could log my Class files into CVS, and the actual Flash Binary file, but even thats not as effecient as FLEX could allow.
Furthermore, if they need to radically change the overall Screen, in that "nah that left panels not working, move it to the right" or "what happens when the browser resizes etc" for me to implement these procedures into place (despite libraries), its a mammoth task. (Asking a total RIA screen to dynamically resize, is a big ask in many ways). FLEX on the other hand removes this constant code crunching or hair pulling every time a piece of screen realestate is changed, further more it also takes care of UI feedback (preloaders, initialization bars, accessability etc etc).
Nope, You still need a lot more work via the Flash MX route to just get it to have basic functionality, and in many RIA apps, its a very un-needed tedious task - shit i just finished biting the bullet and dropped FLASh for a small Internal application, and simply went DHTML.
FLEX could of and should of been a nice saviour, and its not just a cluster of libraries / components. It has more to it than that and its waaaaaaaaaaaaay more versatile then Flash MX IDE approach. The technology is the same but the creation process is totally different.
Companies that have little (or no) Flash expertise - who are usually the less affluent ones - would LOVE to be able to create up bits and pieces with Flash (even whole applications) without having to learn the Flash API's and the IDE. Granted, with FLEX you have to learn a new set of XML tags - but these seem to be intuitive to programmers. Views, Windows, Listboxes, Combo boxes, Trees - all very familiar widgets that are easy to understand in a "tag" format. And we already understand "hierarchy" and "nesting". FLEX would be perfect for this - but the value for money cannot be justified.
I agree :) Its not justified at all.
It goes like this......
We are currently building "dashboard" style systems for internal use (and possibly external use). Flash would probably help us do some of these (and we will probably use it for some things eventually). FLEX would probably make that path quicker (but wouldn't give us any real "Flash" expertise to do the harder things that FLEX may not do - like the NYSE dealing floor, for example). So, we are more likely to spend the budget in training our people to write real Flash applications - even though we could get SWF's out quickly with FLEX. The goal is not to get a few RIA's happening so we can keep pace with the Macromedia world....... The goal is to get a better user experience (which may only be achieved by writing Flash directly and not by using FLEX OR may simply be just a better HTML layout that provides up-to-date information when they view the page).
Honestly, spend the $8 and try out FLEX atleast. A Dashboard setup is the "PERFECT" ideal solution to use FLEX. Its not meant to be a tool to generate a front-end website in Flash, its meant for programmer-art style applications that actually look purty. Furthermore, it reduces the overall screen clumsyness, and allow you to interact with data wayyy more easily from a usability point of view.
If it was a cheap ass price, as we expected it to be, you would of been drooling over the fact that FLEX would of allowed you to do this...shit combine Flex with FCS & Corde PopCharts....omg, you're execs would praise you constantly at how "futuristic" it all is and how actually useable it is (further more how portable it could be as well).
And, if I have to learn the Action Script 2.0 object model to extend FLEX to work the way I want it to - then I am probably more likely just to build everything I want in Flash directly.
No you wouldn't, while you can go deeper with AS2.0, you can get away with tonnes more via tags. Going down the Flash Only path, well thats a road less travelled as much as possible, simply put you'll burn more hours making a button work like an operating systems button or a maximize/minimize window state then you would on the content within that container. FLEX could do this and has done this way more effeciently, but it also allows you to do more of a rapid prototype instead of redsquares on your screen for 2 weeks.
So that is where the budget/pricing/value deliberations come in for us (and we are not a "small" company by any means - although probably not as big as BHP). We have several full Dev-Net subscriptions, we buy the full MM Dev suite for our developers (even though we may not use all the products). We have at least half a dozen CFMX licences. We dont mind spending money. I don't think we are "small" - but we musn't be "Enterprise".
Personally, if you have a development team larger then 2! heh, and you actually own all the license copies of your software, host very big websites and furthermore your not a webdevelopment agency, i'd say you classify as enterprise. Thats my definition anyway.
So yes, it would be nice to know what they mean by "Enterprise" as well. <cynic mode="on">Budget of a Starship Captain perhaps ?</cynic>
Keep in mind a lot of the High Level enterprise organisations have this annoying habit of refering to Flash as a TOY. Further more you are limited in what FLASH player itself can handle, love the product but its
really piss poor when it comes to large amounts of data and heaps of MovieClips.
Interesting.... I suppose we might be suffering from that a little (the "toy" thing). And now that you tell me that it struggles with large amounts of data, we (and others) may be justified in calling it a "toy".
In a nutshell its true, it is a toy on steriods. Its not as sophisticated as JAVA or .NET in regards to coping with large amounts of data and CPU, but its still portable enough to handle client interaction via mediums like the web and has a way smaller payload for the end result. In other words, i wouldn't try writing a 3D animation program in Flash or have an online encylopedia inside one SWF file :D
In the stock broking industry you can really end up with a lot of data. Even if you just want to graph a week of intra-day prices for a single stock you will end up with a LOT of data (especially if that stock has had a good trading week). And often people will want to compare that data against a competitor and or one of the generic indices. That will double or triple the data.
And, worse than that, people probably want the current stuff in real time (i.e. as we get changes through). So that brings Flash Communication Server into the picture.
Yes and no, FCS is fast and is "real time" in many ways, but it too suffers from latency. XMLSockets work just as good as FSC but not as uber goood as FCS :D
But you are right in saying FCS and FLEX should go side by side, as its a classic case of how "enterprise" personnel could leverage things like shared objects more effeciently. (Project management applications would be far superior in Flash/FCS then they would in normal Client approach, as it would allow them to be taken on the road or accessed remotely via the web)
All in all, there's lots of money to pay to get the solutions, lots more money involved in learning how to use them effectively (FLEX vs Flash direct), and then you have to hope that the solution will actually bear up well under the data loads. And if it doesn't you are probably stuffed.
Yes, possibly a "toy" - and an expensive one at that.
Aren't all adult toys expensive *hehehehe* ....hey mind out of the gutter, i meant fast cars.....
--
Regards, Scott Barnes - http://www.mossyblog.com http://www.bestrates.com.au
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
