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.
- File manager form elements - this is already implemented in 2.3
- Into file picker (private files)
- Into file picker (upload)
- 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:
- File manager form element
- HTML editor image dialog
- 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.
- Icon/List view
- Server files location (tweaking file tree structures and reducing empty folders)
Problem B: Private files management
Solution B1: Prevent leaving the Private Files page until changes are saved
Solution B2: Allow multiple uploads directly via Filepicker repository page
Solution B3: Allow users to "link" to files in their private 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
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.
