Hi David,

I agree with you on all the good thing Flash can do. I think the rate of
innovation of AJAX/DHTML application as not being frozen on the last 5 year
you can simply put your nose out there, in a world outside of your enclosed
Flash cocoon where you seems to think that it's the best for everything.

Many examples of AJAX are built with DHTML and Not Flash
e.g. Google Map, Google Suggest, http://www.37signals.com/
, http://www.zimbra.com/, http://del.icio.us etc...

This simply because there is no need of flash for most of this application
and they offer much better experiences then downloading a new flash player
or upgrading each time you guy bring new functionality into the plugin. Yes
because we have to remember on things here Flash Player is a Plugin and if
you don't download it and install it you whole user experience is reduced to
an really ugly icon and you don't nothing instead.

I apologise in advance to you and all Flash lover out there, but please can
you explain to me why when you install Flash Player 8 on your machine it
will install Yahoo toolbar without asking you if you even want to have the
yahoo toolbar.

I'm a UI application developer mostly writing DHTML but often I will direct
Project manager and designer too choose Flash over DHTML because I recognise
that they are other technology out there who are better suited for the
application we are building.
Please don't close your mind on this kind of thing specially now when we are
living in the new internet boom where the vibe is too work together not
against each other.

Laurent

Ps: Sometimes you need to think outside the Box you are living in

-----Original Message-----
From: ajax_and_ria@yahoogroups.com [mailto:ajax_and_ria@yahoogroups.com] On
Behalf Of David Mendels
Sent: 19 November 2005 03:39
To: ajax_and_ria@yahoogroups.com
Subject: RE: [ajax_and_ria] Flash / AJAX decision making

Jon,

Good points.

One thing then to note however, as it relates to (1) is the rate of
innovation and rate of distribution of " underlying capabilities of the
client-side enabling technology. "  Indeed, this is one of the key
points of different between Flash and AJAX/DHTML and again it can lead
to comparing apples to oranges.

With the Flash Player, we are able to introduce major new functionality,
synced with new tooling, every 1-2 years (less in the case of 8.5) and
get 50%+ adoption in less than 6 months. (Recently our rate of
distribution is accelerating with over 5M successful installs per day.)
Further, with the Flash Player less than 1 meg, broadband usage
ubiquitous for *some* communities and application scenarios, and Flash
Player's "Express Intstall", the Player can upgrade itself with a single
click and in less time than some web pages might take to load.  Contrast
the client side technology for AJAX/DHTML, the pace of innovation has
been glacial for the last 5 years, and when new functionality is
introduced it takes an incredibly long time for it to be distributed and
accepted widely, and even then, there is a frequent occurrence of
incompatibilities between different implementations. Relating this to
the example you provide below, if the Flash Player advanced its text
layout engine, one could reasonably start to target that for
applications being deployed soon after the new Flash Player was released
(eg within 6 months if your target distribution was 50%+).  However, if
Firefox added native access to WebCams, or IE did that, you might want
2-5 times longer before you could reasonably count on 50+ penetration.
Further, with broadband + "Express Install" I think the equation changes
dramatically and many people will start to target the capabilities of a
new Flash Player as soon as it is released--we are for example already
starting to see many major internet properties (Sony Pictures, Toyota,
etc.) taking advantage of features that *require* Flash Player 8 within
3 months of shipping Flash Player 8.  That is new in 2005 and is
accelerating. I think it is an exciting change and can really enable
developers to leverage state of the art technology much more quickly and
create more compelling applications.

-David


> -----Original Message-----
> From: ajax_and_ria@yahoogroups.com
> [mailto:ajax_and_ria@yahoogroups.com] On Behalf Of Jonathan Boutelle
> Sent: Friday, November 18, 2005 5:27 PM
> To: ajax_and_ria@yahoogroups.com; ajax_and_ria@yahoogroups.com
> Subject: RE: [ajax_and_ria] Flash / AJAX decision making
>
> David,
>
> I agree that this conversation ends up having "apples to
> oranges" problems.
>
> There are at least two dimensions to the decision:
>
> 1)The underlying capabilities of the client-side enabling technology.
> In the case of Flash, this is whatever version of the Flash
> plugin is currently at 50%+ adoption. In the case of AJAX,
> this is the DOM, and javascript objects, and html rendering
> capabilities supported by the major browser vendors.
>
> 2)The engineering framework used to build software that uses
> this client-side technology. In the case of Flash, this is
> FLEX 2 and the latest version of the Flash IDE. In the case
> of AJAX this is the unruly but rapidly improving open-source
> frameworks (RICO, DOJO, MOCHI, et al), and the more mature
> but proprietary commercial frameworks (hi Jep!).
>
> As application developers, we live in the world of (2). We
> install the IDEs and learn the APIs, and improvements in
> these make our lives dramatically easier over time. But (1)
> is where the longer-lasting constraints are. (2) gets rapidly
> better over time, while (1) has a potentially greater impact
> on the core nature of the application.
>
> For example, FLEX 2 may (hypothetically) bring rapid
> application development nirvana. But if the Flash plugin is a
> weak way to display or work with text, FLEX 2 won't change
> that. If browsers don't provide a javascript API that gives
> native access to client microphones and webcams, that's also
> unlikely to change in the next several years.
>
> I'm more interested in (1) than (2), because I think it forms
> the basis for decisions that will hold up over time.
> -Jon
>
> At 12:20 PM 11/18/2005, David Mendels wrote:
> >  Hi All,
> >
> >Interesting thread.  I am from Macromedia and certainly
> biased, but I
> >do think there are strengths for each and I'll try to write some
> >relatively balanced notes:
> >
> >I think the discussion is a bit awkward however because we are
> >comparing apples and oranges in many cases.  Some people discussing
> >Flash really are talking about the Flash of 1-2 to 5 years ago,
> >pre-Flex and certainly pre Flash Player 8.5.  As for AJAX, are we
> >basing the discussion on the "roll your own" case, or on some of the
> >frameworks/tools that are available, or on a specific tool/framework
> >such as Tibco GI or Backbase?  The pros and cons differ greatly
> >depending on which of these you are comparing to which.
> >
> >Trying to parse this out a bit, some high level pros and cons that
> >aren't dependent on which version, tool or framework you are using:
> >
> >Flash is better at handling rich media, audio, video,
> graphic effects,
> >transitions, motion graphics, data visualization.  It is
> also better at
> >handling binary data streams, two way audio and video. It has much
> >richer capabilities for local data storage. In general, it
> excels are
> >creating an integrated media "experience" that is highly branded. It
> >excels at creating cross-browser applications that runs identically
> >across OS/Browser. In Player 8.5, it has a faster, more
> robust and more
> >advanced javascript engine (ECMA-Script) than any browser today with
> >better XML handling (E4X) which consistancy across
> browsers/platforms.
> >Flash is better for applications that need to received
> "pushed" data as
> >well as offline and occasionally connected use cases.  Flash
> has higher
> >quality and richer printing capabilities (though historically
> >developers have not taken enough advantage of this.)
> >
> >Ajax/DHTML is better for adding incremental functionality to an
> >existing HTML/DHTML page. Eg. If you have a page with a search box,
> >adding "google suggest" style intelligence to that search
> field.  This
> >can be done in Flash, but it is easier to add it incrementally to
> >existing pages/apps with AJAX/DHTML.  I have to say I think
> that is the
> >biggest single advantage because it lets people adopt AJAX
> more gradually.
> >HTML/DHTML have in some ways richer text layout capabilities
> than the
> >Flash Player for flowed text, large blocks of text, text with inline
> >graphics. (Flash Player has stonger support for non system
> fonts, font
> >anti-aliasing, text effects, text on a path).
> >
> >Neither one inherently loads faster than the other--that
> depends on the
> >app and the design. Neither one appears to be generally more
> performant
> >than the other--this also is highly dependent on the app and the
> >design--there are clearly cases where one is much better
> than the other.
> >It is important not to ascribe design choices to the underlying
> >technology.  For example, Google Maps (AJAX) load a bit faster than
> >Yahoo Maps (Flex/Flash).  However Yahoo maps has significantly more
> >functionality in the client.  That was a design choice--as a
> user, you
> >can decide which you like better, but it doesn't in and of
> itself tell
> >you if AJAX loads faster than Flash.
> >
> >As for accessibility, HTML has advantages for simple use cases,
> >Flash/Flex appears to have the edge for complex applications.
> >
> >As for back end integration, Flash/Flex provides many more options:
> >Remote Object invocation, Messaging, Binary Sockets, etc.
> >
> >As for skinning and styling, I think that this has historically been
> >harder in Flash, but with Flex 2.0 it is now easier and more
> flexbile
> >than any specific AJAX approach I have seen. Both have good
> support for
> >CSS.
> >
> >As far as standards support and openness, I think
> counter-intuitively
> >Flash now has an equal story with better support for the recent ECMA
> >Script standard, E4X, CSS support, XML/SOAP/WSDL support, and a
> >published and widely implemented fileformat and much much wider OS
> >support (including game machines, cell phones, cameras, MP3 devices,
> >etc). AJAX/DHTML of course has better support for HTML
> itself, but has
> >to wrestle with different implementations in different
> >browsers/platforms.
> >
> >As for developer productivity and maintainability, the "roll
> your own"
> >approach with both Flash and AJAX/DHTML tends to be hard to
> maintain in
> >both cases and developer productivity varies greatly with the very
> >specific experience of the developer.  At the moment, I believe the
> >Flex offers an order of magnitude advantage in developer
> productivity,
> >maintainability, extensibility for complex applications.
> Talking with
> >developers of large and complex applications (eg. A mortgage loan
> >application with over 1M lines of code, or a insurance company agent
> >broker application with a 30 person 12-18 month development
> cycle) the
> >advantages of Flex and Flash increase dramatically over AJAX/DHTML.
> >Testing costs are generally also lower because of better
> cross browser
> >compatibility. That said, at this point the fair comparison
> is not Flex
> >2.0 vs "roll your own" AJAX/DHTML, but with toolkits such as
> Tibco GI,
> >Backbase or OpenRico.org.  Each one of those would require
> some depth
> >of knowledge to do a fair competitive review and I can't do
> that, but I
> >think as this discussion continues it is important to
> compare apples to
> >apples. One should compare upfront cost, TCO, tooling,
> framework, etc
> >etc etc.
> >
> >Regards,
> >
> >David
> >Macromedia
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
> ----^-------^------^--------^-------^
> Jon Boutelle
> Principal, Uzanto Consulting
> Mountain View, CA
>
> Office Phone:650-564-0000
> Cell Phone   :510-708-9825
> skype id: jboutelle
> www.uzanto.com
> www.jonathanboutelle.com
> ----^-------^------^--------^-------^
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> Get fast access to your favorite
> Yahoo! Groups. Make Yahoo! your home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/spZplB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>




Yahoo! Groups Links

Jon,

Good points.

One thing then to note however, as it relates to (1) is the rate of
innovation and rate of distribution of " underlying capabilities of the
client-side enabling technology. "  Indeed, this is one of the key
points of different between Flash and AJAX/DHTML and again it can lead
to comparing apples to oranges.

With the Flash Player, we are able to introduce major new functionality,
synced with new tooling, every 1-2 years (less in the case of 8.5) and
get 50%+ adoption in less than 6 months. (Recently our rate of
distribution is accelerating with over 5M successful installs per day.)
Further, with the Flash Player less than 1 meg, broadband usage
ubiquitous for *some* communities and application scenarios, and Flash
Player's "Express Intstall", the Player can upgrade itself with a single
click and in less time than some web pages might take to load.  Contrast
the client side technology for AJAX/DHTML, the pace of innovation has
been glacial for the last 5 years, and when new functionality is
introduced it takes an incredibly long time for it to be distributed and
accepted widely, and even then, there is a frequent occurrence of
incompatibilities between different implementations. Relating this to
the example you provide below, if the Flash Player advanced its text
layout engine, one could reasonably start to target that for
applications being deployed soon after the new Flash Player was released
(eg within 6 months if your target distribution was 50%+).  However, if
Firefox added native access to WebCams, or IE did that, you might want
2-5 times longer before you could reasonably count on 50+ penetration.
Further, with broadband + "Express Install" I think the equation changes
dramatically and many people will start to target the capabilities of a
new Flash Player as soon as it is released--we are for example already
starting to see many major internet properties (Sony Pictures, Toyota,
etc.) taking advantage of features that *require* Flash Player 8 within
3 months of shipping Flash Player 8.  That is new in 2005 and is
accelerating. I think it is an exciting change and can really enable
developers to leverage state of the art technology much more quickly and
create more compelling applications.

-David


> -----Original Message-----
> From: ajax_and_ria@yahoogroups.com
> [mailto:ajax_and_ria@yahoogroups.com] On Behalf Of Jonathan Boutelle
> Sent: Friday, November 18, 2005 5:27 PM
> To: ajax_and_ria@yahoogroups.com; ajax_and_ria@yahoogroups.com
> Subject: RE: [ajax_and_ria] Flash / AJAX decision making
>
> David,
>
> I agree that this conversation ends up having "apples to
> oranges" problems.
>
> There are at least two dimensions to the decision:
>
> 1)The underlying capabilities of the client-side enabling technology.
> In the case of Flash, this is whatever version of the Flash
> plugin is currently at 50%+ adoption. In the case of AJAX,
> this is the DOM, and javascript objects, and html rendering
> capabilities supported by the major browser vendors.
>
> 2)The engineering framework used to build software that uses
> this client-side technology. In the case of Flash, this is
> FLEX 2 and the latest version of the Flash IDE. In the case
> of AJAX this is the unruly but rapidly improving open-source
> frameworks (RICO, DOJO, MOCHI, et al), and the more mature
> but proprietary commercial frameworks (hi Jep!).
>
> As application developers, we live in the world of (2). We
> install the IDEs and learn the APIs, and improvements in
> these make our lives dramatically easier over time. But (1)
> is where the longer-lasting constraints are. (2) gets rapidly
> better over time, while (1) has a potentially greater impact
> on the core nature of the application.
>
> For example, FLEX 2 may (hypothetically) bring rapid
> application development nirvana. But if the Flash plugin is a
> weak way to display or work with text, FLEX 2 won't change
> that. If browsers don't provide a javascript API that gives
> native access to client microphones and webcams, that's also
> unlikely to change in the next several years.
>
> I'm more interested in (1) than (2), because I think it forms
> the basis for decisions that will hold up over time.
> -Jon
>
> At 12:20 PM 11/18/2005, David Mendels wrote:
> >  Hi All,
> >
> >Interesting thread.  I am from Macromedia and certainly
> biased, but I
> >do think there are strengths for each and I'll try to write some
> >relatively balanced notes:
> >
> >I think the discussion is a bit awkward however because we are
> >comparing apples and oranges in many cases.  Some people discussing
> >Flash really are talking about the Flash of 1-2 to 5 years ago,
> >pre-Flex and certainly pre Flash Player 8.5.  As for AJAX, are we
> >basing the discussion on the "roll your own" case, or on some of the
> >frameworks/tools that are available, or on a specific tool/framework
> >such as Tibco GI or Backbase?  The pros and cons differ greatly
> >depending on which of these you are comparing to which.
> >
> >Trying to parse this out a bit, some high level pros and cons that
> >aren't dependent on which version, tool or framework you are using:
> >
> >Flash is better at handling rich media, audio, video,
> graphic effects,
> >transitions, motion graphics, data visualization.  It is
> also better at
> >handling binary data streams, two way audio and video. It has much
> >richer capabilities for local data storage. In general, it
> excels are
> >creating an integrated media "experience" that is highly branded. It
> >excels at creating cross-browser applications that runs identically
> >across OS/Browser. In Player 8.5, it has a faster, more
> robust and more
> >advanced javascript engine (ECMA-Script) than any browser today with
> >better XML handling (E4X) which consistancy across
> browsers/platforms.
> >Flash is better for applications that need to received
> "pushed" data as
> >well as offline and occasionally connected use cases.  Flash
> has higher
> >quality and richer printing capabilities (though historically
> >developers have not taken enough advantage of this.)
> >
> >Ajax/DHTML is better for adding incremental functionality to an
> >existing HTML/DHTML page. Eg. If you have a page with a search box,
> >adding "google suggest" style intelligence to that search
> field.  This
> >can be done in Flash, but it is easier to add it incrementally to
> >existing pages/apps with AJAX/DHTML.  I have to say I think
> that is the
> >biggest single advantage because it lets people adopt AJAX
> more gradually.
> >HTML/DHTML have in some ways richer text layout capabilities
> than the
> >Flash Player for flowed text, large blocks of text, text with inline
> >graphics. (Flash Player has stonger support for non system
> fonts, font
> >anti-aliasing, text effects, text on a path).
> >
> >Neither one inherently loads faster than the other--that
> depends on the
> >app and the design. Neither one appears to be generally more
> performant
> >than the other--this also is highly dependent on the app and the
> >design--there are clearly cases where one is much better
> than the other.
> >It is important not to ascribe design choices to the underlying
> >technology.  For example, Google Maps (AJAX) load a bit faster than
> >Yahoo Maps (Flex/Flash).  However Yahoo maps has significantly more
> >functionality in the client.  That was a design choice--as a
> user, you
> >can decide which you like better, but it doesn't in and of
> itself tell
> >you if AJAX loads faster than Flash.
> >
> >As for accessibility, HTML has advantages for simple use cases,
> >Flash/Flex appears to have the edge for complex applications.
> >
> >As for back end integration, Flash/Flex provides many more options:
> >Remote Object invocation, Messaging, Binary Sockets, etc.
> >
> >As for skinning and styling, I think that this has historically been
> >harder in Flash, but with Flex 2.0 it is now easier and more
> flexbile
> >than any specific AJAX approach I have seen. Both have good
> support for
> >CSS.
> >
> >As far as standards support and openness, I think
> counter-intuitively
> >Flash now has an equal story with better support for the recent ECMA
> >Script standard, E4X, CSS support, XML/SOAP/WSDL support, and a
> >published and widely implemented fileformat and much much wider OS
> >support (including game machines, cell phones, cameras, MP3 devices,
> >etc). AJAX/DHTML of course has better support for HTML
> itself, but has
> >to wrestle with different implementations in different
> >browsers/platforms.
> >
> >As for developer productivity and maintainability, the "roll
> your own"
> >approach with both Flash and AJAX/DHTML tends to be hard to
> maintain in
> >both cases and developer productivity varies greatly with the very
> >specific experience of the developer.  At the moment, I believe the
> >Flex offers an order of magnitude advantage in developer
> productivity,
> >maintainability, extensibility for complex applications.
> Talking with
> >developers of large and complex applications (eg. A mortgage loan
> >application with over 1M lines of code, or a insurance company agent
> >broker application with a 30 person 12-18 month development
> cycle) the
> >advantages of Flex and Flash increase dramatically over AJAX/DHTML.
> >Testing costs are generally also lower because of better
> cross browser
> >compatibility. That said, at this point the fair comparison
> is not Flex
> >2.0 vs "roll your own" AJAX/DHTML, but with toolkits such as
> Tibco GI,
> >Backbase or OpenRico.org.  Each one of those would require
> some depth
> >of knowledge to do a fair competitive review and I can't do
> that, but I
> >think as this discussion continues it is important to
> compare apples to
> >apples. One should compare upfront cost, TCO, tooling,
> framework, etc
> >etc etc.
> >
> >Regards,
> >
> >David
> >Macromedia
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
> ----^-------^------^--------^-------^
> Jon Boutelle
> Principal, Uzanto Consulting
> Mountain View, CA
>
> Office Phone:650-564-0000
> Cell Phone   :510-708-9825
> skype id: jboutelle
> www.uzanto.com
> www.jonathanboutelle.com
> ----^-------^------^--------^-------^
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> Get fast access to your favorite
> Yahoo! Groups. Make Yahoo! your home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/spZplB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

David,

I agree that this conversation ends up having "apples to oranges" problems.

There are at least two dimensions to the decision:

1)The underlying capabilities of the client-side enabling technology.
In the case of Flash, this is whatever version of the Flash plugin is
currently at 50%+ adoption. In the case of AJAX, this is the DOM, and
javascript objects, and html rendering capabilities supported by the
major browser vendors.

2)The engineering framework used to build software that uses this
client-side technology. In the case of Flash, this is FLEX 2 and the
latest version of the Flash IDE. In the case of AJAX this is the
unruly but rapidly improving open-source frameworks (RICO, DOJO,
MOCHI, et al), and the more mature but proprietary commercial
frameworks (hi Jep!).

As application developers, we live in the world of (2). We install
the IDEs and learn the APIs, and improvements in these make our lives
dramatically easier over time. But (1) is where the longer-lasting
constraints are. (2) gets rapidly better over time, while (1) has a
potentially greater impact on the core nature of the application.

For example, FLEX 2 may (hypothetically) bring rapid application
development nirvana. But if the Flash plugin is a weak way to display
or work with text, FLEX 2 won't change that. If browsers don't
provide a javascript API that gives native access to client
microphones and webcams, that's also unlikely to change in the next
several years.

I'm more interested in (1) than (2), because I think it forms the
basis for decisions that will hold up over time.
-Jon

At 12:20 PM 11/18/2005, David Mendels wrote:
>  Hi All,
>
>Interesting thread.  I am from Macromedia and certainly biased, but I do
>think there are strengths for each and I'll try to write some relatively
>balanced notes:
>
>I think the discussion is a bit awkward however because we are comparing
>apples and oranges in many cases.  Some people discussing Flash really
>are talking about the Flash of 1-2 to 5 years ago, pre-Flex and
>certainly pre Flash Player 8.5.  As for AJAX, are we basing the
>discussion on the "roll your own" case, or on some of the
>frameworks/tools that are available, or on a specific tool/framework
>such as Tibco GI or Backbase?  The pros and cons differ greatly
>depending on which of these you are comparing to which.
>
>Trying to parse this out a bit, some high level pros and cons that
>aren't dependent on which version, tool or framework you are using:
>
>Flash is better at handling rich media, audio, video, graphic effects,
>transitions, motion graphics, data visualization.  It is also better at
>handling binary data streams, two way audio and video. It has much
>richer capabilities for local data storage. In general, it excels are
>creating an integrated media "experience" that is highly branded. It
>excels at creating cross-browser applications that runs identically
>across OS/Browser. In Player 8.5, it has a faster, more robust and more
>advanced javascript engine (ECMA-Script) than any browser today with
>better XML handling (E4X) which consistancy across browsers/platforms.
>Flash is better for applications that need to received "pushed" data as
>well as offline and occasionally connected use cases.  Flash has higher
>quality and richer printing capabilities (though historically developers
>have not taken enough advantage of this.)
>
>Ajax/DHTML is better for adding incremental functionality to an existing
>HTML/DHTML page. Eg. If you have a page with a search box, adding
>"google suggest" style intelligence to that search field.  This can be
>done in Flash, but it is easier to add it incrementally to existing
>pages/apps with AJAX/DHTML.  I have to say I think that is the biggest
>single advantage because it lets people adopt AJAX more gradually.
>HTML/DHTML have in some ways richer text layout capabilities than the
>Flash Player for flowed text, large blocks of text, text with inline
>graphics. (Flash Player has stonger support for non system fonts, font
>anti-aliasing, text effects, text on a path).
>
>Neither one inherently loads faster than the other--that depends on the
>app and the design. Neither one appears to be generally more performant
>than the other--this also is highly dependent on the app and the
>design--there are clearly cases where one is much better than the other.
>It is important not to ascribe design choices to the underlying
>technology.  For example, Google Maps (AJAX) load a bit faster than
>Yahoo Maps (Flex/Flash).  However Yahoo maps has significantly more
>functionality in the client.  That was a design choice--as a user, you
>can decide which you like better, but it doesn't in and of itself tell
>you if AJAX loads faster than Flash.
>
>As for accessibility, HTML has advantages for simple use cases,
>Flash/Flex appears to have the edge for complex applications.
>
>As for back end integration, Flash/Flex provides many more options:
>Remote Object invocation, Messaging, Binary Sockets, etc.
>
>As for skinning and styling, I think that this has historically been
>harder in Flash, but with Flex 2.0 it is now easier and more flexbile
>than any specific AJAX approach I have seen. Both have good support for
>CSS.
>
>As far as standards support and openness, I think counter-intuitively
>Flash now has an equal story with better support for the recent ECMA
>Script standard, E4X, CSS support, XML/SOAP/WSDL support, and a
>published and widely implemented fileformat and much much wider OS
>support (including game machines, cell phones, cameras, MP3 devices,
>etc). AJAX/DHTML of course has better support for HTML itself, but has
>to wrestle with different implementations in different
>browsers/platforms.
>
>As for developer productivity and maintainability, the "roll your own"
>approach with both Flash and AJAX/DHTML tends to be hard to maintain in
>both cases and developer productivity varies greatly with the very
>specific experience of the developer.  At the moment, I believe the Flex
>offers an order of magnitude advantage in developer productivity,
>maintainability, extensibility for complex applications.  Talking with
>developers of large and complex applications (eg. A mortgage loan
>application with over 1M lines of code, or a insurance company agent
>broker application with a 30 person 12-18 month development cycle) the
>advantages of Flex and Flash increase dramatically over AJAX/DHTML.
>Testing costs are generally also lower because of better cross browser
>compatibility. That said, at this point the fair comparison is not Flex
>2.0 vs "roll your own" AJAX/DHTML, but with toolkits such as Tibco GI,
>Backbase or OpenRico.org.  Each one of those would require some depth of
>knowledge to do a fair competitive review and I can't do that, but I
>think as this discussion continues it is important to compare apples to
>apples. One should compare upfront cost, TCO, tooling, framework, etc
>etc etc.
>
>Regards,
>
>David
>Macromedia
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

Hi All,

Interesting thread.  I am from Macromedia and certainly biased, but I do
think there are strengths for each and I'll try to write some relatively
balanced notes:

I think the discussion is a bit awkward however because we are comparing
apples and oranges in many cases.  Some people discussing Flash really
are talking about the Flash of 1-2 to 5 years ago, pre-Flex and
certainly pre Flash Player 8.5.  As for AJAX, are we basing the
discussion on the "roll your own" case, or on some of the
frameworks/tools that are available, or on a specific tool/framework
such as Tibco GI or Backbase?  The pros and cons differ greatly
depending on which of these you are comparing to which.

Trying to parse this out a bit, some high level pros and cons that
aren't dependent on which version, tool or framework you are using:

Flash is better at handling rich media, audio, video, graphic effects,
transitions, motion graphics, data visualization.  It is also better at
handling binary data streams, two way audio and video. It has much
richer capabilities for local data storage. In general, it excels are
creating an integrated media "experience" that is highly branded. It
excels at creating cross-browser applications that runs identically
across OS/Browser. In Player 8.5, it has a faster, more robust and more
advanced javascript engine (ECMA-Script) than any browser today with
better XML handling (E4X) which consistancy across browsers/platforms.
Flash is better for applications that need to received "pushed" data as
well as offline and occasionally connected use cases.  Flash has higher
quality and richer printing capabilities (though historically developers
have not taken enough advantage of this.)

Ajax/DHTML is better for adding incremental functionality to an existing
HTML/DHTML page. Eg. If you have a page with a search box, adding
"google suggest" style intelligence to that search field.  This can be
done in Flash, but it is easier to add it incrementally to existing
pages/apps with AJAX/DHTML.  I have to say I think that is the biggest
single advantage because it lets people adopt AJAX more gradually.
HTML/DHTML have in some ways richer text layout capabilities than the
Flash Player for flowed text, large blocks of text, text with inline
graphics. (Flash Player has stonger support for non system fonts, font
anti-aliasing, text effects, text on a path).

Neither one inherently loads faster than the other--that depends on the
app and the design. Neither one appears to be generally more performant
than the other--this also is highly dependent on the app and the
design--there are clearly cases where one is much better than the other.
It is important not to ascribe design choices to the underlying
technology.  For example, Google Maps (AJAX) load a bit faster than
Yahoo Maps (Flex/Flash).  However Yahoo maps has significantly more
functionality in the client.  That was a design choice--as a user, you
can decide which you like better, but it doesn't in and of itself tell
you if AJAX loads faster than Flash.

As for accessibility, HTML has advantages for simple use cases,
Flash/Flex appears to have the edge for complex applications.

As for back end integration, Flash/Flex provides many more options:
Remote Object invocation, Messaging, Binary Sockets, etc.

As for skinning and styling, I think that this has historically been
harder in Flash, but with Flex 2.0 it is now easier and more flexbile
than any specific AJAX approach I have seen. Both have good support for
CSS.

As far as standards support and openness, I think counter-intuitively
Flash now has an equal story with better support for the recent ECMA
Script standard, E4X, CSS support, XML/SOAP/WSDL support, and a
published and widely implemented fileformat and much much wider OS
support (including game machines, cell phones, cameras, MP3 devices,
etc). AJAX/DHTML of course has better support for HTML itself, but has
to wrestle with different implementations in different
browsers/platforms.

As for developer productivity and maintainability, the "roll your own"
approach with both Flash and AJAX/DHTML tends to be hard to maintain in
both cases and developer productivity varies greatly with the very
specific experience of the developer.  At the moment, I believe the Flex
offers an order of magnitude advantage in developer productivity,
maintainability, extensibility for complex applications.  Talking with
developers of large and complex applications (eg. A mortgage loan
application with over 1M lines of code, or a insurance company agent
broker application with a 30 person 12-18 month development cycle) the
advantages of Flex and Flash increase dramatically over AJAX/DHTML.
Testing costs are generally also lower because of better cross browser
compatibility. That said, at this point the fair comparison is not Flex
2.0 vs "roll your own" AJAX/DHTML, but with toolkits such as Tibco GI,
Backbase or OpenRico.org.  Each one of those would require some depth of
knowledge to do a fair competitive review and I can't do that, but I
think as this discussion continues it is important to compare apples to
apples. One should compare upfront cost, TCO, tooling, framework, etc
etc etc.

Regards,

David
Macromedia

I haven't heard of anything. Has anybody else?

In general, open source is better for infrastructure (libraries,
APIs, frameworks) than for applications (like IDEs). So if you're
looking for a true rapid application development environment (like
Java Studio Creator), my gut feel is you'd have to go with a
proprietary vendor.

A nice wrap-up of current AJAX toolkits can be found here:
http://edevil.wordpress.com/2005/11/14/javascript-libraries-roundup/
and I've been doing my own bookmarking of anything I come across
http://del.icio.us/jboutelle/ajax_toolkit

Regards,
-Jon


At 04:34 AM 11/18/2005, niksa_os wrote:
>Hi.
>
>Can you tell me where I can find free/open source AJAX framework/tool which
>support d&d GUI building of user interfaces?
>Like Java Studio Creator do for JSF.
>
>Thanks.
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

Hi.

Can you tell me where I can find free/open source AJAX framework/tool which
support d&d GUI building of user interfaces?
Like Java Studio Creator do for JSF.

Thanks.

Hi Jon,

I wrote an Ajax for designers paper that has a section about
"choosing" a technology for the front end. I don't consider rendering
engines b/c I'm purely concerned w/ the UX side of things. Anyway, you
can take a look at it by going to ...
http://synapticburn.com/comments.php?id=97_0_1_0_C

Enjoy!

-- dave

On 11/17/05, Jonathan Boutelle <jon@...> wrote:
>  Hey everybody!
>
>  I'm working on a white paper that looks at when to use Flash vs. when
>  to use AJAX.
>
>  I'd love to hear what people in this group have to say. I really
>  think it's possible to scope out situations where Flash is the only
>  viable option, and other situations where using Flash just doesn't
>  make any sense (and AJAX makes more sense). But I'm having trouble
>  articulating this.
>
>  Macromedia people: What's your take on this? What's the "sweet spot"
>  for Flash, and where does AJAX make more sense?
>
>  AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>  would you use Flash instead?
>
>  Few people are equally proficient in both technologies, and that
>  factors into the decision process as well. So for the purposes of the
>  question, imagine you're the manager of a crew that is good with both
>  technologies.
>
>  I have my own ideas as well, but I don't want to shape this
>  discussion at the outset. Once we get the ball rolling I'll surely
>  chime in. ;->
>
>  ----^-------^------^--------^-------^
>  Jon Boutelle
>  Principal, Uzanto Consulting
>  Mountain View, CA
>
>  Office Phone:650-564-0000
>  Cell Phone   :510-708-9825
>  skype id: jboutelle
>  www.uzanto.com
>  www.jonathanboutelle.com
>  ----^-------^------^--------^-------^
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "ajax_and_ria" on the web.
>
>  To unsubscribe from this group, send an email to:
>  ajax_and_ria-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>


--
David Heller
E: dheller (at) gmail (dot) com
W: www (dot) synapticburn (dot) com

--- In ajax_and_ria@yahoogroups.com, "Jep Castelein" <jep@b...> wrote:
>
> Hi all,
>
> Just a short message to put some more emphasis on AJAX :-)
>
> I believe that everything that Flex can do, can also be done by
mature AJAX
> toolkits. Both provide much higher developer productivity than
custom AJAX
> projects, and I feel that custom AJAX will become less important in
the next
> couple of months. There are so many affordable AJAX toolkits
available, so
> why wouldn't you pick one?
>
> Then the question would be: is custom AJAX (or custom Flash) replaced by
> AJAX toolkits or by Flex? Or by something else?
>
> Whatever the outcome, I'd like to give some quick comments on the Flex
> strengths as mentioned by JesterXL.
>
> - form intensive applications
> Better with HTML: loads faster, runs faster, feels more familiar

Actually thats not entirely true. Perception maybe there provided you
are using it in a linear fashion. DOM by nature is memory intensive,
and with Poor Garbagse Collection in place, its even worse (i.e
Internet Explorer). If you were to scale outward havd 100's of forms
loading / unloading within an application on a daily basis, DOM fails
and has failed time and time again. I've seen the browsers lockup on
KIOSK ware applications that have used "AJAX" approach (Kiosk being
touch screen no chance of close/re-open browers).

This is but a small illustration of how DOM can be intensive depending
on its use and context. Equally as such is FLASH, even more so with
the introduction of assets can be done marginaly faster with new
features in 8.5 such as DisplayLists, where we can re-parent objects
in a seamless fashion that maintains state. All pre-rolled no work
required.

> - integrating many back-end, non-changeable systems
> Don't think this is related to front-end RIA technology: AJAX or
Flash based
> systems should be able to do this equally well

Equally? i think not. Can AJAX compress the packets of data between
client-side and server-side in say Binary? and deserialize this data
auto-magically? That being said, you will always need a buffer between
your disparate system such as "Coldfusion" in order to make the two
pieces sing in the same tune.

> - web service realization
> See previous point

Again, Both can achieve the same result further more using XMLSocket
servers you can tap into SOAP calls, serialize them to binary and then
send them back to Flash (ie mobile devices need this more so then
anything else).

> - drag and drop
> That's really basic functionality in any AJAX engine

Ok, drag and drop in DOM is basically a "hope and prayer". When
implementing drag and drop, you're basically hijacking the "select"
capabilities of a browser and forcing it to "cool off until i need you
next". Drag And Drop can be (when done properly) nice, but its still
cumbersome and you still have limitations imposed. Not only that, you
can only selectievly drag/drop pieces of the DOM puzzle, FLASH has a
more of "go mad" mentality (ie you also have the added annoyance of
SELECT boxes taking depth priority)..

> - branding
> I don't see why Flex is better for branding than HTML. And even if you'd
> like to have animations or specific fonts, you can still embed Flash
movies
> in AJAX sites.

Like wise you can have AJAX embedded within FLEX applications, the two
can easily grow old together, just the AJAX part of the equation
hinders future expansion on say FLEX...more importantly, DESKTOP
conversion of your application from a FLEX to .EXE for example is
easily done (great for occasionally connected clients). If you build
to much dependency on AJAX in this equation, you have to also embed a
browser into the mix of some sort.

> - Give Java developers a client that doesn't suck
> JSF, anyone? And that's an open standard

Give Java Developers rich media exposure, and that too can become an
open standard. I'm not sure anyone has picked up on this as yet, but
when you look at Flex Builder 2, and notice that you can drag and drop
form widgets into the WYSIWYG editor, what is happening here? we are
dragging Java UI into FLASH Player... again, where does Java SWING
play a role now? can AJAX portion of the equation do this? Can you
realistically make a wrapper that embeds DOM into its inner children,
and then interact with it?...ActiveX yes? but thats the point
overall.. AJAX = DOM thats the core component.

> - intranet portals
> Don't see why Flex would do this better than AJAX

VOIP, 2D Rendering, Fluid Effects, More stable control over key/mouse
management, total control over memory utilisation, dynamic loading of
third party entities using things such as RunTime shared libraries,
which do not require additional bandwidth, preloading of data with
prediction algorithiums *already* in place...list could go on.. if you
are going to build an intranet, that is to emulate desktop experience,
do so in  a manner that is effecient and can scale outward. AJAX
taking on say ORACLE FORMS is umm.. would be humilating.

FLEX has the power of taking on board MDI/SDI capabilities, AJAX still
relies on the browser of choice to uphold this. (Seperate threading is
an enormous amount of power).

> - skinnable interfaces
> I feel this was extremely weak in Flex 1.0, slightly better in Flex
1.5, but
> still not on par with the skinnability of HTML. I don't know Flex 2.0 in
> this respect though.

FLEX skinning isn't hard, its totally easily once you know how. I
think the myth behind skinning in general has more to do with the
skinner then anything else. Typically everyones would really prefer to
punch open a photoshop template, design the UI and then save and it
magically disects into a SKIN... won't happen for a bit longer yet.

AJAX is actually just as hard to skin then any other technology, trust
me as i've pushed FLEX to the extreme in terms of skinning.

>
> Cheers,
> Jep
>
>
>
> ________________________________
>
>  From: ajax_and_ria@yahoogroups.com
> [mailto:ajax_and_ria@yahoogroups.com] On Behalf Of JesterXL
>  Sent: 17 November 2005 21:35
>  To: ajax_and_ria@yahoogroups.com
>  Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>  I know a Flex dev from Oz who knows both (Scott Barnes), so
> hopefully he can
>  give a unique, albiet passionate response when he joins this
> discussion
>  later.
>
>  In the iterim, what is and isn't.
>
>  Contents:
>  - What Flex is for
>  - What Flex isn't for
>  - What Flash is for
>  - What Flash isn't for
>  - AJAX for the rest
>  - Flex for JSP developers
>  - Laszlo bashing
>
>
>  What is for Flex:
>  -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>  - form intensive applications.  MoveableType/WordPress' (common
> blogging
>  tools) administration, for example.  While most blogs are best
> servered as
>  HTML, the intensive server interaction as well as content updating,
> and the
>  plethora of forms would be easily done in Flex.  This assumes,
> however, the
>  server is setup as an nTier system vs. old skool programming.  For
> example,
>  a lot of PHP & Perl web apps for example utilize Perl & HTML in the
> same
>  code block.  Sometimes they post to themselves.  Classes, OOP, and
> other
>  software concepts are thrown out the window.  They can be used,
> however, if
>  they are used to be posted to (GET/POST).
>
>  - integrating many back-end, non-changeable systems.  Examples are
> large
>  Enterprise applications that have a plethora of services from a
> wide-range
>  of teams, the majority written in some form of Java.  Equipping a
> team of
>  JSP programmers with Flex, creating hundreds of forms that are
> bindable to
>  the back-end, and replacing the non-stateful JSP's with a stateful
> Flex
>  client empowers a lot of powerful simplification.  Instead of
> various JSP,
>  HTML, DHTML, applets, and other various client implementations, you
> can
>  somewhat standardize the client tier to use Flex, but still keep the
> same
>  back-end services, with or without re-factoring them to expose
> certian
>  methods.  With Remoting (binary vs. XML string), this will decrease
> the
>  overall bandwidth.
>
>  - web service realization.  Just about any webservice out there begs
> to be
>  used by Flex.  The SOA revolution has the most impeccable timing
> since Flex
>  can utilize WebServices just as easily as back-end Java, .NET,
> ColdFusion,
>  and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo!
> ecspecially all
>  have wonderful API's that work extremely well with visualization
> ideas
>  realized in Flex & Flash hybrids.  While Flex is built on the Flash
> Player,
>  Flash would allow you really eximply the creative, and more
> intuitive &
>  responsive ways to show a plethora of data, while Flex makes it
> really easy
>  to speak to the server in a natural, programmatic way.  Granted, you
> put
>  together some really intuitive & dynamic interfaces in Flex, but my
> money is
>  on getting a talented team of designers & infromation architectects,
>
>  implementing some design elements in Flash, and authoring it all in
> Flex.
>
>  Yahoo! Maps for example.  Not only well executed, but developers &
> designers
>  can join in on the fun!
>
>  - niche internet connected components.  Not sure what blog coined
> that
>  phrase, but basically, some things are more approrpriate in HTML for
>
>  skilllset reasons, legacy software, or for time constraints.  As
> such,
>  because Flex is just a SWF, and can be treated as an embedable
> object, it
>  serves well for smaller, niche purposes as well by being integrated
> into
>  larger systems.  Example is MXNA's (Macromedia's blog aggregator)
> where they
>  show your post popularity with an extremely interactive graph.
>
>
>
http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&f
> eedName=jester%20%28jessewarden%2Ecom%29
>
>  Since drag and drop is easy in Flash, I developed a question builder
> for an
>  existing CMS built in HTML & .NET; it integrated nicely, and we
> spoke via
>  POSTS to .NET.  Pretty simple concept, and saved them tons of time
>  developing drag and drop in HTML, and the user ended up winning.
>
>  Some of the real-time polls done in Flex & Flash are various
> Macromedia
>  employee & ColdFusion weblogs are pretty schweet too.
>
>  - branding.  While arguably esoteric, and subjective, I strongly
> beleive
>  bringing a company's brand to a user's client, OR retaining it on a
> company
>  intranet, can best be done using Flex and Flash together.
> Ironically, the
>  downfall of Macromedia's Desktop forray, Central, was because they
>  themselves, Macromedia, impressed their brand onto people looking to
>
>  represent their companies.  Unfortunately, Macromedia won, and
> Central died
>  because of it.  USA Today had a pretty neat forray, but an EXTREMELY
> niche
>  case.
>
>  Bottom line, while I've seen some very impressive HTML designs, I
> still
>  believe if you want to shove a brand, in all it's accuracy, in a
> consumer's
>  face, Flex & Flash is the way to go.  Reason being, Sparkle isn't
> out yet,
>  hehe!  While PC games prove one can create beautiful client
> interfaces, they
>  don't run in the browser, and while Flash Player and XMLHttpRequest
> are both
>  ActiveX controls, both have extremely high-install penetration
> ratios, so
>  ensuring a client's brand can be seen is a lot.  People argue this
> could
>  comprimise usability when a brand's agenda gets in the way, and I'm
> not here
>  to argue that, but I do question if you are here to make money, or
> are on
>  some crusade to spread good practices.  Me?  To make a living.
>
>  - Give Java developers a client that doesn't suck.  JSP developers
> now have
>  a familiar paradigm of development with a client that looks awesome
> with
>  little design investment.  Oh yeah, did we mention it's stateful?
>
>  - intranet portals.  This one is weird; mainly in that I never
> thought to
>  use the technology this way, and curse myself for the lack of
> foresight.
>  There are a lot of intranet applications that have millions of
> dollars
>  pumped into them to ensure they are made, even if they are never
> used.
>  Regardless of their nebolous outcomes, the bottom line is, that
> money pie
>  can be shared if you pitch yourself right.  As such, HR Portals, and
> other
>  departmental information tools work very well in Flex.  I've
> seen/heard of
>  some developing projects where either existing portals are to be
> converted
>  or switched over.  While I'd actually argue for AJAX here, SOME have
> just
>  enough CRUD opertaions of admins needing to see and update data,
> that I
>  could see Flex working great.
>
>  - skinnable interfaces.  While both Flash & Flex can do this, and I
> think
>  it's a stupid feature that is the 20% of the 80/20 rule, it can be
> done, and
>  helps sell applications, even if it's a pointless endeavor.
>
>  - SAP now has Flex embedded.  All the insanely large apps written
> with SAP
>  now have an awesome potential front-end.
>
>  What isn't for Flex:
>  -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>  - eLearning.  While I've recently seen a pretty thoroughly
> developed, and
>  large in scope Flex site that had serious amounts of eLearning, I
> really
>  didn't see the point of Flex other than "developers don't know
> Captivate,
>  Flash, Camtasia, nor care too and want to deploy on the server."
> Um, ok.
>
>  - CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs
> are
>  better done with Director or Flash; Flex, at least in 1.5, has a
> server
>  requirement, and most of those projects do not have the scope of
> code that
>  most Flex projects do.  Additionally, the level of design control &
> branding
>  on those projects is heavyily in need of a tool like Flash with it's
> design
>  power (intergrating designs, video, and other various multimedia).
> While
>  Flex can use said content, it can't easily create & control it
> during
>  authorign like Director & Flash can.  Director also supports older
> systems
>  with less system resources, as well as more capability to support
> thousands
>  of design assets both at authortime and runtime without crashing
> your
>  system.  Flash & Flex do not really have asset memory management at
> runtime,
>  and Director does.
>
>  Flex 1.5 suffers from a liencesing issue where most occasionally
> connected
>  clients don't work; you need a server for Flex, and while Central
> kind of
>  counts, no one develops for Central.  While Flex on the desktop has
> promise
>  in 2:
>  http://dev.jessewarden.com/captivate/flexonthedesktop/
>
>  ... it just doesn't have the API for it either without a 3rd party
>  application to wrap the SWF & EXE.
>
>  Mobile devices, even with the advent of Flash Player 7 'esque for
> Deuce
>  (Flash Lite 2), don't really fit the Flex model.  Meaning the Flex
> framework
>  wasn't designed to run on a mobile device, whereas Flash the IDE and
> Flash
>  Lite the runtime were.  Someday...... but not today or tomorrow.
>
>  - websites.  I've seen 2 websites done in Flex that made no sense at
> all for
>  technology.  The defense was that the large, non-publicly facing CMS
> that
>  ran it was in Flex, but to me that's a pathetic excuse.  This is
> where
>  giving Java developers a client that doesn't suck backfires.
>
>  If HTML, or even AJAX is appropriate, cool, but don't use web
> application
>  software to create a web site.
>
>  - games.  One could argue that many games are easy to create in
> Flex.  While
>  I would agree, most games that actually sell are done in Flash or
> Java.
>
>  What is for Flash:
>  -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>  - games, ecspecially with Flash Player 8 and 8.5 since they both
> have
>  blitting support, you can use double-buffering to get some seriously
> well
>  performing games.  Java used to win in this arena, but not anymore.
> It goes
>  without saying that Flash allows you to create anything the crazy
> design
>  team comes up with and can look and work however you want.
> Supporting
>  sound, video, and other effects most gamers are used to, the world
> is your
>  oyester now.
>
>  - CD-ROMs.  While Director still contents highly in this sphere,
> Flash
>  allows teams of designers to work together more easily with
> authorers than
>  Director did.  With improved video support, Flash is overtaking this
>
>  market... at least, all the CD-ROM's I've seen.
>
>  - Occasionally Connected Clients.  More so, it's best when wrapped
> in a 3rd
>  party projector, custom C wrapper, or something that gives it more
> access to
>  the local OS.  While Flash itself can easily talk asyncronously to
> any
>  back-end system, it's security model is for the web, not for the
> desktop, so
>  you need something to help those weaknesses.  Since Flash is
> stateful, it's
>  really easy to save local data, and connect to the web and update
> data when
>  you have a connection.  This is why a lot are seeing success with
> mobile
>  development in Japan and other parts of Asia.
>
>  - level branding control that Flex & HTML can't do
>
>  - sound control; you already knew that!
>
>  - Collaborative Applications.  Until Flex Enterprise Services show
> us what
>  they are, if you need video chat, audio chat, text chat, and/or
> multiplay
>  games, Flash using XMLSocket, Flash Communication Server, or the new
> binary
>  sockets in Flash Player 8.5, this is the way to go.
>
>  - like Flex, drag and drop on the web.  I've seen some impressive
> stuff with
>  DHTML, but more with Flash.  I think the Flex developers forget it's
> there
>  or don't know how to use the API... or just don't know what to do
> with drag
>  and drop now that they have it.
>
>  - eLearning.  While Captivate holds it's own, I still think all the
> custom
>  solutions I've written in Flash are better for solve "service
> needs".
>
>  - video on the web.  This goes with branding, but you now suddenly
> have a
>  player that's at 90% penetration, linux included (Flash Player 7)...
> and it
>  doesn't have to be a frikin' square on the page or in a new window,
> nor come
>  with pre-fabbed radio buttons to "select your bandwidth".
>
>  - writing extensions for Breeze.  This was talked about, but never
> really
>  elaborated upon by Peldi, nor Nigel.  Basically, it seems you can
> write your
>  own Pods for Breeze, but not really sure where this stands.
>
>  - fighting blogspam.  I implemented a Flash comment form on my site.
> Since
>  blog spamming is typically done with bots, they merely post the
> required
>  form variables to the the server-side script, bypassing the web
> form.
>  Captcha, however, stops them dead in their tracks. My Perl Captcha
> plugin
>  for MoveableType however didn't install correctly... 300 comments an
> hour
>  with my webhost calling my cell on what CGI file to rename.  I
> merely made a
>  hidden field in Flash (like a hidden field in HTML).  Since spambots
> don't
>  know how to screen scrape the internals of a SWF, they failed to
> post the
>  correct hidden form variable that the SWF has hardcoded internally.
> Been
>  blogpsam free from bots for over a year now, since they day I
> implemented
>  it.
>
>  What isn't for Flash:
>  -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>  - web sites.  While clients to this day still pay for it, it's
> ridicolous,
>  and kills usability.  Contrary to popular beleif, there are a
> multitude of
>  ways to get Flash sites into search engines, but unless it's for
> movie
>  sites, or artists showing portfolios, I've yet to see a good use
> case beyond
>  those 2.  Flash elements?  Sure, but only for video, or interactive
> product
>  demos.  Navigation, blocks of text, and other navigational aides,
> ...nope.
>
>  - targetting older systems.  Director owns here, specially with
> Flash Player
>  8 not supporting older OS's, and STILL not supporting a Linux
> version.
>
>  - web widgets.  While I've seen some pretty neat use of web widgets,
> like
>  the polls I've mentioned earlier, some are just too simple to
> justify.
>  Like, a mini-blog reader is neat... but why not use AJAX instead?
> The line
>  gets REALLY fine here, but I usuallly know in my gut what is and
> isn't
>  appropriate.  Some designs lend themselves to just using DHML, while
> others
>  couldn't be done without Flash.  The majority I've seen, however,
> are more
>  appropriate in DHTML or a server-side HTML rendered way.
>
>  - Enterprise applications.  Can it be done?  Sure, but after you've
>  developed in Flash for awhile, and then started to develop in Flex,
> it all
>  becomes clear.  The weeeks spent writing just GUI code turns into
> days.
>  Not to mention the fact, the components in Flex are more mature.
> ASCII MXML
>  files work better in version control than binary FLA's do.  You
> can't diff a
>  FLA accurately; what's the point?  You thus poison builds early on
> by FLA
>  changes, and sharing FLA's amongst developers sucks.  "Hey man, can
> I borrow
>  the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.
>
>  -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>  For everything else, I'd say AJAX.  Most of the so called "Web 2.0"
> sites
>  I've seen are really just extremely well designed and executed
> websites.
>  They are just updating parts of the sites that really don't require
> the
>  whole page to, like Google Adsense's login, or Flickr's picture
> comments.
>  To me, those are extremely awesome & needed uses of AJAX.  With
> HTML's
>  native text & hyperlinking abilities, it's really hard to lose.
>
>  It goes without saying that if your team is good at web skills, find
> a way
>  to make AJAX work unless you really are stretching; same goes with
> Flash &
>  Flex.  I would argue, however, JSP developers really should think
> about
>  investing some time learning Flex.
>
>  ...Laszlo... hrm... gonna be a technology bigot here.  While there
> are
>  exceptions to every stereotype, and Pandora.com really rocks as an
> app, and
>  is a great example of what Laszlo can do... screw Laszlo.  It's
> based on
>  older versions of the Flash Player, uses JavaScript which is a
> prototype
>  based language which doesn't compare to the class based, strong
> typing of
>  ActionScript 2 & 3 that developers respect & come to expect, and is
> based on
>  JGenerator, an antiquated server technology.  I've heard of niche
> casses for
>  it, like supported legacy apps that need to have lower versions of
> the Flash
>  Player because of red tape, but that's a cop-out.   Eeither you are
>  innovative or you aren't.  Either you're trying to push the evelope,
> or you
>  aren't.  Using Open Source as a selling point is lame.  You get what
> you pay
>  for.
>
>  Hope that gives you some info!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  ----- Original Message -----
>  From: "Jonathan Boutelle" <jon@u...>
>  To: <ajax_and_ria@yahoogroups.com>
>  Sent: Thursday, November 17, 2005 2:07 PM
>  Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>  Yes, for sure! Consider the possibility of using Flex 2 (or even
>  third-party frameworks like Laszlo).
>  -Jon
>
>  At 11:02 AM 11/17/2005, JesterXL wrote:
>  >Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted
> my
>  >career
>  >this year to focus on Flex more so than Flash development.
> Granted, I use
>  >both in tandem, but I think Flex is more appropriate for many
> applications
>  >previously used for Flash.
>  >
>  >----- Original Message -----
>  >From: "Jonathan Boutelle" <jon@u...>
>  >To: <ajax_and_ria@yahoogroups.com>
>  >Sent: Thursday, November 17, 2005 1:37 PM
>  >Subject: [ajax_and_ria] Flash / AJAX decision making
>  >
>  >
>  >Hey everybody!
>  >
>  >I'm working on a white paper that looks at when to use Flash vs.
> when
>  >to use AJAX.
>  >
>  >I'd love to hear what people in this group have to say. I really
>  >think it's possible to scope out situations where Flash is the only
>  >viable option, and other situations where using Flash just doesn't
>  >make any sense (and AJAX makes more sense). But I'm having trouble
>  >articulating this.
>  >
>  >Macromedia people: What's your take on this? What's the "sweet
> spot"
>  >for Flash, and where does AJAX make more sense?
>  >
>  >AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>  >would you use Flash instead?
>  >
>  >Few people are equally proficient in both technologies, and that
>  >factors into the decision process as well. So for the purposes of
> the
>  >question, imagine you're the manager of a crew that is good with
> both
>  >technologies.
>  >
>  >I have my own ideas as well, but I don't want to shape this
>  >discussion at the outset. Once we get the ball rolling I'll surely
>  >chime in. ;->
>  >
>  >----^-------^------^--------^-------^
>  >Jon Boutelle
>  >Principal, Uzanto Consulting
>  >Mountain View, CA
>  >
>  >Office Phone:650-564-0000
>  >Cell Phone   :510-708-9825
>  >skype id: jboutelle
>  >www.uzanto.com
>  >www.jonathanboutelle.com
>  >----^-------^------^--------^-------^
>  >
>  >
>  >
>  >
>  >
>  >Yahoo! Groups Links
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >Yahoo! Groups Links
>  >
>  >
>  >
>  >
>
>  ----^-------^------^--------^-------^
>  Jon Boutelle
>  Principal, Uzanto Consulting
>  Mountain View, CA
>
>  Office Phone:650-564-0000
>  Cell Phone   :510-708-9825
>  skype id: jboutelle
>  www.uzanto.com
>  www.jonathanboutelle.com
>  ----^-------^------^--------^-------^
>
>
>
>
>
>  Yahoo! Groups Links
>
>
>
>
>
>
>
> ________________________________
>
>  YAHOO! GROUPS LINKS
>
>
> 		 *  Visit your group "ajax_and_ria
> <http://groups.yahoo.com/group/ajax_and_ria> " on the web.
>
>  *  To unsubscribe from this group, send an email to:
> 		 ajax_and_ria-unsubscribe@yahoogroups.com
> <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>  *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/> .
>
>
> ________________________________
>

RE: initial load time.

Aye, but I'd argue each second I take from the user I am in turn giving them
exponentially more functionality.

RE: drag & drop

Gotcha.

Web Application & Web Site differences?  Dude, if I knew that, then we'd
have this Web 2.0 thing solved.
http://www.jessewarden.com/archives/2005/11/web_20_i_make_i.html

My blog = web site
My blog administration = web app

Really, the whole thing is run by MoveableType, but the site itself, to me,
is a website.  You go there to consume content.  Granted, Flash comments,
adsense, dynamically generated comments, a moving banner, embedded apps...
one could argue that the sum of it's parts really make it a web app, but I
disagree.  It's there for public consumption; the goal of the site is to
consume, to read.

The goal of the admin is to administer the site.  You don't do 1,
overarching task, you performane many different tasks in the same interface.
That to me is an app; an application hopefully allows you to do the 80% of
the things you want to do.

Slashdot & Digg get REALLY fuzzy, but I'd argue both are sites... until you
login.  Flickr?  A site... until you login; then it's both.

As a side effect, you ask me about a project, and if I would use HTML +
JavaScript + CSS vs. Flex, my answer would determine what I think is a
website vs. web app.  Granted, the former can be used to build web apps, but
that's not what I personally use to build web apps.

Technically, anything that has a lot of client server interaction.  My blog?
You post a comment, navigate to another page, or download a file.  Maybe
that was a web application 6 years ago, but it isn't now.

Text.

I think you are dead on with the text argument.  Flash does not make it
easy, not only to create text, but to display it.  You would think a vector
design tool would rival that of Illustrator... but nope, not by a long shot.
There is a reason my site is in HTML.  Not only that, but even though Flex
has greatly enabled dyanmic layout capabilities, there is a fundamental flaw
in thinking Flash could ever parlay with document browser that render HTML.
Look at FlashPaper for example.  They had to implement an entirely new class
in Flash Player 7 JUST TO ENABLE it.

Like, HTML text, when designed correctly, enables you to highlight it in
sections, or the whole thing.  Flash?  Nope... except for FlashPaper.  BUT,
it's slow as nuts in FlashPaper nor does it work right.  You have to, under
the hood, code your own selection mechnism, doing all the math on the fly in
a language that used to be slower than JavaScript.  Not only that.. but no
right click? WTF!?!

Yeah, I've seen a blog in Flash.  Mine was when left LiveJournal... and I
quickly changed it.  Even with RSS, people came for content, not just for
text pulled from an XML file.  Flash sux for displaying large amounts of
textual content that is living.  Like, doing layout in HTML, even with
tables, pee-tags, and breakz... works.  You can do it in Notepad,
Dreamweaver, etc.  HTML markup is ubiquitious in our world of text.  SWF
bytecode?  Uh... no.

Here's another one:
http://www.randomusa.com/flash/

Slow as nuts, text jammed in this box with weird use of negative space.
Drives me up the wall.  The importance of content has been lost to the
developers' desire to prove himself.  As a user, I want to read his content,
maybe his comments, and then his other entries.

Instead, he's forced me to seeing his LoadVars skill, his usage of
components, and random ability to resize... ugh.  If this were an email
client with threading support... ok... but, not a blog.  This is not how
people read content.

Hopefully I'm confirming your points here.

On the flipside, FlashPaper only stands to gain from Flash 8's new text
rendering engine; a non-editable (read-only) document that is portable,
launches faster than PDF, and is easily embedded into other things as well
as generated from a variety of programs (ColdFusion, Acrobat, Contribute,
Breeze, etc.).

Flash the IDE itself defaults text to embedded fonts, the worst possible
thing to do.  Does HTML?  No, from day 1 it respected font-famlies.  Flash?
Naw... it empowered designers to use their fonts, break them to vector
shapes to ensure users saw what they wanted them to see.  But at what cost?
Nothing to their work.

But to developers, we don't give a flip, we just want fast to render, low
resource using, easy to read device text.  Device text is there, but hard to
use.  It's not the default, explain "_sans" takes more than 2 setences, and
thankfully is the default in Flex.

Me?  I'll just ensure my buttons are easier to read when Flex 2 arrives.
... or just right click on my desktop, Properties > Appearnce tab, Effects
button, check smooth screen fonts, and click ok.

It took 7 versions to get a component that showed a scrollbar when there was
too much text in the field... you think everyone else is going to code that
themselves?  Nope... because they didn't... hindsight proves it.

Scaling text takes a lot of code.  HTML?  Uh.. dude, it already does that...
and doesn't spike my CPU either.

Tabbing, however, works in Flex thank God.

...unfortunately, they didn't make the default HTML focus the Flash ActiveX
control in the body tag's onLoad, thus a lot of applications that start with
a login require the user to have to click the field to give it focus, even
if the cursor's in there.  Annoying as hell, and not easy to modify the
default HTML Flex generates; I never use it even though by doing so, I lose
built-in HistoryManagement... catch 22.

So, in conclsion, yeah man, you make a good case against Flash/Flex on the
text route.  While I'd argue Flash 8's text rendering engine looks better
than PDF, creating anything on par with HTML's text rendering capabilities
will cause you to lose.  Inputting's a different story.


----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 7:32 PM
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


Wow, lots of ideas here. A couple of responses.

RE: initial load time. I have to say, html applications always feel a
little bit "snappier" to me in terms of initial load time. The only
apps where I've been able to actually notice the "streaming of the
javascript" effect, as a user, are the email clients (yahoo beta and gmail).

RE: drag & drop not being AJAX. The term AJAX is colloquially used to
refer to any javascripting that impacts the user experience by making
it more "application-like". Lets just agree to use it to mean that,
otherwise we'll get dragged down into a semantic debate.

I'm interested in what advocates of a platform concede it's not good
for. JesterXLs conceding that Flash/FLEX is bad for an intranet (and
for "web pages", however they are distinguished from "web
applications") is therefore interesting. What is it about "intranets"
and "web pages" that make them poor candidates for Flash/FLEX, Jesse?

My initial take is that flash is ROCKIN' for non-textual interfaces.
Video, audio, games, graphics, there's no way that AJAX can compete
there. Marketingware is a great example of this, but so is most
real-time collaboration software. I think Flash would be awesome for
a distributed CAD/CAM design system, just as an example.

On the flip side, I often find myself frustrated when I'm reading or
writing text in a Flash application. Flash doesn't meet my
expectations of being able to cut and paste the text (for example, to
bookmark it, note down a proper name or address, whatever). Flash
interfaces never seem to display the text in a big enough window for
reading (not sure why). Would you want to read a blog that was
implemented in Flash? I wouldn't. I wouldn't want to write a blog in
Flash either: most flash applications don't handle tabbing from field
to field well, I can't easily cut/copy/paste in Flash text fields, etc,etc.

So maybe one dimension that seems important (when making the
Flash/AJAX decision) is the text / non-text dimension. I fleshed that
idea out a little bit here:
http://www.jonathanboutelle.com/mt/archives/2005/11/flash_what_is_i.html

What are other (high-level) dimensions to consider, when making the
Flash/AJAX decision?
-Jon


At 01:29 PM 11/17/2005, you wrote:
>To respond to Jep; thanks for taking the time to read all of that Jep!
>
>- form intensive applications
>* Better with HTML: loads faster, runs faster, feels more familiar
>
>Loads faster?  Maybe.  Depends what assets in Flex are used, what bitmaps
>are used, etc. What do you define as fast?  HTML streams a heck of a lot
>better, I'll give you that.  But.. can you use it while streaming the
>JavaScript?  Also, once the SWF is cached, she no longer loads anything;
>just talks to the server.  And what are you getting with that load?  A
>branded customer experience or a "more dynamic webpage"?  Does it matter to
>the end user?  What about to those funding the project?
>
>Runs faster?  Huh?  My AMF binary is smaller than your XML strings.
>
>I will concur, however, that I could turn on my old p3, and I'd bet the
>AJAX
>apps are more responsive.  My Alienware doesn't really do justice to
>testing
>my content on low-end machines.
>
>Feels familiar?  I agree here.  We need more infromation architects to help
>us; while I disagree with making Flex UI components look like windows or
>mac
>native os widgets, some of the designs don't really accentuate common
>themes.  But then, how does one set oneself apart?  I agree, though, still
>on this fundamental point; Flickr's image editing tools are easy to get
>quickly whereas their Flash apps are a lot slower on the UI
>understanding...
>but then they do accomplish more.
>
>- integrating many back-end, non-changeable systems
>*Don't think this is related to front-end RIA technology: AJAX or Flash
>based systems should be able to do this equally well
>
>Nope, Flash makes this harder than it needs to be... at least for
>server-side developers.  I really don't care; I use the same remoting code
>I
>use in Flash than I do in Flex, but for some reason the back-end Java dues
>are all googly over whitelists and named services, and Java
>front-controllers... not sure why, but then, I do client work, not back-end
>work.
>
> >From what I've seen at a local Java User's group, I'll agree on the AJAX
>here; but you don't have parse a Flex server call; I'm just calling Java
>methods, not sending strings you have to parse on the server-side.
>
>- web service realization
>* See previous point
>
>Those who create SOA are more app to use something like Flex to showcase
>their services than Flex; case in point, Yahoo.  AJAX?  Sure, I agree on
>that.
>
>- drag and drop
>* That's really basic functionality in any AJAX engine
>
>Basic?  I got a job because 3 years ago it was apparently not basic but
>cake
>for Flash.  What does that have to do with AJAX, though, isn't that just
>DHTML?
>
>- branding
>* I don't see why Flex is better for branding than HTML. And even if you'd
>like to have animations or specific fonts, you can still embed Flash movies
>in AJAX sites.
>
>Exactly, you are using Flash Player to deliver that branding.
>
>- Give Java developers a client that doesn't suck
>* JSF, anyone? And that's an open standard
>
>Who's got that installed?  Percentages that matter?  Open standards are
>neato, but I'd like to use something that works and people can actually
>see.
>
>- intranet portals
>* Don't see why Flex would do this better than AJAX
>
>Me neither, just pointing out I've seen people who have been using Flex for
>it.
>
>- skinnable interfaces
>* I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5,
>but
>still not on par with the skinnability of HTML. I don't know Flex 2.0 in
>this respect though.
>
>Oh it's still weaks as nuts in 1.5.  While it's... improved, it's still I
>think a business decision.  Like, a lot of the apps I've seen that are
>"skinned" people tweak CSS styles and say that's skinned.  That to me, is
>not skinned.  Skinned is using totally different bitmaps and shapes, not
>just changing fonts and colors.  Flex 2 is way better, though, not done
>yet.
>
>Please keep in mind my experience with AJAX is null for projects; in the
>little I've coded to understand why XMLHttpRequest is so cool, that's about
>the limit of my undrestanding of it.  I've never been involved in a large
>project that used a lot of DHTML that I had access to; when I was, I just
>handed SWF files over and never really had any contact with those sides of
>the projects.  Hopefully you can temper the above with that.
>
>
>----- Original Message -----
>From: "Jep Castelein" <jep@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 4:10 PM
>Subject: RE: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hi all,
>
>Just a short message to put some more emphasis on AJAX :-)
>
>I believe that everything that Flex can do, can also be done by mature AJAX
>toolkits. Both provide much higher developer productivity than custom AJAX
>projects, and I feel that custom AJAX will become less important in the
>next
>couple of months. There are so many affordable AJAX toolkits available, so
>why wouldn't you pick one?
>
>Then the question would be: is custom AJAX (or custom Flash) replaced by
>AJAX toolkits or by Flex? Or by something else?
>
>Whatever the outcome, I'd like to give some quick comments on the Flex
>strengths as mentioned by JesterXL.
>
>- form intensive applications
>Better with HTML: loads faster, runs faster, feels more familiar
>
>- integrating many back-end, non-changeable systems
>Don't think this is related to front-end RIA technology: AJAX or Flash
>based
>systems should be able to do this equally well
>
>- web service realization
>See previous point
>
>- drag and drop
>That's really basic functionality in any AJAX engine
>
>- branding
>I don't see why Flex is better for branding than HTML. And even if you'd
>like to have animations or specific fonts, you can still embed Flash movies
>in AJAX sites.
>
>- Give Java developers a client that doesn't suck
>JSF, anyone? And that's an open standard
>
>- intranet portals
>Don't see why Flex would do this better than AJAX
>
>- skinnable interfaces
>I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5,
>but
>still not on par with the skinnability of HTML. I don't know Flex 2.0 in
>this respect though.
>
>
>Cheers,
>Jep
>
>
>
>________________________________
>
>From: ajax_and_ria@yahoogroups.com
>[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of JesterXL
>Sent: 17 November 2005 21:35
>To: ajax_and_ria@yahoogroups.com
>Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>I know a Flex dev from Oz who knows both (Scott Barnes), so
>hopefully he can
>give a unique, albiet passionate response when he joins this
>discussion
>later.
>
>In the iterim, what is and isn't.
>
>Contents:
>- What Flex is for
>- What Flex isn't for
>- What Flash is for
>- What Flash isn't for
>- AJAX for the rest
>- Flex for JSP developers
>- Laszlo bashing
>
>
>What is for Flex:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- form intensive applications.  MoveableType/WordPress' (common
>blogging
>tools) administration, for example.  While most blogs are best
>servered as
>HTML, the intensive server interaction as well as content updating,
>and the
>plethora of forms would be easily done in Flex.  This assumes,
>however, the
>server is setup as an nTier system vs. old skool programming.  For
>example,
>a lot of PHP & Perl web apps for example utilize Perl & HTML in the
>same
>code block.  Sometimes they post to themselves.  Classes, OOP, and
>other
>software concepts are thrown out the window.  They can be used,
>however, if
>they are used to be posted to (GET/POST).
>
>- integrating many back-end, non-changeable systems.  Examples are
>large
>Enterprise applications that have a plethora of services from a
>wide-range
>of teams, the majority written in some form of Java.  Equipping a
>team of
>JSP programmers with Flex, creating hundreds of forms that are
>bindable to
>the back-end, and replacing the non-stateful JSP's with a stateful
>Flex
>client empowers a lot of powerful simplification.  Instead of
>various JSP,
>HTML, DHTML, applets, and other various client implementations, you
>can
>somewhat standardize the client tier to use Flex, but still keep the
>same
>back-end services, with or without re-factoring them to expose
>certian
>methods.  With Remoting (binary vs. XML string), this will decrease
>the
>overall bandwidth.
>
>- web service realization.  Just about any webservice out there begs
>to be
>used by Flex.  The SOA revolution has the most impeccable timing
>since Flex
>can utilize WebServices just as easily as back-end Java, .NET,
>ColdFusion,
>and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo!
>ecspecially all
>have wonderful API's that work extremely well with visualization
>ideas
>realized in Flex & Flash hybrids.  While Flex is built on the Flash
>Player,
>Flash would allow you really eximply the creative, and more
>intuitive &
>responsive ways to show a plethora of data, while Flex makes it
>really easy
>to speak to the server in a natural, programmatic way.  Granted, you
>put
>together some really intuitive & dynamic interfaces in Flex, but my
>money is
>on getting a talented team of designers & infromation architectects,
>
>implementing some design elements in Flash, and authoring it all in
>Flex.
>
>Yahoo! Maps for example.  Not only well executed, but developers &
>designers
>can join in on the fun!
>
>- niche internet connected components.  Not sure what blog coined
>that
>phrase, but basically, some things are more approrpriate in HTML for
>
>skilllset reasons, legacy software, or for time constraints.  As
>such,
>because Flex is just a SWF, and can be treated as an embedable
>object, it
>serves well for smaller, niche purposes as well by being integrated
>into
>larger systems.  Example is MXNA's (Macromedia's blog aggregator)
>where they
>show your post popularity with an extremely interactive graph.
>
>
>http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&f
>eedName=jester%20%28jessewarden%2Ecom%29
>
>Since drag and drop is easy in Flash, I developed a question builder
>for an
>existing CMS built in HTML & .NET; it integrated nicely, and we
>spoke via
>POSTS to .NET.  Pretty simple concept, and saved them tons of time
>developing drag and drop in HTML, and the user ended up winning.
>
>Some of the real-time polls done in Flex & Flash are various
>Macromedia
>employee & ColdFusion weblogs are pretty schweet too.
>
>- branding.  While arguably esoteric, and subjective, I strongly
>beleive
>bringing a company's brand to a user's client, OR retaining it on a
>company
>intranet, can best be done using Flex and Flash together.
>Ironically, the
>downfall of Macromedia's Desktop forray, Central, was because they
>themselves, Macromedia, impressed their brand onto people looking to
>
>represent their companies.  Unfortunately, Macromedia won, and
>Central died
>because of it.  USA Today had a pretty neat forray, but an EXTREMELY
>niche
>case.
>
>Bottom line, while I've seen some very impressive HTML designs, I
>still
>believe if you want to shove a brand, in all it's accuracy, in a
>consumer's
>face, Flex & Flash is the way to go.  Reason being, Sparkle isn't
>out yet,
>hehe!  While PC games prove one can create beautiful client
>interfaces, they
>don't run in the browser, and while Flash Player and XMLHttpRequest
>are both
>ActiveX controls, both have extremely high-install penetration
>ratios, so
>ensuring a client's brand can be seen is a lot.  People argue this
>could
>comprimise usability when a brand's agenda gets in the way, and I'm
>not here
>to argue that, but I do question if you are here to make money, or
>are on
>some crusade to spread good practices.  Me?  To make a living.
>
>- Give Java developers a client that doesn't suck.  JSP developers
>now have
>a familiar paradigm of development with a client that looks awesome
>with
>little design investment.  Oh yeah, did we mention it's stateful?
>
>- intranet portals.  This one is weird; mainly in that I never
>thought to
>use the technology this way, and curse myself for the lack of
>foresight.
>There are a lot of intranet applications that have millions of
>dollars
>pumped into them to ensure they are made, even if they are never
>used.
>Regardless of their nebolous outcomes, the bottom line is, that
>money pie
>can be shared if you pitch yourself right.  As such, HR Portals, and
>other
>departmental information tools work very well in Flex.  I've
>seen/heard of
>some developing projects where either existing portals are to be
>converted
>or switched over.  While I'd actually argue for AJAX here, SOME have
>just
>enough CRUD opertaions of admins needing to see and update data,
>that I
>could see Flex working great.
>
>- skinnable interfaces.  While both Flash & Flex can do this, and I
>think
>it's a stupid feature that is the 20% of the 80/20 rule, it can be
>done, and
>helps sell applications, even if it's a pointless endeavor.
>
>- SAP now has Flex embedded.  All the insanely large apps written
>with SAP
>now have an awesome potential front-end.
>
>What isn't for Flex:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- eLearning.  While I've recently seen a pretty thoroughly
>developed, and
>large in scope Flex site that had serious amounts of eLearning, I
>really
>didn't see the point of Flex other than "developers don't know
>Captivate,
>Flash, Camtasia, nor care too and want to deploy on the server."
>Um, ok.
>
>- CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs
>are
>better done with Director or Flash; Flex, at least in 1.5, has a
>server
>requirement, and most of those projects do not have the scope of
>code that
>most Flex projects do.  Additionally, the level of design control &
>branding
>on those projects is heavyily in need of a tool like Flash with it's
>design
>power (intergrating designs, video, and other various multimedia).
>While
>Flex can use said content, it can't easily create & control it
>during
>authorign like Director & Flash can.  Director also supports older
>systems
>with less system resources, as well as more capability to support
>thousands
>of design assets both at authortime and runtime without crashing
>your
>system.  Flash & Flex do not really have asset memory management at
>runtime,
>and Director does.
>
>Flex 1.5 suffers from a liencesing issue where most occasionally
>connected
>clients don't work; you need a server for Flex, and while Central
>kind of
>counts, no one develops for Central.  While Flex on the desktop has
>promise
>in 2:
>http://dev.jessewarden.com/captivate/flexonthedesktop/
>
>... it just doesn't have the API for it either without a 3rd party
>application to wrap the SWF & EXE.
>
>Mobile devices, even with the advent of Flash Player 7 'esque for
>Deuce
>(Flash Lite 2), don't really fit the Flex model.  Meaning the Flex
>framework
>wasn't designed to run on a mobile device, whereas Flash the IDE and
>Flash
>Lite the runtime were.  Someday...... but not today or tomorrow.
>
>- websites.  I've seen 2 websites done in Flex that made no sense at
>all for
>technology.  The defense was that the large, non-publicly facing CMS
>that
>ran it was in Flex, but to me that's a pathetic excuse.  This is
>where
>giving Java developers a client that doesn't suck backfires.
>
>If HTML, or even AJAX is appropriate, cool, but don't use web
>application
>software to create a web site.
>
>- games.  One could argue that many games are easy to create in
>Flex.  While
>I would agree, most games that actually sell are done in Flash or
>Java.
>
>What is for Flash:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- games, ecspecially with Flash Player 8 and 8.5 since they both
>have
>blitting support, you can use double-buffering to get some seriously
>well
>performing games.  Java used to win in this arena, but not anymore.
>It goes
>without saying that Flash allows you to create anything the crazy
>design
>team comes up with and can look and work however you want.
>Supporting
>sound, video, and other effects most gamers are used to, the world
>is your
>oyester now.
>
>- CD-ROMs.  While Director still contents highly in this sphere,
>Flash
>allows teams of designers to work together more easily with
>authorers than
>Director did.  With improved video support, Flash is overtaking this
>
>market... at least, all the CD-ROM's I've seen.
>
>- Occasionally Connected Clients.  More so, it's best when wrapped
>in a 3rd
>party projector, custom C wrapper, or something that gives it more
>access to
>the local OS.  While Flash itself can easily talk asyncronously to
>any
>back-end system, it's security model is for the web, not for the
>desktop, so
>you need something to help those weaknesses.  Since Flash is
>stateful, it's
>really easy to save local data, and connect to the web and update
>data when
>you have a connection.  This is why a lot are seeing success with
>mobile
>development in Japan and other parts of Asia.
>
>- level branding control that Flex & HTML can't do
>
>- sound control; you already knew that!
>
>- Collaborative Applications.  Until Flex Enterprise Services show
>us what
>they are, if you need video chat, audio chat, text chat, and/or
>multiplay
>games, Flash using XMLSocket, Flash Communication Server, or the new
>binary
>sockets in Flash Player 8.5, this is the way to go.
>
>- like Flex, drag and drop on the web.  I've seen some impressive
>stuff with
>DHTML, but more with Flash.  I think the Flex developers forget it's
>there
>or don't know how to use the API... or just don't know what to do
>with drag
>and drop now that they have it.
>
>- eLearning.  While Captivate holds it's own, I still think all the
>custom
>solutions I've written in Flash are better for solve "service
>needs".
>
>- video on the web.  This goes with branding, but you now suddenly
>have a
>player that's at 90% penetration, linux included (Flash Player 7)...
>and it
>doesn't have to be a frikin' square on the page or in a new window,
>nor come
>with pre-fabbed radio buttons to "select your bandwidth".
>
>- writing extensions for Breeze.  This was talked about, but never
>really
>elaborated upon by Peldi, nor Nigel.  Basically, it seems you can
>write your
>own Pods for Breeze, but not really sure where this stands.
>
>- fighting blogspam.  I implemented a Flash comment form on my site.
>Since
>blog spamming is typically done with bots, they merely post the
>required
>form variables to the the server-side script, bypassing the web
>form.
>Captcha, however, stops them dead in their tracks. My Perl Captcha
>plugin
>for MoveableType however didn't install correctly... 300 comments an
>hour
>with my webhost calling my cell on what CGI file to rename.  I
>merely made a
>hidden field in Flash (like a hidden field in HTML).  Since spambots
>don't
>know how to screen scrape the internals of a SWF, they failed to
>post the
>correct hidden form variable that the SWF has hardcoded internally.
>Been
>blogpsam free from bots for over a year now, since they day I
>implemented
>it.
>
>What isn't for Flash:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- web sites.  While clients to this day still pay for it, it's
>ridicolous,
>and kills usability.  Contrary to popular beleif, there are a
>multitude of
>ways to get Flash sites into search engines, but unless it's for
>movie
>sites, or artists showing portfolios, I've yet to see a good use
>case beyond
>those 2.  Flash elements?  Sure, but only for video, or interactive
>product
>demos.  Navigation, blocks of text, and other navigational aides,
>...nope.
>
>- targetting older systems.  Director owns here, specially with
>Flash Player
>8 not supporting older OS's, and STILL not supporting a Linux
>version.
>
>- web widgets.  While I've seen some pretty neat use of web widgets,
>like
>the polls I've mentioned earlier, some are just too simple to
>justify.
>Like, a mini-blog reader is neat... but why not use AJAX instead?
>The line
>gets REALLY fine here, but I usuallly know in my gut what is and
>isn't
>appropriate.  Some designs lend themselves to just using DHML, while
>others
>couldn't be done without Flash.  The majority I've seen, however,
>are more
>appropriate in DHTML or a server-side HTML rendered way.
>
>- Enterprise applications.  Can it be done?  Sure, but after you've
>developed in Flash for awhile, and then started to develop in Flex,
>it all
>becomes clear.  The weeeks spent writing just GUI code turns into
>days.
>Not to mention the fact, the components in Flex are more mature.
>ASCII MXML
>files work better in version control than binary FLA's do.  You
>can't diff a
>FLA accurately; what's the point?  You thus poison builds early on
>by FLA
>changes, and sharing FLA's amongst developers sucks.  "Hey man, can
>I borrow
>the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.
>
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>For everything else, I'd say AJAX.  Most of the so called "Web 2.0"
>sites
>I've seen are really just extremely well designed and executed
>websites.
>They are just updating parts of the sites that really don't require
>the
>whole page to, like Google Adsense's login, or Flickr's picture
>comments.
>To me, those are extremely awesome & needed uses of AJAX.  With
>HTML's
>native text & hyperlinking abilities, it's really hard to lose.
>
>It goes without saying that if your team is good at web skills, find
>a way
>to make AJAX work unless you really are stretching; same goes with
>Flash &
>Flex.  I would argue, however, JSP developers really should think
>about
>investing some time learning Flex.
>
>...Laszlo... hrm... gonna be a technology bigot here.  While there
>are
>exceptions to every stereotype, and Pandora.com really rocks as an
>app, and
>is a great example of what Laszlo can do... screw Laszlo.  It's
>based on
>older versions of the Flash Player, uses JavaScript which is a
>prototype
>based language which doesn't compare to the class based, strong
>typing of
>ActionScript 2 & 3 that developers respect & come to expect, and is
>based on
>JGenerator, an antiquated server technology.  I've heard of niche
>casses for
>it, like supported legacy apps that need to have lower versions of
>the Flash
>Player because of red tape, but that's a cop-out.   Eeither you are
>innovative or you aren't.  Either you're trying to push the evelope,
>or you
>aren't.  Using Open Source as a selling point is lame.  You get what
>you pay
>for.
>
>Hope that gives you some info!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 2:07 PM
>Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>Yes, for sure! Consider the possibility of using Flex 2 (or even
>third-party frameworks like Laszlo).
>-Jon
>
>At 11:02 AM 11/17/2005, JesterXL wrote:
> >Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted
>my
> >career
> >this year to focus on Flex more so than Flash development.
>Granted, I use
> >both in tandem, but I think Flex is more appropriate for many
>applications
> >previously used for Flash.
> >
> >----- Original Message -----
> >From: "Jonathan Boutelle" <jon@...>
> >To: <ajax_and_ria@yahoogroups.com>
> >Sent: Thursday, November 17, 2005 1:37 PM
> >Subject: [ajax_and_ria] Flash / AJAX decision making
> >
> >
> >Hey everybody!
> >
> >I'm working on a white paper that looks at when to use Flash vs.
>when
> >to use AJAX.
> >
> >I'd love to hear what people in this group have to say. I really
> >think it's possible to scope out situations where Flash is the only
> >viable option, and other situations where using Flash just doesn't
> >make any sense (and AJAX makes more sense). But I'm having trouble
> >articulating this.
> >
> >Macromedia people: What's your take on this? What's the "sweet
>spot"
> >for Flash, and where does AJAX make more sense?
> >
> >AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
> >would you use Flash instead?
> >
> >Few people are equally proficient in both technologies, and that
> >factors into the decision process as well. So for the purposes of
>the
> >question, imagine you're the manager of a crew that is good with
>both
> >technologies.
> >
> >I have my own ideas as well, but I don't want to shape this
> >discussion at the outset. Once we get the ball rolling I'll surely
> >chime in. ;->
> >
> >----^-------^------^--------^-------^
> >Jon Boutelle
> >Principal, Uzanto Consulting
> >Mountain View, CA
> >
> >Office Phone:650-564-0000
> >Cell Phone   :510-708-9825
> >skype id: jboutelle
> >www.uzanto.com
> >www.jonathanboutelle.com
> >----^-------^------^--------^-------^
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>________________________________
>
>YAHOO! GROUPS LINKS
>
>
>* Visit your group "ajax_and_ria
><http://groups.yahoo.com/group/ajax_and_ria> " on the web.
>
>* To unsubscribe from this group, send an email to:
>ajax_and_ria-unsubscribe@yahoogroups.com
><mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>Service <http://docs.yahoo.com/info/terms/> .
>
>
>________________________________
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^





Yahoo! Groups Links

Wow, lots of ideas here. A couple of responses.

RE: initial load time. I have to say, html applications always feel a
little bit "snappier" to me in terms of initial load time. The only
apps where I've been able to actually notice the "streaming of the
javascript" effect, as a user, are the email clients (yahoo beta and gmail).

RE: drag & drop not being AJAX. The term AJAX is colloquially used to
refer to any javascripting that impacts the user experience by making
it more "application-like". Lets just agree to use it to mean that,
otherwise we'll get dragged down into a semantic debate.

I'm interested in what advocates of a platform concede it's not good
for. JesterXLs conceding that Flash/FLEX is bad for an intranet (and
for "web pages", however they are distinguished from "web
applications") is therefore interesting. What is it about "intranets"
and "web pages" that make them poor candidates for Flash/FLEX, Jesse?

My initial take is that flash is ROCKIN' for non-textual interfaces.
Video, audio, games, graphics, there's no way that AJAX can compete
there. Marketingware is a great example of this, but so is most
real-time collaboration software. I think Flash would be awesome for
a distributed CAD/CAM design system, just as an example.

On the flip side, I often find myself frustrated when I'm reading or
writing text in a Flash application. Flash doesn't meet my
expectations of being able to cut and paste the text (for example, to
bookmark it, note down a proper name or address, whatever). Flash
interfaces never seem to display the text in a big enough window for
reading (not sure why). Would you want to read a blog that was
implemented in Flash? I wouldn't. I wouldn't want to write a blog in
Flash either: most flash applications don't handle tabbing from field
to field well, I can't easily cut/copy/paste in Flash text fields, etc,etc.

So maybe one dimension that seems important (when making the
Flash/AJAX decision) is the text / non-text dimension. I fleshed that
idea out a little bit here:
http://www.jonathanboutelle.com/mt/archives/2005/11/flash_what_is_i.html

What are other (high-level) dimensions to consider, when making the
Flash/AJAX decision?
-Jon


At 01:29 PM 11/17/2005, you wrote:
>To respond to Jep; thanks for taking the time to read all of that Jep!
>
>- form intensive applications
>* Better with HTML: loads faster, runs faster, feels more familiar
>
>Loads faster?  Maybe.  Depends what assets in Flex are used, what bitmaps
>are used, etc. What do you define as fast?  HTML streams a heck of a lot
>better, I'll give you that.  But.. can you use it while streaming the
>JavaScript?  Also, once the SWF is cached, she no longer loads anything;
>just talks to the server.  And what are you getting with that load?  A
>branded customer experience or a "more dynamic webpage"?  Does it matter to
>the end user?  What about to those funding the project?
>
>Runs faster?  Huh?  My AMF binary is smaller than your XML strings.
>
>I will concur, however, that I could turn on my old p3, and I'd bet the AJAX
>apps are more responsive.  My Alienware doesn't really do justice to testing
>my content on low-end machines.
>
>Feels familiar?  I agree here.  We need more infromation architects to help
>us; while I disagree with making Flex UI components look like windows or mac
>native os widgets, some of the designs don't really accentuate common
>themes.  But then, how does one set oneself apart?  I agree, though, still
>on this fundamental point; Flickr's image editing tools are easy to get
>quickly whereas their Flash apps are a lot slower on the UI understanding...
>but then they do accomplish more.
>
>- integrating many back-end, non-changeable systems
>*Don't think this is related to front-end RIA technology: AJAX or Flash
>based systems should be able to do this equally well
>
>Nope, Flash makes this harder than it needs to be... at least for
>server-side developers.  I really don't care; I use the same remoting code I
>use in Flash than I do in Flex, but for some reason the back-end Java dues
>are all googly over whitelists and named services, and Java
>front-controllers... not sure why, but then, I do client work, not back-end
>work.
>
> >From what I've seen at a local Java User's group, I'll agree on the AJAX
>here; but you don't have parse a Flex server call; I'm just calling Java
>methods, not sending strings you have to parse on the server-side.
>
>- web service realization
>* See previous point
>
>Those who create SOA are more app to use something like Flex to showcase
>their services than Flex; case in point, Yahoo.  AJAX?  Sure, I agree on
>that.
>
>- drag and drop
>* That's really basic functionality in any AJAX engine
>
>Basic?  I got a job because 3 years ago it was apparently not basic but cake
>for Flash.  What does that have to do with AJAX, though, isn't that just
>DHTML?
>
>- branding
>* I don't see why Flex is better for branding than HTML. And even if you'd
>like to have animations or specific fonts, you can still embed Flash movies
>in AJAX sites.
>
>Exactly, you are using Flash Player to deliver that branding.
>
>- Give Java developers a client that doesn't suck
>* JSF, anyone? And that's an open standard
>
>Who's got that installed?  Percentages that matter?  Open standards are
>neato, but I'd like to use something that works and people can actually see.
>
>- intranet portals
>* Don't see why Flex would do this better than AJAX
>
>Me neither, just pointing out I've seen people who have been using Flex for
>it.
>
>- skinnable interfaces
>* I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5,
>but
>still not on par with the skinnability of HTML. I don't know Flex 2.0 in
>this respect though.
>
>Oh it's still weaks as nuts in 1.5.  While it's... improved, it's still I
>think a business decision.  Like, a lot of the apps I've seen that are
>"skinned" people tweak CSS styles and say that's skinned.  That to me, is
>not skinned.  Skinned is using totally different bitmaps and shapes, not
>just changing fonts and colors.  Flex 2 is way better, though, not done yet.
>
>Please keep in mind my experience with AJAX is null for projects; in the
>little I've coded to understand why XMLHttpRequest is so cool, that's about
>the limit of my undrestanding of it.  I've never been involved in a large
>project that used a lot of DHTML that I had access to; when I was, I just
>handed SWF files over and never really had any contact with those sides of
>the projects.  Hopefully you can temper the above with that.
>
>
>----- Original Message -----
>From: "Jep Castelein" <jep@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 4:10 PM
>Subject: RE: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hi all,
>
>Just a short message to put some more emphasis on AJAX :-)
>
>I believe that everything that Flex can do, can also be done by mature AJAX
>toolkits. Both provide much higher developer productivity than custom AJAX
>projects, and I feel that custom AJAX will become less important in the next
>couple of months. There are so many affordable AJAX toolkits available, so
>why wouldn't you pick one?
>
>Then the question would be: is custom AJAX (or custom Flash) replaced by
>AJAX toolkits or by Flex? Or by something else?
>
>Whatever the outcome, I'd like to give some quick comments on the Flex
>strengths as mentioned by JesterXL.
>
>- form intensive applications
>Better with HTML: loads faster, runs faster, feels more familiar
>
>- integrating many back-end, non-changeable systems
>Don't think this is related to front-end RIA technology: AJAX or Flash based
>systems should be able to do this equally well
>
>- web service realization
>See previous point
>
>- drag and drop
>That's really basic functionality in any AJAX engine
>
>- branding
>I don't see why Flex is better for branding than HTML. And even if you'd
>like to have animations or specific fonts, you can still embed Flash movies
>in AJAX sites.
>
>- Give Java developers a client that doesn't suck
>JSF, anyone? And that's an open standard
>
>- intranet portals
>Don't see why Flex would do this better than AJAX
>
>- skinnable interfaces
>I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5, but
>still not on par with the skinnability of HTML. I don't know Flex 2.0 in
>this respect though.
>
>
>Cheers,
>Jep
>
>
>
>________________________________
>
>From: ajax_and_ria@yahoogroups.com
>[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of JesterXL
>Sent: 17 November 2005 21:35
>To: ajax_and_ria@yahoogroups.com
>Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>I know a Flex dev from Oz who knows both (Scott Barnes), so
>hopefully he can
>give a unique, albiet passionate response when he joins this
>discussion
>later.
>
>In the iterim, what is and isn't.
>
>Contents:
>- What Flex is for
>- What Flex isn't for
>- What Flash is for
>- What Flash isn't for
>- AJAX for the rest
>- Flex for JSP developers
>- Laszlo bashing
>
>
>What is for Flex:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- form intensive applications.  MoveableType/WordPress' (common
>blogging
>tools) administration, for example.  While most blogs are best
>servered as
>HTML, the intensive server interaction as well as content updating,
>and the
>plethora of forms would be easily done in Flex.  This assumes,
>however, the
>server is setup as an nTier system vs. old skool programming.  For
>example,
>a lot of PHP & Perl web apps for example utilize Perl & HTML in the
>same
>code block.  Sometimes they post to themselves.  Classes, OOP, and
>other
>software concepts are thrown out the window.  They can be used,
>however, if
>they are used to be posted to (GET/POST).
>
>- integrating many back-end, non-changeable systems.  Examples are
>large
>Enterprise applications that have a plethora of services from a
>wide-range
>of teams, the majority written in some form of Java.  Equipping a
>team of
>JSP programmers with Flex, creating hundreds of forms that are
>bindable to
>the back-end, and replacing the non-stateful JSP's with a stateful
>Flex
>client empowers a lot of powerful simplification.  Instead of
>various JSP,
>HTML, DHTML, applets, and other various client implementations, you
>can
>somewhat standardize the client tier to use Flex, but still keep the
>same
>back-end services, with or without re-factoring them to expose
>certian
>methods.  With Remoting (binary vs. XML string), this will decrease
>the
>overall bandwidth.
>
>- web service realization.  Just about any webservice out there begs
>to be
>used by Flex.  The SOA revolution has the most impeccable timing
>since Flex
>can utilize WebServices just as easily as back-end Java, .NET,
>ColdFusion,
>and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo!
>ecspecially all
>have wonderful API's that work extremely well with visualization
>ideas
>realized in Flex & Flash hybrids.  While Flex is built on the Flash
>Player,
>Flash would allow you really eximply the creative, and more
>intuitive &
>responsive ways to show a plethora of data, while Flex makes it
>really easy
>to speak to the server in a natural, programmatic way.  Granted, you
>put
>together some really intuitive & dynamic interfaces in Flex, but my
>money is
>on getting a talented team of designers & infromation architectects,
>
>implementing some design elements in Flash, and authoring it all in
>Flex.
>
>Yahoo! Maps for example.  Not only well executed, but developers &
>designers
>can join in on the fun!
>
>- niche internet connected components.  Not sure what blog coined
>that
>phrase, but basically, some things are more approrpriate in HTML for
>
>skilllset reasons, legacy software, or for time constraints.  As
>such,
>because Flex is just a SWF, and can be treated as an embedable
>object, it
>serves well for smaller, niche purposes as well by being integrated
>into
>larger systems.  Example is MXNA's (Macromedia's blog aggregator)
>where they
>show your post popularity with an extremely interactive graph.
>
>
>http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&f
>eedName=jester%20%28jessewarden%2Ecom%29
>
>Since drag and drop is easy in Flash, I developed a question builder
>for an
>existing CMS built in HTML & .NET; it integrated nicely, and we
>spoke via
>POSTS to .NET.  Pretty simple concept, and saved them tons of time
>developing drag and drop in HTML, and the user ended up winning.
>
>Some of the real-time polls done in Flex & Flash are various
>Macromedia
>employee & ColdFusion weblogs are pretty schweet too.
>
>- branding.  While arguably esoteric, and subjective, I strongly
>beleive
>bringing a company's brand to a user's client, OR retaining it on a
>company
>intranet, can best be done using Flex and Flash together.
>Ironically, the
>downfall of Macromedia's Desktop forray, Central, was because they
>themselves, Macromedia, impressed their brand onto people looking to
>
>represent their companies.  Unfortunately, Macromedia won, and
>Central died
>because of it.  USA Today had a pretty neat forray, but an EXTREMELY
>niche
>case.
>
>Bottom line, while I've seen some very impressive HTML designs, I
>still
>believe if you want to shove a brand, in all it's accuracy, in a
>consumer's
>face, Flex & Flash is the way to go.  Reason being, Sparkle isn't
>out yet,
>hehe!  While PC games prove one can create beautiful client
>interfaces, they
>don't run in the browser, and while Flash Player and XMLHttpRequest
>are both
>ActiveX controls, both have extremely high-install penetration
>ratios, so
>ensuring a client's brand can be seen is a lot.  People argue this
>could
>comprimise usability when a brand's agenda gets in the way, and I'm
>not here
>to argue that, but I do question if you are here to make money, or
>are on
>some crusade to spread good practices.  Me?  To make a living.
>
>- Give Java developers a client that doesn't suck.  JSP developers
>now have
>a familiar paradigm of development with a client that looks awesome
>with
>little design investment.  Oh yeah, did we mention it's stateful?
>
>- intranet portals.  This one is weird; mainly in that I never
>thought to
>use the technology this way, and curse myself for the lack of
>foresight.
>There are a lot of intranet applications that have millions of
>dollars
>pumped into them to ensure they are made, even if they are never
>used.
>Regardless of their nebolous outcomes, the bottom line is, that
>money pie
>can be shared if you pitch yourself right.  As such, HR Portals, and
>other
>departmental information tools work very well in Flex.  I've
>seen/heard of
>some developing projects where either existing portals are to be
>converted
>or switched over.  While I'd actually argue for AJAX here, SOME have
>just
>enough CRUD opertaions of admins needing to see and update data,
>that I
>could see Flex working great.
>
>- skinnable interfaces.  While both Flash & Flex can do this, and I
>think
>it's a stupid feature that is the 20% of the 80/20 rule, it can be
>done, and
>helps sell applications, even if it's a pointless endeavor.
>
>- SAP now has Flex embedded.  All the insanely large apps written
>with SAP
>now have an awesome potential front-end.
>
>What isn't for Flex:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- eLearning.  While I've recently seen a pretty thoroughly
>developed, and
>large in scope Flex site that had serious amounts of eLearning, I
>really
>didn't see the point of Flex other than "developers don't know
>Captivate,
>Flash, Camtasia, nor care too and want to deploy on the server."
>Um, ok.
>
>- CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs
>are
>better done with Director or Flash; Flex, at least in 1.5, has a
>server
>requirement, and most of those projects do not have the scope of
>code that
>most Flex projects do.  Additionally, the level of design control &
>branding
>on those projects is heavyily in need of a tool like Flash with it's
>design
>power (intergrating designs, video, and other various multimedia).
>While
>Flex can use said content, it can't easily create & control it
>during
>authorign like Director & Flash can.  Director also supports older
>systems
>with less system resources, as well as more capability to support
>thousands
>of design assets both at authortime and runtime without crashing
>your
>system.  Flash & Flex do not really have asset memory management at
>runtime,
>and Director does.
>
>Flex 1.5 suffers from a liencesing issue where most occasionally
>connected
>clients don't work; you need a server for Flex, and while Central
>kind of
>counts, no one develops for Central.  While Flex on the desktop has
>promise
>in 2:
>http://dev.jessewarden.com/captivate/flexonthedesktop/
>
>... it just doesn't have the API for it either without a 3rd party
>application to wrap the SWF & EXE.
>
>Mobile devices, even with the advent of Flash Player 7 'esque for
>Deuce
>(Flash Lite 2), don't really fit the Flex model.  Meaning the Flex
>framework
>wasn't designed to run on a mobile device, whereas Flash the IDE and
>Flash
>Lite the runtime were.  Someday...... but not today or tomorrow.
>
>- websites.  I've seen 2 websites done in Flex that made no sense at
>all for
>technology.  The defense was that the large, non-publicly facing CMS
>that
>ran it was in Flex, but to me that's a pathetic excuse.  This is
>where
>giving Java developers a client that doesn't suck backfires.
>
>If HTML, or even AJAX is appropriate, cool, but don't use web
>application
>software to create a web site.
>
>- games.  One could argue that many games are easy to create in
>Flex.  While
>I would agree, most games that actually sell are done in Flash or
>Java.
>
>What is for Flash:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- games, ecspecially with Flash Player 8 and 8.5 since they both
>have
>blitting support, you can use double-buffering to get some seriously
>well
>performing games.  Java used to win in this arena, but not anymore.
>It goes
>without saying that Flash allows you to create anything the crazy
>design
>team comes up with and can look and work however you want.
>Supporting
>sound, video, and other effects most gamers are used to, the world
>is your
>oyester now.
>
>- CD-ROMs.  While Director still contents highly in this sphere,
>Flash
>allows teams of designers to work together more easily with
>authorers than
>Director did.  With improved video support, Flash is overtaking this
>
>market... at least, all the CD-ROM's I've seen.
>
>- Occasionally Connected Clients.  More so, it's best when wrapped
>in a 3rd
>party projector, custom C wrapper, or something that gives it more
>access to
>the local OS.  While Flash itself can easily talk asyncronously to
>any
>back-end system, it's security model is for the web, not for the
>desktop, so
>you need something to help those weaknesses.  Since Flash is
>stateful, it's
>really easy to save local data, and connect to the web and update
>data when
>you have a connection.  This is why a lot are seeing success with
>mobile
>development in Japan and other parts of Asia.
>
>- level branding control that Flex & HTML can't do
>
>- sound control; you already knew that!
>
>- Collaborative Applications.  Until Flex Enterprise Services show
>us what
>they are, if you need video chat, audio chat, text chat, and/or
>multiplay
>games, Flash using XMLSocket, Flash Communication Server, or the new
>binary
>sockets in Flash Player 8.5, this is the way to go.
>
>- like Flex, drag and drop on the web.  I've seen some impressive
>stuff with
>DHTML, but more with Flash.  I think the Flex developers forget it's
>there
>or don't know how to use the API... or just don't know what to do
>with drag
>and drop now that they have it.
>
>- eLearning.  While Captivate holds it's own, I still think all the
>custom
>solutions I've written in Flash are better for solve "service
>needs".
>
>- video on the web.  This goes with branding, but you now suddenly
>have a
>player that's at 90% penetration, linux included (Flash Player 7)...
>and it
>doesn't have to be a frikin' square on the page or in a new window,
>nor come
>with pre-fabbed radio buttons to "select your bandwidth".
>
>- writing extensions for Breeze.  This was talked about, but never
>really
>elaborated upon by Peldi, nor Nigel.  Basically, it seems you can
>write your
>own Pods for Breeze, but not really sure where this stands.
>
>- fighting blogspam.  I implemented a Flash comment form on my site.
>Since
>blog spamming is typically done with bots, they merely post the
>required
>form variables to the the server-side script, bypassing the web
>form.
>Captcha, however, stops them dead in their tracks. My Perl Captcha
>plugin
>for MoveableType however didn't install correctly... 300 comments an
>hour
>with my webhost calling my cell on what CGI file to rename.  I
>merely made a
>hidden field in Flash (like a hidden field in HTML).  Since spambots
>don't
>know how to screen scrape the internals of a SWF, they failed to
>post the
>correct hidden form variable that the SWF has hardcoded internally.
>Been
>blogpsam free from bots for over a year now, since they day I
>implemented
>it.
>
>What isn't for Flash:
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>- web sites.  While clients to this day still pay for it, it's
>ridicolous,
>and kills usability.  Contrary to popular beleif, there are a
>multitude of
>ways to get Flash sites into search engines, but unless it's for
>movie
>sites, or artists showing portfolios, I've yet to see a good use
>case beyond
>those 2.  Flash elements?  Sure, but only for video, or interactive
>product
>demos.  Navigation, blocks of text, and other navigational aides,
>...nope.
>
>- targetting older systems.  Director owns here, specially with
>Flash Player
>8 not supporting older OS's, and STILL not supporting a Linux
>version.
>
>- web widgets.  While I've seen some pretty neat use of web widgets,
>like
>the polls I've mentioned earlier, some are just too simple to
>justify.
>Like, a mini-blog reader is neat... but why not use AJAX instead?
>The line
>gets REALLY fine here, but I usuallly know in my gut what is and
>isn't
>appropriate.  Some designs lend themselves to just using DHML, while
>others
>couldn't be done without Flash.  The majority I've seen, however,
>are more
>appropriate in DHTML or a server-side HTML rendered way.
>
>- Enterprise applications.  Can it be done?  Sure, but after you've
>developed in Flash for awhile, and then started to develop in Flex,
>it all
>becomes clear.  The weeeks spent writing just GUI code turns into
>days.
>Not to mention the fact, the components in Flex are more mature.
>ASCII MXML
>files work better in version control than binary FLA's do.  You
>can't diff a
>FLA accurately; what's the point?  You thus poison builds early on
>by FLA
>changes, and sharing FLA's amongst developers sucks.  "Hey man, can
>I borrow
>the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.
>
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>For everything else, I'd say AJAX.  Most of the so called "Web 2.0"
>sites
>I've seen are really just extremely well designed and executed
>websites.
>They are just updating parts of the sites that really don't require
>the
>whole page to, like Google Adsense's login, or Flickr's picture
>comments.
>To me, those are extremely awesome & needed uses of AJAX.  With
>HTML's
>native text & hyperlinking abilities, it's really hard to lose.
>
>It goes without saying that if your team is good at web skills, find
>a way
>to make AJAX work unless you really are stretching; same goes with
>Flash &
>Flex.  I would argue, however, JSP developers really should think
>about
>investing some time learning Flex.
>
>...Laszlo... hrm... gonna be a technology bigot here.  While there
>are
>exceptions to every stereotype, and Pandora.com really rocks as an
>app, and
>is a great example of what Laszlo can do... screw Laszlo.  It's
>based on
>older versions of the Flash Player, uses JavaScript which is a
>prototype
>based language which doesn't compare to the class based, strong
>typing of
>ActionScript 2 & 3 that developers respect & come to expect, and is
>based on
>JGenerator, an antiquated server technology.  I've heard of niche
>casses for
>it, like supported legacy apps that need to have lower versions of
>the Flash
>Player because of red tape, but that's a cop-out.   Eeither you are
>innovative or you aren't.  Either you're trying to push the evelope,
>or you
>aren't.  Using Open Source as a selling point is lame.  You get what
>you pay
>for.
>
>Hope that gives you some info!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 2:07 PM
>Subject: Re: [ajax_and_ria] Flash / AJAX decision making
>
>
>Yes, for sure! Consider the possibility of using Flex 2 (or even
>third-party frameworks like Laszlo).
>-Jon
>
>At 11:02 AM 11/17/2005, JesterXL wrote:
> >Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted
>my
> >career
> >this year to focus on Flex more so than Flash development.
>Granted, I use
> >both in tandem, but I think Flex is more appropriate for many
>applications
> >previously used for Flash.
> >
> >----- Original Message -----
> >From: "Jonathan Boutelle" <jon@...>
> >To: <ajax_and_ria@yahoogroups.com>
> >Sent: Thursday, November 17, 2005 1:37 PM
> >Subject: [ajax_and_ria] Flash / AJAX decision making
> >
> >
> >Hey everybody!
> >
> >I'm working on a white paper that looks at when to use Flash vs.
>when
> >to use AJAX.
> >
> >I'd love to hear what people in this group have to say. I really
> >think it's possible to scope out situations where Flash is the only
> >viable option, and other situations where using Flash just doesn't
> >make any sense (and AJAX makes more sense). But I'm having trouble
> >articulating this.
> >
> >Macromedia people: What's your take on this? What's the "sweet
>spot"
> >for Flash, and where does AJAX make more sense?
> >
> >AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
> >would you use Flash instead?
> >
> >Few people are equally proficient in both technologies, and that
> >factors into the decision process as well. So for the purposes of
>the
> >question, imagine you're the manager of a crew that is good with
>both
> >technologies.
> >
> >I have my own ideas as well, but I don't want to shape this
> >discussion at the outset. Once we get the ball rolling I'll surely
> >chime in. ;->
> >
> >----^-------^------^--------^-------^
> >Jon Boutelle
> >Principal, Uzanto Consulting
> >Mountain View, CA
> >
> >Office Phone:650-564-0000
> >Cell Phone   :510-708-9825
> >skype id: jboutelle
> >www.uzanto.com
> >www.jonathanboutelle.com
> >----^-------^------^--------^-------^
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>________________________________
>
>YAHOO! GROUPS LINKS
>
>
>* Visit your group "ajax_and_ria
><http://groups.yahoo.com/group/ajax_and_ria> " on the web.
>
>* To unsubscribe from this group, send an email to:
>ajax_and_ria-unsubscribe@yahoogroups.com
><mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>Service <http://docs.yahoo.com/info/terms/> .
>
>
>________________________________
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

To respond to Jep; thanks for taking the time to read all of that Jep!

- form intensive applications
* Better with HTML: loads faster, runs faster, feels more familiar

Loads faster?  Maybe.  Depends what assets in Flex are used, what bitmaps
are used, etc. What do you define as fast?  HTML streams a heck of a lot
better, I'll give you that.  But.. can you use it while streaming the
JavaScript?  Also, once the SWF is cached, she no longer loads anything;
just talks to the server.  And what are you getting with that load?  A
branded customer experience or a "more dynamic webpage"?  Does it matter to
the end user?  What about to those funding the project?

Runs faster?  Huh?  My AMF binary is smaller than your XML strings.

I will concur, however, that I could turn on my old p3, and I'd bet the AJAX
apps are more responsive.  My Alienware doesn't really do justice to testing
my content on low-end machines.

Feels familiar?  I agree here.  We need more infromation architects to help
us; while I disagree with making Flex UI components look like windows or mac
native os widgets, some of the designs don't really accentuate common
themes.  But then, how does one set oneself apart?  I agree, though, still
on this fundamental point; Flickr's image editing tools are easy to get
quickly whereas their Flash apps are a lot slower on the UI understanding...
but then they do accomplish more.

- integrating many back-end, non-changeable systems
*Don't think this is related to front-end RIA technology: AJAX or Flash
based systems should be able to do this equally well

Nope, Flash makes this harder than it needs to be... at least for
server-side developers.  I really don't care; I use the same remoting code I
use in Flash than I do in Flex, but for some reason the back-end Java dues
are all googly over whitelists and named services, and Java
front-controllers... not sure why, but then, I do client work, not back-end
work.

From what I've seen at a local Java User's group, I'll agree on the AJAX
here; but you don't have parse a Flex server call; I'm just calling Java
methods, not sending strings you have to parse on the server-side.

- web service realization
* See previous point

Those who create SOA are more app to use something like Flex to showcase
their services than Flex; case in point, Yahoo.  AJAX?  Sure, I agree on
that.

- drag and drop
* That's really basic functionality in any AJAX engine

Basic?  I got a job because 3 years ago it was apparently not basic but cake
for Flash.  What does that have to do with AJAX, though, isn't that just
DHTML?

- branding
* I don't see why Flex is better for branding than HTML. And even if you'd
like to have animations or specific fonts, you can still embed Flash movies
in AJAX sites.

Exactly, you are using Flash Player to deliver that branding.

- Give Java developers a client that doesn't suck
* JSF, anyone? And that's an open standard

Who's got that installed?  Percentages that matter?  Open standards are
neato, but I'd like to use something that works and people can actually see.

- intranet portals
* Don't see why Flex would do this better than AJAX

Me neither, just pointing out I've seen people who have been using Flex for
it.

- skinnable interfaces
* I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5,
but
still not on par with the skinnability of HTML. I don't know Flex 2.0 in
this respect though.

Oh it's still weaks as nuts in 1.5.  While it's... improved, it's still I
think a business decision.  Like, a lot of the apps I've seen that are
"skinned" people tweak CSS styles and say that's skinned.  That to me, is
not skinned.  Skinned is using totally different bitmaps and shapes, not
just changing fonts and colors.  Flex 2 is way better, though, not done yet.

Please keep in mind my experience with AJAX is null for projects; in the
little I've coded to understand why XMLHttpRequest is so cool, that's about
the limit of my undrestanding of it.  I've never been involved in a large
project that used a lot of DHTML that I had access to; when I was, I just
handed SWF files over and never really had any contact with those sides of
the projects.  Hopefully you can temper the above with that.


----- Original Message -----
From: "Jep Castelein" <jep@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 4:10 PM
Subject: RE: [ajax_and_ria] Flash / AJAX decision making


Hi all,

Just a short message to put some more emphasis on AJAX :-)

I believe that everything that Flex can do, can also be done by mature AJAX
toolkits. Both provide much higher developer productivity than custom AJAX
projects, and I feel that custom AJAX will become less important in the next
couple of months. There are so many affordable AJAX toolkits available, so
why wouldn't you pick one?

Then the question would be: is custom AJAX (or custom Flash) replaced by
AJAX toolkits or by Flex? Or by something else?

Whatever the outcome, I'd like to give some quick comments on the Flex
strengths as mentioned by JesterXL.

- form intensive applications
Better with HTML: loads faster, runs faster, feels more familiar

- integrating many back-end, non-changeable systems
Don't think this is related to front-end RIA technology: AJAX or Flash based
systems should be able to do this equally well

- web service realization
See previous point

- drag and drop
That's really basic functionality in any AJAX engine

- branding
I don't see why Flex is better for branding than HTML. And even if you'd
like to have animations or specific fonts, you can still embed Flash movies
in AJAX sites.

- Give Java developers a client that doesn't suck
JSF, anyone? And that's an open standard

- intranet portals
Don't see why Flex would do this better than AJAX

- skinnable interfaces
I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5, but
still not on par with the skinnability of HTML. I don't know Flex 2.0 in
this respect though.


Cheers,
Jep



________________________________

From: ajax_and_ria@yahoogroups.com
[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of JesterXL
Sent: 17 November 2005 21:35
To: ajax_and_ria@yahoogroups.com
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


I know a Flex dev from Oz who knows both (Scott Barnes), so
hopefully he can
give a unique, albiet passionate response when he joins this
discussion
later.

In the iterim, what is and isn't.

Contents:
- What Flex is for
- What Flex isn't for
- What Flash is for
- What Flash isn't for
- AJAX for the rest
- Flex for JSP developers
- Laszlo bashing


What is for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- form intensive applications.  MoveableType/WordPress' (common
blogging
tools) administration, for example.  While most blogs are best
servered as
HTML, the intensive server interaction as well as content updating,
and the
plethora of forms would be easily done in Flex.  This assumes,
however, the
server is setup as an nTier system vs. old skool programming.  For
example,
a lot of PHP & Perl web apps for example utilize Perl & HTML in the
same
code block.  Sometimes they post to themselves.  Classes, OOP, and
other
software concepts are thrown out the window.  They can be used,
however, if
they are used to be posted to (GET/POST).

- integrating many back-end, non-changeable systems.  Examples are
large
Enterprise applications that have a plethora of services from a
wide-range
of teams, the majority written in some form of Java.  Equipping a
team of
JSP programmers with Flex, creating hundreds of forms that are
bindable to
the back-end, and replacing the non-stateful JSP's with a stateful
Flex
client empowers a lot of powerful simplification.  Instead of
various JSP,
HTML, DHTML, applets, and other various client implementations, you
can
somewhat standardize the client tier to use Flex, but still keep the
same
back-end services, with or without re-factoring them to expose
certian
methods.  With Remoting (binary vs. XML string), this will decrease
the
overall bandwidth.

- web service realization.  Just about any webservice out there begs
to be
used by Flex.  The SOA revolution has the most impeccable timing
since Flex
can utilize WebServices just as easily as back-end Java, .NET,
ColdFusion,
and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo!
ecspecially all
have wonderful API's that work extremely well with visualization
ideas
realized in Flex & Flash hybrids.  While Flex is built on the Flash
Player,
Flash would allow you really eximply the creative, and more
intuitive &
responsive ways to show a plethora of data, while Flex makes it
really easy
to speak to the server in a natural, programmatic way.  Granted, you
put
together some really intuitive & dynamic interfaces in Flex, but my
money is
on getting a talented team of designers & infromation architectects,

implementing some design elements in Flash, and authoring it all in
Flex.

Yahoo! Maps for example.  Not only well executed, but developers &
designers
can join in on the fun!

- niche internet connected components.  Not sure what blog coined
that
phrase, but basically, some things are more approrpriate in HTML for

skilllset reasons, legacy software, or for time constraints.  As
such,
because Flex is just a SWF, and can be treated as an embedable
object, it
serves well for smaller, niche purposes as well by being integrated
into
larger systems.  Example is MXNA's (Macromedia's blog aggregator)
where they
show your post popularity with an extremely interactive graph.


http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&f
eedName=jester%20%28jessewarden%2Ecom%29

Since drag and drop is easy in Flash, I developed a question builder
for an
existing CMS built in HTML & .NET; it integrated nicely, and we
spoke via
POSTS to .NET.  Pretty simple concept, and saved them tons of time
developing drag and drop in HTML, and the user ended up winning.

Some of the real-time polls done in Flex & Flash are various
Macromedia
employee & ColdFusion weblogs are pretty schweet too.

- branding.  While arguably esoteric, and subjective, I strongly
beleive
bringing a company's brand to a user's client, OR retaining it on a
company
intranet, can best be done using Flex and Flash together.
Ironically, the
downfall of Macromedia's Desktop forray, Central, was because they
themselves, Macromedia, impressed their brand onto people looking to

represent their companies.  Unfortunately, Macromedia won, and
Central died
because of it.  USA Today had a pretty neat forray, but an EXTREMELY
niche
case.

Bottom line, while I've seen some very impressive HTML designs, I
still
believe if you want to shove a brand, in all it's accuracy, in a
consumer's
face, Flex & Flash is the way to go.  Reason being, Sparkle isn't
out yet,
hehe!  While PC games prove one can create beautiful client
interfaces, they
don't run in the browser, and while Flash Player and XMLHttpRequest
are both
ActiveX controls, both have extremely high-install penetration
ratios, so
ensuring a client's brand can be seen is a lot.  People argue this
could
comprimise usability when a brand's agenda gets in the way, and I'm
not here
to argue that, but I do question if you are here to make money, or
are on
some crusade to spread good practices.  Me?  To make a living.

- Give Java developers a client that doesn't suck.  JSP developers
now have
a familiar paradigm of development with a client that looks awesome
with
little design investment.  Oh yeah, did we mention it's stateful?

- intranet portals.  This one is weird; mainly in that I never
thought to
use the technology this way, and curse myself for the lack of
foresight.
There are a lot of intranet applications that have millions of
dollars
pumped into them to ensure they are made, even if they are never
used.
Regardless of their nebolous outcomes, the bottom line is, that
money pie
can be shared if you pitch yourself right.  As such, HR Portals, and
other
departmental information tools work very well in Flex.  I've
seen/heard of
some developing projects where either existing portals are to be
converted
or switched over.  While I'd actually argue for AJAX here, SOME have
just
enough CRUD opertaions of admins needing to see and update data,
that I
could see Flex working great.

- skinnable interfaces.  While both Flash & Flex can do this, and I
think
it's a stupid feature that is the 20% of the 80/20 rule, it can be
done, and
helps sell applications, even if it's a pointless endeavor.

- SAP now has Flex embedded.  All the insanely large apps written
with SAP
now have an awesome potential front-end.

What isn't for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- eLearning.  While I've recently seen a pretty thoroughly
developed, and
large in scope Flex site that had serious amounts of eLearning, I
really
didn't see the point of Flex other than "developers don't know
Captivate,
Flash, Camtasia, nor care too and want to deploy on the server."
Um, ok.

- CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs
are
better done with Director or Flash; Flex, at least in 1.5, has a
server
requirement, and most of those projects do not have the scope of
code that
most Flex projects do.  Additionally, the level of design control &
branding
on those projects is heavyily in need of a tool like Flash with it's
design
power (intergrating designs, video, and other various multimedia).
While
Flex can use said content, it can't easily create & control it
during
authorign like Director & Flash can.  Director also supports older
systems
with less system resources, as well as more capability to support
thousands
of design assets both at authortime and runtime without crashing
your
system.  Flash & Flex do not really have asset memory management at
runtime,
and Director does.

Flex 1.5 suffers from a liencesing issue where most occasionally
connected
clients don't work; you need a server for Flex, and while Central
kind of
counts, no one develops for Central.  While Flex on the desktop has
promise
in 2:
http://dev.jessewarden.com/captivate/flexonthedesktop/

... it just doesn't have the API for it either without a 3rd party
application to wrap the SWF & EXE.

Mobile devices, even with the advent of Flash Player 7 'esque for
Deuce
(Flash Lite 2), don't really fit the Flex model.  Meaning the Flex
framework
wasn't designed to run on a mobile device, whereas Flash the IDE and
Flash
Lite the runtime were.  Someday...... but not today or tomorrow.

- websites.  I've seen 2 websites done in Flex that made no sense at
all for
technology.  The defense was that the large, non-publicly facing CMS
that
ran it was in Flex, but to me that's a pathetic excuse.  This is
where
giving Java developers a client that doesn't suck backfires.

If HTML, or even AJAX is appropriate, cool, but don't use web
application
software to create a web site.

- games.  One could argue that many games are easy to create in
Flex.  While
I would agree, most games that actually sell are done in Flash or
Java.

What is for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- games, ecspecially with Flash Player 8 and 8.5 since they both
have
blitting support, you can use double-buffering to get some seriously
well
performing games.  Java used to win in this arena, but not anymore.
It goes
without saying that Flash allows you to create anything the crazy
design
team comes up with and can look and work however you want.
Supporting
sound, video, and other effects most gamers are used to, the world
is your
oyester now.

- CD-ROMs.  While Director still contents highly in this sphere,
Flash
allows teams of designers to work together more easily with
authorers than
Director did.  With improved video support, Flash is overtaking this

market... at least, all the CD-ROM's I've seen.

- Occasionally Connected Clients.  More so, it's best when wrapped
in a 3rd
party projector, custom C wrapper, or something that gives it more
access to
the local OS.  While Flash itself can easily talk asyncronously to
any
back-end system, it's security model is for the web, not for the
desktop, so
you need something to help those weaknesses.  Since Flash is
stateful, it's
really easy to save local data, and connect to the web and update
data when
you have a connection.  This is why a lot are seeing success with
mobile
development in Japan and other parts of Asia.

- level branding control that Flex & HTML can't do

- sound control; you already knew that!

- Collaborative Applications.  Until Flex Enterprise Services show
us what
they are, if you need video chat, audio chat, text chat, and/or
multiplay
games, Flash using XMLSocket, Flash Communication Server, or the new
binary
sockets in Flash Player 8.5, this is the way to go.

- like Flex, drag and drop on the web.  I've seen some impressive
stuff with
DHTML, but more with Flash.  I think the Flex developers forget it's
there
or don't know how to use the API... or just don't know what to do
with drag
and drop now that they have it.

- eLearning.  While Captivate holds it's own, I still think all the
custom
solutions I've written in Flash are better for solve "service
needs".

- video on the web.  This goes with branding, but you now suddenly
have a
player that's at 90% penetration, linux included (Flash Player 7)...
and it
doesn't have to be a frikin' square on the page or in a new window,
nor come
with pre-fabbed radio buttons to "select your bandwidth".

- writing extensions for Breeze.  This was talked about, but never
really
elaborated upon by Peldi, nor Nigel.  Basically, it seems you can
write your
own Pods for Breeze, but not really sure where this stands.

- fighting blogspam.  I implemented a Flash comment form on my site.
Since
blog spamming is typically done with bots, they merely post the
required
form variables to the the server-side script, bypassing the web
form.
Captcha, however, stops them dead in their tracks. My Perl Captcha
plugin
for MoveableType however didn't install correctly... 300 comments an
hour
with my webhost calling my cell on what CGI file to rename.  I
merely made a
hidden field in Flash (like a hidden field in HTML).  Since spambots
don't
know how to screen scrape the internals of a SWF, they failed to
post the
correct hidden form variable that the SWF has hardcoded internally.
Been
blogpsam free from bots for over a year now, since they day I
implemented
it.

What isn't for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- web sites.  While clients to this day still pay for it, it's
ridicolous,
and kills usability.  Contrary to popular beleif, there are a
multitude of
ways to get Flash sites into search engines, but unless it's for
movie
sites, or artists showing portfolios, I've yet to see a good use
case beyond
those 2.  Flash elements?  Sure, but only for video, or interactive
product
demos.  Navigation, blocks of text, and other navigational aides,
...nope.

- targetting older systems.  Director owns here, specially with
Flash Player
8 not supporting older OS's, and STILL not supporting a Linux
version.

- web widgets.  While I've seen some pretty neat use of web widgets,
like
the polls I've mentioned earlier, some are just too simple to
justify.
Like, a mini-blog reader is neat... but why not use AJAX instead?
The line
gets REALLY fine here, but I usuallly know in my gut what is and
isn't
appropriate.  Some designs lend themselves to just using DHML, while
others
couldn't be done without Flash.  The majority I've seen, however,
are more
appropriate in DHTML or a server-side HTML rendered way.

- Enterprise applications.  Can it be done?  Sure, but after you've
developed in Flash for awhile, and then started to develop in Flex,
it all
becomes clear.  The weeeks spent writing just GUI code turns into
days.
Not to mention the fact, the components in Flex are more mature.
ASCII MXML
files work better in version control than binary FLA's do.  You
can't diff a
FLA accurately; what's the point?  You thus poison builds early on
by FLA
changes, and sharing FLA's amongst developers sucks.  "Hey man, can
I borrow
the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

For everything else, I'd say AJAX.  Most of the so called "Web 2.0"
sites
I've seen are really just extremely well designed and executed
websites.
They are just updating parts of the sites that really don't require
the
whole page to, like Google Adsense's login, or Flickr's picture
comments.
To me, those are extremely awesome & needed uses of AJAX.  With
HTML's
native text & hyperlinking abilities, it's really hard to lose.

It goes without saying that if your team is good at web skills, find
a way
to make AJAX work unless you really are stretching; same goes with
Flash &
Flex.  I would argue, however, JSP developers really should think
about
investing some time learning Flex.

...Laszlo... hrm... gonna be a technology bigot here.  While there
are
exceptions to every stereotype, and Pandora.com really rocks as an
app, and
is a great example of what Laszlo can do... screw Laszlo.  It's
based on
older versions of the Flash Player, uses JavaScript which is a
prototype
based language which doesn't compare to the class based, strong
typing of
ActionScript 2 & 3 that developers respect & come to expect, and is
based on
JGenerator, an antiquated server technology.  I've heard of niche
casses for
it, like supported legacy apps that need to have lower versions of
the Flash
Player because of red tape, but that's a cop-out.   Eeither you are
innovative or you aren't.  Either you're trying to push the evelope,
or you
aren't.  Using Open Source as a selling point is lame.  You get what
you pay
for.

Hope that gives you some info!














----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 2:07 PM
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


Yes, for sure! Consider the possibility of using Flex 2 (or even
third-party frameworks like Laszlo).
-Jon

At 11:02 AM 11/17/2005, JesterXL wrote:
>Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted
my
>career
>this year to focus on Flex more so than Flash development.
Granted, I use
>both in tandem, but I think Flex is more appropriate for many
applications
>previously used for Flash.
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 1:37 PM
>Subject: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hey everybody!
>
>I'm working on a white paper that looks at when to use Flash vs.
when
>to use AJAX.
>
>I'd love to hear what people in this group have to say. I really
>think it's possible to scope out situations where Flash is the only
>viable option, and other situations where using Flash just doesn't
>make any sense (and AJAX makes more sense). But I'm having trouble
>articulating this.
>
>Macromedia people: What's your take on this? What's the "sweet
spot"
>for Flash, and where does AJAX make more sense?
>
>AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>would you use Flash instead?
>
>Few people are equally proficient in both technologies, and that
>factors into the decision process as well. So for the purposes of
the
>question, imagine you're the manager of a crew that is good with
both
>technologies.
>
>I have my own ideas as well, but I don't want to shape this
>discussion at the outset. Once we get the ball rolling I'll surely
>chime in. ;->
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^





Yahoo! Groups Links







________________________________

YAHOO! GROUPS LINKS


* Visit your group "ajax_and_ria
<http://groups.yahoo.com/group/ajax_and_ria> " on the web.

* To unsubscribe from this group, send an email to:
ajax_and_ria-unsubscribe@yahoogroups.com
<mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .


________________________________







Yahoo! Groups Links

Hi all,

Just a short message to put some more emphasis on AJAX :-)

I believe that everything that Flex can do, can also be done by mature AJAX
toolkits. Both provide much higher developer productivity than custom AJAX
projects, and I feel that custom AJAX will become less important in the next
couple of months. There are so many affordable AJAX toolkits available, so
why wouldn't you pick one?

Then the question would be: is custom AJAX (or custom Flash) replaced by
AJAX toolkits or by Flex? Or by something else?

Whatever the outcome, I'd like to give some quick comments on the Flex
strengths as mentioned by JesterXL.

- form intensive applications
Better with HTML: loads faster, runs faster, feels more familiar

- integrating many back-end, non-changeable systems
Don't think this is related to front-end RIA technology: AJAX or Flash based
systems should be able to do this equally well

- web service realization
See previous point

- drag and drop
That's really basic functionality in any AJAX engine

- branding
I don't see why Flex is better for branding than HTML. And even if you'd
like to have animations or specific fonts, you can still embed Flash movies
in AJAX sites.

- Give Java developers a client that doesn't suck
JSF, anyone? And that's an open standard

- intranet portals
Don't see why Flex would do this better than AJAX

- skinnable interfaces
I feel this was extremely weak in Flex 1.0, slightly better in Flex 1.5, but
still not on par with the skinnability of HTML. I don't know Flex 2.0 in
this respect though.


Cheers,
Jep



________________________________

	 From: ajax_and_ria@yahoogroups.com
[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of JesterXL
	 Sent: 17 November 2005 21:35
	 To: ajax_and_ria@yahoogroups.com
	 Subject: Re: [ajax_and_ria] Flash / AJAX decision making


	 I know a Flex dev from Oz who knows both (Scott Barnes), so
hopefully he can
	 give a unique, albiet passionate response when he joins this
discussion
	 later.

	 In the iterim, what is and isn't.

	 Contents:
	 - What Flex is for
	 - What Flex isn't for
	 - What Flash is for
	 - What Flash isn't for
	 - AJAX for the rest
	 - Flex for JSP developers
	 - Laszlo bashing


	 What is for Flex:
	 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

	 - form intensive applications.  MoveableType/WordPress' (common
blogging
	 tools) administration, for example.  While most blogs are best
servered as
	 HTML, the intensive server interaction as well as content updating,
and the
	 plethora of forms would be easily done in Flex.  This assumes,
however, the
	 server is setup as an nTier system vs. old skool programming.  For
example,
	 a lot of PHP & Perl web apps for example utilize Perl & HTML in the
same
	 code block.  Sometimes they post to themselves.  Classes, OOP, and
other
	 software concepts are thrown out the window.  They can be used,
however, if
	 they are used to be posted to (GET/POST).

	 - integrating many back-end, non-changeable systems.  Examples are
large
	 Enterprise applications that have a plethora of services from a
wide-range
	 of teams, the majority written in some form of Java.  Equipping a
team of
	 JSP programmers with Flex, creating hundreds of forms that are
bindable to
	 the back-end, and replacing the non-stateful JSP's with a stateful
Flex
	 client empowers a lot of powerful simplification.  Instead of
various JSP,
	 HTML, DHTML, applets, and other various client implementations, you
can
	 somewhat standardize the client tier to use Flex, but still keep the
same
	 back-end services, with or without re-factoring them to expose
certian
	 methods.  With Remoting (binary vs. XML string), this will decrease
the
	 overall bandwidth.

	 - web service realization.  Just about any webservice out there begs
to be
	 used by Flex.  The SOA revolution has the most impeccable timing
since Flex
	 can utilize WebServices just as easily as back-end Java, .NET,
ColdFusion,
	 and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo!
ecspecially all
	 have wonderful API's that work extremely well with visualization
ideas
	 realized in Flex & Flash hybrids.  While Flex is built on the Flash
Player,
	 Flash would allow you really eximply the creative, and more
intuitive &
	 responsive ways to show a plethora of data, while Flex makes it
really easy
	 to speak to the server in a natural, programmatic way.  Granted, you
put
	 together some really intuitive & dynamic interfaces in Flex, but my
money is
	 on getting a talented team of designers & infromation architectects,

	 implementing some design elements in Flash, and authoring it all in
Flex.

	 Yahoo! Maps for example.  Not only well executed, but developers &
designers
	 can join in on the fun!

	 - niche internet connected components.  Not sure what blog coined
that
	 phrase, but basically, some things are more approrpriate in HTML for

	 skilllset reasons, legacy software, or for time constraints.  As
such,
	 because Flex is just a SWF, and can be treated as an embedable
object, it
	 serves well for smaller, niche purposes as well by being integrated
into
	 larger systems.  Example is MXNA's (Macromedia's blog aggregator)
where they
	 show your post popularity with an extremely interactive graph.


http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&f
eedName=jester%20%28jessewarden%2Ecom%29

	 Since drag and drop is easy in Flash, I developed a question builder
for an
	 existing CMS built in HTML & .NET; it integrated nicely, and we
spoke via
	 POSTS to .NET.  Pretty simple concept, and saved them tons of time
	 developing drag and drop in HTML, and the user ended up winning.

	 Some of the real-time polls done in Flex & Flash are various
Macromedia
	 employee & ColdFusion weblogs are pretty schweet too.

	 - branding.  While arguably esoteric, and subjective, I strongly
beleive
	 bringing a company's brand to a user's client, OR retaining it on a
company
	 intranet, can best be done using Flex and Flash together.
Ironically, the
	 downfall of Macromedia's Desktop forray, Central, was because they
	 themselves, Macromedia, impressed their brand onto people looking to

	 represent their companies.  Unfortunately, Macromedia won, and
Central died
	 because of it.  USA Today had a pretty neat forray, but an EXTREMELY
niche
	 case.

	 Bottom line, while I've seen some very impressive HTML designs, I
still
	 believe if you want to shove a brand, in all it's accuracy, in a
consumer's
	 face, Flex & Flash is the way to go.  Reason being, Sparkle isn't
out yet,
	 hehe!  While PC games prove one can create beautiful client
interfaces, they
	 don't run in the browser, and while Flash Player and XMLHttpRequest
are both
	 ActiveX controls, both have extremely high-install penetration
ratios, so
	 ensuring a client's brand can be seen is a lot.  People argue this
could
	 comprimise usability when a brand's agenda gets in the way, and I'm
not here
	 to argue that, but I do question if you are here to make money, or
are on
	 some crusade to spread good practices.  Me?  To make a living.

	 - Give Java developers a client that doesn't suck.  JSP developers
now have
	 a familiar paradigm of development with a client that looks awesome
with
	 little design investment.  Oh yeah, did we mention it's stateful?

	 - intranet portals.  This one is weird; mainly in that I never
thought to
	 use the technology this way, and curse myself for the lack of
foresight.
	 There are a lot of intranet applications that have millions of
dollars
	 pumped into them to ensure they are made, even if they are never
used.
	 Regardless of their nebolous outcomes, the bottom line is, that
money pie
	 can be shared if you pitch yourself right.  As such, HR Portals, and
other
	 departmental information tools work very well in Flex.  I've
seen/heard of
	 some developing projects where either existing portals are to be
converted
	 or switched over.  While I'd actually argue for AJAX here, SOME have
just
	 enough CRUD opertaions of admins needing to see and update data,
that I
	 could see Flex working great.

	 - skinnable interfaces.  While both Flash & Flex can do this, and I
think
	 it's a stupid feature that is the 20% of the 80/20 rule, it can be
done, and
	 helps sell applications, even if it's a pointless endeavor.

	 - SAP now has Flex embedded.  All the insanely large apps written
with SAP
	 now have an awesome potential front-end.

	 What isn't for Flex:
	 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

	 - eLearning.  While I've recently seen a pretty thoroughly
developed, and
	 large in scope Flex site that had serious amounts of eLearning, I
really
	 didn't see the point of Flex other than "developers don't know
Captivate,
	 Flash, Camtasia, nor care too and want to deploy on the server."
Um, ok.

	 - CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs
are
	 better done with Director or Flash; Flex, at least in 1.5, has a
server
	 requirement, and most of those projects do not have the scope of
code that
	 most Flex projects do.  Additionally, the level of design control &
branding
	 on those projects is heavyily in need of a tool like Flash with it's
design
	 power (intergrating designs, video, and other various multimedia).
While
	 Flex can use said content, it can't easily create & control it
during
	 authorign like Director & Flash can.  Director also supports older
systems
	 with less system resources, as well as more capability to support
thousands
	 of design assets both at authortime and runtime without crashing
your
	 system.  Flash & Flex do not really have asset memory management at
runtime,
	 and Director does.

	 Flex 1.5 suffers from a liencesing issue where most occasionally
connected
	 clients don't work; you need a server for Flex, and while Central
kind of
	 counts, no one develops for Central.  While Flex on the desktop has
promise
	 in 2:
	 http://dev.jessewarden.com/captivate/flexonthedesktop/

	 ... it just doesn't have the API for it either without a 3rd party
	 application to wrap the SWF & EXE.

	 Mobile devices, even with the advent of Flash Player 7 'esque for
Deuce
	 (Flash Lite 2), don't really fit the Flex model.  Meaning the Flex
framework
	 wasn't designed to run on a mobile device, whereas Flash the IDE and
Flash
	 Lite the runtime were.  Someday...... but not today or tomorrow.

	 - websites.  I've seen 2 websites done in Flex that made no sense at
all for
	 technology.  The defense was that the large, non-publicly facing CMS
that
	 ran it was in Flex, but to me that's a pathetic excuse.  This is
where
	 giving Java developers a client that doesn't suck backfires.

	 If HTML, or even AJAX is appropriate, cool, but don't use web
application
	 software to create a web site.

	 - games.  One could argue that many games are easy to create in
Flex.  While
	 I would agree, most games that actually sell are done in Flash or
Java.

	 What is for Flash:
	 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

	 - games, ecspecially with Flash Player 8 and 8.5 since they both
have
	 blitting support, you can use double-buffering to get some seriously
well
	 performing games.  Java used to win in this arena, but not anymore.
It goes
	 without saying that Flash allows you to create anything the crazy
design
	 team comes up with and can look and work however you want.
Supporting
	 sound, video, and other effects most gamers are used to, the world
is your
	 oyester now.

	 - CD-ROMs.  While Director still contents highly in this sphere,
Flash
	 allows teams of designers to work together more easily with
authorers than
	 Director did.  With improved video support, Flash is overtaking this

	 market... at least, all the CD-ROM's I've seen.

	 - Occasionally Connected Clients.  More so, it's best when wrapped
in a 3rd
	 party projector, custom C wrapper, or something that gives it more
access to
	 the local OS.  While Flash itself can easily talk asyncronously to
any
	 back-end system, it's security model is for the web, not for the
desktop, so
	 you need something to help those weaknesses.  Since Flash is
stateful, it's
	 really easy to save local data, and connect to the web and update
data when
	 you have a connection.  This is why a lot are seeing success with
mobile
	 development in Japan and other parts of Asia.

	 - level branding control that Flex & HTML can't do

	 - sound control; you already knew that!

	 - Collaborative Applications.  Until Flex Enterprise Services show
us what
	 they are, if you need video chat, audio chat, text chat, and/or
multiplay
	 games, Flash using XMLSocket, Flash Communication Server, or the new
binary
	 sockets in Flash Player 8.5, this is the way to go.

	 - like Flex, drag and drop on the web.  I've seen some impressive
stuff with
	 DHTML, but more with Flash.  I think the Flex developers forget it's
there
	 or don't know how to use the API... or just don't know what to do
with drag
	 and drop now that they have it.

	 - eLearning.  While Captivate holds it's own, I still think all the
custom
	 solutions I've written in Flash are better for solve "service
needs".

	 - video on the web.  This goes with branding, but you now suddenly
have a
	 player that's at 90% penetration, linux included (Flash Player 7)...
and it
	 doesn't have to be a frikin' square on the page or in a new window,
nor come
	 with pre-fabbed radio buttons to "select your bandwidth".

	 - writing extensions for Breeze.  This was talked about, but never
really
	 elaborated upon by Peldi, nor Nigel.  Basically, it seems you can
write your
	 own Pods for Breeze, but not really sure where this stands.

	 - fighting blogspam.  I implemented a Flash comment form on my site.
Since
	 blog spamming is typically done with bots, they merely post the
required
	 form variables to the the server-side script, bypassing the web
form.
	 Captcha, however, stops them dead in their tracks. My Perl Captcha
plugin
	 for MoveableType however didn't install correctly... 300 comments an
hour
	 with my webhost calling my cell on what CGI file to rename.  I
merely made a
	 hidden field in Flash (like a hidden field in HTML).  Since spambots
don't
	 know how to screen scrape the internals of a SWF, they failed to
post the
	 correct hidden form variable that the SWF has hardcoded internally.
Been
	 blogpsam free from bots for over a year now, since they day I
implemented
	 it.

	 What isn't for Flash:
	 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

	 - web sites.  While clients to this day still pay for it, it's
ridicolous,
	 and kills usability.  Contrary to popular beleif, there are a
multitude of
	 ways to get Flash sites into search engines, but unless it's for
movie
	 sites, or artists showing portfolios, I've yet to see a good use
case beyond
	 those 2.  Flash elements?  Sure, but only for video, or interactive
product
	 demos.  Navigation, blocks of text, and other navigational aides,
...nope.

	 - targetting older systems.  Director owns here, specially with
Flash Player
	 8 not supporting older OS's, and STILL not supporting a Linux
version.

	 - web widgets.  While I've seen some pretty neat use of web widgets,
like
	 the polls I've mentioned earlier, some are just too simple to
justify.
	 Like, a mini-blog reader is neat... but why not use AJAX instead?
The line
	 gets REALLY fine here, but I usuallly know in my gut what is and
isn't
	 appropriate.  Some designs lend themselves to just using DHML, while
others
	 couldn't be done without Flash.  The majority I've seen, however,
are more
	 appropriate in DHTML or a server-side HTML rendered way.

	 - Enterprise applications.  Can it be done?  Sure, but after you've
	 developed in Flash for awhile, and then started to develop in Flex,
it all
	 becomes clear.  The weeeks spent writing just GUI code turns into
days.
	 Not to mention the fact, the components in Flex are more mature.
ASCII MXML
	 files work better in version control than binary FLA's do.  You
can't diff a
	 FLA accurately; what's the point?  You thus poison builds early on
by FLA
	 changes, and sharing FLA's amongst developers sucks.  "Hey man, can
I borrow
	 the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.

	 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

	 For everything else, I'd say AJAX.  Most of the so called "Web 2.0"
sites
	 I've seen are really just extremely well designed and executed
websites.
	 They are just updating parts of the sites that really don't require
the
	 whole page to, like Google Adsense's login, or Flickr's picture
comments.
	 To me, those are extremely awesome & needed uses of AJAX.  With
HTML's
	 native text & hyperlinking abilities, it's really hard to lose.

	 It goes without saying that if your team is good at web skills, find
a way
	 to make AJAX work unless you really are stretching; same goes with
Flash &
	 Flex.  I would argue, however, JSP developers really should think
about
	 investing some time learning Flex.

	 ...Laszlo... hrm... gonna be a technology bigot here.  While there
are
	 exceptions to every stereotype, and Pandora.com really rocks as an
app, and
	 is a great example of what Laszlo can do... screw Laszlo.  It's
based on
	 older versions of the Flash Player, uses JavaScript which is a
prototype
	 based language which doesn't compare to the class based, strong
typing of
	 ActionScript 2 & 3 that developers respect & come to expect, and is
based on
	 JGenerator, an antiquated server technology.  I've heard of niche
casses for
	 it, like supported legacy apps that need to have lower versions of
the Flash
	 Player because of red tape, but that's a cop-out.   Eeither you are
	 innovative or you aren't.  Either you're trying to push the evelope,
or you
	 aren't.  Using Open Source as a selling point is lame.  You get what
you pay
	 for.

	 Hope that gives you some info!














	 ----- Original Message -----
	 From: "Jonathan Boutelle" <jon@...>
	 To: <ajax_and_ria@yahoogroups.com>
	 Sent: Thursday, November 17, 2005 2:07 PM
	 Subject: Re: [ajax_and_ria] Flash / AJAX decision making


	 Yes, for sure! Consider the possibility of using Flex 2 (or even
	 third-party frameworks like Laszlo).
	 -Jon

	 At 11:02 AM 11/17/2005, JesterXL wrote:
	 >Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted
my
	 >career
	 >this year to focus on Flex more so than Flash development.
Granted, I use
	 >both in tandem, but I think Flex is more appropriate for many
applications
	 >previously used for Flash.
	 >
	 >----- Original Message -----
	 >From: "Jonathan Boutelle" <jon@...>
	 >To: <ajax_and_ria@yahoogroups.com>
	 >Sent: Thursday, November 17, 2005 1:37 PM
	 >Subject: [ajax_and_ria] Flash / AJAX decision making
	 >
	 >
	 >Hey everybody!
	 >
	 >I'm working on a white paper that looks at when to use Flash vs.
when
	 >to use AJAX.
	 >
	 >I'd love to hear what people in this group have to say. I really
	 >think it's possible to scope out situations where Flash is the only
	 >viable option, and other situations where using Flash just doesn't
	 >make any sense (and AJAX makes more sense). But I'm having trouble
	 >articulating this.
	 >
	 >Macromedia people: What's your take on this? What's the "sweet
spot"
	 >for Flash, and where does AJAX make more sense?
	 >
	 >AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
	 >would you use Flash instead?
	 >
	 >Few people are equally proficient in both technologies, and that
	 >factors into the decision process as well. So for the purposes of
the
	 >question, imagine you're the manager of a crew that is good with
both
	 >technologies.
	 >
	 >I have my own ideas as well, but I don't want to shape this
	 >discussion at the outset. Once we get the ball rolling I'll surely
	 >chime in. ;->
	 >
	 >----^-------^------^--------^-------^
	 >Jon Boutelle
	 >Principal, Uzanto Consulting
	 >Mountain View, CA
	 >
	 >Office Phone:650-564-0000
	 >Cell Phone   :510-708-9825
	 >skype id: jboutelle
	 >www.uzanto.com
	 >www.jonathanboutelle.com
	 >----^-------^------^--------^-------^
	 >
	 >
	 >
	 >
	 >
	 >Yahoo! Groups Links
	 >
	 >
	 >
	 >
	 >
	 >
	 >
	 >
	 >
	 >Yahoo! Groups Links
	 >
	 >
	 >
	 >

	 ----^-------^------^--------^-------^
	 Jon Boutelle
	 Principal, Uzanto Consulting
	 Mountain View, CA

	 Office Phone:650-564-0000
	 Cell Phone   :510-708-9825
	 skype id: jboutelle
	 www.uzanto.com
	 www.jonathanboutelle.com
	 ----^-------^------^--------^-------^





	 Yahoo! Groups Links







________________________________

	 YAHOO! GROUPS LINKS


			 *  Visit your group "ajax_and_ria
<http://groups.yahoo.com/group/ajax_and_ria> " on the web.

	 *  To unsubscribe from this group, send an email to:
		  ajax_and_ria-unsubscribe@yahoogroups.com
<mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>

	 *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .


________________________________

Crap, forgot; Flash for kiosks is a really really big market, and lends
itself well to the occasionally connected model.

----- Original Message -----
From: "JesterXL" <jesterxl@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 3:34 PM
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


I know a Flex dev from Oz who knows both (Scott Barnes), so hopefully he can
give a unique, albiet passionate response when he joins this discussion
later.

In the iterim, what is and isn't.

Contents:
- What Flex is for
- What Flex isn't for
- What Flash is for
- What Flash isn't for
- AJAX for the rest
- Flex for JSP developers
- Laszlo bashing


What is for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- form intensive applications.  MoveableType/WordPress' (common blogging
tools) administration, for example.  While most blogs are best servered as
HTML, the intensive server interaction as well as content updating, and the
plethora of forms would be easily done in Flex.  This assumes, however, the
server is setup as an nTier system vs. old skool programming.  For example,
a lot of PHP & Perl web apps for example utilize Perl & HTML in the same
code block.  Sometimes they post to themselves.  Classes, OOP, and other
software concepts are thrown out the window.  They can be used, however, if
they are used to be posted to (GET/POST).

- integrating many back-end, non-changeable systems.  Examples are large
Enterprise applications that have a plethora of services from a wide-range
of teams, the majority written in some form of Java.  Equipping a team of
JSP programmers with Flex, creating hundreds of forms that are bindable to
the back-end, and replacing the non-stateful JSP's with a stateful Flex
client empowers a lot of powerful simplification.  Instead of various JSP,
HTML, DHTML, applets, and other various client implementations, you can
somewhat standardize the client tier to use Flex, but still keep the same
back-end services, with or without re-factoring them to expose certian
methods.  With Remoting (binary vs. XML string), this will decrease the
overall bandwidth.

- web service realization.  Just about any webservice out there begs to be
used by Flex.  The SOA revolution has the most impeccable timing since Flex
can utilize WebServices just as easily as back-end Java, .NET, ColdFusion,
and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo! ecspecially all
have wonderful API's that work extremely well with visualization ideas
realized in Flex & Flash hybrids.  While Flex is built on the Flash Player,
Flash would allow you really eximply the creative, and more intuitive &
responsive ways to show a plethora of data, while Flex makes it really easy
to speak to the server in a natural, programmatic way.  Granted, you put
together some really intuitive & dynamic interfaces in Flex, but my money is
on getting a talented team of designers & infromation architectects,
implementing some design elements in Flash, and authoring it all in Flex.

Yahoo! Maps for example.  Not only well executed, but developers & designers
can join in on the fun!

- niche internet connected components.  Not sure what blog coined that
phrase, but basically, some things are more approrpriate in HTML for
skilllset reasons, legacy software, or for time constraints.  As such,
because Flex is just a SWF, and can be treated as an embedable object, it
serves well for smaller, niche purposes as well by being integrated into
larger systems.  Example is MXNA's (Macromedia's blog aggregator) where they
show your post popularity with an extremely interactive graph.

http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&feedN\
ame=jester%20%28jessewarden%2Ecom%29

Since drag and drop is easy in Flash, I developed a question builder for an
existing CMS built in HTML & .NET; it integrated nicely, and we spoke via
POSTS to .NET.  Pretty simple concept, and saved them tons of time
developing drag and drop in HTML, and the user ended up winning.

Some of the real-time polls done in Flex & Flash are various Macromedia
employee & ColdFusion weblogs are pretty schweet too.

- branding.  While arguably esoteric, and subjective, I strongly beleive
bringing a company's brand to a user's client, OR retaining it on a company
intranet, can best be done using Flex and Flash together.  Ironically, the
downfall of Macromedia's Desktop forray, Central, was because they
themselves, Macromedia, impressed their brand onto people looking to
represent their companies.  Unfortunately, Macromedia won, and Central died
because of it.  USA Today had a pretty neat forray, but an EXTREMELY niche
case.

Bottom line, while I've seen some very impressive HTML designs, I still
believe if you want to shove a brand, in all it's accuracy, in a consumer's
face, Flex & Flash is the way to go.  Reason being, Sparkle isn't out yet,
hehe!  While PC games prove one can create beautiful client interfaces, they
don't run in the browser, and while Flash Player and XMLHttpRequest are both
ActiveX controls, both have extremely high-install penetration ratios, so
ensuring a client's brand can be seen is a lot.  People argue this could
comprimise usability when a brand's agenda gets in the way, and I'm not here
to argue that, but I do question if you are here to make money, or are on
some crusade to spread good practices.  Me?  To make a living.

- Give Java developers a client that doesn't suck.  JSP developers now have
a familiar paradigm of development with a client that looks awesome with
little design investment.  Oh yeah, did we mention it's stateful?

- intranet portals.  This one is weird; mainly in that I never thought to
use the technology this way, and curse myself for the lack of foresight.
There are a lot of intranet applications that have millions of dollars
pumped into them to ensure they are made, even if they are never used.
Regardless of their nebolous outcomes, the bottom line is, that money pie
can be shared if you pitch yourself right.  As such, HR Portals, and other
departmental information tools work very well in Flex.  I've seen/heard of
some developing projects where either existing portals are to be converted
or switched over.  While I'd actually argue for AJAX here, SOME have just
enough CRUD opertaions of admins needing to see and update data, that I
could see Flex working great.

- skinnable interfaces.  While both Flash & Flex can do this, and I think
it's a stupid feature that is the 20% of the 80/20 rule, it can be done, and
helps sell applications, even if it's a pointless endeavor.

- SAP now has Flex embedded.  All the insanely large apps written with SAP
now have an awesome potential front-end.

What isn't for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- eLearning.  While I've recently seen a pretty thoroughly developed, and
large in scope Flex site that had serious amounts of eLearning, I really
didn't see the point of Flex other than "developers don't know Captivate,
Flash, Camtasia, nor care too and want to deploy on the server."  Um, ok.

- CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs are
better done with Director or Flash; Flex, at least in 1.5, has a server
requirement, and most of those projects do not have the scope of code that
most Flex projects do.  Additionally, the level of design control & branding
on those projects is heavyily in need of a tool like Flash with it's design
power (intergrating designs, video, and other various multimedia).  While
Flex can use said content, it can't easily create & control it during
authorign like Director & Flash can.  Director also supports older systems
with less system resources, as well as more capability to support thousands
of design assets both at authortime and runtime without crashing your
system.  Flash & Flex do not really have asset memory management at runtime,
and Director does.

Flex 1.5 suffers from a liencesing issue where most occasionally connected
clients don't work; you need a server for Flex, and while Central kind of
counts, no one develops for Central.  While Flex on the desktop has promise
in 2:
http://dev.jessewarden.com/captivate/flexonthedesktop/

... it just doesn't have the API for it either without a 3rd party
application to wrap the SWF & EXE.

Mobile devices, even with the advent of Flash Player 7 'esque for Deuce
(Flash Lite 2), don't really fit the Flex model.  Meaning the Flex framework
wasn't designed to run on a mobile device, whereas Flash the IDE and Flash
Lite the runtime were.  Someday...... but not today or tomorrow.

- websites.  I've seen 2 websites done in Flex that made no sense at all for
technology.  The defense was that the large, non-publicly facing CMS that
ran it was in Flex, but to me that's a pathetic excuse.  This is where
giving Java developers a client that doesn't suck backfires.

If HTML, or even AJAX is appropriate, cool, but don't use web application
software to create a web site.

- games.  One could argue that many games are easy to create in Flex.  While
I would agree, most games that actually sell are done in Flash or Java.

What is for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- games, ecspecially with Flash Player 8 and 8.5 since they both have
blitting support, you can use double-buffering to get some seriously well
performing games.  Java used to win in this arena, but not anymore.  It goes
without saying that Flash allows you to create anything the crazy design
team comes up with and can look and work however you want.  Supporting
sound, video, and other effects most gamers are used to, the world is your
oyester now.

- CD-ROMs.  While Director still contents highly in this sphere, Flash
allows teams of designers to work together more easily with authorers than
Director did.  With improved video support, Flash is overtaking this
market... at least, all the CD-ROM's I've seen.

- Occasionally Connected Clients.  More so, it's best when wrapped in a 3rd
party projector, custom C wrapper, or something that gives it more access to
the local OS.  While Flash itself can easily talk asyncronously to any
back-end system, it's security model is for the web, not for the desktop, so
you need something to help those weaknesses.  Since Flash is stateful, it's
really easy to save local data, and connect to the web and update data when
you have a connection.  This is why a lot are seeing success with mobile
development in Japan and other parts of Asia.

- level branding control that Flex & HTML can't do

- sound control; you already knew that!

- Collaborative Applications.  Until Flex Enterprise Services show us what
they are, if you need video chat, audio chat, text chat, and/or multiplay
games, Flash using XMLSocket, Flash Communication Server, or the new binary
sockets in Flash Player 8.5, this is the way to go.

- like Flex, drag and drop on the web.  I've seen some impressive stuff with
DHTML, but more with Flash.  I think the Flex developers forget it's there
or don't know how to use the API... or just don't know what to do with drag
and drop now that they have it.

- eLearning.  While Captivate holds it's own, I still think all the custom
solutions I've written in Flash are better for solve "service needs".

- video on the web.  This goes with branding, but you now suddenly have a
player that's at 90% penetration, linux included (Flash Player 7)... and it
doesn't have to be a frikin' square on the page or in a new window, nor come
with pre-fabbed radio buttons to "select your bandwidth".

- writing extensions for Breeze.  This was talked about, but never really
elaborated upon by Peldi, nor Nigel.  Basically, it seems you can write your
own Pods for Breeze, but not really sure where this stands.

- fighting blogspam.  I implemented a Flash comment form on my site.  Since
blog spamming is typically done with bots, they merely post the required
form variables to the the server-side script, bypassing the web form.
Captcha, however, stops them dead in their tracks. My Perl Captcha plugin
for MoveableType however didn't install correctly... 300 comments an hour
with my webhost calling my cell on what CGI file to rename.  I merely made a
hidden field in Flash (like a hidden field in HTML).  Since spambots don't
know how to screen scrape the internals of a SWF, they failed to post the
correct hidden form variable that the SWF has hardcoded internally.  Been
blogpsam free from bots for over a year now, since they day I implemented
it.

What isn't for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- web sites.  While clients to this day still pay for it, it's ridicolous,
and kills usability.  Contrary to popular beleif, there are a multitude of
ways to get Flash sites into search engines, but unless it's for movie
sites, or artists showing portfolios, I've yet to see a good use case beyond
those 2.  Flash elements?  Sure, but only for video, or interactive product
demos.  Navigation, blocks of text, and other navigational aides, ...nope.

- targetting older systems.  Director owns here, specially with Flash Player
8 not supporting older OS's, and STILL not supporting a Linux version.

- web widgets.  While I've seen some pretty neat use of web widgets, like
the polls I've mentioned earlier, some are just too simple to justify.
Like, a mini-blog reader is neat... but why not use AJAX instead?  The line
gets REALLY fine here, but I usuallly know in my gut what is and isn't
appropriate.  Some designs lend themselves to just using DHML, while others
couldn't be done without Flash.  The majority I've seen, however, are more
appropriate in DHTML or a server-side HTML rendered way.

- Enterprise applications.  Can it be done?  Sure, but after you've
developed in Flash for awhile, and then started to develop in Flex, it all
becomes clear.  The weeeks spent writing just GUI code turns into days.
Not to mention the fact, the components in Flex are more mature.  ASCII MXML
files work better in version control than binary FLA's do.  You can't diff a
FLA accurately; what's the point?  You thus poison builds early on by FLA
changes, and sharing FLA's amongst developers sucks.  "Hey man, can I borrow
the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

For everything else, I'd say AJAX.  Most of the so called "Web 2.0" sites
I've seen are really just extremely well designed and executed websites.
They are just updating parts of the sites that really don't require the
whole page to, like Google Adsense's login, or Flickr's picture comments.
To me, those are extremely awesome & needed uses of AJAX.  With HTML's
native text & hyperlinking abilities, it's really hard to lose.

It goes without saying that if your team is good at web skills, find a way
to make AJAX work unless you really are stretching; same goes with Flash &
Flex.  I would argue, however, JSP developers really should think about
investing some time learning Flex.

...Laszlo... hrm... gonna be a technology bigot here.  While there are
exceptions to every stereotype, and Pandora.com really rocks as an app, and
is a great example of what Laszlo can do... screw Laszlo.  It's based on
older versions of the Flash Player, uses JavaScript which is a prototype
based language which doesn't compare to the class based, strong typing of
ActionScript 2 & 3 that developers respect & come to expect, and is based on
JGenerator, an antiquated server technology.  I've heard of niche casses for
it, like supported legacy apps that need to have lower versions of the Flash
Player because of red tape, but that's a cop-out.   Eeither you are
innovative or you aren't.  Either you're trying to push the evelope, or you
aren't.  Using Open Source as a selling point is lame.  You get what you pay
for.

Hope that gives you some info!














----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 2:07 PM
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


Yes, for sure! Consider the possibility of using Flex 2 (or even
third-party frameworks like Laszlo).
-Jon

At 11:02 AM 11/17/2005, JesterXL wrote:
>Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted my
>career
>this year to focus on Flex more so than Flash development.  Granted, I use
>both in tandem, but I think Flex is more appropriate for many applications
>previously used for Flash.
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 1:37 PM
>Subject: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hey everybody!
>
>I'm working on a white paper that looks at when to use Flash vs. when
>to use AJAX.
>
>I'd love to hear what people in this group have to say. I really
>think it's possible to scope out situations where Flash is the only
>viable option, and other situations where using Flash just doesn't
>make any sense (and AJAX makes more sense). But I'm having trouble
>articulating this.
>
>Macromedia people: What's your take on this? What's the "sweet spot"
>for Flash, and where does AJAX make more sense?
>
>AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>would you use Flash instead?
>
>Few people are equally proficient in both technologies, and that
>factors into the decision process as well. So for the purposes of the
>question, imagine you're the manager of a crew that is good with both
>technologies.
>
>I have my own ideas as well, but I don't want to shape this
>discussion at the outset. Once we get the ball rolling I'll surely
>chime in. ;->
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^





Yahoo! Groups Links









Yahoo! Groups Links

I know a Flex dev from Oz who knows both (Scott Barnes), so hopefully he can
give a unique, albiet passionate response when he joins this discussion
later.

In the iterim, what is and isn't.

Contents:
- What Flex is for
- What Flex isn't for
- What Flash is for
- What Flash isn't for
- AJAX for the rest
- Flex for JSP developers
- Laszlo bashing


What is for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- form intensive applications.  MoveableType/WordPress' (common blogging
tools) administration, for example.  While most blogs are best servered as
HTML, the intensive server interaction as well as content updating, and the
plethora of forms would be easily done in Flex.  This assumes, however, the
server is setup as an nTier system vs. old skool programming.  For example,
a lot of PHP & Perl web apps for example utilize Perl & HTML in the same
code block.  Sometimes they post to themselves.  Classes, OOP, and other
software concepts are thrown out the window.  They can be used, however, if
they are used to be posted to (GET/POST).

- integrating many back-end, non-changeable systems.  Examples are large
Enterprise applications that have a plethora of services from a wide-range
of teams, the majority written in some form of Java.  Equipping a team of
JSP programmers with Flex, creating hundreds of forms that are bindable to
the back-end, and replacing the non-stateful JSP's with a stateful Flex
client empowers a lot of powerful simplification.  Instead of various JSP,
HTML, DHTML, applets, and other various client implementations, you can
somewhat standardize the client tier to use Flex, but still keep the same
back-end services, with or without re-factoring them to expose certian
methods.  With Remoting (binary vs. XML string), this will decrease the
overall bandwidth.

- web service realization.  Just about any webservice out there begs to be
used by Flex.  The SOA revolution has the most impeccable timing since Flex
can utilize WebServices just as easily as back-end Java, .NET, ColdFusion,
and PHP systems.  eBay, Amamazon, Google, and Flick & Yahoo! ecspecially all
have wonderful API's that work extremely well with visualization ideas
realized in Flex & Flash hybrids.  While Flex is built on the Flash Player,
Flash would allow you really eximply the creative, and more intuitive &
responsive ways to show a plethora of data, while Flex makes it really easy
to speak to the server in a natural, programmatic way.  Granted, you put
together some really intuitive & dynamic interfaces in Flex, but my money is
on getting a talented team of designers & infromation architectects,
implementing some design elements in Flash, and authoring it all in Flex.

Yahoo! Maps for example.  Not only well executed, but developers & designers
can join in on the fun!

- niche internet connected components.  Not sure what blog coined that
phrase, but basically, some things are more approrpriate in HTML for
skilllset reasons, legacy software, or for time constraints.  As such,
because Flex is just a SWF, and can be treated as an embedable object, it
serves well for smaller, niche purposes as well by being integrated into
larger systems.  Example is MXNA's (Macromedia's blog aggregator) where they
show your post popularity with an extremely interactive graph.

http://weblogs.macromedia.com/mxna/reports/feedReport/index.cfm?feedId=139&feedN\
ame=jester%20%28jessewarden%2Ecom%29

Since drag and drop is easy in Flash, I developed a question builder for an
existing CMS built in HTML & .NET; it integrated nicely, and we spoke via
POSTS to .NET.  Pretty simple concept, and saved them tons of time
developing drag and drop in HTML, and the user ended up winning.

Some of the real-time polls done in Flex & Flash are various Macromedia
employee & ColdFusion weblogs are pretty schweet too.

- branding.  While arguably esoteric, and subjective, I strongly beleive
bringing a company's brand to a user's client, OR retaining it on a company
intranet, can best be done using Flex and Flash together.  Ironically, the
downfall of Macromedia's Desktop forray, Central, was because they
themselves, Macromedia, impressed their brand onto people looking to
represent their companies.  Unfortunately, Macromedia won, and Central died
because of it.  USA Today had a pretty neat forray, but an EXTREMELY niche
case.

Bottom line, while I've seen some very impressive HTML designs, I still
believe if you want to shove a brand, in all it's accuracy, in a consumer's
face, Flex & Flash is the way to go.  Reason being, Sparkle isn't out yet,
hehe!  While PC games prove one can create beautiful client interfaces, they
don't run in the browser, and while Flash Player and XMLHttpRequest are both
ActiveX controls, both have extremely high-install penetration ratios, so
ensuring a client's brand can be seen is a lot.  People argue this could
comprimise usability when a brand's agenda gets in the way, and I'm not here
to argue that, but I do question if you are here to make money, or are on
some crusade to spread good practices.  Me?  To make a living.

- Give Java developers a client that doesn't suck.  JSP developers now have
a familiar paradigm of development with a client that looks awesome with
little design investment.  Oh yeah, did we mention it's stateful?

- intranet portals.  This one is weird; mainly in that I never thought to
use the technology this way, and curse myself for the lack of foresight.
There are a lot of intranet applications that have millions of dollars
pumped into them to ensure they are made, even if they are never used.
Regardless of their nebolous outcomes, the bottom line is, that money pie
can be shared if you pitch yourself right.  As such, HR Portals, and other
departmental information tools work very well in Flex.  I've seen/heard of
some developing projects where either existing portals are to be converted
or switched over.  While I'd actually argue for AJAX here, SOME have just
enough CRUD opertaions of admins needing to see and update data, that I
could see Flex working great.

- skinnable interfaces.  While both Flash & Flex can do this, and I think
it's a stupid feature that is the 20% of the 80/20 rule, it can be done, and
helps sell applications, even if it's a pointless endeavor.

- SAP now has Flex embedded.  All the insanely large apps written with SAP
now have an awesome potential front-end.

What isn't for Flex:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- eLearning.  While I've recently seen a pretty thoroughly developed, and
large in scope Flex site that had serious amounts of eLearning, I really
didn't see the point of Flex other than "developers don't know Captivate,
Flash, Camtasia, nor care too and want to deploy on the server."  Um, ok.

- CD-ROM's, Occasionally Connected Clients, mobile devices.  CD-ROMs are
better done with Director or Flash; Flex, at least in 1.5, has a server
requirement, and most of those projects do not have the scope of code that
most Flex projects do.  Additionally, the level of design control & branding
on those projects is heavyily in need of a tool like Flash with it's design
power (intergrating designs, video, and other various multimedia).  While
Flex can use said content, it can't easily create & control it during
authorign like Director & Flash can.  Director also supports older systems
with less system resources, as well as more capability to support thousands
of design assets both at authortime and runtime without crashing your
system.  Flash & Flex do not really have asset memory management at runtime,
and Director does.

Flex 1.5 suffers from a liencesing issue where most occasionally connected
clients don't work; you need a server for Flex, and while Central kind of
counts, no one develops for Central.  While Flex on the desktop has promise
in 2:
http://dev.jessewarden.com/captivate/flexonthedesktop/

... it just doesn't have the API for it either without a 3rd party
application to wrap the SWF & EXE.

Mobile devices, even with the advent of Flash Player 7 'esque for Deuce
(Flash Lite 2), don't really fit the Flex model.  Meaning the Flex framework
wasn't designed to run on a mobile device, whereas Flash the IDE and Flash
Lite the runtime were.  Someday...... but not today or tomorrow.

- websites.  I've seen 2 websites done in Flex that made no sense at all for
technology.  The defense was that the large, non-publicly facing CMS that
ran it was in Flex, but to me that's a pathetic excuse.  This is where
giving Java developers a client that doesn't suck backfires.

If HTML, or even AJAX is appropriate, cool, but don't use web application
software to create a web site.

- games.  One could argue that many games are easy to create in Flex.  While
I would agree, most games that actually sell are done in Flash or Java.

What is for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- games, ecspecially with Flash Player 8 and 8.5 since they both have
blitting support, you can use double-buffering to get some seriously well
performing games.  Java used to win in this arena, but not anymore.  It goes
without saying that Flash allows you to create anything the crazy design
team comes up with and can look and work however you want.  Supporting
sound, video, and other effects most gamers are used to, the world is your
oyester now.

- CD-ROMs.  While Director still contents highly in this sphere, Flash
allows teams of designers to work together more easily with authorers than
Director did.  With improved video support, Flash is overtaking this
market... at least, all the CD-ROM's I've seen.

- Occasionally Connected Clients.  More so, it's best when wrapped in a 3rd
party projector, custom C wrapper, or something that gives it more access to
the local OS.  While Flash itself can easily talk asyncronously to any
back-end system, it's security model is for the web, not for the desktop, so
you need something to help those weaknesses.  Since Flash is stateful, it's
really easy to save local data, and connect to the web and update data when
you have a connection.  This is why a lot are seeing success with mobile
development in Japan and other parts of Asia.

- level branding control that Flex & HTML can't do

- sound control; you already knew that!

- Collaborative Applications.  Until Flex Enterprise Services show us what
they are, if you need video chat, audio chat, text chat, and/or multiplay
games, Flash using XMLSocket, Flash Communication Server, or the new binary
sockets in Flash Player 8.5, this is the way to go.

- like Flex, drag and drop on the web.  I've seen some impressive stuff with
DHTML, but more with Flash.  I think the Flex developers forget it's there
or don't know how to use the API... or just don't know what to do with drag
and drop now that they have it.

- eLearning.  While Captivate holds it's own, I still think all the custom
solutions I've written in Flash are better for solve "service needs".

- video on the web.  This goes with branding, but you now suddenly have a
player that's at 90% penetration, linux included (Flash Player 7)... and it
doesn't have to be a frikin' square on the page or in a new window, nor come
with pre-fabbed radio buttons to "select your bandwidth".

- writing extensions for Breeze.  This was talked about, but never really
elaborated upon by Peldi, nor Nigel.  Basically, it seems you can write your
own Pods for Breeze, but not really sure where this stands.

- fighting blogspam.  I implemented a Flash comment form on my site.  Since
blog spamming is typically done with bots, they merely post the required
form variables to the the server-side script, bypassing the web form.
Captcha, however, stops them dead in their tracks. My Perl Captcha plugin
for MoveableType however didn't install correctly... 300 comments an hour
with my webhost calling my cell on what CGI file to rename.  I merely made a
hidden field in Flash (like a hidden field in HTML).  Since spambots don't
know how to screen scrape the internals of a SWF, they failed to post the
correct hidden form variable that the SWF has hardcoded internally.  Been
blogpsam free from bots for over a year now, since they day I implemented
it.

What isn't for Flash:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

- web sites.  While clients to this day still pay for it, it's ridicolous,
and kills usability.  Contrary to popular beleif, there are a multitude of
ways to get Flash sites into search engines, but unless it's for movie
sites, or artists showing portfolios, I've yet to see a good use case beyond
those 2.  Flash elements?  Sure, but only for video, or interactive product
demos.  Navigation, blocks of text, and other navigational aides, ...nope.

- targetting older systems.  Director owns here, specially with Flash Player
8 not supporting older OS's, and STILL not supporting a Linux version.

- web widgets.  While I've seen some pretty neat use of web widgets, like
the polls I've mentioned earlier, some are just too simple to justify.
Like, a mini-blog reader is neat... but why not use AJAX instead?  The line
gets REALLY fine here, but I usuallly know in my gut what is and isn't
appropriate.  Some designs lend themselves to just using DHML, while others
couldn't be done without Flash.  The majority I've seen, however, are more
appropriate in DHTML or a server-side HTML rendered way.

- Enterprise applications.  Can it be done?  Sure, but after you've
developed in Flash for awhile, and then started to develop in Flex, it all
becomes clear.  The weeeks spent writing just GUI code turns into days.
Not to mention the fact, the components in Flex are more mature.  ASCII MXML
files work better in version control than binary FLA's do.  You can't diff a
FLA accurately; what's the point?  You thus poison builds early on by FLA
changes, and sharing FLA's amongst developers sucks.  "Hey man, can I borrow
the fla?"  "Did you change my components GUI?"  ... f'ing nightmare.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

For everything else, I'd say AJAX.  Most of the so called "Web 2.0" sites
I've seen are really just extremely well designed and executed websites.
They are just updating parts of the sites that really don't require the
whole page to, like Google Adsense's login, or Flickr's picture comments.
To me, those are extremely awesome & needed uses of AJAX.  With HTML's
native text & hyperlinking abilities, it's really hard to lose.

It goes without saying that if your team is good at web skills, find a way
to make AJAX work unless you really are stretching; same goes with Flash &
Flex.  I would argue, however, JSP developers really should think about
investing some time learning Flex.

...Laszlo... hrm... gonna be a technology bigot here.  While there are
exceptions to every stereotype, and Pandora.com really rocks as an app, and
is a great example of what Laszlo can do... screw Laszlo.  It's based on
older versions of the Flash Player, uses JavaScript which is a prototype
based language which doesn't compare to the class based, strong typing of
ActionScript 2 & 3 that developers respect & come to expect, and is based on
JGenerator, an antiquated server technology.  I've heard of niche casses for
it, like supported legacy apps that need to have lower versions of the Flash
Player because of red tape, but that's a cop-out.   Eeither you are
innovative or you aren't.  Either you're trying to push the evelope, or you
aren't.  Using Open Source as a selling point is lame.  You get what you pay
for.

Hope that gives you some info!














----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 2:07 PM
Subject: Re: [ajax_and_ria] Flash / AJAX decision making


Yes, for sure! Consider the possibility of using Flex 2 (or even
third-party frameworks like Laszlo).
-Jon

At 11:02 AM 11/17/2005, JesterXL wrote:
>Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted my
>career
>this year to focus on Flex more so than Flash development.  Granted, I use
>both in tandem, but I think Flex is more appropriate for many applications
>previously used for Flash.
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 1:37 PM
>Subject: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hey everybody!
>
>I'm working on a white paper that looks at when to use Flash vs. when
>to use AJAX.
>
>I'd love to hear what people in this group have to say. I really
>think it's possible to scope out situations where Flash is the only
>viable option, and other situations where using Flash just doesn't
>make any sense (and AJAX makes more sense). But I'm having trouble
>articulating this.
>
>Macromedia people: What's your take on this? What's the "sweet spot"
>for Flash, and where does AJAX make more sense?
>
>AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>would you use Flash instead?
>
>Few people are equally proficient in both technologies, and that
>factors into the decision process as well. So for the purposes of the
>question, imagine you're the manager of a crew that is good with both
>technologies.
>
>I have my own ideas as well, but I don't want to shape this
>discussion at the outset. Once we get the ball rolling I'll surely
>chime in. ;->
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^





Yahoo! Groups Links

Yes, for sure! Consider the possibility of using Flex 2 (or even
third-party frameworks like Laszlo).
-Jon

At 11:02 AM 11/17/2005, JesterXL wrote:
>Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted my career
>this year to focus on Flex more so than Flash development.  Granted, I use
>both in tandem, but I think Flex is more appropriate for many applications
>previously used for Flash.
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Thursday, November 17, 2005 1:37 PM
>Subject: [ajax_and_ria] Flash / AJAX decision making
>
>
>Hey everybody!
>
>I'm working on a white paper that looks at when to use Flash vs. when
>to use AJAX.
>
>I'd love to hear what people in this group have to say. I really
>think it's possible to scope out situations where Flash is the only
>viable option, and other situations where using Flash just doesn't
>make any sense (and AJAX makes more sense). But I'm having trouble
>articulating this.
>
>Macromedia people: What's your take on this? What's the "sweet spot"
>for Flash, and where does AJAX make more sense?
>
>AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
>would you use Flash instead?
>
>Few people are equally proficient in both technologies, and that
>factors into the decision process as well. So for the purposes of the
>question, imagine you're the manager of a crew that is good with both
>technologies.
>
>I have my own ideas as well, but I don't want to shape this
>discussion at the outset. Once we get the ball rolling I'll surely
>chime in. ;->
>
>----^-------^------^--------^-------^
>Jon Boutelle
>Principal, Uzanto Consulting
>Mountain View, CA
>
>Office Phone:650-564-0000
>Cell Phone   :510-708-9825
>skype id: jboutelle
>www.uzanto.com
>www.jonathanboutelle.com
>----^-------^------^--------^-------^
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

Are you factoring in Flex 1.5 and 2 at all?  I've recently shifted my career
this year to focus on Flex more so than Flash development.  Granted, I use
both in tandem, but I think Flex is more appropriate for many applications
previously used for Flash.

----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Thursday, November 17, 2005 1:37 PM
Subject: [ajax_and_ria] Flash / AJAX decision making


Hey everybody!

I'm working on a white paper that looks at when to use Flash vs. when
to use AJAX.

I'd love to hear what people in this group have to say. I really
think it's possible to scope out situations where Flash is the only
viable option, and other situations where using Flash just doesn't
make any sense (and AJAX makes more sense). But I'm having trouble
articulating this.

Macromedia people: What's your take on this? What's the "sweet spot"
for Flash, and where does AJAX make more sense?

AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
would you use Flash instead?

Few people are equally proficient in both technologies, and that
factors into the decision process as well. So for the purposes of the
question, imagine you're the manager of a crew that is good with both
technologies.

I have my own ideas as well, but I don't want to shape this
discussion at the outset. Once we get the ball rolling I'll surely
chime in. ;->

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^





Yahoo! Groups Links

Hey everybody!

I'm working on a white paper that looks at when to use Flash vs. when
to use AJAX.

I'd love to hear what people in this group have to say. I really
think it's possible to scope out situations where Flash is the only
viable option, and other situations where using Flash just doesn't
make any sense (and AJAX makes more sense). But I'm having trouble
articulating this.

Macromedia people: What's your take on this? What's the "sweet spot"
for Flash, and where does AJAX make more sense?

AJAX toolkit vendors: What's the "sweet spot" for AJAX? And when
would you use Flash instead?

Few people are equally proficient in both technologies, and that
factors into the decision process as well. So for the purposes of the
question, imagine you're the manager of a crew that is good with both
technologies.

I have my own ideas as well, but I don't want to shape this
discussion at the outset. Once we get the ball rolling I'll surely
chime in. ;->

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

Ah, a she, cool, thanks for the correction.

Long article... this'll take awhile.

----- Original Message -----
From: "Dave Heller" <dheller@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Friday, November 11, 2005 1:48 PM
Subject: Re: [ajax_and_ria] Interesting presentation regarding making usable
RIAs


Hi there,

first off, Donna is a she ... just a clarification.

Now to your subject about "desktop" applications.

I have known to say that there are few affordances that hold true in
software. To me too few users have used and communicated what is
available today to have created an "archetype" of cultural thinking so
that by just looking at an object we know what to do with it.

That being said, there are some who have said otherwise. Especially of
the Jakob Neilsen variety who profess that the web offers standards
that are quite ingrained. The 2 that I will give him site true to me
b/c they have been entered into the non-web world on the 2 major OSes
and a host of applications:
1. underline = link
Of course this really messes w/ he bibliography requirements according
the APA and MLA, but that is a different problem.

2. back button use

I have posted an article on my blog here that I think addresses the
2nd question. The first one I am not so scared of b/c it does not
directly deal w/ AJAX (which is the center of my article) but more
other RIAs which make underlining annoying, like Flash.

The article can be found at
http://synapticburn.com/comments.php?id=97_0_1_0_C

Enjoy!

-- dave




On 11/11/05, JesterXL <jesterxl@...> wrote:
>  Hey, thanks for the link!
>
>  I really liked his suggestions.  I know it's not as powerful without the
>  accompanying podcast, but I get the gist and dig what says.
>
>  I disagree with what he says about guidelines, though.  Which is vacous
>  because his preso says it without the context of what he actually,
>  physically said.  Bottom line, rich apps, to me, mirror plenty of common
>  desktop application usability paradigms.  If you follow those, the user
>  forgets about the backbutton; they only care when you break it.  And, you
>  can book mark state.
>
>  Good stuff; can't wait for the Podcast.
>
>
>  ----- Original Message -----
>  From: "Dave Heller" <dheller@...>
>  To: <ajax_and_ria@yahoogroups.com>
>  Sent: Friday, November 11, 2005 1:10 PM
>  Subject: [ajax_and_ria] Interesting presentation regarding making usable
>  RIAs
>
>
>  http://www.maadmob.net/donna/blog/archives/000661.html
>
>  Donna Maurer gives a great presentation about easy to think about
>  quick ways to get through some of the biggest issues of keeping rich
>  apps usable
>
>  -- dave
>
>
>
>
>  Yahoo! Groups Links
>
>
>
>
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "ajax_and_ria" on the web.
>
>  To unsubscribe from this group, send an email to:
>  ajax_and_ria-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>


--
David Heller
E: dheller (at) gmail (dot) com
W: www (dot) synapticburn (dot) com




Yahoo! Groups Links

Hi there,

first off, Donna is a she ... just a clarification.

Now to your subject about "desktop" applications.

I have known to say that there are few affordances that hold true in
software. To me too few users have used and communicated what is
available today to have created an "archetype" of cultural thinking so
that by just looking at an object we know what to do with it.

That being said, there are some who have said otherwise. Especially of
the Jakob Neilsen variety who profess that the web offers standards
that are quite ingrained. The 2 that I will give him site true to me
b/c they have been entered into the non-web world on the 2 major OSes
and a host of applications:
1. underline = link
Of course this really messes w/ he bibliography requirements according
the APA and MLA, but that is a different problem.

2. back button use

I have posted an article on my blog here that I think addresses the
2nd question. The first one I am not so scared of b/c it does not
directly deal w/ AJAX (which is the center of my article) but more
other RIAs which make underlining annoying, like Flash.

The article can be found at http://synapticburn.com/comments.php?id=97_0_1_0_C

Enjoy!

-- dave




On 11/11/05, JesterXL <jesterxl@...> wrote:
>  Hey, thanks for the link!
>
>  I really liked his suggestions.  I know it's not as powerful without the
>  accompanying podcast, but I get the gist and dig what says.
>
>  I disagree with what he says about guidelines, though.  Which is vacous
>  because his preso says it without the context of what he actually,
>  physically said.  Bottom line, rich apps, to me, mirror plenty of common
>  desktop application usability paradigms.  If you follow those, the user
>  forgets about the backbutton; they only care when you break it.  And, you
>  can book mark state.
>
>  Good stuff; can't wait for the Podcast.
>
>
>  ----- Original Message -----
>  From: "Dave Heller" <dheller@...>
>  To: <ajax_and_ria@yahoogroups.com>
>  Sent: Friday, November 11, 2005 1:10 PM
>  Subject: [ajax_and_ria] Interesting presentation regarding making usable
>  RIAs
>
>
>  http://www.maadmob.net/donna/blog/archives/000661.html
>
>  Donna Maurer gives a great presentation about easy to think about
>  quick ways to get through some of the biggest issues of keeping rich
>  apps usable
>
>  -- dave
>
>
>
>
>  Yahoo! Groups Links
>
>
>
>
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "ajax_and_ria" on the web.
>
>  To unsubscribe from this group, send an email to:
>  ajax_and_ria-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>


--
David Heller
E: dheller (at) gmail (dot) com
W: www (dot) synapticburn (dot) com

Hey, thanks for the link!

I really liked his suggestions.  I know it's not as powerful without the
accompanying podcast, but I get the gist and dig what says.

I disagree with what he says about guidelines, though.  Which is vacous
because his preso says it without the context of what he actually,
physically said.  Bottom line, rich apps, to me, mirror plenty of common
desktop application usability paradigms.  If you follow those, the user
forgets about the backbutton; they only care when you break it.  And, you
can book mark state.

Good stuff; can't wait for the Podcast.

----- Original Message -----
From: "Dave Heller" <dheller@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Friday, November 11, 2005 1:10 PM
Subject: [ajax_and_ria] Interesting presentation regarding making usable
RIAs


http://www.maadmob.net/donna/blog/archives/000661.html

Donna Maurer gives a great presentation about easy to think about
quick ways to get through some of the biggest issues of keeping rich
apps usable

-- dave




Yahoo! Groups Links

Veerendra,

Nice stuff!

On the Amazon app, I think it's a mistake to start with the tree
completely closed (unless you are displaying other stores as well).
Start with the first level open, so that it's more discoverable.

Your prefetching algorithm (get the 1st 2 levels in initial load, get
lower levels synchronously) isn't bad at all. Could I suggest
prefetching the third level when the 2nd level gets opened? That
would reduce latency a lot, and probably wouldn't increase network
traffic that much. The topic of how to tune the prefetching of a
tree-view is probably of general interest. If you start playing with
it let me know what you find!

Some of my thoughts on predictive downloading
http://www.jonathanboutelle.com/mt/archives/2005/03/rocket_science.html
http://www.jonathanboutelle.com/mt/archives/2004/08/latency_must_di.html

Regards,
-Jon



At 09:55 AM 11/11/2005, you wrote:
>My name is Veerendra Shivhare and I work as a
>software professional in bangalore (india).
>
>I have made a small one page application which I
>will like to share with you and get your
>valuable thoughts/comments on this.
>
>I modified JS Cook Tree to make it use AJAX,
>support n level hierarchy. I used this to Display
>Amazon Catalogue in a new "innovative" way.
>URL :- http://lmap.co.nr/Amazon1.htm
>
>In the tree, one can browse amazon catalogues based
>on the browse id. On reaching the item level (marked
>with red dots) one can click on it to view details
>such as price, image etc.
>
>I made a small app which searches for locations
>in india. I used AJAX with google maps to make this.
>URL :- http://www.lmap.co.nr
>
>Waiting for your feedback.
>
>Regards,
>Veerendra Shivhare
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

http://www.maadmob.net/donna/blog/archives/000661.html

Donna Maurer gives a great presentation about easy to think about
quick ways to get through some of the biggest issues of keeping rich
apps usable

-- dave

My name is Veerendra Shivhare and I work as a
software professional in bangalore (india).

I have made a small one page application which I
will like to share with you and get your
valuable thoughts/comments on this.

I modified JS Cook Tree to make it use AJAX,
support n level hierarchy. I used this to Display
Amazon Catalogue in a new "innovative" way.
URL :- http://lmap.co.nr/Amazon1.htm

In the tree, one can browse amazon catalogues based
on the browse id. On reaching the item level (marked
with red dots) one can click on it to view details
such as price, image etc.

I made a small app which searches for locations
in india. I used AJAX with google maps to make this.
URL :- http://www.lmap.co.nr

Waiting for your feedback.

Regards,
Veerendra Shivhare

JOB TITLE:  AJAX Innovator

LOCATION:  Mountain View, CA

DESCRIPTION:

Want to transform the world of search?  We are seeking a highly-motivated software developer to lead web applications development.  The ideal candidate is an enthusiastic and entrepreneurial software engineer with startup experience who feels passionately about making software highly usable.  You would feel right at home with us if you believe creating great web applications requires "getting into the mind and heart of the user".

Headquartered in Mountain View, we are privately held and VC-backed.

REQUIRED TECHNICAL EXPERIENCE:

* Java Servlet/JSP or equivalent

* Web application experience (HTML, AJAX, DHTML, JavaScript, JSP)

* Relational database experience (MySQL, Oracle, SQL Server, Postgres SQL, DB2)

* Persistence layer experience (e.g. Hibernate)

* Human Computer Interaction (HCI)

* Full product lifecycle

* Natural Language Processing (NLP) and/or Search experience a plus

QUALIFICATIONS:

* BS or higher in Computer Science

* 3-5 years of software engineering experience

* Outstanding communication and teamwork skills

* Passion for broad areas of science, technology, and innovation

* Startup experience

* High degree of integrity, passion and drive

Send resume and cover letter to jobs@... with subject line "AJAX Innovator".  US work authorization required.

KEYWORDS:

o Web Applications Engineer, Web Application Developer, Java Developer

o Human Computer Interaction (HCI)

o Search Engine / Search Engines

o Internet Search

o Software Developer

o User Interface

Hi Jon,

The professional edition is $799/logical CPU with standard support and
$899/logical CPU with extended support.

Both support packages included email-based support and upgrades for 1
year. Extended support is available 24 x 7 with phone contact for
severity 1 issues, the standard support is 8-5 CST.

thanks,
Joe

Jonathan Boutelle wrote:

> Joe,
>
> Thanks for the quick response!
>
> Seems like you guys are segmenting the market
> between enterprise and small-fry, much the way
> Macromedia has now done with FLEX. A good move.
>
> The standard edition is free, right? The professional edition is how much?
> Regards,
> -Jon
>
>
>
>
> At 02:42 PM 10/27/2005, you wrote:
> >Hi guys,
> >
> >Neither FlashORB nor WebORB never used any of the GPL'd code, so it is
> >definitely not the reason why we offered a free edition of the product.
> >
> >Where things stand today, we have a a standard edition for both Java and
> >.NET environments. You can download and generate a license for the
> >standard edition right from our website. The standard edition supports
> >both Flash Remoting and AJAX clients. The Professional edition has 2
> >modes: licensed (where license key is present) and unlicensed (without a
> >license key). The latter forces the product to switch into the
> >'Development Mode' where only 1 IP address is allowed. That can be reset
> >when product restarts.
> >You can see the comparison between Standard and Professional at:
> >http://www.themidnightcoders.com/doc20/?t=5
> >
> >Btw, one of the features we added to professional edition is WebORB
> >Message Server. You can see an example of the message server in action
> >here:
> >http://www.themidnightcoders.net/examples/messageserver/chat/mapchatajax.htm
> >
> >Please let me know if you have any questions about the product or
> licensing.
> >
> >cheers,
> >Joe
> >
> >Julian Suggate wrote:
> >
> > > Hi Jonathon,
> > >
> > > From what I remember from FlashOrb (don't quote me on this) the Java
> > > version is free because TMC have used some GPL'd code in their
> > > implementation. The .NET version of FlashOrb most definitely was NOT
> > > free for production purposes. Single IP limitation without a license.
> > > Licenses were priced per logical CPU last I checked.
> > >
> > > WebOrb may be different though.
> > >
> > > There was a rep from TMC lurking around on this list at one stage,
> > > perhaps they're listening? Try tech support if you're still unsure.
> > >
> > > Jules
> > >
> > > On 10/28/05, *Jonathan Boutelle* <jon@...
> > > <mailto:jon@...>> wrote:
> > >
> > >     http://www.themidnightcoders.com/index.htm
> > >
> > >     The midnight coders have released an interesting
> > >     presentation server / rich client toolkit called
> > >     WebORB. This seems like an ambitious project,
> > >     aimed at solving the problems of rich ui
> > >     development by blending Flash and AJAX
> > >     technologies in innovative ways (just as one
> > >     example, they seem to be planning to support sockets by using
> > >     flashcom server).
> > >
> > >     They still have a lot of work to do. From their site:
> > >         * Communication Stack ­
> > >         * Data binding module ­
> > >         * Dynamic rich user interface widgets (available in a future
> > >     release)
> > >         * Event system (available in a future release
> > >         * Drag-and-drop (available in a future release
> > >         * Interactive messaging client (available in a future
> release)-
> > >     I'm also not too clear on licencing terms for WebORB. The
> website says
> > >     The Standard Edition is free for most commercial
> > >     uses (see explanation
> > >     <http://groups.yahoo.com/group/flashorb/message/146>here).
> > >     It does not have any technical limitations
> > >     (connection limits or expiration dates) and
> > >     provides AJAX support in both Java and .NET
> > >     editions of the product and full Flash Remoting
> > >     implementation in the Java edition of the product.
> > >
> > >     The link goes to a yahoo group that I have no
> > >     inclination to join. Anyone know what the deal is?
> > >
> > >     Does anyone generally have any experience with
> > >     WebORB/Rich Client System they'd like to share?
> > >
> > >     Regards,
> > >
> > >     ----^-------^------^--------^-------^
> > >     Jon Boutelle
> > >     Principal, Uzanto Consulting
> > >     Mountain View, CA
> > >
> > >     Office Phone:650-564-0000
> > >     Cell Phone   :510-708-9825
> > >     skype id: jboutelle
> > >     www.uzanto.com <http://www.uzanto.com>
> > >     www.jonathanboutelle.com <http://www.jonathanboutelle.com>
> > >     ----^-------^------^--------^-------^
> > >
> > >
> > >
> > >     SPONSORED LINKS
> > >     Design patent
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+patent&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=nzt4vhrCYsiJfZ49a2PoVQ
>
<http://groups.yahoo.com/gads?t=ms&k=Design+patent&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=nzt4vhrCYsiJfZ49a2PoVQ>>
> > >       Design school
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+school&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=R4Ow0YiVxLTWY0mOJwIhEQ
>
<http://groups.yahoo.com/gads?t=ms&k=Design+school&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=R4Ow0YiVxLTWY0mOJwIhEQ>>
> > >       Design schools
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+schools&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=hkyvnHAsvWLY5PnX-Skt5A
>
<http://groups.yahoo.com/gads?t=ms&k=Design+schools&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=hkyvnHAsvWLY5PnX-Skt5A>>
> > >
> > >     Design auto dealer web site
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+auto+dealer+web+site&w1=Design+paten\
t&w2=Design+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+d\
esign&w6=Design+for+six+sigma&c=6&s=137&.sig=1HQ5zlE_gIO4juvfxo-vJw
>
<http://groups.yahoo.com/gads?t=ms&k=Design+auto+dealer+web+site&w1=Design+paten\
t&w2=Design+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+d\
esign&w6=Design+for+six+sigma&c=6&s=137&.sig=1HQ5zlE_gIO4juvfxo-vJw>>
> > >       Network design
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Network+design&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=tnLOKn2I0XV-9gXE7bESRg
>
<http://groups.yahoo.com/gads?t=ms&k=Network+design&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=tnLOKn2I0XV-9gXE7bESRg>>
> > >       Design for six sigma
> > >
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+for+six+sigma&w1=Design+patent&w2=De\
sign+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w\
6=Design+for+six+sigma&c=6&s=137&.sig=94rpamLskobjP78ckIk6JA
>
<http://groups.yahoo.com/gads?t=ms&k=Design+for+six+sigma&w1=Design+patent&w2=De\
sign+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w\
6=Design+for+six+sigma&c=6&s=137&.sig=94rpamLskobjP78ckIk6JA>>
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >     YAHOO! GROUPS LINKS
> > >
> > >         *  Visit your group "ajax_and_ria
> > >           <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
> > >
> > >         *  To unsubscribe from this group, send an email to:
> > >             ajax_and_ria-unsubscribe@yahoogroups.com
> > >
> > <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> > >
> > >         *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > >           Service <http://docs.yahoo.com/info/terms/>.
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > YAHOO! GROUPS LINKS
> > >
> > >     *  Visit your group "ajax_and_ria
> > >       <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
> > >
> > >     *  To unsubscribe from this group, send an email to:
> > >        ajax_and_ria-unsubscribe@yahoogroups.com
> > >
> <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> > >
> > >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > >       Service <http://docs.yahoo.com/info/terms/>.
> > >
> > >
> > >
> ------------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
> ----^-------^------^--------^-------^
> Jon Boutelle
> Principal, Uzanto Consulting
> Mountain View, CA
>
> Office Phone:650-564-0000
> Cell Phone   :510-708-9825
> skype id: jboutelle
> www.uzanto.com
> www.jonathanboutelle.com
> ----^-------^------^--------^-------^
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "ajax_and_ria
>       <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ajax_and_ria-unsubscribe@yahoogroups.com
>       <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Joe,

Thanks for the quick response!

Seems like you guys are segmenting the market
between enterprise and small-fry, much the way
Macromedia has now done with FLEX. A good move.

The standard edition is free, right? The professional edition is how much?
Regards,
-Jon




At 02:42 PM 10/27/2005, you wrote:
>Hi guys,
>
>Neither FlashORB nor WebORB never used any of the GPL'd code, so it is
>definitely not the reason why we offered a free edition of the product.
>
>Where things stand today, we have a a standard edition for both Java and
>.NET environments. You can download and generate a license for the
>standard edition right from our website. The standard edition supports
>both Flash Remoting and AJAX clients. The Professional edition has 2
>modes: licensed (where license key is present) and unlicensed (without a
>license key). The latter forces the product to switch into the
>'Development Mode' where only 1 IP address is allowed. That can be reset
>when product restarts.
>You can see the comparison between Standard and Professional at:
>http://www.themidnightcoders.com/doc20/?t=5
>
>Btw, one of the features we added to professional edition is WebORB
>Message Server. You can see an example of the message server in action
>here:
>http://www.themidnightcoders.net/examples/messageserver/chat/mapchatajax.htm
>
>Please let me know if you have any questions about the product or licensing.
>
>cheers,
>Joe
>
>Julian Suggate wrote:
>
> > Hi Jonathon,
> >
> > From what I remember from FlashOrb (don't quote me on this) the Java
> > version is free because TMC have used some GPL'd code in their
> > implementation. The .NET version of FlashOrb most definitely was NOT
> > free for production purposes. Single IP limitation without a license.
> > Licenses were priced per logical CPU last I checked.
> >
> > WebOrb may be different though.
> >
> > There was a rep from TMC lurking around on this list at one stage,
> > perhaps they're listening? Try tech support if you're still unsure.
> >
> > Jules
> >
> > On 10/28/05, *Jonathan Boutelle* <jon@...
> > <mailto:jon@...>> wrote:
> >
> >     http://www.themidnightcoders.com/index.htm
> >
> >     The midnight coders have released an interesting
> >     presentation server / rich client toolkit called
> >     WebORB. This seems like an ambitious project,
> >     aimed at solving the problems of rich ui
> >     development by blending Flash and AJAX
> >     technologies in innovative ways (just as one
> >     example, they seem to be planning to support sockets by using
> >     flashcom server).
> >
> >     They still have a lot of work to do. From their site:
> >         * Communication Stack ­
> >         * Data binding module ­
> >         * Dynamic rich user interface widgets (available in a future
> >     release)
> >         * Event system (available in a future release
> >         * Drag-and-drop (available in a future release
> >         * Interactive messaging client (available in a future release)-
> >     I'm also not too clear on licencing terms for WebORB. The website says
> >     The Standard Edition is free for most commercial
> >     uses (see explanation
> >     <http://groups.yahoo.com/group/flashorb/message/146>here).
> >     It does not have any technical limitations
> >     (connection limits or expiration dates) and
> >     provides AJAX support in both Java and .NET
> >     editions of the product and full Flash Remoting
> >     implementation in the Java edition of the product.
> >
> >     The link goes to a yahoo group that I have no
> >     inclination to join. Anyone know what the deal is?
> >
> >     Does anyone generally have any experience with
> >     WebORB/Rich Client System they'd like to share?
> >
> >     Regards,
> >
> >     ----^-------^------^--------^-------^
> >     Jon Boutelle
> >     Principal, Uzanto Consulting
> >     Mountain View, CA
> >
> >     Office Phone:650-564-0000
> >     Cell Phone   :510-708-9825
> >     skype id: jboutelle
> >     www.uzanto.com <http://www.uzanto.com>
> >     www.jonathanboutelle.com <http://www.jonathanboutelle.com>
> >     ----^-------^------^--------^-------^
> >
> >
> >
> >     SPONSORED LINKS
> >     Design patent
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+patent&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=nzt4vhrCYsiJfZ49a2PoVQ>
> >       Design school
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+school&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=R4Ow0YiVxLTWY0mOJwIhEQ>
> >       Design schools
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+schools&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=hkyvnHAsvWLY5PnX-Skt5A>
> >
> >     Design auto dealer web site
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+auto+dealer+web+site&w1=Design+paten\
t&w2=Design+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+d\
esign&w6=Design+for+six+sigma&c=6&s=137&.sig=1HQ5zlE_gIO4juvfxo-vJw>
> >       Network design
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Network+design&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=tnLOKn2I0XV-9gXE7bESRg>
> >       Design for six sigma
> >
>
<http://groups.yahoo.com/gads?t=ms&k=Design+for+six+sigma&w1=Design+patent&w2=De\
sign+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w\
6=Design+for+six+sigma&c=6&s=137&.sig=94rpamLskobjP78ckIk6JA>
> >
> >
> >
> >
> ------------------------------------------------------------------------
> >     YAHOO! GROUPS LINKS
> >
> >         *  Visit your group "ajax_and_ria
> >           <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
> >
> >         *  To unsubscribe from this group, send an email to:
> >             ajax_and_ria-unsubscribe@yahoogroups.com
> >
> <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >
> >         *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >           Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> >
> ------------------------------------------------------------------------
> >
> >
> >
> > ------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "ajax_and_ria
> >       <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
> >
> >     *  To unsubscribe from this group, send an email to:
> >        ajax_and_ria-unsubscribe@yahoogroups.com
> >       <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------------
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

----^-------^------^--------^-------^
Jon Boutelle
Principal, Uzanto Consulting
Mountain View, CA

Office Phone:650-564-0000
Cell Phone   :510-708-9825
skype id: jboutelle
www.uzanto.com
www.jonathanboutelle.com
----^-------^------^--------^-------^

Hi guys,

Neither FlashORB nor WebORB never used any of the GPL'd code, so it is
definitely not the reason why we offered a free edition of the product.

Where things stand today, we have a a standard edition for both Java and
.NET environments. You can download and generate a license for the
standard edition right from our website. The standard edition supports
both Flash Remoting and AJAX clients. The Professional edition has 2
modes: licensed (where license key is present) and unlicensed (without a
license key). The latter forces the product to switch into the
'Development Mode' where only 1 IP address is allowed. That can be reset
when product restarts.
You can see the comparison between Standard and Professional at:
http://www.themidnightcoders.com/doc20/?t=5

Btw, one of the features we added to professional edition is WebORB
Message Server. You can see an example of the message server in action
here:
http://www.themidnightcoders.net/examples/messageserver/chat/mapchatajax.htm

Please let me know if you have any questions about the product or licensing.

cheers,
Joe

Julian Suggate wrote:

> Hi Jonathon,
>
> From what I remember from FlashOrb (don't quote me on this) the Java
> version is free because TMC have used some GPL'd code in their
> implementation. The .NET version of FlashOrb most definitely was NOT
> free for production purposes. Single IP limitation without a license.
> Licenses were priced per logical CPU last I checked.
>
> WebOrb may be different though.
>
> There was a rep from TMC lurking around on this list at one stage,
> perhaps they're listening? Try tech support if you're still unsure.
>
> Jules
>
> On 10/28/05, *Jonathan Boutelle* <jon@...
> <mailto:jon@...>> wrote:
>
>     http://www.themidnightcoders.com/index.htm
>
>     The midnight coders have released an interesting
>     presentation server / rich client toolkit called
>     WebORB. This seems like an ambitious project,
>     aimed at solving the problems of rich ui
>     development by blending Flash and AJAX
>     technologies in innovative ways (just as one
>     example, they seem to be planning to support sockets by using
>     flashcom server).
>
>     They still have a lot of work to do. From their site:
>         * Communication Stack –
>         * Data binding module –
>         * Dynamic rich user interface widgets (available in a future
>     release)
>         * Event system (available in a future release
>         * Drag-and-drop (available in a future release
>         * Interactive messaging client (available in a future release)-
>     I'm also not too clear on licencing terms for WebORB. The website says
>     The Standard Edition is free for most commercial
>     uses (see explanation
>     <http://groups.yahoo.com/group/flashorb/message/146>here).
>     It does not have any technical limitations
>     (connection limits or expiration dates) and
>     provides AJAX support in both Java and .NET
>     editions of the product and full Flash Remoting
>     implementation in the Java edition of the product.
>
>     The link goes to a yahoo group that I have no
>     inclination to join. Anyone know what the deal is?
>
>     Does anyone generally have any experience with
>     WebORB/Rich Client System they'd like to share?
>
>     Regards,
>
>     ----^-------^------^--------^-------^
>     Jon Boutelle
>     Principal, Uzanto Consulting
>     Mountain View, CA
>
>     Office Phone:650-564-0000
>     Cell Phone   :510-708-9825
>     skype id: jboutelle
>     www.uzanto.com <http://www.uzanto.com>
>     www.jonathanboutelle.com <http://www.jonathanboutelle.com>
>     ----^-------^------^--------^-------^
>
>
>
>     SPONSORED LINKS
>     Design patent
>    
<http://groups.yahoo.com/gads?t=ms&k=Design+patent&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=nzt4vhrCYsiJfZ49a2PoVQ>
>      Design school
>    
<http://groups.yahoo.com/gads?t=ms&k=Design+school&w1=Design+patent&w2=Design+sc\
hool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desig\
n+for+six+sigma&c=6&s=137&.sig=R4Ow0YiVxLTWY0mOJwIhEQ>
>      Design schools
>    
<http://groups.yahoo.com/gads?t=ms&k=Design+schools&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=hkyvnHAsvWLY5PnX-Skt5A>
>
>     Design auto dealer web site
>    
<http://groups.yahoo.com/gads?t=ms&k=Design+auto+dealer+web+site&w1=Design+paten\
t&w2=Design+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+d\
esign&w6=Design+for+six+sigma&c=6&s=137&.sig=1HQ5zlE_gIO4juvfxo-vJw>
>      Network design
>    
<http://groups.yahoo.com/gads?t=ms&k=Network+design&w1=Design+patent&w2=Design+s\
chool&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w6=Desi\
gn+for+six+sigma&c=6&s=137&.sig=tnLOKn2I0XV-9gXE7bESRg>
>      Design for six sigma
>    
<http://groups.yahoo.com/gads?t=ms&k=Design+for+six+sigma&w1=Design+patent&w2=De\
sign+school&w3=Design+schools&w4=Design+auto+dealer+web+site&w5=Network+design&w\
6=Design+for+six+sigma&c=6&s=137&.sig=94rpamLskobjP78ckIk6JA>
>
>
>
>     ------------------------------------------------------------------------
>     YAHOO! GROUPS LINKS
>
>         *  Visit your group "ajax_and_ria
>           <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
>
>         *  To unsubscribe from this group, send an email to:
>             ajax_and_ria-unsubscribe@yahoogroups.com
>          
<mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>         *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>           Service <http://docs.yahoo.com/info/terms/>.
>
>
>     ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "ajax_and_ria
>       <http://groups.yahoo.com/group/ajax_and_ria>" on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ajax_and_ria-unsubscribe@yahoogroups.com
>       <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------