I completely agree about the encapsulation part.  DHTML and JS are
tricky languages to work with and this is compounded by the fact the
browser platforms are a moving target.  One comment we get from a lot of
our enterprise customers is that the components they are using must be
loosely coupled otherwise they at a big risk being stuck with an
outdated technology if new browers or even new GUI technologies emerge.
I think Paul Coffee of eWeek did a good job of putting some of these
challenges in perspective:
http://www.eweek.com/article2/0,1895,1843927,00.asp (shameless self
promotion disclaimer - our product manger was quoted in this article.)
Also, I've found that the skill set of AJAX web developers and
enterprise information system developers are generally different, but
are both required to deliver high performance ebusiness applications,
another argument for encapsulation.

The relationship between SOA and AJAX is quite interesting.  On the
subject of TIBCO they were recently ranked in the leaders quadrant by
Gartner (http://biz.yahoo.com/prnews/050726/sftu083.html?.v=20), and in
the report their AJAX interface tools were mentioned, it seems
interesting that AJAX and SOA being used in conjunction at an enterprise
level.  Seems like we're moving towards an environment where UI and data
sources/services can be quicly mixed and matched.

Andre.

-----Original Message-----
From: ajax_and_ria@yahoogroups.com [mailto:ajax_and_ria@yahoogroups.com]
On Behalf Of khakman
Sent: Thursday, August 18, 2005 9:20 AM
To: ajax_and_ria@yahoogroups.com
Subject: [ajax_and_ria] Re: Emerging Ajaxian controls for ASP.NET

RE: Is encapsulation a good thing for rich UI's?

Encapsulation is critical.  It's the key to faster development,
maintainability over time and support across platforms.  The reality of
developing directly with the DOM and HTTP request objects is that such
processes are riddled with pitfalls.  It's been that way since
1999 when the AJAX capabilities were first put into IE5.0.  If
encapsulation was not a key ingredient we would have seen this all take
off years ago.  Instead there was lots of hype about DHTML, then
everyone figured out it was reall hard to do anyhting beyond basic GUI
tricks with any sort of stability, performance, and maintainability.

Here's a good news byte just out
yesterday that includes comments re:
encapsulation (and AJAX's relation to SOA -- which itself is about
encapsulation):
http://searchwebservices.techtarget.com/originalContent/0,289142
,sid26_gci1116318,00.html

And check out InfoWorld Labs' "AJAX Encapsulation with TIBCO General
Interface" too:
http://weblog.infoworld.com/udell/2005/05/25.html








Yahoo! Groups Links

RE: Is encapsulation a good thing for rich UI's?

Encapsulation is critical.  It's the key to faster development,
maintainability over time and support across platforms.  The reality
of developing directly with the DOM and HTTP request objects is that
such processes are riddled with pitfalls.  It's been that way since
1999 when the AJAX capabilities were first put into IE5.0.  If
encapsulation was not a key ingredient we would have seen this all
take off years ago.  Instead there was lots of hype about DHTML, then
everyone figured out it was reall hard to do anyhting beyond basic
GUI tricks with any sort of stability, performance, and
maintainability.

Here's a good news byte just out
yesterday that includes comments re:
encapsulation (and AJAX's relation to SOA -- which itself is about
encapsulation):
http://searchwebservices.techtarget.com/originalContent/0,289142
,sid26_gci1116318,00.html

And check out InfoWorld Labs' "AJAX Encapsulation with TIBCO General
Interface" too:
http://weblog.infoworld.com/udell/2005/05/25.html

Podcasting applications and jukebox portals that are
launching all confront implementation questions over
how best to deliver appropriate feeds. Feed delivery
is easy using a feedReader and manually selecting your
desired feed sources. Those feeds get downloaded or
polled on http. In another implementation option, AJAX
clients making XmlRequestObj query's can receive the
same feed Message traffic, although without the same
File system priviledges possesed by a client app
running a feedReader. The AJAx client will have a
harder time doing something to persist feed messages
and or media enclosed within the feeds. A more
complicated delivery scenario would mash some APIs
using Akimbo tags in order to bind messages or
feedsources to Middleware "TOPICS" and to then use a
Pub/Sub solution for feed message delivery. Apache
PubScribe is a Pub /SUB API that i've been evaluating
and is the reason for my Post.

see http://ws.apache.org/pubscribe/

Is Pub /SUB going to be a tool for developers and
solution providers in the RSS and Podcasting sector?

Pubscribe seems to be WebService and SOAP everywhere.
Will people trying to use some form of SOAP libraries
in the consumer RIA space get circles run round them
by much more nimble competitors wielding only PHP and
Ajax?

To the extent that the tool selection depends on the
problem, here is a typical problem:

A 15 yr old kid with a phone wants a new RingTone
delivered to the phone without having to do a la carte
search, download, and local FTP to sync the phone to
the browser where the did the search. The browser
interface sucks on the phone. The kid wants to just
express a google query in terms of some akimbo tags.
The semantic for the query is "Find a feed with a
ringtone by the Black-eyed-peas band and download it
to my phone".

Pub Sub solves this kind of problem pretty nicely.
Messages from all sorts of Feeds are observed
server-side. Any messages belonging to a feed or
possessing appropriate tags and satisfying the
specific query are bound to a TOPIC. Normal Pub/Sub
rules for delivery provide either a Notify Push or a
Pull solution for delivery of the specific feed with
the RingTone.

In a corporate MOM environment, Pub/sub built on SOAP
is a no-brainer. But, in the consumer space what to
do?

comments please


robert rowntree
Borneo Consulting Inc
415 642 4162
415 335 5539 M

I think I should have been clearer in my post:

If you are dynamically updating html on your site
then I agree AJAX is a better solution, especially since the browser is so
good at rendering markup.

mike chambers

mesh@...

----- Original Message -----
From: "Mike Chambers" <mchamber@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Wednesday, August 10, 2005 3:38 PM
Subject: Re: [ajax_and_ria] Adaptive Path interviews Flickr


Thanks for clarifying. If you are dynamically updating content on your site
then I agree AJAX is a better solution, especially since the browser is so
good at rendering markup.

This is what we do on parts of our aggregator:

http://weblogs.macromedia.com/mxna/reports/categoryFeedReport/index.cfm

mike chambers

mesh@...

----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Wednesday, August 10, 2005 3:16 PM
Subject: Re: [ajax_and_ria] Adaptive Path interviews Flickr


I think that simple optimization of web forms can be done quite
easily with AJAX. That's what I refer to as "granular/tactical
level", low-risk AJAX projects.

One of the few points of agreement that came out of the Oreilly AJAX
summit was that "AJAX is only rocket science if you are building
rockets". So grabbing some data behind the scenes to drop into a web
form (for example when a particular drop-down option is selected) is
really no big deal.

Making a client-server style application with significant client-side
logic will be a much trickier proposition, involving vendor/platform
selection, with deep architectural implications. It's here that you
have to architect the thing right from the beginning, decide whether
to use Flex or BackBase or Tibco, etc. I think this was the stuff
that you tried to do with AJAX, and you are right, it's probably
easiest using Flex, especially for a team that already knows the toolset.

-Jon

At 03:05 PM 8/10/2005, you wrote:
>Is this actually true though? The experience on our team has been that even
>simple things in DHTML / AJAX take a significant amount of work (mostly due
>to cross browser issues).
>
>Our experience on apps /widgets where we are doing one in Ajax and one in
>Flash, is that in general Flash development has been quicker for two main
>reasons:
>     -Flash has a strong component framework in the Flex framework (I
suspect
>that AJAX / DHTML will get this soon)
>     -Not having to deal with cross browser issues
>
>However, this does not take into consideration that my team already has
>Flash and AJAX/DHTML experience (which other teams may not have). If you
>only know AJAX/DHTML then that is going to be the fastest solution for you
>(at least in the short term).
>
>I am curious with what other's experiences have been?
>
>mike chambers
>
>mesh@...
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Wednesday, August 10, 2005 1:36 PM
>Subject: RE: [ajax_and_ria] Adaptive Path interviews Flickr
>
>
> > I think that the comment about agile development is very relevant. I
> > think that's one key thing to consider when deciding where to use
> > rich client technologies.
> >
> > DHTML lets you can roll out features and respond to client input
> > extremely rapidly. This lets you get something released that
> > satisfies the business problem, even if the business problem keeps
> > changing on you. Once things have settled down, you can then add
> > AJAXian improvements to individual pages of the application at a
> > granular /tactical level, as a series of controlled, low-risk projects.
> >
>
>
>
>------------------------ Yahoo! Groups Sponsor --------------------~-->
><font face=arial size=-1><a
>href="<http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131.6882499.7825260.15102
27/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2889191/R=0/SIG=10r90kr
vo/*http://www.thebeehive.org>http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131
.6882499.7825260.1510227/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2
889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org">Get
>Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life
>- brought to you by One Economy</a>.</font>
>--------------------------------------------------------------------~->
>
>
>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

Thanks for clarifying. If you are dynamically updating content on your site
then I agree AJAX is a better solution, especially since the browser is so
good at rendering markup.

This is what we do on parts of our aggregator:

http://weblogs.macromedia.com/mxna/reports/categoryFeedReport/index.cfm

mike chambers

mesh@...

----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Wednesday, August 10, 2005 3:16 PM
Subject: Re: [ajax_and_ria] Adaptive Path interviews Flickr


I think that simple optimization of web forms can be done quite
easily with AJAX. That's what I refer to as "granular/tactical
level", low-risk AJAX projects.

One of the few points of agreement that came out of the Oreilly AJAX
summit was that "AJAX is only rocket science if you are building
rockets". So grabbing some data behind the scenes to drop into a web
form (for example when a particular drop-down option is selected) is
really no big deal.

Making a client-server style application with significant client-side
logic will be a much trickier proposition, involving vendor/platform
selection, with deep architectural implications. It's here that you
have to architect the thing right from the beginning, decide whether
to use Flex or BackBase or Tibco, etc. I think this was the stuff
that you tried to do with AJAX, and you are right, it's probably
easiest using Flex, especially for a team that already knows the toolset.

-Jon

At 03:05 PM 8/10/2005, you wrote:
>Is this actually true though? The experience on our team has been that even
>simple things in DHTML / AJAX take a significant amount of work (mostly due
>to cross browser issues).
>
>Our experience on apps /widgets where we are doing one in Ajax and one in
>Flash, is that in general Flash development has been quicker for two main
>reasons:
>     -Flash has a strong component framework in the Flex framework (I
suspect
>that AJAX / DHTML will get this soon)
>     -Not having to deal with cross browser issues
>
>However, this does not take into consideration that my team already has
>Flash and AJAX/DHTML experience (which other teams may not have). If you
>only know AJAX/DHTML then that is going to be the fastest solution for you
>(at least in the short term).
>
>I am curious with what other's experiences have been?
>
>mike chambers
>
>mesh@...
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Wednesday, August 10, 2005 1:36 PM
>Subject: RE: [ajax_and_ria] Adaptive Path interviews Flickr
>
>
> > I think that the comment about agile development is very relevant. I
> > think that's one key thing to consider when deciding where to use
> > rich client technologies.
> >
> > DHTML lets you can roll out features and respond to client input
> > extremely rapidly. This lets you get something released that
> > satisfies the business problem, even if the business problem keeps
> > changing on you. Once things have settled down, you can then add
> > AJAXian improvements to individual pages of the application at a
> > granular /tactical level, as a series of controlled, low-risk projects.
> >
>
>
>
>------------------------ Yahoo! Groups Sponsor --------------------~-->
><font face=arial size=-1><a
>href="<http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131.6882499.7825260.15102
27/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2889191/R=0/SIG=10r90kr
vo/*http://www.thebeehive.org>http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131
.6882499.7825260.1510227/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2
889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org">Get
>Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life
>- brought to you by One Economy</a>.</font>
>--------------------------------------------------------------------~->
>
>
>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

I think that simple optimization of web forms can be done quite
easily with AJAX. That's what I refer to as "granular/tactical
level", low-risk AJAX projects.

One of the few points of agreement that came out of the Oreilly AJAX
summit was that "AJAX is only rocket science if you are building
rockets". So grabbing some data behind the scenes to drop into a web
form (for example when a particular drop-down option is selected) is
really no big deal.

Making a client-server style application with significant client-side
logic will be a much trickier proposition, involving vendor/platform
selection, with deep architectural implications. It's here that you
have to architect the thing right from the beginning, decide whether
to use Flex or BackBase or Tibco, etc. I think this was the stuff
that you tried to do with AJAX, and you are right, it's probably
easiest using Flex, especially for a team that already knows the toolset.

-Jon

At 03:05 PM 8/10/2005, you wrote:
>Is this actually true though? The experience on our team has been that even
>simple things in DHTML / AJAX take a significant amount of work (mostly due
>to cross browser issues).
>
>Our experience on apps /widgets where we are doing one in Ajax and one in
>Flash, is that in general Flash development has been quicker for two main
>reasons:
>     -Flash has a strong component framework in the Flex framework (I suspect
>that AJAX / DHTML will get this soon)
>     -Not having to deal with cross browser issues
>
>However, this does not take into consideration that my team already has
>Flash and AJAX/DHTML experience (which other teams may not have). If you
>only know AJAX/DHTML then that is going to be the fastest solution for you
>(at least in the short term).
>
>I am curious with what other's experiences have been?
>
>mike chambers
>
>mesh@...
>
>----- Original Message -----
>From: "Jonathan Boutelle" <jon@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Wednesday, August 10, 2005 1:36 PM
>Subject: RE: [ajax_and_ria] Adaptive Path interviews Flickr
>
>
> > I think that the comment about agile development is very relevant. I
> > think that's one key thing to consider when deciding where to use
> > rich client technologies.
> >
> > DHTML lets you can roll out features and respond to client input
> > extremely rapidly. This lets you get something released that
> > satisfies the business problem, even if the business problem keeps
> > changing on you. Once things have settled down, you can then add
> > AJAXian improvements to individual pages of the application at a
> > granular /tactical level, as a series of controlled, low-risk projects.
> >
>
>
>
>------------------------ Yahoo! Groups Sponsor --------------------~-->
><font face=arial size=-1><a
>href="<http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131.6882499.7825260.1510227/D\
=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2889191/R=0/SIG=10r90krvo/*http\
://www.thebeehive.org>http://us.ard.yahoo.com/SIG=12hfqaacf/M=362131.6882499.782\
5260.1510227/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123718751/A=2889191/R=0/SIG=1\
0r90krvo/*http://www.thebeehive.org">Get
>Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life
>- brought to you by One Economy</a>.</font>
>--------------------------------------------------------------------~->
>
>
>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
----^-------^------^--------^-------^

Is this actually true though? The experience on our team has been that even
simple things in DHTML / AJAX take a significant amount of work (mostly due
to cross browser issues).

Our experience on apps /widgets where we are doing one in Ajax and one in
Flash, is that in general Flash development has been quicker for two main
reasons:
     -Flash has a strong component framework in the Flex framework (I suspect
that AJAX / DHTML will get this soon)
     -Not having to deal with cross browser issues

However, this does not take into consideration that my team already has
Flash and AJAX/DHTML experience (which other teams may not have). If you
only know AJAX/DHTML then that is going to be the fastest solution for you
(at least in the short term).

I am curious with what other's experiences have been?

mike chambers

mesh@...

----- Original Message -----
From: "Jonathan Boutelle" <jon@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Wednesday, August 10, 2005 1:36 PM
Subject: RE: [ajax_and_ria] Adaptive Path interviews Flickr


> I think that the comment about agile development is very relevant. I
> think that's one key thing to consider when deciding where to use
> rich client technologies.
>
> DHTML lets you can roll out features and respond to client input
> extremely rapidly. This lets you get something released that
> satisfies the business problem, even if the business problem keeps
> changing on you. Once things have settled down, you can then add
> AJAXian improvements to individual pages of the application at a
> granular /tactical level, as a series of controlled, low-risk projects.
>

This is an interesting discussion indeed.  Flash and DTHML can both be
used to accomplish very similar things in application point of view.
The further towards animated and graphic design intense user interfaces
you go Flash becomes a better point, the further towards structured
information system or business app type interfaces DHTML seems to be a
better choice.

Using HTML on it's own is very fast to put together screens, display
data and accept input through forms.  Moving AJAX provides huge benefits
to the end user in terms of response performance and usability, however
I think makes development cycles longer and more complicated for
developers.  Incremental (agile) type improvements may be quick but it's
definitely slower than basic forms.

Does anyone on the list have any examples of standard html interfaces
that they've ported to an RIA model, either Flash or AJAX?  And the
usability benefits weighed against the increased development time and
cost?  Is it easier to add features and enhancements to an AJAX
interface or a Flash interface?

Looking forward to your responses and a more indepth usability
discussions!

Andre Charland.



-----Original Message-----
From: ajax_and_ria@yahoogroups.com [mailto:ajax_and_ria@yahoogroups.com]
On Behalf Of Jonathan Boutelle
Sent: Wednesday, August 10, 2005 1:36 PM
To: ajax_and_ria@yahoogroups.com
Subject: RE: [ajax_and_ria] Adaptive Path interviews Flickr

I think that the comment about agile development is very relevant. I
think that's one key thing to consider when deciding where to use rich
client technologies.

DHTML lets you can roll out features and respond to client input
extremely rapidly. This lets you get something released that satisfies
the business problem, even if the business problem keeps changing on
you. Once things have settled down, you can then add AJAXian
improvements to individual pages of the application at a granular
/tactical level, as a series of controlled, low-risk projects.

I use Flash for sections of my application that have to be highly
interactive and immersive, and HTML (that I plan to upgrade to AJAX) for
the sections of my application that I know are going to be subject to
rapid, continual change.

I use Flash for the sections of my application that have to wow the
customer, and HTML (that I plan to upgrade to AJAX) for the sections of
the application that are used by administistrators, IT staff, etc.

-Jonathan Boutelle

At 11:50 AM 8/9/2005, you wrote:
>See Eric's comment, "Although the Flash application was, I think, a
>really innovative interface, and really fun to use, and a lot of people

>enjoyed it, I think it was a little too off the beaten path to really
>get a wide audience."
>
>Do you think he means the application's features were too far off the
>beaten path, or the UI technology stack (i.e., Flash)? In the context,
>I thought he meant that a Flash UI was too far away from what users
>expect from a web-based UI. It jumped out at me because I have heard
>the comment before and so I take interest in articles that attempt to
>describe exactly what users are missing when they use a Flash UI.
>
>I see 9 references to Flash, mostly in the past tense. Reading between
>the lines, I got the sense that maintaining their agile development
>process might also be related, but I do not know enough about their
>tools and technologies to do anything more than speculate.
>
>Ben
>805-403-2380
>484-377-1830 (FAX)
><http://www.benallfree.com/>www.benallfree.com
>
>
>
>
>----------
>From: ajax_and_ria@yahoogroups.com
>[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of Mike Chambers
>Sent: Tuesday, August 09, 2005 10:49 AM
>To: ajax_and_ria@yahoogroups.com
>Subject: Re: [ajax_and_ria] Adaptive Path interviews Flickr
>
>If anything, the article is about Flickr's evolution from a real time
>chat / image sharing app, to a more persistent web based photo sharing
>site. I don't think it really has much to do with any choice between
>Flash and AJAX (unless you are equating Web development with AJAX)
>
>Btw, Flickr still leverages Flash, although they did switch from Flash
>to browser based solutions in areas where it made sense (such as
>displaying images).
>
>mike chambers
>
>mesh@...
>
>----- Original Message -----
>From: "Benjamin C. Allfree" <benles@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Tuesday, August 09, 2005 6:06 AM
>Subject: [ajax_and_ria] Adaptive Path interviews Flickr
>
>
> > Just in case anyone missed it:
> >
> <http://www.adaptivepath.com/publications/essays/archives/000519.php>h
> ttp://www.adaptivepath.com/publications/essays/archives/000519.php
> >
> >
> >
> > It's an interesting read about Flickr's choice between Flash and
Ajax.
> >
> >
> >
> > Ben
> > 805-403-2380
> >
> > 484-377-1830 (FAX)
> >  <<http://www.benallfree.com/>http://www.benallfree.com/>
> www.benallfree.com
> >
> >
> >
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group
> "<http://groups.yahoo.com/group/ajax_and_ria>ajax_and_ria" on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    *
> <mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>a
> jax_and_ria-unsubscribe@yahoogroups.com
>
>    *
>    *  Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

----^-------^------^--------^-------^
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 --------------------~-->
<font face=arial size=-1><a
href="http://us.ard.yahoo.com/SIG=12hrlo1fm/M=362329.6886308.7839368.151
0227/D=groups/S=1705351788:TM/Y=YAHOO/EXP=1123713374/A=2894321/R=0/SIG=1
1dvsfulr/*http://youthnoise.com/page.php?page_id=1992
">Fair play? Video games influencing politics. Click and talk
back!</a>.</font>
--------------------------------------------------------------------~->


Yahoo! Groups Links

I think that the comment about agile development is very relevant. I
think that's one key thing to consider when deciding where to use
rich client technologies.

DHTML lets you can roll out features and respond to client input
extremely rapidly. This lets you get something released that
satisfies the business problem, even if the business problem keeps
changing on you. Once things have settled down, you can then add
AJAXian improvements to individual pages of the application at a
granular /tactical level, as a series of controlled, low-risk projects.

I use Flash for sections of my application that have to be highly
interactive and immersive, and HTML (that I plan to upgrade to AJAX)
for the sections of my application that I know are going to be
subject to rapid, continual change.

I use Flash for the sections of my application that have to wow the
customer, and HTML (that I plan to upgrade to AJAX) for the sections
of the application that are used by administistrators, IT staff, etc.

-Jonathan Boutelle

At 11:50 AM 8/9/2005, you wrote:
>See Eric's comment, "Although the Flash application was, I think, a
>really innovative interface, and really fun to use, and a lot of
>people enjoyed it, I think it was a little too off the beaten path
>to really get a wide audience."
>
>Do you think he means the application's features were too far off
>the beaten path, or the UI technology stack (i.e., Flash)? In the
>context, I thought he meant that a Flash UI was too far away from
>what users expect from a web-based UI. It jumped out at me because I
>have heard the comment before and so I take interest in articles
>that attempt to describe exactly what users are missing when they
>use a Flash UI.
>
>I see 9 references to Flash, mostly in the past tense. Reading
>between the lines, I got the sense that maintaining their agile
>development process might also be related, but I do not know enough
>about their tools and technologies to do anything more than speculate.
>
>Ben
>805-403-2380
>484-377-1830 (FAX)
><http://www.benallfree.com/>www.benallfree.com
>
>
>
>
>----------
>From: ajax_and_ria@yahoogroups.com
>[mailto:ajax_and_ria@yahoogroups.com] On Behalf Of Mike Chambers
>Sent: Tuesday, August 09, 2005 10:49 AM
>To: ajax_and_ria@yahoogroups.com
>Subject: Re: [ajax_and_ria] Adaptive Path interviews Flickr
>
>If anything, the article is about Flickr's evolution from a real time chat /
>image sharing app, to a more persistent web based photo sharing site. I
>don't think it really has much to do with any choice between Flash and AJAX
>(unless you are equating Web development with AJAX)
>
>Btw, Flickr still leverages Flash, although they did switch from Flash to
>browser based solutions in areas where it made sense (such as displaying
>images).
>
>mike chambers
>
>mesh@...
>
>----- Original Message -----
>From: "Benjamin C. Allfree" <benles@...>
>To: <ajax_and_ria@yahoogroups.com>
>Sent: Tuesday, August 09, 2005 6:06 AM
>Subject: [ajax_and_ria] Adaptive Path interviews Flickr
>
>
> > Just in case anyone missed it:
> >
>
<http://www.adaptivepath.com/publications/essays/archives/000519.php>http://www.\
adaptivepath.com/publications/essays/archives/000519.php
> >
> >
> >
> > It's an interesting read about Flickr's choice between Flash and Ajax.
> >
> >
> >
> > Ben
> > 805-403-2380
> >
> > 484-377-1830 (FAX)
> >  <<http://www.benallfree.com/>http://www.benallfree.com/>
> www.benallfree.com
> >
> >
> >
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group
> "<http://groups.yahoo.com/group/ajax_and_ria>ajax_and_ria" on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    *
>
<mailto:ajax_and_ria-unsubscribe@yahoogroups.com?subject=Unsubscribe>ajax_and_ri\
a-unsubscribe@yahoogroups.com
>
>    *
>    *  Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

----^-------^------^--------^-------^
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
----^-------^------^--------^-------^

Comments below:

----- Original Message -----
From: "Benjamin C. Allfree" <benles@...>

> Do you think he means the application's features were too far off the
beaten
> path, or the UI technology stack (i.e., Flash)? In the context, I thought
he
> meant that a Flash UI was too far away from what users expect from a
> web-based UI. It jumped out at me because I have heard the comment before
> and so I take interest in articles that attempt to describe exactly what
> users are missing when they use a Flash UI.

I read that basically Flickr as real time chat / photosharing app, wasn't
taking off, and so they shifted their focus. I.e. the big change (in this
context) was about what Flickr is, and not what technologies they used to
build it.

> I see 9 references to Flash, mostly in the past tense. Reading between the
> lines, I got the sense that maintaining their agile development process
> might also be related, but I do not know enough about their tools and
> technologies to do anything more than speculate.
>

Yeah, but those references are to the initial chat app. I don't know about
all of the examples, but in the case of them moving displaying pictures from
Flash to HTML, I think that was about what was the best way to accomplish
that (which is HTML).

Regardless, they still leverage Flash in a pretty big way (where it make
sense).

We should get Eric on the list...

mike chambers

mesh@...

If anything, the article is about Flickr's evolution from a real time chat /
image sharing app, to a more persistent web based photo sharing site. I
don't think it really has much to do with any choice between Flash and AJAX
(unless you are equating Web development with AJAX)

Btw, Flickr still leverages Flash, although they did switch from Flash to
browser based solutions in areas where it made sense (such as displaying
images).

mike chambers

mesh@...

----- Original Message -----
From: "Benjamin C. Allfree" <benles@...>
To: <ajax_and_ria@yahoogroups.com>
Sent: Tuesday, August 09, 2005 6:06 AM
Subject: [ajax_and_ria] Adaptive Path interviews Flickr


> Just in case anyone missed it:
> http://www.adaptivepath.com/publications/essays/archives/000519.php
>
>
>
> It's an interesting read about Flickr's choice between Flash and Ajax.
>
>
>
> Ben
> 805-403-2380
>
> 484-377-1830 (FAX)
>  <http://www.benallfree.com/> www.benallfree.com
>
>
>
>
>
>
>
>   _____
>
> From: ajax_and_ria@yahoogroups.com [mailto:ajax_and_ria@yahoogroups.com]
On
> Behalf Of Julian Suggate
> Sent: Sunday, August 07, 2005 7:47 PM
> To: ajax_and_ria@yahoogroups.com
> Subject: [ajax_and_ria] Hello and a question
>
>
>
> Hello I'm new to the list. I've just been transferred to a new AJAX
> project that is starting up at my company. I come from a programming
> background, but have spent the last nine months working on a
> Flash/Actionscript RIA which involved plenty of usability focus too.
>
> I'm not sure if it's off-topic to ask general Javascript questions here?
>
> We are looking for a feature-rich javascript context menu system we
> can use on our project. I have searched the web and forums etc but
> usually I seem to get a lot of junk. It must support: right-click
> popup, IE5.5 (not moz currently), icons for menuitems, cascading
> submenus, and something to indicate when a given menuitem is currently
> enabled/in use (eg a 'tick' in the margin or something).
>
> We have looked at jsDOMenu and it supports nearly all our requirements
> except ticks in the margin. This is a bit of a showstopper for us.
> Also, it is GPL'ed, and while we are happy to use open-source tools we
> would prefer an LGPL or looser license to avoid problems.
>
> Has anyone built or know of a tool that would suit our needs? Our
> client can pay for licensing.
>
> To anyone that can help, Thanks! And to the rest of yiz, cheers, thanks
> anyway.
>
>
> Jules
>
>
>
>   _____
>
> 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!
> <http://docs.yahoo.com/info/terms/>  Terms of Service.
>
>
>
>   _____
>
>

Hello I'm new to the list. I've just been transferred to a new AJAX
project that is starting up at my company. I come from a programming
background, but have spent the last nine months working on a
Flash/Actionscript RIA which involved plenty of usability focus too.

I'm not sure if it's off-topic to ask general Javascript questions here?

We are looking for a feature-rich javascript context menu system we
can use on our project. I have searched the web and forums etc but
usually I seem to get a lot of junk. It must support: right-click
popup, IE5.5 (not moz currently), icons for menuitems, cascading
submenus, and something to indicate when a given menuitem is currently
enabled/in use (eg a 'tick' in the margin or something).

We have looked at jsDOMenu and it supports nearly all our requirements
except ticks in the margin. This is a bit of a showstopper for us.
Also, it is GPL'ed, and while we are happy to use open-source tools we
would prefer an LGPL or looser license to avoid problems.

Has anyone built or know of a tool that would suit our needs? Our
client can pay for licensing.

To anyone that can help, Thanks! And to the rest of yiz, cheers, thanks anyway.


Jules

--- In ajax_and_ria@yahoogroups.com, Cedric Savarese
<c.savarese@4...> wrote:
> Hi Folks,
>
> I was wondering if anyone had experience running automated tests on
Ajax
> applications ? Is there any test suite capable of running
javascript and
> performing acceptance tests on a dynamic DOM ? (ie. a DOM modified
> through javascript/xmlhtttprequests).
>
> Thanks,
>
> Cedric


Our customers have used Mercury Interactive's WinRunner product for
testing rich client side applications built with TIBCO General
Interface -- an AJAX based rich Internet application framework.  The
API to TIBCO General Interface's client-side engine may have helped
since it insulated some of the more traditional DOM manipulation
challenges and provided for an easier scripting interface.  More info
at http://www.mercury.com/us/products/quality-center/functional-
testing/winrunner/ and http://www.tibco.com/mk/2005/ajax.html

--Kevin Hakman
   TIBCO General Interface

Hi Folks,

I was wondering if anyone had experience running automated tests on Ajax
applications ? Is there any test suite capable of running javascript and
performing acceptance tests on a dynamic DOM ? (ie. a DOM modified
through javascript/xmlhtttprequests).

Thanks,

Cedric

Hi guys,

I am new to the group and hope to find here a great medium for idea
exchange in the RIA space.

I represent Midnight Coders and would like to announce the release of
our new product - WebORB. The product is a platform for development and
hosting of Flash and JavaScript/AJAX-based rich client applications.
WebORB is available for Java and .NET environments. For the AJAX clients
we provide a library tagged "Rich Client System". The library provides a
set of APIs to enable client/server connectivity and data binding. In
the future the library will include UI widgets, event framework,
drag-n-drop, etc. As for the Flash clients, the product supports the
same protocol used by Macromedia's Flash Remoting. As a result, any
Flash Remoting client can connect to any of the supported service types
using WebORB.

On the server side we support Java and .NET objects, xml web services,
EJBs and ColdFusion Components, so an AJAX or Flash client can bind to
an invoke any method on the above mentioned service types. Here are a
few highlights of the product:

   * Proxies generated by the Rich Client System support synchronous and
asynchronous method invocations
   * Product does not require any modifications on the server-side code,
no need for custom method attributes, special signatures or argument
types. Does not require design-time stub generation either.
   * The same server-side method can be invoked by client synchronously
or asynchronously.
   * Synchronous invocations return data from the same invocation thread
(no callback needed). Asynchronous invocations rely on a callback.
   * Client application can request special activation modes for the
server objects. As a result objects can easily become stateful without
any special programming
   * Provides a special API for handling database query results - server
code can return DataSets or DataTables and the client presents it as a
special RecordSet JavaScript object. The object provides a way to
retrieve column names as well as row data
   * Supports data paging. Client applications can retrieve data in pages
and streamline user experience.
   * Supports all server-side argument types as well as return values -
primitives, strings, complex types, arrays, native .net collections,
remote references
   * Server objects can be secured on a per method, class,
namespace/package level. Product allows custom authentication and
authorization handlers
   * There are 2 editions available: Standard (free) and Professional
(commercial license)

Some links that may be of interest to you:

Product info: http://www.themidnightcoders.com/weborb/aboutWeborb.htm
Online examples: http://www.themidnightcoders.com/examples
Rich Client System info: http://www.themidnightcoders.com/rcs/
Service binding API: http://www.themidnightcoders.com/doc20/?t=34
Service invocation API: http://www.themidnightcoders.com/doc20/?t=330

thanks,
Joe

--------------------------------
Joe Orbman, Chief Architect
Midnight Coders, LLC
http://www.themidnightcoders.com

I've been asked to clarify what the product announcements policy is
for this email list. Frankly, it's something I hadn't thought of till
now.

We're living in an attention economy, and the list will surely attract
people who want to tell us about their new products. My initial
reaction is to allow it (one reason I want this list up is to find out
about rich-client related stuff faster). Only one announcement per
product would be allowed, to stop spam.

If anyone has strong feelings either way, chime in. I don't want to
abuse your inbox.

I agree with Chris ... if I'm going to buy something frameworky
(something that effects the structure of the whole code) I'd want it
to be from either a)a big company that I can count on to exist next
year, or b)an open source community with momentum. Preferably (b), but
(a) is also an option.

What I'm hearing the .net guys (who have access to a viable component
marketplace) say is that if you're just buying widgets, who cares if
the company is going to be in business next year. It's not a
committment, at least not on the same level as buying a framework and
becoming an expert in it is.

.Net and Flash both provide an overall architectural context within
which you can buy interchangable components. That's something missing
from the world of DHTML hackery in general.

-Jonathan

--- In ajax_and_ria@yahoogroups.com, "Christian Cantrell"
<ccantrell@m...> wrote:
> My fear would be that these companies wouldn't stay in business, then
> I'd be stuck with a solution that:
>
> 1. Won't evolve as browsers change.
> 2. Won't be updated with new functionality.
> 3. Won't have bugs fixed.
>
> Then I'd be faced with the question of either investing more time
> hacking away at the code, or migrating to another solution.
>
> If I were going to go with an Ajax framework/toolkit, I would want one
> from a company I trusted (something like Microsoft's Atlas), or one that
> was open source and seemed to have enough momentum that it would
> continue to be developed.
>
> Christian

My fear would be that these companies wouldn't stay in business, then
I'd be stuck with a solution that:

1. Won't evolve as browsers change.
2. Won't be updated with new functionality.
3. Won't have bugs fixed.

Then I'd be faced with the question of either investing more time
hacking away at the code, or migrating to another solution.

If I were going to go with an Ajax framework/toolkit, I would want one
from a company I trusted (something like Microsoft's Atlas), or one that
was open source and seemed to have enough momentum that it would
continue to be developed.

Christian

I guess I'm not ready to trust any Ajax framework yet to let it do
high-level stuff. Maybe it's because of my experience dealing with
proprietary technologies (.NET, and a while ago Notes/Domino) where I
often found myself spending more time trying to undo what the framework
generates by default than if I had written the whole thing from scratch.
I'd rather use low-level libraries (like Sarissa) that takes care of the
cross-browser scripting hassle and leaves the high-level stuff to me.

As for the proprietary vs. open-source question, it looks that some
proprietary products have features not yet supported by open-source
frameworks (Backbase's back button and deep linking ?).

Cedric
www.formassembly.com


Benjamin C. Allfree wrote:

> I do a lot of development in ASP.NET and prefer components that hide
> the Ajax details from me. For example, Dart’s PowerWEB LiveControls
> suite is modeled after the standard ASP.NET web controls, but uses
> Ajax behind the scenes to do JS postbacks and adjust DIV layers.
> Contrast that to a library like Ajax.Net which leaves you to write
> your own JS/DHTML update code.
>
> So while I am in support of high-level toolkits like LiveControls, I
> do think that it’s nice to have the source code if only for the
> purposes of debugging, especially when it includes server-side logic
> that might otherwise be compiled.
>
> Lock-in is not a grave concern of mine because I think development
> cycles are short enough that components get swapped in and out all the
> time in favor of newer, better solutions. Again, this is from the
> ASP.NET perspective which is very component-oriented.
>
> Ben
> 805-403-2380
>
> 484-377-1830 (FAX)
> www.benallfree.com <http://www.benallfree.com/>
>
> ------------------------------------------------------------------------
>
> *From:* ajax_and_ria@yahoogroups.com
> [mailto:ajax_and_ria@yahoogroups.com] *On Behalf Of *jonathanboutelle
> *Sent:* Wednesday, August 03, 2005 10:06 AM
> *To:* ajax_and_ria@yahoogroups.com
> *Subject:* [ajax_and_ria] Is using a proprietary AJAX toolkit ever a
> good idea?
>
> I'm wondering what the people on this list think of the new
> proprietary AJAX toolkits/APIs that are springing up. (I'm thinking of
> things like TIBCO, backbase, jway, jackbe, etc).
>
> I'm sure that thes toolkits are more mature than their open-source
> cousins (RICO, SAJAX, Ruby on Rails). But the vendor lock-in issues
> that they bring seem really troubling to me. Why (as a developer)
> would I want to become an expert in such a specific proprietary tool?
>
> If anyone has experience or thoughts to share on this topic (pro or
> con), I'd love to hear them.
>
> Regards,
> -Jon
>
>
>
> ------------------------------------------------------------------------
> 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/>.
>
>
> ------------------------------------------------------------------------
>

I'm wondering what the people on this list think of the new
proprietary AJAX toolkits/APIs that are springing up. (I'm thinking of
things like TIBCO, backbase, jway, jackbe, etc).

I'm sure that thes toolkits are more mature than their open-source
cousins (RICO, SAJAX, Ruby on Rails). But the vendor lock-in issues
that they bring seem really troubling to me. Why (as a developer)
would I want to become an expert in such a specific proprietary tool?

If anyone has experience or thoughts to share on this topic (pro or
con), I'd love to hear them.

Regards,
-Jon

Hello all,

I'd like to thank everybody for signing up to the AJAX/RIA list. The
response has been really encouraging: as of today, we have 29 members.

I'm hoping that this will be a place for people who are interested in
developing rich client experiences to share tips, tricks, and thoughts
about the industry in an open-minded fashion. In particular, I'm
hoping to start a conversation between the swf-based RIA community and
the javascript-based RIA community. We are dealing with many of the
same design problems, even if we use different tools.

More in a bit...
-Jonathan Boutelle