I'm furious about the price and have been very vocal about this with
Macromedia over the last week.
I think they have made a major mistake with this.
I can feel another Spectra coming on!
Eeek. Spectra had its own set of issues, not just pricing model. FLEX pricing model aside, is a very sweet and mature product. You still have the limitations of the Flash Player and the fact that the Flash Player can't handle too much data within, that and nesting tags inside one another in FLEX could be death by fire... that aside, its still got a lot of positives associated with it and i'd be less likely to quickly rush out with the "another spectra/flash generator" banner just yet. Especially if its based on price model alone.
Having said that, it might be a another good opportunity for someone like the Daemon guys to come up with a sensible product that works in a similar way at a price that people can afford. And one that even integrates better with other MM products.
I very much doubt anyone else could come close to what FLEX has to offer just yet. Keep in mind folks, this is a project that has lasted a very long time in Macromedia, and not only that its been the one project they have spent the most resources and time on yet. This wasn't just slapped together easily enough, that i can contest to.
So for other companies to suddenly approach the product from a "well its just XML, therefore its just Flash reading instructions on how its to be displayed" is not the case. FLEX infact is a compiler in itself, in that you could generate dynamic imagery on the fly, not as sofisticated as other products (ie [EMAIL PROTECTED] fav product) but none the less, you can do some dynamically cool things with FLEX server itself (framework aside).
There is nothing "earth shattering" in the concept of the FLEX technology. Come up with your own XML schema (give it a swanky name) and make a server that can generate the SWF (along with a little library to talk back to the server) and then build an IDE (even a web-based one written in Flash) to hook it all together.
Thats were i'd have to shoot you down a bit, in that it is really earth shattering from a perspective of development capabilities in regards to FLASH as a whole.
Version 1.0 has still got its own teething problems, and i know first hand whats still yet to come in the future, i personally forsee FLEX to be a very big step forward in involving FLASH into existing technologies out there, if the price wasn't so steep of course. I will further gurantee you that if you went a pepsi challenge on a FLash IDE vs FLEX development project, FLEX would cain yo butt 4 times over.
There is a very similar JavaScript solution available now (XML schema based, with a JavaScript API). Maybe it does not have all the Flash libraries - but the concept is just the same.
There are a few, this isn't such a radically new concept XUL comes to mind. Hell, i first had this idea about using XML to layout Flash components waaaaaaaaaaaaaaay before i even heard of royale, back on Macrofun i posted my theory on it.. Thats how i got into the beta in the first place as [EMAIL PROTECTED] saw my idea and went "hey, thats kind of what we are doing, want to beta test it for us". So for a monkey like me to look at FLash, then back at XML and well connect the two, surely this isn't so new... but it is when you look at whats AVAILABLE. Thats the difference, while there are test patterns out there on XML + GUI, none have yet reached maturity.
I'm doing that very same thing now with other projects I am working on (XML schema, some sort of engine to understand and render it - CFMX or JavaScript) and "voila!" you have a new language to deploy things with.
Yet, you won't be able to deploy it without a browser, furthermore universal platform dependent. Oh and throw in Accessibility, mixed with UI feedback oh and lets not forget keep UI consistent accross all platforms down to the pixel if need be... Thats the difference I guess.
I asked at MXDU about FLEX integration with Flash Communication Server and all I got was a blank look.
I asked the Same, twice and i did get a response. FLash Communication server is just that, a seperate product and theres no real connection between the two, in that if you want to use FSC with FLEX, you still can quite easily enough (much like you would with FLASH MX IDE). I expect a release of FCS components to slot into the existing FLEX TagLib eventually, but personally i think FCS and FLEX should be more closely coupled and for 12k, i would expect a free copy of FCS.
This would have a positive impact on the FCS community as a whole and help drive some momentum back into this product. I for one am nervous along with Barry (we brought this up in our presentation at MXDU) that the whole FCS seems to have died, thus we haven't dared used the product fully on our commercial websites etc, for fear it may die off. Its one thing to have the technology, its another to have it for a period of tim e other then its initial marketing PR.
And then when I said that any FLEX solution that we were likely to use (regardless of price) would need to either integrate with FCS and/or have FCS built into the FLEX server......
Another blank look.
Read above.
As many of you know, I am still not a Flash convert (even now having done a couple of full tutorials - basic and advanced). I had hoped that FLEX would push me more in that direction (so I did not have to wrangle with the Flash IDE). But I can't see this being a viable solution. I want it to build quick and clean (rather than dirty) Flash plug-in applications. It can do that - but the cost is stupid. Our organisation will tell me to build it using JavaScript.
And, while we are not actually a large multi-national company, we have got the money to spend on a FLEX server if we wanted it. It's not that we cant afford to pay the price - it's that the price is ridiculous.
A lot of organisations will, ABN Morgans isn't a small fish, along with organisations like Tourism Queensland. We have the money to burn if we felt we were getting a good investment, but while i don't speak for Barry *he's the one with the cheque book*, i'd be very reluctant to purchase it for 12kUSD. As the hidden costs have to also be factored into it asweel (more on this via mossyblog.com shortly).
But then, by MM's definition, we aren't the customer they are looking for - because we don't want to pay that price!
I honestly think they are caught up in the dreamland that which is Enterprise, i guess you look at the comparison between the JAVA/.NET old skool programmers vs the web-script community (such as us) there is of course a bigger market and they look to have fatter wallets. I can see how and why they want to target such a level of market share, but in all honesty, i don't think Macromedia as a brand has enough PR might to make these guys notice. Time will tell who is right/wrong.
To me, it is SMALL BUDGET places that will get the best benefit out of FLEX because they can't afford to pay a swag of different programmers and designers to deliver Flash, HTML and Cold Fusion. They can only really afford one or two people who have to do the lot. And relieving some of the pressure (i.e. using FLEX instead of Flash directly at a SENSIBLE price) would be a goldmine for MM if they priced it right. The people that can afford a couple of Flash developers and a handful of CF programmers - as well some good CSS/XHTML designers - will, in most cases, prefer to write their own stuff. And, in talking to many of the people at MXDU, this was the "mood" towards the pricing (even before it was announced officially). But this was all said at MXDU and even sign language was not enough to open the deaf ears.
And there is another thing.....
I also asked at MXDU about multiple templates for FLEX (other than just Halo)......
You can skin easily enough with FLEX, the hardest part is grasping the V2 framework firstly, then understanding the flexforflash skinning procedure. You also are not totally 100% locked into the HALO components, you can render a UI layout quite as easily enough much like you would with traditional HTML (table layouts - topLeft,Top,TopRight,Left,Middle,Right,BotLeft,Bottom,BotRight) approach.
Take a closer look at the HBOX/VBOX tags along with the CANVAS tags, you will notice it has great capabilities for custom UI aswell.
If you do decide to go your own Skin path, and manage to understand the processs (i have, took some effort) you simply export the entire skinpak into a SWC file, then simply put in your <mx:Application themeSrc="mySkinPack.swc"> and walla your entire application will feed off that skin pack (ie you can even partially skin using custom UI, and still adhere to the HALO look).
Hardest element to date to skin for me was the <mx:Panel> thats a tuff sucker.
--
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
