Moodle
  1. Moodle
  2. MDL-32837

Make the course AJAX load less jarring

    Details

    • Rank:
      39869

      Description

      Unfortunately the course ajax has a horrible visual jump and we can't just use jsenabled to eliminate it since its conditional on the ajaxenabled setting.

      The main problem is the move icons because they are changed from move buttons to a drag handle, and that changes the size of empty sections (making the affect really noticeable).

      Some thoughts:

      1/ Potentially use yui transition to make the effect less startling: http://yuilibrary.com/yui/docs/transition/transition-view.html
      2/ Use some other CSS class hiding based on settings?

        Issue Links

          Activity

          Hide
          Sam Hemelryk added a comment -

          Hi guys,

          Just a few thoughts I've got on this.

          First up Moodle approach to JavaScript and AJAX is that everything should work without it. This has lead in the past to JS and AJAX only having being used for enhancement and in turn user interfaces were very rarely (hesitantly) altered by JS when enhancing a page.
          Certainly people are coming up with some really great JS solutions that are much wanted and make use of new concepts and ideas within Moodle and these are requiring changes in pages in order to possible.

          I've been playing a bit with course editing and at the moment while I can see a visible jump I don't find it overly aggressive. For sure if we could avoid it, or minimise it that would be great.

          In regards to the suggestions made above.
          1. YUI transitions is one way to go, but to be truthful I don't think that is the best approach. Transitions are great for things like expanding/collapsing, or toggling the display of advanced items, however if we are talking about page components that are always going to be available (granted depending upon editing being on) then I think we are best to look for a solution in the design of the page and the javascript components. Adding transitions adds more yet more weight to a page and certainly trying to keep it down is advantageous as I'm sure many more JS solution will arrive in the future.
          2. Adding a CSS class to the body is ajax is enabled for the site I think is an entirely worthwhile endeavor. Even if it doesn't form part of the solution for this issue I think that is a valuable idea. Again as more and more JS arrives that is the sort of thing that implementing now will save countless varying solutions to the same problem from occurring in the future. This of course by itself doesn't constitute a solution, simply hiding things only gets us half way there at the moment as presently we have all things shifting in the page when JS loads.

          As for the complete solution as hinted at above I think we need to look at the design of the page when in editing mode. Especially the icons and placement of them.
          Ideally I think we should stick to the principle of enhancement and try to organise things in such a way that they meet the needs of both the conventional page and the AJAX page.
          Most of the JS that exists for editing has been revisited in the past couple of months and tidied up greatly.
          Certainly it is more possible now than it has been in the past to look at the design; more needed as well of course.
          When I say design by the way I mean where the icons are placed, the HTML that is holding them in place, their size and order, and perhaps even the icons themselves.

          In reflection to my opening statement I think we need to change the page to meet the needs of the JS (as well as the conventional page) and not have the JS make changes to the page (unless absolutely required).

          Anyway I think that about sums up my thoughts on the concept of this issue. I know that it doesn't provide any specific direction but hopefully it gives an insight into what I see as the direction this issue should be taken in finding a solution.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi guys, Just a few thoughts I've got on this. First up Moodle approach to JavaScript and AJAX is that everything should work without it. This has lead in the past to JS and AJAX only having being used for enhancement and in turn user interfaces were very rarely (hesitantly) altered by JS when enhancing a page. Certainly people are coming up with some really great JS solutions that are much wanted and make use of new concepts and ideas within Moodle and these are requiring changes in pages in order to possible. I've been playing a bit with course editing and at the moment while I can see a visible jump I don't find it overly aggressive. For sure if we could avoid it, or minimise it that would be great. In regards to the suggestions made above. 1. YUI transitions is one way to go, but to be truthful I don't think that is the best approach. Transitions are great for things like expanding/collapsing, or toggling the display of advanced items, however if we are talking about page components that are always going to be available (granted depending upon editing being on) then I think we are best to look for a solution in the design of the page and the javascript components. Adding transitions adds more yet more weight to a page and certainly trying to keep it down is advantageous as I'm sure many more JS solution will arrive in the future. 2. Adding a CSS class to the body is ajax is enabled for the site I think is an entirely worthwhile endeavor. Even if it doesn't form part of the solution for this issue I think that is a valuable idea. Again as more and more JS arrives that is the sort of thing that implementing now will save countless varying solutions to the same problem from occurring in the future. This of course by itself doesn't constitute a solution, simply hiding things only gets us half way there at the moment as presently we have all things shifting in the page when JS loads. As for the complete solution as hinted at above I think we need to look at the design of the page when in editing mode. Especially the icons and placement of them. Ideally I think we should stick to the principle of enhancement and try to organise things in such a way that they meet the needs of both the conventional page and the AJAX page. Most of the JS that exists for editing has been revisited in the past couple of months and tidied up greatly. Certainly it is more possible now than it has been in the past to look at the design; more needed as well of course. When I say design by the way I mean where the icons are placed, the HTML that is holding them in place, their size and order, and perhaps even the icons themselves. In reflection to my opening statement I think we need to change the page to meet the needs of the JS (as well as the conventional page) and not have the JS make changes to the page (unless absolutely required). Anyway I think that about sums up my thoughts on the concept of this issue. I know that it doesn't provide any specific direction but hopefully it gives an insight into what I see as the direction this issue should be taken in finding a solution. Cheers Sam
          Hide
          Andrew Nicols added a comment -

          As part of MDL-31215 I've done some initial work which may help with this.
          I've created a new class for only showing content if js is enabled. To use, add the 'visibleifjs' class to the element.

          repo: git://git.luns.net.uk/moodle.git
          branch: MDL-31215-master-9
          diff: https://git.luns.net.uk/moodle.git/commitdiff/91740eac14f4c34df3f5506feddc701092ea32d8
          This is only one commit - the other commits relate to MDL-31215 more explicitly.

          Show
          Andrew Nicols added a comment - As part of MDL-31215 I've done some initial work which may help with this. I've created a new class for only showing content if js is enabled. To use, add the 'visibleifjs' class to the element. repo: git://git.luns.net.uk/moodle.git branch: MDL-31215 -master-9 diff: https://git.luns.net.uk/moodle.git/commitdiff/91740eac14f4c34df3f5506feddc701092ea32d8 This is only one commit - the other commits relate to MDL-31215 more explicitly.
          Hide
          Dan Poltawski added a comment -

          Andrew: I don't understand?

          Explain the difference between that and using .jsenabled.

          Show
          Dan Poltawski added a comment - Andrew: I don't understand? Explain the difference between that and using .jsenabled.
          Hide
          Ruslan Kabalin added a comment -

          Patch is added. This adds ajaxenabled style to body from include_course_ajax, so blocks move icon is being hidden slightly earlier. Ideally this class should be added to all pages once MDL-33099 is sorted.

          Show
          Ruslan Kabalin added a comment - Patch is added. This adds ajaxenabled style to body from include_course_ajax, so blocks move icon is being hidden slightly earlier. Ideally this class should be added to all pages once MDL-33099 is sorted.
          Hide
          Dan Poltawski added a comment -

          This isn't really solving the major issue for the page the move icons in sections. If you watch the page, that is what is making the elements move around because there are multiples - in fact I am confident in saying i've never even seen the block move icons move!

          So, thats what I think needs to be added.

          Show
          Dan Poltawski added a comment - This isn't really solving the major issue for the page the move icons in sections. If you watch the page, that is what is making the elements move around because there are multiples - in fact I am confident in saying i've never even seen the block move icons move! So, thats what I think needs to be added.
          Hide
          Andrew Nicols added a comment -

          Updated to hide:

          • block moving icon
          • section moveup movedown icons
          Show
          Andrew Nicols added a comment - Updated to hide: block moving icon section moveup movedown icons
          Hide
          Ruslan Kabalin added a comment -

          Thanks Andrew

          Show
          Ruslan Kabalin added a comment - Thanks Andrew
          Hide
          Tim Hunt added a comment -

          Are you guys aware of the JavaScript on the quiz/attempt page and quiz/edit page. It saves scroll position when you do an action, then scrolls there when the next page loads.

          Look in question/qengine.js. (I am happy for M.core_scroll_manager to move to another file.)

          Show
          Tim Hunt added a comment - Are you guys aware of the JavaScript on the quiz/attempt page and quiz/edit page. It saves scroll position when you do an action, then scrolls there when the next page loads. Look in question/qengine.js. (I am happy for M.core_scroll_manager to move to another file.)

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: