The best way to trigger browser busy/loading state for AJAX request?

[bootle]

Hey,

I've been searching all around internet for a solution to make
browsers display loading information when accessing ajax content
(spinner on tab and/or in address bar, 'loading...' text as title etc.
- depending on browser). I'm looking for a behaviour like in Gmail and
Facebook (for some calls), best if it could be implemented for JSON
requests.

I found these two articles:

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
http://www.obviously.com/tech_tips/slow_load_technique

Before I start experimenting with that though,
I'm wondering if you know what would be the best way to achieve it
with mootools? Is there any existing class/extension to Request that
could make this easy or an approach you would recommend?

Many thanks guys,
Matt

[Ryan Florence]

onRequest: function(){ /* do whatever you want */ }

http://jsfiddle.net/rpflorence/NF2jz/187/

[Aaron Newton]

See also Spinner:

http://mootools.net/docs/more/Interface/Spinner

[Andrea Dessì]

maybe using the same "onRequest" (or a global one) for all of them you 

can create a stack and show a loading box 

in the proper way :)

--
Andrea Dessì

Email: nkj...@gmail.com
Skype: nkjoep
Blog: http://www.stealthefish.com/
LinkedIn: http://www.linkedin.com/in/andreadessi
Jabber: nkj...@gmail.com
Twitter: http://www.twitter.com/NKjoep

[bootle]

Thanks guys,

That's not what I'm looking for though. I have some big calls that
reload almost all the page (like Facebook, to say) and for these I
would like to give users "proper" loading feedback - as if the page
was loaded without AJAX. onRequest can just modify something within
HTML or temporarily change page title, but not change the state of the
browser.

Matt

On Jul 9, 8:14 am, Andrea Dessì <nkj...@gmail.com> wrote:
> maybe using the same "onRequest" (or a global one) for all of them you
> can create a stack and show a loading box
> in the proper way :)
>
> --
> Andrea Dessì
>
> Email: nkj...@gmail.com
> Skype: nkjoep
> Blog:http://www.stealthefish.com/
> LinkedIn:http://www.linkedin.com/in/andreadessi
> Jabber: nkj...@gmail.com
> Twitter:http://www.twitter.com/NKjoep
>
> On Fri, Jul 9, 2010 at 08:16, Aaron Newton <aa...@iminta.com> wrote:
> > See also Spinner:
>
> >http://mootools.net/docs/more/Interface/Spinner
>

> > On Thu, Jul 8, 2010 at 7:22 PM, Ryan Florence <rpflore...@gmail.com>wrote:
>
> >> onRequest: function(){ /* do whatever you want */ }
>
> >>http://jsfiddle.net/rpflorence/NF2jz/187/
>
> >> On Jul 8, 2010, at 7:07 PM, bootle wrote:
>
> >> > Hey,
>
> >> > I've been searching all around internet for a solution to make
> >> > browsers display loading information when accessing ajax content
> >> > (spinner on tab and/or in address bar, 'loading...' text as title etc.
> >> > - depending on browser). I'm looking for a behaviour like in Gmail and
> >> > Facebook (for some calls), best if it could be implemented for JSON
> >> > requests.
>
> >> > I found these two articles:
>

> >>http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-b...

[Ryan Florence]

Your question makes no sense to me.

Are you saying you want the browser to do everything it normally does when you load a new page (ie Safari, the address field starts filling up with a blue status bar, other browser have a spinner somewhere in the interface.)

If so, no, there's no direct way to do that. I guess onRequest you could create an iframe and point it to some page on your server that has a ridiculously long sleep time so the browser is always trying to load it, then onSuccess of the ajax request you could destroy the iframe. I don't kow ... seems silly. If you're reloading the whole page with ajax, and want it to feel like it's not ajax, why not just reload the whole page?

[Trevor Orr]

If I understand correctly you have multiple requests firing that replace most of the content on the page?  Then I would guess you would to create and display a spinner and then have some way to figure out when the last request has completed and remove the spinner. 

Maybe have a global variables that is incremented when a request starts and decrement when completed and then the variable gets down to 0 the spinner is removed.

Just a thought, and maybe not a good one.

[Aaron Newton]

On Fri, Jul 9, 2010 at 8:24 AM, Trevor Orr <frac...@gmail.com> wrote:

If I understand correctly you have multiple requests firing that replace most of the content on the page?  Then I would guess you would to create and display a spinner and then have some way to figure out when the last request has completed and remove the spinner.  

The Group class lets you do that.

How about just setting the document.body's css cursor property to the progress icon and then set it back when you're done?

I'm with Ryan here, I don't know what you're after. Can you point us to a site that behaves the way you want? I also agree: if you're loading an entirely new document via Ajax, you're doing it wrong. Just load a new document like normal. 

[bootle]

Ha, I know it doesn't sound like it does make too much sense - I have
a feeling that from user experience perspective it works pretty well
though. I am not reloading the whole page, header and footer stay in
place and AJAX load is at least a few times faster to load content
than reloading the whole page.

Yeah, it seems some hacky trick with an iFrame will have to be the
solution.

Thanks

[bootle]

How about just setting the document.body's css cursor property to
the progress icon and then set it back when you're done?

I'm doing it now + setting the page's <title> to "Loading...", that
doesn't give the exact feel I want to achieve though

I'm with Ryan here, I don't know what you're after. Can you point us
to a
site that behaves the way you want? I also agree: if you're loading an
entirely new document via Ajax, you're doing it wrong. Just load a new
document like normal.

For example Gmail and Facebook do it this way (Facebook only for the
main page loads though). Notice that when you load a 'new page' in
either of these the site never actually reloads, header and the chat
area stay intact, only the content is loaded - despite that, browser
displays all the loading whistles as with a classic page load - hope
I'm explaining it well enough

I have just one call that I want to handle this way, as I wrote to
Ryan, I think iframe might actually be a thing to experiment with.

Thanks,
Matt

On Jul 9, 4:37 pm, Aaron Newton <aa...@iminta.com> wrote:

[Ryan Florence]

>> I have some big calls that
>> reload almost all the page (like Facebook, to say)

I had to log in to facebook for the first time in forever to see what your'e talking about.

Facebook either has a little indicator next to the link you clicked (which is completely sufficient user feedback), or, in the case of moving to a user's profile, it reloads the whole page.

But facebook doesn't try to act like it's reloading the whole page when it's not.

[bootle]

Log in again, go to your profile, then click anything that would
reload the main content area (for example Info or Photos in the
topnav) and you will see what I'm talking about. In my first post I
said that Facebook only does it for some calls. The AJAX call they use
for it is a POST request: http://www.facebook.com/ajax/location_refresh.php

Is this email group about helping eachother and producing solutions to
problems or just about forcefully trying to prove the one who asked a
question is stupid?

Matt

[Ryan Florence]

Now that I know what you're talking about, I'm 95% sure that facebook is loading in iframes when you click those top tabs (like info, photos, etc). I also give it as my opinion that the iframes are there for purposes other than forcing the browser state to change, otherwise facebook would do that on every ajax call, not just a couple of them.

But there's your solution, as I mentioned before, just create an iframe and load something that will never finish loading, then kill it when the request is complete. I still don't think it's worth the extra request and extra code, but that's your decision.

> Is this email group about helping eachother and producing solutions to
> problems or just about forcefully trying to prove the one who asked a
> question is stupid?

If David Walsh is asking the question, yes, the point is to prove the asker is stupid. Otherwise, no, it's about helping people come to solutions.

Sorry, most the time I'm busy at work and so I just type quick emails to try to help out. The directness isn't meant to be rude, just quick.

However, that brings up a valid point about what types of solutions we're going to suggest. I have a hard time offering up a hack as a solution and would rather find out the real problem and then help somebody implement a real solution--not just what they think is the solution.

Before you get all frustrated with responses that aren't what you expect, keep in mind that a lot of the people on this group are professional web developers, people working on high profile sites like monster energy, visa, mtv, enterprise apps like cloudera's stuff, etc. So when they say "sounds like you're doing something wrong" don't forget where the advice is coming from. That's the best part about being involved with open source, interfacing with arguably some of the best developers out there. Without the help of people on this list I'd probably still be doing sites for http://nealthebarber.com (best site evar!)

And please remember, just because it sounds rude doesn't mean it is. It's email, it can always sound rude :)

[Paul Saukas]

Ryan we need to speak about retina damage.

[Ryan Florence]

Just let me know the cost, I'm sure my professional liability insurance will cover it.

[Aaron Newton]

I think I would rather have been rickrolled.

-Aaron

Sorry for any typos. Big fingers , tiny buttons.

[bootle]

Nah, I didn't mean rude, more like trying to get away with a simple
answer ;)

I still don't think it's worth the extra request and extra code, but
that's your decision.

I'll try. I don't think users care about a few extra lines of code,
but it definitely could make the site behave more 'natural' while
keeping the benefit of AJAX's speed.
I think, in general it would be cool to have an option to make an AJAX
call less asynchronous and force the browser's loading behavior when
needed, without using such hacks.

For now I'm thinking about a class, similar to Request.HTML that gets
stuff into an iframe, loads it, then returns the content into
onSuccess and removes the iFrame? Not AJAX, but might work - would
that make sense?

Cheers,
Matt

On Jul 9, 7:19 pm, Ryan Florence <rpflore...@gmail.com> wrote:
> Now that I know what you're talking about, I'm 95% sure that facebook is loading in iframes when you click those top tabs (like info, photos, etc).  I also give it as my opinion that the iframes are there for purposes other than forcing the browser state to change, otherwise facebook would do that on every ajax call, not just a couple of them.
>
> But there's your solution, as I mentioned before, just create an iframe and load something that will never finish loading, then kill it when the request is complete.  I still don't think it's worth the extra request and extra code, but that's your decision.
>
> > Is this email group about helping eachother and producing solutions to
> > problems or just about forcefully trying to prove the one who asked a
> > question is stupid?
>
> If David Walsh is asking the question, yes, the point is to prove the asker is stupid.  Otherwise, no, it's about helping people come to solutions.
>
> Sorry, most the time I'm busy at work and so I just type quick emails to try to help out.  The directness isn't meant to be rude, just quick.
>
> However, that brings up a valid point about what types of solutions we're going to suggest.  I have a hard time offering up a hack as a solution and would rather find out the real problem and then help somebody implement a real solution--not just what they think is the solution.
>

> Before you get all frustrated with responses that aren't what you expect, keep in mind that a lot of the people on this group are professional web developers, people working on high profile sites like monster energy, visa, mtv, enterprise apps like cloudera's stuff, etc.  So when they say "sounds like you're doing something wrong" don't forget where the advice is coming from.  That's the best part about being involved with open source, interfacing with arguably some of the best developers out there.  Without the help of people on this list I'd probably still be doing sites forhttp://nealthebarber.com(best site evar!)

[Ryan Florence]

> For now I'm thinking about a class, similar to Request.HTML that gets
> stuff into an iframe, loads it, then returns the content into
> onSuccess and removes the iFrame? Not AJAX, but might work - would
> that make sense?

If I was forced to code it I would have the request be a normal request and then add onRequest and onComplete events.

onRequest I'd create an iframe element with a src pointing to a file, that, on the server side (assuming php) is just a big long sleep(), like sleep(10000000000). That should force the browser into a "loading state".

And then onComplete destroy the iframe element.

I love to beat dead horses. A simple indicator by the link or over the content that's updating is enough ...

[Sanford Whiteman]

> onRequest I'd create an iframe element with a src pointing to a
> file, that, on the server side (assuming php) is just a big long
> sleep(), like sleep(10000000000). That should force the browser into
> a "loading state".

Hmm, yes, but consuming resources on the server, and IIRC if the
connection is severed at the client end, they won't be freed until
min(your_sleep_period,max_exec_time).

I think you'd be better off trickling bytes to the client way outside
of your HTTPD, so you don't tax your server proper at all. Something
like a tarpit daemon. I still think this whole idea is pretty strange,
though.

-- S.

[Aaron Newton]

<facepalm>

[jiggliemon]

@Ryan

OMG <--- meant to be rude.

-Chase

[Ryan Florence]

:D

Momentary lapse of reason...

Sent from my iPhone

[Jay]

I find my most creative work comes from being restricted from doing
something the way I'd initially want to do it. When being forced to
work within confined limits, you can often come up with an elegant
solution that's cooler and more usable than existing implementations.
Instead of having wacky IFrames and stuff, what if you would use a
slightly-less-standard paradigm for user feedback? Start with the
basics. To preach to the choir, I almost ALWAYS set the cursor
property if I'm doing time-consuming requests, as Mr. Newton
suggested. I'm not sure why, but even something as subtle as that
seems to have a huge effect on the user of the site. If you think you
need more feedback than that, what if you did a "Loading..." message
in the style of GMail? Something like that could integrate beautifully
with the design of your site, and would give your app a really novel
feel.

But, of course, it always depends what you're going for. If you really
really really need to simulate that browser behavior, IFrames are the
only way to go. However, I imagine that the extra requests to IFrames
+ extra load on your server + JavaScript overhead would make your AJAX
site load just as slowly (if not more so) than a traditional site,
which seems to defeat the purpose of AJAX in the first place
(especially when you consider its usability concerns for the outskirts
of the internet world -- screen readers, old web browsers, javascript-
blocking firewalls and paranoid javascript disablers. Coincidentally,
the people I find I need to emulate "traditional" methods for to avoid
confusing them are the same people that -- of course -- use screen
readers, old web browsers, and the like. At which point, I make sure
the site gracefully degrades, and kill two birds with one stone.

[André Fiedler]

@Jay That´s great! That´s the way i´m doing this, too. ;o)

2010/7/12 Jay <jay.d....@gmail.com>

[bootle]

Wow @Jay, that's a bit of a lecture there ;)

@Ryan, we've tried and tested the iframe approach you suggested and
I've got my answer:

Yup, you're right. The reason is speed, loading an iframe causes the
main ajax request to take about 30% longer in averege which is a lot
(even if it's only 100-200ms) so I gotta shelf the idea, at least
until I can get the speed facebook has achieved. Good lesson anyway!

Cheers all




On Jul 12, 10:23 am, André Fiedler <fiedler.an...@googlemail.com>
wrote:

> @Jay That´s great! That´s the way i´m doing this, too. ;o)
>

> 2010/7/12 Jay <jay.d.carl...@gmail.com>

[Fli7e]

Well - i might be a bit late on this but if you fire multiple ajax
request and want to keep your spinner or whatever indicator be active
until the last request fired its OK, why don't you just add a kind of
stack to your calls.

Set a global var and increase it on every ajax call "onStart".
Decrease the value on each "onComplete". If the value reaches 0,
remove your Indicators.

By this you have no forever waiting calls, iframes or whatever
overhead ..

maybe i am totaly wrong but this is how i would do it by what i've
understand about your problem. Maybe the following non working just
illustrated code helps to make my thoughts clear:

var AjaxCounter = 0;
var AjaxIndicator = false;

Request.HTML( ...

onStart: function(){
AjaxCounter++;
if( !AjaxIndicator )
{
AjaxIndicator = true;
// add your Indicators
}
}

onCompletet: function(){
AjaxCounter--;
if( AjaxCounter == 0 )
{
AjaxIndicator = false;
// remove your Indicators
}
}
...);

[Aaron Newton]

Or use the Group class in -more.