× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.