Re: Adobe's RIA Technologies

["Mark Allen" <scprideandms@xxxxxxxxx>]

My coke rewards has to be one of the WORST designed web sites EVER!!!

On Wed, Oct 29, 2008 at 7:07 PM, Dean, Robert <rdean@xxxxxxxxxxxx> wrote:

> My primary complaint about Flash-based applications is that the browser
> back button is pretty much useless. Instead, they put
> the user in a jail with limited options for navigating content intuitively
> (mycokerewards is a good example of this).
> ________________________________________
> From: web400-bounces@xxxxxxxxxxxx [web400-bounces@xxxxxxxxxxxx] On Behalf
> Of Nathan Andelin [nandelin@xxxxxxxxx]
> Sent: Wednesday, October 29, 2008 6:31 PM
> To: Web Enabling the AS400 / iSeries
> Subject: Re: [WEB400] Adobe's RIA Technologies
>
> > From: Pete Helgren
> > Great observations Nathan...
>
>
> Thanks for the feedback.  I'll share a few more observations.  My Flash
> based email client (gowebtop) provides a Login prompt as an application
> entry point.  It happily entertains with various visual transitions such as
> fade-in effects and progress bars while it transfers the code to display the
> login prompt, which takes about 15 seconds.  Actually the ubiquitous
> "Transfering ..." status never goes away so you're never quite sure when
> it's done.  Unfortunately it doesn't download code to set focus to the User
> ID input element, so I click on the input element to set focus.  And if you
> tab past the password prompt, the cursor moves to hidden fields, so you grab
> your mouse and click again.
>
> It takes another 15 seconds to authenticate the user and transfer more code
> to display the first screen.  You get used to the "Transfering ..." status.
>  I guess the point is that it takes quite a bit of code to display a set of
> windows and populate data elements.  So as Web applications go, it appears
> to me that Flash needs a lot of bandwidth to initially activate a screen.
>  After that, it behaves much like a desktop application from a functional
> point of view, except for the lag time to fetch new data from the server,
> which seems to run at the speed of HTTP plus whatever technology you use for
> responding to HTTP requests, where runtime performance ranges widely from
> one request to the next.  You never quite get the feeling that you're in
> control of the user interface because of widely differing lag times.
>  Sometimes it's quick.  Other times it's slow.
>
> Another pattern that seems to emerge in Flash based data entry applications
> is to store data locally, at least temporarily in memory, until the Save
> button is clicked.  Say you have a classroom gradebook for teachers, and you
> enter scores for 30 students in the course, then click the Save button.  In
> one demo I watched it took about 10 seconds to refresh the screen with new
> scores, which I think was running on a pretty much dedicated server.  You've
> got to hope that the service is not disrupted between the time the data
> entry window is displayed and the time the scores are posted.  That would
> make a teacher mad.
>
> But hey, the visual transitions are cool...
>
> Nathan.
>
>
>
>
> --
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
> --
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.