Posts made by Itamar Tzadok

Confirmed in the application level (that is, I didn't examined the respective code). The export doesn't seem to support groups.

One possible non-hack workaround is to generate a csv code of the displayed items in the list view by javascript. Teachers could then copy and save into a txt file or csv file and take it from there. smile

Should be exactly the same method you use to extract a value from a table cell but a "get" rather than "set".

The "get" is something like:

somevar = somecell.innerHTML;

So the "set" should be:

somecell.innerHTML = somevar;

In your case you have

<td id="totalP"></td>
<td id="totalC"></td>

So the last two lines of your script should be:

document.getElementById('totalP').innerHTML=countP;
document.getElementById('totalC').innerHTML=countC;

 

One other suggestion. Since you intend the countP and countC as numbers but you extract the values from innerHTML which is a string and at that html, you may want to explicitly convert the innerHTML to Number just to be on the safe side. Something like:

countP+=Number(theCells[3].innerHTML);

 

hth smile

Average of ratings: Useful (1)

Absolutely. The only reason I made it this way and didn't go all the way with something like the explorer experience is that this design is fairly close to the current and may be implemented fairly quickly and boost up efficiency and effectiveness with relatively little effort.

Ajax dialogues are accessibility friendly right? If they are then they go in without saying, already in the first improvement phase.

The main challenge with the explorer experience is the select&drag&drop behavior which should replace the check&click_with_selected_button. I'm not sure how accessibility friendly this behavior is and even if it is it may be a bit more difficult to implement and if so should be done in phase two.

If all the above holds, there remains the question where to put the control buttons (which would open Ajax dialogues). The reason I prefer a third column is that these controls shouldn't require scrolling to. We could lay them out horisentally above the items list in the main display area but I don't think that would look to people as a familiar experience. Now, the third column doesn't have to be an actual column. it could be the settings block positioned by default on the right hand side and dockable. This may also make more sense with respect to the Moodle standard of administration controls interface in any other component.

smile