Bug 385287 - Consider improving/changing wait feedback during ajax requests
Summary: Consider improving/changing wait feedback during ajax requests
Status: ASSIGNED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.5   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 332512
  Show dependency tree
 
Reported: 2012-07-17 07:19 EDT by Tim Buschtoens CLA
Modified: 2014-04-16 06:37 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Buschtoens CLA 2012-07-17 07:19:42 EDT
Currently the UI will give no immediate feedback that an ajax request is running. After 500ms  the mouse cursor will change to an wait icon, then nothing else happens. In my opinion this is not ideal because:

1) Often the rendering of the response takes longer than the request itself. So the time until the UI changes after a user interaction may well be over 500ms without any feedback at all.

2) If a request really takes a long time (lets say more than 3 seconds), the user can continue to interact with the UI, which he will becauser users are inpatient. As a result then next request may contain several events/UI updates, and all potentially based on an outdated UI state.

3) The wait cursor is not visible on tablets.

I would suggest to always change the cursor to a wait icon immediately. (So it may appear to ficker a bit sometimes, i would not consider this a problem.) Alternatively, it could change the cursor if the response contains more than a certain number of operations, predicting a longer time for rendering.

Also, i think we should consider to show a wait-popup (with an document overlay) if the request runs longer than 3-5 seconds. This also happens in windows 7 if an application becomes unresponsive. Usually this should never be seen by the user, as the application developer should use UI callback for operations that take a longer time.

Since the code for much of this is already in place, the changes would be relatively small.

On a related note, certain widgets could show some kind of wait-hint if they "know" that the server will change their visual appearance as a result of a request. I already did this for columns in two cases: A dragged column will "snap" to its now position after the request (triggered by the drop) is finished, and expanding/collapsing a column group will change the expand/collapse icon to a wait gif during the request. 

Other places where this could done is when tree items are resolved or when switching in a tabfolder.
Comment 1 Tim Buschtoens CLA 2013-02-06 08:34:50 EST
As of commit a1940d7046d24dc2e7f5cbd79ad1967dd3111c33 RAP shows an overlay with an loading gif if the request takes longer than 1 second. It's themeable (SystemMessage-DisplayOverlay) and configurable (ConnectionMessages client service), but the Java API is still internal (which is why i won't close the bug yet).
Comment 2 Tim Buschtoens CLA 2013-02-13 10:47:56 EST
There are two minor issues I discovered:
1. During the initial request there might be a splash screen, which is then convered by the new overlay. A quickfix would be to disable the feature on the first request, but on the long term i feel it would be best to make it possible to use the same feature for splash screens in general.
2. The current waiting animation looks ugly against a non-white background. We should find one that always look good, or set it against a white box (needs more theming).
Comment 3 Tim Buschtoens CLA 2013-04-08 05:38:48 EDT
With commit 9b329d5fa61d7bac707d30cdcd8393e9da0c4b8f the initial requests no longer display the overlay.
Comment 4 Tim Buschtoens CLA 2013-04-24 06:31:17 EDT
With commit 35e11b98de65b76f8b7882abd49625dbf33a096a the key events are also blocked while the overlay is visible.
Comment 5 Ivan Furnadjiev CLA 2014-04-16 06:37:01 EDT
Tim, can we close this bug as fixed?