Files usability 2.3

Files Usability 2.3
Project state	Specifications, feedback sought
Tracker issue	TBA
Discussion
Assignee	Moodle HQ DEV team

Moodle 2.3

Background

The file handling of Moodle 1.x was a very simple system with basically one server directory of files per course and very basic access controls. This system had the benefits of being simple, which meant it was easy to understand and to perform hacks around, but it's naivety had a lot of disadvantages in security, consistency, disk use, activity portability, and in some cases even led to dataloss. It also encouraged a certain workflow of "dumping" huge amounts of content into the course in an unstructured way.

The Files system was re-designed in Moodle 2.0 to solve these problems by introducing a model where files are directly associated with texts and "file areas" within different plugins in Moodle, and access to them is finely controlled by those same plugins. For some examples, the assignment module is now able to control access to assignment submissions depending on due dates and so on. Backups now accurately contain all the files they need, and multiple copies of the same file take up no more disk space than a single copy. Files can be drawn as easily from external repositories as from your own computer. The files system in Moodle 2.0 is more capable and detailed than pretty much any other system around.

However, the interfaces to CONTROL all this had to increase significantly in complexity, and this, combined with limited development time and technical constraints in web browsers have led to a large drop in usability. Not only do Moodle users have to contend with a different mindset when adding their resources to Moodle, but they also had to contend with a long list of unfamiliar interface issues.

This project aims to make large improvements in the interface when dealing with files in Moodle and improve usability significantly in Moodle 2.3.

Critical problems

This short list of problems has been identified from user feedback via Moodle partners, tracker issues with votes, user surveys, usability studies and common sense. It's not exhaustive, but covers the most severe issues that we think need to be fixed. If you'd like to comment about this list, please use the discussion page for this project or comment directly on the linked tracker issues.

Problem A: Uploading files take a lot of clicks

The most common case for most people is to upload files from their own desktop (not a repository). Since the file picker must be used for this, this can take a lot of clicks, and only one file can be uploaded at a time (unless you know how to use zip).

Solution A1: Allow drag+drop files from desktop.

We can add the ability to drag files from the desktop in multiple places. This needs some infrastructure for licensing to set default licenses at site/course/user level, because there is no opportunity to select that at upload time. File manager form elements should have an "Info" item as well that gives a dialog to edit name/license.

1. File manager form elements - this is already implemented in 2.3
2. Into file picker (private files)
3. Into file picker (upload)
4. Into course sections (auto-creation of file resources)

Solution A2: Add "quick upload" buttons that bring up dialog as quickly as possible

We can add small buttons that take the user directly to a browse-and-upload button as fast as possible, in the following places:

1. File manager form element
2. HTML editor image dialog
3. HTML editor media dialog

Solution A3: Allow multiple files to be uploaded at the same time

We can add the ability to browse/select multiple files from the desktop via one form, along with a way to update license information for all of them before saving.

Solution A4: More stickiness in file picker between invocations

The file picker should remember more of your settings from the last time you used it.

1. Last Icon/List view
2. Last server files location

Problem B: Private files management

The 'Private files" area is the main place that all users have to store files privately in Moodle. It is like a mini-repository that people can use to store files before sharing them in courses and other public places.

Solution B1: Prevent leaving the Private Files page until changes are saved

A big problem for people currently is that they can leave the filemanager page before saving their changes. A simple fix is to detect this situation just like Gmail and our Tracker do, and throw up a dialog to confirm they want to do this. The "Save" button can also be more a lot more obvious (should we also offer auto-save?)

Solution B2: Allow multiple uploads directly via Filepicker repository page

In the file picker, we should allow people to upload files directly into their Private files and then select it for use in whatever filearea they were editing, all in one step.

Solution B3: Allow users to "link" to files in their private files

Add the linking ability to private files, so that people can manage and update multiple copies of files.

Problem C: File picker looks "ugly"

Many people say that they just don't like the "MS Windows" look of the current filepicker. This look has been somewhat dictated by the choice of YUI2 to implement it, but it can be improved a lot.

Solution C1: Improve default graphics styling/layout for the dialog

It needs to look more like the rest of the Moodle interface.

It should use lightboxing to prevent access to the page, and should be larger by default.

Thumbnails and titles should flow more nicely with less cropping.

Solution C2: Implement real thumbnail images where possible

Currently we show images based on the mimetype of the file. For images, we should generate and cache small, efficient thumbnail images of the file for viewing in the file picker via lazy-loading.

Along with this, we should increase the length of pages as much as possible and reduce the number of pages. Scrolling works better than paging.

Solution C4: Add better descriptions/help for options

Options all need help icons with translated popup help. "linking files" needs to be better explained.

Solution C5: Simplify "Server Files"

Server files can be improved by tweaking file tree structures to make them more logical and reducing empty folders.

Problem D: File area management

Solution D1: A dialog in the HTML editor to manage embedded files directly

We need a way to edit the filearea that is associated with a HTML text. We currently do have one for non-Javascript users but it's never seen. We need a proper one available in the HTML editor, probably accessed as a popup dialog from a button with a yellow folder on it. Warnings need to be shown to the effect that renaming or removing files can break the HTML text.

Solution D2: Add the ability to "replace" files.

When a file is added to the file area with the same name as one that exists, a dialog should be shown allowing the user to "replace the existing file" or "rename the new file". The dialog should also indicate how many "linked copies" will be affected, if that is the case.

"Replace" means that the old file record is updated with the new content (perhaps with a version increment?) - this means that any LINKS to that file are retained, and it becomes possible to update many copies at once. This needs to be a new function in the file API.