We have fallen well behind schedule unfortunately. There are a few reasons, I guess the big one being the lack of time on my part to get it done. However the task has grown a lot more complex than we originally thought. What follows is a bit of a breakdown of the tasks and an explanation of the approach we are taking for PoodLL for Moodle 2. (Lets just call it PoodLL 2)
Two broad constraints apply to our design for PoodLL 2. First, we want to integrate as closely with Moodle as possible. Second, we want to avoid the need to modify core files, since it is scary for many and makes upgrading difficult.
Regarding audio video recording for the PoodLL online assignment and question types, we are putting the student recorders into the activity itself and handling the integration of the recorded file with the Moodle file system. This will apply permissions correctly, enable portfolio stuff and be as secure as anything else in Moodle. It will also mean no need for the student to click through menu after menu to get the recorder.
Other audio/video recordings(forums, replies to students etc etc) won’t be done in the same way. This is because we want to shorten the development time, and for example in the case of the forum, we would need a custom PoodLL forum mod or a core file hack. In this and other cases we should just use a PoodLL repository for video / audio recording. Sadly this means there won’t be a big recorder in the middle of the forum post/comment to student or anything. The user will have to click the editor PoodLL button, open the PoodLL repository and record, and then click the “add” button. It will mean telling students/teachers how to do it.
We are also going to put up a publically accessible Red5 server with authentication. Registered Moodle sites will be able to use it in place of installing their own Red5 server. This should lower the bar in terms of what is required to get PoodLL 2 installed on your site. Moodle sites on cheap web hosts will be able to use Red5, which they can’t now.
To get plugins added to the TinyMCE editor you have to edit core code. It shouldn’t be like that. Prove me wrong, and I’d be happy. We are not going to hack core files in PoodLL 2, so we won’t be using Moodle’s TinyMce. Instead we are creating our own version of it, TinyPoodLL. It is just the Moodle TinyMCE with our plugins installed. but since it is a separate editor, installing it can be done without overwriting core files. People can still edit their TinyMCE to add in the PoodLL buttons if they like,we will provide the resources to do that. But we will mostly recommend TinyPoodLL. You can swap out editors using the Moodle UI. So it should be safe and require no need to edit php files. (There is a TinyMath for math style functions, which is where I got the idea.)
Now the thing that had me throwing coffee cans at students in frustration the other day was the whole repository/file picker/activity file area system. I will explain it a little here, but it gets a bit involved.
The filepicker has two functions.
i) uploading files(one by one) to a repository
ii) selecting from repository(one by one) and attaching to an activity
Moodle 2 activities don’t access these files in the repositories, directly. They have their own little area with their own files. Selecting from the repository copies a file over to the activity’s file area. From here on I will call that, “attaching” a file to an activity. The system is quite nifty actually, the activity file area is really a virtual file system. Moodle manages all access to said files via its moodle security access mechanism. You can browse and manage repositories, but there is no way that I am aware of to browse the little file area for each activity.
Sadly that just doesn’t play well with the way PoodLL accesses files. We often include paths to media files, or lists of media files, in xml files. In these cases the path to the XML file is the parameter we pass into the widget.The poodll widget first loads the xml file and then goes looking for the media files. I bust my brain figuring out a way to auto generate an xml list of all the media files that were attached to an activity for use in a list player or gallery. I got it to work. Cool. But after attaching files to an activity, we can’t manage those files, we can’t delete or rename them. Actually, we can’t even see a list of the files attached. One mistake, say the wrong video or incorrect audio, gets attached to your activity and you are toast. Delete the whole activity and try again. Once it is attached to an activity, as it currently stands, a file is untouchable.
Other widgets simply take the path to a media file as parameter. In that case to edit the activity we could attach the file with a different name and tell the poodll widget the new filename. But that gets quite tedious, especially 5 mins before class.
PoodLL can also use XML files that is not auto generated. This is the case with PoodLL flashcards. You often need to edit the xml file a few times to get it right. But after it is attached to the activity we can’t edit it anymore. Actually there is not a standard way to attach an xml file, let alone edit it after it has been attached. Even if we could attach and edit it, imagine if that file contains list of other attached media files, say flashcard images, and you want to change those too. It gets very tough.
Basically the current situation is not tenable for PoodLL.
To get around it we could
i) quit using xml and pass all config and media file information in as parameters to the widget. But it would be a headache trying to modify a file or file list, when we can’t see what is attached to the activity, and only have the option of adding files to it.
ii) keep media files completely out of the Moodle file system, in a separate web accessible directory. Then we could continue largely as we do now. But then we have lost all of the benefits of the new file system.
iii) Create a gui file browser/explorer for activity attachments. The explorer would pop up for the admin on right clicking the widget. The admin could then manage files in the activity file area directly.
We think that iii) is the best option. It worries me that I have not heard of anything like this already. Actually in a forum post one of the Moodle developers Tim Hunt specifically said that such an explorer was not necessary. But I guess here at PoodLL we are not close to mainstream in our requirements. Anyway we are doing it.
The PoodLL explorer will show a directory tree of all files attached to an activity. It would also allow the user to add a file/dir from a repository(initially File System repositories only) into an activity. There will be basic rename/delete/move/add folder/delete folder functions. You will also be able to copy files across activities. We may add upload features, so we can upload files and folders from our desktop straight into our activity.
So for each of the widgets that accepts files or lists of files as arguments, it would be a two step process. First the widget would get added to an activity via TinyPoodLL. Then the admin would use the PoodLL explorer to manage files that the widget will access.
However now the PoodLL 2 “to do” list stands at:
i) a new poodll repository(for video/audio recording basically)
ii) a revised Red5 web application, and a public red5 server
iii) a new TinyPoodLL
iv) a standalone pairwork admin console(because we no longer have a PoodLL header)
v) a PoodLL explorer(for managing activity attachments)
vi) modified poodllonline assignment
vii) modified PoodLL pairwork assignment
viii) modified PoodLL audio/video recording question
The volume of work needed to get this stuff done is pretty serious. And this is almost all just getting PoodLL 2 to do in Moodle 2 what it can already do in 1.9. But we are committed to making it happen. It is hard to say when we will have a release ready to try out. Let me just say as soon as I can, but that you shouldn’t hold your breath.