|
[
Permalink
| « Hide
]
Olli Savolainen added a comment - 01/Jul/08 11:35 PM
The current version, if you can't view the static mht file, read mht-readme.txt.
what was changed in question/ is in the diff, the other files are just to be added in mod/quiz/ for now.
diffs and separate files for current changes from moodle 1.9
This time, just the diff + one gif file + the lang files from moodledata
Drat! I can't get the patch to apply. Well, it is nearly time to go home here anyway, so I don't have time to look at the code now, but I was hoping to get the merge done now so I could start looking first thing in the morning.
It is not happy with weblib, I think because of whitespace differerences. More seriously, there are files like editlib_redesign.php where the patch contains changes, but 1.9 does not have a file of that name. Apart from that the patch works (once I have selected reverse). Could you try regenerating the patch, then I will try to have a look tomorrow. Thanks. Yes, there are some additional files. Since the original where I created the patch from does not contain the _redesign files, I figured patch would just create those files. But I'll create another package with also separate files.
Eclipse seems to want to forcibly add strange whitespace into weblib.php. I will look into that, too later today. (It's 13:20 here so plenty time). I am sorry indeed. It seems that revision 1 in my subversion repository (against witch the previous patch was made) was not clean moodle 1.9 after all. Now I have tested the new version 0.52 to patch against fresh 1.9, see notes.txt. I also made some fixes based on the usability tests already, now that I got started
Also, fixed IE 6 to display properly, just had to fix two things in CSS and no quirks were required. However, everything related to javascript is broken on IE 6 at the moment: IE6 only seems to show one error message: Line 67 Char 22: Expected identifier, string or number. So the "add question" dropdown does not work. When I remove the new YUI javascript however everything works, so there is a conflict of some kind (though not if used in firefox). One thing that might help is to move also the new javascript to <head>, it is now in <body>. This error seems to vary between page loads or something though; in any case, the YUI random question adding dialog does not work. On the other hand, it seems that Moodle does not support IE 5 at all: the login form does not appear on the login page so I could not test it. Just to make sure you can use something, Tim, here is everything I have done as separate files, too.
Some review comments:
1. Do you develop with Administration ? Server ? Debugging > Debug messages set to DEVELOPER, and Display debug messages turned on? You should. I do, and am seeing PHP notices displayed, and that is making it very hard to test. Also, some of the notices seem to be pointing out real bugs. 2. Please try to keep the code wrapped at about 80 colums wide. It makes it easier to read, and when you wrap a line, double-indent the following lines (8 spaces) to try to give some clue that it is a continuation. 3. Line 249 of mod/quiz/edit.php (an example of a line that is too long!) refers to $param->..., but I can't see where this is defined. Looking at the code being called, these parameters don't seem to be used. Oh ... 4. I did not know about the PHP compact function. It looks dangerous to me, because it makes it hard to see where a variable like $currentcat is used. I would stick to the more verbose array('currentcat' => $currentcat, 'contexts' => $contexts); 5. And it is this undefined variable that is giving me SQL errors like ERROR: syntax error at or near "AND" LINE 1: ...ies c1, s19_question_categories c2 WHERE c2.id = AND c1.con... ^ SELECT count I am on PHP 5.2.4 and PostgreSQL here. 6. <link> tags should use the short-tag syntax: <link ... />, instead of <link></link>. 7. The way to get extra stuff, like links to stylesheets, included in <head>, is to pass extra HTML as the 5th ($meta) parameter to print_header_simple. 8. You probably need to change your print_box_start(); call around line 570 of edit.php to print_box_start('generalbox clearfix'); 9. It still lets me add questions even though the "You cannot add or remove questions because there are attempts." message is displayed. Also, when that message is displayed, the stylesheet is not used so the layout is messed up. I'm going to stop reviewing there for now. Sorry that a lot of these points are trivial. The key ones to fix are 1. and 9. It would be a lot easier to carry on reviewing if these are fixed. Huh, I was trying to set debugging on all along on the server, and couldn't so far make ubuntu do the PHP logging to /var/log/php.log where I have gotten used to seeing it. Didn't come to think that it might be in the actual panel. Sorry to have you test at this point, you could've just said the first point I guess :o).
Anyway, thanks for the generous input. It isn't like I did not expect issues like this to pop up, however. As my schedule is tight and the focus is on user interaction, making everything solid on the backend can only be done once the interaction looks like it really matches the users' needs, since before that virtually anything can change. So, the question again is: How does the process of evaluating the entire project proceed? When would you expect to know positively if you can take my work into core? My current funding is about to end but I am committed to making this a finished package. However, I am a bit unease with the feeling that I have no guarantee at all from Moodle's side at this point that any of this stuff will be used, and as mentioned, www.coss.fi people would like to hear something, as well. Some replies: 9. Will fix. I'm happy you brought up the subject of "You cannot add or remove questions because there are attempts", since this is a real issue with multiple faces. This came up in the usability tests, too: teachers are used to try everything in student role to preview. However, this way of previewing normally locks the quiz up, and the undo - deleting all attempts - is everything but obvious. So this is quite a usability disaster. This is not really much of a change in the UI but something that could be automated or the user, as follows. I think this would be of tremendous benefit, as also various messages in the quiz forum show this is a real issue - do you think we could get something like the following done? 1. Always warn the user if the are about to do something that affects the set of choices they can make later (User control and freedom), and as the undo here is not obvious, tell the user about it
Yeah, I guess options to just
would suffice. Still, hiding the quiz contents when there are attempts is not an option, just editing needs to be disabled. Also, since understanding what kinds of attempts there are is key to making the decision of whether the attempts can be deleted, there is a chance to make the interaction really fluid here by providing that information exactly where the decision is to be made. During the idle hours of the evening I couldn't resist the temptation but to look at the notices. Everything else I found at a glance was easy to fix, but the SQL error puzzles me. Seems that I don't know how to use question_category_object and the commenting seems scarce. I will look into it later more, now just to let you know.
$qcobject = new question_category_object( Actually, I did not know about compact() before you introduced it to me, either. Ah yes, I seem to have copied the latter line from the earlier line here verbatim:
$this->catform = new question_category_edit_form($this->pageurl, compact('contexts', 'currentcat')); I, too, think it is worth changing to standard array() call. I certainly did not write the compact call, since I had to look it up to find out what it did! CVS blames Jamie
I have been using the interface some more this morning, and I really like it. There are a couple of parts I have questions about, so hopefully we can hook up on Skype some time today and talk about it. But the big question is, should this be included in Moodle 2.0? That is a big question, so we need to break it down a bit. 1. Is this the right direction for the Moodle quiz user interface to evolve? And do we have a consensus about the answer? 2. Is the code quality good enough to be included in Moodle 2.0? That is does it follow the coding guidelines, and does it look like it is maintainable? 2a. If not, about how much more work needs to be done? 3. Does it meet all the necessary accessibility standards? For example, does it work with JavaScript turned off? Is it all valid HTML? Is it all usable just with the keyboard, no mouse? 4. How much time to you have to commit to this project from now on? In particular from now until we think everything is finished, and then later when 2.0 is in beta? My opinions about the answers to these questions are: 1. Yes. It immediately improves the current interface, and it probably makes it easier to add some of the future enhancements that have been talked about. There are some parts that need to be improved further, for example doing the re-ordering using drag and drop, but we can release what we have now, it is good enough, and make further improvements later. On the consensus subject, I will start another thread in the quiz forum in a moment. Annoyingly, Martin D is still on holiday at the Olympics, so I won't be able to discuss this with him until Monday, which is bad timing. 2. I would like to review the code some more. I have mostly been focussing on using the functionality in my recent testing. For the remaining questions, your probably have a better idea than me, hence the fact it would be good to talk. The essay icon looks more finished now
Initial thoughts: 1. The comments about the demo have all been mostly favourable. One thing that really needs to be settled is switching between quiz editing and question bank. More about that in my report, which I hope to publish tomorrow. 2. I have tried to stick to general PHP coding guidelines and Moodle guidelines. However, I have a bit of an paranoid feeling about having covered all Moodle's guidelines since at the beginning of the summer new docs documentation about development I had not seen, seemed to pop up every once in a while. 3. Keyboard usage could probably be improved quite a bit from the current state - adding accesskey properties and setting tabbing order etc. 4. I am writing my master's thesis about this project this next semester, and I believe it will motivate me to have something concrete to do with the subject, as well as analyzing usability work in an open source project. Besides that, I am learning French and building up a new social sphere since I don't know almost anyone from Metz, France yet. During the following two or three week it will probably be pretty crazy trying to arrange everything and settling in, but after that I expect to have lots of time and motivation for this. By the way, the new interface for adding a random question to the quiz does not work for me. The form appears, but I get an error when I click submit.
Some comments on the code: lang/en_utf8/quiz.php
lang/en_utf8/help/quiz/editconcepts.html
lib/weblib.php
question/type/essay/icon.gif
question/category_class.php
question/type/edit_question_form.php
That is everything outside mod/quiz. Submitting this comment now, before it gets lost. More later. The usual follow-up question: What are you trying to use the random question dialog on?
print_paging_bar changes are separate I think. They depend on the CSS in the css file of this project, though - making them separate really might be a good idea. The random question icon is from the package gnome-tali. I am verifying that it is okay to use an icon from a GPL'd project in another one. http://library.gnome.org/users/gtali/2.21/playing.html.en I am using Firefox 3 on Linux. The console gives a strange error in the middle of a YUI library.
Forum thread about whether to include this in 2.0: http://moodle.org/mod/forum/discuss.php?d=103869 Copying from one GPL project to another is fine. Another question: Do we need to make any changes to the separate question bank interface? Probably yes, but only small visual changes to the stylesheet, to maintain consistency with the quiz interface. http://tracker.moodle.org/browse/CONTRIB-643
It is important to keep the question bank window and the separate question bank as consistent as possible, to avoid confusion. In addition to outlook, element order etc. should be as close as possible. Rather, I would like to think of this as having them only differ where absolutely necessary. Also, I am still wondering about whether the question bank window should have a separate "create new category" button. I think it should, but it's a bit tricky to add it anywhere so that it is easy enough to find. And the create new question might be simpler if it were a separate dialog to select the question type from, but then again, it is an additional step. More review comments:
mod/quiz/addrandom.php
mod/quiz/edit_redesign.css
mod/quiz/edit-js.css
mod/quiz/quiz_edit.js
mod/quiz/tabs.php
mod/quiz/locallib.php
Some comments on the interface: I don't like the blue for the page and question numbers. They make me think that these are links, even though they are in a darker blue than the link colour. Reviewing this in 1.9 made me realise that I had only done I am not convinced by the repeated IU elements at the top and bottom of the reordering page. They look silly on very short quizzes, and are not really enough on very long quizzes. Is drag-and-drop reordering on the todo list? and have you looked at how re-ording activities on the course front page works? Again, changing that may be something for the future. I expect you have already written about this, but why did you keep the add question button in the mini question bank interface? What about combining the display of the current category with with UI for changing category? On the quiz settings form, we should change the "Questions per page" caption to "Automatic page breaks" with options "Never", "After every question", "Every 2 questions", ... I don't think we need to give every single option up to 50, either! That just leaves the two big files edit.php and editlib.php. More later. Great that the tabs are being emphasized further. I hope it is enough. The subtabs suffer this issue, too, actually to a greater degree since at least in the default theme the tabs don't look like tabs at all and they are hard to tell apart if there are multiple words, even if there is generous spacing.
"I don't like the blue for the page and question numbers. They make me think that these are links, even though they are in a darker blue than the link colour." I guess another suitable colour might be found. Drag-and-drop is not a priority right now, although yeah I have planned to have it. I have understood that most novice users ignore it on the web anyway so it is an advanced option. http://www.uie.com/brainsparks/2005/11/01/drag-n-drop-is-invisible-to-users/ More importantly though, is there any reasoning to go against general guidelines and keep the links not underlined? http://www.useit.com/alertbox/20040510.html "I expect you have already written about this, but why did you keep the add question button in the mini question bank interface? " There is no way to add questions in a random question otherwise? "What about combining the display of the current category with with UI for changing category?" Testing showed that it is hard to understand what the "box on the right" is actually about. This makes it as clear and fluent to use as possible As the "page breaks" concept is misleading in most cases and foreign to many users (though word processing uses it too, it is not very visible there, either) - compared to just talking about pages - I would vote for keeping consistent and taking "page breaks" out everywhere. I just had a look at the demo and I like it. +1 for putting this into core as its a lot simpler. I did find the edit quiz screen a bit confusing though - the questions seem to run into one another as did the pages. Same for the order/pages screen - a bit of css to get things away from the left and borders around questions pages to distinguish them would be great.
Also, the update this quiz button would be good as another tab. Laia has been discussing this idea elsewhere as part of the usability review and it seems popular.
Thanks Matt, I appreciate it. I agree that the graphical layout of the elements is not as clear as it could be. Vertical margins might help a bit, but adding margin on the left-hand side?
The update quiz into tab suggestion is linked from here, and I am in favour of it, too. (A quick note: I upgraded the demo just now to match the latest patch.) Thanks Olli. I was rushing when I looked yesterday and only looked at the first quiz, marked 'demo quiz'. I can see a completely different layout if I go to the 'test pierre pinchet' quiz. (much nicer on edit screen). What's the difference?
Oh, right. Sorry about that... it seems that people have made attempts to the quizzes - apparently by changing to student role - and the view of "edit quiz" in that situation is still unfinished, so it currently looks really screwed.
Tim, please confirm if the YUI Dialog and its submit button work for you in the new demo now online at http://localhost/moodle/mod/quiz/edit.php?cmid=2
Hi Olli,
could you attach the last version similar to the test site. Thanks I just look at your site and its seems that the version used is 1.9 as said in other comments.
As we want to put this on 2.0, I think that we should migrate to 2.0 and code in 2.0. The complexity of the showbank code ask for modifications so that it can be used in two format if this is the conclusion about this project although I prefer that showbank be as consistent as possible . Perhaps some 5.0 features on class can be useful i.e we could create a class for the showbank. The code actual definition use terms like question_category_form() although we are a long way from the actual moodleform... Tim,
A first look at the code shows that to obtain a specific showbank most of the code of question showbank as been reproduced in the mod/quiz/editlib.php. Given the complexity of this code including question deletion from the database (not just from the quiz), I think that if we maintain this double showbank feature, the code should be rebuilt so that the functions remain in the same file (question/editlib.php?) with a structure (new class?) that allow the two showbanks to originate from the same main code. This last remark illustrate the difficulties to code the various valid features of the Olli proposition.
That is to say that I want to thank Olli for the work done. Basically I think that we should continue to develop his project. The current version of the project uploaded as patch.Project status: http://docs.moodle.org/en/Development:Quiz_UI_redesign_-_development
However to install it, the files zip is more useful to me.
If you can set a cvs in the moodel/contrib it will be easier to have the files and all the revisions. Thinking about the duplication between question bank drawing code in mod/quiz/editlib.php and question/editlib.php. I think Pierre may be on to something. Perhaps we should change showbank from being a function to being a class. Then question/editlib.php can define a standard implementation, and mod/quiz/editlib.php defines a subclass that changes the bits that need to be changed without duplicating code.
Or perhaps we should leave that clean-up for now. It is the sort of thing that I could tackle when I am improving the interface for searching the question bank? I'll probably have clearer thought about this when I review the latest patch. I agree that functionality should not be duplicated needlessly. However, I would like to refrain from making architecture-related changes. Also, the changes to the question bank's own UI to keep the UI relatively consistent with Quiz's questio bank UI should be thought through first.
This project is a multi-task one or multi-objective if you prefer.
At this time we have not set the final design and this should be done for all the project or step by step. The new showbank proposal of Olli is a complete project by itself and a complement ot the creation of the two interfaces i.e. the edit and the order and paging. Let first create the two interfaces without doing changes to the question showbank even if there is some double features between the interfaces and the actual showbank. When we agree to these two interfaces (the discussion is not finished on the available features of these interfaces) and the necessary code built then we could work on the best showbanks (if we need two different one). The final design has been very stable ever since the project begun. There have been minor fixes to the original design based on the usability testing that took place in the summer. The changes in the showbank have been usability tested together with the rest of the new UI and results will be unpredictable usability-wise if only the content panes are upgraded.
In addition, the new user interface of quiz editing/order and paging will probably not work with the old showbank UI as it was, at least due to the difference in dimensions of the new and old showbanks. Uploading the final patch that appies to moodle1.9-weekly2008-06-30, to apply to Moodle 2.0 HEAD.
This does not contain the CSS, which will need to be added to Moodle 2.0's theme files after the merge. Naturally also the two changed question type icons have been left out at this point. uploaded the separate lang files required by the patch 2008-11-04. To be added to Moodle 2.0 HEAD after merging.
"To be added to Moodle 2.0 HEAD after merging."
Could you explain your time schedule about putting this on Moodle 2.0? The schedule is ASAP. That is, I am currently creating the patch that would apply to Moodle 2.0 instead of Moodle 1.9. I got most of that patch done today, so I expect the merge to happen within a couple of weeks. I understand from the last discussion with Tim that CVS access is being arranged. Tim, any status updates on this?
Should we understand that the version you want to apply to HEAD is the version that we can access on your demo site.
If yes, I think that Tim should take a look at it, to see if he agrees with the changes done in the interface like having a link in question name (Tim proposed to not set the name as a link) I think that these "details" should be solved before CVS to HEAD. Olli (and Pierre),
I definitely want to review the code again and test it again before it goes into HEAD. However, once the code is in HEAD, I want Olli to have CVS access so he can work on it directly, without me needing to be in the loop I think the steps are these: 1. Olli makes a patch that applies to HEAD and attached it here. Before step 5. I will move this issue into the Moodle project in this tracker, which means that it will gets a new MDL-nnnnn id to use in the commit message. All the bugs to be fixed in step 6 should be reported as separate bugs under project Moodle, component Quiz and assigned to Olli. Olli has demonstrated enough commitment to this project that I trust him to do the bug fixing after the merge into head. Olli, you might like to review the sub-tasks of this issue and try to mark some of them as resolved. So Olli welcome to the "quiz/question club"
Tim, you mentioned that strings cannot be replaced but a new one must be created. Does this imply that also mistakes can not be corrected?
Anyway, following that I did this (added the strings with "by") since not repeating "Sort" unnecessarily and taking it as "Sort questions" next to the sorting dropdown element
$string['sortage'] = 'Sort by age'; The following is not a mistake per se, but the string applies to all situations: the original string 'No questions have been added yet' may be displayed even if the category has already had questions, and would thus be false. $string['noquestions'] = 'There are no questions in this category.'; Also, I alphabetized the strings as follows. However, it seems that en_utf8/quiz.php was not alphabetized in the first place, so my script alphabetized also the old strings. Also, it is kind of hard to see from the diff which strings are really new. Is this ok? //check if we are overwriting anything I will also post the strings in Finnish for the new UI as soon as it is confirmed that the changes are ok in English. You've confused me. I cannot tell which of the sort strings are the ones that are currently in Moodle, and which ones are in your code. I'll go and look at your demo...
You need to stick to the never change lang strings rule. (Except that any string you have added during a development that has not been released yet can be changed during that development.) And remember that the rationale for the rules is to let the translators translate Moodle into all 70+ languages that Moodle supports. OK, so the problem with your approach is that you have done: Sort questions: [by type, name |v] That makes an assumption that is true in English and (I suppose) Finnish, that you have a sentence that can be broken up like that. However that is not universally true. For example Yoda would say "Questions, [by type, name |v], sort" or something. The correct way to handle this is to make strings like $string['age'] = 'by age'; (I called it questionname, rather than assuming you can re-use the 'name' string from moodle.php, because I bet there are languages where idiomatically you use different words for a person's name and the name of an inanimate object). Then do $choices = array(get_string('qtypename', 'quiz'), ...); (Then in the Yoda language pack, you can do $string['sortquestionsbyx'] = 'Questions, by $a, sort'; and it works.) I know that the quiz is full of lots of old places where language strings are concatenated in ways that make assumptions about word-order, but we should be gradually trying to eliminate them. On the other hand, it is not possible to second-guess every single language out there. Sometimes you just have to make a pragmatic decision, and rely on translators filing bugs if you have done something untranslatable. (The thing that is currently giving my big problems is that in the roles system, roles are only defined with singular names, because in some languages, you have lots of agreement rules for different numbers, not just singular an plural, so we can't support everything properly, so they made the decision to just use singular role names. However I am trying to improve the usability of pages like the assign roles page, and I want headings like 'Assign Teachers in course X', however, I can't do that. I have to use "Assign role 'Teacher' in course X" which is not as good in English.) Wherever possible, make the lang string key be as close as possible to the English string. So $string['sortbyalpha'] = 'by name'; is bad. If you were going to continue to use that string, you would be better to do $string['byname'] = 'by name';. If not, one day someone will actually want to add the string 'Sort by alpha', and will then by annoyed because the most natural key has already been taken. If quiz.php is not currently sorted, then actually it is probably better if we do your big check-in with all the new strings at the end, to make it clear what has changed. Then make a separate commit that just sorts the file. That probably leaves the clearest trace for anyone who later needs to mine CVS history. (Unrelated point. I just realised that we can use the Moodle gradebook icon for the 'Results' tab. Now we just an icon for the Info tab. How about the quiz icon there, since that is the closest thing we have to 'Home'.) I'll see what the quiz icon will look like. That sounds like a good candidate for home. Then again, using the gradebook icon for results may cause conceptual confusion, since the meanings of the functionalities are not the same but in a sense the quiz results are subordinate to the gradebook.
The problem then, with the approach you have suggested, is to include the label tag. Shall I just add it to the language string? $string['sortquestionsbyx'] = '<label for ="elementname">Sort questions by</label> $a'; Patch and demo for Moodle 2.0 coming up on Monday. The migration is quite finished, so I will be moving on to http://docs.moodle.org/en/Development:Quiz_UI_redesign_-_development#After_migration:_when_the_code_is_in_HEAD There are two bugs that seem to be caused by other parts of Moodle 2 which we need to go through: Namely, I am not sure how to get the id/context of the default category properly and adding random questions does not currently work, and for some reason adding random questions to a quiz seems to be somehow disabled in also a fresh Moodle 2.0 HEAD. To clarify a bit...
The point about adding the tab icons for preview and edit tabs was that there is a characteristic functionality that is related to exactly these concepts: editing - a quiz or a question - or previewing - a quiz or a single question. That is, the broader icon is teaching the meaning of the icons in the narrower sense, too. I do not see any problem in just leaving the other tabs without icons, since they do not really carry any comparable chance to get a novice user to "inadvertedly" learn the usabe of the app. Even though an icon for the info/home tab may not do harm, it is still mostly graphical sugar, though it can perhaps help recognize the tab more fluently, faster. No worries about the icons, it was just a wild idea late at night.
In HTML it is allowed for the <label> to completely surround the form control (and in this case, it is supposed to work without needing the for="" attribute, but as usual, IE does not respect that. Therefore, you should be able to do echo '<lable for="elementname">, get_string('sortquestionsbyx', 'quiz', $a), '</lable>'; It is better not to put HTML in lang strings, if you can avoid it. Adding a random question works for me. I just tested. About the default category. Look at question_edit_setup in question/editlib.php around line 666. Here's the patch. It did not apply for styles_color.css (due to http://cvs.moodle.org/moodle/theme/standard/styles_color.css?r1=1.182&r2=1.183
I am sorry to say but the server I run moodle on does not have the php version required by Moodle, so I am afraid I have no place to put the demo with Moodle 2 online. Compiling PHP myself is beyond my range of skills. Oh. Thanks. <label> added. No, it wasn't a bad wild idea. The below if in category_form_randomquestion.php evaluates true, so in order to make random questions work you have to comment it out. if (1 == $DB->count_records_sql("SELECT count About random questions, that form just doesn't appear for me - at least in the HEAD version I have from a couple of weeks back. It seems in edit.php module_specific_controls() the following evaluates false: if ($maxrand > 0). Hi Olli,
If you put the zip files (not the patch) here I will apply them to my 2.0 site which is PHP5. http://132.208.141.198/moodle_head_exp you can log as moodle pw:moodle If you need, I can also create an admin user with a pasword that I will send you by e-mail. Thank you Pierre, that is great.
However, I hope to get the couple of migration-borne bugs, discussed above with Tim, ironed out before putting the demo online. To clarify further about that other bug about creating random questions: I actually seem to have had getting the default category ok alright, but that default category does not seem to work with the category creating form. Access to question category has to be modified because of permission levels and context definition.
You should not go higher than the course context. In your pipi site I creates pierre random category in the top but as demo I cannot use them. However I created pierre random1 at the course level and I can access it. This is also the case when you create a question, you cannot create a question anywhere. You can move it once created .This is because of question content(files) that could be defined at a context level and will need to be moved to another context through the complex move process Pierre, I will put up the files for the current HEAD version zipped in the new MDL-17284 tomorrow.
Sorry for the delay. No problem
As they are already on HEAD, this is not necessary. http://132.208.141.198/moodle_head/ I will try to update on a dayly basis. Development continues at MDL-17284
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||