ICEfaces
  1. ICEfaces
  2. ICE-7740

New ace:submitMonitor component

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2.BETA1, 3.2
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 3.1, ACE Components

      Description

      Create a new ace:activityIndicator component that will provide configurable activity indication while a submit is in progress.

      This component may take a couple of forms:

      1. Classic mode which resembles the ice:outputConnectionStatus component where you place it on the page and it shows progress, error status for all ajax submits on that page, or possible via specifying which forms it should work with(?)

      2. Per component where the indicator would appear over the component/container only while an ajax submit was underway triggered by that component. This would be similar to the current blockUIOnSubmit behaviour, but specified per component. Specifying it on a container would have it work for all child components within the container.

      This may be 2 separate components if that makes more sense.

        Issue Links

          Activity

          Hide
          Ken Fyten added a comment - - edited

          I've noticed while playing with the new component that it can be quite jarring if the modal layer / busy indicator is displayed during a very short-lived submit (<500 millis) as it appears as a quick flash that might even cause problems for anyone susceptible to seizures. I would suggest that we adjust the component behaviour to delay presentation of the modal layer and activity indicator/message until at least 500 millis have transpired, thus avoiding the quick flashing behaviour.
          Here is a reference on this subject:

          What sort of Progress Indicator will you use?
          A well known set of guidelines is summarised in Jakob Nielsen's Usability Engineering. As a quick summary:

          • If the delay is less than 0.1 second, the user will feel it's instantaneous. No feedback necessary.
          • If the delay is between 0.1 second and 1 second, the user will notice it but it won't break their flow of thought. No feedback necessary.
          • If the delay is between 1 and 10 seconds, the user's flow of thought is interrupted as they await the response. Basic feedback necessary, i.e. an indication that a delay is occurring. Ajax examples include animated icons and simple text messages.
          • If the delay is greater than 10 seconds, the user will want to proceed onto other tasks. Detailed feedback necessary. Ajax examples include progress meters and messages showing current state.
            The precise figures may require some adjustment and I suspect a web context requires them to be dropped a bit. For example, users will probably want some feedback for a delay of 0.5 seconds rather than 1 second, and more detailed information is probably appropriate after 2-3 seconds rather than 10 seconds.

          If we are concerned about not blocking user input for the first 500 millis, perhaps we could implement user event blocking immediately and only style the overlay darker and display the activity monitor/message after 500 millis.

          Show
          Ken Fyten added a comment - - edited I've noticed while playing with the new component that it can be quite jarring if the modal layer / busy indicator is displayed during a very short-lived submit (<500 millis) as it appears as a quick flash that might even cause problems for anyone susceptible to seizures. I would suggest that we adjust the component behaviour to delay presentation of the modal layer and activity indicator/message until at least 500 millis have transpired, thus avoiding the quick flashing behaviour. Here is a reference on this subject: What sort of Progress Indicator will you use? A well known set of guidelines is summarised in Jakob Nielsen's Usability Engineering. As a quick summary: If the delay is less than 0.1 second, the user will feel it's instantaneous. No feedback necessary. If the delay is between 0.1 second and 1 second, the user will notice it but it won't break their flow of thought. No feedback necessary. If the delay is between 1 and 10 seconds, the user's flow of thought is interrupted as they await the response. Basic feedback necessary, i.e. an indication that a delay is occurring. Ajax examples include animated icons and simple text messages. If the delay is greater than 10 seconds, the user will want to proceed onto other tasks. Detailed feedback necessary. Ajax examples include progress meters and messages showing current state. The precise figures may require some adjustment and I suspect a web context requires them to be dropped a bit. For example, users will probably want some feedback for a delay of 0.5 seconds rather than 1 second, and more detailed information is probably appropriate after 2-3 seconds rather than 10 seconds. If we are concerned about not blocking user input for the first 500 millis, perhaps we could implement user event blocking immediately and only style the overlay darker and display the activity monitor/message after 500 millis.
          Hide
          Mark Collette added a comment - - edited

          We never know how long a request will take. We could delay 500 ms, and then the request will only take a further 100 ms, and it will be a flicker. It's important to not delay too long, so the user won't think the system is laggy or that they fail to initiate the submit.

          Show
          Mark Collette added a comment - - edited We never know how long a request will take. We could delay 500 ms, and then the request will only take a further 100 ms, and it will be a flicker. It's important to not delay too long, so the user won't think the system is laggy or that they fail to initiate the submit.
          Hide
          Ken Fyten added a comment - - edited

          Updated the active and idle icons.
          This JIRA is now resolved.

          Show
          Ken Fyten added a comment - - edited Updated the active and idle icons. This JIRA is now resolved.
          Hide
          Migration added a comment - - edited

          Added capability for old SubmitMonitor javascript instances to clean themselves up, and not interfere with subsequent instances, which are created when the ace:submitMonitor properties are changed or when the component is updated. This ties into the onElementUpdate feature that was ported into this branch.
          Tested against QA submitMonitor test app, specifically submitMonitorFor, submitMonitorRepeat pages, and a hybrid, with the Repeat sections that cause large updates added into the For page.
          Two caveats with the cleanup functionality found are:
          1. ICE-8580 onElementUpdate is not called when the document body is updated
          2. ICE-8579 There is no way to remove the submit listeners, so right now instances are leaked, but flag themselves to discontinue processing
          patch branch
          Subversion 30882 submitmonitor.js
          Subversion 30883 application.js

          Show
          Migration added a comment - - edited Added capability for old SubmitMonitor javascript instances to clean themselves up, and not interfere with subsequent instances, which are created when the ace:submitMonitor properties are changed or when the component is updated. This ties into the onElementUpdate feature that was ported into this branch. Tested against QA submitMonitor test app, specifically submitMonitorFor, submitMonitorRepeat pages, and a hybrid, with the Repeat sections that cause large updates added into the For page. Two caveats with the cleanup functionality found are: 1. ICE-8580 onElementUpdate is not called when the document body is updated 2. ICE-8579 There is no way to remove the submit listeners, so right now instances are leaked, but flag themselves to discontinue processing patch branch Subversion 30882 submitmonitor.js Subversion 30883 application.js
          Hide
          Oscar Stigzelius added a comment -

          The component ace:submitMonitor is useless nowadays due to the changes in this bug: ICE-10518. Now the element ace:submitMonitor with the attribute blockUI=@none (Which is specific for every form) will not stop the blockUIOnSubmit setting (Which is specific for every page).

          I've added a comment to the issue here: ICE-10518 comment.

          I've also created a new issue about this: ICE-11454.

          Show
          Oscar Stigzelius added a comment - The component ace:submitMonitor is useless nowadays due to the changes in this bug: ICE-10518 . Now the element ace:submitMonitor with the attribute blockUI=@none (Which is specific for every form) will not stop the blockUIOnSubmit setting (Which is specific for every page). I've added a comment to the issue here: ICE-10518 comment . I've also created a new issue about this: ICE-11454 .

            People

            • Assignee:
              Mark Collette
              Reporter:
              Evgheni Sadovoi
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: