Flex? (was: What's exciting in Adobe Thermo?)

22 Mar 2008 - 4:14pm
6 years ago
29 replies
3484 reads
Matt Nish-Lapidus
2007

So, all this talk about Thermo and how it integrates into Flex... but
do people use Flex for real projects? I have yet to see any web
app/site that really uses Flex for an RIA.. most apps still use (and
will use IMHO) web standard technologies like html, css, javascript,
etc...

What are people suing Flex for? intranet apps? industrial? anything?
and in that light, is the Flex integration with Thermo really that big
a selling point?

On Sat, Mar 22, 2008 at 1:07 PM, Dan Harrelson <danh at adaptivepath.com> wrote:
> Smitha makes some good points. I agree that from what I've seen of
> Thermo, it will be a good prototyping tool. It's time that we get some
> decent tools for mocking up real interactions that have movement. It's
> such a pain that so many of us have to use "flat" tools like InDesign
> or Visio or Illustrator or Photoshop or Graffle or, or or.
>
> I think that Thermo will position itself as the high fidelity
> prototyping tool. Given the likely high price-point and the expected
> high-end feature list, I doubt that it'll be the tool we reach for to
> draw a quick box and arrow. Thermo will probably be the tool we reach
> for when it's time to spend a couple of hours designing something more
> interactive.
>
> I am also looking forward to better design tools than are available in
> Flex Builder. I find that the GUI design palette in Builder is what
> I'd expect from a tool aimed at developers. You quickly find yourself
> in the code view working on MXML or ActionScript. Thermo will allow
> designers, and possibly even developers to accomplish many of the same
> interactions without diving into code.
>
> If they get it right, Adobe will be able to offer us a great workflow
> as well. We'll be able to pull in assets seamlessly from Photoshop and
> Illustrator. We'll also be able to round trip an RIA between Flex
> Builder and Thermo. Yes, I foresee that Flex Builder will remain in
> the ecosystem.
>
> <plug>
> What I'm most excited about is getting the Thermo team from Adobe up
> on stage during my workshop at UX Week this August. http://www.uxweek.com/workshops/beyond-wireframes-making-interactive-sketches
> </plug>
>
> ...Dan
>
> On Mar 21, 2008, at 5:32 AM, Charusmitha Ram wrote:
>
> > Oleg,
> > What is most compelling to me, as an Interaction Designer, is that
> > Thermo
> > would allow me to do rapid prototyping using some very simple
> > interactions.
> > I usually create my wireframes in InDesign and publish them as PDFs.
> > Thermo
> > would save a lot of time and effort when I need to create these
> > click-thrus.
> > I also think this is very useful for high fidelity prototypes.
> > Whether or not the built-in interactions are scalable enough for
> > actual
> > development needs is yet to be tested. But at this point it looks
> > quite
> > promising as a prototyping tool.
> >
> > - Smitha Ram
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
Matt Nish-Lapidus
work: matt at bibliocommons.com / www.bibliocommons.com
--
personal: mattnl at gmail.com

Comments

22 Mar 2008 - 4:26pm
SemanticWill
2007

1. orginal kayak.com was in flex with flash front end. we changed to
html/ajax cause aol gave us money with strings attached - those strings
included no plugins (flash), and work with IE 5.5 on 36K dial-up connection.
those constraints meant rebuilding the front end.
2. http://www.volkswagen.co.uk/ using it. click through "new cars" and the
faceted navigation with dynamic hide/show is all flash/flex.

Check out : http://flex.org/showcase/ a to see a bunch of examples

Cheers!

<trimmed for the nannybot>

On Sat, Mar 22, 2008 at 6:14 PM, Matthew Nish-Lapidus <mattnl at gmail.com>
wrote:

> So, all this talk about Thermo and how it integrates into Flex... but
> do people use Flex for real projects? I have yet to see any web
> app/site that really uses Flex for an RIA.. most apps still use (and
> will use IMHO) web standard technologies like html, css, javascript,
> etc...
>
> What are people suing Flex for? intranet apps? industrial? anything?
> and in that light, is the Flex integration with Thermo really that big
> a selling point?
>
>

22 Mar 2008 - 10:02pm
Grady Kelly
2007

Sorry if this is long ... I have been burned by a few real projects.

I have done a few projects over the last few years where the direction given
was to use Flex.

I really believe that Flex is one of those tools that trys to get momentum
from the developer out. Developers love Flex. They get cool looking stuff
right out of the box. Not like xhtml/css/javascript, where they would have
to do a lot without a designer around.

My first experience with Flex was with an Electronic Medical Records
company. The CEO read something about Flex, so we had to use it. (lame) We
had outsourced some Flex gurus to come help us take a key part of our
application, done with xhtml, css and javascript, and rebuild it in Flex.
The original part of the app took about 3 months for myself and the
developer to do. After giving the "gurus" all they needed, they told us it
would take about 6 months to accomplish with 4 developers working on it!
Unbelievable! Needless to say, we dropped them.

Again, the CEO wanted us to use Flex, but with something else. We had a
patient dashboard that had various panels of patient info, everything from
vitals to allergies, etc. The panels were supposed to be customizable, so
that you could arrange them the way you wanted, and save on the fly. Sounds
simple enough, right? Wrong. These same flex developers took 4 weeks to
produce the single page, at a cost of $15,000. We wanted to add some
charting and other features, the gurus came back with another $15k bid. I
could not believe that there was any benefit to all this. I spoke to my
boss, and we decided to build it with xhtml/css/javascript and show them
up. In a days time I had a fully working front end prototype with all the
bells and whistles that the page needed to fulfill the requirements of the
original pae, and everything that we needed for the second round of
changes. The executive team was shocked that this could be done in a day.
It took a developer 2 more days to integrate it, and we were done.

I am currently working at a telecommunications company, and developers
decided to use Flex, for the reasons I mentioned above. It has taken
forever for the 3 developers to create this application. I was able to
build it as I had in the previous project it a few weeks.

So, In my experience, it is not a good tool. There are some simple things
that the developers had to create custom stuff for Flex to do, like wrap
text! I think that Adobe is using Thermo now to get to the Designer side of
things. But even then from the one demo that I saw online. it produces code
like Frontpage did in the day. Sections have weird names, and it is not at
all meaningful.

Sorry to rant about it, but I have just had such a horrible experience with
Flex.

Grady Kelly
http://www.gradykelly.com

On Sat, Mar 22, 2008 at 4:14 PM, Matthew Nish-Lapidus <mattnl at gmail.com>
wrote:

> So, all this talk about Thermo and how it integrates into Flex... but
> do people use Flex for real projects? I have yet to see any web
> app/site that really uses Flex for an RIA.. most apps still use (and
> will use IMHO) web standard technologies like html, css, javascript,
> etc...
>
> What are people suing Flex for? intranet apps? industrial? anything?
> and in that light, is the Flex integration with Thermo really that big
> a selling point?
>
> On Sat, Mar 22, 2008 at 1:07 PM, Dan Harrelson <danh at adaptivepath.com>
> wrote:
> > Smitha makes some good points. I agree that from what I've seen of
> > Thermo, it will be a good prototyping tool. It's time that we get some
> > decent tools for mocking up real interactions that have movement. It's
> > such a pain that so many of us have to use "flat" tools like InDesign
> > or Visio or Illustrator or Photoshop or Graffle or, or or.
> >
> > I think that Thermo will position itself as the high fidelity
> > prototyping tool. Given the likely high price-point and the expected
> > high-end feature list, I doubt that it'll be the tool we reach for to
> > draw a quick box and arrow. Thermo will probably be the tool we reach
> > for when it's time to spend a couple of hours designing something more
> > interactive.
> >
> > I am also looking forward to better design tools than are available in
> > Flex Builder. I find that the GUI design palette in Builder is what
> > I'd expect from a tool aimed at developers. You quickly find yourself
> > in the code view working on MXML or ActionScript. Thermo will allow
> > designers, and possibly even developers to accomplish many of the same
> > interactions without diving into code.
> >
> > If they get it right, Adobe will be able to offer us a great workflow
> > as well. We'll be able to pull in assets seamlessly from Photoshop and
> > Illustrator. We'll also be able to round trip an RIA between Flex
> > Builder and Thermo. Yes, I foresee that Flex Builder will remain in
> > the ecosystem.
> >
> > <plug>
> > What I'm most excited about is getting the Thermo team from Adobe up
> > on stage during my workshop at UX Week this August.
> http://www.uxweek.com/workshops/beyond-wireframes-making-interactive-sketches
> > </plug>
> >
> > ...Dan
> >
> > On Mar 21, 2008, at 5:32 AM, Charusmitha Ram wrote:
> >
> > > Oleg,
> > > What is most compelling to me, as an Interaction Designer, is that
> > > Thermo
> > > would allow me to do rapid prototyping using some very simple
> > > interactions.
> > > I usually create my wireframes in InDesign and publish them as PDFs.
> > > Thermo
> > > would save a lot of time and effort when I need to create these
> > > click-thrus.
> > > I also think this is very useful for high fidelity prototypes.
> > > Whether or not the built-in interactions are scalable enough for
> > > actual
> > > development needs is yet to be tested. But at this point it looks
> > > quite
> > > promising as a prototyping tool.
> > >
> > > - Smitha Ram
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > Unsubscribe ................ http://www.ixda.org/unsubscribe
> > List Guidelines ............ http://www.ixda.org/guidelines
> > List Help .................. http://www.ixda.org/help
> >
>
>
>
> --
> Matt Nish-Lapidus
> work: matt at bibliocommons.com / www.bibliocommons.com
> --
> personal: mattnl at gmail.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

22 Mar 2008 - 5:23pm
Dave Malouf
2005

Matt,

Huh? My favorite RIA right now is a Flex app. Buzzword.com. It is the
best browser based word processor.

There is also (and I'm forgetting the name) great PPT clone done in
Flash/Flex as well.

I think Yahoo maps is or used to be a flash/flex app.
Goowy.com is one.

And as Will highlighted there is a showcase of it.
Also, all the AIR stuff CAN be Flex stuff as well, as obviously it is
Flash stuff.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

22 Mar 2008 - 11:06pm
Troy Gardner
2008

I am a flash expert and have played with Flex as well. I've seen
Thermo demo'd at MAX, and I look forward to seeing it help bridge the
gaps in real world workflows between Photoshoppers, Illustrators and
Flash, Dreamweaver, Fireworks and Flexers.

The declaritive aspect of Flex can be faster than Flex for developing
applications, especially in teams. That said historically, it's a
complex beast, as there are two areas of of complexity 1) mastering
the rather deep libraries 2) running into their limitations, which
are only revealled when you're standing on top of them with 90% of
your application built.

This is true for Flash as well, historically 80% of my programming can
take 20% of the time some other traditional languages take if you
measure total cost of development (cross browser compatibility being
the achilles heel for html), but that 5-20% of feature can end up
taking 80% of the time when you hit one of those walls, because the
libraries aren't built in a way to make some features possible.
Another major issue for Flex until recently is the sheer size,
200KB--1.2MB for the adobe framework to load. Thankfully Adobe is
trying to address some of these.

To be fair developing RIA's is an order of magnitude more complex than
page by page html applications, but on par with AJAX applications, and
consulting agencies recognize that risk...and of course tend to charge
as much as they can. I have gotten far better experiences out of
using Flash and Flex than AJAX/HTML when projects are setup
appropriately, but perhaps like you I am also keenly aware of what
needs to be done, the limitations and am not looking to geek out on
implementation, or charge as much as possible as I'm in house.

Troy.

23 Mar 2008 - 9:01am
Matt Nish-Lapidus
2007

I have lots of experience working on Flash based projects, and overall
it's been about 20% positive, 80% negative. I've found that
development takes longer, there are more issues.. and you inevitably
end up rebuilding most of the browser functionality that you get with
HTML for free.

I'm of the mind that Flash is great for really experiential sites and
kiosk/embedded type applications. However, for websites you end up
with a lot of conflicting interaction cues, and building your app to
accommodate things like that browser back button, multi-page
information, scrolling, even word wrap (as has been mentioned).. all
that stuff takes time in Flash/Flex. You can build a standard
library, but from what I've seen you end up having to customize a lot
each project anyway.

All that aside, there is one huge problem I see with the SWF format in
general .. it's closed. The web only exists because of the open
nature of HTML ... you can learn just be looking at other work that
you like, that encouraged huge growth in the early days, and the same
thing can't happen with a closed compiled format.

I was hoping to see some Flex examples that would blow me away.. and I
saw a few that are really good, but nothing that would sway my
feelings about it.

Like Troy said he has had better experience with RIAs built in
Flex/Flash than HTML/AJAX.. (needless to say at this point) I have had
the opposite experience. I've found that making changes down the
line, HTML/AJAX is far faster and more flexible than trying to change
the core of a Flex app six months after it's finished. Same thing
with CSS swapping for different devices...

Okay, this is getting off topic now.. so to bring it back... do people
see value in Thermo outside of a Flex environment? Or are the two
workflows linked too closely?

On Sun, Mar 23, 2008 at 1:06 AM, Troy Gardner <troy at troyworks.com> wrote:
> To be fair developing RIA's is an order of magnitude more complex than
> page by page html applications, but on par with AJAX applications, and
> consulting agencies recognize that risk...and of course tend to charge
> as much as they can. I have gotten far better experiences out of
> using Flash and Flex than AJAX/HTML when projects are setup
> appropriately, but perhaps like you I am also keenly aware of what
> needs to be done, the limitations and am not looking to geek out on
> implementation, or charge as much as possible as I'm in house.

--
Matt Nish-Lapidus
work: matt at bibliocommons.com / www.bibliocommons.com
--
personal: mattnl at gmail.com

23 Mar 2008 - 9:54am
Matt Nish-Lapidus
2007

On more quick note before I end my rant :)

What about accessibility? font-size changing? both are much more
difficult in Flash, and I imagine Flex is the same...

On Sun, Mar 23, 2008 at 11:01 AM, Matthew Nish-Lapidus <mattnl at gmail.com> wrote:
> I have lots of experience working on Flash based projects, and overall
> it's been about 20% positive, 80% negative. I've found that
> development takes longer, there are more issues.. and you inevitably
> end up rebuilding most of the browser functionality that you get with
> HTML for free.
>
> I'm of the mind that Flash is great for really experiential sites and
> kiosk/embedded type applications. However, for websites you end up
> with a lot of conflicting interaction cues, and building your app to
> accommodate things like that browser back button, multi-page
> information, scrolling, even word wrap (as has been mentioned).. all
> that stuff takes time in Flash/Flex. You can build a standard
> library, but from what I've seen you end up having to customize a lot
> each project anyway.
>
> All that aside, there is one huge problem I see with the SWF format in
> general .. it's closed. The web only exists because of the open
> nature of HTML ... you can learn just be looking at other work that
> you like, that encouraged huge growth in the early days, and the same
> thing can't happen with a closed compiled format.
>
> I was hoping to see some Flex examples that would blow me away.. and I
> saw a few that are really good, but nothing that would sway my
> feelings about it.
>
> Like Troy said he has had better experience with RIAs built in
> Flex/Flash than HTML/AJAX.. (needless to say at this point) I have had
> the opposite experience. I've found that making changes down the
> line, HTML/AJAX is far faster and more flexible than trying to change
> the core of a Flex app six months after it's finished. Same thing
> with CSS swapping for different devices...
>
> Okay, this is getting off topic now.. so to bring it back... do people
> see value in Thermo outside of a Flex environment? Or are the two
> workflows linked too closely?
>
>
>
> On Sun, Mar 23, 2008 at 1:06 AM, Troy Gardner <troy at troyworks.com> wrote:
> > To be fair developing RIA's is an order of magnitude more complex than
> > page by page html applications, but on par with AJAX applications, and
> > consulting agencies recognize that risk...and of course tend to charge
> > as much as they can. I have gotten far better experiences out of
> > using Flash and Flex than AJAX/HTML when projects are setup
> > appropriately, but perhaps like you I am also keenly aware of what
> > needs to be done, the limitations and am not looking to geek out on
> > implementation, or charge as much as possible as I'm in house.
>
> --
>
>
> Matt Nish-Lapidus
> work: matt at bibliocommons.com / www.bibliocommons.com
> --
> personal: mattnl at gmail.com
>

--
Matt Nish-Lapidus
work: matt at bibliocommons.com / www.bibliocommons.com
--
personal: mattnl at gmail.com

23 Mar 2008 - 11:08am
jayhilwig
2006

The PPT clone is called SlideRocket:
http://www.sliderocket.com/

Another good example is Picnik, photo editor:
http://www.picnik.com/

There was an article on TechCrunch yesterday "Bridging Desktop and Web
Apps" discussing similar issues:
http://www.techcrunch.com/2008/03/22/bridging-desktop-and-web-applications-a
-look-at-mozilla-prism/

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of dave
malouf
Sent: Saturday, March 22, 2008 4:24 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Flex? (was: What's exciting in Adobe Thermo?)

Matt,

Huh? My favorite RIA right now is a Flex app. Buzzword.com. It is the
best browser based word processor.

There is also (and I'm forgetting the name) great PPT clone done in
Flash/Flex as well.

I think Yahoo maps is or used to be a flash/flex app.
Goowy.com is one.

And as Will highlighted there is a showcase of it.
Also, all the AIR stuff CAN be Flex stuff as well, as obviously it is
Flash stuff.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

23 Mar 2008 - 1:08pm
Troy Gardner
2008

> development takes longer, there are more issues.. and you inevitably
> end up rebuilding most of the browser functionality that you get with
> HTML for free.

No argument if you are comparing, but they are different beasts. One
of the reasons I love the Flash Platform is the ability for people to
push past the limitations in HTML into making things more useable.
Sadly they reinvent things that don't need to be reinvented, like
scrollbars.

Many of the issues you mention affect RIA's in general. Be it Flash,
Flex or AJAX. It's the difference of maintaining state client side,
turning it into an application, versus a page by page. Despite being
HTML I've seen AJAX projects take far longer than Flash based sites,
precisely because what's built into the browser starts getting in the
way, and cross browser compatibility ends up eating into all the time.

> All that aside, there is one huge problem I see with the SWF format in
> general .. it's closed.

Depending on your definition, It's been open for quite awhile now
(http://osflash.org/flash9), though it does require a license.

Since SWF's are like zip files, they contain vector, bitmap graphics,
all streaming having it text readable isn't really practical..google
can index swf file contents, but due to the fact that swfs aren't
static, there's very little value in indexing them. Also Flex based
apps ARE text based (declarative markup) like HTML, and many
developers allow people to view the source via right click.

> The web only exists because of the open
> nature of HTML

The flash community is incredibly open about most of their work. It's
one of the best things about the community, and why (perhaps to your
frustration) it's so pervasive on the web, the number of sites I go to
that don't have flash somewhere is really small.

> I was hoping to see some Flex examples that would blow me away..

Flex and AIR is young, as we both remarked, it's been a rough start.
Many of the Flex 1.0 and Apollo examples on the web are broken as it's
changed so much, that said is it's starting to settle down. Also
Flash 10 will support autoflowing multicolumn text (newspaper style).

Also I develop in RAW Flash, which is vastly different than Flex, and
since they are technologies, it's highly dependent on who is doing the
work, and their understanding of the limitations. HTML and Flash
can be complimentary, I use Flash as presentation layer, and
experience layer (animation, fading etc), all the text comes from the
underlying html site (some of which is coming from WordPress), text
styled with the CSS (and I could even do the layout in HTML from the
CSS). If the user of the site has javascript turned off, they will
get a basic html site that is compatible with Screen
Readers/Accessibility.

AJAX sites are on a spectrum, so we may be arguing diffferent things.
Sites that do basic pagination, can get the no-refresh feel of AJAX
cheaply and fastly. If you've outsourced the development, doesn't
matter if it's Wordpress, Java, Oracle etc, it's always harder than
just opening up a text editor and start changing.

I haven't seen any AJAX sites really deal with dramatic font resizing
gracefully, nor is this a requirement in every site. Flash in
particular can embed fonts, which are easier to read IMO than html.
It's trivial to change the text size (a process similar to CSS), but
as you know that's not built in, if that's what you are expecting.

Start getting into custom components with complex layout, calendars,
tree grids, drag and drop, applications like Buzzword, and as yet I've
never seen a AJAX site that hasn't taken *way* longer to develop.
Applications like Photoshop online, video and sound editors, aren't
possible in HTML.

Thermo even outside of Flex is a great tool to develop prototypes, as
that is what it's built to do. It integrates with sample XML data
sets, and layout when neither Fireworks or Flash make drag and drop
easy. Any time interactive design can be pushed more towards the IA,
IxD, design before hitting implementation is generally a good idea.
As wireframes without interactive flows tend to be filled with major
holes, and at the point any change to the UI to fill them in, is
hitting application logic, server logic, and database schema it's
several orders of magnitude of cost. The concern I have is the same
that many IA's UX face...not all companies recognize the value in a
dedicated position and skillset, so they get filled in with sales,
marketing and creative types.

Troy.

23 Mar 2008 - 9:50am
Jose E.
2008

I Guess the main issues with Flash/Flex is the addressing issues that
are common stuff when using standard XHTML/CSS like the back button,
custom urls and other trivialities.

But for great interaction and immersive experiences you have to use
Flash, also to integrate video Flash is the de facto standard.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

24 Mar 2008 - 8:16am
Scott McDaniel
2007

We built a Flex application for an insurance company's CSRs.
It was - as Troy mentioned for one of his projects - because the
executive stakeholder
heard of this Flex-thing and wanted to whiz-bang. I had done Flash in
the past, so
I was tapped to learn Flex and go from there.
When it dealt with out-of-the-box needs, it was great - easy, I
learned on the fly, I produced the basic application in a little over
a week...and it became easier as I went along. When I started hitting
walls, we had to backtrack and re-engineer because
our IAs and their system requirements didn't mesh - and well,I'll say
it - they had no idea of the capacities or limitations
of the technology. When we were done (and it took our engineers extra
time to integrate the backend, but they were learning as well),
I was able to complete something in a week and a half (with 3 days
help from a seasoned contractor) that would have taken me about 3
weeks in HTML/Ajax - a nice slice off the time, even if not
revolutionary. However, for such an easy-to-learn technology and
usable
platform, it gave me a daily headache. Since then, I've advised
against Flex for every project which has been brought up - not
because I don't think it has uses, it's just not the right tool for
the problems presented...and people are still learning what it is and
isn't.

Scott

24 Mar 2008 - 1:56am
Sharon Greenfield5
2008

Very, Very good point.
Flash definitely hasn't in the past grown, nor do I think it will in
the future grow very quickly in creative adaptive ways, because of
this hinderance.

On Mar 23, 2008, at 8:01 AM, Matthew Nish-Lapidus wrote:.
>
> All that aside, there is one huge problem I see with the SWF format in
> general .. it's closed. The web only exists because of the open
> nature of HTML ... you can learn just be looking at other work that
> you like, that encouraged huge growth in the early days, and the same
> thing can't happen with a closed compiled format.

24 Mar 2008 - 2:01am
Sharon Greenfield5
2008

Additionally, unless you are a huge brand name *cough* Nike *cough*
in which it doesn't matter, most e-commerce sites don't want to be
built in Flash.
This is because often e-commerce is highly dependent on (SEO) search
engine optimization.

On Mar 23, 2008, at 8:50 AM, Jose E. wrote:

> I Guess the main issues with Flash/Flex is the addressing issues that
> are common stuff when using standard XHTML/CSS like the back button,
> custom urls and other trivialities.
>
> But for great interaction and immersive experiences you have to use
> Flash, also to integrate video Flash is the de facto standard.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=27483
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

23 Mar 2008 - 8:19pm
Ryan Stewart
2008

Hey All, great discussion.

I'm an evangelist at Adobe so I'm not unbiased but I wanted to chime in
on a couple of things. Especially with Flex we've really tried to make
SWF in general more web-like. So some of the issues below, like back
button and custom URLs are fully possible in Flex. It's a bit more work
but I don't think it's a lot of extra work over an Ajax application.

I saw another question about accessibility and all of the Flex
components are accessible out of the box. Currently they work with JAWS
on Windows and we're working on Mac support as well. So instead of
having to create your own accessible components as you would with Flash,
you can use the Flex Framework components and get some of those tasks
for "free".

I'd love to answer any other questions. I'm about to dive into the rest
of the thread about Thermo so I may have more responses.

=Ryan Stewart
rstewart at adobe.com
RIA Evangelist
Adobe Systems

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Jose E.
Sent: Sunday, March 23, 2008 1:51 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Flex? (was: What's exciting in Adobe
Thermo?)

I Guess the main issues with Flash/Flex is the addressing issues that
are common stuff when using standard XHTML/CSS like the back button,
custom urls and other trivialities.

But for great interaction and immersive experiences you have to use
Flash, also to integrate video Flash is the de facto standard.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

24 Mar 2008 - 9:07am
SemanticWill
2007

If you all don't mind - I would love to take a step back from the
"implement/not" discussion and point out a thread I hear being repeated in
this discussion which is management starting with the tech
selection/solution first which is a bad idea all around. I know at least in
my b-school strategy class - they taught that problem-space definition
always comes first - and this seems to be where stakeholders/management are
falling down. Wouldn't it be nice if stakeholders got together with their
teams and started with problem definition and goals first - worked those out
completely - and then explored possible solutions/technology selection, etc
after strategy?

If the conversation starts with "We need to build an RIA in Foo" the project
has already been draped with a great big nasty rotting albatross around it's
neck.

My humble 2 cents and a tequila shot.

<trim>
On Sun, Mar 23, 2008 at 10:19 PM, Ryan Stewart <rstewart at adobe.com> wrote:

> Hey All, great discussion.
>
> I'm an evangelist at Adobe so I'm not unbiased but I wanted to chime in
> on a couple of things. Especially with Flex we've really tried to make
> SWF in general more web-like. So some of the issues below, like back
> button and custom URLs are fully possible in Flex. It's a bit more work
> but I don't think it's a lot of extra work over an Ajax application.
>
> I saw another question about accessibility and all of the Flex
> components are accessible out of the box. Currently they work with JAWS
> on Windows and we're working on Mac support as well. So instead of
> having to create your own accessible components as you would with Flash,
> you can use the Flex Framework components and get some of those tasks
> for "free".
>
> I'd love to answer any other questions. I'm about to dive into the rest
> of the thread about Thermo so I may have more responses.
>
> =Ryan Stewart
> rstewart at adobe.com
> RIA Evangelist
> Adobe Systems

24 Mar 2008 - 9:43am
mtumi
2004

in response to those who have posted the "i am a still recovering flex
user" threads, one comment worth making is that the initial version of
Flex (1.5 and earlier) was really (IMO) released too soon. The code
editor was built on dreamweaver rather than eclipse, and compared to
2.0, it was a real dog. Numerous improvements were made for 2.0, and
with 3.0 I think we're probably seeing about what should have been 1.0
in an ideal world (since we all work with software I don't have to
explain this further. :-) )

so, if you were burned as an early adopter you might want to take
another look.

MT

24 Mar 2008 - 10:19am
Dave Meeker
2008

Ahhhh... Flex....

Hey all. As someone who doesn't post to the list much, I finally feel
compelled to speak up regarding the whole prototyping/thermo and flex
subject. Alas, it is something that I arguably know something about.

As a guy who has been using flex for close to 5 years and has seen it grow
from a server-side product at Macromedia to the current 3.0 version, I can
stand up and state that flex is much more widely used than you'd think (or
seem to think based on your email).

So, all this talk about Thermo and how it integrates into Flex... but
> do people use Flex for real projects?

Absolutely. A lot of "real projects" have been built using Flex. Before
going any further, I think there needs to be some demystification of what
flex is. People seem to treat Flex as if it is some unknown product on the
far reaching corners of the web galaxy. Flex is just a way to create RIAs or
other "Flash" content without using the Adobe "Flash" IDE. Flex has Flex
Builder, the tool created by Adobe to write Flex apps, but in reality, Flex
is just a framework to build RIAs that play in the Flash player (or AIR now
that we have it).

> I have yet to see any web
> app/site that really uses Flex for an RIA.. most apps still use (and
> will use IMHO) web standard technologies like html, css, javascript,
> etc...

I spoke at the Adobe MAX conference last year in Chicago on "Next Generation
User Experiences" and how you can develop them in Flex.
Here are some examples of Sites that are built on Flex, and these projects
have been worked on by myself, someone I know or have met in one capacity or
another. I am just stating that so you can understand that this is
first-hand information as opposed to "that could have been built in Flex".

Out of the giant list of Flex apps that have been launched to the public,
here is a handful that you might recognize:

- www.scion.com - Full Flex application with Flash assets being
loaded.
- Ebay Desktop - AIR Application that my old crew at EffectiveUI built
using Flex
- anywhere.fm - online media player replacement for iTunes.
- Picnik - Online image editor application
- Mixbook.com - Book creation and sharing
- Snapfish - http://www.snapfish.com/
- Mastercard -
http://www.mastercard.com/us/business/en/smallbiz/findacard/findacard.html
- Finetune Desktop - http://www.finetune.com/desktop/

In addition to this quick list, I've seen Flex be used for others including
NBC, EA, Discovery Channel, matchmine, Harley Davidson,
PriceWaterhouseCoopers, The US Air Force, Citi, Sherwin Williams... the list
just goes on and on.

One amazing new application that is built on Flex was built by the folks at
Adobe Consulting: www.searchme.com. Also, most of the applications that you
find Adobe putting out (labs.adobe.com) are built on Flex.

Why Flex? I could go on for ages on this topic. First, it isn't the perfect
tool for everyone. It is, however, the perfect tool when you've got a group
of developers who are working on an enterprise-level application. Flex is
going to be quite daunting for someone who knows the Flash IDE, but is not
familiar with OO programming, design patterns, MVC, etc.

Flex was intended for "programmers". As the market has created demand for
better user experiences and RIAs, there just aren't enough Flash developers
out there to meet the demand. Flex allows non-visual developers (i.e Java
developers) to jump into RIA development by giving them a tool that let's
them build apps using the skills that they have as opposed to trying to
learn Flash itself.

There is obviously a lot more to the discussion and I've only barely touched
the surface of the who, where, why and what of Adobe Flex.

I would be more than happy to answer individual questions outside of the
list though. So... please feel free to email me :)

Dave

Dave Meeker
Roundarch
Adobe - "Flex Champion"

>
>
> What are people suing Flex for? intranet apps? industrial? anything?
> and in that light, is the Flex integration with Thermo really that big
> a selling point?
>
> On Sat, Mar 22, 2008 at 1:07 PM, Dan Harrelson <danh at adaptivepath.com>
> wrote:
> > Smitha makes some good points. I agree that from what I've seen of
> > Thermo, it will be a good prototyping tool. It's time that we get some
> > decent tools for mocking up real interactions that have movement. It's
> > such a pain that so many of us have to use "flat" tools like InDesign
> > or Visio or Illustrator or Photoshop or Graffle or, or or.
> >
> > I think that Thermo will position itself as the high fidelity
> > prototyping tool. Given the likely high price-point and the expected
> > high-end feature list, I doubt that it'll be the tool we reach for to
> > draw a quick box and arrow. Thermo will probably be the tool we reach
> > for when it's time to spend a couple of hours designing something more
> > interactive.
> >
> > I am also looking forward to better design tools than are available in
> > Flex Builder. I find that the GUI design palette in Builder is what
> > I'd expect from a tool aimed at developers. You quickly find yourself
> > in the code view working on MXML or ActionScript. Thermo will allow
> > designers, and possibly even developers to accomplish many of the same
> > interactions without diving into code.
> >
> > If they get it right, Adobe will be able to offer us a great workflow
> > as well. We'll be able to pull in assets seamlessly from Photoshop and
> > Illustrator. We'll also be able to round trip an RIA between Flex
> > Builder and Thermo. Yes, I foresee that Flex Builder will remain in
> > the ecosystem.
> >
> > <plug>
> > What I'm most excited about is getting the Thermo team from Adobe up
> > on stage during my workshop at UX Week this August.
> http://www.uxweek.com/workshops/beyond-wireframes-making-interactive-sketches
> > </plug>
> >
> > ...Dan
> >
> > On Mar 21, 2008, at 5:32 AM, Charusmitha Ram wrote:
> >
> > > Oleg,
> > > What is most compelling to me, as an Interaction Designer, is that
> > > Thermo
> > > would allow me to do rapid prototyping using some very simple
> > > interactions.
> > > I usually create my wireframes in InDesign and publish them as PDFs.
> > > Thermo
> > > would save a lot of time and effort when I need to create these
> > > click-thrus.
> > > I also think this is very useful for high fidelity prototypes.
> > > Whether or not the built-in interactions are scalable enough for
> > > actual
> > > development needs is yet to be tested. But at this point it looks
> > > quite
> > > promising as a prototyping tool.
> > >
> > > - Smitha Ram
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > Unsubscribe ................ http://www.ixda.org/unsubscribe
> > List Guidelines ............ http://www.ixda.org/guidelines
> > List Help .................. http://www.ixda.org/help
> >
>
>
>
> --
> Matt Nish-Lapidus
> work: matt at bibliocommons.com / www.bibliocommons.com
> --
> personal: mattnl at gmail.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
Any fool can make things bigger, more complex, and more violent. It takes a
touch of genius - and a lot of courage - to move in the opposite direction.
-- Albert Einstein

24 Mar 2008 - 10:38am
SemanticWill
2007

While a good start - I fear your post suffered from an unbearable lightness
of being.

"Why Flex? I could go on for ages on this topic."

So why Flex? Could you list out some reasons? You need to answer that
relative to other platforms.

" It is, however, the perfect tool when you've got a group
of developers who are working on an enterprise-level application."

How is it perfect when these java/rails/jango/foobar developers need to
learn yap (yet another platform). Given the transition/learning time - what
are the net benefits that make it better than sticking with the tried and
true?

<trim a long-a-ding-dong>
On Mon, Mar 24, 2008 at 12:19 PM, Dave Meeker <meekerd at gmail.com> wrote:

> Ahhhh... Flex....
>
>

24 Mar 2008 - 10:51am
Dave Meeker
2008

One more I forgot to mention...
If you have Adobe CS3 (and I assume that most of you do), you've seen the
Adobe "Video Workshop"... which was shipped with CS3 on DVD and is also
hosted online at http://www.*adobe*.com/designcenter/*video*_*workshop*/

This application was built by my team for Adobe using Flex and also packaged
up using the Adobe Flash standalone player to run on DVD, etc.

Dave

24 Mar 2008 - 11:11am
Dave Meeker
2008

> So why Flex? Could you list out some reasons? You need to answer that
> relative to other platforms.

Sure. I can tackle this one.

Flex isn't perfect for everyone. I've seen a lot of people with solid Flash
chops try to use Flex and just get frustrated. (Nobody said Flex was "easy")
:)
There has been a ton of improvement in the product since the early days.
Flex 1.5 was rough to say the least. Flex 2.0 was a ton better, and Flex 3
is proof positive that Adobe has been listening to the community to make the
tool more robust and more integrated with the CS3 line of tools.

Why Flex over Flash?

I think the case for Flex over flash has to do with the type of application
you are building. If you've got a very robust "application", Flex is
probably the right tool. If you've got a team of "developers" as opposed to
"Flash developers", Flex is probably the right reason. If you've got a
project that requires heavy use of data, data visualization, or needs to
utilize some more advanced back-end systems ... Flex is the tool. This is
especially the case when thinking about applications that might utilize
LiveCycle Data Services or the OpenSource Blaze Data Services.

Flex isn't better than flash... it is just a different tool to accomplish
the same end goal. You have to use a tool that works best for you and your
team.

Instead of saying "Why Flex over AJAX", I will instead say "Why the Flash
player over AJAX".
Both Adobe Flash and Flex output Flash player content. Whatever you use to
develop your application, there are significant benefits to using Flex over
AJAX... again it depends on your specific project!

I will say that in recent months, I've done several evaluations of
technology for client projects, and have had to compare Flex to AJAX for
each.

The biggest advantages of using the Flash player as a runtime for your RIA
as opposed to using AJAX:

1) Write once, deploy cross platform
2) You can turn your Flex application into a desktop application without
much code refactoring (using AIR).
3) With the evolution of browsers, you can be less concerned about how to
migrate your code to keep up with changes in the Document Object Model in
AJAX, as the Flash player is backwards compatible.
4) The Flash player now has hardware acceleration... so you can build UI's
that look and feel the way YOU want the to, and not be limited by your
development technology
5) 3-d integration (using papervision or another framework)
6) Handles LOTS of data much, much, much better (data grids with tons of
rows, etc)

To help you understand what other benefits flex can offer, check out
www.flex.org.

How is it perfect when these java/rails/jango/foobar developers need to
> learn yap (yet another platform). Given the transition/learning time - what
> are the net benefits that make it better than sticking with the tried and
> true?

It isn't. You have to use tools that you know of course.
I will say that the ramp-up time for experienced Java or C# developers to
move to Flex is nominal. ActionScript 3.0 is a lot like Java or C#.
The benefits aren't from a technology point of view. I really think that the
benefits are around the user experience that you can get from a Flex
application as opposed to something else.

If you know Java and that's your thing, then Flex isn't too far off from
your comfort level.

Again, I wouldn't recommend anyone use a new technology on a critical
project. Especially a technology that is completely unfamiliar. One thing I
will say about developing in Flex is that to make "killer" flex apps, you
need to really know the framework and be able to proof-of-concept you way
from the initial idea to a working application. You can build a flex
application that "looks right" but has performance issues due to the way it
was coded. There have been several projects we've worked on in the past
where we were called in to help "save' a project that was built in Flex, but
wasn't built properly. It was all there, but in order to make it
launch-ready, needed a bit of refactoring, etc in order to be optimized for
a great user experience.

If you hit me up offline (meekerd at gmail.com) or (dmeeker at roundarch.com) I'd
be more than happy to chat with you about things we've learned in the past
regarding Flex and the do's and don'ts related to taking on projects using
it.

All in all, it's been a really good tool in my experiences... But I preface
that by saying I've been fortunate enough to work with some pretty talented
software engineers that really know the framework and how to make it sing.

Flex, Flash, AJAX... whatever..... You have to build apps using tools you
are comfortable with, and don't pick a technology simply because it's the
latest thing :)

Dave

24 Mar 2008 - 2:19pm
SemanticWill
2007

Wow. Honestly this is fantastic Dave. I wasn't trying to be a pain in the
ass - if you refer back to my post about stakeholders and wishing more would
start at the problem-space definition and goals first - things would be alot
better. With the things you set down - it means that a team can get through
those, and then start exploring solutions in a more effective manner.

> The biggest advantages of using the Flash player as a runtime for your RIA
> as opposed to using AJAX:
>
> 1) Write once, deploy cross platform
>
Okay.

>
> 2) You can turn your Flex application into a desktop application without
> much code refactoring (using AIR).
>
OSX/Vista/Linux ?

>
> 3) With the evolution of browsers, you can be less concerned about how to
> migrate your code to keep up with changes in the Document Object Model in
> AJAX, as the Flash player is backwards compatible.
>
Your right - this is a pretty big issue that always costs development time
when you have to support IE/FF/Safari on Linux/OSX/MS and you end up going
to the lowest common denominator - but still developers have to hack to get
the right outcome for all flavors - especially when they work for/with me.

>
> 4) The Flash player now has hardware acceleration... so you can build UI's
> that look and feel the way YOU want the to, and not be limited by your
> development technology
> 5) 3-d integration (using papervision or another framework)
> 6) Handles LOTS of data much, much, much better (data grids with tons of
> rows, etc)
>

No argument here - for dynamic visualization of large datasets - I can see
that this is far superior - actually - the types of visualization I am
imagining are only possible in Flex/Flash or in WPF.

Thanks for the extensive answer.

~ Will

24 Mar 2008 - 2:40pm
Andrei Herasimchuk
2004

I've been really trying to stay away from this... but I have to chime
in.

On Mar 24, 2008, at 10:11 AM, Dave Meeker wrote:

> The biggest advantages of using the Flash player as a runtime for
> your RIA
> as opposed to using AJAX:
>
> 1) Write once, deploy cross platform

That "pro" is also it's biggest con, in that you are tying yourself,
your product and everything you do to Adobe in what is effectively a
closed and proprietary format. In other words, you are at the mercy
of the Adobe folks getting it right year over year as technology
continues to evolve.

> 2) You can turn your Flex application into a desktop application
> without
> much code refactoring (using AIR).

Indeed. This is a nice argument for creating a thin client product.
But mixing these products into browser environments as well as having
desktop versions is massively confusing in my opinion. I actually
think Flash/Flex is better for the thin client approach, and
desperately wish people would stop embedding massively complex Flash
apps inside web browsers where they make little sense.

> 3) With the evolution of browsers, you can be less concerned about
> how to
> migrate your code to keep up with changes in the Document Object
> Model in
> AJAX, as the Flash player is backwards compatible.

This is an argument for dropping the web browser as a development
platform. However, if Adobe ever were honest about that product path,
they'd probably lose 90% of the people who would even be interested
in using Flash/Flex. Why? Because the products would live outside the
massive deployment model of the web browser. Unfortunate as that is.

So, in short... be careful with this point. It will burn a lot of
people when you get into the heart of *WHY* it is the case.

> 4) The Flash player now has hardware acceleration... so you can
> build UI's
> that look and feel the way YOU want the to, and not be limited by your
> development technology

No. You are still limited by whatever Flash can or cannot do as a
platform. Let's not even bring up how crappy text handling still is
to this day in the Flash rendering environment.

> 5) 3-d integration (using papervision or another framework)

No one cares about this. Ok... maybe 3% of the development teams out
there do... but really, no one cares about this point.

> 6) Handles LOTS of data much, much, much better (data grids with
> tons of
> rows, etc)

Based on what metrics? I have yet to find a Flash/Flex app that
handles large sets of data faster or better that a well implemented
browser or desktop version. They all have their pitfalls, especially
when done improperly. And yes, this includes and understanding that
even if you could display a thousand rows of data in less than a
second, people can't process it on something as coarse as the
resolution of a computer screen, so who cares?

> All in all, it's been a really good tool in my experiences... But I
> preface
> that by saying I've been fortunate enough to work with some pretty
> talented
> software engineers that really know the framework and how to make
> it sing.

That's obviously a big issue. The thing I have yet to understand is
that if I'm working with that kind of engineering group, which I have
have done so many times in my past, why not just build a real desktop
client application and regain control of everything you need to gain
control of. Sure, *some* of the up front engineering may take a tad
longer than going the RIA route, but given the total and full amount
of control you'll get for that investment,

Now... I'm not saying Flex/Silverlight or any of those technologies
are bad or anything. But what I am tired of are people who aren't
discussing the pros and cons of all of them at a purely agnostic,
"what happens" level, letting people decide for themselves what they
really need to do for their product development. Your list crosses
that line for me.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

24 Mar 2008 - 2:51pm
Andrei Herasimchuk
2004

Let me clarify two things real quick:

On Mar 24, 2008, at 1:40 PM, Andrei Herasimchuk wrote:

> This is an argument for dropping the web browser as a development
> platform. However, if Adobe ever were honest about that product path,
> they'd probably lose 90% of the people who would even be interested
> in using Flash/Flex. Why? Because the products would live outside the
> massive deployment model of the web browser. Unfortunate as that is.

With AIR you can use the browser as both a deployment and access
point for the desktop client version of the product, if you are so
inclined to do so as a user. It's confusing to most people what an
AIR "app" is when they do this, however. The real issue is one of how
people like to access their tools, applications and stuff on their
computer, I think. With AIR apps, you kind of get the best all of
the various methods from an end user point of view, which in my
opinion actually winds up confusing the issue of what an RIA is
rather than providing more clarity.

> That's obviously a big issue. The thing I have yet to understand is
> that if I'm working with that kind of engineering group, which I have
> have done so many times in my past, why not just build a real desktop
> client application and regain control of everything you need to gain
> control of. Sure, *some* of the up front engineering may take a tad
> longer than going the RIA route, but given the total and full amount
> of control you'll get for that investment,

I forgot to complete my thought...

I meant to end it with: "you get a lot of control in return over the
entire interface at every level."

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

24 Mar 2008 - 2:40pm
Dave Meeker
2008

> Wow. Honestly this is fantastic Dave. I wasn't trying to be a pain in the
> ass - if you refer back to my post about stakeholders and wishing more would
> start at the problem-space definition and goals first - things would be alot
> better. With the things you set down - it means that a team can get through
> those, and then start exploring solutions in a more effective manner.

No problem guys! I am glad it helped in a small way!
You have to understand, I spend a LOT of time (a couple hours every day)
thinking about these issues and how people can design and implement the best
possible user experiences while still fitting the project into a mold that
meets the needs of the end users, the client, and of course... the team who
is doing the design and development :) There really is no right answer to
the whole Flex v other technologies question. It really just depends on the
specifics of the situation.
One thing I will say though: If you don't know ActionScript 3, and/or your
team isn't being led up by someone with an actual software development
background... take caution in jumping into a Flex project. Thankfully, there
are folks out there (to whom I could refer you) that could jump in and help
out on a project to get a team up to speed, etc.

> > The biggest advantages of using the Flash player as a runtime for your
> > RIA as opposed to using AJAX:
> >
> > 1) Write once, deploy cross platform
> >
> Okay.
>
> >
:)

>
> > 2) You can turn your Flex application into a desktop application without
> > much code refactoring (using AIR).
> >
> OSX/Vista/Linux ?
>

OSX = yes
vista = yes
Linux = In the works. Adobe has an internal build that works. Should be
soon!

The best part is that you could create your application once, and then make
desktop builds for all three platforms. It is the promise that suckered us
into Java back in the day (sort of). It actually works though, and that is
quite cool.

> > 3) With the evolution of browsers, you can be less concerned about how
> > to migrate your code to keep up with changes in the Document Object Model in
> > AJAX, as the Flash player is backwards compatible.
> >
> Your right - this is a pretty big issue that always costs development time
> when you have to support IE/FF/Safari on Linux/OSX/MS and you end up going
> to the lowest common denominator - but still developers have to hack to get
> the right outcome for all flavors - especially when they work for/with me.
>

Amen to that. The worst I've seen is a team massaging code to work with IE,
Firefox, and Safari and then having MSIE 8 come out and need to be reckoned
with.
at least with the Flash player, you are talking about 1 single runtime that
is the same cross-platform. Granted there are always little things you might
need to tweak, but that really is just for more advanced types of
application logic or potentially integration with the flash object and
JavaScript, etc, etc.

>
> > 4) The Flash player now has hardware acceleration... so you can build
> > UI's that look and feel the way YOU want the to, and not be limited by your
> > development technology
> > 5) 3-d integration (using papervision or another framework)
> > 6) Handles LOTS of data much, much, much better (data grids with tons of
> > rows, etc)
> >
>
> No argument here - for dynamic visualization of large datasets - I can see
> that this is far superior - actually - the types of visualization I am
> imagining are only possible in Flex/Flash or in WPF.
>

Right on. We've done a lot of testing with AJAX and big sets of data. For
the most part, it's a no-go.
Don't get me wrong (again!)... AJAX rocks and everything has a place and
time. But this is not an AJAX sweet spot :)

>>Thanks for the extensive answer.

No problem!

If anyone else has Flex-esque questions, please feel free to drop me a line.

I am glad to be able to help.

Dave

24 Mar 2008 - 3:13pm
Dave Meeker
2008

I've been really trying to stay away from this... but I have to chime
> in.

Uh Oh. :)

>
> > 1) Write once, deploy cross platform
>
> That "pro" is also it's biggest con, in that you are tying yourself,
> your product and everything you do to Adobe in what is effectively a
> closed and proprietary format. In other words, you are at the mercy
> of the Adobe folks getting it right year over year as technology
> continues to evolve.
>

Agreed. But, with any software, you have to have some faith.
Added to that is Adobe's deal with Mozilla this year to license the
scripting language to them for inclusion in the browser framework.
For me, I think it is as simple as recognizing that Flash (player) isn't
going anywhere, is installed on 98.5 (or more) of the computers out there,
takes only a minute to install on machines that don't have it, and because
of that is pretty much ubiquitous. Lesson #2: Don't launch a mission
critical application using any brand new technology you've been working with
it for a while and think you've mastered it (or you know a bunch of
engineers at Adobe who work on the Flex team).

>
> > 2) You can turn your Flex application into a desktop application
> > without
> > much code refactoring (using AIR).
>
> Indeed. This is a nice argument for creating a thin client product.
> But mixing these products into browser environments as well as having
> desktop versions is massively confusing in my opinion. I actually
> think Flash/Flex is better for the thin client approach, and
> desperately wish people would stop embedding massively complex Flash
> apps inside web browsers where they make little sense.
>

I don't disagree with you here. Like anything though, "good" experiences and
"bad" experiences shouldn't be blamed on the technology itself, rather the
implementation of an idea using a particular technology. I've seen the same
concept built by two different teams and feeling that one of them sucked
pretty bad, while the other was brilliant. It comes down to execution,
paying attention to the little details that can make an embedded application
give off bad UX vibes, etc.

>
> > 3) With the evolution of browsers, you can be less concerned about
> > how to
> > migrate your code to keep up with changes in the Document Object
> > Model in
> > AJAX, as the Flash player is backwards compatible.
>
> This is an argument for dropping the web browser as a development
> platform. However, if Adobe ever were honest about that product path,
> they'd probably lose 90% of the people who would even be interested
> in using Flash/Flex. Why? Because the products would live outside the
> massive deployment model of the web browser. Unfortunate as that is.
>

I hear you. I still think that adobe (like a lot of software companies) have
the official plan, but are very cognoscente of the change in the market,
etc.
I don't think Adobe wants to kill the browser as a platform by any means...
(case in point, the deal with Mozilla).
Let's face it... it is a hell of a lot easier to deploy a web application
than a desktop application. AIR solves some of that, but it still isn't as
simple as just going to a URL and having the application sitting there for
you. The downside to browser-only applications is that there is not any
integration with the desktop. Some of the cool things that a platform like
AIR brings you is the ability to drag items (a spreadsheet for example) into
the application and have it converted to consumable data on the fly.

Some of the comments I have made regarding Mozilla refers to the Tamarin
Project: http://www.mozilla.org/projects/tamarin/

> > 4) The Flash player now has hardware acceleration... so you can
> > build UI's
> > that look and feel the way YOU want the to, and not be limited by your
> > development technology
>
> No. You are still limited by whatever Flash can or cannot do as a
> platform. Let's not even bring up how crappy text handling still is
> to this day in the Flash rendering environment.

You are limited by any of the technologies that we have. Flash isn't
perfect, but it is arguably the best we have at the moment.
Also... I've been fortunate to work with some of the best and brightest
Flash developers out there. So, can flash "do it all?". NO.
Can an ActionScript Ninja who really understands the SWF format and the
inner workings of the Flash player work magic? Amen.

> > 5) 3-d integration (using papervision or another framework)
> No one cares about this. Ok... maybe 3% of the development teams out
> there do... but really, no one cares about this point.

They will. :)
check out searchme.com as an example of why.

> > 6) Handles LOTS of data much, much, much better (data grids with
> > tons of
> > rows, etc)
>
> Based on what metrics? I have yet to find a Flash/Flex app that
> handles large sets of data faster or better that a well implemented
> browser or desktop version. They all have their pitfalls, especially
> when done improperly. And yes, this includes and understanding that
> even if you could display a thousand rows of data in less than a
> second, people can't process it on something as coarse as the
> resolution of a computer screen, so who cares?

I could provide proof of concept after proof of concept that I or coworkers
have developed that demonstrate this.
I will not say that a compiled desktop application suffers from the same
lack of data handling that you'd find in the browser though.
Desktop binaries are a different class, and would most likely outperform an
application in Flex. (almost definitely).
But when it comes to pure handling of data, Flex beats Flash, and most of
the AJAX frameworks.
You also have to take into consideration that if you use Flex with BlazeDS
or LiveCycle DS or even products like Midnightcoders' Web Orb, you also
benefit from the data compression and passing of native objects between the
server and the client.

> > All in all, it's been a really good tool in my experiences... But I
> > preface
> > that by saying I've been fortunate enough to work with some pretty
> > talented
> > software engineers that really know the framework and how to make
> > it sing.
>
> That's obviously a big issue. The thing I have yet to understand is
> that if I'm working with that kind of engineering group, which I have
> have done so many times in my past, why not just build a real desktop
> client application and regain control of everything you need to gain
> control of.

Point taken. I don't argue with you here, except for the fact that the "Web"
is king and the large majority of these apps have distinct business
requirements that require them to be deployed online. The flipside of this
is that with the reintroduction of thin-clients (AIR, WPF/Silverlight) the
notion of having "Web" or "Network" connectivity inside your application
should be taken as an obvious thing to include in the architecture.

I agree though. If you want maximum performance... bring your application to
the desktop.
If you have to play in a world with requirements that require it to be
deployed in a different manner.....

> Sure, *some* of the up front engineering may take a tad
> longer than going the RIA route, but given the total and full amount
> of control you'll get for that investment,

True. (again!)

>
>
> Now... I'm not saying Flex/Silverlight or any of those technologies
> are bad or anything. But what I am tired of are people who aren't
> discussing the pros and cons of all of them at a purely agnostic,
> "what happens" level, letting people decide for themselves what they
> really need to do for their product development. Your list crosses
> that line for me.

I am an agnostic guy. I have to be. I have a lot of experience with Flash
and for the last 4-5 years, Flex...
but there is the right tool for the right job, and it might not always be a
flash-player based RIA.

Case in point: I am working on a project now which is an internal
application to be deployed world-wide for a corporation that needs to have
the ability to tie in a device plugged in via USB or serial cable with a web
application. Whoa.... This will be MSIE only, utilizing AJAX as a UI and
data transmission layer with embedded Flash content and OS integration (USB)
using a (gasp) ActiveX Control.

When was the last time you heard that! :)

Thanks for the fascinating challenges to my point of view and the
interesting discussion.

dave

25 Mar 2008 - 8:43am
biankamcgovern@...
2007

Does anybody have experience with Flex and the .net platform as a backend?
What are the possibilities, where are the limits and obstacles?

25 Mar 2008 - 8:11am
Gregor Kiddie
2008

" do people use Flex for real projects? I have yet to see any web
app/site that really uses Flex for an RIA.. most apps still use (and
will use IMHO) web standard technologies like html, css, javascript,
etc...

What are people suing Flex for? intranet apps? industrial? anything?
and in that light, is the Flex integration with Thermo really that big
a selling point?"

We are using Flex for a very large project. We are involved in the
British NHS's "National Program for IT", creating GP systems.

We are looking at tens of thousand of users (all of whom are demanding
and highly opinionated)

>From a design perspective it's proving an interesting challenge given
that the NHS is still handing out "guidance" on everything from
navigation to specific pieces of the interface, and wondering why
everyone is late delivering!

Gk.

Gregor Kiddie
Senior Developer
INPS

Tel: 01382 564343

Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ

Registered Number: 1788577

Registered in the UK

Visit our Internet Web site at www.inps.co.uk

The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact is.helpdesk at inps.co.uk
a.org/help

25 Mar 2008 - 11:35pm
Kontra
2007

Andrei Herasimchuk:

> Now... I'm not saying Flex/Silverlight or any of those technologies
> are bad or anything. But what I am tired of are people who aren't
> discussing the pros and cons of all of them at a purely agnostic,
> "what happens" level, letting people decide for themselves what they
> really need to do for their product development.

March 24, 2008 (Computerworld) Most power users are disappointed with the
performance of Rich Internet Applications (RIAs) based on Asynchronous
JavaScript with XML, or AJAX, according to a new research report from
Forrester Research Inc.

As a result of the AJAX limitations, the research firm recommended that
business users consider emerging next-generation RIA technologies like Adobe
AIR from Adobe Systems Inc. and Microsoft Corp.'s Silverlight tool set.
Forrester report<http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9071039>
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9071039

Computerworld. Forrester. Report.
That pretty much settles that!

--
Kontra
http://counternotions.com

26 Mar 2008 - 1:46am
Andrei Herasimchuk
2004

On Mar 25, 2008, at 10:35 PM, Kontra wrote:

> Computerworld. Forrester. Report.
> That pretty much settles that!

Are you trolling on purpose here or what?

That article is so patently ridiculous, vague and chock full of so
little real qualitative information that I'm not even sure where to
begin.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

27 Mar 2008 - 5:52am
bschultheiss
2008

A lot of interesting posts here.

HTML has a comfortable feel about it.
Its main value is in Simplicity, familiarity and consistency.

But there's things can't do in HTML or AJAX or any available
Javascript project that you can do using the Flash plug-in.

That's what it comes down to.
That's why people use Flash.
Not as an alternative but because there is no alternative.

Silverlight is changing that, but i'll wait and see for that one.

In terms of development.. Its painful... bad..
Flex and Actionscript 3 made it a lot better.. A proper OOP language
aids development hugely.

The main problem using Flex is designing for Flex is terrible..
The current flex framework is difficult to work with..

Thats why this Thermo tool sounds sooooo nice..
They're showing demos of RIA's designed in other Adobe products
(photoshop, illustrator, flash) and generating Flex apps, without
needing to compromise the original design.

This would be difficult to achieve using the current Flex 3
framework, but apparently in Flex 4 (which i'm guessing Thermo is
targeted at) we've got a new MVC architecture for the framework, so
they can generate the highly customised designs without effecting
Application and client/server communication logic which is handy for
the developers.

regards,

Bjorn

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27483

Syndicate content Get the feed