Details

    • Testing Instructions:
      Hide
      1. As teacher, go to a course and create a quiz
      2. Add few questions to quiz and two description questions
      3. click edit quiz.
      4. Select "Order and paging" tab and check the "Move selected questions to page:" (on top and bottom) text elements. Make sure it has a proper label
      5. check question order input elements (next to up/down arrow icons). Make sure it has a proper label
      6. On "Editing quiz" tab, check the "Marked out of" text elements, they SHOULD have a proper label
      7. In Navigation block under the quiz, select Results -> Statistics.
      8. check the element called "menudownload", it should have a proper label
      Show
      As teacher, go to a course and create a quiz Add few questions to quiz and two description questions click edit quiz. Select "Order and paging" tab and check the "Move selected questions to page:" (on top and bottom) text elements. Make sure it has a proper label check question order input elements (next to up/down arrow icons). Make sure it has a proper label On "Editing quiz" tab, check the "Marked out of" text elements, they SHOULD have a proper label In Navigation block under the quiz, select Results -> Statistics. check the element called "menudownload", it should have a proper label
    • Affected Branches:
      MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Pull Master Branch:
      wip-mdl-34568
    • Rank:
      43001

      Description

      There are several select input fields that do not have labels explicitly tied to them. Often this is because there is a visual cue as to what information is being asked for but the visual cue is not explicitly linked to the input element.

      Because this problem is sporadic it might be necessary to break this task out into smaller sub-tasks for each instance of the problem.

      Here is a tutorial for methods of labeling text input elements. http://oit.ncsu.edu/itaccess/forms#select

      1. After.png
        23 kB
      2. Before.png
        21 kB

        Issue Links

          Activity

          Hide
          Dan Poltawski added a comment -

          Seems like Tim hasn't been added as a watcher to this issue. Added him.

          Show
          Dan Poltawski added a comment - Seems like Tim hasn't been added as a watcher to this issue. Added him.
          Hide
          Tim Hunt added a comment -

          Sorry, but these changes are also bad. -1.

          The Move down/up labels are just wrong. Those controls don't do that!

          For the "Move selected questions to page" change. That text is already visible on screen. Why on earth would you duplicate the text inside an accesshide label? Just wrap the label tags around the existing on-screen text.

          The inputs with id inputq' . $question->id already have a label in the HTML. You have added a completely redundant second one.

          You have added an identical label "Reorder questions" to that input box for every single question. I assume you don't need me to explain why that is completely useless.

          I am not sure that the "Action" label added in the statistics report does any good. Note that this bit of UI is matching a similar bit of UI that is output by tablelib.php which appears elsewhere on the page, so you should not change one without changing the other. Also, this UI is probably weird for sighted users too. Perhaps change it so that it is better for everyone, which will probably mean that you don't need any accesshide text, just a normal visible label.

          The testing instructions also display completely the wrong attitude to me: 'they SHOULD have a label with "accesshide" class'. Who cares whether the class is accesshidden or not. That is an implementation detail. The test should be "they SHOULD have a label that makes the form easier to use for screen-reader users". Testing instructions should be written from the user's point of view, not the developer's.

          Show
          Tim Hunt added a comment - Sorry, but these changes are also bad. -1. The Move down/up labels are just wrong. Those controls don't do that! For the "Move selected questions to page" change. That text is already visible on screen. Why on earth would you duplicate the text inside an accesshide label? Just wrap the label tags around the existing on-screen text. The inputs with id inputq' . $question->id already have a label in the HTML. You have added a completely redundant second one. You have added an identical label "Reorder questions" to that input box for every single question. I assume you don't need me to explain why that is completely useless. I am not sure that the "Action" label added in the statistics report does any good. Note that this bit of UI is matching a similar bit of UI that is output by tablelib.php which appears elsewhere on the page, so you should not change one without changing the other. Also, this UI is probably weird for sighted users too. Perhaps change it so that it is better for everyone, which will probably mean that you don't need any accesshide text, just a normal visible label. The testing instructions also display completely the wrong attitude to me: 'they SHOULD have a label with "accesshide" class'. Who cares whether the class is accesshidden or not. That is an implementation detail. The test should be "they SHOULD have a label that makes the form easier to use for screen-reader users". Testing instructions should be written from the user's point of view, not the developer's.
          Hide
          Aparup Banerjee added a comment -

          reopening based on Tim's comments.

          Show
          Aparup Banerjee added a comment - reopening based on Tim's comments.
          Hide
          Michael de Raadt added a comment -

          Carrying over to the next sprint.

          Show
          Michael de Raadt added a comment - Carrying over to the next sprint.
          Hide
          Rajesh Taneja added a comment -

          Requested Rossie to have a look at this.

          Show
          Rajesh Taneja added a comment - Requested Rossie to have a look at this.
          Hide
          Rajesh Taneja added a comment -

          Thanks for the review Tim,

          I have been looking at Rossie's patch and it seems we have few options there, but not sure which one is good:

          Point 1 (Move down/up labels):
          1. Should we change lang string and add label to lang string, as we are passing input element to lang string (https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L438). Probably not.
          2. Can we remove $a from lang string and concatenate this outside (https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/lang/en/quiz.php#L448). In this case, it won't be back-ported.
          3. Add label tag at https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L438 and end tag at https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L434 (Which is probably not a good idea)
          Point 3 (Reorder questions)
          1. Should we concatenate question->id or question->name to "Reorder"?
          Point 4 (statistics report)

          I agree with you that it should be added in tablelib as well. And it has been added to tablelib

          html_writer::label(get_string('downloadoptions', 'table'), 'menudownload', false, array('class' => 'accesshide'));
          

          Can you please suggest if this should be downloadoptions or action?

          Thanks for all the help Tim.

          Show
          Rajesh Taneja added a comment - Thanks for the review Tim, I have been looking at Rossie's patch and it seems we have few options there, but not sure which one is good: Point 1 (Move down/up labels): Should we change lang string and add label to lang string, as we are passing input element to lang string ( https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L438 ). Probably not. Can we remove $a from lang string and concatenate this outside ( https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/lang/en/quiz.php#L448 ). In this case, it won't be back-ported. Add label tag at https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L438 and end tag at https://github.com/rwijaya/moodle/blob/c8227ccbc4ec33bec482a4726d1f61ae20b2e65a/mod/quiz/editlib.php#L434 (Which is probably not a good idea) Point 3 (Reorder questions) Should we concatenate question->id or question->name to "Reorder"? Point 4 (statistics report) I agree with you that it should be added in tablelib as well. And it has been added to tablelib html_writer::label(get_string('downloadoptions', 'table'), 'menudownload', false, array('class' => 'accesshide')); Can you please suggest if this should be downloadoptions or action? Thanks for all the help Tim.
          Hide
          Tim Hunt added a comment -

          Can I ask, have you ever tried to use your computer using a screen-reader, with the monitor switched off? It is an instructive exercise, but actually it can only ever give you a flavour of what real screen-reader users experience, because they are sophisticated tools that take time to learn to use properly. (Imagine sitting a novice down in front of Eclipse or Vim, and appreciate the right way to use the tool.)

          It is also instructive to find videos on YouTube of experts using a screen-reader.

          However, screen-reader users are just one category of people who require assistive technologies. Fortunately, these days, web browsers mostly deal with the most common accessibility requirement (larger text) for us.

          The other common one is high contrast mode. Try switching your OS into high contrast mode, and see if Moodle is usable.


          Anyway, just adding stuff with class="accesshide" does not magically make things accessible. What you add has to be useful. So, another way to think about the problem is: "What change would increase the usability of this feature for disabled users?". And, once you start to think like that, it becomes natural to wonder if you can answer the more general question "What change would increase the usability of this feature (for all users)?"

          A good example of this is Point 4. If changing the UI here to include a label does improve the usability, the you should not accesshide it! Improve the usability for everyone. If you don't think the label is an improvement for sighted users, why do you think it will help screenreader users?


          On the other points, I mostly not sure. However:

          Point 1. 2) I am sure you should never concatenate outside language strings. No point improving accessibility at the cost of making Moodle harder to translate. Find a solution that makes Moodle better in all ways.

          Point 3. 1) Of course don't use question->id in a UI string. It is completely meaningless to the user. So, either $question->name, which is long, or can you get the question number within the quiz? (but if so, what about descriptions).

          Show
          Tim Hunt added a comment - Can I ask, have you ever tried to use your computer using a screen-reader, with the monitor switched off? It is an instructive exercise, but actually it can only ever give you a flavour of what real screen-reader users experience, because they are sophisticated tools that take time to learn to use properly. (Imagine sitting a novice down in front of Eclipse or Vim, and appreciate the right way to use the tool.) It is also instructive to find videos on YouTube of experts using a screen-reader. However, screen-reader users are just one category of people who require assistive technologies. Fortunately, these days, web browsers mostly deal with the most common accessibility requirement (larger text) for us. The other common one is high contrast mode. Try switching your OS into high contrast mode, and see if Moodle is usable. Anyway, just adding stuff with class="accesshide" does not magically make things accessible. What you add has to be useful. So, another way to think about the problem is: "What change would increase the usability of this feature for disabled users?". And, once you start to think like that, it becomes natural to wonder if you can answer the more general question "What change would increase the usability of this feature (for all users)?" A good example of this is Point 4. If changing the UI here to include a label does improve the usability, the you should not accesshide it! Improve the usability for everyone. If you don't think the label is an improvement for sighted users, why do you think it will help screenreader users? On the other points, I mostly not sure. However: Point 1. 2) I am sure you should never concatenate outside language strings. No point improving accessibility at the cost of making Moodle harder to translate. Find a solution that makes Moodle better in all ways. Point 3. 1) Of course don't use question->id in a UI string. It is completely meaningless to the user. So, either $question->name, which is long, or can you get the question number within the quiz? (but if so, what about descriptions).
          Hide
          Rajesh Taneja added a comment -

          Thanks for the inputs Tim,

          No I have never used screen-reader before and I think I am getting your point about accessibility.

          Point 3. 1) You are right, question number makes more sense.

          Point 1. Can you please suggest the best possible solution?

          Point 4. It might not be a good idea to add this label.

          Show
          Rajesh Taneja added a comment - Thanks for the inputs Tim, No I have never used screen-reader before and I think I am getting your point about accessibility. Point 3. 1) You are right, question number makes more sense. Point 1. Can you please suggest the best possible solution? Point 4. It might not be a good idea to add this label.
          Hide
          Tim Hunt added a comment -

          For Point 4, I actually think the label is a good idea. I find the current UI, with just a button, a bit odd. I think the best UI (for everyone) would be:

          Download this table as [ CSV / Excel / ... | v ] ( Download )

          I don't have any inspiration about how to solve Point 1 at the moment. Sorry.

          Show
          Tim Hunt added a comment - For Point 4, I actually think the label is a good idea. I find the current UI, with just a button, a bit odd. I think the best UI (for everyone) would be: Download this table as [ CSV / Excel / ... | v ] ( Download ) I don't have any inspiration about how to solve Point 1 at the moment. Sorry.
          Hide
          Rajesh Taneja added a comment -

          It's valid to have input element in label (http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL), so point 1 has been solved by encapsulating string and input element in label tag.

          Show
          Rajesh Taneja added a comment - It's valid to have input element in label ( http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL ), so point 1 has been solved by encapsulating string and input element in label tag.
          Hide
          Tim Hunt added a comment -

          It may be valid to put the control inside the label, but in the past that did not actually work in IE. Mind you, I have not re-tested that recently, but you should.

          Show
          Tim Hunt added a comment - It may be valid to put the control inside the label, but in the past that did not actually work in IE. Mind you, I have not re-tested that recently, but you should.
          Hide
          Rajesh Taneja added a comment -

          Thanks Tim,

          Just tested on ie8 and ie7 (compatibility mode), and it is working fine.

          Show
          Rajesh Taneja added a comment - Thanks Tim, Just tested on ie8 and ie7 (compatibility mode), and it is working fine.
          Hide
          Rajesh Taneja added a comment -

          Hello Tim,
          Can you please suggest if rest of the patch is fine or any modifications are required.

          Show
          Rajesh Taneja added a comment - Hello Tim, Can you please suggest if rest of the patch is fine or any modifications are required.
          Hide
          Tim Hunt added a comment -

          Problems:

          1. https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R436 (and the one after) this label is not associated with any form control.
          2. https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R653 as I am sure I pointed out somewhere above. That label is completely wrong. Those inputs are not question weight.
          3. https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L3L972 The label here (well, button caption) used to say "Download full report as" which is clearly a better label.

          Do you really need me to point out things like this.

          Also, the downloadas string beside the buttons is essentially doing string concatenation, which causes problems for people trying to translate into languages with different word orders. I wonder if it would be better to have a string:

          $string['downloadtableas'] = 'Download table data as {$a->formatsmenu} {$a->gobutton}';

          That would also put a space between things, which would look nicer. You might want to check this with David Mudrak.

          Show
          Tim Hunt added a comment - Problems: https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R436 (and the one after) this label is not associated with any form control. https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R653 as I am sure I pointed out somewhere above. That label is completely wrong. Those inputs are not question weight. https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L3L972 The label here (well, button caption) used to say "Download full report as" which is clearly a better label. Do you really need me to point out things like this. Also, the downloadas string beside the buttons is essentially doing string concatenation, which causes problems for people trying to translate into languages with different word orders. I wonder if it would be better to have a string: $string ['downloadtableas'] = 'Download table data as {$a->formatsmenu} {$a->gobutton}'; That would also put a space between things, which would look nicer. You might want to check this with David Mudrak.
          Hide
          Rajesh Taneja added a comment - - edited

          point 1, if input is encapsulated in label, then we don't need any association. Label is automatically associated with encapsulated input.
          point 2, What do you think is the best label? I am not sure, if naming it as "Reorder question 1" will make it any better.
          point 3, This was added, as per your suggestion (http://tracker.moodle.org/browse/MDL-34568?focusedCommentId=174366&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-174366). Will check with David for better convention.

          Show
          Rajesh Taneja added a comment - - edited point 1, if input is encapsulated in label, then we don't need any association. Label is automatically associated with encapsulated input. point 2, What do you think is the best label? I am not sure, if naming it as "Reorder question 1" will make it any better. point 3, This was added, as per your suggestion ( http://tracker.moodle.org/browse/MDL-34568?focusedCommentId=174366&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-174366 ). Will check with David for better convention.
          Hide
          Tim Hunt added a comment -

          1. Sorry. I see, $a is the input. I should have worked that out for myself.

          2. The best I can do it "New position in order for question 1" (that is a bit long). However, when testing this, add at least two description 'questions' to your quiz, in order to see a potential problem.

          3. I did not intend to suggest that.

          I suggested is that you replaced the old 'Download table as' button with the new UI, like you did at https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L0L920. Great.

          So then we have to decide what should happen to the "Download entire report as" button. The suggestion was to make a similar change there. When I said "Similar change", that did not include changing the text to the misleading 'Download table as'.

          Show
          Tim Hunt added a comment - 1. Sorry. I see, $a is the input. I should have worked that out for myself. 2. The best I can do it "New position in order for question 1" (that is a bit long). However, when testing this, add at least two description 'questions' to your quiz, in order to see a potential problem. 3. I did not intend to suggest that. I suggested is that you replaced the old 'Download table as' button with the new UI, like you did at https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L0L920 . Great. So then we have to decide what should happen to the "Download entire report as" button. The suggestion was to make a similar change there. When I said "Similar change", that did not include changing the text to the misleading 'Download table as'.
          Hide
          Rajesh Taneja added a comment -

          Thanks for the response Tim,

          Added David and Helen to get some inputs on how download button should be visible (on stats page).

          FYI: Adding two images (before and after), so Helen and David can easily see the difference.

          Show
          Rajesh Taneja added a comment - Thanks for the response Tim, Added David and Helen to get some inputs on how download button should be visible (on stats page). FYI: Adding two images (before and after), so Helen and David can easily see the difference.
          Hide
          Helen Foster added a comment -

          Hi Raj,

          Thanks for asking my opinion on this issue. I started by looking at other places in Moodle where you can download data, such as gradebook export and database entries export, as I think we should be aiming for these interfaces to look and behave as similar as possible.

          Looking at the before and after screen shots, I like the after one much better, as having a button with only the word 'Download' makes it similar to gradebook export.

          Just wondering whether radio buttons would be possible for selecting the export format, rather than the dropdown menu selector, so that users can see at a glance the different formats available?

          Also wondering whether the names of the export formats could be the same as used elsewhere i.e.

          • 'a Microsoft Excel spreadsheet' changed to 'Excel spreadsheet'
          • 'an OpenDocument Spreadsheet (ODS)' changed to 'OpenDocument spreadsheet'
          • 'a tab separated values text file' and 'a comma separated values text file' combined and changed to 'Plain text file'

          (I couldn't find 'an unpaged XHTML document' export format used anywhere else in Moodle!)

          Apologies if my language string suggestions don't make much sense, as I didn't fully understand all the comments in this issue.

          Finally, noting for historical interest how downloading of quiz results was done in 1.9 - 3 buttons as shown in the screenshot in http://docs.moodle.org/19/en/Quiz_reports

          Show
          Helen Foster added a comment - Hi Raj, Thanks for asking my opinion on this issue. I started by looking at other places in Moodle where you can download data, such as gradebook export and database entries export, as I think we should be aiming for these interfaces to look and behave as similar as possible. Looking at the before and after screen shots, I like the after one much better, as having a button with only the word 'Download' makes it similar to gradebook export. Just wondering whether radio buttons would be possible for selecting the export format, rather than the dropdown menu selector, so that users can see at a glance the different formats available? Also wondering whether the names of the export formats could be the same as used elsewhere i.e. 'a Microsoft Excel spreadsheet' changed to 'Excel spreadsheet' 'an OpenDocument Spreadsheet (ODS)' changed to 'OpenDocument spreadsheet' 'a tab separated values text file' and 'a comma separated values text file' combined and changed to 'Plain text file' (I couldn't find 'an unpaged XHTML document' export format used anywhere else in Moodle!) Apologies if my language string suggestions don't make much sense, as I didn't fully understand all the comments in this issue. Finally, noting for historical interest how downloading of quiz results was done in 1.9 - 3 buttons as shown in the screenshot in http://docs.moodle.org/19/en/Quiz_reports
          Hide
          Tim Hunt added a comment -

          Thanks Helen, those look like good suggestions to me, with one exception. I think radio buttons would take up too much space, so I would stick to a drop-down. Anyway, Raj is doing all the hard work here, so I will let him make the final call on what to implement.

          Show
          Tim Hunt added a comment - Thanks Helen, those look like good suggestions to me, with one exception. I think radio buttons would take up too much space, so I would stick to a drop-down. Anyway, Raj is doing all the hard work here, so I will let him make the final call on what to implement.
          Hide
          David Mudrak added a comment -
          • +1 for the new layout illustrated in After.png screenshot
          • +1 for using the template-like string 'Download table data as {$a->formatsmenu} {$a->gobutton}'; as Tim suggested. It will allow translators to form a readable sentence even for right-to-left languages. All other attempts to concatenate texts are generally suboptimal.
          • +1 for Helen's suggestions to reword the options. Note that strings like 'Excel spreadsheet' should already exist so you might want to re-use them or at least CPY them via AMOScript in the commit message. Just note that I am not sure that we can combine 'tab separated values' and 'comma separated values' as these are two different formats IIUIC.
          • +1 for using drop-down menu even though I understand Helen's point. With radios, it is generally difficult to render a nice one-line text like we need here.
          Show
          David Mudrak added a comment - +1 for the new layout illustrated in After.png screenshot +1 for using the template-like string 'Download table data as {$a->formatsmenu} {$a->gobutton}'; as Tim suggested. It will allow translators to form a readable sentence even for right-to-left languages. All other attempts to concatenate texts are generally suboptimal. +1 for Helen's suggestions to reword the options. Note that strings like 'Excel spreadsheet' should already exist so you might want to re-use them or at least CPY them via AMOScript in the commit message. Just note that I am not sure that we can combine 'tab separated values' and 'comma separated values' as these are two different formats IIUIC. +1 for using drop-down menu even though I understand Helen's point. With radios, it is generally difficult to render a nice one-line text like we need here.
          Hide
          Rajesh Taneja added a comment -

          Thanks for the feedback David,

          Will do the needful.

          Show
          Rajesh Taneja added a comment - Thanks for the feedback David, Will do the needful.
          Hide
          Helen Foster added a comment -

          Regarding my suggestion

          'a tab separated values text file' and 'a comma separated values text file' combined and changed to 'Plain text file'

          I was thinking that if radio buttons were used, the plain text file option could have a dropdown menu selector after it for choosing tab separated or comma separated (as done elsewhere in Moodle, for example in database entries export) however I accept everybody's point about not using radio buttons.

          I guess we couldn't possibly simplify things by reducing the number of available export formats and have only one text file format?

          Show
          Helen Foster added a comment - Regarding my suggestion 'a tab separated values text file' and 'a comma separated values text file' combined and changed to 'Plain text file' I was thinking that if radio buttons were used, the plain text file option could have a dropdown menu selector after it for choosing tab separated or comma separated (as done elsewhere in Moodle, for example in database entries export) however I accept everybody's point about not using radio buttons. I guess we couldn't possibly simplify things by reducing the number of available export formats and have only one text file format?
          Hide
          Tim Hunt added a comment -

          I think having both formats is useful. Excel, for example, has them as two separate formats.

          Show
          Tim Hunt added a comment - I think having both formats is useful. Excel, for example, has them as two separate formats.
          Hide
          Rajesh Taneja added a comment -

          Thanks everyone,

          I have kept this as drop-down to keep it simple. Have changed strings and added AMOS.

          Hope all good now.

          Show
          Rajesh Taneja added a comment - Thanks everyone, I have kept this as drop-down to keep it simple. Have changed strings and added AMOS. Hope all good now.
          Hide
          Tim Hunt added a comment -

          I really hate this style:

          https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R926

          Why not one line of code:

          html_writer::start_tag('label', get_string('downloadas', 'table', $downloadelements);

          It has the advantage that if someone modifies the code in the future, the start/end tags cannot get mismatched.

          Anyway, that is just personal preference. The code is good. +1 to submit for integration. Thanks for sticking with it.

          Show
          Tim Hunt added a comment - I really hate this style: https://github.com/rajeshtaneja/moodle/compare/master...wip-mdl-34568#L1R926 Why not one line of code: html_writer::start_tag('label', get_string('downloadas', 'table', $downloadelements); It has the advantage that if someone modifies the code in the future, the start/end tags cannot get mismatched. Anyway, that is just personal preference. The code is good. +1 to submit for integration. Thanks for sticking with it.
          Hide
          Rajesh Taneja added a comment -

          Thanks Tim,

          I have modified it to use html_writer::tag, pushing it for integration now.

          Show
          Rajesh Taneja added a comment - Thanks Tim, I have modified it to use html_writer::tag , pushing it for integration now.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday.

          This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody.

          This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P

          Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday. This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody. This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao
          Hide
          Rajesh Taneja added a comment -

          Branch re-based.

          Show
          Rajesh Taneja added a comment - Branch re-based.
          Hide
          Sam Hemelryk added a comment -

          Thanks Raj, this has been integrated now

          Show
          Sam Hemelryk added a comment - Thanks Raj, this has been integrated now
          Hide
          Sam Hemelryk added a comment -

          Just noting that I had to fix a whitespace issue during integration, line 653 of editlib.php.

          Show
          Sam Hemelryk added a comment - Just noting that I had to fix a whitespace issue during integration, line 653 of editlib.php.
          Hide
          David Monllaó added a comment -

          It passes, tested in master

          Show
          David Monllaó added a comment - It passes, tested in master
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Gutta cavat lapidem, non vi sed saepe cadendo - Ovidio

          This issue has been integrated upstream and is now available both via git and cvs (and in some hours, via mirrors and downloads).

          Thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Gutta cavat lapidem, non vi sed saepe cadendo - Ovidio This issue has been integrated upstream and is now available both via git and cvs (and in some hours, via mirrors and downloads). Thanks!
          Hide
          Aparup Banerjee added a comment -

          note: TimH pointed out in devchat (just now) that we didn't need to wrap the label tag around the input tag : see http://fisheye.moodle.org/viewrep/Moodle/mod/quiz/editlib.php?r1=d197ea4300083cfa6c4f09613f9fb1f98ce2e69a&r2=0465ef6e319aa1801cccfb2d5bec72a94c3d87ac

          Show
          Aparup Banerjee added a comment - note: TimH pointed out in devchat (just now) that we didn't need to wrap the label tag around the input tag : see http://fisheye.moodle.org/viewrep/Moodle/mod/quiz/editlib.php?r1=d197ea4300083cfa6c4f09613f9fb1f98ce2e69a&r2=0465ef6e319aa1801cccfb2d5bec72a94c3d87ac

            People

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

              Dates

              • Created:
                Updated:
                Resolved: