As some of you may have read in yesterday’s blog post on the Moodle workshop I ran yesterday at the Australian Moot, there was some fairly robust discussion on how the file management functionality in Moodle 2.0 differs from that in 1.9. For my money, it is the single biggest change that many users will need to deal with when they move to 2.0, and I thought I’d write up a little piece here about the problems, reasons, solutions and a work around that will make things easier for those who are coming to terms with the changes as they play with 2.0 preview releases.
First, its worth understanding the current 1.9 state of play in how files are managed.
Each course has a files area. You get the predictable stuff you’d expect for a files area like shown below – you can add files and folders, you can move them around, you can delete them – the usual.
The problems with this are many and varied, but the two biggies I know of are:
- You cannot share files across courses, making each course a silo of information, which is tedious to manage and inefficient in terms of how files are stored; and
- This files area isn’t totally secure in the sense that if a student knows a direct URL to a file and they are enrolled in the course, then they can access it. Normally this isn’t an issue, but if a teacher was to, say, publish a link to the Assignment1Answers.txt file one week, then a clever student could take a stab in the dark that there might be a file called Assignment1Answers.txt in there as well – and if there is then they can access it by modifying the original URL.
Most of the time the latter of these hasn’t been a problem – I’ve never met anyone personally who has been stung by it – but it is an undeniable flaw. The former problem (file sharing) is usually managed through an integration with an external LCMS like EQUELLA or Alfresco.
Another partially related problem
I never really thought about this until Martin’s discussion with the group yesterday, but, and I’ll say it loud and clear now – Moodle is not meant to be a file repository. When I look back at Martin’s original pedagogical drivers of social constructionism then it makes perfect sense that storing files should be low on the list of priorities. Learning in a social constructionist world isn’t about downloading and reading files, its about collaboratively constructing them with others – a critical distinction.
Learning in a social constructionist world isn’t about downloading and reading files, its about collaboratively constructing them with others
The problem though is twofold:
- Many online learning courses are nothing more than places to download lecture notes, i.e. a files repository; and
- Moodle has always supported this quite happily in the past, even with the limitations given above.
If anything this is an indicator of the problem of being known as the ‘swiss army knife’ of learning technologies – people use you for all sorts of stuff that you weren’t really intended for. I for one have used Moodle as a website, conference hub, community space and research hub – and many of these require good file management features which Moodle has been able to do well enough to meet the need – for better or worse.
The solution coming in Moodle 2.0 in layman’s terms – and please if there’s anyone from HQ reading then please correct me is to remove the concept of a bucket of files which resides within each course, and replace it with a file repository which controls access to files based on the resource/activity to which it is connected. Your ability to access the file is based on your access to the resource/activity.
To illustrate this in pictures, in Moodle 1.9 we access files like this:
Whereas in 2.0 it looks more like this:
The good thing about this model is that it solves the two problems I listed, and apparently a whole bunch of other ones. Files can be shared across courses, and opening a file up to access via (say) a ‘Link to a file’ resource doesn’t open up everything else in the course files area, because there is no course files area – there are simply files which are being accessed by some resource/activity within the course.
So what’s the problem then?
Well firstly its worth mentioning how you get files into Moodle in 2.0 now that there is no course files area, which usually needs to be done as you are adding your resource/activity. You could always do this in Moodle 1.9 (i.e. add as you go), but in the past you could also construct a neat files area with all your folders, and once you did that then start to link to your files. This was something I would always mention in my training sessions as to me it was important that if you were going to store lots of files you should try and organise them in some way – just like I do on my laptop’s hard drive. *Cough*.
Now there is no link to a ‘Files’ area in the course admin block, so Moodle 1.9 users new to Moodle 2.0 are left scratching their heads about how they are meant to manage files.
Of course you can upload files, but they are stored in a hierarchy which is perfectly logical from a design perspective, and perfectly ugly from a user perspective who is looking to access a file they’ve already uploaded, namely because the file structure looks like this when a user enters their System Files on the File Picker:
If you didn’t notice, the hierarchy (quite logically) to get to a file is:
Category>Course>Resource>[[Something Called Page Content]]>File
which like I said, makes sense, but if I’ve forgotten which resource I uploaded my file from then it can be onerous to track down the right file. Also, the more resources I’ve got, the more difficult it is to find my way through the maze of Moodle-created folders.
So what’s the fix?
This is the tricky bit – how to make it usable for those Moodle users who do not have an external file repository with all the bells and whistles. I understand that Moodle isn’t a file repository, but I also believe that a big part of Moodle’s beauty is that it works straight out of the box without having to say ‘oh, no, it can only do that if you plug it in to other product x’.
To be fair, there are plenty of things 1.9 couldn’t do, like proper LCMS functions and videoconferencing which people were cool with having to plug into other systems for, but managing files is such a basic thing (for better or worse) for many elearning practitioners that this is something worth sorting.
I think/hope the fix won’t be too difficult, combined with some re-education of 1.9 users. I can see a couple of ways out of it which don’t compromise the current situation, namely:
- Provide a search feature, which will at least let me search files which I have access to as a teacher by virtue of being enrolled in a course which has a link to a file. This already exists in things like the Flickr repository connection, so I can’t see why it couldn’t be done in the Server Files area; and/or
- Allowing metadata tags to be stored against a file, which could then be clicked or searched, again based on my access to the files as determined above.
I think one or both of these will allow the best bits of the new file management architecture to stay, while allowing users to manage files a little better, but hopefully without putting too much focus on file management.
So what about right now?
As it happens I think I’ve worked out a neat work around for now, which will get past the problems faced by adding content directly through a resource/activity – I hope this doesn’t give the guys at HQ a heart attack for suggesting it, but its all I can think of right now and it seems fair…
I also should have shown that you can hide the original folder after you’ve created it, meaning you’ve got the underlying structure even if student’s can’t see it, but I forgot, and its hometime 🙂
I think the internal Server Files area is closer to being usable than I did when I first used it, and even just knowing the work around above makes me far more comfortable that I can actually structure some files. For those who would like to vote for the tracker changes, the link for a search function is here – I think it would be worthwhile, get on and vote for it if you do to.
Hope this somewhat lengthy post has been useful.