Taking Time Out To Improve the Ajax Experience
Anybody who downloaded the Ajax rating demo from last week and looked at the LotusScript agent which handled the process would have seen this line up at the top:
Sleep 2 'Give spinner gif chance to appear and make it more obvious to user that something is happening -- remove when live?
At first I'd added this line for my own sake, so I could test whether the animated gif (
) and the associated "Casting vote now..." text appeared, as expected. Sitting so close to my development server means that Ajax responses are received and processed in the blink of an eye. Unless paying careful attention it's easy to miss the spinner and message, thus thinking nothing happened.
The "remove when live" comment was originally meant for me but I left it in for you guys. The more I thought about it the more I thought it might be an idea to actually leave it in. This might sound perverse, but hear me out.
As a part of the overall user experience ("UX") the spinning gif is becoming an essential and accepted way of letting the user know something is happening. Especially when used with Ajax. Traditionally users are used to clicking an element on a webpage and the page reloading — changed in some way. Now that Ajax has done away with the need for a new page load it's essential we let the user know something is in fact happening and that the link they just clicked isn't broken. An animated spinning gif is the perfect way to do this.
This is especially true of a scenario like the document rating where the change to the page post-Ajax-call is quite subtle. The pages updates to say your vote has been cast and the rating itself updates (in most cases) but that's easily missed if it happens in a flash.
However, the spinning image is only any use if it's there long enough for the user to notice it. Hence making the agent sleep for two seconds before processing the request. It might seem an odd thing to do to code for such a massive negative impact on performance, but, in cases like this, the positive effect on UX outweighs performance. In my opinion anyway.
My only concern is the affect this may have on the server. Depending on the way you have your server configured, agents will run in different ways. As I understand it the default is for agents to run in series — one after the other. If this is the case then making an agent stall for two seconds is just going to create a queue of other agents waiting for it to finish. If this queue consists of lots of other agents with 2 second sleeps then the user is in for quite a wait!
One alternative is to keep the pause but to keep it in the browser by using the JavaScript window.setTimeout() method. Another alternative is to to do away with the pause and just make the result more obvious. I'm thinking the "Your vote has been cast" message has a coloured background or uses the YFT to bring the user's attention to it.
Either way, I'm interested to hear your opinion on this. Is it a good idea to create delays and what is the affect on the "agent manager"?
Skip to the 
You can subscribe to an individual
Delays are good - if you know your code has a very quick turn-around time and it is updating the page too fast for you ...
Another way of delaying the updates would be to set the delay in your javascript. Simply set the start and end times of the ajax call. Calculate the time difference and if it is less < 2 secs, sleep/wait 1 second then process the ajax call results ... this way you're not delaying any processing on the server side ...
What about if you changed the indication that something changed to the infamous fade to yellow. Perhaps in conjunction with the spinner.
In fact thinking about it the process should probably be - always fade to yellow to show the update and only show the spinner if you haven't received a response with x number of seconds (to show activity).
Did you guys read all the way to the end? ;o)
Nice ideas though -- great minds...
I swear that part was not there before ;-)
I totaly agree with u jack...
since i started using Ajax call to Domino Agents i always add such indicators on page to let user know that some processing is goin on and they dont close the browser .....
it is good to do so bcoz u don't know the TAT time of server which depends on how busy he is !!!
What r d disadvantage of Ajax call to agents ?
I once implemented "Ajax-save" on a form in application since it was a monstrous HTML-form (not made by me).
The problem before, was that the form took too long to (re)load on save. With the Ajax-save, the opposite was true. I ended up using a setTimeout( [hide indicator] )..
Jake, By default Domino will handle running more than one web agent at a time, bet there are a few gotchas that you will want to know about.
There are 3 thread queue models and the default one is a poor choice for most Domino apps in my opinion.
There are details here: {Link}
Quick Summary:
There are a number of worker threads that process http requests, regardless of whether they are going to run agents or not. In queue models 0 and 1, each thread has it own queue that requests are assigned to and each thread processes requests on its queue serially.
Thread model 2 has a single queue for all requests and each worker thread pulls the next request off the single queue.
The only difference between model 0 and 1 is that model 0 assigns requests to queues using a simple round robin, where model 1 assigns to the shorted queue.
The upshot of this is that unless you are using model 2, any delay to the processing of a request will delay all requests on the same queue. So you definitely don't want to put an intentional delay in any code.
From my point of view you should never have to put a delay in just so you can put in an indicator that something is being processed. Go with making the update more obvious after the fact.
Kerr, what about the "run web agents concurrently" setting, that still defaults to "disabled". I think that this applies, no matter what threading model you pick.
Harkpabst, you might be right that it's on by default. It a complete performance killer though, so I always turn it off.
My opinion, having worked on various Ajax enabled apps for the past several months, is that Jake is right on here in terms of UI responsiveness being in some cases too fast. I've been thinking about that exact same thing.
I think some of the frameworks out there take these ideas into account, from what I remember Ext is very smooth that way, the transitions from one state to another in the UI are well managed.
I do think those transitions should be managed in the Javascript and not on the server. Seems to me you leave yourself more flexibility that way.
My two cents...you could go with a "low tech" solution and use CSS to change the users cursor to an hourglass when the Ajax call is invoked, then change back to normal once the Ajax.responseText is returned. No need to slow down the back end agent.
While the hourglass cursor is not as eye catching as the spinning graphic, I would think that most users would understand that something is happening with an hourglass.
I agree with John and Glen. Put the delay on the browser end with a setTimeout(), not on the backend in an agent. If you start doing that, you could end up hammering the http process to death.
Remember, you don't have to process the information that you get from an ajax call right away. Let the browser sit on it, or spend some time doing happy graphics transitions.